今天看了一篇文章，覺得不管怎么強調sortheap的重要性都不為過。理由我后面肯定會寫詳細的，這里寫記錄下，占個位置：
----2007.07.10.00。13（沒想到是10號還以為9號呢 ，9號剛過
）
========================
感覺學的不是很好，沒有達到目標，但還是把這2天學的寫上吧 。
1.sortheap在數據庫配置說明上是這樣的：定義要用于專用排序的專用內存頁的最大數目，或者要用于共享排序的共享內存頁的最大數目。現在這個項目并沒有啟動分區并行性，所以此參數只是表示要用于專用排序的專用內存頁的最大數目。不知道是我沒理解好，還是db2沒有說好，其實這個參數還有個很重要的作用：數據庫在執行散列連接sql的時候也用到此內存區域。db2 對2個表進行連接的時候，只有3種類型：嵌套，合并，散列。其中散列連接用的最多（我在執行復雜sql的時候是這樣的，簡單的沒有測試過大家可以測試下）。進行散列連接的時候，數據庫會把其中一個表的內容復制到sortheap對應的內存中，如果sortheap對應的內存不夠大，就會吧余下的數據庫復制到臨時表空間中。然后進行連接比較。可以想想操作內存和操作硬盤的差別吧，所以我們應盡量大的設置sortheap，使他不溢出到硬盤中，或者很少溢出。（關于上面3中嵌套，合并，散列連接類型，可以看下面的附件，附件中有很詳細的說明）
2. 查看是否溢出的方法：
大家執行下面的命令： db2 gen snapshot for db on 數據庫名 （這個命令不需要打開db2的快照開關，db2有些默認的快照信息）。在輸出的信息中查找下面的信息：
已分配的專用排序堆總數 = 0
已分配的共享排序堆總數 = 0
共享排序堆高水位標記 = 0
總計排序 = 34600
總計排序時間（毫秒） = 35491
排序溢出 = 2384
活動排序數 = 0
和
散列連接數 = 38808
散列循環數 = 0
散列連接溢出數 = 534
小散列連接溢出數 = 1
排序溢出 /總計排序 可以得到溢出比例 （如果溢出比例大于 3 個百分點，那么在應用程序 SQL 中會出現嚴重的或意外的排序問題。因為正是溢出的存在表明發生了大的排序，所以理想的情況是發現沒有排序溢出或至少其百分比小于一個百分點。
如果出現過多的排序溢出，那么“應急”解決方案是增加SORTHEAP的大小。然而，這樣做只是掩蓋了真實的性能問題。相反，您應該確定引起排序的 SQL 并更改該 SQL、索引或群集來避免或減少排序開銷。如果溢出比例大于 5 （作為一種經驗之談），那么每個事務的排序數可能很大。雖然某些應用程序事務執行許多小的組合排序（它們不會溢出并且執行時間很短），但是它消耗了過多的 CPU。當SortsPerTX很大時，按我的經驗，這些機器通常會受到 CPU 的限制。確定引起排序的 SQL 并改進存取方案（通過索引、群集或更改 SQL）對提高事務吞吐率是極為重要的。）
散列連接數 就是在執行sql的時候進行散列連接的數目。這里只說下散列循環數 的意義，其他參數的意義在下面的附件中都有很詳細的說明： 我在測試的時候，把sortheap設置為16個頁，然后執行復雜的sql，散列循環數有值，而且很高。一般看到散列循環數有值就要注意，他說明你的sortheap或者SHEAPTHRES（實例級參數）太低了。現在的測試情況就說明sortheap太低了。另外一種情況SHEAPTHRES太低的原因： SHEAPTHRES已經分配給前面的代理進程了，再有代理進程申請sortheap的時候，SHEAPTHRES已經達到上限了，這個時候db2就會給申請sortheap的進程很小的值，此時代理進程進行散列連接的時候就需要把很多數據放到硬盤上，這個時候就會導致散列循環數值很高，這個時候大家可以增加 SHEAPTHRES進行觀察。
3.查看排序溢出的sql方法： 首先打開快照監視器： db2 update monitor switches using sort on statements on ;
然后過段時間（1分鐘就可以了）執行 get snapshot for all on 數據庫名；
在輸出的信息中查找：語句排序溢出 = 1 ，看對應的sql就知道了，對sql的執行計劃分析下就明白了。
記得在測試完要關閉 快照開關： db2 update monitor switches using sort off statements off;