--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