DB2 的REORG_學習(2)_表重組
學習完命令之後來看一下表重組,然後再看索引重組哈。
表重組的方法
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)表 | 是1 | 否 |
範圍集群表(RCT) | 否2 | 否 |
追加方式表 | 是 | 否3 |
包含長字段或大對象 (LOB)數據的表 | 是4 | 是5 |
係統目錄表:
|
是 | 否 |
注意:
1. 由於通過 MDC 塊索引自動維護集群,所以 MDC 表的重組隻涉及空間回收。不能指定索引。同樣,對於 ITC 表,不能使用集群索引來指定重組。
2. RCT 的範圍區域始終保持集群。
3. 可以在將追加方式禁用後執行聯機重組。
4. 重組長字段或大對象 (LOB) 數據相當耗時,並且**無法提高查詢性能**;僅當需要回收空間時,才應該重組這些數據。
5. 聯機表重組不會對 LONG/LOB 數據進行重組,但會對其他列進行重組。
監視表 reorg 操作的進度
有關當前表重組操作的進度信息將寫入曆史記錄文件。曆史記錄文件包含每個重組事件的記錄。要查看此文件,請對正在重組的表所在的數據庫執行 **LIST HISTORY **命令。
此外,也可使用表快照來監視表重組操作的進度。無論如何設置數據庫係統監視器表開關,係統均會記錄表重組監視數據。
如果發生錯誤,那麼 SQLCA 消息將寫入曆史記錄文件。對於原位置表重組操作而言,狀態將被記錄為 PAUSED。
1.傳統(脫機)重組
傳統表重組使用**影子副本**方法,從而構建正在重組的表的完整副本。(*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*)從構建階段開始。
- BUILD 構建階段- 在此階段,將構建整個表的重組副本,此操作在該表的表空間或者 REORG TABLE 命令中指定的臨時表空間中執行。
- REPLACE**置換階段** - 在此階段,將原始表對象替換為臨時表空間中的副本,或者在所重組表的表空間中創建指向新構建的對象的指針。 表上Z鎖定1,不能進行讀訪問了;
- RECREATE ALL INDEXES**重建索引階段** - 在此階段,重新創建先前對該表定義的所有索引。
Z鎖:該鎖不是通過應用程序的DML語句來產生的。一般是通過對表進行刪除(Drop)和更改(Alter)操作,或**創建和刪除索引**而獲得的。如果對表加上Z鎖,其他應用程序(包括未提交讀程序)都不能對表進行存取。
那在replace階段,Z鎖應該是由Alter table name產生的吧?
那在recreate indexes階段,Z鎖應該是由創建索引產生的吧?
問題:創建索引會產生Z鎖?那我們在一個已存在的表上創建索引時,其他用戶可以訪問不?我覺得應該可以並行訪問的呀。。。。
步驟個人理解(不保證對哈)
reorg table t2 using tempspace1
所以,使用臨時表空間的重組應該是這麼一個過程:
1. 將表t2拷貝到係統臨時表空間tempspace1中,假設叫t2_shadow吧
2. 對tempspace1中的t2_shadow表進行排序,
or:
1. 對t2表進行排序,
2. 把排序好的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表,
這裏應該有個問題就是:從係統臨時表空間拷貝到當前表空間的時候將會拷貝到哪裏去呢?
5. 重新創建索引:重新**創建**先前對該表定義的所有索引
♦ 假使當前的表空間中有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) 表空間中創建的臨時文件:
.DTR - 數據影子副本文件
.LFR - 長字段文件
.LAR - 長字段分配文件
.RLB - LOB 數據文件
.RBA - LOB 分配文件
.BMR - 多維集群 (MDC) 表和插入時間集群 (ITC) 表的塊對象文件
在索引重組操作期間,將創建以下臨時文件:
.IN1 - 影子副本文件
以下列表提供了排序階段在係統臨時表空間中創建的臨時文件:
.TDA - 數據文件
.TIX - 索引文件
.TLF - 長字段文件
.TLA - 長字段分配文件
.TLB - LOB 文件
.TBA - LOB 分配文件
.TBM - 塊對象文件
您不應以手動方式從係統中除去與重組過程相關聯的文件。
1.以脫機方式重組表
以脫機方式重組表是整理表碎片的最快方法。重組可減少表所需的空間量並提高數據訪問和查詢性能。
開始之前
您必須具有 SYSADM、SYSCTRL、SYSMAINT、DBADM 或 SQLADM 權限或者對所要重組的表具有 CONTROL 特權。您還必須建立數據庫連接才能重組表。
關於此任務
在標識需要重組的表之後,可以對那些表運行 REORG 實用程序,並且可以選擇對那些表的任何索引運行該實用程序。
過程
要使用 REORG TABLE 命令來重組表,隻需指定該表的名稱。例如:
reorg table employee
您可以使用特定的臨時表空間來重組表。例如:
reorg table employee use mytemp
您可以重組表並根據特定索引對行進行重新排序。例如:
reorg table employee index myindex
要使用 SQL CALL 語句來重組表,請通過 ADMIN_CMD 過程來指定 REORG TABLE 命令。例如:
call sysproc.admin_cmd ('reorg table employee')
要使用管理應用程序編程接口來重組表,請調用 db2Reorg API。
下一步做什麼
在重組表之後,請收集有關該表的統計信息,以便優化器掌握最準確的數據來評估查詢存取方案。
2.脫機表重組的恢複
在替換階段開始之前,脫機表重組是一個完全成功或完全失敗的過程。如果係統在排序或構建階段崩潰,那麼重組操作將回滾,並且不會在崩潰恢複期間重新執行。
如果係統在替換階段開始之後崩潰,那麼重組操作必須完成,這是因為已完成所有重組工作,原始表可能不再可用。在崩潰恢複期間,需要已重組的表對象的臨時文件,而不是用於執行排序的臨時表空間。恢複操作將完全重新開始替換階段,並且需要恢複副本對象中的所有數據。在這種情況下,係統管理的空間 (SMS) 表空間與數據庫管理的空間 (DMS) 表空間之間有一個差別:;但在 DMS 中,如果在同一個表空間中執行重組,那麼**隻需指向已重組的表對象,並且將刪除原始表**。將不重建索引,但在崩潰恢複期間會將索引標記為無效。數據庫將根據一般規則確定重建索引的時間:在數據庫重新啟動時或第一次訪問索引時。
如果在索引重建階段發生崩潰,那麼由於新的表對象已存在,因此不會重新執行任何操作。將按先前描述的方式來處理索引。
在前滾恢複期間,如果舊版本的表在磁盤上,那麼重新進行重組操作。前滾實用程序使用構建階段記錄的記錄標識(RID)來重新應用創建了已重組的表的操作,從而重複構建和替換階段。將按先前描述的方式來處理索引。僅當最初使用了臨時表空間時,已重組的對象的副本才需要臨時表空間。在前滾恢複期間,可以同時重新執行多個重組操作(並行恢複)。
3.提高脫機表重組的性能
脫機表重組的性能在很大程度上由數據庫環境的特征決定。
以 ALLOW NO ACCESS 方式運行的重組操作與以 ALLOW READ ACCESS 方式運行的重組操作**在性能方麵幾乎沒有任何差別**。**差別在於,在 ALLOW READ ACCESS 方式的重組操作期間,實用程序可能必須先等待其他應用程序完成掃描並釋放它們的鎖定,然後才能替換該表**。在以任何一種方式運行的重組操作的索引重建階段,該表都不可用。
有關提高性能的技巧
- 如果有足夠的空間,那麼請對原始表和表的重組副本使用同一個表空間,以代替使用臨時表空間。這將節省從臨時表空間複製已重組的表所需的時間。
- 考慮在重組表之前刪除不必要的索引,以便減少重組操作期間需要維護的索引數目。
- 確保正確設置已重組的表所在的表空間的預取大小。
- 調整 sortheap 和 sheapthres 數據庫配置參數,以便控製可用於排序的空間量。由於每個處理器都將執行私有排序,因此 sheapthres 的值至少應該是 sortheap x 使用的處理器數。
- 調整頁清除程序數,以確保盡快清除緩衝池中的髒索引頁。
2.聯機/原位置重組
原位置表重組在您能夠對表數據進行全麵訪問的情況下重組該表。數據訪問不中斷的代價是,表重組操作的運行速度較慢。
在原位置(即聯機)表重組操作期間,不是立即重組整個表,,而是按順序重組表的各個部分。不會將數據複製到臨時表空間;而是,在現有表對象中移動行以重新建立集群、回收可用空間並消除溢出行。
聯機重組步驟
聯機表重組操作分為 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,並且必須啟動新的重組操作。
您不應以手動方式從係統中除去與重組過程相關聯的文件。
1.以聯機方式重組表
聯機或原位置表重組允許用戶在重組表的同時訪問該表。
開始之前
您必須具有 SYSADM、SYSCTRL、SYSMAINT、DBADM 或 SQLADM 權限或者對所要重組的表具有 CONTROL 特權。您還必須建立數據庫連接才能重組表。
關於此任務
在標識需要重組的表之後,可以對那些表運行 REORG 實用程序,並且可以選擇對那些表的任何索引運行該實用程序。
過程
要使用 REORG TABLE 命令以聯機方式重組表,請指定表名和 INPLACE 參數。 例如:
reorg table employee inplace
要使用 SQL CALL 語句以聯機方式重組表,請通過 ADMIN_CMD 過程來指定 REORG TABLE 命令。 例如:
call sysproc.admin_cmd ('reorg table employee inplace')
要使用管理應用程序編程接口以聯機方式重組表,請調用 db2Reorg API。
下一步做什麼
在重組表之後,請收集有關該表的統計信息,以便優化器掌握最準確的數據來評估查詢存取方案。
2.聯機表重組的恢複
聯機表重組的故障通常是由於處理錯誤(例如磁盤已滿或日誌記錄錯誤)所致。如果聯機表重組失敗,那麼係統會將 SQLCA 消息寫入曆史記錄文件。
如果運行時發生故障,那麼聯機表重組操作將暫停,然後在崩潰恢複期間回滾。以後,您可以通過在 REORG TABLE 命令中指定 RESUME 參數來繼續執行重組操作。由於聯機表重組過程進行全麵的日誌記錄,因此保證可恢複。
在某些情況下,聯機表重組操作可能會超出 num_log_span 數據庫配置參數所設置的限製。在這種情況下,數據庫管理器將強製控製 REORG 實用程序並將其置於 PAUSE 狀態。在快照監視器輸出中,REORG 實用程序的狀態將顯示為 PAUSED。
聯機表重組暫停由中斷驅動,這意味著它既可以由用戶觸發(使用 REORG TABLE 命令的 PAUSE 參數或者 FORCE APPLICATION 命令),也可以由數據庫管理器在某些情況(例如係統崩潰)下觸發。
如果分區數據庫環境中的一個或多個數據庫分區遇到錯誤,那麼返回的 SQLCODE 將是來自第一個報告錯誤的數據庫分區的 SQLCODE。
3,暫停和重新啟動聯機表重組
用戶可以暫停和重新啟動正在進行中的聯機表重組。
開始之前
您必須具有 SYSADM、SYSCTRL、SYSMAINT、DBADM 或 SQLADM 權限或者對要暫停或重新啟動聯機重組操作的表具有 CONTROL 特權。您還必須建立數據庫連接才能暫停或重新啟動聯機表重組。
過程
- 要使用 REORG TABLE 命令來暫停聯機表重組,請指定表名、INPLACE 參數和 PAUSE 參數。 例如:
reorg table employee inplace pause
-
要重新啟動已暫停的聯機表重組,請指定 RESUME 參數。 例如:
reorg table employee inplace resume
暫停聯機表重組操作之後,無法開始對該表執行新的重組。您必須繼續執行或停止已暫停的操作,然後才能開始新的重組過程。
發出 RESUME 請求之後,重組過程將考慮當前 RESUME 請求所指定的截斷選項。例如,如果未在當前 RESUME 請求上指定 NOTRUNCATE 參數,那麼原始 REORG TABLE 命令上指定的 NOTRUNCATE 參數或帶有任何先前 RESUME 請求的命令被忽略。
執行複原和前滾操作後,無法恢複表重組操作。
4.聯機表重組的鎖定和並行性注意事項
聯機表重組的其中一個重要方麵是如何控製鎖定,因為這對應用程序並行性而言至關重要。
聯機表重組操作可以掛起下列鎖定:
- 為了確保能夠對表空間進行寫訪問,獲取對重組操作所影響的表空間的 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 管理視圖。 例如,下列查詢將返回有關對當前所連接數據庫的所有數據庫分區執行的表重組操作的詳細信息。如果未重組任何表,那麼不會返回任何行。
select
substr(tabname, 1, 15) as tab_name,
substr(tabschema, 1, 15) as tab_schema,
reorg_phase,
substr(reorg_type, 1, 20) as reorg_type,
reorg_status,
reorg_completion,
dbpartitionnum
from sysibmadm.snaptab_reorg
order by dbpartitionnum
要使用快照監視器來訪問有關重組操作的信息,請使用 GET SNAPSHOT FOR TABLES 命令並檢查表重組監視元素的值。
結果
由於脫機表重組操作是同步操作,所以錯誤將返回給實用程序的調用者(應用程序或命令行處理器)。並且,由於聯機表重組操作是異步操作,所以這種情況下不會將錯誤消息返回給 CLP。要查看執行聯機表重組操作期間返回的 SQL 錯誤消息,請使用 LIST HISTORY REORG 命令。
聯機表重組操作作為 db2Reorg 進程在後台運行。即使調用應用程序終止其數據庫連接,此進程也將繼續運行。
3.admin_move_table
當調用 SYSPROC.ADMIN_MOVE_TABLE 過程時,會:
1. 創建源表的影子副本(shadow table)
2. 在複製階段期間,會使用觸發器來捕獲對源表的更改(更新、插入或刪除)並將其放置到staging table中
3. 當複製階段完成後,會對影子副本重放登台表中捕獲的更改。
4. 存儲過程會迅速使源表脫機並將源表名稱和索引名稱指定給影子副本及其索引。
5. 然後,使影子表聯機,從而替換源表。缺省情況下,會刪除源表,但可以使用 KEEP 選項來以另一個名稱保留該源表。
最後更新:2017-06-29 09:02:25