ORACLE DATAGURARD 折騰記二

標籤：des   blog   http   io   os   使用   ar   for   檔案   

 前文再續，書接上一回，這次折騰Data Guard的一個重要目的是利用switchover實現機器的升級，怎麼switchover呢？按照我的理解，Data Guard的角色切換是這樣一個過程：

      （1）讓primary節點變為standby節點。

      （2）讓其中一個standby節點變為primary節點

      這裡比較有意思是“其中一個”，也就是說節點A原來是primary轉成standby後，突然我後悔了，還是可以馬上讓他變回primary節點的，具體看操作：

      此時 test02 是primary 節點，test03是standby節點，由於test03缺少一個參數，一點test03變為primary，歸檔不會自動發到test02，於是第一步要補全這個參數：

12	##### test03 target priamry, standby now #####alter system set log_archive_dest_2=‘service=mydb_test02‘;

      讓test02由primary變為standby：

12	##### test02, target standby, primary now #####alter database commit to switchover to physical standby ;

      以上語句有可能會遇到如下錯誤：

1234	alter database commit to switchover to physical standby*ERROR at line 1:ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

      這是由於一些串連還沒有釋放所致的，將前端應用關閉後如果還出現這種情況，可以用以下語句確認一下有哪些串連：

1234	##### test02, target standby, primary now #####SELECT SID, PROCESS, PROGRAM FROM V$SESSION   WHERE TYPE = ‘USER‘AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT);

      如果是Oracle內部進程的串連就不用管他了，執行如下語句就可以了：

1234	##### test02, target standby, priamry now #####alter database commit to   switchover to physical standby   with session shutdown

      將test03也就是原來是standby的節點轉為primary：

123	##### test03, target primary, standby now #####alter database commit to switchover to primary;##### test03, target primary, primary now #####

      開啟primary節點的資料庫，使其可對外服務：

123	##### test03, target primary, primary now #####shutdown immediate;startup;

      啟動standby的歸檔恢複進程：

12	##### test02, target standby, standby now #####alter database recover managed standby database disconnect from session;

      此時已經完成了Data Guard 主備切換了，可以監控住standby的alert檔案，在primay中做一次日誌切換，看看是否有歸檔記錄傳送過來並且恢複。

 

      如果監控時間比較長的（超過5分鐘）會看到如下錯誤：

123456789101112131415161718

##### primary alert #####Fri Dec 17 14:04:46 2010Redo Shipping Client Connected as PUBLIC-- Connected User is ValidRFS[10]: Assigned to RFS process 12079RFS[10]: Database mount ID mismatch [0x9e217391:0x9e217bca]RFS[10]: Client instance is standby database instead of primaryRFS[10]: Not using real application clustersFri Dec 17 14:04:46 2010Errors in file /u01/app/admin/mydb/udump/mydb_rfs_12079.trc:ORA-16009: remote archive log destination must be a STANDBY database   ##### standby alert #####Fri Dec 17 14:04:54 2010Errors in file /u01/app/admin/mydb/bdump/mydb_arc1_6821.trc:ORA-16009: remote archive log destination must be a STANDBY databaseFri Dec 17 14:04:54 2010PING[ARC1]: Heartbeat failed to connect to standby ‘mydb_test02‘. Error is 16009.

      雖然不影響 Data Guard 的功能和使用，但如何解決呢？其實這是歸檔進程ARCHn進程在作怪，想辦法屏蔽就可以，一個比較土的方法就是將備節點的log_archive_dest_2設為空白，也就是回到上一篇中提到那種配置上，另外一種聰明點的做法就是引入valid_for參數：

12345

##### test02 #####alter system set log_archive_dest_2=‘service=mydb_test03 valid_for=(online_logfiles,primary_role)‘; ##### test03 #####alter system set log_archive_dest_2=‘service=mydb_test02 valid_for=(online_logfiles,primary_role)‘;

      alert檔案中再也看不到這兩個錯誤了。

ORACLE DATAGURARD 折騰記二