SQL SERVER DBCC命令解释

SQL SERVER DBCC命令解释

八点钟起床一直搞到现在 好多还不太记得 先放上来以后慢慢修改

dbcc trraceon DBCC TRACEOFF

对于数据库死锁 通常可以通过TRACE FLAG 检查ERRORLOG里面的输出 和分析SQLTRACE的执行上下文判断死锁问题的来由

TRACEON函数的第三个参数设置为 表示不单单针对当前connection

而是针对所有包括未来建立的connection 这样 才够完全 否则只是监视当前已经建立的数据库连接了

执行下面的话可以把死锁记录到Errorlog中

dbcc traceon ( )

go

dbcc tracestatus( )

go

说明

打印关于扩展存储过程动态链接库的版本信息

停止auto parameterization

输出锁信息

传回参与死锁的SQL SERVER相关程序之运行数据

停止lock escalation(锁升级)

显示动态选择锁的相关信息

通过 DBCC CHECKDB DBCC CHECKFILEGROUP 和 DBCC CHECKTABLE 禁用对象的并行检查

默认情况下 并行度由查询处理器自动确定 最大并行度的配置方式与并行查询相同

有关更多信息 请参见 max degree of paralleli *** 选项

通常情况下 应将并行 DBCC 保留为启用状态 执行 DBCC CHECKDB 时

查询处理器重新评估和自动调整并行度 并检查每个表或一批表

有时 检查可能在服务器处于实际空闲状态时进行 如果管理员知道在检查结束前负荷将加大

可能希望手工减小或禁用并行度

但是 禁用并行检查会导致数据库的总体性能降低 降低并行度将增加必须扫描的事务日志量

这反过来增加了对 tempdb 空间的需求 并导致 dbcc 完成检查所需的时间非线性增加

如果运行 DBCC 时启用了 TABLOCK 功能并关闭了并行度 则表可能被锁定更长时间

默认情况下 如果磁带驱动器支持硬件压缩 则 DUMP 或 BACKUP 语句会使用该功能

利用此跟踪标记 可以禁用磁带驱动程序的硬件压缩

本项在要与不支持压缩的其它站点或磁带驱动器交换磁带时有用

将trace结果输出到前端

要求DBCC的输出放到SQL server ERROR LOG

停止索引提示功能

停止join group等最优化提示功能

停止锁提示功能

停止最优化超时配置 强制做完整的最优化动作

DBCC page

dbcc traceon( )

dbcc page(northwind )

/*查询northwind 的数据的第 个页面的信息*/

/*DBCC Page ({dbid|dbname} filenum pagenum[ printopt])

?

具体参数描述如下

dbid: 包含页面的数据库ID

dbname:包含页面的数据库的名称

filenum:包含页面的文件编号

pagenum:文件内的页面

printopt:可选的输出选项选用其中一个值

:默认值 输出缓冲区的标题和页面标题

:输出缓冲区的标题 页面标题(分别输出每一行) 以及行偏移量表

:输出缓冲区的标题 页面标题(整体输出页面) 以及行偏移量表

:输出缓冲区的标题 页面标题(分别输出每一行) 以及行偏移量表每一行后跟分别列出的它的列值

*/

DBCC checkalloc

DBCC checkalloc(northwind)

/*检查指定数据库的系统表内和表间的一致性

checkalloc是检查指定数据库 看其所有正确分配的页和尚未分配的页的情况

若未指定数据库名 则checkalloc检查当前数据库 checkalloc会返回已分配的和使用的空间数量

checkalloc的缺省模式为nofix 要使用fix选项 必须把数据库置于单用户模式

*/

DBCC checkcatalog

DBCC checkcatalog(northwind)

/*

检查批定数据库的系统表内和系统表间的一致性

*/

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的组合

*/

DBCC checkdb

DBCC checkdb

/*

检查数据库中的所有对象的分配和结构完整性

checkdb [( database_name [ NOINDEX | REPAIR])]

[WITH NO_INFOMSGS[ ALL_ERRORMSGS][ PHYSICAL_ONLY]

[ ESTIMATEONLY][ TABLOCK]]

*/

DBCC cleantable

DBCC cleantable

/*

回收alter table drop column语句 删除可变长度列或text列后的存储空间

cleantable ( database_name |database_id table_name |table_id [batch_size])

*/

DBCC dbreindex

DBCC dbreindex

/*

重建指定数据库的一个或多个索引

dbreindex ( table_name [ index_name [ fillfactor ]]) [WITH NO_INFOMSGS]

*/

DBCC indexdefrag

DBCC indexdefrag

/*

对表或视图上的索引和非聚集索引进行碎片整理

indexdefrag ({dbid | dbname | } {tableid | tablename} {indid | indname})

*/

DBCC pintable/DBCC unpintable

将表数据驻留在内存中或撤销驻留 在内存中的数据

pintable (database_id table_id)

DBCC shrinkdatabase

收缩指定数据库的数据文件和日志文件大小

shrinkdatabase ({dbid | dbname } [freespace_percentage [ {NOTRUNCATE | TRUNCATEONLY}]])

DBCC shrinkfile

收缩相关数据库的指定数据文件和日志文件大小

shrinkfile ({fileid | filename } [press_size [ {NOTRUNCATE | TRUNCATEONLY | EMPTYFILE}]])

DBCC dllname(free)

在内存中制裁指定的扩展想念过程动态链接库(DLL)

sp_helpextended proc

查询当前内存中的扩展存储过程动态链接库

DBCC dropcleanbuffers

从缓冲池中删除所有缓冲区

/*

使用 DBCC DROPCLEANBUFFERS 测试带有冷高速缓存的查询 而不用关闭和重新启动服务器

*/

DBCC freeproccache

从过程缓冲区删除所有元素

清理所有数据库的过程高速缓存

DBCC inputButter

显示从客户机发送到服务器的最后一个语句

DBCC opentran

查询某个数据库执行时间最久的事务 由哪个程序拥有

DBCC show_statistics

显示指定表上的指定目前的当前分布统计信息

DBCC showcontig

显示指定表的数据和索引的碎片信息

DBCC sqlperf

可用参数logspace iostats threads

返回多种有用的统计信息

dbcc sqlperf(logspace)

Database Name Log Size (MB) Log Space Used (%) Status

master

tempdb

model

msdb

pubs

Northwind

db cdr

fcdb

fcdb_

test

kldb

dbcc sqlperf(iostats)

Statistic Value

Reads Outstanding

Writes Outstanding

dbcc sqlperf(threads)

Spid Thread ID Status LoginName IO CPU MemUsage

NULL background NULL

NULL background NULL

NULL sleeping NULL

NULL background NULL

background sa

NULL sleeping NULL

background sa

background sa

background sa

background sa

background sa

background sa

sleeping RD Adm

sleeping RD Adm

runnable RD Adm

DBCC cachestats

显示SQL SERVER内存的统计信息

DBCC cursorstats

显示SQL SERVER游标的统计信息

DBCC sqlmgrstats

显示缓冲中先读和预先准备的SQL语句

DBCC errlog

初始化SQL SERVER错误日志文件

DBCC flushprocindb

清除SQL SERVER服务器内存中某个数据库的存储过程缓存内容

DBCC Buffer

显示缓冲区的善信息和页面信息

DBCC DBinfo

显示数据库结构信息

DBCC DBtable

显示管理数据的表信息

DBCC IND

查看某个索引使用的页面信息

DBCC REbuild_log

重建SQL SERVER事务日志文件

DBCC log

查看某个数据库使用的事务日志信息

DBCC procbuf

显示过程缓冲池中的缓冲区头和存储过程头

DBCC prtipage

查看某个索引页面的每行指向的页面号

DBCC pss

显示当前连接到SQL SERVER的进程信息

DBCC resource

显示服务器当前使用的资源情况

DBCC tab

lishixinzhi/Article/program/SQLServer/201311/22263

1、启动"SQLSERVERManagementStudio"登入进入主界面步骤阅读步骤阅读。

2、点击新建查询(N)，选择查询数据库步骤阅读在新建新建查询(N)输入SQL语句dbcccheckdb，点击执行(X)步骤阅读。

3、最后结果出来，发现没有错误，如果恢复后的数据库，为了确保能正常运行，先查询还是有必要的。

备份数据文件,然后按下面的步骤处理:

1.新建一个同名的数据库(数据文件与原来的要一致)

2.再停掉sql server(注意不要分离数据库)

3.用原数据库的数据文件覆盖掉这个新建的数据库

4.再重启sql server

5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)

6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用

数据库的脚本创建一个新的数据库,并将数据导进去就行了.

USE MASTER

GO

SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE

GO

UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'

Go

sp_dboption '置疑的数据库名', 'single user', 'true'

Go

DBCC CHECKDB('置疑的数据库名')

Go

update sysdatabases set status =28 where name='置疑的数据库名'

Go

sp_configure 'allow updates', 0 reconfigure with override

Go

sp_dboption '置疑的数据库名', 'single user', 'false

假设数据库为TEST：

按以下步骤执行

A．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

B．设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

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

C．下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')

执行过程中，如果遇到下列提示信息：

服务器: 消息 5030，级别 16，状态 1，行 1

未能排它地锁定数据库以执行该 *** 作。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

正确执行完成的提示应该类似于：

警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

D．验证数据库一致性（可省略）

dbcc checkdb('test')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

E．设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

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

F．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成

sp_configure 'allow updates',0

go

reconfigure with override

go

上面的语句 *** 作步骤有点问题：

应该如下：

A．我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。

B．停掉数据库服务器。

C．将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。

D．启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。

E．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

F．设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

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

G．下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')

执行过程中，如果遇到下列提示信息：

服务器: 消息 5030，级别 16，状态 1，行 1

未能排它地锁定数据库以执行该 *** 作。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

正确执行完成的提示应该类似于：

警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

H．验证数据库一致性（可省略）

dbcc checkdb('test')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

I．设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

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

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

sp_configure 'allow updates',0

go

reconfigure with override

go

---