sqlserver数据库:修复SQLSERVER2000数据库的实战经验来源: 发布时间:星期六, 2009年2月21日 浏览:0次 评论:0
="t18">*********************************************************************
Author:黄山光明顶 mail:[email protected] version:1.0.0 date:2004-1-30 (如需转载,请注明出处!,如果有问题请发MAIL给我:-)) ************************************************************************ 我所讲   个故事背景是这样 在某个POS项目中使用SQLSERVER 2000做前台数据库IBM DB2做后台数据库 前台数据库环境是这样操作系统是WINDOWS2000 SERVER(10 USERS),数据库是SQLSERVER2000(E)+SP3,Application是POS收银系统(是种实时交易系统)硬件配置是:P4 XRON 2.4G*2,36G HDD*5 做RAID5 ,1G MEMORYHP 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 off  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 off 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 spec  ic logical checks _disibledevent=>
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 _disibledevent=>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块HDDRAID5为何有块HDD坏会影响数据库文件损坏不解？？？:-(3.恢复数据库 2003－12－29 00:30 没有办法 用备份数据集恢复数据库(看来备份是多么重要)USE MASTER GO RESTORE DATABASE POS_DB FROM DISK='D:\DATABASEBACKUP\POS_DB_BACKUP.DAT' 重新启动MSSQLSERCVER服务 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'. 再次运行 还是有同样糟糕:=)看来这种方式是无法修复这样测失败！！！ 再仔细看看SQLSERVER BOL发现CHECKDB还有 个非常有用参数PHYSICAL_ONLYPHYSICAL_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) po  s to the data row identied by  .根据MSDN上 介绍说明:This problem does not cause any data or index corruption. The problem is in the metadata which is corrected _disibledevent=>http://support.microsoft.com/default.aspx?scid=kb;en-us;298806 http://support.microsoft.com/default.aspx?scid=kb;en-us;284440 http://support.microsoft.com/default.aspx?kbid=320434 http://support.microsoft.com/default.aspx?scid=kb;en-us;828339 http://support.microsoft.com/default.aspx?scid=kb;en-us;308795 http://support.microsoft.com/default.aspx?scid=kb;en-us;826433 0
相关文章
读者评论发表评论 |
 |
专注于互联网--专注于架构 |
最新标签 网站地图 文章索引 Rss订阅 |
