MDC 以及空間回收簡介
MDC 是在 DB2 V8 中引入的，通過它可以在物理上將在多個維上具有類似值的行聚集在一起放在磁盤上。這種聚集能為常見分析性查詢提供高效的 I/O。例如對於 Product=car，Region=East，並且 SaleMonthYear = Jan09 的所有行，可以將它們存儲在相同的存儲位置，即所謂的塊（block）。一個塊的大小等於表空間的擴展數據塊（extent）大小，擴展數據塊是磁盤上的一組連續頁，所以將這些具有類似值的行在物理上是存放在連續的數據頁上。
在 MDC 表中，塊映射（block map）會跟蹤屬於這個表的所有擴展數據塊，並且指示哪些塊或擴展數據塊上包含數據以及哪些塊或擴展數據塊上沒有包含數據。包含數據的塊標記為“正在使用”(“IN USE”)。每當發生刪除或轉出時，相應的塊條目不再標記為“正在使用”，而是被釋放以供 MDC 表復用。但是表空間中的其他對象無法使用這些擴展數據塊。
可以通過重組 MDC 表來從 MDC 表釋放這些可用數據擴展數據塊。在 DB2 9.7 之前只能在完全脫機的情況進行重組，在 DB2 9.7 中開始支持聯機對 MDC 進行重組以釋放擴展數據塊。DB2 9.7 中的 REORG TABLE 命令增加了 RECLAIM EXTENTS ONLY 選項，可以使用這個選項來釋放 MDC 表專用的擴展數據塊，並且使該空間可供表空間內其他數據庫對象使用。該選項還允許控制在釋放擴展數據塊期間對 MDC 表的並行訪問，寫訪問權限為缺省訪問權限，還可選擇讀訪問權限和無訪問權限來控制並行訪問。
除了使用 REORG TABLE 命令來釋放擴展數據塊，也可以使用 db2Reorg API 來回收擴展數據塊。
另外，從 MDC 表釋放擴展數據塊只支持在 DMS 表空間。
自動維護簡介
DB2 V9 中引入了自動維護功能，即自動數據庫備份、自動統計信息更新以及在必要時重組表和索引，基於這些新的特性，將大大簡化我們在實際維護數據庫過程中的工作量。
在 DB2 9.7 中，自動維護功能可用於釋放擴展數據塊部分。為了啟用重組以釋放 MDC 表中的擴展數據塊，AUTO_MAINT、AUTO_TBL_MAINT 和 AUTO_REORG 數據庫配置參數必須全部設置為“ON”。可通過使用“配置自動維護”向導或命令行來進行這些數據庫配置參數的配置。在啟用了數據庫分區功能的 DB2 實例上，必須在目錄分區上發出對這些參數的配置。
維護策略可以控制何時執行 MDC 表的自動重組以釋放未使用的擴展數據塊。DB2 的系統存儲過程 AUTOMAINT_SET_POLICY 和 AUTOMAINT_SET_POLICYFILE 用來設置此維護策略，這裡的策略都是用 XML 來存儲的。
接下來我們通過實際操作來了解如何實現自動回收 MDC 中的空閒空間。
准備工作
我們先創建一個新的數據庫名字叫做 MYDB，或者也可以使用一個已有的數據庫。本文中所有操作都是在 LinuxAMD64 平台上的 DB2 9.7 進行，在其他的平台上也可以得到相似的結果，但不能保證完全一致。
創建數據庫以及表空間的命令如清單 1 所示。需要注意的是這裡的表空間是 DMS 類型。
清單 1. 創建數據庫
db2start
db2 CREATE DB MYDB
db2 CONNECT TO MYDB
db2 "create tablespace tbs1 managed by database using (FILE 'tbs1' 10M) autoresize yes"
db2 list tablespaces show detail
Tablespace ID = 4
Name = TBS1
Type = Database managed space
Contents = All permanent data. Large table space.
State = 0x0000
Detailed explanation:
Normal
Total pages = 2560
Useable pages = 2528
Used pages = 96
Free pages
= 2432
High water mark (pages) = 96
Page size (bytes) = 4096
Extent size (pages) = 32
Prefetch size (pages) = 32
Number of containers = 1
DB2 V9 中引入了自動維護功能，即自動數據庫備份、自動統計信息更新以及在必要時重組表和索引，基於這些新的特性，將大大簡化我們在實際維護數據庫過程中的工作量。
在 DB2 9.7 中，自動維護功能可用於釋放擴展數據塊部分。為了啟用重組以釋放 MDC 表中的擴展數據塊，AUTO_MAINT、AUTO_TBL_MAINT 和 AUTO_REORG 數據庫配置參數必須全部設置為“ON”。可通過使用“配置自動維護”向導或命令行來進行這些數據庫配置參數的配置。在啟用了數據庫分區功能的 DB2 實例上，必須在目錄分區上發出對這些參數的配置。
維護策略可以控制何時執行 MDC 表的自動重組以釋放未使用的擴展數據塊。DB2 的系統存儲過程 AUTOMAINT_SET_POLICY 和 AUTOMAINT_SET_POLICYFILE 用來設置此維護策略，這裡的策略都是用 XML 來存儲的。
接下來我們通過實際操作來了解如何實現自動回收 MDC 中的空閒空間。
准備工作
我們先創建一個新的數據庫名字叫做 MYDB，或者也可以使用一個已有的數據庫。本文中所有操作都是在 LinuxAMD64 平台上的 DB2 9.7 進行，在其他的平台上也可以得到相似的結果，但不能保證完全一致。
創建數據庫以及表空間的命令如清單 1 所示。需要注意的是這裡的表空間是 DMS 類型。
清單 1. 創建數據庫
db2start
db2 CREATE DB MYDB
db2 CONNECT TO MYDB
db2 "create tablespace tbs1 managed by database using (FILE 'tbs1' 10M) autoresize yes"
db2 list tablespaces show detail
Tablespace ID = 4
Name = TBS1
Type = Database managed space
Contents = All permanent data. Large table space.
State = 0x0000
Detailed explanation:
Normal
Total pages = 2560
Useable pages = 2528
Used pages = 96
Free pages
= 2432
High water mark (pages) = 96
Page size (bytes) = 4096
Extent size (pages) = 32
Prefetch size (pages) = 32
Number of containers = 1
可以看到，每次插入一行具有不同的 c1 值的數據都會占用一個擴展數據塊（2240 - 2208 = 32 page ， 2208 - 2112 = 96 page ），4 條具有不同 c1 值的數據共占用 4 個數據塊。如果我們接著向表中插入具有相同 c1 值的數據則將被放置相應的塊中，例如 (1,2) 將被放置到與 (1,1) 相同的塊或擴展數據塊中，直至當前的塊沒有足夠的空間而占用新的擴展數據塊。
當前表空間 tbs1 中空閒的頁為 2112 個。將之前插入的 4 條數據全部刪除然後再次查看表空間，表空間 tbs1 空閒的頁仍為 2112 個，也即是說雖然表中的數據全部刪除了但是之前已經占用了的擴展數據塊沒有釋放，如清單 4 所示。
清單 4. 刪除數據
db2 "delete from mdctab"
DB20000I The SQL command completed successfully.
db2 list tablespaces show detail
Used pages = 416
Free pages = 2112
手動釋放 MDC 中的空間
現在使用 REORG 的 RECLAIM EXTENTS ONLY 選項來釋放這些擴展數據塊。對整個表進行不帶選項的 REORG 也可以釋放空閒空間，但必須是脫機執行，而使用 RECLAIM EXTENTS ONLY 選項則可以聯機執行，如清單 5 所示。
清單 5. 回收 MDC 中的空閒空間
db2 reorg table mdctab allow write Access
SQL0104N An unexpected token "write" was found following "ALLOW". Expected tokens may
include: "NO". SQLSTATE=42601
db2 reorg table mdctab RECLAIM EXTENTS ONLY allow write Access
DB20000I The REORG command completed successfully.
Used pages = 320
Free pages = 2208
在清單 9 中可以看到使用 RECLAIM EXTENTS ONLY 選項進行 REORG 時可以指定 ALLOW WRITE ACCESS 也就是在執行 REORG 的同時允許其他的應用程序對該表進行寫操作。而如果對不帶該選項的 REORG 命令指定 ALLOW WRITE Access 則會報錯。另外可以看到使用該選項 REORG 之後空閒的擴展數據塊已經被釋放，通過計算可以看出釋放了 3 個擴展數據塊（2208 - 2112 = 96 page ），另外一個擴展數據塊是作為保留的塊，不會被釋放。
至此，我們已經了解 DB2 9.7 中使用 REORG 的 RECLAIM EXTENTS ONLY 選項聯機釋放 MDC 表中的空閒空間，接下來我們來看如何自動的完成回收工作。
利用自動維護策略自動回收
首先重復使用上文中的語句創建 MDC 表並插入、刪除數據（清單 2、3 和 4），獲得一個具有空閒空間的 MDC 表，然後開始設置自動維護策略。
設置自動維護策略
設置自動維護策略可使用“配置自動維護”向導或命令行來進行，本文中使用的是命令行調用存儲過程 AUTOMAINT_SET_POLICY 的方式。AUTOMAINT_SET_POLICY 有兩個輸入參數，第一個是自動維護的類型，可用的類型包括 AUTO_REORG、AUTO_RUNSTATS 和 AUTO_DB_BACKUP 這三種，另一個是用來指定配置內容的 XML 文檔。
另外我們也可以用 AUTOMAINT_SET_POLICYFILE 的方式，由於其通常需要在嵌入式 C 程序中調用，為了便於讀者理解本文中沒有采用這種方式，讀者可以自行實踐。
設置自動回收 MDC 空閒空間是自動 REORG 策略的一部分，因此使用“AUTO_REORG”作為 AUTOMAINT_SET_POLICY 的第一個輸入參數。而在作為配置內容的 XML 文檔中需要指定 REORG 選項 reclaimExtentsSizeForMDCTables，需要為該選項設定一個以 KB 為單位的阈值，當數據庫中的 MDC 表中可釋放的空間大於這個阈值時才執行自動回收。另外作為一個完整的自動 REORG 策略的配置，還需要指定 REORG 的表的范圍，默認是包括系統表的所有的表。這裡我們把完整的命令寫入文件中，並通過 db2 – tvf 方式執行，如清單 6 所示。
清單 6. 設置自動 REORG 策略
vi setAutoReclaim.sql
CALL SYSPROC.AUTOMAINT_SET_POLICY
('AUTO_REORG', BLOB( '
<?XML version="1.0" encoding="UTF-8"?>
<DB2AutoReorgPolicy xmlns="http://www.ibm.com/XMLns/prod/db2/autonomic/config">
<ReorgOptions reclaimExtentsSizeForMDCTables ="1" />
<ReorgTableScope>
<FilterClause />
</ReorgTableScope>
</DB2AutoReorgPolicy>
')
);
db2 -tvf setAutoReclaim.sql
CALL SYSPROC.AUTOMAINT_SET_POLICY ('AUTO_REORG', ...
Return Status = 0
在清單 6 中我們設定了 reclaimExtentsSizeForMDCTables ="1"，也就是說只要 MDC 中有多於 1KB 的空閒空間，在啟用了自動維護的情況下 DB2 服務器就會自動維護從而回收這些空閒空間。這個設定當然只是為了便於我們的示例演示，在實際的應用中建議根據實際情況設定合理的阈值。
設置自動維護窗口
設置了自動 REORG 的維護策略還不夠，還需要指定一個維護窗口，也就是指定 DB2 可以調度並運行自動維護任務的時段。一個 DB2 數據庫最多可以指定兩個維護窗口：在線窗口（用於使維護對象保持可訪問狀態的維護操作）和離線窗口（在此期間用戶不能訪問進行維護的對象），其中離線窗口是可選的。維護窗口通常由起始時間和持續時間組成。這裡為了演示方便設定了一個非常大的維護窗口，如清單 7 所示。在實際的應用環境中，需要根據實際應用程序的不同情況進行設定，宗旨是選擇一個對訪問數據庫的應用程序影響最小的一個時間段。
清單 7. 設置自動維護窗口
vi setmaintenanceWindow.sql
CALL SYSPROC.AUTOMAINT_SET_POLICY
('MAINTENANCE_WINDOW',BLOB('
<?XML version="1.0" encoding="UTF-8"?>
<DB2MaintenanceWindows
xmlns="http://www.ibm.com/XMLns/prod/db2/autonomic/config" >
<!-- Online Maintenance Window -->
<OnlineWindow Occurrence="During" startTime="00:00:00" duration="24" >
<DaysOfWeek>Mon Tue Wed Thu Fri</DaysOfWeek>
<DaysOfMonth>All</DaysOfMonth>
<MonthsOfYear>All</MonthsOfYear>
</OnlineWindow>
<!-- Offline Maintenance Window -->
<OfflineWindow Occurrence="During" startTime="00:00:00" duration="24" >
<DaysOfWeek>All</DaysOfWeek>
<DaysOfMonth>All</DaysOfMonth>
<MonthsOfYear>All</MonthsOfYear>
</OfflineWindow>
</DB2MaintenanceWindows>
')
);
查看自動維護策略
設定了上述兩個策略之後我們可以用 AUTOMAINT_GET_POLICYFILE 存儲過程來查看當前的自動維護策略，如清單 8 所示。
清單 8. 查看策略設置
CALL SYSPROC.AUTOMAINT_GET_POLICYFILE('AUTO_REORG','reorg_cfg.XML')
Return Status = 0
more ~/sqllib/tmp/reorg_cfg.XML < 需要根據實際安裝路徑決定該文件的路徑 >
<XML 文檔的內容與清單 6 一致，在文中省略 >
CALL SYSPROC.AUTOMAINT_GET_POLICYFILE('MAINTENANCE_WINDOW','window.XML')
Return Status = 0
more ~/sqllib/tmp/window.XML < 需要根據實際安裝路徑決定該文件的路徑 >
<XML 文檔的內容與清單 7 一致，在文中省略 >
這裡需要注意的是，得到的 XML 文檔的存放路徑是 SQLLIB/temp 而不是執行命令時的當前路徑，如果在存儲過程的參數中指定了相對路徑名，則絕對路徑則是 SQLLIB/temp 接上指定的相對路徑。
也可以 AUTOMAINT_GET_POLICY 存儲過程查看策略的設置，由於其通常需要在嵌入式 C 程序中調用，為了便於讀者理解本文中沒有采用這種方式，讀者可以自行實踐。
另外還需要知道自動維護的刷新時間間隔為 7200 秒，也就是每 2 個小時 DB2 將檢查自動維護的策略並決定是否需要進行自動維護。可以通過清單 9 的語句查看。
清單 9. 查看刷新間隔
db2 "SELECT REFRESH_INTERVAL FROM TABLE(HEALTH_GET_IND_DEFINITION('')) AS T
WHERE NAME = 'db.tb_reorg_req'"
REFRESH_INTERVAL
--------------------
7200
1 record(s) selected.
啟用自動維護
設置了自動維護策略之後就可以啟用自動維護，上文中已經提到需要將 AUTO_MAINT、AUTO_TBL_MAINT 和 AUTO_REORG 這三個數據庫配置參數全部設置為“ON”，默認情況下前兩個已經是“ON”，只需要將第三個設置為“ON”即可，使用的命令和結果如清單 10 所示。
清單 10. 啟用自動維護
db2 update db cfg using AUTO_REORG on
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
db2 get db cfg
Automatic maintenance (AUTO_MAINT) = ON
Automatic table maintenance (AUTO_TBL_MAINT) = ON
Automatic reorganization (AUTO_REORG) = ON
至此，萬事俱備只需等待。當下一個刷新周期到來時表 mdctab 將會被評估並提交一個 REORG RECLAIM EXTENTS ONLY 的任務，當時間進入維護窗口時這個任務將會被執行。
查看回收信息
耐心等待一段時間之後，通過檢查表空間的可用數據頁的個數可以判斷 MDC 表中的空閒空間是否被釋放，我們將會看到可用的數據頁與清單 5 中手動釋放空間後的個數相同。
但是這種方法僅適用在本文中示例場景，因為在這個示例場景中沒有其他對數據庫的操作，而在真實的應用場景中有持續的數據庫操作在進行，所以表空間可用數據頁的個數也在不停的變化。因此，我們還需要另外一種方法來判斷，其中一種比較便捷的方式是使用 list history 命令查看 REORG 的歷史，如清單 11 所示。
清單 11. 查看空間回收的歷史記錄
db2 list history reorg all for mydb
List History File for mydb
Number of matching file entrIEs = 2
Op Obj Timestamp+Sequence Type Dev EarlIEst Log Current Log Backup ID
-- --- ------------------ ---- --- ------------ ------------ ---------
G T 20100101064038 N S0000000.LOG S0000002.LOG
----------------------------------------------------------------------
Table: "HAOQINGY"."MDCTAB"
----------------------------------------------------------------------
Comment: REORG RECALIM
Start Time: 20100101064038
End Time: 20100101064039
Status: A
---------------------------------------------------------------------
EID: 3
Op Obj Timestamp+Sequence Type Dev EarlIEst Log Current Log Backup ID
-- --- ------------------ ---- --- ------------ ------------ ----------
G T 20100101075636 N S0000000.LOG S0000000.LOG
-----------------------------------------------------------------------
Table: "HAOQINGY"."MDCTAB"
---------------------------------------------------------------------
Comment: REORG RECALIM
Start Time: 20100101075636
End Time: 20100101075636
Status: A
---------------------------------------------------------------------
EID: 5
在清單 11 中可以看到兩條對表 HAOQINGY.MDCTAB 的“REORG RECALIM”操作，也就是使用 RECLAIM EXTENTS ONLY 選項的 REORG 操作歷史，其中第一次是我們在清單 5 中手工調用的，而第二次則是自動維護功能自動調用的。同時還可以結合結果中的時間戳來判斷這條歷史記錄是否就是自動維護所執行的。在本文場景中，看到了這條歷史記錄，也就說明了自動維護策略已經自動執行了一次 MDC 表空間回收操作。如果此時再次手動執行清單 5 中的命令，也不會有更多的空間被釋放。
至此，我們已經討論並演示了如何配置自動維護策略自動釋放 MDC 表中空閒空間。
總結
在文中介紹了 DB2 9.7 中 REORG 的新選項 RECLAIM EXTENTS ONLY 並演示了其聯機回收 MDC 表中空閒空間的功能，然後詳細介紹並演示了如何通過配置自動維護策略自動調用這一 REORG 的新功能來實現自動回收，讀者可以在實際的生產場景中應用這些新特性，從定期手動執行的重復勞動中釋放出來，提高數據庫系統管理的效率。
