博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
DBCC CHECKDB
阅读量:6820 次
发布时间:2019-06-26

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

  DBCC CHECKDB 算是管理员们最常用的命令也是必须要知道的命令了。定期的检查及问题的修复都是比较重要的!!下面介绍一下 DBCC CHECKDB 的一些基本用法。

  

  DBCC CHECKDB 完成两项任务:

  • 检查数据库里有没有损坏发生。
  • 尽力修复数据库损坏,使数据库能够被重新正常访问。

  

  DBCC CHECK 做了些什么:

  • 检查一些关键的系统表
  • 对数据库运行DBCC CHECKALLOC
  • 对数据库运行DBCC CHECKCATALOG
  • 验证数据库中每个索引视图的内容
  • 验证数据库中service broker数据

  DBCC CHECKDB提供的修复方法

  • Repair_allow_data_loss :尝试修复所有错误(可能导致一些数据丢失,一般无发从备份恢复才使用)
  • Repair_fast 未执行任何修复
  • Repair_rebuild :执行次要、快速修复(如:修复非聚集索引中的额外键)及耗时修复(如:重新生成索引),这些修复不会造成数据丢失。

  注意:使用Repair_allow_data_loss参数导致的数据丢失也许是不能接受的,一般从备份还原的数据丢失可以做到心里有数,可以通过查询丢失前数据条数与修复后数据条数进行对比知道丢了多少数据。另外在早期备份中尝试找回。

  如果使用repair_allow_data_loss级别都不能恢复:

  • 按照预先备份恢复
  • 如果损坏发生在默写用户对象(表、视图、存储过程等),可以把它们DROP掉
  • 将数据库设置成紧急只读模式,用select into 将数据导入一个新建的空库。挽救尽可能多的数据,但是损坏严重程度不一样,丢失的数据多少也不一样。这样挽救回来的数据库各个数据表的状态将不一致,一般在逻辑上或有很大的问题。

  虽然sqlserver 对dbcc checkdb 做了一些优化但是对于较大的数据库还是不小的负担所以分时间段进行不同的check检查以分散一次check的影响。还可以通过下面两个参数减轻一些消耗负担

  • With noindex : 不对非聚集索引检查。
  • With physical_only:只做物理结构完整性检查。

  

  数据库损坏确实让人头疼,但出现问题耐心处理并积累处理手法还是很重要的!损坏的修复处理我也是新手仍然需要多多积累!

转载于:https://www.cnblogs.com/double-K/p/4984867.html

你可能感兴趣的文章
Linux安装mysql5.7
查看>>
HIVE常用操作以及函数
查看>>
【优达学城测评】SQL 支持许的数据类型(3)
查看>>
PHP CURL CURLOPT参数说明(curl_setopt)
查看>>
Learning NodeJs(1)
查看>>
怎么解决mysql远程连接报10038的错误
查看>>
js 父窗口可以找到子窗口的元素
查看>>
从FB10.3升级到11.0后几个问题的解决
查看>>
django使用MySql的基本步骤
查看>>
笔记《Java并发编程实战》[2]
查看>>
fpdf基本用法
查看>>
Linux下使用pure-ftpd建立匿名ftp访问
查看>>
PhalApi:[1.11] 快速入门: 接口开发示例 源码 图文
查看>>
分享插件
查看>>
HTML 页面中Buton 按钮提交,一个很坑的问题
查看>>
kitchen测试salt-formulas
查看>>
拿Nginx 部署你的静态网页
查看>>
23种设计模式
查看>>
制作自己的镜像(一)
查看>>
openstack命令整理
查看>>