我需要一些关于 SQL Server 2005 维护计划的建议，这里有一些问题：
在我们的例子中，每周 7 天、每天 24 小时每 1 分钟输入一次数据（每分钟仅 200 条记录）。
有人可以建议我对这个数据库有什么好处的维护计划吗？
谢谢，
德尔斯
维护计划实际上取决于您的数据库进程。由于每分钟输入一次数据，您是否有任何 rollup 和 etl 进程在运行？
我可以告诉您的最重要的过程是您的数据和事务日志的每日备份（磁带和磁盘）。
使用查询计划分析器检查任何运行缓慢的查询，您可能需要根据需要每天或每周重新索引一些表。您可以在 SQL Server 2005 企业版中进行在线重新索引，这意味着您不需要离线。
通过创建维护计划来制定良好的流程，并通过创建计划作业尽可能地实现自动化。
两个字：灾难恢复
最好的计划是您已经测试过的计划。
计划灾难恢复，看看您可以从该计划中恢复多少现有系统。记下任何问题并找到解决方法，然后重新运行灾难恢复。您会发现这将帮助您做出决策并确定需求的优先级。
最好同时使用 O/S 还原和 SQL 服务器还原来执行此操作。
还有一些建议：设置一个 O/S 计划任务来执行 master、model、mssqlsystemresource 数据库的文件系统副本。这将为您省去烦恼，并且不必在单用户模式下运行 SQL 服务器来尝试从备份中恢复您的主数据库。
拥有备份一切都很好，但是如果您从不测试恢复，那么您的备份将毫无价值。
为了保持性能并确保数据库一致性，我通常每晚运行以下任务：
1)备份数据库 （通常这是完整备份。但是，如果数据库非常大，则每周{周末}运行一次完整备份，每个工作日进行增量或差异备份）
2）重建所有索引 （这也会自动重组所有索引，因此不需要重组步骤。）
3）更新数据库统计信息 （仅需要列统计信息，因为其他统计信息由之前运行的索引重建自动更新）
4）验证数据库完整性 （这是最重要的一步，因为它几乎可以被任何东西破坏并且仍然可以正常运行一段时间，同时所有数据都变得越来越损坏。）
5）通过电子邮件通知操作员成功（您必须同时发送成功和失败。如果您只发送失败，那么服务器可能有另一个问题阻止发送失败电子邮件，然后他们永远不会知道。）
6）清理文件 （根据驱动器空间，您将需要删除旧备份。如果有空间，我会尝试至少保留几周，但随着数据库的增长，需要检查这一点，并可能将其减少到低至一两个完整备份。）
7)清理历史记录 （维护计划日志历史记录不是很大，因此您可以保留很长的历史记录，而不必担心空间过多。当您遇到长时间失败的数据库时，有时会有所帮助。当它开始失败并用它来向监控它的人指出它没有被适当地监控成功。）
注意：确保从主数据库服务器上复制备份并将它们存储在异地。