最近文章更新
- 1966年生产的广州 珠江 SB6-2型 ..
- HD6870/6850全面评测,让你大饱眼..
- 百万现金刚入门 中国7大奢华私人..
- 罕见4G希捷酷鱼系类万转SCSI服务..
- IBM 6x86MX PR333 CPU
- 采用MC68000 CPU的进口老计算机主..
- 1989年IBM-XT机软驱
- BC3型饱和标准电池拆解
- JUKO ST
- Kingston 品牌的CPU
- YAMAHA 719
- intel 30线 内存条
- intel mmx cpu和主板
- 首款xHCI 1.0正式版标准USB 3.0控..
- 《极品飞车:地下狂飙》纹理MOD视..
- USB接口加扩展子卡:影驰神秘GTX..
- 阿里巴巴将发布浏览器 核心不是W..
- 黄仁勋大秀NVIDIA LOGO纹身
- Google Earth上的奇特卫星图片
- 开火!讯景限量版HD 5970详细测试..
相关文章链接
本类文章排行
最新新闻资讯
本周下载排行
- ArcSoft TotalMedia Theatre 3 P..
- Windows 7 Build 7600 16385 RTM..
- 《姗姗来迟软件光盘+飞扬PE工具箱..
- MSDN Windows 7 RTL 7600 Ultima..
- Windows 7 Home Premium (x86) -..
- Windows Virtual PC (x86) - (Mu..
- MSDN Windows 7 Language Pack X..
- Windows 7 Language Pack (x64) ..
- Windows 7 Starter (x86) - DVD ..
- Windows 7 Professional (x86) -..
- Windows 7 Language Pack (x86) ..
- Windows 7 Home Premium (x64) -..
- Windows XP Mode (x86, x64) - (..
- 7127.0.090507-1820_x86fre_clie..
- DMG2ISO
本月下载排行
- ArcSoft TotalMedia Theatre 3 P..
- Windows 7 Build 7600 16385 RTM..
- 《姗姗来迟软件光盘+飞扬PE工具箱..
- MSDN Windows 7 RTL 7600 Ultima..
- MSDN Windows 7 Language Pack X..
- Windows 7 Home Premium (x86) -..
- Windows 7 Language Pack (x64) ..
- Windows 7 Professional (x86) -..
- 7127.0.090507-1820_x86fre_clie..
- Windows 7 Professional (x64) -..
- Windows 7 Starter (x86) - DVD ..
- Windows Virtual PC (x86) - (Mu..
- Windows 7 Ultimate (x64) - DVD..
- Lenovo Windows 7 Ultimate OEM ..
- Windows 7 Home Premium (x64) -..
- 阅览次数: 文章来源: 原文作者: 整理日期: 2010-07-13
Windows存储:SQL行溢出、差异备份及疑问
Windows存储:SQL行溢出、差异备份及疑问
问:我使用的备份策略包括完整备份和日志备份,但有人建议我应该加入差异备份来缩短还原时间。我每周进行一次完整备份,每个小时进行一次日志备份。我试过每天添加差异备份,但我注意到一个异常现象:每个星期结束时的差异备份与每周的完整备份大小差不多。我记得差异备份与日志备份一样都属于增量备份啊!难道是我记错了吗?
答:这是对差异备份的本质有所误解造成的。差异备份与日志备份不同,不属于增量备份。差异备份包含自上次完整备份后所有更改的数据文件范围(这适用于数据库、文件组和文件级别备份)。
如果范围(包含八个连续数据文件页的逻辑组)有任何更改,都会标记在称为差异图的特殊位图页中。每个数据文件的每 4GB 就有一个差异图。进行差异备份时,备份子系统会扫描所有差异图,并复制所有已更改的范围,但不会重置差异图。这表示连续的差异备份之间更改的范围越大,后者的备份会越大。只有在执行完整备份时才会重置差异图。
如果应用程序工作负载太大,以至于数据库内容在短时间(假设在一个星期)内进行了大量更改,那么每周的完整备份大小几乎会与在下一个完整备份前进行的差异备份的大小相同。这也解释了您看到的现象。
另外,差异备份确实提供了一种在灾难恢复的情况下缩短还原时间的方法。如果您采用的备份策略是每周进行一次完整备份,每小时进行一次日志备份,那么您必须执行下列操作才能最迅速地实现还原:
运行尾日志备份(自最近的日志备份后生成的所有日志)。
还原最近的完整数据库备份。
按顺序还原自最近的完整数据库备份后的所有日志备份。
还原尾日志备份。
这可能需要还原大量日志备份,尤其是在灾难刚好发生在进行下次完整备份之前。(最糟的情况是需要还原 24 + 24 + 24 + 24 + 24 + 24 + 23 个日志备份!)在此策略中每天添加差异备份,还原的顺序会变成这样:
运行尾日志备份(自最近的日志备份后生成的所有日志)。
还原最近的完整数据库备份。
还原最近的差异备份。
按顺序还原自最近的差异备份后的所有日志备份。
还原尾日志备份。
这样就不必还原大量的日志备份了,因为还原差异备份与还原差异备份涵盖期间内的所有日志备份基本相同。
在每天执行差异备份的情况下,即使是在该周的最后一天,最糟的情况也不过是 23 个日志备份。差异备份不属于增量备份,它的一个缺点是它们可能会占用更多的空间,但与缩短还原时间相比,这是值得的。
问:我有一个两节点的故障转移群集,每个节点都运行一个 SQL Server 2005 实例。我按照通常的要求,将每个实例设置为只使用 50% 的可用内存。现在我遇到了一些问题,因为两个实例上的工作负载都需要更多的内存才能维持相同的性能级别。如果我删除内存限制,或是增加内存,我想我会碰到这样的问题:其中一个实例故障转移,然后两个实例都只在一个节点上运行。您有什么建议?
答:我会针对两节点、双实例的情况来解答这个问题,但下列内容也适用于其他多实例设置(N-1 故障转移群集,其中有 N 个节点和 N-1 个 SQL Server 实例)。
许多人在两个实例上都遇到过高工作负载的情况(占用的服务器内存超过 50%),而没有考虑到两个实例在发生故障转移后最后会在一个节点上运行对工作负载的影响。如果没有特殊的配置,实例之间的内存分配很可能会不成比例,结果一个工作负载正常运行,而另一个却慢得不行。
对于 SQL Server 2000,建议将每个实例限制为最多使用 50% 的群集节点内存。这是因为 SQL Server 2000 中的内存管理器并不会对内存不足做出响应 — 假如 SQL Server 占用了节点 80% 的内存,它并不会降低内存使用量。这表示在故障转移的情况下,另一个刚启动的实例只有 20% 的内存可用。通过将两个实例限制为最多使用节点 50% 的内存,可保证每个故障转移实例有 50% 的内存。不过,这种方法产生的问题是每个实例上的工作负载也会限制为使用 50% 的内存。
而对于 SQL Server 2005(和 SQL Server 2008),内存管理器可以响应内存不足,因此 50% 的上限不再适用。但是没有这类限制,如果两个实例都在一个群集节点上运行,它们可能会争用内存直到产生不成比例的内存分配。
答案是将每个实例设置为最低内存量,这样一来,它们就不会被迫释放过多的内存。对于两节点、双实例的情况,最常见的设置是为每个实例至少配置 40% 的内存。这表示当每个实例在不同的节点上运行时,它们可以占用任意内存量。而当发生故障转移时,会保证每个实例有特定的内存量,以保持固定的工作负载性能级别,并留一些内存在两者之间共享。虽然这意味着两个工作负载的性能在发生故障转移时可能会下降(在意料之中),但是每个实例在不同的群集节点上运行的大多数时间完全不会受到限制。
[1] [2]