Jaa

运行DBCC CHECKDB命令节省时间的办法

  • Artikkeli

近期我们做了一个关于数据库Corruption（损坏）的案例。众所周知，为了能够尽早的发现数据库Corruption以拯救更多的数据，我们通常会建议定期的运行DBCC CHECKDB命令对数据库进行检查。但是，请大家试想一下，如果我有个超级巨大的数据表，需要用超过25个小时才能完成对该表的DBCC CHECKDB操作（或者DBCC CHECKTABLE）, 时间长到超出维护窗口时间，该怎么办？

建议使用DBCC CHECKFILEGROUP的方式：

  • 第一步: 创建 partition function.

--Create a partition function

CREATE PARTITION FUNCTION myRangePF2 (int)

AS
RANGE LEFT FOR VALUES (1, 100, 1000);

GO

有关创建partition function的详细介绍请参考：

https://msdn.microsoft.com/en-us/library/ms187802.aspx

 

  • 第二步：创建file group.

 

 

  • 第三步: 创建 partition scheme.

--create a partition scheme base on the partition function we created.

CREATE PARTITION SCHEME myRangePS2

AS
PARTITION myRangePF2

TO
(test1fg, test1fg, test1fg, test2fg );

Go

 

  • 第四步: 创建data files并映射到file group.

 

  • 第五步: 创建在partition上的数据表.

--create a test table by applying the partition scheme

create table TestTable

(id int,

name varchar(20)

) on myRangePS2(id)

 

接下来，一个数据表被多个data file所承载，并被分在不同file group中进行创建。 你现在可以使用DBCC CHECKFILEGROUP了！通过将一个需长时间运行的CHECKDB操作分成若干个小的CHECKFILEGROUP操作，这样就可以大大减少在一个大数据表上的一致性检查的时间。

Comments

  • Anonymous
    May 11, 2014
    这个顶多是分区表的好处，一个表已经很大，dbcc时一定会很慢很慢，这个标题有点儿标题党的意思
  • Anonymous
    September 03, 2014
    这个要一开始架构好，不能普及。还是用简单的点检查dbcc checkdb(testdb) WITH NO_INFOMSGS,PHYSICAL_ONLY
  • Anonymous
    September 23, 2014
    的确有点标题党的意思。做一个表分区往往不是想做就能做在我实践的客户中，很难有checktable超出维护窗口的事情，如果不做定期归档任由表增大，那不用等checkdb，性能首先就会受很大影响。