|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Friday, November 05, 2010 10:14 AM
Points: 3,
Visits: 49
|
|
| On occasion a log file will fill up to the problem point and we could use detach/attach to delete the old log and start over. Not something that we would normally want to do but something that was an option in an emergency. Is there a simple way to do that once detach/attach goes away?
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Today @ 3:01 PM
Points: 2,065,
Visits: 3,453
|
|
Jonathan Kehayias (5/27/2009)
Brian Munier (5/27/2009) Interesting article, thank you. My question is if detach/attach is going away, and I want to move a database from one server to another server does that mean I now have to use backup/restore which can be slower and require more effort to work?You should use CREATE DATABASE [databasename] FOR ATTACH as shown in the quote from the Books Online. This has a much more verbose syntax and allows for the options needed to be configured while the database is created to include, who the owner should be, one of the other problems listed in the comments here.
...and there is a great script for this HERE
David
@SQLTentmaker SQL Tentmaker “He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Thursday, April 05, 2012 2:35 PM
Points: 2,007,
Visits: 767
|
|
GRE (5/27/2009) Have i missed a trick here? I understand that the old way to attach a database is be depreciated, But is SP_Detach_DB bein decreciated too? or will that remain? Yes, both the attach and detach stored procedures are deprecated, here is the page for sp_detach_db from Books Online (see the Important box just after the syntax section):
http://msdn.microsoft.com/en-us/library/ms188031.aspx
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Thursday, October 04, 2012 11:13 AM
Points: 257,
Visits: 80
|
|
David Benoit (5/27/2009)
Jonathan Kehayias (5/27/2009)
Brian Munier (5/27/2009) Interesting article, thank you. My question is if detach/attach is going away, and I want to move a database from one server to another server does that mean I now have to use backup/restore which can be slower and require more effort to work?You should use CREATE DATABASE [databasename] FOR ATTACH as shown in the quote from the Books Online. This has a much more verbose syntax and allows for the options needed to be configured while the database is created to include, who the owner should be, one of the other problems listed in the comments here. ...and there is a great script for this HERE
Thanks, I think my colleague uses this script all the time.
Brian
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Monday, June 03, 2013 7:03 PM
Points: 1,696,
Visits: 1,746
|
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Monday, June 03, 2013 7:03 PM
Points: 1,696,
Visits: 1,746
|
|
David Benoit (5/27/2009)
Jonathan Kehayias (5/27/2009)
Brian Munier (5/27/2009) Interesting article, thank you. My question is if detach/attach is going away, and I want to move a database from one server to another server does that mean I now have to use backup/restore which can be slower and require more effort to work?You should use CREATE DATABASE [databasename] FOR ATTACH as shown in the quote from the Books Online. This has a much more verbose syntax and allows for the options needed to be configured while the database is created to include, who the owner should be, one of the other problems listed in the comments here. ...and there is a great script for this HERE
Excellent script David. Thanks for pointing that out.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008 My Blog | Twitter | MVP Profile Training | Consulting | Become a SQLskills Insider Troubleshooting SQL Server: A Guide for Accidental DBAs
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Tuesday, March 26, 2013 9:55 AM
Points: 1,024,
Visits: 2,768
|
|
GRE (5/27/2009) -------------------------------------------------------------------------------- Have i missed a trick here? I understand that the old way to attach a database is be depreciated, But is SP_Detach_DB bein decreciated too? or will that remain?
Yes, both the attach and detach stored procedures are deprecated, here is the page for sp_detach_db from Books Online (see the Important box just after the syntax section):
http://msdn.microsoft.com/en-us/library/ms188031.aspx
Yes i saw that....but It offers no alternative,like the SP_Attach_Db BOL entry does, so if both these sp are being depreciated, how are you going detach a db in the first place to warrant attaching it using this new script?
Gethyn Ellis
gethynellis.com
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Tuesday, March 26, 2013 9:55 AM
Points: 1,024,
Visits: 2,768
|
|
Noel McKinney (5/27/2009)
GRE (5/27/2009) Have i missed a trick here? I understand that the old way to attach a database is be depreciated, But is SP_Detach_DB bein decreciated too? or will that remain?Yes, both the attach and detach stored procedures are deprecated, here is the page for sp_detach_db from Books Online (see the Important box just after the syntax section): http://msdn.microsoft.com/en-us/library/ms188031.aspx
Yes i saw that....but It offers no alternative,like the SP_Attach_Db BOL entry does, so if both these sp are being depreciated, how are you going detach a db in the first place to warrant attaching it using this new approach?
Gethyn Ellis
gethynellis.com
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: 2 days ago @ 5:09 AM
Points: 134,
Visits: 620
|
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Tuesday, April 06, 2010 1:30 PM
Points: 34,
Visits: 82
|
|
It is a terrible practice to detach a database from a production server. If you had any corruption in any database file or in the server itself, you will never be able to re-attach it. I know from experience this is so.
The CORRECT way to migrate a database and its files to a new location is through a manual backup and restore.
Ensure you use INIT in the backup statement. Ensure you disconnect the users before restoring it.
In this way you avoid business exposure to corruption. If it is corrupt, it will not restore. But the database will remain online for the business to use it while you and your team figure out what to do about the corruption. Then in an orderly, non-destructive way, you can migrate the business to a new solution, whatever that is.
NEVER detach a production database unless you want to answer the business challenge with a job interview elsewhere.
|
|
|
|