SQL Server 数据库突然不能使用解决问题回顾

2005 年 8 月 1 日 星期一。服务器数据库作业全部失败。经过查看错误日志报告为823错误。数据库SQL Server 823错误是指：SQL Server 在对某设备进行读或写请求时遇到I/O错误，该错误通常表明磁盘问题。由于该服务器上有资材处重要数据，最紧急的事情是做现在数据库的备份与恢复工作，该服务器硬盘为IDE硬盘 120G ,没有做READ。

 

服务器配置：

软件：操作系统为 windows server 2000 .数据库：SQLSERVER 2000。

硬件：cpu:    内存为： 256M 硬盘： 18G sengate硬盘（系统盘）， 120G 硬盘（数据盘）、

 

第一步解决方案：

      1.     用gost 软件把损坏的硬盘，整个备份一个。由于硬盘已经损坏，为了避免造成更大的损失，把上备份到一个新的硬盘上

 

2.     把数据备份，然后恢复到另外一台电脑中。

执行情况：由于当时数据库文件已经损坏无法完全恢复。所以此方案失败。

3.           试图通过下面语句恢复数据库。

在查询分析器中运行：

ALTER DATABASE REPORT SET SINGL_USER

GO

DBCC CHECKDB(‘REPORT’,repair_all_data_loss) WITH TABLOCK

GO

ALTER DATABASE REPORT SET MULTI_USER

GO

通过另外一台电脑。恢复数据库执行该操作，数据库文件有 17G 。执行了2天都没有执行完成。

4.       幸好，数据库备份作业在上周日下午运行的时候，数据库文件还没有损坏的迹象。决定采取恢复数据库文件到另外一台机器上的方案。通过一晚的测试。数据库文件成功恢复到自己的笔记本上。但作业和包并不能恢复回来。因为作业和包设置到服务器SQLServer实例上的。所以手工恢复该步操作。

5.       恢复数据库后可能出现很多问题，比如原来的用户权限可能没有了。需要手工建立回来。

6.       恢复数据库后。出现事务日志文件特别的大，几天下来就１０Ｇ，我们没有那么大的空间。后来出现日志文件满而造成SQL数据库无法写入文件时，用一些方法修改的。

　　　方法１：　

１．打开查询分析器，输入命令
ＤＵＭＰ　ＴＲＡＮＳＡＣＴＩＯＮ　　数据库名　with no_log

２．打开企业管理器――右建你要压缩的数据库――所有热望――收缩数据库――收缩文件――选择日志文件――在收缩方式里选择收缩至ＸＸＭ，这里会给出一个允许收缩到的最小Ｍ数，直接输入这个数，确定就可以了。

注：我用此方法，成功的压缩了数据库LOG文件

方法２：

这种发放有一点的风险性，因为SQL server的日志文件不是及时写入数据库主文件的，如处理不当，会造成数据的丢失。

１．删除LOG
分离数据库　企业管理器－》服务器－》数据库－》右建－》分离数据库

２．删除ＬＯＧ文件

３．附加数据库　企业管理器－》服务器－》数据库－》右建－》附加数据库此法生成新的ｌｏｇ文件，大小只有500多ｋ。

注：我用这种方法时：系统提示错误。无法压缩。原因不明，当时没有记下错误信息。

 

如果以后，不想要它变的

SQL 2000下使用：

在数据库上点右建－》属性－》选项－》故障恢复－模型－选择－简单模型　或用语句

　　　　　　　ｌａｔｅｒ　ｄａｔａｂａｓｅ　数据库名　ｓｅｔ　ｒｅｃｏｖｅｒｙ　ｓｉｍｐｌｅ

 

另外，如上图中数据库属性有两个选项，与事务日志增长有关：

Truncate log on checkpoint

(此选项用于SQL７．０　SQL２０００中即故障恢复模型选择为简单模型)

当执行checkpoint 命令时如果事务日志文件超过其大小的７０％则将其内容清除在开发数据库时时常将此项设置为Ｔｒｕｅ。

Ａｕｔｏ　ｓｈｒｉｎｋ

定期对数据库进行检查当数据库文件或日志文件的未用空间超过其大小的２５％时，系统将会自动缩减文件使其未使用空间等于２５％当文件大小没有超过其建立以完成恢复数据库的任务，还需要备份的数据文件参与恢复工作。恢复数据库时，首先进行的是数据文件的恢复工作。在整个数据文件恢复完成前，不要将其设为完成状态，否则交易日志就不会被恢复。

 

经过种种实验。我们的数据库现已经恢复正常。摆在我面前的又有一个新的问题，如何提供数据库的性能。压缩数据库的大小，由于我数据库管理的经验有限。可能方法有些苯，希望以后的工作中总结问题。