笔记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 --一、数据库自身大小
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能够考虑试试