目前,我的生产服务器有几个大型数据库,我使用第二个SQL服务器进行报告。我使用事务性复制维护数据库的报告副本。
由于我们最近升级到EE,我希望在报表服务器上的几个大型表上启用数据压缩,以节省磁盘空间(我目前还没有准备好在生产服务器上启用它)
有没有人试过这样做,如果有,有什么隐藏的陷阱吗?
我能看到的唯一缺陷是,如果重新快照表,复制的表将失去压缩。由于所有额外的报告索引也将丢失,这不是我会轻易承担的事情。
发布于 2016-11-03 04:29:19
我以前尝试过这样的方法,并且在磁盘空间中发现了大量的节省。
但是,我发现需要从磁盘读取数据的查询比未压缩的表要快,而在RAM中已经缓冲数据的查询比未压缩的表要慢。
我把我的调查放在那里,但是根据RAM或存储的相对丰富程度,我建议只压缩很少使用的数据,无论是分区还是表。(但也许您不能轻松地对表进行分区-分区也不是在发布服务器上完成的。)
我确实有些情况下,表神秘地失去了它的压缩,可能是由于一些重建脚本,不遵守压缩设置。
发布于 2016-11-02 16:19:02
做这件事没有什么真正的陷阱。您只需要意识到订阅服务器上的CPU将略有增加,所以如果您已经绑定了CPU,那么它可能不是最佳的前进途径。
您可以考虑使用任何一个前后快照脚本来帮助确保在需要运行另一个快照(并添加所需的任何其他索引)时保持索引压缩。
在执行压缩时,请注意您可能会经历事务日志的增长,就像您重新构建任何其他索引时一样。对类似的事情来说,在tempdb中进行排序通常是一个很好的实践。
发布于 2016-11-02 17:26:19
是否考虑在订阅上创建非聚集柱状商店索引。
Columnstore索引将为您提供大量压缩速率的好处。
我刚刚用SQLServer2016Developer版本对此进行了测试,它允许我在订阅上创建非聚集列存储索引。
https://dba.stackexchange.com/questions/154058
复制相似问题