【備份恢復】行遷移與行連結

行連結、行遷移:
行連結（Row Chaining）：行連結產生在第一次插入資料的時候如果一個block不能存放一行記錄的情況下。這種情況下，Oracle將使用連結一個或者多個在這個段中保留的 block儲存這一行記錄，行連結比較容易發生在比較大的行上，例如行上有LONG、LONG RAW、LOB等資料型別的欄位，這種時候行連結是不可避免的會產生的，也就是說行連結發生在INSERT階段資料塊無法容納過大資料時。

行遷移（Row Migrating）：當一行記錄初始插入的時候事可以儲存在一個block中的，由於更新操作導致行長增加了，而block的自由空間已經完全滿了，這個時候就產生了行遷移。在這種情況下，Oracle將會遷移整行資料到一個新的block中（假設一個block中可以儲存下整行資料），Oracle會保留被遷移行的原始指標指向新的存放行資料的block，這就意味著被遷移行的ROW ID是不會改變的。也就是說行遷移發生在UPDATE階段時原資料塊無法容納增大的資料時。因為在這種情況下查詢需要掃描更多的資料塊才能得到所需的資訊，所以行連結和行遷移會導致系統的查詢效率降低。

1.1. 行連結、行遷移測試

例1：測試行連結

第一步：建測試表(char型別，在塊中固定佔有空間，定長)

SYS@ORA11GR2>create table t_row_changing (x char(2000),y char(2000),z char(2000),q char(2000));

 

Table created.

 

第二步：插入初始化資料

SYS@ORA11GR2>insert into t_row_changing values('a','b','c','d');

 

1 row created.

 

SYS@ORA11GR2>commit;

 

Commit complete.

 

第三步：使用analyze命令對錶t_row_chaining進行分析，以便驗證該表是否發生了行連結。

SYS@ORA11GR2>analyze table t_row_changing list chained rows;

analyze table t_row_changing list chained rows

*

ERROR at line 1:

ORA-01495: specified chain row table not found

注：此時會出錯，原因是CHAINED_ROWS表沒有建立導致的！！！

 

第四步：使用Oracle自帶的utlchain.sql指令碼建立CHAINED_ROWS表，並再次分析表

SYS@ORA11GR2>@?/rdbms/admin/utlchain.sql

 

Table created.

 

SYS@ORA11GR2>analyze table t_row_changing list chained rows;

 

Table analyzed.

 

第五步：測試行連結，由於初始化的資料無法在一個資料塊中存放（因為測試表所有欄位都為char型別所致），此時發生了行連結。

SYS@ORA11GR2>col owner_name for a5

SYS@ORA11GR2>col table_name for a15

SYS@ORA11GR2>select owner_name,table_name,head_rowid,analyze_timestamp from chained_rows;

 

OWNER TABLE_NAME      HEAD_ROWID         ANALYZE_TIMESTAMP

----- --------------- ------------------ -------------------

SYS   T_ROW_CHANGING  AAAVuqAABAAAXLyAAA 2016-10-13 22:35:31

注：chained_rows表中，存在T_ROW_CHAINING的資料，即說明發生了行連結

 

例2：測試行遷移

第一步：建測試表（欄位型別為varchar2，可變長）

SYS@ORA11GR2>create table t_row_migrating (x varchar2(2000),y varchar2(2000),z varchar2(2000),q varchar2(2000));

 

Table created.

 

第二步：插入初始化資料

SYS@ORA11GR2>insert into t_row_migrating values('a','b','c','d');

 

1 row created.

 

SYS@ORA11GR2>commit;

 

Commit complete.

 

第三步：此時由於是VARCHAR2型別的欄位（此型別欄位可以自適應資料的長短），此時資料完全可以在一個資料塊中存放，因此此時不會發生行連結。分析表t_row_migrating，並驗證是否存在行連結。

SYS@ORA11GR2>analyze table t_row_migrating list chained rows;

 

Table analyzed.

 

SYS@ORA11GR2>select owner_name,table_name,head_rowid,analyze_timestamp from chained_rows;

 

OWNER TABLE_NAME      HEAD_ROWID         ANALYZE_TIMESTAMP

----- --------------- ------------------ -------------------

SYS   T_ROW_CHANGING  AAAVuqAABAAAXLyAAA 2016-10-13 22:35:31

注：此時chained_rows表中，還是剛才我們測試行連結的那條記錄。

 

第四步：我們使用t_row_chaining中的大資料對錶t_row_migrating進行更新，使之發生行遷移。

SYS@ORA11GR2>update t_row_migrating set (x,y,z,q)=(select * from t_row_changing);

 

1 row updated.

 

SYS@ORA11GR2>commit;

 

Commit complete.

 

第五步：對錶t_row_migrating進行分析，並驗證行連結

SYS@ORA11GR2>analyze table t_row_migrating list chained rows;

 

Table analyzed.

 

SYS@ORA11GR2>select owner_name,table_name,head_rowid,analyze_timestamp from chained_rows;

 

OWNER TABLE_NAME      HEAD_ROWID         ANALYZE_TIMESTAMP

----- --------------- ------------------ -------------------

SYS   T_ROW_CHANGING  AAAVuqAABAAAXLyAAA 2016-10-13 22:35:31

SYS   T_ROW_MIGRATING AAAVusAABAAAXkBAAA 2016-10-13 22:47:03

 

此時，我們發現表t_row_migrating已經存在chained_rows表中，注：chained_rows表中的資料，要麼是出現了行遷移，要麼就出現了行連結。

OWNER_NAME：表所屬的schema

TABLE_NAME：表名

HEAD_ROWID：出現行遷移、行連結的rowid

ANALYZE_TIMESTAMP：執行ANALYZE的時間戳