sql server数据库的检测及修复方法

随着K/3产品的推广，要求客户服务人员对SQL SERVER数据库的了解也进一步提高。在K/3的使用过程中，数据库文件被频繁地使用，由于某些原因，数据库有可能被损坏，本文将针对这种情况的数据库 检测及修复方法做一简单讲解。希望各位在实际工作过程中有新的发现时，及时给我们提供信息，以便做进一步的更新。

1. 数据文件修复

1.1 SQL SERVER数据库的检测

SQL SERVER提供了数据库检测的命令，可用DBCC CHECKDB对数据库中各个对象的分配及结构的正确性进行检测，并可通过一参数控制，将所有的错误信息显示出来。其语法如下：

DBCCCHECKDB

('database_name'[,NOINDEX | { REPAIR_ALLOW_DATA_LOSS

|REPAIR_FAST

|REPAIR_REBUILD

}]

) [WITH{ALL_ERRORMSGS | NO_INFOMSGS}]

参数说明：

'database_name'代表被检测的数据库实体名；

NOINDEX指非系统表的非聚族索引不检测；

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST|REPAIR_REBUILD 指直接修复发现的错误，其中REPAIR_ALLOW_DATA_LOSS代表，若此错误不能修复时，系统将直接删除相关数据。带此三个参数的任一个时， 数据库必须处于单用户模式，可在Enterprise Manager中的数据库属性中设置；

ALL_ERRORMSGS代表将检测到的错误信息全部显示出来，否则，对于每张表最多只显示200条错误信息；

NO_INFOMSGS代表隐藏所有的信息及占用空间的报告。

经过检测，对于错误的对象，将以OBJECT ID的形式报告具体出错的信息，可根据OBJECT ID到系统表sysobjects中查找到相关的表，即NAME。

1.2 SQL SERVER问题数据库的修复

经过数据库检测后，可针对出现的问题采取相应的措施进行处理。如通过检测后，发现对象的物理存放存在问题，可用DBCCCHECKALLOC来进行修复：

DBCCCHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS |NO_INFOMSGS}]

若是非系统对象的索引出错，则可用DBCC DBREINDEX进行修复：

DBCCDBREINDEX ( [ 'database.owner.table_name' [, index_name [, fillfactor ] ] ] )[WITH NO_INFOMSGS]

以上两种情况，也可直接使用DBCC CHECKDB(‘db_name’,repair_rebuild)来修复。

另外一种情况是在进行检测时，提示无法建立数据连接，此时表明，数据库已损坏。对于这种情况，我们可采取如下措施来尝试修复。

首先，在SQL Enterprise中新建一数据库（如数据库名为test）,建好数据库后，停止SQL Server Service Manager，并将客户数据库的MDF文件更名为test _data.mdf(即新建数据库的主文件名)，然后用更名后的文件覆盖新建数据库同名文件，接着，启动SQL ServerService Manager。对Master数据库将系统表设置为可更改状态

UseMaster

Go

sp_configure'allow updates', 1

reconfigurewith override

Go

将数据库设为紧急状态：

updatesysdatabases set status = 32768 where database '

停止并重新启动SQL Server Service Manager，并重建Log文件：

DBCCTRACEON (3604)

DBCCREBUILD_LOG(' test ','test _log_ldf')

将数据库设置为单用户模式，然后进行检测：

sp_dboption' test ', 'single user', 'true'

DBCCCHECKDB(' test ')

Go

此数据库执行CHECKDB的过程中发现一些表的索引被破坏，于是针对具体的表进行重建索引的操作：

DBCCDBREINDEX（表名）

如执行以上操作仍然不能解决，若索引破坏的表是临时表或不是关键表，则可从新建账套中引入，若是主表，则可能通过近期的备份来（部份）恢复。若没有一个备份，则无法修复。

1.3 SQL Server数据库为什么易损坏呢？

以下是微软提供的一些可能引起数据库损坏的原因及一些预防措施：

操作问题，包括冷起动机器、热拔硬盘、删除一些数据库文件；

硬件问题，包括磁盘控制器的问题；

操作系统问题，包括与系统相关的一些致命错误。

预防措施：

1、定期/不定期执行CHKDSK(不带参数)，以检测硬盘物理结构并修复一些CHKDSK报告的问题；

2、常备份数据。

1.5 应用数据库修复举例

declare@databasename varchar(255)

set@databasename='AIS20021224170730'------一定要手工输入

--执行一般性修复还存在问题时,进行允许数据丢失的修复

--许数据丢失的修复要求在单用户下进行,此时请退出中间层,客户端,sql的其他模块

--所有功能退出,在查询分析器master里设置数据库为单用户

execsp_dboption @databasename, N'single', N'true'

--在查询分析器master里,进行修复数据库

dbcccheckdb(@databasename,REPAIR_ALLOW_DATA_LOSS)

dbcccheckdb(@databasename,REPAIR_REBUILD)

--还原数据库状态

execsp_dboption @databasename, N'single', N'false'

2.数据库日志损坏的修复

请遵照如下步骤来试图重建数据库事务日志.

注意: 由于事务日志丢失, 数据库可能有没有提交的数据.

注:都要替换成真实的数据库名字

2.1 步骤1:

创建一个新的数据库,命名为原来数据库的名字.

2.2步骤2:

停止SQL Server

2.3步骤3:

把老数据库的MDF文件替换新数据库的相应的MDF文件, 并把LDF文件删除

2.4步骤4:

重新启动SQL Server 服务,然后运行如下命令:

UseMaster

Go

sp_configure'allow updates', 1

reconfigurewith override

Go

begintran

updatesysdatabases set status = 32768 where db_name'

-- Verifyone row is updated before committing

committran

2.5步骤5:

停止SQL然后重新启动SQL Server 服务,然后运行如下命令:

DBCCTRACEON (3604)

DBCCREBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF')

Go

2.6步骤6:

停止SQL然后重新启动SQL Server 服务,然后运行:

usemaster

update sysdatabasesset status = 8 where

Go

sp_configure'allow updates', 0

reconfigurewith override

Go

2.7步骤7:

运行dbcc checkdb(db_name)检查数据库的完整性.

3 数据库质疑的一般处理

1、执行如下SQL（打开修改系统表的开关）：

EXECsp_configure 'allow updates', 1

RECONFIGUREWITH OVERRIDE

2、修改数据库Master中的表：sysdatabases

将 status字段数值更改为4

3、再执行如下SQL：

EXECsp_configure 'allow updates', 0

RECONFIGUREWITH OVERRIDE。