SQL Server备份-几个问题

我们在星期五的晚上9点运行每周备份工作，并且在磁盘空间（有时会变得非常低）和性能方面遇到一些问题。我们正在考虑精简/优化发生的事情，并希望您提出宝贵意见。

特别：

1. 备份过程大约需要4个小时来更新统计信息。我们可以安全地禁用此过程以节省时间吗？

2. 我们非常经常地在磁盘空间上运行不足，想知道是否应该重新调整该过程。当前，它创建备份，然后删除以前的备份，这就是占用磁盘空间的原因。我们可以安全地删除前一首，然后做备份？

任何其他评论或意见将非常受欢迎编辑：服务器上SQL文件的总大小约为35GB。一个db的大小约为25GB，而其他六个共享的磁盘则构成了另外10个左右的GB。

（1）是的，我通常具有备份过程。如果可以的话，我在备份期间不会做任何事情。您可能需要备份，然后对统计信息进行更新。听起来好像您正在同时运行两个作业（1个用于备份，1个用于更新统计）？

（2）是否将备份复制到磁带或其他磁盘存储？如果是这样，那么我通常会在本地创建新备份之前清理文件。如果没有，那么如果我要争取存储空间，我会考虑在创建新备份文件之前先压缩备份文件。（也就是说，如果您无法如@Simon所建议的那样对备份启用压缩，那么这也会节省一些空间。）

我只能在这里回答问题2。我建议您看一下压缩备份。

• 如果您具有2008企业版，则SQL Server可以执行此操作。如果没有看下面两个。
• Quest Litespeed
• RedGate SQL备份

1）我看不到备份任务和更新统计信息之间的直接关系。因此，您可以毫无问题地拆分它们。我会看到更新统计信息部分与将对碎片进行碎片整理/重建索引的工作更相关。

2）即使时间很短，您也不想没有备份。因此，仅当您已经将备份保存在其他位置时，才希望删除它。

此处的补充说明：如果在与数据库相同的存储盒中进行备份，则当存储盒出现硬件问题时，备份将不安全。因此，您需要确保有足够的空间用于其他地方（而不是同一台计算机）上的备份。

旁注2：如Simon所指出的，如果空间有限，请花费时间/金钱进行压缩备份。您可以在此问题中看到许多想法：使用SQL Server可以进行最小的备份。

对于3-4 GB的数据库，您的更新统计信息任务不应花费4个小时。您极有可能遇到一些I / O问题，或者您的数据库过于分散，造成了I / O问题。在数据库上运行碎片整理或索引重建，看看是否可以提高性能。如果不是，则启动性能监视器并检查性能瓶颈在哪里。

我不建议您删除唯一的备份，然后再进行新备份。这不是第一次备份失败或实例出现故障，并且建议间隔时间短而无恢复的机会。

那不是解决您问题的方法。弄清楚如何有更大的空间容纳两者，将是解决该问题的正确方法。