SQL Server 备份 - 几个问题

Question

我们在周五晚上 9 点运行每周备份作业，我们遇到了一些关于磁盘空间（有时会变得非常低）和性能方面的问题。我们正在考虑精简/优化所发生的事情，并感谢您的意见。

具体来说：

备份过程大约需要 4 小时才能在备份期间更新统计信息。我们可以安全地禁用此过程以节省时间吗？
我们经常会遇到磁盘空间不足的情况，想知道是否应该重新调整这个过程。目前它创建备份，然后删除以前的备份，这就是占用磁盘空间的原因。我们可以安全地删除前一首，然后做备份？

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

Answer 1

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

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

Answer 2

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

Answer 3

1) 我没有看到备份任务和更新统计数据之间的直接关系。所以你可以毫无问题地拆分它们。我会看到更新统计信息部分与对索引进行碎片整理/重建的工作更相关。

2) 即使时间很短，您也不想没有备份。因此，仅当您已将其保存在其他地方时，您才需要删除上次备份。

旁注：如果您在拥有数据库的同一个存储盒上进行备份，那么当存储盒出现硬件问题时，备份将不安全。所以你需要确保你有足够的空间用于其他地方的备份，而不是在同一台机器上。

旁注 2：正如 Simon 已经指定的那样，如果您有空间问题，请在压缩备份上投入时间/金钱。您可以在这个问题中看到很多想法：最小的备份可能……使用 SQL Server。

Answer 4

对于 3-4 GB 的数据库，您的更新统计任务不应花费 4 小时。很可能您有一些 I/O 问题，或者您有一个严重碎片化的数据库，这导致了 I/O 问题。在数据库上运行碎片整理或索引重建，看看是否能提高性能。如果没有，则启动 perfmon 并检查您的性能瓶颈在哪里。