測試環境的遷移式升級和資料整合

很多時候，大家工作中都會有一種被動的思維，那就是能不動就不動，從求穩的角度來看無可厚非，但是從風險的角度來說，還是有待商榷的。如果存在風險，還保持原樣很可能就是一個不定時炸彈。
這不手頭有一套環境，按照以前的標準是根本入不了我的法眼的，但是因為是測試環境，小問題比較多，存在容災風險，但是這麼多年一直這樣，也就默然接受了。
這套環境硬體配置很低，基本上和我的筆記本配置差不多，可能還略差一些，在上面跑著3個資料庫例項，其中一個是11g的，2個是10g的。兩個10g的資料庫例項資料量都不大，幾十G而已。
看起來是有些彆扭，而且這幾個資料庫例項都是執行在費歸檔模式下，對於備份目前是採用了邏輯備份的方式，備份了幾個重要的schema資料，每天凌晨開始執行，然後上傳到異機上去。
聽起來也還是可行的，但是一旦發生硬體問題，恢復就是一個大麻煩。
這部凌晨就收到了報警，然後發現這臺伺服器不可用了。登入ILO之後，發現系統健康情況為Unknown，已經無法連通了。

然後發現備用電源已經停了，強制手工啟動之後，算是勉強撐了4個多小時，然後中午又當機了，下午三點又當機一次。
當然這個期間，自己已經開始著實一些具體的工作了。
經過評估，發現這個問題還得先整合起來，然後逐步遷移例項。
類似下面的情況，首先在一臺新的伺服器上安裝11gR2的軟體，然後把11g的庫做成dataguard的形式，然後switchover,這樣11g的庫就遷移出去了，然後對於10gR2的庫來說，因為資料量不大，可以考慮直接邏輯匯出匯入即可。當然前提是這幾個資料庫中的使用者表沒有衝突。

搭建dataguard用了沒多少時間，簡單確認就可以直接切換了。測試環境所以流程上就會送一些，但是資料遷移的質量還是要保持，當然吐槽一下dataguard搭建過程中的錯誤。
搭建的過程中報錯。
input datafile file number=00061 name=/U01/app/oracle/oradata/actvdb/slzj_actv_index01.dbf
output file name=/U01/app/oracle/oradata/actvdb/slzj_actv_index01.dbf tag=TAG20160303T133618
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 03/03/2016 13:30:18
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script

trace日誌的資訊如下：
Errors in file /U01/app/oracle/diag/rdbms/sactvdb/actvdb/trace/actvdb_ora_18030.trc:
ORA-19505: failed to identify file "/U01/app/oracle/product/11.2.3/db_1/dbs/d:oracleoradatamytbs_tl.dbf"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 1
Thu Mar 03 13:26:37 2016
Errors in file /U01/app/oracle/diag/rdbms/sactvdb/actvdb/trace/actvdb_ora_18032.trc:
這個問題有多奇葩，竟然在$ORACLE_HOME/dbs下有資料檔案，而且竟然還是以d:字樣開頭的資料檔案。
主庫端馬上做了修復，
alter tablespace TEST_ACTV_DATA offline;
!cp '/U01/app/oracle/product/11.2.3/db_1/dbs/d:oracleoradatamytbs_tl.dbf' '/U01/app/oracle/oradata/actvdb/d:oracleoradatamytbs_tl.dbf';
alter tablespace TEST_ACTV_DATA rename datafile '/U01/app/oracle/product/11.2.3/db_1/dbs/d:oracleoradatamytbs_tl.dbf' to '/U01/app/oracle/oradata/actvdb/d:oracleoradatamytbs_tl.dbf';
alter tablespace TEST_ACTV_DATA online;
然後繼續同步，就會從上次的斷點處繼續，很快就做好了。
然後開始做switchover，當然速度也很快，都在計劃之中。
DGMGRL> show configuration;
Configuration - actvdb_dg
  Protection Mode: MaxPerformance
  Databases:
    actvdb  - Primary database
    sactvdb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> switchover to sactvdb;
Performing switchover NOW, please wait...
New primary database "sactvdb" is opening...
Operation requires shutdown of instance "actvdb" on database "actvdb"
Shutting down instance "actvdb"...
ORA-01031: insufficient privileges
第一步完成，後面的就是做資料的整合了。邏輯備份不會同步下面的這些資訊。
profile資訊，使用者的密碼和基本基本許可權資訊，系統許可權，角色，表空間定義資訊等，這些都需要我們自己來完成。
當然這些也不是什麼難事了。生成使用者的基本定義資訊。
select dbms_metadata.get_ddl('USER',u.username) from dba_users u WHERE USERNAME  in ('ACC',。。。。。);
select dbms_metadata.get_granted_ddl('SYSTEM_GRANT',u.username) from dba_users u WHERE USERNAME in USERNAME  in ('ACC',。。。。。);
select dbms_metadata.get_granted_ddl('ROLE_GRANT',u.username) from dba_users u WHERE USERNAME in USERNAME  in ('ACC',。。。。。);

生成表空間資訊
select dbms_metadata.get_ddl('TABLESPACE', ts.tablespace_name)||';' from dba_tablespaces ts;  
邏輯備份匯出
exp xxx/xxx owner=ACC1,ACC2，ACC3....   buffer=9102000 statistics=none log=acc_test1.log file=acc_test1.dmp
邏輯匯入
imp xxx/xxx fromuser=ACC1,ACC2，ACC3.... touser=ACC1,ACC2，ACC3....   buffer=9102000 statistics=none log=acc_test1_imp.log file=acc_test1.dmp
前期準備較好，資料的遷移就會很流暢。
遷移完成之後，終於能夠鬆一口氣，也算是脫離那個定時炸彈了，後期修復了電源之後，這臺伺服器還可以勉強做個備庫。得來全不費功夫。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2029946/，如需轉載，請註明出處，否則將追究法律責任。