These are just some Suggestions to get rid of from recovery mode of SQL database. Mostly suspension of database made due to any long process and long suspended query which generating deadlock and infinite loop for your database.
Try these option.
A. Alter database dbname set emergency
Alter database dbname set single_user
dbcc checkdb(‘dbname’,repair_allow_Data_loss)
alter database dbname set multi_user
B. we have to run dbcc checkdb only in the third step,because User does not want to loose the data. If that don't works, then we have to use allow data loss. but first option is better to restore with available backup, if back up is not there then we have to use this method.
C.First find which file is corrupted, if Data file corruption immediately take Tail log backup then restore full backup followed by differential , log backups with no recovery finally restore tail log backup with recovery.
D.
1. Ensure that the device file is actually available.
2. Use the supplemental stored procedure sp_resetstatus to reset the status of a suspect database. For more information on sp_resetstatus, see the "Resetting the Suspect Status" topic in the SQL Server Books Online. For SQL Server 6.0 and 6.5, if you have not already done so, create this procedure by executing the Instsupl.sql script, found in the Mssql\Install directory. For SQL Server 7.0 and later, this procedure is created at installation by the inscat.sql script, found in the Mssql\Install directory.
3. Use the supplemental stored procedure sp_resetstatus to reset the status of a suspect database. If you have not already done so, create this procedure by executing the Instsupl.sql script, found in the Mssql\Install directory. For more information on sp_resetstatus, see the "Resetting the Suspect Status" topic in the SQL Server Books Online.
4. Execute sp_resetstatus in the master database for the suspect database:
use master
go
exec sp_resetstatus your_database_name
5. Stop and restart SQL Server.
6. Verify that the database was recovered and is available.
7. Run DBCC NEWALLOC, DBCC TEXTALL and DBCC CHECKDB.
use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
select status from sysdatabases where name = 'Testdb'
4194329
update sysdatabases set status= 32768 where name = 'Testdb'
dbcc rebuild_log ('your database name', 'full path to a new transaction log file')
dbcc rebuild_log ('Testdb', 'D:\Program Files\Microsoft SQL Server\MSSQL\Data\testdb.ldf')
use Testdb
go
sp_dboption 'Testdb, 'single_user', true
go
dbcc checkdb ('Testdb', repair_allow_data_loss)
update sysdatabases set status= 0 where name = 'Testdb'
DBCC CHECKALLOC ('Testdb')
and
DBCC CHECKDB ('Testdb')
sp_dboption 'Testdb', 'single_user', 'false'
use master
go
sp_configure 'allow updates', 0
go
use master
go
exec sp_resetstatus Testdb
DBCC NEWALLOC
DBCC TEXTALL
DBCC CHECKDB
Try these option.
A. Alter database dbname set emergency
Alter database dbname set single_user
dbcc checkdb(‘dbname’,repair_allow_Data_loss)
alter database dbname set multi_user
B. we have to run dbcc checkdb only in the third step,because User does not want to loose the data. If that don't works, then we have to use allow data loss. but first option is better to restore with available backup, if back up is not there then we have to use this method.
C.First find which file is corrupted, if Data file corruption immediately take Tail log backup then restore full backup followed by differential , log backups with no recovery finally restore tail log backup with recovery.
D.
1. Ensure that the device file is actually available.
2. Use the supplemental stored procedure sp_resetstatus to reset the status of a suspect database. For more information on sp_resetstatus, see the "Resetting the Suspect Status" topic in the SQL Server Books Online. For SQL Server 6.0 and 6.5, if you have not already done so, create this procedure by executing the Instsupl.sql script, found in the Mssql\Install directory. For SQL Server 7.0 and later, this procedure is created at installation by the inscat.sql script, found in the Mssql\Install directory.
3. Use the supplemental stored procedure sp_resetstatus to reset the status of a suspect database. If you have not already done so, create this procedure by executing the Instsupl.sql script, found in the Mssql\Install directory. For more information on sp_resetstatus, see the "Resetting the Suspect Status" topic in the SQL Server Books Online.
4. Execute sp_resetstatus in the master database for the suspect database:
use master
go
exec sp_resetstatus your_database_name
5. Stop and restart SQL Server.
6. Verify that the database was recovered and is available.
7. Run DBCC NEWALLOC, DBCC TEXTALL and DBCC CHECKDB.
use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
select status from sysdatabases where name = 'Testdb'
4194329
update sysdatabases set status= 32768 where name = 'Testdb'
dbcc rebuild_log ('your database name', 'full path to a new transaction log file')
dbcc rebuild_log ('Testdb', 'D:\Program Files\Microsoft SQL Server\MSSQL\Data\testdb.ldf')
use Testdb
go
sp_dboption 'Testdb, 'single_user', true
go
dbcc checkdb ('Testdb', repair_allow_data_loss)
update sysdatabases set status= 0 where name = 'Testdb'
DBCC CHECKALLOC ('Testdb')
and
DBCC CHECKDB ('Testdb')
sp_dboption 'Testdb', 'single_user', 'false'
use master
go
sp_configure 'allow updates', 0
go
use master
go
exec sp_resetstatus Testdb
DBCC NEWALLOC
DBCC TEXTALL
DBCC CHECKDB