物化檢視prebuilt和線上重定義

資料遷移中有一種解決方案很有亮點，如果表的資料量大，遷移涉及的表不多，同時對於維護時間有要求的情況下，物化檢視的prebuilt方式就是一種很不錯的選擇。
大體的步驟和方法如下：
假設源環境是test_source,目標環境是test_target

在源環境中test_source的操作如下：
Create table test_mv as select *from all_objects  ;
alter table test_mv modify(object_id primary key);
create materialized view log on test;    這個地方需要注意是主鍵，with rowid的方式是不可以的

目標環境test_target的操作如下：
建立db link
然後建立表，同步表結構即可
create table test_mv as select * from test_mv@prdb where 1=2;
然後建立物化檢視，和表同名
create materialized view test_mv on prebuilt table refresh fast as select * from test_mv@test_source;
第一次需要全量重新整理資料，也就意味著一次全量，以後都是增量
exec dbms_mview.refresh(‘TEST_MV’,‘FAST’); -- 重新整理資料
確認資料同步正常，刪除物化檢視即可
Drop materialized view test_mv;

需要補充的是建立快速重新整理的物化檢視，使用如下with rowid的方式是可行的，但是在prebuilt table的情況下，這個還無法支援。
create materialized view test_mv on prebuilt table refresh fast with rowid as select * from test_mv@test_source;
這個其實也可以理解。因為源環境和目標環境是完全不同的資料庫環境，rowid無法固定，只能透過主鍵的方式來定位。
而如果我們進一步細想，如果是同一個資料庫中要做這種類似的操作，好像實踐意義不大，誰會無聊的自己複製自己的資料，然後不斷重新整理。
其實不然，大名鼎鼎的線上重定義就是如此。我們來捋一捋裡面的一些東西。
線上重定義需要有一個檢查步驟。
EXEC dbms_redefinition.can_redef_table('N1','TAB_PART_ONE_PAR',1); 
預設是需要使用PK,否則會報出錯誤ORA-12089: cannot online redefine table "N1"."TAB_PART_ONE_PAR" with no primary key
而一種改進思路就是使用rowid的方式，改進成為下面的形式即可。
EXEC dbms_redefinition.can_redef_table('N1','TAB_PART_ONE_PAR',dbms_redefinition.cons_use_rowid); 
在同一個資料庫中，這樣做是沒有問題的，我們完全可以透過rowid定位到具體的一行資料。
而線上重定義為什麼能夠始終保持重定義的過程中，源表始終可用，其實內部就是在透過物化檢視日誌來得到增量的資料變化，重定義過程中DML操作依舊是在源表上進行，對於源表要說完全沒有影響那是不可能的，但是能夠保證資料訪問，更新操作始終可進行，這個意義就大大不同了。為什麼一個表可以線上修改為分割槽表，為什麼一個表新增若干個欄位始終會保持業務不受影響。因為線上重定義的本質就是物化檢視的prebuilt，比如我們要把一個普通表改為分割槽表，那麼普通表就是源表，分割槽表就是目標表。
線上重定義的過程中會從源表中複製資料到目標表，類似於insert into 目標表 select *from 源表，或者dbms_mview.refresh('目標表‘，'C')這種方式。
而增量的資料則會寫入物化檢視日誌，可以在後續不斷去重新整理縮小資料的差異。這個過程就是無話檢視的增量重新整理，類似於dbms_mview.refresh('目標表‘,'F');
而在最後確認無誤的情況下，能夠刪除和表同名的物化檢視，則停止了資料的更新，這樣目標表也釋放出來了，這個時候需要做的就是，複製源表的資料字典資訊，和目標表替換。整個過程都給完整的銜接起來了。
    如此看來，線上重定義的過程真是好玩，和物化檢視prebuilt方式較大的差別就是資料字典資訊的複製，而在多資料庫環境中，源庫，目標庫的資料訪問資訊本就不同，所以也就無需考慮這個因素了，大道至簡，其實很多思路都是相通。