[SQL]数据库置疑的故事

发表于:2007-07-02来源:作者:点击数: 标签:
The information in this article applies to: - Microsoft SQL Server 7.0,2000 [SQL]数据库置疑的 故事 Revision History: 对本文档所有修改都应按修改时间顺序记录在此。 Version Date Creator Description 1.0.0.1 2004-2-19 郑昀 草稿 Implementation S

The information in this article applies to:

- Microsoft SQL Server 7.0,2000

 

[SQL]数据库置疑的

故事
Revision History:
对本文档所有修改都应按修改时间顺序记录在此。

 

Version

Date

Creator

Description

1.0.0.1

2004-2-19

郑昀

草稿

 

 

 

 
Implementation Scope:
本文面向的读者是Microsoft SQL Server维护人员。

继续阅读之前,我们假设您熟悉以下知识

n        Microsoft SQL Server

 
1.以前的文章
从前写过一篇

数据库日志文件丢失时的恢复步骤    zhengyun_ustc(原作)

(http://www.csdn.net/develop/read_article.asp?id=17604),描述我误删除了数据库的事务日志文件(.ldf)之后,如何经过各种尝试恢复数据库的。

 

但是不少网友在处理“数据库置疑”的实践过程中,又产生了许多新的疑问。

我还是总结一下出现的几种情况,以供参考。

 
2.Zach的灵验脚本
Zach说他每次遇到这种数据库置疑情况,就运行下面这个脚本,屡试不爽:

======================================================

--before running any script, run the following to set the

master database to allow updates

USE master

GO

sp_configure @#allow updates@#, 1

GO

RECONFIGURE WITH OVERRIDE

GO

 

--Run the following script

UPDATE master..sysdatabases SET status = status ^ 256

WHERE name = @#Database_Name@#

 

--Run the following script

exec SP_resetstatus Database_Name

 

--stop and start the MSDTC at this stage

 

--After the procedure is created, immediately disable

updates to the system tables:

exec sp_configure @#allow updates@#, 0

GO

RECONFIGURE WITH OVERRIDE

GO

=====================================

 

从上面可以看出,处理置疑的基本步骤还是我那篇文章中说的(注意我使用的字体颜色):

执行 sp_configure 以允许对系统表进行更新,然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置;

数据库重置紧急模式;

执行sp_resetstatus关闭数据库的置疑标志,但是原封不动地保持数据库的其它选项(只有系统管理员才能执行)。执行该过程后,立即重启 SQL Server服务;

执行 sp_configure 以禁止对系统表进行更新,然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置。

    

 

status ^ 256的意思就是:


Constant

Value

Description

SQLDMODBStat_Suspect

256

Database integrity is suspect for the referenced database.


 

 

不同的是,有时候丢失了数据库日志文件,额外需要以下步骤:

Ø         把应用数据库设置为Single User模式;

Ø         做DBCC CHECKDB;

才可以。

 

但是几位网友的实践结果就是这个DBCC CHECKDB执行失败。一位网友yang说:“但是 DBCC CHECKDB就是执行不了,总是说“该数据库处于回避恢复模式”。我已经试了很多次了,就是改变不了这个状态。”

还有一位Rui执行DBCC CHECKDB时报错:“Server: Msg 943, Level 14, State 1, Line 1 Database @#his_yb@# cannot be opened because its version (539) is later than the current server version (515).”

 

对于Yang,可能他没有一步一步做,。我的切身体会是,把应用数据库设置为Single User模式后就可以做DBCC CHECKDB。之后呢,也许SQL Server重启后自动检查数据库是否正常。但是数据应该是可以读出来的,至少可以被DTS Wizard读出来的。这时候的数据库还存在问题,比如我的组件使用数据库时,报告说:“发生错误:-2147467259,未能在数据库 @#XXX@# 中运行 BEGIN TRANSACTION,因为该数据库处于回避恢复模式。”

 

对于Rui,他碰到的那个错误

Server: Msg 943, Level 14, State 1, Line 2
Database @#XXXX@# cannot be opened because its version (536) is later than
the current server version (515).

这表明Rui正试图:

从一个SQL Server 2000(version 539,536之类的)的数据库备份恢复到一个SQL Server 7.0中

或者

把一个SQL Server 2000(version 539,536之类的)的数据库attach到一个SQL Server 7.0中,

这是不允许的。如果你必须使用这个SQL Server 2000的数据备份,那么请您首先把这个备份倒入SQL Server 2000,最后用DTS把数据库从SQL Server 2000上transfer到SQL Server 7.0上。

 

关于数据库置疑和日志文件丢失损坏,我们还会继续关注并作进一步报道。

 

Writen by zhengyun.NoJunk(at)tomosoft.dot.com
Disclaimers:
本文档所包含的信息代表了在发布之日,ZhengYun 对所讨论问题的当前看法,Zhengyun 不保证所给信息在发布之日以后的准确性。

本文档仅供参考。对本文档中的信息,Zhengyun 不做任何明示或默示的保证。

用户必须遵守所有适用的版权法。在不对版权法所规定的权利加以限制的情况下,如未得到 zhengyun和CSDN.Net明确的书面许可,不得出于任何目的、以任何形式或手段(电子的、机械的、影印、录制等等)复制、传播本文的任何部分,也不得将其存储或引入到检索系统中。

 

原文转自:http://www.ltesting.net