建议
使用数据库系统监视器来跟踪排序活动。
使用合适的索引使排序堆的使用降到最低。
当需要频繁进行大型排序时，增加 SORTHEAP 的值。
如果增加 SORTHEAP，请确定是否还需要调整数据库管理器配置文件中的 SHEAPTHRES 参数。
优化器用排序堆大小来确定存取路径。在更改该参数后请考虑重新绑定应用程序(使用 REBIND PACKAGE 命令)。
理想情况下，应当将排序堆阈值(SHEAPTHRES)参数合理地设置为在数据库管理器实例中设置的 SORTHEAP 参数最大值的倍数。该参数至少应当是实例中任何数据库所定义的最大 SORTHEAP 的两倍。
如何更改这些参数
要更改 SORTHEAP 和 SHEAPTHRES 的值，请运行以下命令:
-- SORTHEAP should be changed for individual database --
db2 "update db cfg for DB_NAME using SORTHEAP a_value"
-- SHEAPTHRES is a database manager parameter --
db2 "update dbm cfg using SHEAPTHRES b_value"
研究步骤
OLTP 应用程序不应该执行大型排序。大型排序在 CPU 和 I/O 资源方面的成本太高了。通常，SORTHEAP 大小的缺省值(256 个 4KB 页)就足够了。事实上，对于高并发性 OLTP，可能希望降低这个缺省值。当需要进一步研究时，可以发出下面这条命令:
db2 "update monitor switches using sort on"
然后，让应用程序运行一会，然后输入:
db2 "get snapshot for database on DBNAME"
根据该输出，可以计算每个事务的排序数目，并可以计算溢出了可用于排序的内存的那部分排序的百分比。
SortsPerTransaction
= (Total Sorts) / (Commit statements attempted + Rollback statements attempted)
PercentSortOverflow
= (Sort overflows * 100 ) / (Total sorts)
经验:如果 SortsPerTransaction 大于 5，它可能表明每个事务的排序太多。如果 PercentSortOverflow 大于 3%，那么可能发生了严重的、未曾预料到的大型排序。发生这种情况时，增加 SORTHEAP 只会隐藏性能问题 - 却无法修正它。这个问题的正确解决方案是通过添加正确的索引改进有问题的 SQL 语句的存取方案。
