sqlserver2000数据库修复实战经验DBCC

DBCC         

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_ONLY

　　PHYSICAL_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) points to the data row identified by ().

　　根据MSDN上的说明：
　　This problem does not cause any data or index corruption. The problem is in the metadata which is corrected only by

dropping and re-creating the indexes.
　　这些问题不会引起数据或索引的损坏，这些问题的元数据是正确的，只是删除再重新建立索引。
看来问题是修改了。

　　再次运行DBCC CHECKDB('POS_DB'),再次运行:DBCC CHECKDB('POS_DB'),message没有错误信息。

　　ok！成功修复:-)

　　4.检查修复后的数据库并且备份数据库
检查DBCC CHECKDB报错的相关表，和没有执行DBCC之前的记录数进行比较，发现有一个表少了40条记录。郁闷:-<

　　5.总结

　　1.RAID5并不能保证SQLSERVER 2000 数据库的数据文件的完整性；
　　2.SQLERVER 2000的备份程序不验证数据库文件的数据完整性；如果你的数据文件有问题，备份时也不图示；
　　3.DBCC CHECKDB的repair_allow_data_loss并不是非常安全的，不能修复所有的错误，即使是对不完整页（TORN PAGE）的修复也会着成数

据丢失；
　　4.DBCC CHECKDB的REPAIR_ALLOW_DATA_LOSS参数无法修复所有的错误;

　　参考文章:
　　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

文章出处：http://www.diybl.com/course/7_databases/sql/sqlServer/2007926/73889_2.html   

 

 

 

------------------------------------- 

 

 

在 Microsoft® SQL Server™ 2000 中，可以在用户使用数据库时运行 DBCC CHECKDB，因为 DBCC CHECKDB 在检查每个数据库表时在表上控制的锁的类型均更改。

在 SQL Server 7.0 和早期版本中，DBCC CHECKDB（依次在数据库的每个表上运行 DBCC CHECKTABLE 和 CHECKALLOC）常常在表上控制共享锁 (S)，因而阻塞了所有的数据修改语言 (DML) 语句。

在 SQL Server 2000 中，当检查表时 DBCC CHECKDB 在表上控制架构锁以防止元数据的更改，因而允许在正在检查的表上使用除任何数据定义语言 (DDL) 语句之外的 DML 语句。该变化对于决定何时运行 DBCC CHECKDB 提供了更大的灵活性，因为 DBCC CHECKDB 并不完全拒绝用户对系统的使用。

DBCC CHECKDB 是大量占用 CPU 和磁盘的操作。每一个需要检查的数据页都必须首先从磁盘读入内存。另外，DBCC CHECKDB 使用 tempdb 排序。

如果在 DBCC CHECKDB 运行时动态执行事务，那么事务日志会继续增长，因为 DBCC 命令在完成日志的读取之前阻塞日志截断。

建议在服务器负荷较少的时候运行 DBCC CHECKDB。如果在负荷高峰期运行 DBCC CHECKDB，那么事务吞吐量性能和 DBCC CHECKDB 完成时间性能都会受到影响。

要获得好的 DBCC 性能的一些建议

• 在系统使用率较低时运行 CHECKDB。
  
  
• 请确保未同时执行其它磁盘 I/O 操作，例如磁盘备份。
  
  
• 将 tempdb 放到单独的磁盘系统或快速磁盘子系统中。
  
  
• 允许 tempdb 在驱动器上有足够的扩展空间。使用带有 ESTIMATE ONLY 的 DBCC 估计 tempdb 将需要多少空间。
  
  
• 避免运行占用大量 CPU 的查询或批处理作业。
  
  
• 在 DBCC 命令运行时，减少活动事务。
  
  
• 使用 NO_INFOMSGS 选项显著减少处理和 tempdb 的使用。

考虑使用带有 PHYSICAL_ONLY 选项的 DBCC CHECKDB 来检查页和记录首部的物理结构。当硬件导致的错误被置疑时，这个操作将执行快速检查。

SQL2000数据修复命令DBCC用法

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 (表名,’’) 修复此表所有的索引。

4.DBCC SHRINKFILE (设备文件名或id, 目标大小)

DBCC SHRINKFILE (tempdev, 200)
收缩数据库文件tempdev到200MB
DBCC SHRINKFILE (templog, 100)
收缩数据库文件templog到100MB

清除日志文件
backup log 数据库名 with NO_LOG
dbcc shrinkDatabase(数据库名)

例：将tempdb文件设定大小为50M：
USE tempdb
DBCC SHRINKFILE(tempdb,50)

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-606920/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-606920/