首先我要声明，我是 SQL 管理方面的新手，我继承了一台较旧的服务器，该服务器为我们日常运营提供主数据库服务。因此，我提前为我的初学者问题道歉。
我的任务是找出为什么此服务器上的简单维护计划仅在完整备份未运行时才会失败。我进行了一些调查，并确定罪魁祸首是我的事务日志已满（静态设置为 20 GB，在第一轮作业失败后设置为 40 GB）。我还了解到，我们当前的恢复模型（简单）对于生产 SQL 服务器来说不是一个好主意，应该改为批处理或完整。我还对日志文件使用情况（%）进行了监控，并注意到日志文件在生产时间内的使用量很少（不到 1%），只有在维护时才会填满。成功的简单维护计划将消耗 40% 到 80% 的事务日志。失败将使日志达到最大值。您还需要哪些其他信息？
我需要了解为什么简单维护计划在完整备份运行时会成功，而在不完整备份运行时会失败。我读到的所有内容都表明我不应该看到这个问题。我想更好地了解发生了什么，这样我就不必“只是增加日志空间”。对我来说，这个想法只是一种创可贴，从长远来看只会伤害我们。
服务器环境：Windows Server 2003 R2 x64 上的 SQL Ent 2005 x64 (9.0.3080) 带 SSRS。所有 DBs MF 上都运行完整备份。主操作 DB 在生产/营业时间内有 10 分钟的差异和一个简单的恢复模型。简单的维护计划每 24 小时运行一次。在文件系统上：主操作 DB 约为 70 GB，索引文件（其中 4 个）约为 2 GB，事务日志为 40 GB。完整备份约为 50 GB
没有复制或镜像。
我正在查看该作业，其类型被列为 SSIS 包。这有意义吗？
执行任务：数据库完整性 - 包括索引重建索引 - 每页默认可用空间 - 在 tempdb 中对结果进行排序更新统计信息 - 仅列统计信息 - 全面扫描维护清理 - 删除文件：维护计划文本报告 - 年龄：超过 2 周历史清理 - 删除文件：备份和还原、SQL Server 代理作业历史记录、维护计划历史记录 - 年龄：超过 2 周
请协助。任何帮助都感激不尽。
答案1
这篇关于尝试找出 SQL 不同恢复模型的备份策略的 Symantec Connect 文章应该会有所帮助。即使您不使用 Backup Exec，它也几乎全部相关，并且适用于其他备份模型，包括如果您使用 SQL 工具执行 DB 转储以进行备份： http://www.symantec.com/connect/forums/be2012-backing-sql-databases-full-simple-recovery-mode-issue