Need help tuning SQL Server 2000
-
If the seek would be looking for the key, would it not only return one row?
-
Does detatching hurt the database on the production server in any way? I saw the idea about detach/attach, and it sounds like a great way to switch over the system when we do the changeover, but I have to make sure this isn't going to adversely affect the system that we're currently using.
-
One thing I know is Detaching and Attaching are much faster than Backup and Restore.
Thanks
Sreejith
-
Brent,
The detach/attach option requires exclusive access to the database. That means only you can connect to it while running the sp_detach_db command. Don't forget that you also need to factor in the file copy time (because you can't reattach the files while they copy). The detach/attach operation itself is quite fast. If you can't afford downtime then maybe reconsider. As for "hurting" the database the main thing is that you don't want to "cut and paste" your DB files. Don't start moving files around. That just complicates things.
Having said that, detaching/attaching may not yield anything for you. I suggested it as an alternative to backup/restore as a process of elimination. Again, the biggest headache is the copy time required from one server to another. If your database is several GB and your network isn't robust then you will just be sitting there (for what seems an eternity) twiddling your thumbs while your files copy. And, of course, while your boss breathes down your neck asking "Are you done yet? What about now? Now??"
As a side: How many files does your database have (including the log file)? If there are more than 16 files then you need to do things a little differently.
James Stover, McDBA -
I have two files, a data and a log file. What do you mean by "cut and paste" the files? And why would moving files around hurt things?
The database is about 3.5GB in size.
Viewing 5 posts - 46 through 49 (of 49 total)
You must be logged in to reply to this topic. Login to reply