数据库823错误解决方法

标题：MySQLMSSQL数据库823错误解决方法出处：时间：Sat, 12 Apr 2008 10:12:27 +0000作者：ah011地址：/read.php?193内容：1.日志文件被破坏823错误-日志文件被破坏的数据库文件，通过如下方法附加上去后，数据库里所有的表都不能访问，提示错误832，请问要如何解决？use mastergosp_configure allow updates,1goreconfigure with overridegoupdate sysdatabases set status=-32768 where dbid=DB_ID(linyi_pljy)godbcc rebuild_log(linyi_pljy,e:Program FilesMicrosoft SQL ServerMSSQLDatalinyi_pljy_log.ldf)gosp_dboption linyi_pljy,dbo use only,falsegosp_configure allow updates,0go reconfigure with overridego-2.附加数据库文件时,提示823错误-（1）朋友单位有台电脑的数据库ufdata_001_2008状态为置疑，我断开再附加时提示如下图所示说明，附加时失败，错误823。原因分析：出现这种情况可能是由于电脑忽然断电或者异常关机造成的。解决方法：在SQL企业管理器中，新建同名数据库ufdata_001_2008，新建库后现有数据名称是ufdata_001_2008.mdf和ufdata_001_2008_log.LDF；停止数据库，把损坏的数据库文件ufdata.mdf和ufdata.LDF修改名称为ufdata_001_2008.mdf和ufdata_001_2008_log.LDF，并覆盖刚才新建数据库目录下的数据，同时删除ufdata_001_2008_log.LDF文件；启动数据库服务，发现数据库名ufdata_001_2008后面有“置疑”字样；打开SQL自带查询分析器，执行如下SQL语句：use mastergoexec sp_configure allow updates,1 RECONFIGURE WITH OVERRIDE /* 打开修改系统表的开关 */goupdate sysdatabases set status=32768 where name=ufdata_001_2008 /* 设置数据库状态 */goDBCC REBUILD_LOG (ufdata_001_2008,E:ufdataufdata.LDF) /* 重建LDF文件 */goupdate sysdatabases set status=0 where name=ufdata_001_2008 /* 重置数据库状态 */gorestore database ufdata_001_2008 WITH RECOVERY /* 恢复数据库 */goexec sp_configure allow updates,0 RECONFIGURE WITH OVERRIDE /* 关闭打开修改系统表的开关 */执行以上语句后，ufdata_001_2008没有了置疑状态，数据可以正常读取了（2）use mastergoEXEC sp_configure allow updates,1 RECONFIGURE WITH OVERRIDE /* 打开修改系统表的开关 */ update sysdatabases set status = 32768 where name = 数据库名 DBCC REBUILD_LOG (数据库名, E: dzzdatabase dzz1204_Log.LDF ) update sysdatabases set status = 0 where name = 数据库名 restore database 数据库名 WITH RECOVERY EXEC sp_configure allow updates,0 RECONFIGURE WITH OVERRIDE /* 关闭打开修改系统表的开关 */ 3因为停电等原因造成MSSQL数据库,提示823错误-USE MASTERGOsp_dboption databaseName, single user, trueGoDBCC CHECKDB(databaseName, REPAIR_REBUILD)GoUSE databaseNamegoexec sp_msforeachtable DBCC CHECKTABLE(?,REPAIR_REBUILD)gosp_dboption databaseName, single user, falseGo如果还不行，可以采用允许丢失数据的方式修复，如下：USE MASTERGOsp_dboption databaseName, single user, trueGoDBCC CHECKDB(databaseName, REPAIR_ALLOW_DATA_LOSS)GoUSE databaseNamegoexec sp_msforeachtable DBCC CHECKTABLE(?,REPAIR_REBUILD)gosp_dboption databaseName, single user, falseGo 4.数据库恢复资料-SQL Server数据库备份有两种方式，一种是使用BACKUP DATABASE将数据库文件备份出去，另外一种就是直接拷贝数据库文件mdf和日志文件ldf的方式。下面将主要讨论一下后者的备份与恢复。本文假定您能熟练使用SQL Server Enterprise Manager(SQL Server企业管理器)和SQL Server Quwey Analyser(SQL Server查询分析器)1、正常的备份、恢复方式正常方式下，我们要备份一个数据库，首先要先将该数据库从运行的数据服务器中断开，或者停掉整个数据库服务器，然后复制文件。卸下数据库的命令：Sp_detach_db 数据库名连接数据库的命令：Sp_attach_db或者sp_attach_single_file_dbs_attach_db dbname = dbname, filename1 = filename_n ,.16sp_attach_single_file_db dbname = dbname, physname = physical_name使用此方法可以正确恢复SQL Sever7.0和SQL Server 2000的数据库文件，要点是备份的时候一定要将mdf和ldf两个文件都备份下来，mdf文件是数据库数据文件，ldf是数据库日志文件。例子：假设数据库为test，其数据文件为test_data.mdf，日志文件为test_log.ldf。下面我们讨论一下如何备份、恢复该数据库。卸下数据库：sp_detach_db test连接数据库：sp_attach_db test,C:Program FilesMicrosoft SQL ServerMSSQLDatatest_data.mdf,C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.ldfsp_attach_single_file_db test,C:Program FilesMicrosoft SQL ServerMSSQLDatatest_data.mdf2、只有mdf文件的恢复技术由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息设备激活错误。物理文件名 C:Program FilesMicrosoft SQL ServerMSSQLdatatest_Log.LDF 可能有误。已创建名为 C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.LDF 的新日志文件。但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息服务器: 消息 1813，级别 16，状态 2，行 1未能打开新数据库 test。CREATE DATABASE 将终止。设备激活错误。物理文件名 d:test_log.LDF 可能有误。怎么办呢？别着急，下面我们举例说明恢复办法。A我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。B停掉数据库服务器。C将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。D启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。E设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。use mastergosp_configure allow updates,1go reconfigure with overridegoF设置test为紧急修复模式update sysdatabases set status=-32768 where dbid=DB_ID(test)此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读置疑脱机紧急模式”可以看到数据库里面的表，但是仅仅有系统表G下面执行真正的恢复操作，重建数据库日志文件dbcc rebuild_log(test,C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf)执行过程中，如果遇到下列提示信息：服务器: 消息 5030，级别 16，状态 1，行 1未能排它地锁定数据库以执行该操作。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。brown说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。正确执行完成的提示应该类似于：brown警告: 数据库 test 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。H验证数据库一致性（可省略）dbcc checkdb(test)一般执行结果如下：CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 test 中）。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。I设置数据库为正常状态sp_dboption test,dbo use only,false如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。J最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成sp_configure allow updates,0go reconfigure with overridegoSQL Server数据库文件恢复技术SQL Server数据库备份有两种方式，一种是使用BACKUP DATABASE将数据库文件备份出去，另外一种就是直接拷贝数据库文件mdf和日志文件ldf的方式。下面将主要讨论一下后者的备份与恢复。本文假定您能熟练使用SQL Server Enterprise Manager(SQL Server企业管理器)和SQL Server Quwey Analyser(SQL Server查询分析器)1、正常的备份、恢复方式正常方式下，我们要备份一个数据库，首先要先将该数据库从运行的数据服务器中断开，或者停掉整个数据库服务器，然后复制文件。卸下数据库的命令：Sp_detach_db 数据库名连接数据库的命令：Sp_attach_db或者sp_attach_single_file_dbs_attach_db dbname = dbname, filename1 = filename_n ,.16sp_attach_single_file_db dbname = dbname, physname = physical_name使用此方法可以正确恢复SQL Sever7.0和SQL Server 2000的数据库文件，要点是备份的时候一定要将mdf和ldf两个文件都备份下来，mdf文件是数据库数据文件，ldf是数据库日志文件。例子：假设数据库为test，其数据文件为test_data.mdf，日志文件为test_log.ldf。下面我们讨论一下如何备份、恢复该数据库。卸下数据库：sp_detach_db test连接数据库：sp_attach_db test,C:Program FilesMicrosoft SQL ServerMSSQLDatatest_data.mdf,C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.ldfsp_attach_single_file_db test,C:Program FilesMicrosoft SQL ServerMSSQLDatatest_data.mdf2、只有mdf文件的恢复技术由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息设备激活错误。物理文件名 C:Program FilesMicrosoft SQL ServerMSSQLdatatest_Log.LDF 可能有误。已创建名为 C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.LDF 的新日志文件。但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息服务器: 消息 1813，级别 16，状态 2，行 1未能打开新数据库 test。CREATE DATABASE 将终止。设备激活错误。物理文件名 d:test_log.LDF 可能有误。怎么办呢？别着急，下面我们举例说明恢复办法。A我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。B停掉数据库服务器。C将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。D启动数据库服务器。此时会看到数据库test的状态为置疑。这时候不能对此数据库进行任何操作。E设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择属性，在服务器设置页面中将允许对系统目录直接修改一项选中。也可以使用如下语句来实现。use mastergosp_configure allow updates,1go reconfigure with overridegoF设置test为紧急修复模式update sysdatabases set status=-32768 where dbid=DB_ID(test)此时可以在SQL Server Enterprise Manager里面看到该数据库处于只读置疑脱机紧急模式可以看到数据库里面的表，但是仅仅有系统表G下面执行真正的恢复操作，重建数据库日志文件dbcc rebuild_log(test,C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf)执行过程中，如果遇到下列提示信息：服务器: 消息 5030，级别 16，状态 1，行 1未能排它地锁定数据库以执行该操作。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。正确执行完成的提示应该类似于：警告: 数据库 test 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为只供DBO使用。此时可以访问数据库里面的用户表了。H验证数据库一致性（可省略）dbcc checkdb(test)一般执行结果如下：CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 test 中）。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。I设置数据库为正常状态sp_dboption test,dbo use only,false如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。J最后一步，我们要将步骤E中设置的允许对系统目录直接修改一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成sp_configure allow updates,0go reconfigure with overridego=(转)修复SQLSERVER2000数据库之实战经验我所讲的一个故事的背景是这样的，在某一个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.故障爆发：20031226 13:00客户报告所有的POS死机和SERVER运行速度非常的慢。经过重新启动服务器（启动到检查RAID卡时开始报警）我们发现在WINDEOWS 2000 SERVER的“系统日志”中有这样的信息：Error: 823, Severity: 24, State: 2I/O error (torn page) detected during read at offset 0xbf96000 in file D :DATAPOS_DB.mdf. SQLSERVER的“错误日志”中有这样的信息： 2003-12-10 03:34:22.23 spid56 Error: 823, Severity: 24, State: 22003-12-10 03:34:22.23 spid56 I/O error (torn page) detected during read at offset 0x000 in file D:DATAPOS_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 0x000 in file F:SQLDatamydb.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 0x000 in file F:SQLDatamydb.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 1Table error: Object ID , index ID 35207, page ID (1:50978). The PageId in the page header =(32230:-).Server: Msg 8939, Level 16, State 1, Line 1Table error: Object ID , index ID 255, page (1:). Test (IS_ON (BUF_IOERR, bp-bstat) & bp-berrcode) failed. Values are 2057 and -1.Server: Msg 8928, Level 16, State 1, Line 1Object ID , index ID 0: Page (1:57291) could not be processed. See other errors for details.Server: Msg 2511, Level 16, State 1, Line 1Table error: Object ID , Index ID 0. Keys out of order on page (1:), slots 0 and 1.啊哈，果然有很多的表都有错误关联（请记录每一个错误表的OBJECT ID)从MSDN查到：错误号Msg 823:表示SQLSERVER在读取数据和写数据时检测到硬件设备有问题或者系统有问题。TORN PAGE:的意思是不完整的页0xbf96000：这是从数据文件开始处到TORN PAGE 的字节数。错误号Msg 8939 ：大家可以看看：/default.aspx?kbid=FIX：在运行 CHECKDB 时，具有 TABLOCK 提示的大容量插入（bulk insert, bcp 等）可能导致错误 8929 和 8965错误号MSG 8928:是和8939相关联的信息，错误号MSG 8965:是和8939相关联的信息，大家可以到下面的地址找到相关的信息：/default.aspx?scid=kb;en-us;PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems/default.aspx?scid=kb;en-us;PRB: Error message 823 may indicate hardware problems or system problems/default.aspx?scid=kb;en-us;FIX: CheckDB May Not Fix Error 8909 or Error 8905故障确诊：RAID有一块HDD坏，造成数据库文件破坏2.更换HDD20031228 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.恢复数据库20031229 00:30没有办法，用备份的数据集恢复数据库（看来备份是多么的重要）USE MASTERGORESTORE DATABASE POS_DB FROM DISK=D:DATABASEBACKUPPOS_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(这里可能是错误的应为：sp_dboption , single user, true)GODBCC CHECKDB(POS_DB,repair_allow_data_loss) WITH TABLOCKGOALTER DATABASE POS_DB SET MULTI_USERGOCHECKDB 有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 ) (object ID ).CHECKDB fixed 0 allocation errors and 1 consistency errors in table (Object ID ) (object ID ).这样的信息有很多，并且有“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_