数据库置疑(SQL数据库置疑怎么办？)
数据库置疑了怎么处理？
磁盘应该有问题。恢复的可能性很小。解决方法如下：3360 1。首先，备份数据库，即复制数据目录中的两个文件，前提是MSSQL SERVER停止运行。如果在复制过程中提示I/O错误，则磁盘有问题。这是无法挽回的。如果可能的话，使用SQL的附加数据库函数来添加这两个文件。一切
SQL数据库置疑怎么办？
你好，是这样的：
1.首先确认一下。mdf和。ldf文件已备份。
2.在SQL Server中创建一个同名的新数据库，然后停止SQL Server服务。
3.覆盖。mdf和。ldf文件对应的新数据库与原。mdf和。ldf文件。
4.重新启动SQL Server服务。您应该看到该数据库处于可疑状态。
5.在SQL查询分析器中执行以下命令，以允许更新系统表：使用mastergosp_configure
sql 2000数据库置疑的解决方法？
备份数据文件，然后如下处理3360。
1.用相同的名字创建一个新的数据库(数据文件应该和原来的一致)
2.再次停止sql server(注意不要分离数据库)
3.用原始数据库的数据文件覆盖新数据库。
4.再次重新启动sql server
5.这时候你打开企业管理器，就会有疑惑。不管怎样，执行下面的语句(注意修改数据库名)。
6.完成后，您通常可以访问数据库中的数据。这个时候，数据库本身通常会出现问题。解决方案是使用
创建新数据库并导入数据的数据库脚本。
使用母版
去
SP_CONFIGURE #039;允许更新#039;1用覆盖重新配置
去
更新sysdatabases set status=32768，其中name=#039;有问题的数据库名#039;
去
Sp_dboption #039;有问题的数据库名称#039;#039;单用户#039;#039; true #039;
去
Dbccheckdb(“有问题的数据库名称”)
去
更新数据库设置状态=28，其中名称=#039;有问题的数据库名称#039;
去
sp_configure #039;允许更新#039;0使用替代重新配置
去
Sp_dboption #039;有问题的数据库名称#039;#039;单用户#039;#039; false #039;
假设数据库是TEST:
遵循这些步骤。
A.将数据库设置为允许直接操作系统表。对于此操作，您可以在SQL Server企业管理器中选择数据库服务器，右键单击并选择“属性”，然后在“服务器设置”页面中选择“允许直接修改系统目录”。也可以使用下面的语句来实现。
使用母版
去
sp_configure #039;允许更新#039;1
去
用覆盖重新配置
去
B.将测试设置为紧急修复模式
更新sysdatabases set status=-32768，其中dbid=DB_ID(#039;test #039;)
此时，您可以看到数据库在SQL Server企业管理器中处于“只读 怀疑 脱机 紧急模式”。您可以看到数据库中的表，但只能看到系统表。
C.接下来，执行真正的恢复操作并重建数据库日志文件。
dbcc rebuild_log(#039;test #039;#039; c : Program Files Microsoft SQL Server MSSQL Data
est_log.ldf #039;)
在执行过程中，如果您遇到以下提示信息：
服务器：消息5030，级别16，状态1，第1行
无法以独占方式锁定数据库来执行此操作。
DBCC的死刑执行完毕。如果DBCC输出错误消息，请联系您的系统管理员。
说明您的其他程序正在使用该数据库。如果您刚刚在步骤F中使用SQL Server企业管理器打开了测试库的系统表，您可以直接退出SQL Server企业管理器。
正确执行完成的提示应该类似于：
警告：数据库“test”的日志已经重建。事务一致性已经丢失。运行DBCC CHECKDB以验证物理一致性。必须重置数据库选项，并且可能需要删除冗余的日志文件。
DBCC的死刑执行完毕。如果DBCC输出错误消息，请联系您的系统管理员。
此时，当您在SQL Server企业管理器中打开它时，您将看到该数据库的状态为“仅限DBO”。此时，您可以访问数据库中的用户表。
D.验证数据库一致性(可以省略)
dbcc checkdb(“测试”)
总体实施结果如下：
CHECKDB在数据库“test”中发现0个分配错误和0个一致性错误。
DBCC的死刑执行完毕。如果DBCC输出错误消息，请联系您的系统管理员。
E.将数据库设置为正常状态。
sp_dboption #039;test #039;#039;仅使用dbo #039;#039; false #039;
如果没有错误，恭喜你，现在你可以正常使用恢复的数据库了。
F.最后，我们将恢复步骤e中设置的“允许直接修改系统目录”这一项，因为平时直接操作系统表是很危险的。当然，我们可以在SQL Server企业管理器中恢复它，也可以使用下面的语句。
sp_configure #039;允许更新#039;0
去
用覆盖重新配置
去
上面的语句操作步骤有问题：
应该是这样的：
A.我们使用默认方法构建一个数据库(如test)进行恢复。您可以在SQL Server企业管理器中创建它。
B.停止数据库服务器。
C.删除刚刚生成的数据库的日志文件test_log.ldf，用要恢复的数据库mdf文件覆盖数据库数据文件test_即可。
D.启动数据库服务器。此时，您将看到数据库测试的状态为“怀疑”。此时您无法对此数据库进行任何操作。
E.将数据库设置为允许直接操作系统表。对于此操作，您可以在SQL Server企业管理器中选择数据库服务器，右键单击并选择“属性”，然后在“服务器设置”页面中选择“允许直接修改系统目录”。也可以使用下面的语句来实现。
使用母版
去
sp_configure #039;允许更新#039;1
去
用覆盖重新配置
去
F.将测试设置为紧急修复模式
更新sysdatabases set status=-32768，其中dbid=DB_ID(#039;test #039;)
此时，您可以看到数据库在SQL Server企业管理器中处于“只读 怀疑 脱机 紧急模式”。您可以看到数据库中的表，但只能看到系统表。
G.接下来，执行真正的恢复操作并重建数据库日志文件。
dbcc rebuild_log(#039;test #039;#039; c : Program Files Microsoft SQL Server MSSQL Data
est_log.ldf #039;)
在执行过程中，如果您遇到以下提示信息：
服务器：消息5030，级别16，状态1，第1行
无法以独占方式锁定数据库来执行此操作。
DBCC的死刑执行完毕。如果DBCC输出错误消息，请联系您的系统管理员。
说明您的其他程序正在使用该数据库。如果您刚刚在步骤F中使用SQL Server企业管理器打开了测试库的系统表，您可以直接退出SQL Server企业管理器。
正确执行完成的提示应该类似于：
警告：数据库“test”的日志已经重建。事务一致性已经丢失。运行DBCC CHECKDB以验证物理一致性。必须重置数据库选项，并且可能需要删除冗余的日志文件。
DBCC的死刑执行完毕。如果DBCC输出错误消息，请联系您的系统管理员。
此时，当您在SQL Server企业管理器中打开它时，您将看到该数据库的状态为“仅限DBO”。此时，您可以访问数据库中的用户表。
H.验证数据库一致性(可以省略)
dbcc checkdb(“测试”)
总体实施结果如下：
CHECKDB在数据库“test”中发现0个分配错误和0个一致性错误。
DBCC的死刑执行完毕。如果DBCC输出错误消息，请联系您的系统管理员。
I .将数据库设置为正常状态。
sp_dboption #039;test #039;#039;仅使用dbo #039;#039; false #039;
如果没有错误，恭喜你，现在你可以正常使用恢复的数据库了。
J.最后，我们将恢复步骤e中设置的“允许直接修改系统目录”这一项，因为平时直接操作系统表是很危险的。当然，我们可以在SQL Server企业管理器中恢复它，也可以使用下面的语句。
sp_configure #039;允许更新#039;0
去
用覆盖重新配置
去
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
