在前一篇博文数据压缩简要的基础上，我希望把数据压缩评估自动化。于是有了这篇博文。白皮书推荐对符合如下条件的大型表和索引使用页压缩：表或索引的扫描操作占到所有操作的75%及以上时表或索引的更新操作占到所有操作的20%及以下时注意，这是白皮书中的结论和建议，但是也只能做参考，最为最佳实践的考虑点之一。 此脚本的原始作者是Louis Li。但是它的脚本有一些限制，我在这此基础上做了修改：辅助表
1. 决定压缩哪些对象通过sp_estimate_data_compression_savings 评估在ROW和PAGE压缩时分别节省的空间量。表包含如下数据模式时，会有较好的压缩效果：数字类型的列和固定长度的字符类型数据，但两者的大多数值都不会用到此类型的所有字节。如INT列的值大多数少于1000.允许为NULL的列有很多NULL值列值中有很多一样的值或者相同的前缀。表包含如下数据模式时，压缩
什么是临界点? 注意，我要说的问题是非聚集索引的执行计划从Seek+Lookup变成Table/Clustered Index Scan的临界点。SQL Server的访问数据的IO最小单元是页。 我们知道聚集索引的叶级是数据页，非聚集索引的叶级是指向数据行的指针。所以通过聚集
Hash Warning 事件类可用于监视在哈希操作过程中何时发生哈希递归或哈希终止（哈希释放）。 当生成输入无法装入可用内存时，会发生哈希递归，这将导致输入分割成单独处理的多个分区。 如果这些分区中任何一个仍然大于可用内存，则该分区再拆分成子分区分别进行处理。 此拆分过程将一直持续到每个分区都小于可用内存，或达到最大递归级数（显示在 IntegerData
CXPACKET 已经成为所有等待类型中最常见的一种了。我通常会在多CPU系统的前五位等待类型统计中看见CXPACKET. 联机丛书： 当尝试同步查询处理器交换迭代器时出现。如果针对该等待类型的争用成为问题时，可以考虑降低并行度。 CXPACKET 解释： 当为SQL查询创建一个并行
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
