September 15, 2009 at 8:16 am
triggered by a remark from george sibbald i'm curious about this:
what kind of causes have you seen where you had to rebuild/recover/restore your master db (and perhaps other system db files) on production based systems. situations where a reinstall of sql server could be skipped.
the range is from disk corruption till windows operators making a mistake while using office on your production server.
in 2 situations i have thought about repairing the master db. both where diskcorruption issues. once with a damaged disks and once very likely with bugged diskdrivers. in both cases it turned out my user data was also corrupt.
in the first situation we replaced the database disks and restored all db's (including master) from backup's.
in the second situation, after ping pong with different support departments, we decided to replace even the hardware (it was a very critical system).
September 15, 2009 at 8:48 am
I had a situation where a 3rd party app was deployed and the database was stuck in recovery/readonly simultaneously and attempting to drop/detach/recover or otherwise change the state of the database caused SQL to basically lock up and start producing memory dumps. nothing we tried could get rid of that database, so we had to rebuild master to basically remove all the user databases.
September 15, 2009 at 9:01 am
I've only seen this with corruption. However in DR situations you have to restore master, which can be a nice challenge if you're not used to it.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply