5. 内存排序
OLTP 应用程序不应该执行大的排序。它们在 CPU、I/O 和所用时间方面的成本极高，而且将使任何 OLTP 应用程序慢下来。因此，256 个 4K 页(1MB)的缺省SORTHEAP大小(1MB)应该是足够了。您也应该知道排序溢出的数量和每个事务的排序数。
请发出以下命令：
并查找以下行：
2 Total sorts = 1
3 Total sort time (ms)= 8
4 Sort overflows = 0
5 Active sorts = 0
6 Commit statements attempted = 3
7 Rollback statements attempted = 0
8 Let transactions = Commit statements attempted + Rollback
9 statements attempted
10 Let SortsPerTX= Total sorts / transactions
11 Let PercentSortOverflows = Sort overflows * 100 / Total sorts
如果PercentSortOverflows ((Sort overflows * 100) / Total sorts )大于 3 个百分点，那么在应用程序 SQL 中会出现严重的或意外的排序问题。因为正是溢出的存在表明发生了大的排序，所以理想的情况是发现没有排序溢出或至少其百分比小于一个百分点。
如果出现过多的排序溢出，那么“应急”解决方案是增加SORTHEAP的大小。然而，这样做只是掩盖了真实的性能问题。相反，您应该确定引起排序的 SQL 并更改该 SQL、索引或群集来避免或减少排序开销。
如果SortsPerTX大于 5 (作为一种经验之谈)，那么每个事务的排序数可能很大。虽然某些应用程序事务执行许多小的组合排序(它们不会溢出并且执行时间很短)，但是它消耗了过多的 CPU。当SortsPerTX很大时，按我的经验，这些机器通常会受到 CPU 的限制。确定引起排序的 SQL 并改进存取方案(通过索引、群集或更改 SQL)对提高事务吞吐率是极为重要的。
4. 表访问
对于每个表，确定 DB2 为每个事务读取的行数。您必须发出两个命令：
2 db2 "get snapshot for tables on DBNAME"
在发出第一个命令以后，确定发生了多少个事务(通过取Commit statements attempted和Rollback statements attempted之和 - 请参阅 技巧 3)。
在发出第二个命令以后，将读取的行数除以事务数(RowsPerTX)。在每个事务中，OLTP 应用程序通常应该从每个表读取 1 到 20 行。如果您发现对每个事务有成百上千的行正被读取，那么发生了扫描操作，也许需要创建索引。(有时以分布和详细的索引来运行 runstats 也可提供了一个解决的办法。)
2 Snapshot timestamp = 09-25-2000
3 4:47:09.970811
4 Database name= DGIDB
5 Database path= /fs/inst1/inst1/NODE0000/SQL00001/
6 Input database alias= DGIDB
7 Number of accessed tables= 8
8 Table List
9 Table Schema= INST1
10 Table Name= DGI_
11 SALES_ LOGS_TB
12 Table Type= User
13 Rows Written= 0
14 Rows Read= 98857
15 Overflows= 0
16 Page Reorgs= 0
Overflows 的数量很大就可能意味着您需要重组表。当由于更改了行的宽度从而 DB2 必须在一个不够理想的页上定位一个行时就会发生溢出。
