SQL SERVER DBCC命令解释

SQL SERVER DBCC命令解释
――――――――――――――
�C1 dbcc trraceon DBCC TRACEOFF
�C对于数据库死锁，通常可以通过TRACE FLAG 1204、1205、1206，检查ERRORLOG里面的输出，和分析SQLTRACE的执行上下文判断死锁问题的来由。
�CTRACEON函数的第三个参数设置为-1，表示不单单针对当前connection，
�C而是针对所有包括未来建立的connection。这样，才够完全，否则只是监视当前已经建立的数据库连接了。
�C执行下面的话可以把死锁记录到Errorlog中：
dbcc traceon (1204, 3605, -1)
go
dbcc tracestatus(-1)
go

�C说明：
�C260：打印关于扩展存储过程动态链接库的版本信息
�C444：停止auto-parameterization
�C1200：输出锁信息
�C1204：传回参与死锁的SQL SERVER相关程序之运行数据
�C1211：停止lock escalation（锁升级）
�C1252：显示动态选择锁的相关信息
�C2528：通过 DBCC CHECKDB、DBCC CHECKFILEGROUP 和 DBCC CHECKTABLE 禁用对象的并行检查。
�C默认情况下，并行度由查询处理器自动确定。最大并行度的配置方式与并行查询相同。
�C有关更多信息，请参见 max degree of parallelism 选项。
�C 通常情况下，应将并行 DBCC 保留为启用状态。执行 DBCC CHECKDB 时，
�C 查询处理器重新评估和自动调整并行度，并检查每个表或一批表。
�C有时，检查可能在服务器处于实际空闲状态时进行。如果管理员知道在检查结束前负荷将加大，
�C可能希望手工减小或禁用并行度。
�C 但是，禁用并行检查会导致数据库的总体性能降低。降低并行度将增加必须扫描的事务日志量。
�C这反过来增加了对 tempdb 空间的需求，并导致 dbcc 完成检查所需的时间非线性增加。
�C如果运行 DBCC 时启用了 TABLOCK 功能并关闭了并行度，则表可能被锁定更长时间。
�C3205：默认情况下，如果磁带驱动器支持硬件压缩，则 DUMP 或 BACKUP 语句会使用该功能。
�C 利用此跟踪标记，可以禁用磁带驱动程序的硬件压缩。
�C 本项在要与不支持压缩的其它站点或磁带驱动器交换磁带时有用。
�C3604：将trace结果输出到前端
�C3605：要求DBCC的输出放到SQL server ERROR LOG
�C8602：停止索引提示功能
�C8722：停止join group等最优化提示功能
�C8755：停止锁提示功能
�C8780：停止最优化超时配置，强制做完整的最优化动作
――――――――――――――――――
�C2 DBCC page
dbcc traceon(3604)
dbcc page(northwind,1,100,1)
/*查询northwind 的数据的第101个页面的信息*/
/*DBCC Page ({dbid|dbname},filenum,pagenum[,printopt])
?
具体参数描述如下：
dbid: 包含页面的数据库ID
dbname:包含页面的数据库的名称
filenum:包含页面的文件编号
pagenum:文件内的页面
printopt:可选的输出选项；选用其中一个值：
0:默认值，输出缓冲区的标题和页面标题
1:输出缓冲区的标题、页面标题(分别输出每一行)，以及行偏移量表
2:输出缓冲区的标题、页面标题(整体输出页面)，以及行偏移量表
3:输出缓冲区的标题、页面标题(分别输出每一行)，以及行偏移量表；每一行后跟分别列出的它的列值
*/
――――――――――――――――――
�C3 DBCC checkalloc
DBCC checkalloc（northwind)
/*检查指定数据库的系统表内和表间的一致性
checkalloc是检查指定数据库，看其所有正确分配的页和尚未分配的页的情况。
若未指定数据库名，则checkalloc检查当前数据库。checkalloc会返回已分配的和使用的空间数量。
checkalloc的缺省模式为nofix，要使用fix选项，必须把数据库置于单用户模式。
*/
―――――――――――――――――�C
�C4 DBCC checkcatalog
DBCC checkcatalog(northwind)
/*
检查批定数据库的系统表内和系统表间的一致性
*/
―――――――――――――――――�C
�C5 DBCC checkconstraints
DBCC checkconstraints(products)
/*
检查指定表上的指定约束或所有约束的完整性
DBCC CHECKCONSTRAINTS
[('table_name'|'constraint_name'
)]
[WITH {ALL_ERRORMSGS|ALL_CONSTRAINTS}]
DBCC CHECKCONSTRAINTS在某个数据库中，检测某些特定的约束或者全部约束的一致性。
DBCC CHECKCONSTRAINTS总是在当前数据库的上下文环境中执行。
　　注意，DBCC CHECKCONSTRAINTS并不进行磁盘或者文件级别的一致性检测;
它只是确保外键定义的一致性，同时检测约束――仅仅是确认数据有效。
如果你希望检测磁盘上表和索引的一致性，
你应该执行DBCC CHECKDB或者在所有的表上执行DBCC CHECKALLOC和 DBCC CHECKTABLE的组合。
*/
――――――――――――――――――
�C6 DBCC checkdb
DBCC checkdb
/*
检查数据库中的所有对象的分配和结构完整性
checkdb [('database_name'[, NOINDEX | REPAIR])]
[WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY]
[, ESTIMATEONLY][, TABLOCK]]
*/
―――――――――――――――――�C
�C7 DBCC cleantable
DBCC cleantable
/*
回收alter table drop column语句 删除可变长度列或text列后的存储空间
cleantable (‘database_name’|database_id, ‘table_name’|table_id, [batch_size])
*/
―――――――――――――――――�C
�C8 DBCC dbreindex
DBCC dbreindex
/*
重建指定数据库的一个或多个索引
dbreindex (‘table_name’ [, index_name [, fillfactor ]]) [WITH NO_INFOMSGS]
*/
―――――――――――――――――�C
�C9 DBCC indexdefrag
DBCC indexdefrag
/*
对表或视图上的索引和非聚集索引进行碎片整理
indexdefrag ({dbid | dbname | 0}, {tableid | tablename}, {indid | indname})
*/

在小规模环境下，DBCC INDEXDEFRAG的结果比DBCC DBREINDEX要好一些。不过，在大多数情况下，完全重建索引应该具有更好的性能。
当DBCC INDEXDEFRAG运行在一个动态的系统上，即数据保持在线更新，DBCC INDEXDEFRAG会跳过那些被锁住的页。因此DBCC INDEXDEFRAG也许就无法完全消除碎片。要衡量DBCC INDEXDEFRAG发挥了多大作用，可以在DBCC INDEXDEFRAG后立刻运行DBCC SHOWCONTIG。
DBCC DBREINDEX完全重建索引

――――――――――――――――――�C
�C10 DBCC pintable/DBCC unpintable
�C将表数据驻留在内存中或撤销驻留 在内存中的数据
�Cpintable (database_id, table_id)
―――――――――――――――――――-
�C11 DBCC shrinkdatabase
�C收缩指定数据库的数据文件和日志文件大小
�Cshrinkdatabase ({dbid | ‘dbname’}, [freespace_percentage [, {NOTRUNCATE | TRUNCATEONLY}]])
―――――――――――――――――――-
�C12 DBCC shrinkfile
�C收缩相关数据库的指定数据文件和日志文件大小
�Cshrinkfile ({fileid | ‘filename’}, [compress_size [, {NOTRUNCATE | TRUNCATEONLY | EMPTYFILE}]])
――――――――――――――――――――
�C13 DBCC dllname(free)
�C在内存中制裁指定的扩展想念过程动态链接库（DLL）
sp_helpextended proc
�C查询当前内存中的扩展存储过程动态链接库
――――――――――――――――――――-
�C14 DBCC dropcleanbuffers
�C从缓冲池中删除所有缓冲区
/*
使用 DBCC DROPCLEANBUFFERS 测试带有冷高速缓存的查询，而不用关闭和重新启动服务器
*/
―――――――――――――――――――――
�C15 DBCC freeproccache
�C从过程缓冲区删除所有元素
�C清理所有数据库的过程高速缓存
―――――――――――――――――――――�C
�C16 DBCC inputButter
�C显示从客户机发送到服务器的最后一个语句
――――――――――――――――――――-
�C17 DBCC opentran
�C查询某个数据库执行时间最久的事务，由哪个程序拥有
―――――――――――――――――――――-
�C18 DBCC show_statistics
�C显示指定表上的指定目前的当前分布统计信息
――――――――――――――――――――――
�C19 DBCC showcontig
�C显示指定表的数据和索引的碎片信息
―――――――――――――――――――――�C
�C20 DBCC sqlperf
�C可用参数logspace,iostats,threads
�C返回多种有用的统计信息
―dbcc sqlperf(logspace)
Database Name Log Size (MB) Log Space Used (%) Status
――――――――――――――――――――――――――――――――――――――――――�C ―――――――― ―――――――― ―――�C
master 5.0546875 27.93663 0
tempdb 0.7421875 58.88158 0
model 0.4921875 74.206352 0
msdb 2.2421875 38.414635 0
pubs 0.7421875 43.947369 0
Northwind 0.9921875 41.732285 0
db40cdr 32.304688 6.3618503 0
fcdb 218.30469 79.981796 0
fcdb_20070826 19.992188 3.0138726 0
test 176.92969 6.4423542 0
kldb 0.9921875 33.267715 0
�Cdbcc sqlperf(iostats)
Statistic Value
――――――――――�C ――――――――
Reads Outstanding 0.0
Writes Outstanding 0.0
�Cdbcc sqlperf(threads)
Spid Thread ID Status LoginName IO CPU MemUsage
―― ―――�C ―――- ―――- ―――――――- ―――�C ―――�C
1 NULL background NULL 0 0 0
2 NULL background NULL 0 0 5
3 NULL sleeping NULL 0 0 0
4 NULL background NULL 0 0 -6
5 0 background sa 41 0 3
6 NULL sleeping NULL 1 0 0
7 0 background sa 0 0 3
8 0 background sa 0 0 3
9 0 background sa 0 0 3
10 0 background sa 0 0 3
11 0 background sa 0 0 3
12 0 background sa 0 0 3
51 0 sleeping RD-001\Adm 19 32 29
52 0 sleeping RD-001\Adm 6 515 15
53 3828 runnable RD-001\Adm 1 15 5
――――――――――――――――――――――
�C21 DBCC cachestats
�C显示SQL SERVER内存的统计信息
―――――――――――――――――――――�C
�C22 DBCC cursorstats
�C显示SQL SERVER游标的统计信息
――――――――――――――――――――――
�C23 DBCC sqlmgrstats
�C显示缓冲中先读和预先准备的SQL语句
――――――――――――――――――――
�C24 DBCC errlog
�C初始化SQL SERVER错误日志文件
―――――――――――――――――――-
�C25 DBCC flushprocindb
�C清除SQL SERVER服务器内存中某个数据库的存储过程缓存内容
―――――――――――――――――――-
�C26 DBCC Buffer
�C显示缓冲区的善信息和页面信息
――――――――――――――――――�C
�C27 DBCC DBinfo
�C显示数据库结构信息
――――――――――――――――――――
�C28 DBCC DBtable
�C显示管理数据的表信息
―――――――――――――――――――�C
�C29 DBCC IND
�C查看某个索引使用的页面信息
――――――――――――――――――――-
�C30 DBCC REbuild_log
�C重建SQL SERVER事务日志文件
――――――――――――――――――――
�C31 DBCC log
�C查看某个数据库使用的事务日志信息
―――――――――――――――――――�C
�C32 DBCC procbuf
�C显示过程缓冲池中的缓冲区头和存储过程头
――――――――――――――――――――
�C33 DBCC prtipage
�C查看某个索引页面的每行指向的页面号
――――――――――――――――――――
�C34 DBCC pss
�C显示当前连接到SQL SERVER的进程信息
―――――――――――――――――――�C
�C35 DBCC resource
�C显示服务器当前使用的资源情况
――――――――――――――――――――
�C36 DBCC tab
�C查看数据页面的结构
―――――――――――――――――――-

1. DBCC CHECKDB
　　重启服务器后，在没有进行任何操作的情况下，在SQL查询分析器中执行以下SQL进行数据库的修复，修复数据库存在的一致性错误与分配错误。

use master
declare @databasename varchar(255)
set @databasename=’需要修复的数据库实体的名称’
exec sp_dboption @databasename, N’single’, N’true’ �C将目标数据库置为单用户状态
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N’single’, N’false’�C将目标数据库置为多用户状态

然后执行 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’

―�C在查询分析器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’

�C 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。