db2 参数 sortheap sheapthres

 SORTHEAP和SHEAPTHRES SORTHEAP 是一个数据库配置参数，它定义了私有排序或共享排序所使用的私有内存页的最大数目。每个排序都有一个独立的排序堆，这是由数据库管理器在需要的时候分配的。通常，大家都能理解得很好的是，当一个排序所需的内存量超过了SORTHEAP时，就会发生排序溢出；理解得不够好的一点是，如果统计信息已过时，或者数据有偏差，并且没有收集到发布的统计信息，此时一旦 DB2 请求一个太小的堆，而实际的排序操作超出了所请求的量，也会发生溢出。因此，使统计信息保持最新十分重要。此外，应确保排序不是一个丢失的索引的结果。如果排序是私有排序，那么该参数会影响代理程序的私有内存；如果排序是共享排序，那么该参数将影响数据库的共享内存。每个排序都有单独的由数据库管理器按需分配的排序堆。在排序堆中对数据进行排序。如果由优化器来指导排序堆大小的分配，那么用优化器提供的信息来分配的排序堆的大小要小于由该参数所指定的排序堆大小。 SHEAPTHRES也是一个数据库管理器配置参数。私有排序和共享排序所使用内存的来源不一样。共享排序内存区的大小是在第一次连接到数据库时根据 SHEAPTHRES值以静态方式预先确定的。私有排序内存区的大小则是不受限制的。对于私有排序和共享排序，应用 SHEAPTHRES参数的方式也不同：对于私有排序，SHEAPTHRES 是对私有排序在任何给定的时间可以消耗的全部内存的实例级"软"限制。当实例的总私有排序内存消耗量达到这一限制时，为其他进入的私有排序请求而分配的内存会大大减少。对于共享排序，SHEAPTHRES 是对共享排序在任何给定的时间可以消耗的全部内存的数据库级"硬"限制。当达到这一限制时，不允许有其他共享排序内存请求，直到总的共享内存消耗量回落到 SHEAPTHRES 所指定的限制之下。使用排序堆的操作示例包括内存中表的哈希连接和操作。SHEAPTHRES的显式定义可以防止数据库管理器将过多数量的内存用于大量排序。 1. 建议使用数据库系统监视器来跟踪排序活动；使用合适的索引使排序堆的使用降到最低；当需要频繁进行大型排序时，增加SORTHEAP的值；如果增加 SORTHEAP，请确定是否还需要调整数据库管理器配置文件中的SHEAPTHRES参数；优化器使用排序堆大小来确定存取路径。在更改该参数后请考虑重新绑定应用程序(使用 REBIND PACKAGE 命令)；理想情况下，应当将排序堆阈值参数(SHEAPTHRES)合理地设置为在数据库管理器实例中设置的SORTHEAP参数最大值的倍数。该参数至少应当是实例中任何数据库所定义的最大 SORTHEAP的两倍。 2. 如何更改这些参数要更改 SORTHEAP和SHEAPTHRES的值，请运行以下命令： -- SORTHEAP是数据库级别参数-- db2 -v update db cfg for DB_NAME using SORTHEAP a_value -- SHEAPTHRES是实例级别参数-- db2 -v update dbm cfg using SHEAPTHRES b_value db2 -v terminate 3. 调优步骤对于OLTP 应用程序，不应该执行大型排序。大型排序在CPU和I/O 资源方面的消耗成本太高了。通常，SORTHEAP的默认大小(256个4KB 页)就足够了。事实上，对于高并发性 OLTP，您可能希望降低这个默认值。当需要进一步研究时，可以发出下面这条命令： db2 -v update monitor switches using sort on 然后，让您的应用程序运行一会儿，然后运行： db2 -v get snapshot for database on sample 查看如下输出结果： Total sort heap allocated = 0 Total sorts = 1 Total sort time (ms) = 0 Sort overflows = 0 Active sorts = 0 Commit statements attempted = 1 Rollback statements attempted = 0 Dynamic statements attempted = 4 Static statements attempted = 1 Binds/precompiles attempted = 0 根据该输出，可以计算每个事务的排序数目，并计算溢出了可用于排序的内存的那部分排序的百分比。 SortsPerTransaction = (Total Sorts) / (Commit statements attempted + Rollback statements attempted) PercentSortOverflow = (Sort overflows * 100 ) / (Total sorts) 经验：如果 SortsPerTransaction 大于5，它可能表明每个事务的排序太多。如果 PercentSortOverflow 大于3%，那么可能发生了严重的、未曾预料到的大型排序。发生这种情况时，增加 SORTHEAP 只会隐藏性能问题，却无法修正它。这个问题的正确解决方案是通过添加正确的索引来改进有问题的SQL 语句的存取方案。对于OLTP，一开始最好是设为128；对于OLAP，则设置在4096 - 8192 之间。如果有很多的"Sort overflows" (两位数)，那么很可能需要增加 SORTHEAP。如果 "Number of hash join overflows" 不为0，则按照 256 逐次增加 SORTHEAP，直到它为0。如果 "Number of small hash join overflows" 不为0，则按10%的比例逐次增加 SORTHEAP，直到小散列连接溢出数为0。