笔记19-徐 如何在超大型数据库上运行DBCC CHECKDB

 --如何在超大型数据库上运行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 --1、数据库自身大小
31 --2、当前系统I/O子系统的读写能力和繁忙程度
32 --3、当前系统CPU负荷
33 --4、当前数据库并发修改量 ，数据库快照问题
34 --5、存放tempdb磁盘的速度
35 --6、数据库里的对象：非聚集索引、计算列、off-row LOB VALUES、Service Broker、XML索引、索引视图等等
36
37 --7、checkdb使用的参数：physical_only只做物理结构完整性检查
38 DBCC CHECKDB(GPOSDB) WITH physical_only
39
40 --8、数据库里的错误类型和错误数目
41 --根据2009年的经验，一个大于1TB的数据库如果没有错误，CHECKDB在某些机器上用20小时就能够跑完
42 --，而一个有上百上千错误的数据库，哪怕只有两三百GB，有可能一天都跑不完。这个区别很显著
43
44
45 --对超大数据库，CHECKDB本身是一个很昂贵的任务
46 --1、对于使用了分区表机制的数据库，对于存储历史数据的分区文件组，
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 --2、没有使用分区表机制的数据库，把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可以考虑试试