当前位置: 首页 > 图文教程 > 数据库 > MSSQL > 修复SQLSERVER2000数据库之实战经验

MSSQL
用SQL语句实现替换字符串
mssql查找备注(text,ntext)类型字段为空的方法
MSSQL数据类型及长度限制详细说明
SQL Server下几个危险的扩展存储过程
一些SQL Server存储过程参数及例子
sql高级技巧几个有用的Sql语句
SQL语句实现SQL Server 2000及Sql Server 2005日志收缩(批量)
用SQL建立索引的方法步骤
MSsql每天自动备份数据库并每天自动清除log的脚本
mssql无数据库日志文件恢复数据库的方法
SQL Server常用管理命令小结
SQL SERVER性能优化综述(很好的总结,不要错过哦)
sqlserver 游标的简单示例
sqlserver只有MDF文件恢复数据库的方法
在SQL Server启动时自动执行存储过程。
在 SQLSERVER 中快速有条件删除海量数据
阿拉伯数字转大写中文_财务常用sql存储过程
SQL Server存储过程的基础说明
列出SQL Server中具有默认值的所有字段的语句
文本、Excel、Access数据导入SQL Server2000的方法

MSSQL 中的 修复SQLSERVER2000数据库之实战经验


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-10-30   浏览: 63 ::
收藏到网摘: n/a

 

*********************************************************************

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 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
 Tab