Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Nicademas
Starting Member
10 Posts |
Posted - 2009-04-22 : 12:52:39
|
| Hi.My database is in use.I have a couple GB of data in the database but need to get the data and log files moved over to the D: drive and have the instance start using it there. Seen some documentation, but curious if anyone has done this post-deployment and has some advice.Right now it is on: C:\Program Files\Microsoft SQL Server\MSSQL10.MyInstance\MSSQL\DATAand I want it to go to:D:\MSSQL\DATAThank you kindly.Nic |
|
|
SwePeso
Patron Saint of Lost Yaks
30421 Posts |
Posted - 2009-04-22 : 13:02:04
|
You can always detach, move the files (both data and log), and attach them again. E 12°55'05.63"N 56°04'39.26" |
 |
|
|
dinakar
Master Smack Fu Yak Hacker
2507 Posts |
Posted - 2009-04-22 : 14:55:25
|
| you need to stop any connections to the database first, before you detach.Dinakar Nethi************************Life is short. Enjoy it.************************http://weblogs.sqlteam.com/dinakar/ |
 |
|
|
Nicademas
Starting Member
10 Posts |
Posted - 2009-04-22 : 15:04:59
|
| What are the commands to kill users and disallow connections; and then restart conenctions?Thanks! |
 |
|
|
tosscrosby
Aged Yak Warrior
676 Posts |
Posted - 2009-04-22 : 15:49:29
|
| Obviously the kill command (I assume it's still valid in 2008). To stop any connections, how is the application attaching to the database? If through an app service, stop the service and start it when your done. Also, once you dettach the database, no new connections will be allowed either, until you reattach at the new location.Terry-- Procrastinate now! |
 |
|
|
RyanAustin
Yak Posting Veteran
50 Posts |
Posted - 2009-04-23 : 19:44:22
|
| Doing the detach and reattach can be tricky though. Especially if you catch a user with a large open transaction. You may be better taking an outage and backing up and restoring the database over it with a replace. Then you can specifiy where the data and log file is going. I have seen a data file corrupt on a production database and it wasn't pretty explaining to the manager's that it needs to be restored with potential loss of data. Better be safer then sorry. Ryan |
 |
|
|
|
|
|