sql-server – 24×7 vs Night Time Window

>清除旧数据
> reindex
>更新统计信息

所有这些似乎都对我们的系统(即在线用户和实时数据馈送)造成了严重影响.我在亚马逊上看过任何与这个主题相关的书,到目前为止还没有找到任何东西.

解决方法

您首先想要识别的是,虽然许多操作都是24×7,但通常会有低活动时间.您可以利用这些时间来运行维护,从而减少对数据库的干扰.第二个是您需要预留一些时间来完成中断(例如服务包或数据库迁移),因此您需要与管理层协商完整的维护时段.对于特定项目,您需要考虑并计划每个项目,并适当地利用您的工具.重要的是你必须计划每一个,我提供的任何例子都非常“你的里程可能会有所不同”.

备份

备份通常不会对工作负载产生巨大影响,但必须加以考虑,因为它们可能会占用大量I / O.您需要适当地安排这些并监控完成所需的时间.这里最大的障碍是,在24×7全天候运行中,您可能无法在每周的每个晚上进行完整的夜间备份.您可能需要计划何时可以完成任务,何时执行差异,以及将这两者与日志备份结合使用的保留期.

例如,我在周日晚上(最低活动)运行我所有数据库的完整备份,在所有其他夜晚(周一至周六)运行差异.我保留最近两周的满额和差异在磁盘上,过去两天的日志.这为我提供了足够的恢复灵活性,但如果需要,我可能必须从磁带恢复备份.

指数/统计维护

这是您必须处理的最常见的主动维护类型.你无法避免它,但你可以减轻影响.最初的经验法则是您只应对需要它的对象进行维护.一般准则是仅重建greater than 30% fragmented and larger than 1000 pages的索引.如果您有auto-update statistics,这将处理您的大部分统计维护,但每晚工作以保持同步并不是一个坏主意.

如果您拥有Enterprise Edition,则还可以访问其他一些用于管理维护的选项.最重要的是Online Index Rebuilds,这将允许您在它们仍在使用时重建索引(实质上,它并排构建索引,然后交换它).您还可以将partitioning用于“大”表,以减少所需的重建时间.

如果您没有处理这些最佳实践的自定义脚本,那么此类维护的最佳选择是使用Ola Hallengren’s Maintenance scripts.这些设置和配置相当容易,并且内置了许多这些指南.

DBCC一致性检查

根据您的总体工作负载,您可能会发现DBCC检查会破坏您的操作.有两种常用方法可以最小化DBCC对数据库的影响：

> PHYSICAL_ONLY – 运行此选项将检查物理页面级别的数据库,并避免更具侵入性的全面检查.这将涵盖识别最可能的腐败类型.
>检查已还原的副本 – 如果有空间,则可以将数据库还原到另一个实例,并对还原的副本运行DBCC检查.这将讲述有关您的实时数据库的相同故事,但您显然不会干扰该活动.这里的一些其他替代方法是针对日志传送副本或镜像数据库运行DBCC.

This blog post提供了有关您的选项的更多详细信息.

批处理作业/ ETL

这实际上取决于您如何设计流程.您的ETL总是会干扰实时OLTP表(就像任何其他应用程序一样),所以要记住一些键：

>在您的其他维护期间和活动期间安排此类工作.
>正确调整工作大小,以便为性能进行批处理,以便批处理不会太大,以至于它会将表锁定几个小时.频谱结束的示例：逐行激励行(RBAR)与单行百万行删除.
>使用阶段表并在适当的时候使数据处理脱机.只有在绝对必要时才触摸实时内容.

结论

同样,这里有很多理由可以覆盖.这不是一个全面的指南,而是一些方法的高级概述.我甚至没有讨论过高可用性选项(例如可用性组和故障转移群集).您需要检查每个项目并构建一个如何处理它的计划.在许多方面,您还需要在前进时迭代并优化您的工作.

其他资源：

SQL Skills VLDB maintenance best practices

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!