What are the reasons for the database to be in suspect state?
1) Data and Log files missing
2) Corruption of pages in the Data files.
3) Issues that are caused during Recovery/Restoring process
4) Disk level failures 5) SNA drives are missing
How to recover a database from suspect mode ?
Step 1:
Open SQL Server Management Studio and connect to the SQL Server. Make sure that your current database is set to master
Step 2:
Clear the suspect mode of the database using sp_resetstatus DatabaseName. This will clear the suspect flag and make the database available online
Step 3:
Change the database status to Emergency using the following command. Emergency mode allows you to access the databases as normal but with no consistency guarantee. This option also allows us to export the table data so that we can minimize the damage.
ALTER DATABASE DatabaseName SET EMERGENCY;
Step 4:
Restrict database to single user by changing the access mode as mentioned below
ALTER DATABASE DatabaseName SET SINGLE_USER;
Step 5:
Run the CHECKDB command with “REPAIR_ALLOW_DATA_LOSS” option.
This option should be tried as last option as it always behaves the way it is named. We are not sure of what data it removes.
DBCC CHECKDB (DatabaseName, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
Even though the step 4 is expected to result in data loss while repairing the database, I was lucky to restore the database without any loss. My job would have been much easier if the admin of the database server followed few general guidelines that allow recovery of database in case of any unexpected failures. Here are the few of them
• Backup your data frequently. (once in two days or daily or even more frequent depending on your needs)
• Have multiple backups. Move the backups to external drives or tapes frequently
• Validate that your backups are good by performing trial restores to alternate server
• Run CHECKDB regularly if possibly in your case, to know how long it regularly takes
Step 4:
Restrict database to single user by changing the access mode as mentioned below
ALTER DATABASE DatabaseName SET SINGLE_USER;
Step 5:
Run the CHECKDB command with “REPAIR_ALLOW_DATA_LOSS” option.
This option should be tried as last option as it always behaves the way it is named. We are not sure of what data it removes.
DBCC CHECKDB (DatabaseName, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
Even though the step 4 is expected to result in data loss while repairing the database, I was lucky to restore the database without any loss. My job would have been much easier if the admin of the database server followed few general guidelines that allow recovery of database in case of any unexpected failures. Here are the few of them
• Backup your data frequently. (once in two days or daily or even more frequent depending on your needs)
• Have multiple backups. Move the backups to external drives or tapes frequently
• Validate that your backups are good by performing trial restores to alternate server
• Run CHECKDB regularly if possibly in your case, to know how long it regularly takes
