日期：2011-05-02 15:21:00 来源：本站整理
一次SQL Server 2000修复实践[MSSQL防范]
本文“一次SQL Server 2000修复实践[MSSQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
我所讲的一个故事的后台是这样的,在某一个POS的项目中利用sql server 2000做前台数据库,IBM 的DB2做后台数据库.前台数据库的环境是这样的操作系统是Windows 2000 SERVER(10 USERS),数据库是SQL SERVER 2000(E)+SP3,Application是POS的收银系统（是一种及时的交易系统）.硬件的配置是:P4 XRON 2.4G*2,36G HDD*5 做的RAID5 ,1G MEMORY,HP DDS4 磁带机,数据库的容量普通保持在5G左右.
因为数据对比的重要,并且数据容量也不大,我们要求的备份战略是每天在磁带机做POS_DB的全备份（一个星期7天一个循环）,在晚上还在硬盘上做全部备份（MASTER,MSDB,POS_DB).这样保持双重的保险.
1.弊端爆发:
2003－12－26 13:00
客户报告全部的POS死机和SERVER运行速度非常的慢.经太重新启动服务器（启动到查抄RAID卡时开始报警）我们发目前WINDEOWS 2000 SERVER的"系统日记"中有这样的信息:
Error: 823, Severity: 24, State: 2
I/O error (torn page) detected during read at offset 0x0000001bf96000 in file D :\DATA\POS_DB.mdf'.
SQLSERVER的"错误日记"中有这样的信息:
2003-12-10 03:34:22.23 spid56 Error: 823, Severity: 24, State: 2
2003-12-10 03:34:22.23 spid56 I/O error (torn page) detected during read at offset 0x00000074964000 in file 'D:\DATA\POS_DB.mdf'..
来自msdn的注释:
I/O logical check failure: If a read Windows API call or a write Windows API call for a database file is successful, but specific logical checks on the data are not successful (a torn page, for example), an 823 error is raised. The following error message is an example of an 823 error for an I/O logical check failure:
2003-09-05 16:51:18.90 spid17 Error: 823, Severity: 24, State: 2
2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected during read at offset 0x00000094004000 in file 'F:\SQLData\mydb.MDF'..
To resolve this problem, first run the DBCC CHECKDB statement on the database that is associated with the file in the error message. If the DBCC CHECKDB statement reports errors, correct those errors before you troubleshoot this problem. If the problem persists even after the DBCC CHECKDB errors have been corrected, or if the DBCC CHECKDB statement does not report any errors, review the Microsoft Windows NT system event log for any system errors or disk-related errors. You can also contact your hardware vendor to run any appropriate diagnostics.
I/O逻辑查抄失利:假若有一个WINDOWS程序在读取和写数据库文件时是成功的,但是在具体的数据逻辑查抄时没有成功（比方:不完好的页）,SQLSERVER会返回MSG 823的错误.下面就是一个I/O逻辑查抄失利MSG 823的实例:
2003-09-05 16:51:18.90 spid17 Error: 823, Severity: 24, State: 2
2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected during read at offset 0x00000094004000 in file 'F:\SQLData\mydb.MDF'..
要办理这样的问题,首先要在该数据库中履行DBCC CHECKDB（错误信息提醒的数据库文件）.假如DBCC CHECKDB报错,在你修复错误之前改正这些错误.假如这些错误信息一向保存到履行DBCC CHECKDB运行之后,大概DBCC CHECKDB没有报告任何错误,查抄WINDOWS NT系统的的事件查看器的和系统错误或磁盘错误相关的信息.你也可以接洽硬件厂商运行精确的诊断工具.
坏了,数据库文件有问题,在查抄OS的事件查看器,我们发目前一个星期之前就有错误信息（只是OFFSET的偏移地址差别）.
赶忙查抄HDD,公然发目前RAID5的第一快HDD亮了红灯（尘埃太多,很难于看清）
履行 DBCC CHECKDB('POS_DB')查抄发现:
Server: Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 26342838, index ID 35207, page ID (1:50978). The PageId in the page header =(32230:-2048732002).
Server: Msg 8939, Level 16, State 1, Line 1
Table error: Object ID 859150106, index ID 255, page (1:238770). Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are 2057 and -1.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 861246123, index ID 0: Page (1:57291) could not be processed. See other errors for details.
Server: Msg 2511, Level 16, State 1, Line 1
Table error: Object ID 862626116, Index ID 0. Keys out of order on page (1:269310), slots 0 and 1.
啊哈,公然有很多的表都有错误关联（请记录每一个错误表的OBJECT ID).
从MSDN查到:
错误号Msg 823:表示SQLSERVER在读取数据和写数据时检测到硬件设备有问题大概系统有问题.
TORN PAGE:的意思是不完好的页
0x0000001bf96000:这是从数据文件开始处到TORN PAGE 的字节数.
错误号Msg 8939 :大家可以看看:http://support.microsoft.com/default.ASPx?kbid=320434
FIX:在运行 CHECKDB 时,具有 TABLOCK 提醒的大容量插入（bulk insert, bcp 等）大概招致错误 8929 和 8965.
错误号MSG 8928:是和8939相关联的信息,
错误号MSG 8965:是和8939相关联的信息,
大家可以到下面的地址找到相关的信息:
http://support.microsoft.com/default.aspx?scid=kb;en-us;826433
PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
PRB: Error message 823 may indicate hardware problems or system problems
http://support.microsoft.com/default.aspx?scid=kb;en-us;308795
FIX: CheckDB May Not Fix Error 8909 or Error 8905
弊端确诊:RAID有一块HDD坏,造成数据库文件破坏
2.改换HDD
2003－12－28 23:00
目前就表现了RAID5的好处,坏了一块HDD,系统可以照常运行,不过系统的日记和SQLSERVER的日记还是有MSG823的报错信息.
按照RAID 卡的REBUILD的步骤将新的HDD绑定到原始的RAID5中,顺利完成.
用DBCC查抄数据库的完好性
DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS
发现还是有和改换HDD之前一样的ERROR信息,看来数据库文件还是有问题.
--有一个奇特问题1,既然是5块HDD的RAID5,为什么有一块HDD坏会影响数据库文件的破坏,不解?
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参数无法修复全部的错误;
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“一次SQL Server 2000修复实践”更多相关内容
中查找“一次SQL Server 2000修复实践”更多相关内容评论内容只代表网友观点，与本站立场无关！
评论摘要(共 0 条，得分 0 分，平均 0 分)
查看完整评论