博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SQL Server 2008 存储结构之DCM、BCM
阅读量:7228 次
发布时间:2019-06-29

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

原文首发于it168,链接见http://tech.it168.com/a2010/0921/1106/000001106857.shtml

差异变更(Differential Changed Map,DCM)页面。它跟踪一个文件中的哪一个区在最新一次完全数据库备份以后被修改过。这样SQL Server用在增量备份时只对已发生数据变更的分区进行增量备份即可。

   那么首先让我们执行一下dbcc page(testDB,1,6,2)命令,可以看出前96字节为文件头,接下来的96个字节为保留页面,从第195个字节才开始记录区是否已做变更。由 于是新库,数据对象并不多;ffff 7f,这三个字节记录了需要进行下次备份需要进行增量备份的信息。

1

 

  让我们换个视图来看一下,即执行dbcc page(testDB,1,6,3),这样可以清楚地看到只有第0页到第183页是CHANGED状态,下次备份需要备份这些页面。

1

 

  接下来当我们执行一次testDB库全备后,再次用dbcc page(testDB,1,6,3)观察一下变化。

1

 

  就会发现除了一下系统保留页面,基本上都变更为NOT CHANGED状态,记住DCM页面记录的是区变更信息,并且系统保留页面是一定要备份的。

  BCM页

   批量更改映射(Bulk Changed Map,BCM)页面,只有在数据库处于BULK_LOGGED模式,并且没有执行任何bulk批量操作时,才被使用到,因为BULK_LOGGED模式 时数据库日志记录了包含数据库所有改变的完整顺序记录,所以我们能够将数据库还原到任一时间点。

  大容量日志恢复模式是一种特殊用途的恢复模式,只应偶尔用于提高某些大规模大容量操作(如大量数据的大容量导入)的性能

  与完整恢复模式(完全记录所有事务)相比,大容量日志恢复模式只对大容量操作进行最小记录(尽管会完全记录其他事务)。大容量日志恢复模式保护大容量操作不受媒体故障的危害,提供最佳性能并占用最小日志空间。

  但是,大容量日志恢复模式会增加这些大容量复制操作丢失数据的风险,因为大容量日志操作阻止再次捕获对每个事务逐一所做的更改。如果日志备份包含大容量日志操作,则无法还原到该日志备份中的时点,而只能还原整个日志备份。

  为跟踪数据页,日志备份操作依赖于位图页的大容量更改,位图页针对每个区包含一位。对于自上次日志备份后由大容量日志操作所更新的每个区,在位图中将每个位都设置为 1。

  因为BCM页的应用场景比较单一,在此不对BCM页做相关详述。

本文转自baoqiangwang51CTO博客,原文链接:http://blog.51cto.com/baoqiangwang/412108,如需转载请自行联系原作者

你可能感兴趣的文章
我的朗科运维第七课
查看>>
CentOS的进程管理二
查看>>
https客户端证书导入
查看>>
用 PreparedStatement 向 SqlServer 中一次性插入多条记录
查看>>
Slackware-2014-0903
查看>>
CentOS下安装JDK1.7
查看>>
LDAP DIT设计参考
查看>>
iptables详解
查看>>
Protostuff 介绍
查看>>
一张图看懂开源许可协议,开源许可证GPL、BSD、MIT、Mozilla、Apache和LGPL的区别...
查看>>
参数验证其实可以更简明一点
查看>>
Set up Mule runtime env with mule-standalone-3.6.0
查看>>
Linux基础-linux命令:csplit
查看>>
core_framework —— 基于libev的轻量级lua网络开发框架
查看>>
回到顶部
查看>>
DES/3DES(TripleDES)加密、解密测试数据
查看>>
Maven项目标准目录结构
查看>>
Tomcat 系统架构与设计模式,第 1 部分: 工作原理
查看>>
Hadoop输出参数信息详解(16)
查看>>
ERROR 2002 (HY000): Can't connect to local MySQL错误
查看>>