Skip to content

MS SQL Server 2000/2005/2008/2008R2数据库质疑修复总结

2013-11-24 16:25:24   来源:技王数据恢复

MS SQL Server 2000/2005/2008/2008R2数据库质疑修复总结

1前言

本文的步骤基于以下条件:

1.SQL Server可以启动。

2.数据库没有做有效的备份。

3.当前用户有Sysadmin权限。

数据库质疑的原因会有多种多样,不同的suspect采用的步骤也会有所不同,以下的步骤不能适用所有的情况,但包括了一些基本的步骤。数据库suspect是指数据库内部处于不一致的状态,很有可能会有数据丢失。 我们推荐您从“好的数据库备份”恢复。 我们这里所指的“好的数据库备份”是指:

1.在做数据库备份之前,您检查过DBCC CHECKDB没有错误。

2.备份之后的数据库没有更改,或者更改可以忽略。

在做任何修复操作之前,请务必备份.mdf/.ndf以及.ldf文件。

2SQL Server 2000修复步骤

如果没有“好的数据库备份”,我们不能保证没有数据丢失。 以下是恢复suspect数据库 (SQL Server 2000)的一般方法,供您参考。 同时在操作下列步骤之前,您可以备份质疑数据库的MDFNDFLDF文件,以便以下步骤恢复失败时能够回滚到原来的状态。

1.在查询分析器中,运行如下命令将数据库置于紧急模式。

Sp_configure 'allow update', 1

Go

Reconfigure with override

Go

Begin Tran

Update master..sysdatabases set status = 32768 where name ='

Commit Tran

--此处需要替代成您出问题的数据库名字。

--以下同

Go

Select * from sysdatabases

--检查数据库状态是否已经变成32768

Go

2.重启SQL Server服务。

3.如果第二步中重启服务,数据库再次进入suspect模式,请设置数据库紧急模式,使用BCP方式导出数据。

否则在查询分析器中,重新连接到SQL Server,运行如下命令重建日志。

特别注意:dbcc rebuild_log是内部命令,请您阅读附件中的DBCC Rebuild Run Command.doc。 只有当您同意了附件中的内容,才可以运行此命令。

dbcc rebuild_log('’,'')

--此处是新的日志文件的物理文件的绝对地址。

go

如果rebuild_log失败,请运行如下命令,

Use

Go

如果数据库在emergency方式能够进入紧急模式,直接使用BCP方式导出数据,没有其他方式来恢复数据库。

如果不能进入,则没有其他方式恢复数据库

如果数据库在Rebuild_log之后恢复正常,进入第四步。

4.关掉查询分析器,再次打开查询分析器,运行如下语句,查询出问题的数据库的DBID

Select * from master.dbo.sysdatabases

Go

5.再运行如下命令,检查是否有人在使用当前出问题的数据库,如果有的话,请将他们退出。

Select * from master.dbo.sysprocesses

Go

6.然后运行如下命令,将数据库置于单用户使用模式。如果设置不生效,可以尝试使用企业管理器->数据库属性->选项来直接设置.

exec sp_dboption N'', N'single', N'true'

7.在查询分析器中,运行如下命令,检查数据库是否有损坏。

dbcc checkdb(‘')

go

8.如果您运行上述命令发现数据库有错误。 此时我们需要根据错误来处理。 接下去有两个方向。

方向一:

使用Repair_Allow_Data_Loss选项修复数据库。

优点: 可能可以恢复尽量多的数据

缺点:

a)不一定能够将全部错误修复,还有可能越修越多。同时,需要大量时间,需要经过多次执行修复命令.十几次,甚至数十次.修复时间不能预估.

b)就算我们将所有错误修复,我们也不能保证数据在应用程序逻辑这一层次上的数据正确性,您需要找您的应用程序提供商来检查数据在程序逻辑层次是否正确。

dbcc checkdb ('', REPAIR_ALLOW_DATA_LOSS) go

--此命令可能需要运行多次,才能完全修复。

方向二:

通过BCPDTSselect into等方式将好的表,或者表中好的数据导出来。建议使用BCP的方法,这样可以最大限度的回复数据.BCP会停在出错的纪录上,但是前面的数据就能成功导出.使用DTSSelect into的话,我们很难判断最大限度能导出的记录数.

优点:导出来的数据保证在应用程序逻辑这一层次的正确性

缺点:不会修复数据库中存在的错误,丢失的数据量会比较大,取决于第7步的运行结果。

9.数据库完全恢复正常之后,将数据库置于正常状态,并将单用户模式改成多用户模式。(16或者0)

begin tran

update sysdatabases set status = 8 where name = 'db_name'

commit tran

sp_configure 'allow', 0

go

reconfigure with override

exec sp_dboption N'', N'single', N'false'

go

另外,上述步骤之前或者之中,可能会有数据库在企业管理器中看不到,并且无法attach的状况。 通常可以建同名数据库(注意:物理文件名也要一致),停止SQL Server,覆盖文件,重启SQLServer的方式来解决。

3SQL Server 2005/2008/2008R2修复步骤

方法一

alter databaseset emergency

go

alter databaseset single_user with rollback immediate

go

use

go

dbcc checkdb

go

use master

go

alter databaseRebuild Log on

(name=_log,filename='c:\sql\logs\_log.LDF')

go

select * from sys.databases

go

dbcc checkdb('', repair_allow_data_loss)

go

sp_dboption '','single user','false'

方法二

alter database set emergency

go

alter database set single_user with rollback immediate

go

use master

go

alter database Rebuild Log on

(name=_log,filename='c:\sql\logs\_log.LDF')

go

use

go

dbcc checkdb

go

--此时checkdb有错误才需要做步骤d)

d)此时数据库应处于emergency状态,创建一个新数据库,通过bcp/bulk insert/DTS/SSIS方式将数据导出到新的数据库.

请注意,这种情况下索引,存储过程,视图等,都需要手工导出来。

4导数据总结

1.创建一个空的数据库。

2.使用脚本禁用所有外键约束。

Use<NewDatabase>

GO

DECLARE@disableBIT

set@disable=1

DECLARE

@sqlVARCHAR(500),

@tableNameVARCHAR(128),

@foreignKeyNameVARCHAR(128)

-- A list of all of the Foreign Keys and the table names

DECLAREforeignKeyCursorCURSOR

FOR

SELECT

ref.constraint_nameASFK_Name,

fk.table_nameASFK_Table

FROM

INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTSref

INNERJOININFORMATION_SCHEMA.TABLE_CONSTRAINTSfkONref.constraint_name=fk.constraint_name

ORDERBY

fk.table_name,

ref.constraint_name

OPENforeignKeyCursor

FETCHNEXTFROMforeignKeyCursorINTO@foreignKeyName,@tableName

WHILE(@@FETCH_STATUS=0)

BEGIN

IF@disable=1

SET@sql='ALTER TABLE ['+@tableName+'] NOCHECK CONSTRAINT ['+@foreignKeyName+ 上一篇:硬盘数据永久删除,你关注过吗???下一篇:Microsoft Exchange Server 2013 RDB邮箱数据库恢复

Back To Top
Search