Compartilhar via


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

近期我们做了一个关于数据库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,性能首先就会受很大影响。