dbcc checkdb大数据库修复：
--如何在超大型数据库上运行DBCC CHECKDB
--运行DBCC CHECKDB影响性能是难免的，影响正常应用运行也是难免的
--许多数据库是无法修复的，或者在物理上的错误修复成功，但是在逻辑上
--的错误是无法挽回的。
--当发现用户访问数据库才发现数据库损坏，可能已经为时已晚，损失巨大。
--所以DBA应该定期对每个数据库做CHECKDB工作。
--两者平衡：比较合理的周期DBCC CHECKDB，不影响数据库应用性能
--内部数据库快照
--DBCC CHECKDB完全可以在多用户模式下正常使用DBCC CHECKDB(GPOSDB)，不需要等到一个所有用户都离线的时候再做
DBCC CHECKDB(GPOSDB)
--并行检查对象
--若要限制DBCC检查可使用的处理器的最大数目，请使用
EXEC sys.sp_configure @configname = 'max degree of parallelism', -- varchar()
@configvalue = -- int
--使用跟踪标识 /T 可以禁用并行检查
--PHYSICAL ONLY
--对大表使用physical_only可以节省时间，检查索引,noindex可以让SQL不用去做费事费力的
--非聚集索引检查
DBCC CHECKDB(GPOSDB,NOINDEX) WITH physical_only
------影响checkdb时间的因素--------
--、数据库自身大小
--、当前系统I/O子系统的读写能力和繁忙程度
--、当前系统CPU负荷
--、当前数据库并发修改量 ，数据库快照问题
--、存放tempdb磁盘的速度
--、数据库里的对象：非聚集索引、计算列、off-row LOB VALUES、Service Broker、XML索引、索引视图等等
--、checkdb使用的参数：physical_only只做物理结构完整性检查
DBCC CHECKDB(GPOSDB) WITH physical_only
--、数据库里的错误类型和错误数目
--根据年的经验，一个大于TB的数据库如果没有错误，CHECKDB在某些机器上用小时就能够跑完
--，而一个有上百上千错误的数据库，哪怕只有两三百GB，有可能一天都跑不完。这个区别很显著
--对超大数据库，CHECKDB本身是一个很昂贵的任务
--、对于使用了分区表机制的数据库，对于存储历史数据的分区文件组，
--由于数据本身已经不会发生修改，我们可以把文件组类型设成只读模式，防止任何误修改。
--每个月或半个月运行一次
USE GPOSDB
GO
DBCC CHECKFILEGROUP()
GO
--即可。
--对于存储当前的数据的分区文件组（不是历史数据），每个星期或者一星期两次的
USE GPOSDB
GO
DBCC CHECKFILEGROUP() --{ 'filegroup' | filegroup_id }
GO
--即可
--、没有使用分区表机制的数据库，把checkdb里的关键任务分解在每天运行
--周一到周三：每天运行一组，假如张GPOSDB表，/=张表/每天
DBCC CHECKTABLE()
--周四：
DBCC CHECKALLOC(gposdb) + 一组 DBCC CHECKTABLE()
--周五周六：每天运行一组
DBCC CHECKTABLE()
--周日：
DBCC CHECKALLOC(gposdb) + DBCC CHECKCATALOG(gposdb) + 一组DBCC CHECKTABLE()
--以上方法TB级数据库的DBA可以考虑试试