请教如何使用DBCC命令修复数据库的相关推荐

1.停止SQL Server的服务,备份SQL Server安装目录下的\data子目录下故障数据库的两个文件,一个数据文件hbposv6_branch_data.mdf, 一个hbposv6_branch_log.ldf(也有可能非此命名),同时查看磁盘空间是否有足够的空间； 2.启动SQL Server服务(如已停止),创建一个新的数据库，命名为原来数据库的名字。 3.停止SQL Server 4.把老数据库的MDF文件(hbposv6_branch_data.mdf)替换新数据库的相应的MDF文件，并把LDF文件(hbposv6_branch_log.ldg)删除。 5.重新启动SQL Server服务，然后运行如下命令： Use Master go sp_configure 'allow updates', 1 reconfigure with override go begin tran update sysdatabases set status = 32768 where name = 'hbposv6_branch' --Verify one row is updated before committing commit tran go 6.停止SQL然后重新启动SQL Server服务，然后运行如下命令 (更换日志文件路径地址)： use master go DBCC TRACEON(3604) DBCC REBUILD_LOG ('hbposv6_branch', 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\hbposv6_branch_log.ldf') --在这里，请输入你的数据库的路径 go 7.停止SQL然后重新启动SQL Server服务，然后运行： use master go update sysdatabases set status = 8 where name = 'hbposv6_branch' go sp_configure 'allow updates', 0 reconfigure with override go 8.运行dbcc checkdb(db_name) 检查数据库的完整性 9.修复数库 --请在查询分析器中执行下列语句.执行前断开其它所有数据库连接，最好是断开网线 --如果不是该数据库名，请将数据库 --hbposv6_branch --改为要修复的数据库 USE master Go --单用户模式 EXEC sp_dboption 'hbposv6_branch', 'single user', 'TRUE' go --数据库检查 DBCC CHECKDB ('hbposv6_branch') Go --如果返回结果出现了红色的提示文字，说明数据库中存在错误，需要修复 --数据库修复 DBCC CHECKDB ('hbposv6_branch','repair_rebuild') Go --再次数据库检查，如果返回结果中没有了红色的提示文字，说明修复成功； DBCC CHECKDB ('hbposv6_branch') Go --否则意味着还需要更高级别的修复；尝试将上面修复语句的 'repair_rebuild'换为'repair_allow_data_loss'再试，之后再次检查数据库。 --如果还有错误未修复，请把这些信息以文字的方式发给我们 --退出前请一定要执行以下语句返回到多用户模式 EXEC sp_dboption 'hbposv6_branch', 'single user','FALSE' go 注：都要把 dbname 替换成真实的数据库名字。

很多时候你或者因为性能问题而使用表分区技术，将一些数据放到不同的分区，而这些数据实际上是被逻辑的放到不同的文件组里

大家知道：不管是索引还是数据，文件组都是这些索引和数据存放的最小逻辑单位

文件组是文件的命名集合，用于简化数据存放和管理任务（例如，备份和还原 *** 作，文件组备份和文件组还原）

MSDN 使用文件和文件组 ：http://msdn.microsoft.com/zh-cn/library/ms187087(v=sql.90).aspx

那么假如我有一个表使用了表分区技术，如下图

表中索引和数据放在这3个文件组中，其中历史数据/归档数据放在文件组1，索引放在文件组2，当前数据放在文件组3

当然，真实环境中的大型数据库会有更多的文件组用来存放不同的历史数据和索引！！

对于使用了分区表机制的数据库，对于存储历史数据的分区文件组，由于数据本身已经不会发生修改，我们可以把文件组类型设成只读模式，

防止任何误修改。

步骤一：

我们可以对文件组1进行一次DBCC CHECKFILEGROUP检查，如果没有错误，就将文件组1设置为只读，

这样以后就不用再执行DBCC CHECKFILEGROUP检查了，因为文件组1是只读的，不会再对它进行修改

我们使用下面SQL语句检查文件组1是否有错误

1 USE [partionTest]2 GO3 DBCC CHECKFILEGROUP(1)4 GO

1 partionTest的 DBCC 结果。 2 sys.sysrowsetcolumns的 DBCC 结果。 3 对象 'sys.sysrowsetcolumns' 的 5 页中有 552 行。 4 sys.sysrowsets的 DBCC 结果。 5 对象 'sys.sysrowsets' 的 1 页中有 84 行。 6 sysallocunits的 DBCC 结果。 7 对象 'sysallocunits' 的 1 页中有 95 行。 8 sys.sysfiles1的 DBCC 结果。 9 对象 'sys.sysfiles1' 的 1 页中有 6 行。10 sys.syshobtcolumns的 DBCC 结果。11 对象 'sys.syshobtcolumns' 的 5 页中有 552 行。12 sys.syshobts的 DBCC 结果。13 对象 'sys.syshobts' 的 1 页中有 84 行。14 sys.sysftinds的 DBCC 结果。15 对象 'sys.sysftinds' 的 0 页中有 0 行。16 sys.sysserefs的 DBCC 结果。17 对象 'sys.sysserefs' 的 1 页中有 95 行。18 sys.sysowners的 DBCC 结果。19 对象 'sys.sysowners' 的 1 页中有 14 行。20 sys.sysprivs的 DBCC 结果。21 对象 'sys.sysprivs' 的 1 页中有 120 行。22 sys.sysschobjs的 DBCC 结果。23 对象 'sys.sysschobjs' 的 1 页中有 50 行。24 sys.syscolpars的 DBCC 结果。25 对象 'sys.syscolpars' 的 7 页中有 424 行。26 sys.sysnsobjs的 DBCC 结果。27 对象 'sys.sysnsobjs' 的 1 页中有 1 行。28 sys.syscerts的 DBCC 结果。29 对象 'sys.syscerts' 的 0 页中有 0 行。30 sys.sysxprops的 DBCC 结果。31 对象 'sys.sysxprops' 的 0 页中有 0 行。32 sys.sysscalartypes的 DBCC 结果。33 对象 'sys.sysscalartypes' 的 1 页中有 27 行。34 sys.systypedsubobjs的 DBCC 结果。35 对象 'sys.systypedsubobjs' 的 1 页中有 1 行。36 sys.sysidxstats的 DBCC 结果。37 对象 'sys.sysidxstats' 的 2 页中有 151 行。38 sys.sysiscols的 DBCC 结果。39 对象 'sys.sysiscols' 的 2 页中有 263 行。40 sys.sysbinobjs的 DBCC 结果。41 对象 'sys.sysbinobjs' 的 1 页中有 23 行。42 sys.sysobjvalues的 DBCC 结果。43 对象 'sys.sysobjvalues' 的 24 页中有 151 行。44 sys.sysclsobjs的 DBCC 结果。45 对象 'sys.sysclsobjs' 的 1 页中有 20 行。46 sys.sysrowsetrefs的 DBCC 结果。47 对象 'sys.sysrowsetrefs' 的 1 页中有 4 行。48 sys.sysremsvcbinds的 DBCC 结果。49 对象 'sys.sysremsvcbinds' 的 0 页中有 0 行。50 sys.sysxmitqueue的 DBCC 结果。51 对象 'sys.sysxmitqueue' 的 0 页中有 0 行。52 sys.sysrts的 DBCC 结果。53 对象 'sys.sysrts' 的 1 页中有 1 行。54 sys.sysconvgroup的 DBCC 结果。55 对象 'sys.sysconvgroup' 的 0 页中有 0 行。56 sys.sysdesend的 DBCC 结果。57 对象 'sys.sysdesend' 的 0 页中有 0 行。58 sys.sysdercv的 DBCC 结果。59 对象 'sys.sysdercv' 的 0 页中有 0 行。60 sys.syssingleobjrefs的 DBCC 结果。61 对象 'sys.syssingleobjrefs' 的 1 页中有 138 行。62 sys.sysmultiobjrefs的 DBCC 结果。63 对象 'sys.sysmultiobjrefs' 的 1 页中有 102 行。64 sys.sysdbfiles的 DBCC 结果。65 对象 'sys.sysdbfiles' 的 1 页中有 6 行。66 sys.sysguidrefs的 DBCC 结果。67 对象 'sys.sysguidrefs' 的 1 页中有 4 行。68 sys.sysqnames的 DBCC 结果。69 对象 'sys.sysqnames' 的 1 页中有 91 行。70 sys.sysxmlcomponent的 DBCC 结果。71 对象 'sys.sysxmlcomponent' 的 1 页中有 93 行。72 sys.sysxmlfacet的 DBCC 结果。73 对象 'sys.sysxmlfacet' 的 1 页中有 97 行。74 sys.sysxmlplacement的 DBCC 结果。75 对象 'sys.sysxmlplacement' 的 1 页中有 17 行。76 sys.sysobjkeycrypts的 DBCC 结果。77 对象 'sys.sysobjkeycrypts' 的 0 页中有 0 行。78 sys.sysasymkeys的 DBCC 结果。79 对象 'sys.sysasymkeys' 的 0 页中有 0 行。80 sys.syssqlguides的 DBCC 结果。81 对象 'sys.syssqlguides' 的 0 页中有 0 行。82 sys.sysbinsubobjs的 DBCC 结果。83 对象 'sys.sysbinsubobjs' 的 0 页中有 0 行。84 sys.queue_messages_1977058079的 DBCC 结果。85 对象 'sys.queue_messages_1977058079' 的 0 页中有 0 行。86 sys.queue_messages_2009058193的 DBCC 结果。87 对象 'sys.queue_messages_2009058193' 的 0 页中有 0 行。88 sys.queue_messages_2041058307的 DBCC 结果。89 对象 'sys.queue_messages_2041058307' 的 0 页中有 0 行。90 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038321152，因为它驻留在文件组 "FileGroup001" (ID 2)中，但未选中该文件组。 91 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038386688，因为它驻留在文件组 "FileGroup002" (ID 3)中，但未选中该文件组。 92 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038452224，因为它驻留在文件组 "FileGroup003" (ID 4)中，但未选中该文件组。 93 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038517760，因为它驻留在文件组 "FileGroup004" (ID 5)中，但未选中该文件组。 94 无法处理对象 "aa" (ID 2105058535)、索引 "aa" (ID 0)的行集 ID 72057594038583296，因为它驻留在文件组 "FileGroup001" (ID 2)中，但未选中该文件组。 95 无法处理对象 "rr" (ID 2121058592)、索引 "rr" (ID 0)的行集 ID 72057594038648832，因为它驻留在文件组 "FileGroup001" (ID 2)中，但未选中该文件组。 96 CHECKFILEGROUP 在数据库 'partionTest' 中发现 0 个分配错误和 0 个一致性错误。97 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

View Code

从结果中可以看到只检查了文件组1里的错误

如果是检查文件组2的话就用下面的SQL语句，将1改为2就行了

1 USE [partionTest]2 GO3 DBCC CHECKFILEGROUP(2)4 GO

1 partionTest的 DBCC 结果。 2 sys.sysowners的 DBCC 结果。 3 对象 'sys.sysowners' 的 0 页中有 0 行。 4 sys.sysschobjs的 DBCC 结果。 5 对象 'sys.sysschobjs' 的 0 页中有 0 行。 6 sys.syscolpars的 DBCC 结果。 7 对象 'sys.syscolpars' 的 0 页中有 0 行。 8 sys.sysnsobjs的 DBCC 结果。 9 对象 'sys.sysnsobjs' 的 0 页中有 0 行。10 sys.syscerts的 DBCC 结果。11 对象 'sys.syscerts' 的 0 页中有 0 行。12 sys.sysscalartypes的 DBCC 结果。13 对象 'sys.sysscalartypes' 的 0 页中有 0 行。14 sys.systypedsubobjs的 DBCC 结果。15 对象 'sys.systypedsubobjs' 的 0 页中有 0 行。16 sys.sysidxstats的 DBCC 结果。17 对象 'sys.sysidxstats' 的 0 页中有 0 行。18 sys.sysbinobjs的 DBCC 结果。19 对象 'sys.sysbinobjs' 的 0 页中有 0 行。20 sys.sysclsobjs的 DBCC 结果。21 对象 'sys.sysclsobjs' 的 0 页中有 0 行。22 sys.sysremsvcbinds的 DBCC 结果。23 对象 'sys.sysremsvcbinds' 的 0 页中有 0 行。24 sys.sysrts的 DBCC 结果。25 对象 'sys.sysrts' 的 0 页中有 0 行。26 sys.syssingleobjrefs的 DBCC 结果。27 对象 'sys.syssingleobjrefs' 的 0 页中有 0 行。28 sys.sysmultiobjrefs的 DBCC 结果。29 对象 'sys.sysmultiobjrefs' 的 0 页中有 0 行。30 sys.sysguidrefs的 DBCC 结果。31 对象 'sys.sysguidrefs' 的 0 页中有 0 行。32 sys.sysqnames的 DBCC 结果。33 对象 'sys.sysqnames' 的 0 页中有 0 行。34 sys.sysxmlcomponent的 DBCC 结果。35 对象 'sys.sysxmlcomponent' 的 0 页中有 0 行。36 sys.sysxmlplacement的 DBCC 结果。37 对象 'sys.sysxmlplacement' 的 0 页中有 0 行。38 sys.sysasymkeys的 DBCC 结果。39 对象 'sys.sysasymkeys' 的 0 页中有 0 行。40 sys.syssqlguides的 DBCC 结果。41 对象 'sys.syssqlguides' 的 0 页中有 0 行。42 sys.sysbinsubobjs的 DBCC 结果。43 对象 'sys.sysbinsubobjs' 的 0 页中有 0 行。44 sys.queue_messages_1977058079的 DBCC 结果。45 无法处理对象 "sys.queue_messages_1977058079" (ID 1993058136)、索引 "queue_clustered_index" (ID 1)的行集 ID 72057594037927936，因为它驻留在文件组 "PRIMARY" (ID 1)中，但未选中该文件组。 46 无法处理对象 "sys.queue_messages_1977058079" (ID 1993058136)、索引 "queue_secondary_index" (ID 2)的行集 ID 72057594037993472，因为它驻留在文件组 "PRIMARY" (ID 1)中，但未选中该文件组。 47 对象 'sys.queue_messages_1977058079' 的 0 页中有 0 行。48 sys.queue_messages_2009058193的 DBCC 结果。49 无法处理对象 "sys.queue_messages_2009058193" (ID 2025058250)、索引 "queue_clustered_index" (ID 1)的行集 ID 72057594038059008，因为它驻留在文件组 "PRIMARY" (ID 1)中，但未选中该文件组。 50 无法处理对象 "sys.queue_messages_2009058193" (ID 2025058250)、索引 "queue_secondary_index" (ID 2)的行集 ID 72057594038124544，因为它驻留在文件组 "PRIMARY" (ID 1)中，但未选中该文件组。 51 对象 'sys.queue_messages_2009058193' 的 0 页中有 0 行。52 sys.queue_messages_2041058307的 DBCC 结果。53 无法处理对象 "sys.queue_messages_2041058307" (ID 2057058364)、索引 "queue_clustered_index" (ID 1)的行集 ID 72057594038190080，因为它驻留在文件组 "PRIMARY" (ID 1)中，但未选中该文件组。 54 无法处理对象 "sys.queue_messages_2041058307" (ID 2057058364)、索引 "queue_secondary_index" (ID 2)的行集 ID 72057594038255616，因为它驻留在文件组 "PRIMARY" (ID 1)中，但未选中该文件组。 55 对象 'sys.queue_messages_2041058307' 的 0 页中有 0 行。56 testPartionTable的 DBCC 结果。57 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038386688，因为它驻留在文件组 "FileGroup002" (ID 3)中，但未选中该文件组。 58 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038452224，因为它驻留在文件组 "FileGroup003" (ID 4)中，但未选中该文件组。 59 无法处理对象 "testPartionTable" (ID 2073058421)、索引 "testPartionTable" (ID 0)的行集 ID 72057594038517760，因为它驻留在文件组 "FileGroup004" (ID 5)中，但未选中该文件组。 60 对象 'testPartionTable' 的 2 页中有 126 行。61 aa的 DBCC 结果。62 对象 'aa' 的 0 页中有 0 行。63 rr的 DBCC 结果。64 对象 'rr' 的 0 页中有 0 行。65 CHECKFILEGROUP 在数据库 'partionTest' 中发现 0 个分配错误和 0 个一致性错误。66 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

View Code

从结果中可以看到只检查了文件组2里的错误

步骤二：

如果发现文件组1有错误，我们需要使用DBCC CHECKDB来修复错误或者还原文件组备份

1 DBCC CHECKDB([partionTest],REPAIR_ALLOW_DATA_LOSS)

步骤三：设置文件组1为只读文件组

设置文件组1为只读文件组之前需要断开所有对业务数据库的连接

1 USE master2 GO3 ALTER DATABASE [partionTest] SET OFFLINE4 5 --语法6 ALTER DATABASE [partionTest] MODIFY FILEGROUP 文件组名 READONLY7 8 ALTER DATABASE [partionTest] MODIFY FILEGROUP FileGroup001 READONLY

步骤四：对于存储当前的数据的分区文件组（不是历史数据），每个星期或者一星期两次的DBCC CHECKFILEGROUP即可

因为表中的索引和表中的现有数据是随时变化的，今年2013年还没有过完，所以文件组3中的数据和文件组2中的索引肯定会变化的

这个只能定期做DBCC CHECKFILEGROUP了

小结：

对于大型数据库，SQLSERVER针对是否使用了多个文件组的数据库提供了比较灵活的DBCC CHECKDB的方法

如果使用了多个文件组，就使用DBCC CHECKFILEGROUP

注意：这里除了表分区会用到多个文件组之外，不用表分区也可以使用多个文件组，在创建表的时候或者创建索引的时候

可以指定表和索引建立在哪个文件组上！！

没有使用表分区技术的数据库或者只有一个默认文件组的数据库

可以使用下面几个语句把DBCC CHECKDB里的关键任务分解在每天运行

周一到周三：每天运行一组，假如32张GPOSDB表，32/3=10张表/每天

1 DBCC CHECKTABLE()

周四： DBCC CHECKALLOC(gposdb) + 一组 DBCC CHECKTABLE()

1 DBCC CHECKALLOC(gposdb) 2 DBCC CHECKTABLE()

周五周六：每天运行一组 DBCC CHECKTABLE()

1 DBCC CHECKTABLE()

周日： DBCC CHECKALLOC(gposdb) + DBCC CHECKCATALOG(gposdb) + 一组DBCC CHECKTABLE()

1 DBCC CHECKALLOC(gposdb) 2 DBCC CHECKCATALOG(gposdb) 3 DBCC CHECKTABLE()

SQLSERVER提供给大家的一些DBCC CHECKDB选项

并行检查对象

若要限制DBCC检查可使用的处理器的最大数目，请使用

1 EXEC sys.sp_configure @configname = 'max degree of parallelism', -- varchar(35)2 @configvalue = 0 -- int

使用跟踪标识 /T 2528 可以禁用并行检查

PHYSICAL ONLY

对大表使用physical_only可以节省时间，检查索引,noindex可以让SQL不用去做费事费力的

非聚集索引检查

1 DBCC CHECKDB(GPOSDB,NOINDEX) WITH physical_only

除了DBCC CHECKDB之外,DBCC CHECKFILEGROUP和DBCC CHECKTABLE也有PHYSICAL ONLY和noindex选项

详细的可以看msdn

CHECKFILEGROUP:http://msdn.microsoft.com/zh-cn/library/ms187332.aspx

CHECKTABLE:http://msdn.microsoft.com/zh-cn/library/ms174338(v=sql.105).aspx

CHECKCATALOG:http://msdn.microsoft.com/zh-cn/library/ms186720(v=sql.105).aspx

CHECKALLOC:http://msdn.microsoft.com/zh-cn/library/ms188422(v=sql.90).aspx

总结

个人感觉其实SQLSERVER的东西挺灵活的，提供的选项也比较多，关键是你怎麽去用，你知道他内部的一些原理有多少

就像DBCC CHECKDB这个简单的命令其实也可以做得很灵活，一些不会用的人对于大型数据库随便

执行DBCC CHECKDB，结果就是无限期的等待

就像徐老师在《SQLSERVER企业级平台管理实践》里说的

根据2009年的经验，一个大于1TB的数据库如果没有错误，CHECKDB在某些机器上用20小时就能够跑完

，而一个有上百上千错误的数据库，哪怕只有两三百GB，有可能一天都跑不完。这个区别很显著

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

---