寒山sql数据库修复中心https://www.doczj.com/doc/b71336165.html,/
出错状态:
现象1：
数据库后面有“置疑”字样，查看系统事务日记出现以下错误：错误1--------------------------------------------- 错误: 823，严重度: 24，状态: 2
I/O error 23(数据错误(循环冗余检查)。) detected during read at offset 0x00000000200000 in file 'D:\捷作2008\data\test_Data.MDF'. 错误2--------------------------------------------- 错误: 3313，严重度: 21，状态: 2
恢复数据库'' 的日志中记录的操作时出错。出错位置在日志记录ID (274:377:2)。
错误3--------------------------------------------- 错误: 3313，严重度: 21，状态: 2
Error while redoing logged operation in database 'test'. Error at log record ID (274:377:2).
数据库可以分离，但分离后无法附加，附加时出现“823”号错误。
------------------------------------------------------------------------------------------------------------- 微软公司SQL联机从书解释:
错误823 严重级别24
消息正文在文件''%4!'' 的偏移量%3! 处的%2! 过程中，检测到I/O 错误%1!。解释
Microsoft? SQL Server? 在对某设备进行读或写请求时遇到I/O 错误。该错误通常表明磁盘问题。但是，错误日志中在错误823 之前记录的其它核心消息应指出涉及了哪个设备。对策
检查该设备的可访问性和状态。如果可能，执行硬件诊断并纠正问题。从最新的数据库备份还原损坏的文件。从数据库备份中还原应始终是修复已损坏数据库的首选方法。
如果没有备份或者检测到的错误是孤立的，则DBCC CHECKDB 的修复功能可能很有用。然而，比起从备份中还原损坏的文件，可能使用DBCC CHECKDB 消耗的时间更多，且可能无法恢复全部数据。
注意??如果使用修复子句运行DBCC CHECKDB 时，问题没有得到纠正，或者不知道该过程将如何影响数据，请与主要的支持提供者联系。出错原因:通常这个问题是由于硬盘空间不够/硬盘读写错误/忽然断电(停电/死机),SQL系统异常。
1.日志文件被破坏823错误----------------------
日志文件被破坏的数据库文件，通过如下方法附加上去后，数据库里所有的表都不能访问，提示错误832，请问要如何解决？？use master go
sp_configure 'allow updates',1 go
reconfigure with override go
/*注意输正确，如果输入后执行此语句，并且下面显示
DBCC 执行完毕。如果DBCC 输出了错误信息，请与系统管理员联系。已将配置选项'allow updates' 从0 改为1。请运行RECONFIGURE 语句以安装。
说明执行正确，如果不显示以上信息，请检查是否有输错！此语句是的作用是：设置数据库允许直接操作系统表。
*/
update sysdatabases set status=-32768 where dbid=DB_ID('icyqshsf') /*设置数据库为紧急修复模式。*/ go
dbcc rebuild_log('icyqshsf','e:\Program Files\Microsoft SQL Server\MSSQL\Data\icyqshsf_log.ldf') /*重新数据库日志(ldf)文件。
下面显示:
警告: 数据库'test' 的日志已重建。已失去事务的一致性。应运行DBCC CHECKDB 以验证物理一致性。
将必须重置数据库选项，并且可能需要删除多余的日志文件。*/ go
dbcc checkdb('icyqshsf')/*现在检查有没有错误，再输入语法
下面显示
CHECKDB 发现了0 个分配错误和0 个一致性错误（在数据库'tiger' 中）。
那说明第6步就建立成功没问题了，下面就可以把SQL恢复模式了*/ go
sp_dboption 'icyqshsf','dbo use only','false' go
sp_configure 'allow updates',0 go
reconfigure with override go
---------------------
2.附加数据库文件时,提示823错误----------------------
EXEC 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 MASTER GO sp_dboption 'databaseName', 'single user', 'true' Go
DBCC CHECKDB('databaseName', REPAIR_REBUILD) Go
USE databaseName go
exec sp_msforeachtable 'DBCC CHECKTABLE('''?''',REPAIR_REBUILD)' go
sp_dboption 'databaseName', 'single user', 'false' Go如果还不行，可以采用允许丢失数据的方式修复，如下：USE MASTER GO
sp_dboption 'databaseName', 'single user', 'true' Go
DBCC CHECKDB('databaseName', REPAIR_ALLOW_DATA_LOSS) Go
USE databaseName go
exec sp_msforeachtable 'DBCC CHECKTABLE('''?''',REPAIR_REBUILD)' go
sp_dboption 'databaseName', 'single user', 'false' Go
================================================================ 修复方法恢复语句:
--drop database wgy --create database wgy
--RESTORE FILELISTONL Y from disk='F:\data\1218\wgy.db' ALTER DATABASE wgy SET OFFLINE WITH ROLLBACK IMMEDIATE restore database wgy from disk='F:\data\1218\wgy.db' with replace,
MOVE 'Syb_Data' TO 'D:\Data\NPDFDN.mdf', MOVE 'Syb_Log' TO 'D:\Data\NPDFDN.ldf'
ALTER DATABASE wgy SET ONLINE WITH ROLLBACK IMMEDIATE 方法一：
1.新建一个同名的数据库
2.再停掉sql server
3.用mdf和ldf数据库的文件覆盖掉这个新建的同名数据库
4.再重启sql server
5.此时打开企业管理器时新建的同名数据库会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
USE MASTER GO
SP_CONFIGURE 'ALLOW UpdateS',1 RECONFIGURE WITH OVERRIDE GOUpdate SYSDATABASES SET STATUS =32768 Where NAME='aaa' Go
sp_dboption 'aaa', 'single user', 'true' Go
DBCC CHECKDB('aaa') Go
update sysdatabases set status =28 where name='aaa' Go
sp_configure 'allow updates', 0 reconfigure with override Go
sp_dboption 'aaa', 'single user', 'true' Go
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了. 方法二：
1.新建一个同名的数据库
2.再停掉sql server
3.用mdf和ldf数据库的文件覆盖掉这个新建的同名数据库
4.再重启sql server
5.此时打开企业管理器时新建的同名数据库会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名) USE MASTER GO
SP_CONFIGURE 'ALLOW UpdateS',1 RECONFIGURE WITH OVERRIDE GO
Update SYSDATABASES SET STATUS =32768 Where NAME='aaa' Go
sp_dboption 'aaa', 'single user', 'true' Go
DBCC REBUILD_LOG ('aaa', 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\aaa_Log2.LDF' )
Go
update sysdatabases set status = 0 where name = 'aaa' Go
restore database aaa WITH RECOVERY
--如果表有错的话用DBCC CHECKTABLE来进行修复go
DBCC CHECKDB('aaa')Go
update sysdatabases set status =28 where name='aaa' Go
sp_configure 'allow updates', 0 reconfigure with override Go
sp_dboption 'aaa', 'single user', 'true' Go
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了. 方法三：
.非置疑数据库修复技术:
USE MASTER GO
sp_dboption 'aaa', 'single user', 'true' Go
--无损修复
DBCC CHECKDB('aaa', REPAIR_REBUILD)
--有损修复
-- DBCC CHECKDB('ke_2008', repair_allow_data_loss) WITH TABLOCK --如果表有错的话用DBCC CHECKTABLE来进行修复Go
sp_dboption 'aaa', 'single user', 'false' Go
方法四：/*--重置置疑状态系统方法:
如果sql server 因为磁盘驱动器不再有可用空间，而不能完成数据库的恢复，那么microsoft? sql server? 2000 会返回错误1105
并且将sysdatabases 中的status 列设为置疑。按下面的步骤解决这个问题：执行sp_resetstatus。语法为：
sp_resetstatus 'aaa' sp_resetstatus '数据库名'
用alter database 向数据库添加一个数据文件或日志文件。停止并重新启动sql server。用新的数据文件或日志文件所提供的额外空间，sql server 应该能完成数据库的恢复。
释放磁盘空间并且重新运行恢复操作。
sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。--*/ 方法五：
--手工重置置疑状态use master go
sp_configure 'allow updates',1 reconfigure with override go
declare @dbname varchar(30) set @dbname='lqgs' if @@trancount > 0
print '正在进行事务处理,操作不能进行' else if suser_id()!=1
print '你不是系统管理员(sa),不能进行此操作' else if not exists(select 1 from master..sysdatabases where name=@dbname) print '你要操作的数据库不存在' else if not exists(select 1 from master..sysdatabases where name= @dbname and status & 256 = 256) print '你的数据库没有被置疑' else begin
begin tran update master..sysdatabases set status = status ^ 256 where name = @dbname if @@error != 0 or @@rowcount != 1 rollback tran else begin
commit tran
print '操作成功,请重新启动SQL' end end go
sp_configure 'allow updates', 1 reconfigure with override go
sp_resetstatus lqgs 方法六：重置置疑状态
如果SQL Server 因为磁盘驱动器不再有可用空间，而不能完成数据库的恢复，那么
Microsoft? SQL Server? 2000 会返回错误1105 并且将sysdatabases 中的status
列设为置疑。按下面的步骤解决这个问题：1.. 执行sp_resetstatus。
2.. 用Alter DATABASE 向数据库添加一个数据文件或日志文件。
3.. 停止并重新启动SQL Server。
用新的数据文件或日志文件所提供的额外空间，SQL Server 应该能完成数据库的恢复。
4.. 释放磁盘空间并且重新运行恢复操作。
sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。
注意只有在您的主要支持提供者指导下或有疑难解答建议的做法时，才可以使用
sp_resetstatus。否则，可能会损坏数据库。由于该过程修改了系统表，系统管理员必须在创建这个过程前，启用系统表更新。要启
用更新，使用下面的过程：USE master GO
sp_configure 'allow updates', 1 GO
RECONFIGURE WITH OVERRIDE GO
过程创建后，立即禁用系统表更新：sp_configure 'allow updates', 0 GO
RECONFIGURE WITH OVERRIDE GO
只有系统管理员才能执行sp_resetstatus。执行该过程后，立即关闭SQL Server。语法为：
sp_resetstatus aaa
下面的例子将关闭PRODUCTION 数据库的置疑标志。sp_resetstatus PRODUCTION 下面是结果集：
Database 'PRODUCTION' status reset!
WARNING: You must reboot SQL Server prior to accessing this database! sp_resetstatus 存储过程代码
下面是sp_resetstatus 存储过程的代码：
IF EXISTS ( Select * from sysobjects where name = 'sp_resetstatus' )Drop PROCEDURE sp_resetstatus GO
Create PROC sp_resetstatus @dbname varchar(30) AS DECLARE @msg varchar(80) IF @@trancount > 0 BEGIN
PRINT 'Can''t run sp_resetstatus from within a transaction.' RETURN (1) END
IF suser_id() != 1 BEGIN
Select @msg = 'You must be the System Administrator (SA)' Select @msg = @msg + ' to execute this procedure.' RETURN (1) END
IF (Select COUNT(*) FROM master..sysdatabases Where name = @dbname) != 1 BEGIN
Select @msg = 'Database ' + @dbname + ' does not exist!' PRINT @msg RETURN (1) END IF (Select COUNT(*) FROM master..sysdatabases
Where name = @dbname AND status & 256 = 256) != 1 BEGIN
PRINT 'sp_resetstatus can only be run on suspect databases.' RETURN (1) END
BEGIN TRAN
Update master..sysdatabases SET status = status ^ 256 Where name = @dbname
IF @@error != 0 or @@rowcount != 1 ROLLBACK TRAN ELSE BEGIN
COMMIT TRAN
Select @msg = 'Database ' + @dbname + ' status reset!' PRINT @msg PRINT ''
PRINT 'WARNING: You must reboot SQL Server prior to ' PRINT ' accessing this database!' PRINT '' ENDMS Sql Server 提供了很多数据库修复的命令，当数据库置疑或是有的无法完成读取时可以尝试这些修复命令。
1. DBCC CHECKDB
重启服务器后，在没有进行任何操作的情况下，在SQL查询分析器中执行以下SQL进行数据库的修复，修复数据库存在的一致性错误与分配错误。
use master
declare @databasename varchar(255)
set @databasename='需要修复的数据库实体的名称'
exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态
然后执行DBCC CHECKDB('需要修复的数据库实体的名称') 检查数据库是否仍旧存在错误。注意：修复后可能会造成部分数据的丢失。
2. DBCC CHECKTABLE
如果DBCC CHECKDB 检查仍旧存在错误，可以使用DBCC CHECKTABLE来修复。
use 需要修复的数据库实体的名称declare @dbname varchar(255)
set @dbname='需要修复的数据库实体的名称' exec sp_dboption @dbname,'single user','true'
dbcc checktable('需要修复的数据表的名称',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable('需要修复的数据表的名称',REPAIR_REBUILD) ------把’需要修复的数据表的名称’更改为执行DBCC CHECKDB时报错的数据表的名称
exec sp_dboption @dbname,'single user','false'
3. 其他的一些常用的修复命令
DBCC DBREINDEX 重建指定数据库中表的一个或多个索引用法：DBCC DBREINDEX (表名,’’) 修复此表所有的索引。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
SQL SERVER数据库的检测及修复方法数据库文件被频繁地使用，由于某些原因，数据库有可能被损坏，本文将针对这种情况的数据库检测及修复方法做一简单讲解。1.1 SQL SERVER数据库的检测
SQL SERVER提供了数据库检测的命令，可用DBCC CHECKDB对数据库中各个对象的分配及结构的正确性进行检测，并可通过一参数控制，将所有的错误信息显示出来。其语法如下：DBCC CHECKDB
('database_name' [,NOINDEX | { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD }]
) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}] 参数说明：
'database_name'代表被检测的数据库实体名；NOINDEX指非系统表的非聚族索引不检测；
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST| REPAIR_REBUILD 指直接修复发现的错误，其中REPAIR_ALLOW_DATA_LOSS代表，若此错误不能修复时，系统将直接删除相关数据。带此三个参数的任一个时，数据库必须处于单用户模式，可在Enterprise Manager中的数据库属性中设置；ALL_ERRORMSGS代表将检测到的错误信息全部显示出来，否则，对于每张表最多只显示200条错误信息；NO_INFOMSGS代表隐藏所有的信息及占用空间的报告。
经过检测，对于错误的对象，将以OBJECT ID的形式报告具体出错的信息，可根据OBJECT ID到系统表sysobjects中查找到相关的表，即NAME。
1.2 SQL SERVER问题数据库的修复
经过数据库检测后，可针对出现的问题采取相应的措施进行处理。如通过检测后，发现对象的物理存放存在问题，可用DBCC CHECKALLOC来进行修复：
DBCC CHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
若是非系统对象的索引出错，则可用DBCC DBREINDEX进行修复：DBCC DBREINDEX ( [ 'database.owner.table_name' [, index_name [, fillfactor ] ] ] ) [WITH NO_INFOMSGS] 以上
两
种
情
况
，
也
可
直
接
使
用
DBCC
CHECKDB(‘db_name’,repair_rebuild)来修复。
另外一种情况是在进行检测时，提示无法建立数据连接，此时表明，数据库已损坏。对于这种情况，我们可采取如下措施来尝试修复。首先，在企业管理器中新建一数据库（如
数据库名为test）；建好数据库后，停止SQL服务器，并将客户数据库的MDF文件更名为test _data.mdf(即新建数据库的主文件名)，然后用更名后的文件覆盖新建数据库同名文件，接着，启动SQL服务器。对Master数据库将系统表设置为可更改状态Use Master Go sp_configure 'allow updates', 1 reconfigure with override Go
将数据库设为紧急状态：
update sysdatabases set status = 32768 where dbid=DB_ID('test')
停止并重新启动SQL服务器，并重建Log文件：DBCC TRACEON (3604)
DBCC REBUILD_LOG(' test ','test _log_ldf')
将数据库设置为单用户模式，然后进行检测：sp_dboption ' test ', 'single user', 'true' DBCC CHECKDB(' test ') Go
此数据库执行CHECKDB的过程中发现一些表的索引被破坏，于是针对具体的表进行重建索引的操作：DBCC DBREINDEX（表名）
如执行以上操作仍然不能解决，若索引破坏的表是临时表或不是关键表，则可从新建账套中引入，若是主表，则可能通过近期的备份来（部份）恢复。若没有一个备份，则无法修复。
1.3 SQL Server数据库为什么易损坏呢？
以下是微软提供的一些可能引起数据库损坏的原因及一些预防措施：操作问题，包括冷起动机器、热拔硬盘、删除一些数据库文件；硬件问题，包括磁盘控制器的问题；
操作系统问题，包括与系统相关的一些致命错误。
1.4 预防措施：
1、定期/不定期执行CHKDSK(不带参数)，以检测硬盘物理结构并修复一些CHKDSK报告的问题；
2、常备份数据。
1.5 应用数据库修复举例
declare @databasename varchar(255)
set @databasename='AIS20021224170730'------一定要手工输入---------执行一般性修复还存在问题时,进行允许数据丢失的修复---------许数据丢失的修复要求在单用户下进行,此时请退出中间层,客户端,sql的其他模块
---所有功能退出,在查询分析器master里设置数据库为单用户
exec sp_dboption @databasename, N'single', N'true'
-----在查询分析器master里,进行修复数据库
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) dbcc checkdb(@databasename,REPAIR_REBUILD) ------还原数据库状态
exec sp_dboption @databasename, N'single', N'false'
第2章数据库日志损坏的修复
请遵照如下步骤来试图重建数据库事务日志.
注意: 由于事务日志丢失, 数据库可能有没有提交的数据.
注:都要替换成真实的数据库名字
--1．我们使用默认方式建立一个供恢复使用的数据库(如pos)。可以在SQL Server Enterprise Manager里面建立。--2．停掉数据库服务器。
--3．将刚才生成的数据库的日志文件pos_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件pos_data.mdf。--4．启动数据库服务器。此时会看到数据库pos的状态为“置疑”。这时候不能对此数据库进行任何操作。
--5．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目
录直接修改”一项选中。也可以使用如下语句来实现。use master go
exec sp_configure 'allow updates',1 go
reconfigure with override go
--6．设置pos为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('pos') --此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
--7．下面执行真正的恢复操作，重建数据库日志文件go dbcc
rebuild_log('pos','D:\Program
Files\Microsoft
SQL
Server\MSSQL\Data\pos_log.ldf') go
--执行过程中，如果遇到下列提示信息：
--服务器: 消息5030，级别16，状态1，行1 --未能排它地锁定数据库以执行该操作。
--DBCC 执行完毕。如果DBCC 输出了错误信息，请与系统管理员联系。
--说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了pos库的系统表，那么退出SQL Server Enterprise Manager就可以了。--正确执行完成的提示应该类似于：
--警告: 数据库'pos' 的日志已重建。已失去事务的一致性。应运行DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
--DBCC 执行完毕。如果DBCC 输出了错误信息，请与系统管理员联系。
--此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
--8．验证数据库一致性（可省略）go
dbcc checkdb('pos') --一般执行结果如下：
--CHECKDB 发现了0 个分配错误和0 个一致性错误（在数据库'pos' 中）。
--DBCC 执行完毕。如果DBCC 输出了错误信息，请与系统管理员联系。
--9．设置数据库为正常状态go
exec sp_dboption 'pos','dbo use only','false' go
--如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
--10．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
exec sp_configure 'allow updates',0 go
reconfigure with override go
本文来自sql数据库修复大师https://www.doczj.com/doc/b71336165.html,/soft/57122.html