sql server数据库置疑_数据库置疑什么原因
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
根据以上操作步骤执行相关操作后，如果不出什么意外，你的数据就成功恢复了。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/171216.html原文链接：https://javaforall.cn