数据库置疑修复？数据库置疑是什么意思

大家好，今天小编来为大家解答数据库置疑修复这个问题，数据库置疑是什么意思很多人还不知道，现在让我们一起来看看吧！

sql2000数据库置疑怎么修复_sql2000数据库置疑恢复办法

sql2000数据库置疑可以通过新建库来修复。首先，假设原库名为DB，新建一个库名为DB1，并确保DB1与DB不在同一目录下。其次，需要停止SQL服务。接下来，将置疑的DB库重命名为DB1，覆盖原有的DB1。启动SQL服务后，尽管在企业管理器中DB1仍显示为置疑状态，暂时无需处理。然后执行一系列修复语句：USE MASTER，GOSP_CONFIGURE'ALLOW UPDATES',1，RECONFIGURE WITH OVERRIDE，UPDATE SYSDATABASES SET STATUS=32768 WHERE NAME='DB1'，Gosp_dboption'DB1','single user','true'，DBCC CHECKDB('DB1')，Goupdate sysdatabases set status=28 where name='DB1'，Gosp_configure'allow updates', 0 reconfigure with override，Gosp_dboption'DB1','single user','false'。经过上述步骤后，DB1库应该恢复正常。

然而，如果重启电脑后库仍然显示为置疑状态，需要采取更彻底的解决方案。此时，可以新建一个库，例如DB11，并将DB1库中的数据通过“导入导出工具”导出至新库中。通过这种方式，可以确保数据库数据的安全性和完整性。

在处理sql2000数据库置疑问题时，需要注意以下几个关键步骤，以确保数据的安全和恢复的顺利进行。首先，确保新数据库名称与原数据库名称不同，并且不在同一目录下。其次，停止SQL服务以避免在恢复过程中出现冲突。然后，通过重命名和覆盖原数据库来创建一个临时的修复点。最后，执行一系列修复语句，包括启用更新、更改数据库状态、执行数据库检查等。

此外，在数据恢复过程中，应定期备份数据库，以防止数据丢失。通过定期备份，即使在遇到数据库置疑或其他问题时，也可以快速恢复到之前的状态。对于sql2000数据库置疑的修复，定期备份是至关重要的。

对于sql2000数据库置疑的处理，除了上述方法外，还可以考虑使用专业的数据库恢复工具。这些工具通常具有更高的兼容性和更强大的修复能力，能够处理更复杂的问题。使用这些工具时，务必选择信誉良好的供应商，并确保遵循正确的操作步骤。

总之，对于sql2000数据库置疑的修复，需要遵循一系列具体步骤，并确保数据的安全性和完整性。通过定期备份、执行正确的修复操作和使用专业的恢复工具，可以最大限度地减少数据丢失的风险。

数据库出现置疑了怎么恢复

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

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_log.ldf')

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

服务器:消息 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_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。

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_log.ldf')

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

服务器:消息 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

数据库“置疑”该怎么处理

解决由于sql2000日志文件引起的“置疑”。

日志有错误--------重新附加提示日志有错误。

日志文件丢失-----丢失了.ldf文件，只有.mdf文件的数据库重建。

步骤：

一、备份“置疑”数据库的数据文件，因为日志文件.ldf出错，可以只备份.mdf文件。

二、打开企业管理器（SQL Server Enterprise Manager），删除“置疑”数据库，如果提示删除错误，可以重启数据库服务器，然后再试。

三、在企业管理器中，新建同名数据库（假如数据库为test），注意建立的数据库名称，还有数据文件名要保持和原数据库一致。

四、停止数据库服务器。

五、将刚才新建数据库生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库.mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。

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

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

use master

go

sp_configure'allow updates',1

go

reconfigure with override

go

八、设置test为紧急修复模式。

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

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

九、下面执行真正的恢复操作，用dbcc rebuild_log命令来重建数据库日志文件（重建路径根据你实际的数据库路径来）。

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

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

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

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

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

说明您的其他程序正在使用该数据库，如果刚才您在八步骤中使用企业管理器打开了test库的系统表，那么退出企业管理器就可以了。

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

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

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

此时打开在企业管理器里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

十、验证数据库一致性。（次步骤可省略）

dbcc checkdb('test')

一般执行结果如下：

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

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

十一、设置数据库为正常状态

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

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

十二、最后一步，我们要将步骤七中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在企业管理器里面恢复，也可以使用如下语句完成

sp_configure'allow updates',0

go

reconfigure with override

go

对于只有.mdf文件的sql2000数据库恢复，从第三步开始做就行了。

最好的方法为先分离然后附加看下

1．我们SQL SERVER企业管理器新建立一个供恢复使用的同名数据库(注意：要跟问题数据库同名，本例中为myDb)。

2．停掉数据库服务器。

3．将刚才生成的数据库的日志文件myDb_log.ldf删除（本例中的示列数据库名，实际使用您自己的数据库名称），用刚才备份的数据库mdf文件覆盖新生成的数据库数据文件myDb_data.mdf。

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

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

use master

go

sp_configure'allow updates',1

go

reconfigure with override

go F．设置myDb为紧急修复模式

在查询管理器里设置如下命令：

update sysdatabases set status=-32768 where dbid=DB_ID('stib')此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

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

dbcc rebuild_log('stib','E:\zz\stib_log.ldf')警告:数据库'myDb'的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

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

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

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

dbcc checkdb('stib')一般执行结果如下：

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

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

sp_dboption'stib','single user','true'--设置为单用户

dbcc checkdb('stib','REPAIR_ALLOW_DATA_LOSS')--这个语句可能执行几遍之后有效

sp_dboption'stib','single user','false'--取消单用户

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

sp_dboption'stib','dbo use only','false'

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

sp_configure'allow updates',0

go

reconfigure with override

go

到此数据库置疑问题解决。

数据库置疑修复的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于数据库置疑是什么意思、数据库置疑修复的信息别忘了在本站进行查找哦。