|
导读-- 在某一个POS的项目中使用SQL SERVER 2000做前台数据库，IBM 的DB2做后台数据库
3.恢复数据库
2003－12－29 00:30
没有办法，用备份的数据集恢复数据库（看来备份是多么的重要）
USE MASTER
GO
RESTORE DATABASE POS_DB FROM DISK=''D:\DATABASEBACKUP\POS_DB_BACKUP.DAT''
重新启动MS SQL SERCVER服务。
NET STOP MSSQLSERVER / NET START MSSQLSERVER
用DBCC检查数据库的完整性
DBCC CHECKDB(''POS_DB'') WITH ALL_ERRORMSGS
和恢复之前的错误信息一致，没有改变。
--奇怪问题之2，SQLSERVER BACKUP 之前并不验证数据库的完整性，数据库的全备份竟然是有问题的。气愤！！
看来只能通过工具修复数据库了（--在修改之前记录错误表的记录数，以便修复数据库后进行比较）。
在查询分析器中运行：
ALTER DATABASE POS_DB SET SINGL_USER
GO
DBCC CHECKDB(''POS_DB'',repair_allow_data_loss) WITH TABLOCK
GO
ALTER DATABASE POS_DB SET MULTI_USER
GO
CHECKDB 有3个参数:
REPAIR_ALLOW_DATA_LOSS
执行由 REPAIR_REBUILD 完成的所有修复，包括对行和页进行分配和取消分配以改正分配错误、结构行或页的错误，以及删除已损坏的文本对象。这些修复可能会导致一些数据丢失。修复操作可以在用户事务下完成以允许用户回滚所做的更改。如果回滚修复，则数据库仍会含有错误，应该从备份进行恢复。如果由于所提供修复等级的缘故遗漏某个错误的修复，则将遗漏任何取决于该修复的修复。修复完成后，备份数据库。
REPAIR_FAST 进行小的、不耗时的修复操作，如修复非聚集索引中的附加键。这些修复可以很快完成，并且不会有丢失数据的危险。
REPAIR_REBUILD 执行由 REPAIR_FAST 完成的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。
第一次运行，我们会发现：
DBCC results for ''TABLE_NAME''.
There are 1 rows in 1 pages for object ''TABLE_NAME''.
The error has been repaired.
CHECKDB found 0 allocation errors and 1 consistency errors in table ''(Object ID 26342838)'' (object ID 26342838).
CHECKDB fixed 0 allocation errors and 1 consistency errors in table ''(Object ID 26342838)'' (object ID 26342838).
这样的信息有很多，并且有“The error has been repaired”的提示。不过到最后还是有这样的信息：
CHECKDB found 0 allocation errors and 19 consistency errors in database ''POS_DB''.
CHECKDB fixed 0 allocation errors and 19 consistency errors in database ''POS_DB''.
再次运行，还是有同样的错误。糟糕:=)看来这种方式是无法修复这样测错误。
失败！！！
再仔细看看SQL SERVER BOL发现CHECKDB还有一个非常有用的参数PHYSICAL_ONLY
PHYSICAL_ONLY
仅限于检查页和记录标题物理结构的完整性，以及页对象 ID 和索引 ID 与分配结构之间的一致性。该检查旨在以较低的开销检查数据库的物理一致性，同时还检测会危及用户数据安全的残缺页和常见的硬件故障。PHYSICAL_ONLY 始终意味着 NO_INFOMSGS，并且不能与任何修复选项一起使用。
再次运行：
DBCC CHECKDB(''POS_DB'') with NO_INFOMSGS,PHYSICAL_ONLY
然后再运行：
DBCC CHECKDB(''POS_DB'',repair_allow_data_loss) WITH TABLOCK
这次会返回一些8952.8956的错误信息:
Server: Msg 8952, Level 16, State 1, Line 1
Table error: Database ''POS_DB'', index ''POS_REFER.Idx2_POS_REFER'' (ID 861246123) (index ID 2). Extra or invalid key for the keys:
Server: Msg 8956, Level 16, State 1, Line 1
Index row (1:26315:23) with values (PLU_ID = ''6922825200240'' and PRD_AGGR_ID = 10006 and EVNT_ID = NULL and RGST_MDE = 0 and SUBPRD_NBR = 0 and STR_ID = 12 and PRD_AGGR_ID = 10006 and SUBPRD_NBR = 0 and STR_ID = 12 and PLU_ID = ''6922825200240'' and EVNT_ID = NULL and RGST_MDE = 0) points to the data row identified by ().
根据MSDN上的说明：
This problem does not cause any data or index corruption. The problem is in the metadata which is corrected only by dropping and re-creating the indexes.
这些问题不会引起数据或索引的损坏，这些问题的元数据是正确的，只是删除再重新建立索引。
看来问题是修改了。
再次运行DBCC CHECKDB(''POS_DB''),再次运行:DBCC CHECKDB(''POS_DB''),message没有错误信息。
成功修复。
4.检查修复后的数据库并且备份数据库
检查DBCC CHECKDB报错的相关表，和没有执行DBCC之前的记录数进行比较，发现有一个表少了40条记录。郁闷。
5.总结
1.RAID5并不能保证SQLSERVER 2000 数据库的数据文件的完整性；
2.SQLERVER 2000的备份程序不验证数据库文件的数据完整性；如果你的数据文件有问题，备份时也不图示；
3.DBCC CHECKDB的repair_allow_data_loss并不是非常安全的，不能修复所有的错误，即使是对不完整页（TORN PAGE）的修复也会着成数据丢失；
4.DBCC CHECKDB的REPAIR_ALLOW_DATA_LOSS参数无法修复所有的错误;
|
