DB2 的REORG_學習（2）_表重組表重組的方法1.傳統（脫機）重組2.聯機/原位置重組3.admin_move_table

學習完指令之後來看一下表重組，然後再看索引重組哈。

db2 v8之後有兩種不同的表重組的方法：

脫機reorg

聯機reorg

reorg指令的inplace選項指定聯機重組。如果未指定此選項，那麼将運作脫機reorg。

可以通過兩種方法來重組表：傳統重組（脫機）和原位置重組（聯機）。

1).預設行為是脫機重組。

2).要指定聯機重組操作，請使用 reorg table 指令的 inplace 選項。

3).另一種方法是，使用聯機表移動存儲過程進行原位置重組。即使用 admin_move_table 過程以聯機方式移動表。

每種方法都有其優點和缺點，下面各節對其進行了概述。選擇重組方法時，應考慮哪種方法提供的優點是您優先要解決的方面。例如，如果發生故障時進行恢複比性能更重要，那麼最好使用聯機重組方法。

此方法具有下列優點：

最快速的表重組操作，未包括大對象 (lob)或長字段資料時尤其如此

完成後将生成叢集情況完美的表和索引

在表之後自動重建的索引已被重組；不需要執行單獨的步驟來重建索引

使用臨時表空間來建構影子副本；這降低了包含目标表或索引的表空間的空間需求

使用除叢集索引以外的索引對資料進行重新叢集

此方法具有下列缺點：

對表的通路受限：在重組操作的排序和建構階段，隻能進行讀通路

正在重組的表的影子副本需要大量空間

對重組過程的控制能力較低；脫機重組操作無法暫停和重新啟動

除重組操作的截斷階段以外，允許對表進行全面的通路

對重組過程的控制能力較高，該過程以異步方式在背景運作，并可以被暫停、繼續或停止；例如，如果正在對表運作大量的更新或删除操作，那麼您可以暫停進行中的重組操作

重組過程在發生故障後可恢複

由于以遞增方式處理表，是以降低了工作存儲空間需求

重組的好處将立即展現，甚至可以在重組操作完成前展現

資料或索引的叢集情況并不完美，這取決于在重組操作期間通路表的事務的類型

與脫機重組操作相比，性能欠佳

日志記錄需求可能較高，這取決于移動的行數、對表定義的索引數以及那些索引的大小

由于此過程執行的是索引維護操作而非重建操作，是以可能需要執行後續的索引重組操作

由于聯機重新組織無法移動内部記錄1，是以空間回收不完整。

注：無法移動内部記錄：

表 1. 聯機重組與脫機重組的比較

特征

脫機重組

聯機重組

性能

快

慢

完成後資料的叢集因子

良好

非最佳叢集

并行性（對表的通路）

從不能通路到隻讀通路

從隻讀通路到完全通路

資料存儲空間需求

非常大

不是非常大

日志記錄存儲空間需求

使用者控制（暫停和重新啟動重組過程的能力）

控制能力較低

控制能力較高

可恢複性1

不可恢複

可恢複

索引重建

進行

不進行

支援所有類型的表

是

否

是否能夠指定除叢集索引以外的索引

是否使用臨時表空間

這裡的這個可恢複性指的是如果重組期間down機，那麼資料庫恢複之後重組是否可以恢複。我是這麼了解的哈。

表 2. 聯機重組和脫機重組支援的表類型

表類型

是否受脫機重組支援

是否受聯機重組支援

多元叢集表 (mdc)

是1

插入時間叢集 (itc)表

範圍叢集表（rct）

否2

追加方式表

否3

包含長字段或大對象 (lob)資料的表

是4

是5

系統目錄表：

sysibm.syscodeproperties

sysibm.sysdatatypes

sysibm.sysnodegroups

sysibm.sysroutines

sysibm.syssequences

sysibm.systables

sysibm.sysvariables

注意： 由于通過 mdc 塊索引自動維護叢集，是以 mdc 表的重組隻涉及空間回收。不能指定索引。同樣，對于 itc 表，不能使用叢集索引來指定重組。 rct 的範圍區域始終保持叢集。 可以在将追加方式禁用後執行聯機重組。 重組長字段或大對象 (lob) 資料相當耗時，并且無法提高查詢性能；僅當需要回收空間時，才應該重組這些資料。 聯機表重組不會對 long/lob 資料進行重組，但會對其他列進行重組。

有關目前表重組操作的進度資訊将寫入曆史記錄檔案。曆史記錄檔案包含每個重組事件的記錄。要檢視此檔案，請對正在重組的表所在的資料庫執行 list history 指令。

此外，也可使用表快照來監視表重組操作的進度。無論如何設定資料庫系統螢幕表開關，系統均會記錄表重組監視資料。

如果發生錯誤，那麼 sqlca 消息将寫入曆史記錄檔案。對于原位置表重組操作而言，狀态将被記錄為 paused。

傳統表重組使用影子副本方法，進而建構正在重組的表的完整副本。（classic table reorganization uses a shadow copy approach, building a full copy of the table that is being reorganized.）（也就是說這種方法是把指定的表拷貝一份出來，然後對這個拷貝出來的副本進行重組，重組完成之後替換原來的表，我是這樣了解的）

  傳統的脫機表重組操作包括四個階段：

sort 排序階段 - 在此階段，如果 reorg table 指令中指定了索引，或者已對表定義叢集索引，那麼首先根據該索引對表行進行排序。如果指定了 indexscan 選項，那麼使用索引掃描方法對表進行排序；否則，使用表掃描排序方法。此階段僅适用于叢集表重組操作。空間回收重組操作（space reclaiming reorg operations）從建構階段開始。

表上ix鎖定，可以進行隻讀通路，效率低；

build 建構階段- 在此階段，将建構整個表的重組副本，此操作在該表的表空間或者 reorg table 指令中指定的臨時表空間中執行。

表上u鎖定，可以進行隻讀通路，效率低；

replace置換階段 - 在此階段，将原始表對象替換為臨時表空間中的副本，或者在所重組表的表空間中建立指向新建構的對象的指針。

表上z鎖定1，不能進行讀通路了；

recreate all indexes重建索引階段 - 在此階段，重新建立先前對該表定義的所有索引。

表上z鎖定，不能進行讀通路了；

z鎖：該鎖不是通過應用程式的dml語句來産生的。一般是通過對表進行删除（drop）和更改（alter）操作，或建立和删除索引而獲得的。如果對表加上z鎖，其他應用程式（包括未送出讀程式）都不能對表進行存取。 那在replace階段，z鎖應該是由alter table name産生的吧？ 那在recreate indexes階段，z鎖應該是由建立索引産生的吧？ 問題：建立索引會産生z鎖？那我們在一個已存在的表上建立索引時，其他使用者可以通路不？我覺得應該可以并行通路的呀。。。。

是以，使用臨時表空間的重組應該是這麼一個過程：

将表t2拷貝到系統臨時表空間tempspace1中，假設叫t2_shadow吧

對tempspace1中的t2_shadow表進行排序，

or：

對t2表進行排序，

把排序好的t2表拷貝到系統臨時表空間tempspace1中，假設叫t2_shadow吧，

3.建構： during this phase, a reorganized copy of the entire table is built, either in its table space or in a temporary table space that was specified on the reorg table command.在系統臨時表空間tempspace1對表t2進行重新組織，包括送出deleted record，pseudo empty 的頁，進而能進行space reclaim，使表的邏輯順序重新對應存儲順序。

4.置換：the original table object is replaced by a copy from the temporary table space,原始表被來自臨時表空間的拷貝所取代：應該是把這個重組好的t2_shadow從 系統臨時表空間tempspace1中拷貝到目前的表空間，然後實行表的替換，把原來的t2換成一個别的名字，這裡應該也包含原表的索引頁重命名了，之後删除把t2_shadow名稱換成t2，删除原來的t2表，

  這裡應該有個問題就是：從系統臨時表空間拷貝到目前表空間的時候将會拷貝到哪裡去呢？

重新建立索引：重新建立先前對該表定義的所有索引

♦ 假使目前的表空間中有extent22-28是empty的，29-59是有内容的，高水位就在extent58；

♦ 原來的t2表占據extent13,14，48,49,50,51,52,53,54,55,56,57,58，59，

♦ t2_shadow經過重新組織之後需要占據 11 個extent，

♥ 那麼t2_shadow拷貝過來時先占據22-28這7個extent，然後還有4個extent，這4個extent就要新申請存儲空間，故會占據extent60,61,62,63；然後置換完成之後space reclaim 原來的t2表占據的extent 13,14，48,49,50,51,52,53,54,55,56,57,58，59，這14個extent會變成empty的。

您可以使用快照螢幕或快照管理視圖來監視表重組操作的進度并确定目前階段。

脫機方式下的鎖定條件的限制性與聯機方式更強。建構副本期間，可以對表進行讀通路。但是，在将原始表替換為已重組的副本期間以及在重建索引期間，需要對表進行互斥通路。

在整個表重組過程中，需要挂起 ix 表空間鎖定。在建構階段，将擷取 u 鎖定并對該表挂起該鎖定。u 鎖定允許鎖定所有者更新表中的資料。雖然沒有其他應用程式能夠更新資料，将允許進行讀通路。替換階段開始後，u 鎖定将更新為 z 鎖定。在此階段，任何其他應用程式都無法通路資料。此鎖定将一直挂起到表重組操作完成為止。

脫機重組過程将建立多個檔案。這些檔案存儲在資料庫目錄中。它們的名稱以表空間辨別和對象辨別為字首；例如，0030002.ror 是表空間辨別為 3 且表辨別為 2 的表重組操作的狀态檔案。

以下清單提供了脫機表重組操作期間在系統管理的空間 (sms) 表空間中建立的臨時檔案：

在索引重組操作期間，将建立以下臨時檔案：

以下清單提供了排序階段在系統臨時表空間中建立的臨時檔案：

您不應以手動方式從系統中除去與重組過程相關聯的檔案。

 以脫機方式重組表是整理表碎片的最快方法。重組可減少表所需的空間量并提高資料通路和查詢性能。

您必須具有 sysadm、sysctrl、sysmaint、dbadm 或 sqladm 權限或者對所要重組的表具有 control 特權。您還必須建立資料庫連接配接才能重組表。

在辨別需要重組的表之後，可以對那些表運作 reorg 實用程式，并且可以選擇對那些表的任何索引運作該實用程式。

要使用 reorg table 指令來重組表，隻需指定該表的名稱。例如：

您可以使用特定的臨時表空間來重組表。例如：

您可以重組表并根據特定索引對行進行重新排序。例如：

要使用 sql call 語句來重組表，請通過 admin_cmd 過程來指定 reorg table 指令。例如：

在重組表之後，請收集有關該表的統計資訊，以便優化器掌握最準确的資料來評估查詢存取方案。

  在替換階段開始之前，脫機表重組是一個完全成功或完全失敗的過程。如果系統在排序或建構階段崩潰，那麼重組操作将復原，并且不會在崩潰恢複期間重新執行。

  如果系統在替換階段開始之後崩潰，那麼重組操作必須完成，這是因為已完成所有重組工作，原始表可能不再可用。在崩潰恢複期間，需要已重組的表對象的臨時檔案，而不是用于執行排序的臨時表空間。恢複操作将完全重新開始替換階段，并且需要恢複副本對象中的所有資料。在這種情況下，系統管理的空間 (sms) 表空間與資料庫管理的空間 (dms) 表空間之間有一個差别：必須将 sms 中已重組的表對象從一個對象複制到另一個對象；但在 dms 中，如果在同一個表空間中執行重組，那麼隻需指向已重組的表對象，并且将删除原始表。将不重建索引，但在崩潰恢複期間會将索引标記為無效。資料庫将根據一般規則确定重建索引的時間：在資料庫重新啟動時或第一次通路索引時。

  如果在索引重建階段發生崩潰，那麼由于新的表對象已存在，是以不會重新執行任何操作。将按先前描述的方式來處理索引。

  在前滾恢複期間，如果舊版本的表在磁盤上，那麼重新進行重組操作。前滾實用程式使用建構階段記錄的記錄辨別（rid）來重新應用建立了已重組的表的操作，進而重複建構和替換階段。将按先前描述的方式來處理索引。僅當最初使用了臨時表空間時，已重組的對象的副本才需要臨時表空間。在前滾恢複期間，可以同時重新執行多個重組操作（并行恢複）。

脫機表重組的性能在很大程度上由資料庫環境的特征決定。

以 allow no access 方式運作的重組操作與以 allow read access 方式運作的重組操作在性能方面幾乎沒有任何差别。差别在于，在 allow read access 方式的重組操作期間，實用程式可能必須先等待其他應用程式完成掃描并釋放它們的鎖定，然後才能替換該表。在以任何一種方式運作的重組操作的索引重建階段，該表都不可用。

如果有足夠的空間，那麼請對原始表和表的重組副本使用同一個表空間，以代替使用臨時表空間。這将節省從臨時表空間複制已重組的表所需的時間。

考慮在重組表之前删除不必要的索引，以便減少重組操作期間需要維護的索引數目。

確定正确設定已重組的表所在的表空間的預取大小。

調整 sortheap 和 sheapthres 資料庫配置參數，以便控制可用于排序的空間量。由于每個處理器都将執行私有排序，是以 sheapthres 的值至少應該是 sortheap x 使用的處理器數。

調整頁清除程式數，以確定盡快清除緩沖池中的髒索引頁。

原位置表重組在您能夠對表資料進行全面通路的情況下重組該表。資料通路不中斷的代價是，表重組操作的運作速度較慢。

在原位置（即聯機）表重組操作期間，不是立即重組整個表，，而是按順序重組表的各個部分。不會将資料複制到臨時表空間；而是，在現有表對象中移動行以重建立立叢集、回收可用空間并消除溢出行。

聯機表重組操作分為 4 個主要階段：

（1） 選擇 n 頁（select n pages）

  在此階段，資料庫管理器将選擇由 n 頁組成的範圍，其中 n 是至少包含 32 個要進行重組處理的順序頁的擴充資料塊的大小。

（2） 騰出範圍(vacate the range)

   標明n頁後，聯機表重組将第一階段標明範圍内的所有行移至表中的可用頁1。每個被移動的行都保留一條rp(reorg table　pointer)記錄，該記錄包含行的新位置的rid。将行作為包含資料的ro(reorg table overflow)插入到表的可用頁中。

重組表完成移動一組行後，它将等待表中進行的所有現有資料通路（例如，通過目前執行的應用程式）完成。這些現有通路稱為舊掃描程式，他們在通路資料時使用舊rid。在此等待過程中啟動的任何通路都稱為新掃描程式，它們使用新的rid來通路資料。在所有舊掃描程式都完成後，重組表操作将清除已移動的行、删除rp記錄并将ro記錄轉換為正常的記錄。

或者使用下面的表述方式

   reorg 實用程式将此範圍内的所有行移至表中的可用頁。每個被移動的行 的原位置 就不存儲行了，而是存儲 一條重組表指針（rp reorg table　pointer）記錄，該記錄包含該行的新位置的記錄辨別 (rid)。将行作為包含資料的重組表溢出（ro reorg table overflow）記錄被放入到表的可用頁。此實用程式移動一組行完成後，它将等待所有通路該表中資料的應用程式完成。這些“舊掃描者”在通路表資料時，将使用舊 rid。在等待階段開始的任何表通路（“新掃描者”）都将使用新 rid 來通路資料。在所有舊掃描者都完成後，reorg 實用程式将清除已移動的行、删除 rp 記錄并将 ro 記錄轉換為正常記錄。

（3） 填充範圍（fill the range）

   騰出特定範圍内的所有行之後，将采用已重組的格式、根據先前使用的任何索引進行排序後的順序并遵循先前定義的任何預取限制寫回這些行。重寫該範圍内的所有頁之後，将選擇該表中的後續 n 個順序頁并重複以上過程。

（4） 截斷表（truncate table）

   預設情況下，重組表中的所有頁後，預設情況下将截斷表以回收空間。如果指定了 notruncate 選項，那麼不會截斷已重組的表。by default, when all pages in the table have been reorganized, the table is truncated to reclaim space. if the notruncate option has been specified, the reorganized table is not truncated.

 &esmp;在這裡的truncate table 與指令執行truncate table table_name的truncate含義應該不一樣吧？

truncate：切去頭端, 截棱成平面, 縮短：在在這裡了解成縮短的意思吧，經過重組之後可能會有一本空間empty了，階段表是将這些empty的頁截斷回收利用吧。

1: 要是沒有可用頁怎麼辦？或者可用頁不夠怎麼辦？   這個，既然是要重組表了哈，一般應該是有可用頁的哈，然後這個n至少是32，但是n具體是多少是重組程式内部控制的吧不是外部指定的哈？），那麼reorg應該在重組開始之前 首先通過搜尋 fscr 來找到空 page，看看有多少空page，如果空page比較少，那麼這個n應該會比較少，如果比較多就會比較自由了哈，如果實在是找不到，可能會重新申請一個extent吧/ fscr：可用空間控制行：db2 每個表對象的存儲裡有一種特殊的記錄叫做 fscr（free space control record），從 page 0 開始每 500 個 page 有一個 fscr 記錄，用來記錄目前 500 個 page 中空閑空間情況。

  從上面的描述中可以看出，聯機重組之是以也被稱為原位置重組，就是因為它最後會把排序好的行寫回去，寫回原位置。也正是因為她是n pages->n pages這樣進行的，那兩組n pages之間的一些相關的行呀是沒有重組的，是以可能有一些順序還是不對的，是以第一個表格中完成後資料的叢集因子不是最優的，非最佳叢集，但是因為這些n pages行的轉換都是記錄了日志的，是以可以恢複重組之前的狀态，而n pages 隻需要比較小的空間，脫機重組需要拷貝整個表是以需要的空間比較大。

聯機表重組操作期間，将為每個資料庫分區建立一個 .olr 狀态檔案。這個二進制檔案的名稱格式為 xxxxyyyy.olr，其中 xxxx 是表空間辨別，yyyy 是十六進制的對象辨別。此檔案包含從暫停狀态繼續執行聯機重組操作所需的下列資訊：

重組操作的類型

正在重組的表的生存日志序号（lsn）

要騰出的下一個範圍

重組操作是為了對資料進行叢集還是僅僅為了回收空間

正在用于對資料進行叢集的索引的辨別

将對 .olr 檔案執行校驗和檢查。如果該檔案已損壞并導緻校驗和錯誤，或者表 lsn 與生存 lsn 不比對，那麼将啟動新的重組操作并建立新的狀态檔案。

如果 .olr 狀态檔案被删除，那麼重組過程無法繼續，将傳回 sql2219，并且必須啟動新的重組操作。

聯機或原位置表重組允許使用者在重組表的同時通路該表。

要使用 reorg table 指令以聯機方式重組表，請指定表名和 inplace 參數。 例如：

要使用 sql call 語句以聯機方式重組表，請通過 admin_cmd 過程來指定 reorg table 指令。 例如：

要使用管理應用程式程式設計接口以聯機方式重組表，請調用 db2reorg api。

聯機表重組的故障通常是由于處理錯誤（例如磁盤已滿或日志記錄錯誤）所緻。如果聯機表重組失敗，那麼系統會将 sqlca 消息寫入曆史記錄檔案。

如果運作時發生故障，那麼聯機表重組操作将暫停，然後在崩潰恢複期間復原。以後，您可以通過在 reorg table 指令中指定 resume 參數來繼續執行重組操作。由于聯機表重組過程進行全面的日志記錄，是以保證可恢複。

在某些情況下，聯機表重組操作可能會超出 num_log_span 資料庫配置參數所設定的限制。在這種情況下，資料庫管理器将強制控制 reorg 實用程式并将其置于 pause 狀态。在快照螢幕輸出中，reorg 實用程式的狀态将顯示為 paused。

聯機表重組暫停由中斷驅動，這意味着它既可以由使用者觸發（使用 reorg table 指令的 pause 參數或者 force application 指令），也可以由資料庫管理器在某些情況（例如系統崩潰）下觸發。

如果分區資料庫環境中的一個或多個資料庫分區遇到錯誤，那麼傳回的 sqlcode 将是來自第一個報告錯誤的資料庫分區的 sqlcode。

使用者可以暫停和重新啟動正在進行中的聯機表重組。

您必須具有 sysadm、sysctrl、sysmaint、dbadm 或 sqladm 權限或者對要暫停或重新啟動聯機重組操作的表具有 control 特權。您還必須建立資料庫連接配接才能暫停或重新啟動聯機表重組。

要使用 reorg table 指令來暫停聯機表重組，請指定表名、inplace 參數和 pause 參數。 例如：

要重新啟動已暫停的聯機表重組，請指定 resume 參數。 例如：

聯機表重組的其中一個重要方面是如何控制鎖定，因為這對應用程式并行性而言至關重要。

聯機表重組操作可以挂起下列鎖定：

為了確定能夠對表空間進行寫通路，擷取對重組操作所影響的表空間的 ix 鎖定。

在整個重組操作期間擷取并挂起表鎖定。鎖定級别取決于重組期間實施的通路方式：

如果指定了 allow write access，那麼擷取 is 表鎖定。

如果指定了 allow read access，那麼擷取 s 表鎖定。

在截斷階段，将請求對表挂起 s 鎖定。在擷取 s 鎖定之前，并發事務可以插入行。這些插入的行可能不會被 reorg 實用程式檢測到，并可能導緻表無法被截斷。擷取 s 表鎖定之後，導緻表無法被截斷的行将被移走，以便能夠對表進行壓縮。在壓縮表之後，會将其截斷，但僅當确定所有在截斷點通路該表的事務都完成後才會執行此操作。

可能會擷取行鎖定，這取決于表鎖定的類型：

如果已對該表挂起 s 鎖定，那麼不需要單獨的行級别 s 鎖定，并且不必進一步執行鎖定。

如果已對該表挂起 is 鎖定，那麼移動行之前将擷取 ns 行鎖定，并在移動完成後釋放該鎖定。

在聯機表重組操作期間，還可能擷取某些内部鎖定。

鎖定會影響聯機表重組操作和并發使用者應用程式的性能。您可以使用鎖定快照資料來幫助您了解聯機表重組期間發生的鎖定活動。

您可以使用 get snapshot 指令、snaptab_reorg 管理視圖或 snap_get_tab_reorg 表函數來擷取有關表重組操作的狀态資訊。

要使用 sql 來通路有關重組操作的資訊，請使用 snaptab_reorg 管理視圖。 例如，下列查詢将傳回有關對目前所連接配接資料庫的所有資料庫分區執行的表重組操作的詳細資訊。如果未重組任何表，那麼不會傳回任何行。

要使用快照螢幕來通路有關重組操作的資訊，請使用 get snapshot for tables 指令并檢查表重組監視元素的值。

由于脫機表重組操作是同步操作，是以錯誤将傳回給實用程式的調用者（應用程式或指令行處理器）。并且，由于聯機表重組操作是異步操作，是以這種情況下不會将錯誤消息傳回給 clp。要檢視執行聯機表重組操作期間傳回的 sql 錯誤消息，請使用 list history reorg 指令。

聯機表重組操作作為 db2reorg 程序在背景運作。即使調用應用程式終止其資料庫連接配接，此程序也将繼續運作。

  當調用 sysproc.admin_move_table 過程時，會:

建立源表的影子副本（shadow table）

在複制階段期間，會使用觸發器來捕獲對源表的更改（更新、插入或删除）并将其放置到staging table中

當複制階段完成後，會對影子副本重放登台表中捕獲的更改。

存儲過程會迅速使源表脫機并将源表名稱和索引名稱指定給影子副本及其索引。

然後，使影子表聯機，進而替換源表。預設情況下，會删除源表，但可以使用 keep 選項來以另一個名稱保留該源表。