现在的位置: 首页 > 综合 > 正文

MS Sql Server 数据库或表修复(Log日志文件损坏的修复方法)

2014年08月06日 ⁄ 综合 ⁄ 共 7907字 ⁄ 字号 评论关闭

----------------- 【1】
use master
go 
sp_configure 'allow updates',1
reconfigure with override
go 
----------------- 【2】
update sysdatabases set status=-32768 where dbid=DB_ID('zc_post')
----------------- 【3】
dbcc rebuild_log('zc_post','d:\zc_post_log.ldg')

----------------- 【4】
dbcc checkdb('zc_post')

----------------- 【5】
sp_dboption 'zc_post','dbo use only','false'
----------------- 【6】
sp_configure 'allow updates',0
go 
reconfigure with override
go


============================================================ 【详细方法】

[转]sql server 2000,Log.LDF文件丢失,附加数据库失败的解决办法

关键词:SQL Server数据库文件恢复技术 SQL 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_db
-SQL
s_attach_db [@dbname =] ′dbname′, [@filename1 =] ′filename_n′ [,...16]
sp_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。下面我们讨论一下如何备份、恢复该数据库。
卸下数据库:
-SQL
sp_detach_db 'test'

连接数据库:
-SQL
sp_attach_db 'test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf'
sp_attach_single_file_db 'test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf'


2、只有mdf文件的恢复技术
  由于种种原因,我们如果当时仅仅备份了mdf文件,那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的,那么很侥幸,也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库,但是会出现类似下面的提示信息
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。

sql server 2000,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里面“工具-》SQL Server配置属性”,在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
-SQL
use master
go
sp_configure 'allow updates',1
go 
reconfigure with override
go


  F.设置test为紧急修复模式
-SQL
update sysdatabases set status=-32768 where dbid=DB_ID('test')

此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表,但是仅仅有系统表

  G.下面执行真正的恢复操作,重建数据库日志文件
-SQL
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')

执行过程中,如果遇到下列提示信息:
服务器: 消息 5030,级别 16,状态 1,行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。[brown]
  说明您的其他程序正在使用该数据库,如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表,那么退出SQL Server Enterprise Manager就可以了。
  正确执行完成的提示应该类似于:
警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项,并且可能需要删除多余的日志文件。
  DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

  H.验证数据库一致性(可省略)
-SQL
dbcc checkdb('test')

一般执行结果如下:
CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 'test' 中)。
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

  I.设置数据库为正常状态
-SQL
sp_dboption 'test','dbo use only','false'

  如果没有出错,那么恭喜,现在就可以正常的使用恢复后的数据库啦。

  J.最后一步,我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然,我们可以在SQL Server Enterprise Manager里面恢复,也可以使用如下语句完成
-SQL
sp_configure 'allow updates',0
go 
reconfigure with override
go






====================================================================

MS Sql Server 数据库或表修复(DBCC CHECKDB)

MS 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数据库的检测及修复方法 
随着K/3产品的推广,要求客户服务人员对SQL SERVER数据库的了解也进一步提高。在K/3的使用过程中,数据库文件被频繁地使用,由于某些原因,数据库有可能被损坏,本文将针对这种情况的数据库检测及修复方法做一简单讲解。希望各位在实际工作过程中有新的发现时,及时给我们提供信息,以便做进一步的更新。 
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)来修复。 
另外一种情况是在进行检测时,提示无法建立数据连接,此时表明,数据库已损坏。对于这种情况,我们可采取如下措施来尝试修复。 
首先,在SQL Enterprise中新建一数据库(如数据库名为test),建好数据库后,停止SQL Server Service Manager,并将客户数据库的MDF文件更名为test _data.mdf(即新建数据库的主文件名),然后用更名后的文件覆盖新建数据库同名文件,接着,启动SQL Server Service Manager。对Master数据库将系统表设置为可更改状态 
Use Master 
Go 
sp_configure 'allow updates', 1 
reconfigure with override 
Go 
将数据库设为紧急状态: 
update sysdatabases set status = 32768 where database ' 
停止并重新启动SQL Server Service Manager,并重建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章数据库日志损坏的修复 
请遵照如下步骤来试图重建数据库事务日志.

注意: 由于事务日志丢失, 数据库可能有没有提交的数据.

注:都要替换成真实的数据库名字

2.1 步骤1:

创建一个新的数据库,命名为原来数据库的名字.

2.2步骤2:

停止SQL Server

2.3步骤3:

把老数据库的MDF文件替换新数据库的相应的MDF文件, 并把LDF文件删除

2.4步骤4:

重新启动SQL Server 服务,然后运行如下命令:

Use Master

Go

sp_configure 'allow updates', 1

reconfigure with override

Go

begin tran

update sysdatabases set status = 32768 where db_name'

-- Verify one row is updated before committing

commit tran

2.5步骤5:

停止SQL然后重新启动SQL Server 服务,然后运行如下命令:

DBCC TRACEON (3604)

DBCC REBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF')

Go

2.6步骤6:

停止SQL然后重新启动SQL Server 服务,然后运行:

use master

update sysdatabases set status = 8 where 
Go

sp_configure 'allow updates', 0

reconfigure with override

Go

2.7步骤7: 
运行dbcc checkdb(db_name)检查数据库的完整性.

第3章 数据库质疑的一般处理 
1、执行如下SQL(打开修改系统表的开关): 
EXEC sp_configure 'allow updates', 1 
RECONFIGURE WITH OVERRIDE 
2、修改数据库Master中的表:sysdatabases 
将 status字段数值更改为4 
3、再执行如下SQL: 
EXEC sp_configure 'allow updates', 0 
RECONFIGURE WITH OVERRIDE。

转自:曾伟的博客 | DBCC CHECKDB 数据库或表修复

原文地址:http://www.cnblogs.com/zengwei/archive/2009/09/18/1569376.html

抱歉!评论已关闭.