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

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

 1 --如何在超大型数据库上运行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可以考虑试试

 

posted @ 2013-07-27 15:40 桦仔 阅读(...) 评论(...)  编辑 收藏