如何修复sql数据库数据不一致

修复sql2000数据库置疑在实际的 *** 作中由于突然断电或者突然断网造成数据库置疑（在企业管理器中数据库后面出现置疑两个字），下面我们通过以下方法来进行修复置疑的数据库。A．我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQLServerEnterpriseManager里面建立。B停掉数据库服务器。C将刚才生成的数据库的日志文件test_logldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_datamdf。D启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。E设置数据库允许直接 *** 作系统表。此 *** 作可以在SQLServerEnterpriseManager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。usemastergosp_configure'allowupdates',1goreconfigurewithoverridegoF设置test为紧急修复模式updatesysdatabasessetstatus=-32768wheredbid=DB_ID('test')此时可以在SQLServerEnterpriseManager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表G下面执行真正的恢复 *** 作，重建数据库日志文件dbccrebuild_log('test','C:\ProgramFiles\MicrosoftSQLServer\MSSQL\Data\test_logldf')执行过程中，如果遇到下列提示信息：服务器:消息5030，级别16，状态1，行1未能排它地锁定数据库以执行该 *** 作。DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQLServerEnterpriseManager打开了test库的系统表，那么退出SQLServerEnterpriseManager就可以了。正确执行完成的提示应该类似于：警告:数据库'test'的日志已重建。已失去事务的一致性。应运行DBCCCHECKDB以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。此时打开在SQLServerEnterpriseManager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。H验证数据库一致性（可省略）dbcccheckdb('test')一般执行结果如下：CHECKDB发现了0个分配错误和0个一致性错误（在数据库'test'中）。DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。I设置数据库为正常状态sp_dboption'test','dbouseonly','false'如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。J最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQLServerEnterpriseManager里面恢复，也可以使用如下语句完成sp_configure'allowupdates',0goreconfigurewithoverridego

用dbcc

checkdb

检查数据库。

DBCC

CHECKDB

重启服务器后，在没有进行任何 *** 作的情况下，在SQL查询分析器中执行以下SQL进行数据库的修复，修复数据库存在的一致性错误与分配错误。

use

master

declare

@databasename

varchar(255)

set

@databasename='需要修复的数据库实体的名称'

exec

sp_dboption

@databasename,

N'single',

N'true'

--将目标数据库置为单用户状态

dbcc

checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)

dbcc

checkdb(@databasename,REPAIR_REBUILD)

exec

sp_dboption

@databasename,

N'single',

N'false'--将目标数据库置为多用户状态

然后执行

DBCC

CHECKDB('需要修复的数据库实体的名称')

检查数据库是否仍旧存在错误。注意:修复后可能会造成部分数据的丢失。

从你的出错来看“ 0 个分配错误和 1 个一致性错误”可能是索引问题，一致性出错多数情况是索引问题，你可以drop 所有索引，再检查一下表。

另数据库比较保守的修复方法是

DBCC CHECKDB('数据库名',REPAIR_REBUILD )

因为REPAIR_ALLOW_DATA_LOSS

尝试修复报告的所有错误。这些修复可能会导致一些数据丢失。

REPAIR_REBUILD

执行不会丢失数据的修复。这包括快速修复（如修复非聚集索引中缺少的行）以及更耗时的修复（如重新生成索引）。

1、修改数据库为紧急模式ALTER DATABASE Stock SET EMERGENCY

2、使数据库变为单用户模式ALTER DATABASE Stock SET SINGLE_USER

3、修复数据库日志重新生成，此命令检查的分配，结构，逻辑完整性和所有数据库中的对象错误。当您指定“REPAIR_ALLOW_DATA_LOSS”作为DBCC CHECKDB命令参数，该程序将检查和修复报告的错误。但是，这些修复可能会导致一些数据丢失。DBCC CheckDB (Stock, REPAIR_ALLOW_DATA_LOSS)

4、使数据库变回为多用户模式ALTER DATABASE Stock SET MULTI_USER1：重新建立一个，一样的数据库，路径名称，文件都一样哈！

1 首先确认已经备份了mdf和ldf文件。

2 在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。

3 用原有的mdf和ldf文件覆盖新建数据库对应的mdf和ldf文件。

4 重新启动SQL Server服务，这是应该会看到这个数据库处于置疑（Suspect）状态。（人品好的话，这个时候数据库就已经恢复正常了，上次xrf的数据库就是这样被我恢复的。人品不好的话，下面的步骤也不行，我有一次就是找了一个北京做数据恢复的公司才恢复完毕。）

5 在SQL查询分析器中执行以下命令，以允许更新系统表：use mastergosp_configure ‘allow updates’,1

reconfigure with overridego

6 将这个数据库置为紧急模式：

update sysdatabases set status = 32768 where name = 'db_name'go

7 使用DBCC CHECKDB命令检查数据库中的错误：

DBCC CHECKDB(‘db_name’)GO

8 如果DBCC CHECKDB命令失败，请转至第10步，否则先将数据库置为单用户模式，再尝试对其进行修复：

sp_dboption 'db_name',’single user’,’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_resetstatus 'db_name'

清除数据库的单用户模式状态：sp_dboption 'db_name',’single user’,’false’

重新启动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_LogLDF'）

6 重新将该数据库置为单用户模式。

1 首先确认已经备份了mdf和ldf文件。

2 在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。

3 用原有的mdf和ldf文件覆盖新建数据库对应的mdf和ldf文件。

4 重新启动SQL Server服务，这是应该会看到这个数据库处于置疑（Suspect）状态。（人品好的话，这个时候数据库就已经恢复正常了，上次xrf的数据库就是这样被我恢复的。人品不好的话，下面的步骤也不行，我有一次就是找了一个北京做数据恢复的公司才恢复完毕。）

5 在SQL查询分析器中执行以下命令，以允许更新系统表：use mastergosp_configure ‘allow updates’,1

reconfigure with overridego

6 将这个数据库置为紧急模式：

update sysdatabases set status = 32768 where name = 'db_name'go

7 使用DBCC CHECKDB命令检查数据库中的错误：

DBCC CHECKDB(‘db_name’)GO

8 如果DBCC CHECKDB命令失败，请转至第10步，否则先将数据库置为单用户模式，再尝试对其进行修复：

sp_dboption 'db_name',’single user’,’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_resetstatus 'db_name'

清除数据库的单用户模式状态：sp_dboption 'db_name',’single user’,’false’

重新启动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_LogLDF'）

6 重新将该数据库置为单用户模式。

如果是单用户模式，要清楚这个表中的数据。如果还是不行就新建一个数据库，将现有的数据导到新库里。

也可能是因为当前数据库正处在

EMERGENCY

（紧急状态）下，

可以使用

alter

database

数据库名

set

online

来恢复成在线状态。

恢复数据库的方法：

1

update sysdatabases set status =0 where name = 'fdshop'

，go

把状态重置为0，重启库。

2

修复的话，先将将数据库置为单用户模式，sp_dboption 'fdshop','single user','true'，如果报错，可能有用户正在使用库，在进程管理里面杀掉，用户进程，重新执行，直到成功。

3

尝试对其进行不丢失数据的修复：DBCC CHECKDB('fdshop',REPAIR_REBUILD)。

尝试对其进行可能丢失数据的修复DBCCCHECKDB('fdshop',REPAIR_ALLOW_DATA_LOSS)

。

4

将数据库置为多用户模式：sp_dboption 'fdshop','single user','false'

，如果用户库无法启动，则打开sql server分析查询器，执行以下命令。

怎么办呢别着急 下面我们举例说明恢复办法

A 我们使用默认方式建立一个供恢复使用的数据库(如test) 可以在SQL Server Enterprise Manager里面建立

B 停掉数据库服务器

C 将刚才生成的数据库的日志文件test_log ldf删除 用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data mdf

D 启动数据库服务器 此时会看到数据库test的状态为 置疑 这时候不能对此数据库进行任何 *** 作

E 设置数据库允许直接

*** 作系统表 此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器 按右键 选择 属性 在 服务器设置 页面中将 允许对系统目录直接修改 一项选中 也可以使用如下语句来实现

以下是引用片段 use master go sp_configure  allow updates go reconfigure with override go

F 设置test为紧急修复模式

update sysdatabases set status= where dbid=DB_ID( test )

此时可以在SQL Server Enterprise Manager里面看到该数据库处于 只读\置疑\脱机\紧急模式 可以看到数据库里面的表 但是仅仅有系统表

G 下面执行真正的恢复 *** 作 重建数据库日志文件

dbcc rebuild_log( test C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log ldf )

执行过程中 如果遇到下列提示信息

服务器: 消息 级别 状态 行

未能排它地锁定数据库以执行该 *** 作

DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系

说明您的其他程序正在使用该数据库 如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表 那么退出SQL Server Enterprise Manager就可以了

正确执行完成的提示应该类似于

警告: 数据库 test 的日志已重建 已失去事务的一致性 应运行 DBCC CHECKDB 以验证物理一致性 将必须重置数据库选项 并且可能需要删除多余的日志文件

DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为 只供DBO使用 此时可以访问数据库里面的用户表了

H 验证数据库一致性(可省略)

dbcc checkdb( test )

一般执行结果如下

CHECKDB 发现了 个分配错误和 个一致性错误(在数据库 test 中)

DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系

I 设置数据库为正常状态

sp_dboption test dbo use only false

如果没有出错 那么恭喜 现在就可以正常的使用恢复后的数据库啦

J 最后一步 我们要将步骤E中设置的 允许对系统目录直接修改 一项恢复 因为平时直接 *** 作系统表是一件比较危险的事情 当然 我们可以在SQL Server Enterprise Manager里面恢复 也可以使用如下语句完成

以下是引用片段 sp_configure  allow updates go reconfigure with override go

lishixinzhi/Article/program/SQL/201311/16354

以上就是关于如何修复sql数据库数据不一致全部的内容，包括:如何修复sql数据库数据不一致、SQL2000数据库的系统表出错，怎么修复syscolumns和sysobjects、SQL SERVER中一张表损坏了，没有备份文件，如何将这张表修复一下呢在线等待等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！