3. 資料鏈結

資料鏈結（Chained Row）有兩種型態：

• 資料遷徒（Row Migration）：當PCTFREE所預留的空間太小時，造成空間不足，也就是說現行所在的資料區塊（Data Block）裡面的資料列（Row）要做修改（Update）時空間不夠，Oracle會希望這筆資料列（Row）在這個資料區塊（Data Block）裡面就儘量的留在這個資料區塊（Data Block）裡面，但當現在要做修改（Update）時Oracle發現現有的空間不足已放下修改（Update）之後的整筆資料列（Row），那只好搬家，但如果搬了家又有另外一個問題，就是如果搬了家所有的ROWID都會變了，這影響會很大，例如如果ROWID搬了家所有的索引（INDEX）都會跟著改變，所以Oracle使用了一種影響最小的方式，就是把ROW Header留下來，後面加上一個指標（Point），再把資料列（Row）搬到另一個地方，所以當我們找到這筆資料列（Row）時實際上是找到ROW Header 加上指標（Pointer），這指標（Pointer）會告訴使用者現在這筆資料列（Row）是搬到什麼地方，舉一個例子，通訊地址和戶籍地址，當搬家或到外地工作時的地址是通訊地址，而戶籍地址通常是老家地址，而很久沒聯絡的朋友或較重要的信件通常是寄到戶籍地址，所以說會花較多的時間才拿到這封信件。這就是資料遷徒（Row Migration），ROWID不變，但資料的位置改變了。資料遷徒（Row Migration）的重點是，當要找一筆資料列（Row）時必須先查詢的ROW Header一次I/O，然後再透過指標（Pointer）才能取得那筆資料列（Row）又一次I/O，因此查一筆資料列（Row）就需要兩次I/O，所以I/O一定會差；如圖所示

• 資料串鏈（Row Chaining）：造成原因是因為一筆資料列（Row）太大了，無法容納在一個資料區塊（Data Block）裡面，例如有一個表格（Table）裡面有100個欄位全都是VARCHAR2(1)，所以一筆資料列（Row）是400k（因為一個VARCHAR2是4 k），在現行Oracle database的block沒有一個block是400k，所以一定會造成ROW Chaining，而ROW Chaining的意思是當要讀這筆資料列（Row）時必需要讀取好幾個資料區塊（Data Block），才能把一筆資料列（Row）湊出來，此時I/O效能當然不會好，這是沒有辦法解決的，唯一的方法只能移除（Drop）原來的表格（Table），重新定義表格（Table）。

Chain Row可利用下列步驟檢查：
步驟 1. 建立暫存表格。執行$ORACLE_HOME/rdbms/admin/utlchain.sql會自動產生暫存表格如圖2-9。或是是手動產生，表格名稱可以隨便取，但要注意的步驟2和步驟3的表格名稱都需和手動產生的表格名稱一致。手動產生暫存表格與法如下

CREATE TABLE CHAINED_ROWS (  owner_name         varchar2(30),  table_name         varchar2(30),  cluster_name       varchar2(30),  partition_name     varchar2(30),  subpartition_name  varchar2(30),  head_rowid         rowid,  analyze_timestamp  date);

步驟 2. 產生分析指令。語法如下。

SELECT 'analyze table '||owner||'.'||table_name||' list chained rows into system.chained_rows; ' FROM dba_tables  WHERE owner = ‘TEST’;

說明

注意WHERE owner=’TEST’可自行決定要針對哪一個Schema下的表格作分析。產生出來的結果如下，並執行。如圖

analyze table TEST.ORACLE_TEST01 list chained rows into system.chained_rows;

以上執行這段語法的目的是將分析出來的結果放入到chained_rows表格中，因此每此要執行前

將chained_rows表格清空或移除重建，以防止重複計算失去其真實性。

步驟 3. 執行報表與法如下。產生結果如圖。

SELECT B.owner_name AS "OWNER",         A.table_name AS "TABLE NAME",                     B.row_count AS "ROW COUNT",         A.num_rows AS "TOTAL ROWS" FROM ALL_tables A,       (SELECT B.owner_name, B.table_name,                COUNT(B.head_rowid) ROW_COUNT         FROM chained_rows B         GROUP BY B.owner_name, B.table_name) B WHERE A.table_name=B.table_name;

• OWNER：代表所分析的表格是屬於哪個schema。

• TABLE NAME：代表所分析的表格名稱。
• ROW COUNT：代表有多少資料是Chanied Rows。
• TOTAL COUNT：代表此表格總共有多少筆資料；此表格的數據是由分析表格指令產生出來。

按照以上的步驟就可以產生有造成Chained Rows報表結果，選擇適當時間進行表格重整。

解決方式

解決資料遷徒（Row Migration）與資料串鏈（Row Chaining）方式大致如下：

修改表格（Table）參數將PCTFREE加大。但此方式只能使未來的資料生效，無法對目前產生資料遷徒（Row Migration）的資料生效。

使用表格（Table）搬移表格空間（Tablespace）指令，消除已存在的資料遷徒（Row Migration）。

利用EXPORT與IMPORT方式。步驟如下：

步驟1. 先將表格（Table）利用EXPORT方式備份出來。

步驟2. 移除（Drop）原來的表格（Table）。

步驟3. 使用新的PCTFREE參數重建此表格（Table）。

步驟4. 將資料IMPORT到重建後的表格（Table）。