目前，我的生产服务器上有几个大型数据库，我使用第二个 SQL 服务器进行报告。我使用事务复制维护数据库的报告副本。
由于我们最近升级到 EE，我想在报告服务器上的几个大表上启用数据压缩以节省磁盘空间（我目前还没有准备好在生产服务器上启用它）
有没有人试过这个，如果有的话有没有隐藏的陷阱？
我能看到的唯一缺陷是如果表被重新快照，复制的表将失去其压缩。由于所有额外的报告索引也将丢失，这不是我会轻易承担的事情。
AskOverflow.Dev
目前，我的生产服务器上有几个大型数据库，我使用第二个 SQL 服务器进行报告。我使用事务复制维护数据库的报告副本。
由于我们最近升级到 EE，我想在报告服务器上的几个大表上启用数据压缩以节省磁盘空间（我目前还没有准备好在生产服务器上启用它）
有没有人试过这个，如果有的话有没有隐藏的陷阱？
我能看到的唯一缺陷是如果表被重新快照，复制的表将失去其压缩。由于所有额外的报告索引也将丢失，这不是我会轻易承担的事情。
这样做没有真正的陷阱。您只需要注意订阅服务器上的 CPU 会略有增加，因此如果您已经受 CPU 限制，这可能不是最好的前进方式。
您可以考虑使用快照前脚本或快照后脚本，以帮助确保在您需要运行另一个快照（并添加所需的任何其他索引）时保持索引压缩。
执行压缩时请注意，您可能会遇到事务日志增长，就像您重建任何其他索引时一样。在 tempdb 中排序通常是类似的好习惯。
您是否考虑过在您的订阅上创建非聚集列存储索引。
列存储索引将为您带来巨大的压缩率优势。
我刚刚使用 SQL Server 2016 Developer Edition 对此进行了测试，它允许我在我的订阅上创建非聚集列存储索引。
我以前尝试过类似的方法，发现磁盘空间大大节省了。
但是，我发现与未压缩的表相比，需要从磁盘读取数据的查询更快，而与未压缩的表相比，数据已经缓冲在 RAM 中的查询变得更慢。
我将调查留在那里，但根据 RAM 或存储的相对丰富程度，我建议仅按分区或表压缩不常用的数据。（但也许您不能轻松地对表进行分区，因为分区也没有在发布者上完成。）
我确实遇到过表格神秘地失去压缩的情况，这可能是由于某些不支持压缩设置的重建脚本。