数据库置疑修复评析.docx

1、数据库置疑修复评析数据库置疑修复评析数据库置疑修复数据库置疑的解决方法: (1):如果是严重的置疑,就这样解决 停止SQL服务,备份你的置疑的数据库的数据文件(直接将MDF，LDF文件拷贝出去就可以). 然后启动SQL服务,再删除置疑的数据库 然后按下面的步骤处理: 1.新建一个同名的数据库 2.再停掉sql server(注意不要分离数据库) 3.用原数据库的数据文件覆盖掉这个新建的数据库 4.再重启sql server 5.此时打开企业管理器时会出现置疑，先不管，在SQL查询分析器中执行下面的语句(注意修改其中的数据库名) 6.完成后(刷新数据库)一般就可以访问数据库中的数据了,这时,数据

2、库本身一般还有问题,解决办法是,利用 数据库的脚本创建一个新的数据库,并将数据导进去就行了.USE MASTER GO SP_CONFIGURE ALLOW UPDATES,1 RECONFIGURE WITH OVERRIDEGO UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME=置疑的数据库名 Go sp_dboption 置疑的数据库名, single user, trueGo DBCC CHECKDB(置疑的数据库名) Go update sysdatabases set status =28 where name=置疑的数据库名 Go

3、sp_configure allow updates, 0 reconfigure with overrideGo sp_dboption 置疑的数据库名, single user, falseGo - (2) 重置置疑状态 如果 SQL Server 因为磁盘驱动器不再有可用空间，而不能完成数据库的恢复，那么 Microsoft? SQL Server? 2000 会返回错误 1105 并且将 sysdatabases 中的 status 列设为置疑。按下面的步骤解决这个问题: 执行 sp_resetstatus。 用 ALTER DATABASE 向数据库添加一个数据文件或日志文件。停止并

4、重新启动 SQL Server。 用新的数据文件或日志文件所提供的额外空间，SQL Server 应该能完成数据库的恢复。 释放磁盘空间并且重新运行恢复操作。 sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。 注意 只有在您的主要支持提供者指导下或有疑难解答建议的做法时，才可以使用 sp_resetstatus。否则，可能会损坏数据库。由于该过程修改了系统表，系统管理员必须在创建这个过程前，启用系统表更新。要启用更新，使用下面的过程: USE master GO sp_configure allow updates, 1 GO RECONFIGURE W

5、ITH OVERRIDE GO 过程创建后，立即禁用系统表更新: sp_configure allow updates, 0 GO RECONFIGURE WITH OVERRIDE GO 只有系统管理员才能执行 sp_resetstatus。执行该过程后，立即关闭 SQL Server。 语法为: sp_resetstatus database_name 下面的例子将关闭 PRODUCTION 数据库的置疑标志。 sp_resetstatus PRODUCTION 下面是结果集: Database PRODUCTION status reset! WARNING: You must rebo

6、ot SQL Server prior to accessing this database! sp_resetstatus 存储过程代码 下面是 sp_resetstatus 存储过程的代码: IF EXISTS ( SELECT * from sysobjects where name = sp_resetstatus ) DROP PROCEDURE sp_resetstatus GO CREATE PROC sp_resetstatus dbname varchar(30) ASDECLARE msg varchar(80) IF trancount 0 BEGIN PRINT Can

7、t run sp_resetstatus from within a transaction. RETURN (1) END IF suser_id() != 1 BEGIN SELECT msg = You must be the System Administrator (SA) SELECT msg = msg + to execute this procedure.RETURN (1) END IF (SELECT COUNT(*) FROM master.sysdatabases WHERE name = dbname) != 1 BEGIN SELECT msg = Databas

8、e + dbname + does not exist! PRINT msg RETURN (1) END IF (SELECT COUNT(*) FROM master.sysdatabases WHERE name = dbname AND status & 256 = 256) != 1BEGIN PRINT sp_resetstatus can only be run on suspect databases. RETURN (1) END BEGIN TRAN UPDATE master.sysdatabases SET status = status 256WHERE name =

9、 dbname IF error != 0 OR rowcount != 1 ROLLBACK TRAN ELSE BEGIN COMMIT TRAN SELECT msg = Database + dbname + status reset! PRINT msg PRINT PRINT WARNING: You must reboot SQL Server prior to PRINT accessing this database!PRINT END GO - (3) 在MS SQLSERVER中一直有这样的问题,SQLSERVER的状态置疑,我们先来分析一下SQLSERVER数据库置疑的

10、原因: 1.错误的删除日志; 2.硬件(HD)损坏,造成日志和数据文件写错误; 3.硬盘的空间不够,比如日志文件过大; 解决办法: 这是最简单的办法是有数据库的全备份,然后恢复即可.步骤: 1. 删除原始的数据库: USE MASTER GO DROP DATABASE DB_SUEPECT 2.建立同名的数据库: USE master GO CREATE DATABASE DB_SUSPECT ON ( NAME = DBNAME_DAT, FILENAME = C:, SIZE = 10, FILEGROWTH = 5 ) LOG ON ( NAME = DBNAME_LOG, FILEN

11、AME = g:, SIZE = 5MB, FILEGROWTH = 5MB ) GO 3.恢复数据库: RESTORE DATABASE DB_SUSPECT FROM DBNAME_BACKUP.DAT 4.数据库完整性检测: DBCC CHECKDB(DB_SUSPECT) 5.重新启动MSSQLSERVER服务. 如果没有全备份,那就要用一些特殊的方法: 1.设置数据库为紧急模式 Use Master GO sp_configure allow updates, 1 reconfigure with override GO UPDATE sysdatabases SET status

12、= 32768 where name = DB_SUSPECT GO 2.停掉SQL Server服务: NET STOP MSSQLSERVER 3.把原始数据库的数据文件DBNAME_DAT.MDF,DBNAME_LOG.LDF移走:4.启动SQL Server服务: NET START MSSQLSERVER 5.重新建立一个同名的数据库DB_SUSPECT; USE master GO CREATE DATABASE DB_SUSPECT ON ( NAME = DBNAME_DAT, FILENAME = C:, SIZE = 10, FILEGROWTH = 5 ) LOG ON

13、( NAME = DBNAME_LOG, FILENAME = g:, SIZE = 5MB, FILEGROWTH = 5MB ) GO 6.设置数据库运行在单用户的模式: USE MASTER GO ALTER DATABASE DB_SUSPECT SET SINGLE_USERGO 7.停掉SQL服务: NET STOP MSSQLSERVER 8.把原来的数据文件再覆盖回来: 9.启动SQL Server服务: NET START MSSQLSERVER 10.重新设置SQLSERVER的状态: USE MASTER GO EXEC sp_resetstatus DB_SUSPECT

14、 11.数据库完整性检测: DBCC CHECKDB(DB_SUSPECT) 12.恢复数据库为多用户模式: USE MASTER GO ALTER DATABASE DB_SUSPECT SET MULTI_USERGO 13.恢复SQLSERVER原始的配置: USE MATER GO UPDATE sysdatabases SET status = 4194320 where name = DB_SUSPECT GO 14.配置SQLSERVER不允许更新系统表: USE MASTER GO sp_configure allow updates, 0 reconfigure with o

15、verride GO 15.重新启动MSSQLSERVER服务: 最好重新启动操作系统 16.备份数据库: 可以通过SQLSERVER企业管理器或T-SQL.需要备份MASTER和DB_SUSPECT 对该贴的补充: 1.如果不需要恢复到指定的时间点,你可以将数据库的恢复模式配置为简单,这样 UPDATE,DELETE,SELECT就不会记录日志,日志就不会增加的很大:ALTER DATABASE DB_NAME SET RECOVERY SIMPLE 2.如果你的恢复模式是全部,你一定要配置日志字段收缩:sp_dboption databasename,trunc. log on chkpt

16、.,truesp_dboption databasename,autoshrink,true3.通过每日备份将日志收缩: BACKUP DATABASE DATABASE_NAME TO BACKUP_DEVICESBACKUP LOG DATABASE_NAME TO LOG_DEVICES OR BACKUP LOG DATABASE_NAME with truncate_only *检查日志的容量:DBCC SQLPERF (LOGSPACE) 这时日志并没有收缩!4.每天在备份数据库完成之后,重新启动MS SQLSERVER SERVICE.USE DATABASE_NAME go D

17、BCC SHRINKFILE(2,truncateonly) *检查日志的容量:DBCC SQLPERF (LOGSPACE) 这时日志已经收缩!5.手动快速收缩日志: / *run below script,you will shrink you database log files immediately, in my experience,you need to run the script for 3 or 4 minutes before stopping it manually */ use databasename dbcc shrinkfile(2,notruncate) db

18、cc shrinkfile(2,truncateonly) create table t1(char1 char(4000) go declare i int select i=0 while(1=1) begin while(i100) begin INSERT INTO T1 VALUES (A) SELECT I=I+1 END TRUNCATE table T1 BACKUP LOG youdatabasename with truncate_onlyend go - (4) 任何数据库系统都无法避免崩溃的状况，即使你使用了Clustered，双机热备仍然无法完全根除系统中的单点故障，

19、何况对于大部分用户来说，无法承受这样昂贵的硬件投资。所以，在系统崩溃的时候，如何恢复原有的宝贵数据就成为一个极其重要的问题了。在恢复的时候，最理想的情况就是你的数据文件和日志文件都完好无损了，这样只需要sp_attach_db，把数据文件附加到新的数据库上即可，或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行，不过一般不推荐这样的做法，sp_attach_db比较好，虽然麻烦许多。 但是呢，一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏页等写入磁盘的，这样的情况sp_attach_db就会失败。那么，寄期望于DBA制定了一个良好的灾难恢复计划吧。按照

20、你的恢复计划，还原最新的完全备份，增量备份或者事务日志备份，然后如果你的活动事务日志还能读得出来的话，恭喜你你可以还原到崩溃前的状态。 一般的单位都是没有专职的DBA的，如果没有可用的备份，更可能是最近一次备份的时间过于久远而导致不可接受的数据损失，而且你的活动事务日志也处于不可用的状态，那就是最麻烦的情况了。不幸的很的是，一般数据库崩溃都是由于存储子系统引起的，而这样的情况是几乎不可能有可用的日志用于恢复的。 那么就只好试一下这些方案了。当然，是要求至少你的数据文件是存在的，要是数据文件、日志文件和备份都没有了的话，别找我，你可以到楼顶上去唱“神啊，救救我吧”。 首先，你可以试一下sp_at

21、tach_single_file_db，试着恢复一下你的数据文件，虽然能恢复的可能性不大，不过假如这个数据库刚好执行了一个checkpoint的话，还是有可能成功的。 如果你没有好到有摸彩票的手气，最重要的数据库没有像你期盼的那样attach上去，不要气馁，还是有别的方案的。 我们可以试着重新建立一个log，先把数据库设置为emergency mode，sysdatabases的status为32768 就表示数据库处于此状态。不过系统表是不能随便改的，设置一下先 Use Master Go sp_configure allow updates, 1 reconfigure with over

22、ride Go 然后 update sysdatabases set status = 32768 where name = 现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。如果没有报告什么错误，现在就可以松一口气了。 虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损坏。 先把SQL Server 重新启动一下，然后检查你的数据库吧。先设置成单用户模式，然后做dbcc sp_dboption , single user, true DBCC CHECKDB() 如果没有什么大问题就可以

23、把数据库状态改回去了，记得别忘了把系统表的修改选项关掉。 update sysdatabases set status = 28 where name = -当然你的数据库状态可能不是这个，自己改为合适的值吧。也可以用sp_resetstatus go sp_configure allow updates, 0 reconfigure with override Go checkdb的时候可能报告有一些错误，这些错误的数据你可能就只好丢弃了。 checkdb有几种修复选项，自己看着用吧，不过最后你可能还是得用REPAIR_ALLOW_DATA_LOSS，完成所有修复。 chekcdb并不能完成所有的修复，我们需要更进一步的修复，用DBCC CHECKTABLE对每一个表做检查吧。 表的列表可以用sysobjects里面得到，把OBJECTPROPERTY是IsTable的全部找出来检查一下吧，这样能够基本上解决问题了，如果还报告错误，试着把数据select into到另一张表检查一下。这些都做完了之后，把所有索引、视图、存储过程、触发器等重新建立一下。DBCC DBREINDEX也许可以帮你一些忙。