--1，先停止服务器，然后备份tigerzz_Data.mdf和tigerzz_Log.ldf文件。
--2，启动服务器，然后删除数据库tigerzz。
--3，建立一个供恢复使用的数据库tigerzz。
--4，停止数据库服务器。
--5，将刚才生成的数据库的日志文件tigerzz_Log.ldf删除，用要恢复的数据库tigerzz_Data.mdf文件
-- 覆盖刚才生成的数据库数据文件tigerzz_Data.mdf。
--6, 启动数据库服务器。此时数据库tigerzz的状态为“置疑”。
--7，在查询分析器运行下面代码，允许对系统目录修改
u master
教师家访记录内容go
sp_configure 'allow updates',1
go
reconfigure with override
go
--8，设置数据库tigerzz为紧急修复模式
update sysdatabas t status = 32768 where name ='tigerzz'
go
--9，重建数据库日志文件
dbcc rebuild_log('tigerzz','E:\Program Files\Microsoft SQL Server\MSSQL\Data\tigerzz_Log') --改为你的目录
go
代表英文--10，验证数据库一致性
DBCC CHECKDB('tigerzz')
go
--11，恢复数据库为正常状态
sp_dboption 'tigerzz','dbo u only','fal'
go
--12，禁止修改系统选项
sp_configure 'allow updates',0
go
reconfigure with override
go
首先确认已经备份了.mdf和.ldf文件。
2. 在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。
3. 用原有的.mdf和.ldf4月23日文件覆盖新建数据库对应的.mdf和.ldf文件。
4. 重新启动SQL Server服务，这是应该会看到这个数据库处于置疑（Suspect）状态。
5. 在SQL查询分析器中执行以下命令，以允许更新系统表：
u mastergosp_configure ‘allow updates’,1reconfigure with overridego
6. 将这个数据库置为紧急模式：
update sysdatabas t status = 32768 where name = ‘db_name’go
7. 使用DBCC CHECKDB命令检查数据库中的错误：
DBCC CHECKDB(‘db_name’)GO
8. 如果DBCC CHECKDB命令失败，请转至第动漫背景素材10步，否则先将数据库置为单用户模式，再尝试对其进行修复：
sp_dboption ‘db_name’,’single ur’,’true’DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)GO
如果在执行DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)命令时提示说数据库未处于单用户模式状态的话，则重新启动SQL Server服务，然后继续尝试。
9. 如果DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)命令失败，请转至第大胆尝试10步，否则若成功修复了数据库中的错误：
重新执行DBCC CHECKDB(‘db_name’)命令，确认数据库中已没有错误存在。
清除数据库的置疑状态：sp_retstatus ‘db_name’
清除数据库的单用户模式状态：sp_dboption ‘db_name’,’single ur’,’fal’
重新启动SQL Server服务，如果一切正常的话，则数据库已经成功恢复。
10. 如果以上步骤都不能解决问题的话，请参考附件中的文档尝试通过重建事务日志来恢复数据库中的数据。如果您只有MDF文件，问题就更加复杂一些，我们需要直接重建事务日志了:
1. 在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。
2. 用原有的ldf文件覆盖新建数据库对应的.mdf文件，将其日志文件（.ldf）删除。
3. 启动SQL Server服务，并将数据库置为紧急模式（同上: 步骤5和步骤6）。
4. 停止并重新启动SQL Server服务。
5. 执行以下命令重建数据库日志文件：(下面是个示例，您要用您实际的数据库名)
DBCC REBUILD_LOG（’cas_db’, ‘D:\cas_db\cas_db_Log.LDF’）
6. 重新将该数据库置为单用户模式。
7. 再次尝试使用DBCC CHECKTABLE或DBCC CHECKDB命令检查并修复数据库中的错误
--SQL SERVER数据库置疑后恢复步骤
--1． 恢复步骤：
--a.将smlog_log.ldf文件备份到其它目录下；
--b.将源目录下的smlog_log.ldf文件改名为smlog_log_bak.ldf；
--c.执行以下语句修改数据库的状态：
u Master
go
update sysdatabas t status=32768 where name='数据库名称' --修改状态,設為緊急狀態
go
shutdown with nowait --停止数据库服务器
go
--d.退出SQL并在(COMMAND)命令行模式中通过下面的代码重新启动SQL：
sqlrvr -c -T3608 -T4022 --安全模式启动SQL SERVER
--e.在查询分析器中执行以下语句来查看刚刚修改过状态的数据库状态：
lect Name,Status from sysdatabas where Name='数据库名稱'
--f.执行以下代码新建日志文件：
dbcc traceon(3604)--跟踪
dbcc rebuild_log('数据库名称','日志文件全路徑') --文件名要有全路径和扩展名
--dbcc rebuild_log('prs_msc','d:\mscsql\mssql\data\prs_msc_log.ldf
--g.将数据库置回正常状态：
update sysdatabas t status=0 where name='数据库名称'
--h.重新启动数据库后执行以下语句检查数据库：
DBCC CHECKDB --如果执行完有错误用以下语句修复
--i.要修复数据库必需将数据库改为单用户模式：
Exce sp_dboption '数据库名称','single ur','true'---('fal'恢复多用户)
--j.执行以下语句修复数据库：
DBCC CHECKDB('数据库名称',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS：是比较高级的修复方式
REPAIR_FAST：是简单快速的修复方式
/*
處理状态就为"置疑"的數據庫
备份数据文件,然后按下面的步骤处理:
1.新建一个同名的数据库(数据文件与原来的要一致)
2.再停掉sql rver(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql rver
5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.
*/
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
辅导培训
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Go
sp_dboption '置疑的数据库名','single ur','true'
Go
DBCC CHECKDB('置疑的数据库名')
朋友生日送什么花合适Go
update sysdatabas t status=28 where name='置疑的数据库名'
广西玉林必去景点大全Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的数据库名', 'single ur','fal'
Go
