Help! Suspect Databases - Hardware Failure

We have numerous suspect databases across multiple serverse due to a hardware
failure on our SAN. The part of the SAN that failed had a combination of data
and log files, but not both for a given database.
Right now we have services shut down on the server. When we bring the server
back up, after fixing our hardware failure, what would be the best steps?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200703/1"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:6eca09c69ec9c@.uwe...
> We have numerous suspect databases across multiple serverse due to a
> hardware
> failure on our SAN. The part of the SAN that failed had a combination of
> data
> and log files, but not both for a given database.
> Right now we have services shut down on the server. When we bring the
> server
> back up, after fixing our hardware failure, what would be the best steps?
BEFORE bringing up the server, make complete backups of all files.
Then once you bring up the server, check the logs and find out why the
databases are suspect.
In some cases it may be as simple as the drive letters or paths no longer
being right and once you fix those, the database may come up cleanly.
If it's more complex, you'll have to do different things, but hard to
recommend w/o knowing in advance the exact nature of the problems.
No matter what I'd make sure to do a DBCC checkdb once the database is back
up, just to be sure.
(btw, I've found that it takes pretty bad problems to outright corrupt a SQL
2000/2005 database, so you may luck out.)
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200703/1
>
--
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||Thanks Greg. Once the hardware was repaired and we restarted the services (we
had complete backups available) all databases came up cleanly.
If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run after
hours, if there were errors encountered, would I still be informed, even
though I had the "WITH NO_INFOMSGS" option?
Greg D. Moore (Strider) wrote:
>> We have numerous suspect databases across multiple serverse due to a
>> hardware
>[quoted text clipped - 5 lines]
>> server
>> back up, after fixing our hardware failure, what would be the best steps?
>BEFORE bringing up the server, make complete backups of all files.
>Then once you bring up the server, check the logs and find out why the
>databases are suspect.
>In some cases it may be as simple as the drive letters or paths no longer
>being right and once you fix those, the database may come up cleanly.
>If it's more complex, you'll have to do different things, but hard to
>recommend w/o knowing in advance the exact nature of the problems.
>No matter what I'd make sure to do a DBCC checkdb once the database is back
>up, just to be sure.
>(btw, I've found that it takes pretty bad problems to outright corrupt a SQL
>2000/2005 database, so you may luck out.)
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200703/1|||"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:6ecae312206bc@.uwe...
> Thanks Greg. Once the hardware was repaired and we restarted the services
> (we
> had complete backups available) all databases came up cleanly.
>
Glad to hear it.
> If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run
> after
> hours, if there were errors encountered, would I still be informed, even
> though I had the "WITH NO_INFOMSGS" option?
I believe so.
>
--
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||On 06.03.2007 22:11, cbrichards via SQLMonster.com wrote:
> Thanks Greg. Once the hardware was repaired and we restarted the services (we
> had complete backups available) all databases came up cleanly.
> If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run after
> hours, if there were errors encountered, would I still be informed, even
> though I had the "WITH NO_INFOMSGS" option?
Wouldn't it be better to run this first before using the DB again? I
mean if there were issues you'd rather want to fix them before you put
the DB back in production.
Kind regards
robert