小编Dan*_*ink的帖子

我正忙于审查我的 SQL 维护计划，并且对数据库上的恢复模型选项感到有些困惑，特别是与时间点恢复相关。

这是我的场景：

• 我有两个维护计划
  • 每小时进行一次事务日志备份的工具
  • 另一个每天进行完整备份（但首先在完整备份之前进行事务日志备份）
• 所有数据库都设置为使用简单恢复模型。

这是我的问题

• 看到恢复模式设置为 simple 并且 msdn 声明简单恢复模式不支持时间点恢复 - 这是否意味着我将无法在灾难中使用我的事务日志备份来恢复数据库到它发生前一个小时？
• 应该先做哪个备份，数据库备份还是事务日志备份？

我正在忙着阅读的文章说我应该先备份数据库，然后备份事务日志，否则我会得到维护计划错误，但我目前先备份事务日志，然后备份数据数据库，但我没有得到任何错误。

我的最终解决方案（维护计划）
将所有数据库设置为使用 FULL 恢复模型。然后：
每小时维护计划：
- 检查足够的硬盘空间进行备份
- 进行事务日志备份
- 归档事务日志备份（压缩 .trn 文件）
- FTP 异地归档事务日志备份

每日维护计划：
- 检查足够的硬盘空间进行备份
- 执行完整的数据库备份，然后进行事务日志备份
- 存档备份（压缩 .bak 和 .trn 文件）
- 异地 FTP 备份

每周维护计划：
- 检查数据库完整性
- 重建索引
- 清理超过 4 周的历史记录
- 删除超过 4 周的.bak 和 .trn 文件
- 删除超过 4 周的存档备份（zip 文件）

如果任何任务失败，则会发送通知电子邮件。当每日和每周任务成功完成时，还会发送成功电子邮件。

测试维护计划的注意事项。我的第一个备份被 ms windows ftp.exe 没有正确配置为使用被动模式损坏。所以检查你的备份:)

我一直在审查我们数据库中的索引（添加缺失的索引并删除坏的索引）。我偶然发现了我几个月前创建的一个索引，它看起来不错。自上次服务器重启（大约 2 周前）以来，只有 109 次写入，但有近 270 万次读取。通常，当我看到读取次数多于写入次数时，我会认为它是一项不错的工作，然后继续进行下一项工作，但这一次看起来好得令人难以置信。

所以我的问题是：有没有办法确定哪些存储过程正在使用索引？除了手动阅读所有存储过程并检查连接和 where 条件。