SQL SERVER DBCC命令解释
——————————————
–1 dbcc trraceon DBCC TRACEOFF
–对于数据库死锁，通常可以通过TRACE FLAG 1204、1205、1206，检查ERRORLOG里面的输出，和分析SQLTRACE的执行上下文判断死锁问题的来由。
–TRACEON函数的第三个参数设置为-1，表示不单单针对当前connection，
–而是针对所有包括未来建立的connection。这样，才够完全，否则只是监视当前已经建立的数据库连接了。
–执行下面的话可以把死锁记录到Errorlog中：
dbcc traceon (1204, 3605, -1)
go
dbcc tracestatus(-1)
go
–说明：
–260：打印关于扩展存储过程动态链接库的版本信息
–444：停止auto-parameterization
–1200：输出锁信息
–1204：传回参与死锁的SQL SERVER相关程序之运行数据
–1211：停止lock escalation（锁升级）
–1252：显示动态选择锁的相关信息
–2528：通过 DBCC CHECKDB、DBCC CHECKFILEGROUP 和 DBCC CHECKTABLE 禁用对象的并行检查。
–默认情况下，并行度由查询处理器自动确定。最大并行度的配置方式与并行查询相同。
–有关更多信息，请参见 max degree of parallelism 选项。
– 通常情况下，应将并行 DBCC 保留为启用状态。执行 DBCC CHECKDB 时，
– 查询处理器重新评估和自动调整并行度，并检查每个表或一批表。
–有时，检查可能在服务器处于实际空闲状态时进行。如果管理员知道在检查结束前负荷将加大，
–可能希望手工减小或禁用并行度。
– 但是，禁用并行检查会导致数据库的总体性能降低。降低并行度将增加必须扫描的事务日志量。
–这反过来增加了对 tempdb 空间的需求，并导致 dbcc 完成检查所需的时间非线性增加。
–如果运行 DBCC 时启用了 TABLOCK 功能并关闭了并行度，则表可能被锁定更长时间。
–3205：默认情况下，如果磁带驱动器支持硬件压缩，则 DUMP 或 BACKUP 语句会使用该功能。
– 利用此跟踪标记，可以禁用磁带驱动程序的硬件压缩。
– 本项在要与不支持压缩的其它站点或磁带驱动器交换磁带时有用。
–3604：将trace结果输出到前端
–3605：要求DBCC的输出放到SQL server ERROR LOG
–8602：停止索引提示功能
–8722：停止join group等最优化提示功能
–8755：停止锁提示功能
–8780：停止最优化超时配置，强制做完整的最优化动作
——————————————————
–2 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:输出缓冲区的标题、页面标题(分别输出每一行)，以及行偏移量表；每一行后跟分别列出的它的列值
*/
——————————————————
–3 DBCC checkalloc
DBCC checkalloc（northwind)
/*检查指定数据库的系统表内和表间的一致性
checkalloc是检查指定数据库，看其所有正确分配的页和尚未分配的页的情况。
若未指定数据库名，则checkalloc检查当前数据库。checkalloc会返回已分配的和使用的空间数量。
checkalloc的缺省模式为nofix，要使用fix选项，必须把数据库置于单用户模式。
*/
—————————————————–
–4 DBCC checkcatalog
DBCC checkcatalog(northwind)
/*
检查批定数据库的系统表内和系统表间的一致性
*/
—————————————————–
–5 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的组合。
*/
——————————————————
–6 DBCC checkdb
DBCC checkdb
/*
检查数据库中的所有对象的分配和结构完整性
checkdb [('database_name'[, NOINDEX | REPAIR])]
[WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY]
[, ESTIMATEONLY][, TABLOCK]]
*/
—————————————————–
–7 DBCC cleantable
DBCC cleantable
/*
回收alter table drop column语句 删除可变长度列或text列后的存储空间
cleantable (‘database_name’|database_id, ‘table_name’|table_id, [batch_size])
*/
—————————————————–
–8 DBCC dbreindex
DBCC dbreindex
/*
重建指定数据库的一个或多个索引
dbreindex (‘table_name’ [, index_name [, fillfactor ]]) [WITH NO_INFOMSGS]
*/
—————————————————–
–9 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完全重建索引
——————————————————–
–10 DBCC pintable/DBCC unpintable
–将表数据驻留在内存中或撤销驻留 在内存中的数据
–pintable (database_id, table_id)
———————————————————-
–11 DBCC shrinkdatabase
–收缩指定数据库的数据文件和日志文件大小
–shrinkdatabase ({dbid | ‘dbname’}, [freespace_percentage [, {NOTRUNCATE | TRUNCATEONLY}]])
———————————————————-
–12 DBCC shrinkfile
–收缩相关数据库的指定数据文件和日志文件大小
–shrinkfile ({fileid | ‘filename’}, [compress_size [, {NOTRUNCATE | TRUNCATEONLY | EMPTYFILE}]])
————————————————————
–13 DBCC dllname(free)
–在内存中制裁指定的扩展想念过程动态链接库（DLL）
sp_helpextended proc
–查询当前内存中的扩展存储过程动态链接库
————————————————————-
–14 DBCC dropcleanbuffers
–从缓冲池中删除所有缓冲区
/*
使用 DBCC DROPCLEANBUFFERS 测试带有冷高速缓存的查询，而不用关闭和重新启动服务器
*/
—————————————————————
–15 DBCC freeproccache
–从过程缓冲区删除所有元素
–清理所有数据库的过程高速缓存
—————————————————————–
–16 DBCC inputButter
–显示从客户机发送到服务器的最后一个语句
————————————————————-
–17 DBCC opentran
–查询某个数据库执行时间最久的事务，由哪个程序拥有
—————————————————————-
–18 DBCC show_statistics
–显示指定表上的指定目前的当前分布统计信息
——————————————————————
–19 DBCC showcontig
–显示指定表的数据和索引的碎片信息
—————————————————————–
–20 DBCC sqlperf
–可用参数logspace,iostats,threads
–返回多种有用的统计信息
—dbcc sqlperf(logspace)
Database Name Log Size (MB) Log Space Used (%) Status
——————————————————————————————————————————– ———————— ———————— ———–
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
–dbcc sqlperf(iostats)
Statistic Value
——————————– ————————
Reads Outstanding 0.0
Writes Outstanding 0.0
–dbcc sqlperf(threads)
Spid Thread ID Status LoginName IO CPU MemUsage
—— ———– ———- ———- ———————- ———– ———–
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
——————————————————————
–21 DBCC cachestats
–显示SQL SERVER内存的统计信息
—————————————————————–
–22 DBCC cursorstats
–显示SQL SERVER游标的统计信息
——————————————————————
–23 DBCC sqlmgrstats
–显示缓冲中先读和预先准备的SQL语句
————————————————————
–24 DBCC errlog
–初始化SQL SERVER错误日志文件
———————————————————-
–25 DBCC flushprocindb
–清除SQL SERVER服务器内存中某个数据库的存储过程缓存内容
———————————————————-
–26 DBCC Buffer
–显示缓冲区的善信息和页面信息
——————————————————–
–27 DBCC DBinfo
–显示数据库结构信息
————————————————————
–28 DBCC DBtable
–显示管理数据的表信息
———————————————————–
–29 DBCC IND
–查看某个索引使用的页面信息
————————————————————-
–30 DBCC REbuild_log
–重建SQL SERVER事务日志文件
————————————————————
–31 DBCC log
–查看某个数据库使用的事务日志信息
———————————————————–
–32 DBCC procbuf
–显示过程缓冲池中的缓冲区头和存储过程头
————————————————————
–33 DBCC prtipage
–查看某个索引页面的每行指向的页面号
————————————————————
–34 DBCC pss
–显示当前连接到SQL SERVER的进程信息
———————————————————–
–35 DBCC resource
–显示服务器当前使用的资源情况
————————————————————
–36 DBCC tab
–查看数据页面的结构
———————————————————-
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。