SQL SERVER DBCC命令解释

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。

  • 本文链接地址:http://www.dbainfo.net/sql-server-dbcc-synta.htm
  • 本文为dbainfo个人原创,请在尊重作者劳动成果的前提下进行转载;
  • 转载务必注明原始出处 : Sybase数据库技术,数据库恢复专家
  • 对《SQL SERVER DBCC命令解释》有何疑问或见解,请在本文下方发表;
  • 对网站还有其他问题或建议,请提交在留言板,谢谢!
  • 目前还没有任何评论.
    :wink: :twisted: :roll: :oops: :mrgreen: :lol: :idea: :evil: :cry: :arrow: :?: :-| :-x :-o :-P :-D :-? :) :( :!: 8-O 8)