如何从SQL Server 2008中的备份中排除索引


19

每晚的完整(和定期差异)备份正变得非常大,这主要是由于表上的索引数量所致。大约一半的备份大小由索引组成。

我们正在使用简单恢复模型进行备份。

有没有办法通过使用FileGroups或其他文件分区方法从备份中排除索引?

如果也可以将其扩展到全文目录,那就太好了。

Answers:


15

如果切换到完全恢复模式,则可以使用文件组来执行此操作,但这确实非常笨拙。您将数据保留在主文件组中,并将索引放在一个单独的(非默认值,这是关键)文件组中。

然后,您将备份错开,以便每晚进行一次主数据库的文件组备份,每隔X分钟执行一次事务日志备份。

灾难发生时,您可以自行还原主文件组。数据突然联机,但索引不联机。但是,要恢复正常状态,您需要将该数据导出到新的干净数据库中并从那里添加索引。您不能在不恢复所有文件组的情况下使数据库完全联机,也不能说“我不再需要其他文件组了”。

有关其工作原理的更多信息,请查看我有关文件组还原的视频教程。


呵呵,我已经将非聚集索引移动到了自己的文件组中;Simple Recovery模式完全使我受阻。索引实际上比数据大-它是如何嘲笑我的!哦,好吧,也许第3方会发布魔术子弹提示提示 :)
Jarrod Dixon

1
也许,也许,您将免费获得许可。;-)
布伦特·奥扎尔

5

老实说,即使您克服了其他人在这里提出的其他问题,您也确实不想这样做。

当您在紧急情况下还原备份时,您不想等待索引重建,而在这样做之前,您将遭受可恶的性能。

我想不出要还原没有索引的备份的情况,因此,在所有情况下,您实际上都想同时备份它们。

您可能需要寻找该问题的其他解决方案...

-亚当


1
IMO非常推定:“您不想等待索引重建”
Jeff Atwood,

2
是的,但是请记住,我在这里概括。我还没有说过,在更多情况下,最好放弃索引并进行重建,而不是在某些情况下最好备份索引并避免进行重建。换句话说,通常情况下更好,除非有特殊情况需要,否则应该在备份方面犯错。话虽如此,每种情况都是不同的。我很好奇,知道重建SO索引需要花费多长时间,以及在完成索引之前网站的性能会遭受多少损失(假设它在重建期间已启动)。
亚当·戴维斯

长期档案备份是我现在正在查看的特定用例,这使我想到了这个问题。我有一个已完成的项目,不再希望数据库联机,但是也不需要使用比必要的更大的备份文件来整理我们的网络驱动器。我不想丢失索引定义,但是如果我不得不再次恢复它,也不会介意重建它们。
richardtallent

3

听起来好像不支持。从此错误报告信息

对此有很多兴趣,所以我将对幕后发生的事情以及实现此功能的含义进行更详细的介绍。某些类型的索引页被分离到单独的分配单元中,而另一些类型则与数据页混合在一起。当前我们仅查看分配位图以查看是否分配了扩展区,现在我们必须进入并解释存储在每个分配单元中的内容。此外,我们现在将不能仅对复制数据的数据文件进行线性扫描,而要在文件中四处跳过。所有这些对数据结构的解释都会极大地减慢备份速度。还原变得更加有趣,因为必须修复许多结构来解决备份中的漏洞。否则,您将拥有指向未备份页面的分配映射,因此其中包含垃圾等。因此,实施此操作意味着我们将节省更少的数据,花费更长的时间,并且要花很多时间。恢复更长的时间。要考虑的另一个方面是,要使其完全正常,将需要大量的工程工作。尽管这不是表面上的问题,但请考虑这意味着您可能想看到的其他功能将无法构建。


对于全文索引来说,这不是问题,不是吗?那些往往很大。
Michael Teper

1

可能是个疯狂的主意,但这是可行的。

  1. 删除占用大量空间的非聚集索引
  2. 做一个备份
  3. 重新创建您删除的索引

当然,只有在数据库允许一天中有一些停机时间的情况下,您才能真正做到这一点。

另外,不要删除群集索引,因为SQL Server将浪费大量时间将它们转换为堆。

购买额外的磁盘空间似乎更容易解决吗?

您是否考虑过进行压缩备份?这是2008年的新功能,可能是您的选择。


是的,我们已经为备份启用了压缩功能,但是内置的压缩​​功能并不是那么好。实际上,我们采取了一个周末的非压缩备份,然后将其压缩7zip以供我们的开发人员使用。它的大小约为1/3,但运行起来确实需要一些时间!
贾罗德·迪克森

至于数据库停机时间,我们真的可以在没有将serverfault.comstackoverflow.com都尽可能多的情况下生存吗?我为那个想法感到颤抖:)
贾罗德·迪克森

我自己还没有测试过,但我也怀疑过。它不是非常可配置的。如果你还在寻找在压缩作为一个选项看看SQL光速(昂贵,但真棒,而且价格也面议)和展鹏的SQL备份。非常可配置的出色结果
尼克·卡瓦迪亚斯
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.