完整的DB2 REORG案例
事件：
和資料量相當的另一個數據庫b上，同樣的查詢語句只需要花費1秒鐘，但a要用十幾分鍾。
- 處理辦法：
重建表和索引，清除葉子頁碎片，可以有效提高資料庫效能。
首先查詢syscat.indexes表，檢視STATS_TIME列，重要的使用者表的索引在最近一次runstats的時間。
從結果可以看到，幾乎所有重要的使用者表在建立之後，就從未做過runstats。
所以為了徹底的檢查，哪些表和索引需要進行重建，需要對所有使用者表做runstats檢查。
一個完整的REORG表的過程應該是由下面的步驟組成的：
RUNSTATS:
- 登陸資料庫：
- 1
- 1
對所有使用者表執行runstats（reorgchk加update引數等同於runstats）
- 1
- 2
- 3
- 1
- 2
- 3
REORG:
在檢查結果中，所有帶星號的表或分割槽表、以及索引都需要做reorg重建。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
SQL2217N
REORG 實用程式使用的系統臨時表空間的頁大小必須與表資料 （包括 LONG 或 LOB
列資料）所在表空間的頁大小相匹配。原因基於下列原因碼 原因碼。 說明下面是原因碼的列表：
1.原因與表的資料的臨時表空間的選擇相關。
2.原因與表的 LONG 或 LOB 資料的臨時表空間的選擇相關。 如果對 REORG 實用程式顯式地指定了系統臨時表，那麼 REORG 實用程式使用的系統臨時表空間的頁大小必須與表資料（包括 LONG 或 LOB列資料）所在的表空間的頁大小相匹配，否則必須為長資料指定適當的容器。下列其中一項違反了此限制：
表資料所在的表空間的頁大小與指定的系統臨時表空間的頁大小不同。 該表包含 LONG 或 LOB列，這些列的資料駐留在頁大小與系統臨時表空間和表的規則資料的頁大小不同的表空間中，但是，無法為 LONG 或 LOB資料物件找到具有正確頁大小的表空間。 如果未對 REORG 實用程式指定系統臨時表空間或 LONG臨時表空間，那麼該實用程式在內部查詢系統臨時表空間。在資料庫中不存在使用與表資料頁大小相同的頁大小的系統臨時表空間，或者該系統臨時表空間此時不可用。使用者響應
如果資料庫中不存在使用與表資料頁大小相同的頁大小的系統臨時表空間，請建立一個系統臨時表空間，它使用與該表資料的頁大小相匹配的頁大小。如果表資料的頁大小與
LOB 或 LONG 資料的頁大小不同，那麼應確保使用該頁大小的系統臨時表空間也存在。
如果資料庫中存在使用與表資料頁大小相同的頁大小的系統臨時表空間，但是發出命令時該臨時表空間不可用，請在該系統臨時表空間可用時重新發出該命令。
當前使用的臨時表空間頁大小和該表的頁大小不符合，需要新建一個頁大小和該表的頁大小符合的系統臨時表空間。
檢視各個表空間的pagesize：
- 1
- 1
檢視當前bufferpool：
- 1
- 1
新建一個頁大小為32K的bufferpool
- 1
- 2
- 1
- 2
新建一個臨時表空間，使用剛才那個bufferpool
- 1
- 2
- 1
- 2
重新執行reorg:
- 1
- 1
監視表重組：
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
或：
- 1
- 2
- 3
- 1
- 2
- 3
或：
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
完成！
參考資料：
重組處理期間將發生的最大重組階段數。此項僅適用於經典（離線）重組。值的範圍為 2 到 4（SORT, BUILD,
REPLACE,INDEX_RECREATE）。此值還可能指示執行重組時為了從多維叢集 (MDC)
表中回收擴充套件資料塊而完成的工作總量。執行這樣的重組時，此值是 3（SCAN、DRAIN 和 RELEASE）。對於分割槽表來說，重組是逐個資料分割槽進行的。對於傳統表重組而言，可能的階段如下所示（這些階段與它們在 sqlmon.h
中的相應定義一起列示）： 排序：SQLM_REORG_SORT 構建：SQLM_REORG_BUILD
替換：SQLM_REORG_REPLACE 索引重新建立：SQLM_REORG_INDEX_RECREATE
字典構建：SQLM_REORG_DICT_SAMPLE
對於分割槽表而言，在資料分割槽的“替換”階段完成後，可以直接進入分割槽索引（如果有的話）的“索引重建”階段。僅當每個資料分割槽上的所有先前階段成功完成後，reorg_phase
元素才會指示“索引重新建立”階段。在 XDA 物件壓縮期間，XML 資料重組階段涉及識別表的 XML 儲存器物件。XML 字典構建階段涉及嘗試為 XML
儲存器物件建立壓縮字典。對於 XDA 物件壓縮而言，可能的兩個階段如下所示： XML 重組：SQLM_REORG_XML_DATA XML
字典構建：SQLM_REORG_XML_DICT_SAMPLE 對於分割槽表，在執行擴充套件資料塊回收操作時，可能的階段如下所示：
掃描：SQLM_REORG_SCAN 漏出：SQLM_REORG_DRAIN 釋放：SQLM_REORG_RELEASE
- 1
- 2
- 1
- 2
分割槽表reorg
RMADMIN.RMOBJECTS是分割槽表，reorg需要指定data partition number名稱，
總共有62個分割槽，標記F1的有39個分割槽，2個索引分割槽標記F8
Index: RMADMIN.IDX_OBJ_STATUS
Data Partition: EXCEP2
Index: SYSIBM.SQL120528224438680
Data Partition: EXCEP2
參考:
查詢該表分割槽情況：
select * from SYSCAT.DATAPARTITIONS where tabname='RMOBJECTS'
- 1
- 1
