--如何在超大型數據庫上運行DBCC CHECKDB
2 --運行DBCC CHECKDB影響性能是不免的,影響正常應用運行也是不免的
3 --許多數據庫是沒法修復的,或者在物理上的錯誤修復成功,可是在邏輯上
4 --的錯誤是沒法挽回的。
5
6 --當發現用戶訪問數據庫才發現數據庫損壞,可能已經爲時已晚,損失巨大。
7 --因此DBA應該按期對每一個數據庫作CHECKDB工做。
8
9 --二者平衡:比較合理的週期DBCC CHECKDB,不影響數據庫應用性能
10
11 --內部數據庫快照
12 --DBCC CHECKDB徹底能夠在多用戶模式下正常使用DBCC CHECKDB(GPOSDB),不須要等到一個全部用戶都離線的時候再作
13 DBCC CHECKDB(GPOSDB)
14
15
16 --並行檢查對象
17 --若要限制DBCC檢查可以使用的處理器的最大數目,請使用
18 EXEC sys.sp_configure @configname = 'max degree of parallelism', -- varchar(35)
19 @configvalue = 0 -- int
20
21 --使用跟蹤標識 /T2528 能夠禁用並行檢查
22
23 --PHYSICAL ONLY
24 --對大表使用physical_only能夠節省時間,檢查索引,noindex可讓SQL不用去作費事費力的
25 --非彙集索引檢查
26 DBCC CHECKDB(GPOSDB,NOINDEX) WITH physical_only
27
28
29 -------------------------------影響checkdb時間的因素---------------------------------------------------
30 --一、數據庫自身大小
31 --二、當前系統I/O子系統的讀寫能力和繁忙程度
32 --三、當前系統CPU負荷
33 --四、當前數據庫併發修改量 ,數據庫快照問題
34 --五、存放tempdb磁盤的速度
35 --六、數據庫裏的對象:非彙集索引、計算列、off-row LOB VALUES、Service Broker、XML索引、索引視圖等等
36
37 --七、checkdb使用的參數:physical_only只作物理結構完整性檢查
38 DBCC CHECKDB(GPOSDB) WITH physical_only
39
40 --八、數據庫裏的錯誤類型和錯誤數目
41 --根據2009年的經驗,一個大於1TB的數據庫若是沒有錯誤,CHECKDB在某些機器上用20小時就可以跑完
42 --,而一個有上百上千錯誤的數據庫,哪怕只有兩三百GB,有可能一天都跑不完。這個區別很顯著
43
44
45 --對超大數據庫,CHECKDB自己是一個很昂貴的任務
46 --一、對於使用了分區表機制的數據庫,對於存儲歷史數據的分區文件組,
47 --因爲數據自己已經不會發生修改,咱們能夠把文件組類型設成只讀模式,防止任何誤修改。
48 --每月或半個月運行一次
49 USE GPOSDB
50 GO
51 DBCC CHECKFILEGROUP(1)
52 GO
53 --便可。
54
55 --對於存儲當前的數據的分區文件組(不是歷史數據),每一個星期或者一星期兩次的
56 USE GPOSDB
57 GO
58 DBCC CHECKFILEGROUP(1) --{ 'filegroup' | filegroup_id }
59 GO
60 --便可
61
62
63 --二、沒有使用分區表機制的數據庫,把checkdb裏的關鍵任務分解在天天運行
64 --週一到週三:天天運行一組,假如32張GPOSDB表,32/3=10張表/天天
65 DBCC CHECKTABLE()
66 --週四:
67 DBCC CHECKALLOC(gposdb) + 一組 DBCC CHECKTABLE()
68 --週五週六:天天運行一組
69 DBCC CHECKTABLE()
70 --週日:
71 DBCC CHECKALLOC(gposdb) + DBCC CHECKCATALOG(gposdb) + 一組DBCC CHECKTABLE()
72
73 --以上方法TB級數據庫的DBA能夠考慮試試數據庫