sql server数据库置疑_数据库置疑什么原因

一、数据库置疑产生的原因

1、SQL Server所在分区空间是否足够，数据库文件大小是否达到最大文件限制，FAT32事务格式只支持4G以内的文件？

2、数据库文件损坏或被非正常删除时会出现这种情况；

3、病毒防火墙的扫面也可能会引起数据库置疑；

4、当SQL

Server启动时，将会尝试获得对数据库文件的排他访问权，如果此时该文件被其他程序占用，或者遗失，数据库将会被标记为置疑；

5、电脑非法关机也可能会造成数据库置疑；

6、电脑磁盘有坏道可能会造成数据库置疑。

二、数据库置疑的预防

1、数据库文件存放的磁盘或磁带，空间是否够大，经常检查盘符的空间；

2、数据库文件存放的磁盘格式设置为NTFS格式；

3、进行病毒清除时，尽量将SQL Server服务停掉，再进行杀毒操作，不过一般不会影响数据库；

4、尽量减少非正常关机；

5、建议购买后备电源；

6、实施软件之后一定要做好自动备份处理。

7、建议每隔一定时间进行一次数据库全备份。

三、数据库置疑测试环境搭建

1、分离数据库，备份数据库数据文件和日志文件

在SQL

Server2000企业管理器下，选中数据库mytest库，右键菜单中—所有任务—分离数据库，对mytest数据库实现分离操作。然后在C:\Program

Files\Microsoft SQL

Server\MSSQL\Data目录下将mytest_Data.MDF和mytest_Log.LDF两个文件做备份处理；如果mytest_Log.LDF已损坏，则只备份mytest_Data.MDF处理。

2、新建同名数据库

在企业管理器中创建同名数据库mytest，数据库数据文件名和日志文件名需和原库一致。

3、停止SQL Server服务

4、替换数据文件

只将备份的mytest_Data.MDF替换掉刚创建的mytest数据库的mytest_Data.MDF文件

5、启动SQL

Server服务，此时由于mytest_Log.LDF日志文件出现问题，导致mytest数据库处于置疑状态，在置疑状态下，无法对数据库做任何操作，如下图所示：

四、数据库置疑恢复

4.1、只备份了数据文件，无日志文件的情况

1、设置数据库允许直接操作系统表。

此操作可以在企业管理器(SQL Server Enterprise

Manager)里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以在查询分析器中使用如下语句来实现：

use master

go

sp_configure ‘allow updates’,1

go

reconfigure with override

go

2、设置mytest数据库为紧急修复模式

在查询分析器中使用如下语句：

— -32768：将模式改为只读/脱机/紧急模式

update sysdatabases set status=-32768 where

dbid=DB_ID(‘mytest’)

此时刷新数据库，可以在企业管理器(SQL Server Enterprise

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

3、重建数据库日志文件

下面执行真正的恢复操作，在查询分析器中用dbcc

rebuild_log命令来重建数据库日志文件(重建路径根据你实际的数据库路径来)

dbcc rebuild_log(‘mytest’,’C:\Program

Files\Microsoft SQL Server\MSSQL\Data\mytest_Log.LDF’)

执行过程中，如出现如下错误：

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

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

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

原因：说明其他程序正在使用该数据库，如果之前在第3步中使用企业管理器打开了mytest库的系统表，那么退出企业管理器就可以了。

该命令正常执行的结果提示如下：

警告: 数据库 ‘mytest’ 的日志已重建。已失去事务的一致性。应运行 DBCC

CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

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

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

4、验证数据库一致性(数据库较大时，会耗费一定的时间)

在查询分析器中执行如下命令：

dbcc checkdb(‘mytest’)

一般执行结果：

‘sysobjects’ 的 DBCC 结果。

对象 ‘sysobjects’ 有 27 行，这些行位于 1 页中。

‘sysindexes’ 的 DBCC 结果。

对象 ‘sysindexes’ 有 41 行，这些行位于 2 页中。

‘syscolumns’ 的 DBCC 结果。

对象 ‘syscolumns’ 有 271 行，这些行位于 6 页中。

‘systypes’ 的 DBCC 结果。

对象 ‘systypes’ 有 26 行，这些行位于 1 页中。

‘syscomments’ 的 DBCC 结果。

对象 ‘syscomments’ 有 95 行，这些行位于 7 页中。

…

CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 ‘mytest’ 中)。

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

5、设置数据库为正常状态

在查询分析器中执行：

sp_dboption ‘mytest’,’dbo use

only’,’false’

如果提示命令已成功完成，且没有报错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

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

use master

go

sp_configure ‘allow updates’,0

reconfigure with override

go

执行结果一般如下：

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

已将配置选项 ‘allow updates’ 从 1 改为 0。请运行 RECONFIGURE 语句以安装。

4.2、备份了数据文件，日志文件的情况

1、设置数据库允许直接操作系统表。

此操作可以在企业管理器(SQL Server Enterprise

Manager)里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以在查询分析器中使用如下语句来实现：

use master

go

sp_configure ‘allow updates’,1

go

reconfigure with override

go

运行结果：

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

已将配置选项 ‘allow updates’ 从 0 改为 1。请运行 RECONFIGURE 语句以安装。

2、设置mytest数据库为紧急模式

在查询分析器中使用如下语句：

— 32768：将模式改为置疑\紧急模式

update sysdatabases set status=32768 where

dbid=DB_ID(‘mytest’)

此时刷新数据库，可以在企业管理器(SQL Server Enterprise

Manager)里面看到该数据库处于“置疑\紧急模式”，但是什么都看不到。

3、设置数据库为单用户模式

下面执行真正的恢复操作，使用如下命令设置数据库为单用户模式。

sp_dboption ‘mytest’,’single

user’,true

此时，打开企业管理器，会看到该数据库的状态由“置疑\紧急模式”变为“紧急模式”，仍然看不到任何表之类的文件。

4、验证数据库一致性(数据库较大时，会耗费一定的时间)

在查询分析器中执行如下命令：

dbcc checkdb(‘mytest’)

一般执行结果：

‘sysobjects’ 的 DBCC 结果。

对象 ‘sysobjects’ 有 27 行，这些行位于 1 页中。

‘sysindexes’ 的 DBCC 结果。

对象 ‘sysindexes’ 有 41 行，这些行位于 2 页中。

‘syscolumns’ 的 DBCC 结果。

对象 ‘syscolumns’ 有 271 行，这些行位于 6 页中。

‘systypes’ 的 DBCC 结果。

对象 ‘systypes’ 有 26 行，这些行位于 1 页中。

‘syscomments’ 的 DBCC 结果。

对象 ‘syscomments’ 有 95 行，这些行位于 7 页中。

…

CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 ‘mytest’ 中)。

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

5、修改mytest数据库状态

update sysdatabases set status=28 where

name=’mytest’

此时，刷新下数据库，可以看到mytest数据的状态也恢复正常，且能看到相关数据文件了，

status参数说明：

1 = autoclose；使用 sp_dboption 设置。

4 = select into/bulkcopy；使用 sp_dboption 设置。

8 = trunc. log on chkpt；使用 sp_dboption 设置。–//设完检查点后即清除日志

16 = torn page detection，使用 sp_dboption 设置。–//残缺页检测

32 = loading。

64 = pre recovery。

128 = recovering。

256 = not recovered。

512 = offline；使用sp_dboption 设置。

1024 = read only；使用 sp_dboption 设置。

2048 = dbo use only；使用

sp_dboption 设置。

4096 = single user；使用 sp_dboption 设置。–//单用户

32768 = emergency mode。–//紧急恢复模式

4194304 = autoshrink。

1073741824 = cleanly shutdown。

注意：这里的status=28(28=16+8+4)三种模式的组合。

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

use master

go

sp_configure ‘allow updates’,0

reconfigure with override

go

执行结果一般如下：

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

已将配置选项 ‘allow updates’ 从 1 改为 0。请运行 RECONFIGURE 语句以安装。

7、修改mytest数据库为多用户模式

sp_dboption ‘mytest’,’single

user’,false

根据以上操作步骤执行相关操作后，如果不出什么意外，你的数据就成功恢复了。