HELP me please ....
-
Correction - looking back at the log we did just do a service restart. Of course, that was after 30 minutes of "OH NO!" detective work.
Chad
-
My concern is the drive being powered off possibly causing data corruption.
-
Lynn Pettis (1/19/2010)
My concern is the drive being powered off possibly causing data corruption.It may have. Or it may not have. Impossible to tell without running a checkDB, which is why I would suggest reboot (to clear any lingering effects from the missing disk) and then a checkDB before making a decision on how to proceed.
Restoring and losing a day's data because there might be corruption is not something I'd recommend. If there is corruption then, based on how serious/repairable the corruption is, an educated decision on whether or not to restore backups can be made.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
Chad Crawford (1/19/2010)
The drive came back ok when the network came up, but SQL Server didn't 'reconnect' to the file.It doesn't. Once SQL detects that a drive is missing it almost caches that, won't use that drive/file again properly until at least the service is restarted.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
Sounds good.
-
I had a similar issue once with SQL server starting before the disks on which the data files were accessible. A reboot did the trick and also I ran dbcc checkdb to make sure everything was good with the db.
The_SQL_DBA
MCTS"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
-
I thought that the server was already restarted and that after the restart the database was still unaccessible. That is why I recommended a restore. In case the server has not been restarted yet, then I have to admit that Gails approach is the best.
-
Thanks for all the posts. So even though the database appeared totally "out of wack" - technical term, once the server was restarted the database seems good. I ran a checkdb and it returned no error messages. I had restored a backup but I ended up deleting it once I confirmed that the original database was ok.
Anyway I guess I learned a few things during this process.
Cheers.
-
Glad to know that everything its ok now, I also will like to thank you for let us know how you resolve the problem.
-
scott williams-465021 (1/20/2010)
Thanks for all the posts. So even though the database appeared totally "out of wack" - technical term, once the server was restarted the database seems good. I ran a checkdb and it returned no error messages. I had restored a backup but I ended up deleting it once I confirmed that the original database was ok.Anyway I guess I learned a few things during this process.
Cheers.
Having already restored the database, you were in a position to quickly "swap" it if the checkdb had come back bad. Actually, not a bad idea if you think about it. I'm glad powering off the drive didn't corrupt anything.
-
Lynn Pettis (1/20/2010)
Having already restored the database, you were in a position to quickly "swap" it if the checkdb had come back bad.True, but in general I would still recommend checkDB first then decide on the resolution. Not all corruptions require a restore from backup to fix.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
[quote-0True, but in general I would still recommend checkDB first then decide on the resolution. Not all corruptions require a restore from backup to fix.[/quote-0]
I agree with Gail on that. In this case restart the server first, then checkDB and depending on the result, a restore may be needed.
-
GilaMonster (1/20/2010)
Lynn Pettis (1/20/2010)
Having already restored the database, you were in a position to quickly "swap" it if the checkdb had come back bad.True, but in general I would still recommend checkDB first then decide on the resolution. Not all corruptions require a restore from backup to fix.
I guess it would also depend on how long checkdb and a restore run. Checkdb on one of our production databases runs about 45 minutes. A restore of the same database usually is done in 35 minutes. In this case, I'd start both so I would have the restored database to the closest point in time ready (or almost ready) should I need it. Reduces the down time for the user community.
-
Good point Lynn, but I still will restart the server first!
-
I'll agree with restarting the server (or the instance of SQL Server, could be faster and work just as well).
Viewing 15 posts - 16 through 30 (of 38 total)
You must be logged in to reply to this topic. Login to reply