SQLSERVER2000数据库频繁被置疑，高手解决下

1、在SQL查询分析器中执行以下语句：（注以下所用的dbname为数据库名称，请客户手工改为自己的数据库名）

use dbname

dbcc checkdb

2、查看查询结果，有很多红色字体显示，最后结果有这样的提示：

CHECKDB 发现了x个分配错误和 x 个一致性错误（在数据库 'dbname' 中）。

一般情况下，引起分配错误的原因是磁盘损坏或突然停电；一致性错误可能是数据库中的表或索引坏，一般都可修复。

3、查看红色字体，并把有错误的数据库表名记录下来，或把索引损坏的表名记录下来。

4、把数据库设置为单用户模式，直接在查询分析器中执行以下语句即可：

EXEC sp_dboption 'dbname', 'single user', 'TRUE'

5、进入查询分析器执行如下语句：

use kmjxcv3

dbcc checkdb（’dbname’，repair_allow_data_loss）-------修复数据库

dbcc checkdb ('dbname',REPAIR_REBUILD)----------------修复数据库索引

6、再执行：dbcc checkdb，检测数据库，出现结果为：

CHECKDB 发现了0个分配错误和 0个一致性错误（在数据库 'dbname' 中）。

数据库已经修复完毕。

7、取消单用户模式，即直接在查询分析器中执行以下语句即可：

EXEC sp_dboption 'dbname', 'single user','FALSE'

现在可以正常使用了！

假定数据库名为AA

1将AA_logldf文件备份到其它目录下；

2将源目录下的AA_logldf文件改名为smlog_log_bakldf；

3在查询分析器中执行以下语句修改数据库的状态：

use Master

go

update sysdatabases set status=32768 where name='AA' --修改状态

go

shutdown with nowait --停止数据库服务器

go

4退出SQL并在命令行模式中执行以下代码：

sqlservr -c -T3608 -T4022 --安全模式启动SQL SERVER

5在查询分析器中执行以下语句来查看刚刚修改过状态的数据库状态：

select Name,Status from sysdatabases where Name='AA'

6在查询分析器中执行以下代码重建日志文件：

dbcc traceon(3604) --跟踪

dbcc rebuild_log('AA','AA') --文件名要有全路径和扩展名

本步骤如果成功，继续执行下一步的 *** 作，如果报错，也可以不管它继续下一步，也可以将 *** 作之前建立的同名空数据库日志文件COPY过来就行。

7在查询分析器中执行以下代码将数据库置回正常状态：

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

8重新启动数据库后执行以下语句检查数据库：

DBCC CHECKDB --如果执行完有错误用以下910两步语句修复

9要修复数据库必需将数据库改为单用户模式：

Exec sp_dboption '数据库名称','single user','true'

10执行以下语句修复数据库：

DBCC CHECKDB('AA',REPAIR_ALLOW_DATA_LOSS)

11将数据库改为多用户模式：

Exec sp_dboption 'AA','single user','false'

12重新启动电脑，成功！

sql2000数据库经常置疑，并且按照网上所说的只能暂时解决问题！在不重装软件和系统的情况下可不可以一次性解决这个问题？估计是我不小心硬关机造成的！请各位能提个有效的建议，尽量详细和易懂！！！

一般在

安装目录\MSSQL\Data下

出现这种情况是你把mdf弄丢了

没有其他备份数据就没了

不过你可以下载个

硬盘数据恢复

先看看能不能把mdf

文件恢复

过来，不能就没戏了

可以修复，从故障解析，数据库损坏分为

逻辑层

损坏和

物理层

损坏。

1，逻辑损坏是指，文件本身完整，系统表在

逻辑结构

上混乱造成的错误。

2，物理损坏是指，文件由于不完整，导致置疑等故障

数据库损坏，由断电，非法关机，系统重启，文件被误删除，误GHOST自己恢复出来的文件附加失败，阵列崩溃等原因造成的。

逻辑层修复方法，网上有很多DBCC修复命令，可以区尝试下、

物理层还是找专业人员吧！

备份数据文件,然后按下面的步骤处理:

1新建一个同名的数据库(数据文件与原来的要一致)

2再停掉sql server(注意不要分离数据库)

3用原数据库的数据文件覆盖掉这个新建的数据库

4再重启sql server

5此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)

6完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用

数据库的脚本创建一个新的数据库,并将数据导进去就行了

USE MASTER

GO

SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE

GO

UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'

Go

sp_dboption '置疑的数据库名', 'single user', 'true'

Go

DBCC CHECKDB('置疑的数据库名')

Go

update sysdatabases set status =28 where name='置疑的数据库名'

Go

sp_configure 'allow updates', 0 reconfigure with override

Go

sp_dboption '置疑的数据库名', 'single user', 'false

假设数据库为TEST：

按以下步骤执行

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

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

B．设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

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

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

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf')

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

服务器: 消息 5030，级别 16，状态 1，行 1

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

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

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

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

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

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

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

D．验证数据库一致性（可省略）

dbcc checkdb('test')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。

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

E．设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

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

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

sp_configure 'allow updates',0

go

reconfigure with override

go

上面的语句 *** 作步骤有点问题：

应该如下：

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

B．停掉数据库服务器。

C．将刚才生成的数据库的日志文件test_logldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_datamdf。

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

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

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

F．设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

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

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

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf')

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

服务器: 消息 5030，级别 16，状态 1，行 1

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

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 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。

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

I．设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

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

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

sp_configure 'allow updates',0

go

reconfigure with override

go

请输入你的答案 数据库926错误解决方案在做任何 *** 作前首先备份数据库的数据文件和日志文件！以及最新的备份文件！第一种解决方法：先删除报错数据库，再新建一同名数据库，然后暂停Service manager（及sql server 服务） ，删除库文件和日志文件再启动Service manager ，使用单数据文件恢复数据库命令恢复数据库。例：打开sql server/tools/sql server query analyzer 执行下面 *** 作 EXEC sp_attach_single_file_db @dbname = 'pubs', @physname = 'c:\mssql7\data\pubsmdf' 说明：‘pubs’为要恢复的数据库名称，‘c:\mssql7\data\pubsmdf’为要恢复的数据库的库文件的具体路径和文件名称。再重新启动一下service manager ，看能否正常打开处理后的数据库；如果不可以再使用第二种方案。第二种解决方法：打开sql server/tools/sql server query analyzer 执行下面 *** 作 USE MASTER GO sp_configure 'allow update',1 RECONFIGURE WITH OVERRIDE GO UPDATE sysdatabases set status = 32768 WHERE name = 'db_pos363' GO sp_configure 'allow update',0 RECONFIGURE WITH OVERRIDE GO 说明：'db_pos363'是要修复的数据库名称。执行完毕再重启一下Service manager打开数据库看是否处于紧急状态！再从另一装有sql 2000的机器上连接报错的数据库，然后再在sql 2000的机器上新建一数据库，再使用sql 2000自带的数据库导入导出功能（在新建的数据库上单击右键/所有任务/数据导入、数据导出）从报错数据库导入数据到新建的数据库中！在导入选项中注意以下几项： 1， 导入方式选择分‘从源数据库复制表和视图’以及‘从sql server数据库间复制对象和数据’。当选择从源数据库复制表和视图时一定要选择全部表！ 2， 当选择‘从sql server数据库间复制对象和数据’时，在‘导入导出向导’对话框中去除‘使用默认选项’的选中标志；再在打开‘选项’对话框，去除以下三项的选中标志。A,复制数据用户和数据库角色；B，复制sql server 登陆；C，复制对象及权限。 3， 在使用‘从sql server数据库间复制对象和数据’时，有时会出现单张表导入失败，这时有时会在导入结束时提示那几张表导入失败有时不提示，如果提示，就再使用‘从源数据库复制表和视图’并选中导入失败的表重新导入一遍；如果不提示就只能在一张张表打开查看了，发现空表后再使用‘从源数据库复制表和视图’导入需要导入的表！导入成功后再删除sql server 70机器上处于紧急状态的数据库，再新建一个同名数据库，建好后再使用sql 2000的数据库导出功能导出到此数据库中，在导出过程中同样要注意导入时的注意事项！

以上就是关于SQLSERVER2000数据库频繁被置疑，高手解决下全部的内容，包括:SQLSERVER2000数据库频繁被置疑，高手解决下、SQl数据库被置疑！！！高手请进！！、sql2000数据库经常置疑怎么处理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！