DBCC命令

DBCC SQLMGRSTATS

用于产生3个不同的值,这些值用在你想查看高速缓存在ad-hoc和预编译的TSQL语句中是如何工作的

Memory Used(8K Pages):若内存页的数量非常大,这也许表明一些用户连接正在预处理许多T-SQL语句。

Number CSql Objects:表明已经在高速缓存中的T-SQL的语句的总数

Number False Hits:有时,当sql server匹配在高速缓存中已经存在的T-SQL语句时会出现错误的命中。在理想的情况下,这个数字应该尽可能地小。

DBCC MEMORYSTATUS

列出各项SQL Server内存缓存区的使用情况。

返回了大量的有关内存方面的信息,在动态性能视图sys.dm_os_memory_clerks中有类似的信息。

DBCC PROCCACHE

显示过程的执行计划高速缓存的使用情况。

image

DBCC FREEPROCCACHE

删除计划缓存中的所有元素,通过指定计划句柄或 SQL 句柄从计划缓存中删除特定计划,或者删除与指定资源池相关联的所有缓存条目。

DBCC FREEPROCCACHE [ ( { plan_handle | sql_handle | pool_name } ) ] [ WITH NO_INFOMSGS ]

参数

( { plan_handle | sql_handle |pool_name } )

plan_handle 用于唯一标识已执行并且其计划驻留在计划缓存中的批处理的查询计划。plan_handle 的数据类型为varbinary(64),可从下列动态管理对象中获得此参数:

  • sys.dm_exec_cached_plans
  • sys.dm_exec_requests
  • sys.dm_exec_query_memory_grants
  • sys.dm_exec_query_stats

sql_handle 是要清除的批处理的 SQL 句柄。sql_handle 的数据类型为varbinary(64),可从下列动态管理对象中获得此参数:

  • sys.dm_exec_query_stats
  • sys.dm_exec_requests
  • sys.dm_exec_cursors
  • sys.dm_exec_xml_handles
  • sys.dm_exec_query_memory_grants

pool_name 是资源调控器资源池的名称。pool_name 的数据类型为sysname,可通过查询 sys.dm_resource_governor_resource_pools 动态管理视图获得此参数。

若要将资源调控器工作负荷组与资源池相关联,请查询 sys.dm_resource_governor_workload_groups 动态管理视图。有关会话的工作负荷组的信息,请查询 sys.dm_exec_sessions 动态管理视图。

WITH NO_INFOMSGS

禁止显示所有信息性消息。

清除单条缓存计划:

USE AdventureWorks2008R2;
GO
SELECT * FROM Person.Address;
GO
SELECT plan_handle, st.text
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
WHERE text LIKE N'SELECT * FROM Person.Address%';
GO

DBCC FREEPROCCACHE (0x060006001ECA270EC0215D05000000000000000000000000);
GO
清除所有缓存计划:

DBCC FREEPROCCACHE WITH NO_INFOMSGS;

清除与资源池相关联的所有缓存条目
SELECT * FROM sys.dm_resource_governor_resource_pools;
GO
DBCC FREEPROCCACHE ('default');
GO
 

DBCC FREESYSTEMCACHE

从所有缓存中释放所有未使用的缓存条目。SQL Server 数据库引擎会事先在后台清理未使用的缓存条目,以使内存可用于当前条目。但是,可以使用此命令从所有缓存中或者从指定的资源调控器池缓存中手动删除未使用的条目。

DBCC FREESYSTEMCACHE 
        ( 'ALL' [, pool_name ] ) 
    [WITH 
    { [ MARK_IN_USE_FOR_REMOVAL ] , [ NO_INFOMSGS ]  }
    ]

参数

( 'ALL' [, pool_name ] )

ALL 指定所有受支持的缓存。

pool_name 指定资源调控器池缓存。只释放与此池关联的条目。

MARK_IN_USE_FOR_REMOVAL

当不再使用当前使用的条目后,将它们分别从其各自所属的缓存中进行异步释放。当 DBCC FREESYSTEMCACHE WITH MARK_IN_USE_FOR_REMOVAL 执行后,缓存中新创建的条目不会受到影响。

下面的示例说明如何清除专属于某个指定资源调控器资源池的缓存。

-- Clean all the caches with entries specific to the resource pool named "default".
DBCC FREESYSTEMCACHE ('ALL','default');

下面的示例使用 MARK_IN_USE_FOR_REMOVAL 子句,在不再使用条目后将它们从所有当前缓存中释放。

DBCC FREESYSTEMCACHE ('ALL') WITH MARK_IN_USE_FOR_REMOVAL;
 
DBCC FREESESSIONCACHE

刷新针对 Microsoft SQL Server 实例执行的分布式查询所使用的分布式查询连接缓存。

DBCC FREESESSIONCACHE [ WITH NO_INFOMSGS ]

以下示例将刷新分布式查询缓存。

USE AdventureWorks2008R2;
GO
DBCC FREESESSIONCACHE WITH NO_INFOMSGS;
GO

DBCC CLEANTABLE

回收表或索引视图中已删除的可变长度列的空间。

DBCC CLEANTABLE
(
    { database_name | database_id | 0 }
        , { table_name | table_id | view_name | view_id }
    [ , batch_size ]
)
[ WITH NO_INFOMSGS ]

参数

database_name | database_id | 0

要清除的表所在的数据库。如果指定 0,则使用当前数据库。数据库名称必须符合标识符规则。

table_name | table_id |view_name| view_id

要清除的表或索引视图。

batch_size

每个事务处理的行数。如果未指定,或指定为 0,则该语句将在一个事务中处理整个表。

DBCC CLEANTABLE 用于在删除可变长度列之后回收空间。可变长度列可以属于下列数据类型之一:varcharnvarcharvarchar(max)nvarchar(max)varbinaryvarbinary(max)textntextimagesql_variantxml。该命令不回收删除固定长度列后的空间。

如果删除的列存储在行内,则 DBCC CLEANTABLE 将从表的 IN_ROW_DATA 分配单元回收空间。如果列存储在行外,则将根据已删除列的数据类型从 ROW_OVERFLOW_DATA 或 LOB_DATA 分配单元回收空间。如果从 ROW_OVERFLOW_DATA 或 LOB_DATA 页回收空间时产生空页,DBCC CLEANTABLE 将删除该页。有关分配单元和数据类型的详细信息,请参阅表和索引数据结构体系结构。

DBCC CLEANTABLE 作为一个或多个事务运行。如果未指定批大小,则该命令将在一个事务中处理整个表,并在操作过程中以独占方式锁定该表。对于某些大型表,单个事务的长度和所需的日志空间可能太大。如果指定批大小,则该命令将在一系列事务中运行,每个事务包括指定的行数。DBCC CLEANTABLE 不能作为其他事务内的事务运行。

该操作将被完整地记入日志。

系统表或临时表不支持使用 DBCC CLEANTABLE。

DBCC CLEANTABLE (AdventureWorks2008R2,"Production.Document", 0)
WITH NO_INFOMSGS;
GO
 

DBCC DROPCLEANBUFFERS

从缓冲池中删除所有清除缓冲区。
DBCC DROPCLEANBUFFERS [ WITH NO_INFOMSGS ]

此指示符只清掉clean buffer,若希望把dirty buffer的空间也清掉,那么需要先把dirty buffer中的数据写到disk,这可以通过可以执行checkpoint来实现,然后再一起清除掉。

DBCC FLUSHPROCINDB

只清除某一个数据库内被高速缓存的程序,以避免用freeproccache清掉所有程序缓存。

declare @i int

set @i = DB_ID('wcc')

dbcc flushprocindb(@i)

DBCC INPUTBUFFER

显示从客户端发送到 Microsoft SQL Server 实例的最后一个语句。

DBCC OUTPUTBUFFER

以十六进制和 ASCII 格式返回指定 session_id 的当前输出缓冲区。

DBCC CURSORSTATUS

显示游标的统计信息
 
 

一、DBCC 帮助类命令

* DBCC HELP('?')
查询所有的DBCC命令
* DBCC HELP('checktable')
查询指定的DBCC命令的语法说明
* DBCC USEROPTIONS
返回当前连接的活动(设置)的SET选项

二、DBCC 检查验证类命令

* DBCC CHECKALLOG ('数据库名称')
检查指定数据库的磁盘空间分配结构的一致性
* DBCC CHECKCATALOG ('数据库名称')
检查指定数据库的系统表内和系统表间的一致性
* DBCC CHECKCONSTAINTS ('tablename')
检查指定表上的指定约束或所有约束的完整性
* DBCC CHECKDB
检查数据库中的所有对象的分配和结构完整性
* DBCC CHECKFILEGROUP
检查指定文件组中所有表在当前数据库中的分配和结构完整性
* DBCC CHECKTABLE
检查指定表或索引视图的数据、索引及test、ntest和image页的完整性
* DBCC CHECKIDENT
检查指定的当前标识值
* DBCC SQLPERF(UMSSTATS) undocumented in BOL
可以用来检查是否CPU使用达到瓶颈
最关键的一个参考数据num runnable,表明当前有多少个线程再等待运行
如果大于等于2,考虑CPU达到瓶颈

三、DBCC 维护类命令

* DBCC CLEANTABLE ('db_name','table_name')
回收Alter table drop column语句删除可变长度列或text
* DBCC DBREINDEX
重建指定数据库的一个或多个索引
* DBCC INDEXDEFRAG
对表或视图上的索引和非聚集索引进行碎片整理
* DBCC PINTABLE (db_id,object_id)
将表数据驻留在内存中
查看哪些表驻留在内存的方法是:
select objectproperty(object_id('tablename'),'tableispinned')
* DBCC UNPINTABLE (db_id,object_id)
撤消驻留在内存中的表
* DBCC SHRINKDATABASE(db_id,int)
收缩指定数据库的数据文件和日志文件大小
* DBCC SHRINKFILE(file_name,int)
收缩相关数据库的指定数据文件和日志文件大小

四、DBCC 性能调节命令

* DBCC dllname(FREE)
sp_helpextendedproc 查看加载的扩展PROC
在内存中卸载指定的扩展过程动态链接库(dll)
* DBCC DROPCLEANBUFFERS
从缓冲池中删除所有缓冲区
* DBCC FREEPROCCACHE
从过程缓冲区删除所有元素
* DBCC INPUTBUFFER
显示从客户机发送到服务器的最后一个语句
* DBCC OPENTRAN (db_name)
查询某个数据库执行时间最久的事务,由哪个程序拥有
* DBCC SHOW_STATISTICS
显示指定表上的指定目标的当前分布统计信息
* DBCC SHOWCONTIG
显示指定表的数据和索引的碎片信息
* DBCC SQLPERF
(logspace) 查看各个DB的日志情况
(iostats) 查看IO情况
(threads) 查看线程消耗情况
返回多种有用的统计信息
* DBCC CACHESTATS
显示SQL Server 2000内存的统计信息
* DBCC CURSORSTATS
显示SQL Server 2000游标的统计信息
* DBCC MEMORYSTATS
显示SQL Server 2000内存是如何细分的
* DBCC SQLMGRSTATS
显示缓冲中先读和预读准备的SQL语句

五、DBCC 未公开的命令

* DBCC ERRLOG
初始化SQL Server 2000的错误日志文件
* DBCC FLUSHPROCINDB (db_id)
清除SQL Server 2000服务器内存中的某个数据库的存储过程缓存内容
* DBCC BUFFER (db_name,object_name,int(缓冲区个数))
显示缓冲区的头部信息和页面信息
* DBCC DBINFO (db_name)
显示数据库的结构信息
* DBCC DBTABLE
显示管理数据的表(数据字典)信息
* DBCC IND (db_name,table_name,index_id)
查看某个索引使用的页面信息
* DBCC REBUILDLOG
重建SQL Server 2000事务日志文件
* DBCC LOG (db_name,3) (-1--4)
查看某个数据库使用的事物日志信息
* DBCC PAGE
查看某个数据库数据页面信息
* DBCC PROCBUF
显示过程缓冲池中的缓冲区头和存储过程头
* DBCC PRTIPAGE
查看某个索引页面的每行指向的页面号
* DBCC PSS (user,spid,1)
显示当前连接到SQL Server 2000服务器的进程信息
* DBCC RESOURCE
显示服务器当前使用的资源情况
* DBCC TAB (db_id,object_id)
显示数据页面的结构

六、DBCC跟踪标记

跟踪标记用于临时设置服务器的特定特征或关闭特定行为,常用于诊断性能问题或调试存储过程或复杂的计算机系统
* DBCC TRACEON (3604)
打开跟踪标记
* DBCC TRACEOFF
关闭跟踪标记
* DBCC TRACESTATS
查看跟踪标记状态

七、使用 DBCC 结果集输出

  许多 DBCC 命令可以产生表格格式的输出(使用 WITH TABLERESULTS 选项)。该信息可装载到表中以便将来使用。以下显示一个示例脚本:

  CREATE TABLE DBCCResult (

  DBCCFlag INT,

  Result INT

  )

  INSERT INTO DBCCResult

  EXEC ('DBCC TRACESTATUS (-1) WITH NO_INFOMSGS')

  SELECT *

  FROM DBCCResult
八、官方使用DBCC的建议
1、在系统使用率较低时运行 CHECKDB。
2、请确保未同时执行其它磁盘 I/O 操作,例如磁盘备份。
3、将 tempdb 放到单独的磁盘系统或快速磁盘子系统中。
4、允许 tempdb 在驱动器上有足够的扩展空间。 使用带有 ESTIMATE ONLY 的 DBCC
估计 tempdb 将需要多少空间。
5、避免运行占用大量 CPU 的查询或批处理作业。
6、在 DBCC 命令运行时,减少活动事务。
7、使用 NO_INFOMSGS 选项显著减少处理和 tempdb 的使用。
8、考虑使用带有 PHYSICAL_ONLY 选项的 DBCC CHECKDB 来检查页和记录首部
的物理结构。当硬件导致的错误被置疑时,这个操作将执行快速检查。

在发布,订阅复制时要用服务器实名时可以这样:

select * from sysservers   (可以找到原来服务器的名称)

exec sp_dropserver 'jmsql9'    (删除原来的服务器名)

exec sp_addserver 'jmSQL9' ,LOCAL    (改为新的服务器名)

ALTER DATABASE [jm] SET SINGLE_USER          (改为单用户模式)

DBCC CHECKDB("databasename",REPAIR_REBUILD) WITH TABLOCK    (修复数据库) 

DBCC  CHECKTABLE("tablename",repair_rebuild) with tablock  (修复表)

DBCC DBREINDEX ('t_icitem'  ,  '   ')       修复此表所有的索引。

ALTER DATABASE [jm] SET MULTI_USER                    (改为多用户模式)

REPAIR_ALLOW_DATA_LOSS:执行由REPAIR_REBUILD 完成的所有修复,包括对行和页进行分配和取消分配以改正分配错误、结构行或页的错误,以及删除已损坏的文本对象。这些修复可能会导致一些数据丢失。修复操作可以在用户事务下完成以允许用户回滚所做的更改。如果回滚修复,则数据库仍会含有错误,应该从备份进行恢复。如果由于所提供修复等级的缘故遗漏某个错误的修复,则将遗漏任何取决于该修复的修复。修复完成后,备份数据库。

REPAIR_FAST 进行小的、不耗时的修复操作,如修复非聚集索引中的附加键。这些修复可以很快完成,并且不会有丢失数据的危险。

REPAIR_REBUILD 执行由REPAIR_FAST 完成的所有修复,包括需要较长时间的修复(如重建索引),执行这些修复时不会有丢失数据的危险。

dbcc shrinkdatabase  (jm)      压缩数据库

 
 
原文地址:https://www.cnblogs.com/kingwwz/p/5817913.html