博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
对于超大型SQL SERVER数据库执行DBCC操作
阅读量:7296 次
发布时间:2019-06-30

本文共 847 字,大约阅读时间需要 2 分钟。

原文:

对于数据库维护,主要使用DBCC CHECKDB来实现,以下是对大型数据库的使用说明,小型数据库一般直接使用就可以了:

1、2008(2005我不确认)已经实现了快照检查,也就是当你执行DBCC时,DBMS会先快照出一个数据库,然后在快照上执行检查,这样对原来的库不造成锁的影响。
2、使用Physical_only选项,可以以较少的开销检查数据库的物理一致性。并且能检查出会危及用户数据安全的残缺页、校验和错误及常见的硬件故障。所以对于频繁使用的生产库,建议使用该选项。,可以极大地缩短对大数据库运行DBCC CHECKDB的时间。
3、CHECKDB所花费的时间主要取决于:
  a、数据库自身大小;
  b、当前I/O读写能力和繁忙程度;
  c、当前系统CPU负荷;
  d、当前数据库的并发修改量;
  e、存放tempdb磁盘的速度;
  f、数据库对象类型:如LOB会花更多时间;
  g、CHECKDB的参数;参数的选择会影响DBCC所做的事情多少;
  h、数据库的错误类型和错误数量;
按照别人的经验:1T的数据库如果没错误,checkdb可能要花上20小时。如果一个成百上千的数据库,哪怕只有2、300G。可能一天都跑不完。
现在入正题:
如果数据库设计了分区表机制,做起来会简单一些,对于存储历史数据的分区文件组,由于本身数据不发生变化,可以设为只读模式,防止任何错误修改。每个月左右经行一次DBCC CHECKFILEGROUP即可。对于当前数据,最好一周两次,单独做DBCC CHECKFILEGROUP。
如果没有分区的超大型数据库,可以参照以下方式:
周一到周三:每天运行一组DBCC CHECKTABLE
周四:DBCC CHECKALLOC+一组DBCC CHECKTABLE
周五周六:每天运行一组DBCC CHECKTABLE 
周日:DBCC CHECKALLOC+DBCC CHECKCATALOG+一组DBCC CHECKTABLE。
对于TB级数据库可以尝试使用这个方法。

转载地址:http://wownm.baihongyu.com/

你可能感兴趣的文章
《与编码人员一起工作》作者访谈
查看>>
编写Linux内核模块——第一部分:前言
查看>>
python学习笔记 - StringIO以及BytesIO
查看>>
消息称微软计划收购GitHub,估值超50亿美元
查看>>
Netflix Play API:我们为什么构建了一个演进式架构?
查看>>
知乎推荐页Ranking构建历程和经验分享
查看>>
Web性能API——帮你分析Web前端性能
查看>>
Swift 4正式发布,新功能概览
查看>>
谈谈基于机器学习的编程到底比传统编程强在哪里?
查看>>
持续演进,克服“REST缺乏”
查看>>
中国互联网公司开源项目调研报告
查看>>
Prettier 1.15代码格式化工具新增Angular和Vue.js支持
查看>>
7道常见的数据分析面试题
查看>>
管理微服务中的数据
查看>>
Oracle将NetBeans交给了Apache基金会
查看>>
新JEP将简化Java类型变异
查看>>
象SaaS一样用亚马逊Kinesis Analytics做大数据分析
查看>>
TSC的分歧导致Node.js分支
查看>>
作者问答:解密硅谷
查看>>
苹果如何使用神经网络在点云中做对象检测
查看>>