我已经安装了 Ola Hallengrens 维护脚本，它为我创建了作业。
DatabaseBackup - SYSTEM_DATABASES - FULL
DatabaseBackup - USER_DATABASES - FULL
DatabaseBackup - USER_DATABASES - DIFF
DatabaseBackup - USER_DATABASES - LOG
DatabaseIntegrityCheck - SYSTEM_DATABASES
DatabaseIntegrityCheck - USER_DATABASES
IndexOptimize - USER_DATABASES
我打算按照他的指导来回答他的问题常问问题 How should I schedule the jobs?
这取决于您的维护窗口、数据库的大小、最大数据丢失以及许多其他因素。以下是一些您可以开始使用的指南，但您需要根据您的环境进行调整。
用户数据库：每周一天进行完整备份。每周其他日子进行差异备份。每小时备份事务日志。每周一天进行完整性检查。每周一天进行索引优化。
系统数据库：每天进行完整备份。每周进行一天的完整性检查。
索引优化后进行完整性检查。这是因为索引重建有时可以修复数据库损坏。索引优化后进行完整备份。那么接下来的差异备份就会很小。完整性检查后进行完整备份。然后您就知道备份的完整性没问题。这意味着首先进行索引优化，然后进行完整性检查，最后进行完整备份。
我的问题仍然是How should I schedule the jobs?。
尤其：
如果我每天午夜执行完整/差异备份，我是否也应该在午夜运行事务日志备份？或者，我应该让午夜作业运行事务日志，然后再执行完整/差异备份？或者，我是否应该不在午夜执行事务日志备份？
我应该如何设置作业来执行索引优化，然后进行完整性检查，然后进行完整备份？除非绝对必要，否则我不希望差异备份和事务日志备份在索引重建后变得非常大。
关于其他人如何进行设置的任何建议都非常有用。
答案1
这些都非常笼统，但我们还是继续吧。
每日进行完整备份。每 15 分钟备份一次事务日志（多或少取决于在数据库完全故障的情况下可以接受多少数据丢失）。索引重建或碎片整理应该每周进行一次（对于较大的数据库，则每天进行一次）。完整性检查应该每天进行。如果无法每天进行（完整性检查非常耗费 CPU 和 IO），那么至少每周进行一次。
索引维护完成后直接备份的事务日志会比其他备份大很多。对此你无能为力。不要将数据库从完整恢复更改为简单恢复以进行索引重建操作。工作完成后不要缩小文件。让日志增长到所需的大小并保留在那里。