搭建dataguard碰到的幾個小問題

今天在搭建dataguard環境的時候，發現操作還是生疏了，環境也被反反覆覆折騰了好久，也碰到了一些小問題，總結一下。
第一個問題是使用sys賬戶登入rman的時候總是報錯。比如密碼是oracle ，使用sqlplus登入的時候總是報錯。
>sqlplus sys/oracle@test11g as sysdba
ERROR:ORA-01031: insufficient privileges
這個問題的思路就是密碼檔案出現了問題，但是使用orapwd重建密碼檔案都不見效，最後冷靜下來，使用tnsping test11g的時候也沒有錯誤
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = oel1.oracle.com)(PORT = 1511))) (CONNECT_DATA = (SERVICE_NAME = DG11G)))
OK (30 msec)
最後發現是因為listener.ora和tnsnames.ora中的sid_name配置錯誤導致的。
可見這個問題還是帶有一些隱蔽性，在密碼檔案那下了不少功夫，結果發現是由最低階的錯誤導致的。

第二個問題是在主備環境都準備好了，準備先啟動一下主庫，結果報了下面的錯誤。
Errors in file /u01/app/ora11g/diag/rdbms/test11g/TEST11G/trace/TEST11G_lgwr_26304.trc:
ORA-00314: log 1 of thread 1, expected sequence# 49 doesn't match 0
ORA-00312: online log 1 thread 1: '/u02/ora11g/oradata/TEST11G/redo01.log'
Errors in file /u01/app/ora11g/diag/rdbms/test11g/TEST11G/trace/TEST11G_lgwr_26304.trc:
ORA-00314: log 1 of thread 1, expected sequence# 49 doesn't match 0
ORA-00312: online log 1 thread 1: '/u02/ora11g/oradata/TEST11G/redo01.log'
Mon May 11 18:00:27 2015
ARC1 started with pid=21, OS id=26328 
Errors in file /u01/app/ora11g/diag/rdbms/test11g/TEST11G/trace/TEST11G_ora_26324.trc:
ORA-00314: log 1 of thread , expected sequence#  doesn't match 
ORA-00312: online log 1 thread 1: '/u02/ora11g/oradata/TEST11G/redo01.log'
USER (ospid: 26324): terminating the instance due to error 314
Instance terminated by USER, pid = 26324
看這個錯誤，感覺是哪裡不匹配了。檢視了metalink有一篇相關的文章。

ORA-314 Attempting to Startup Database following Restore from Cold Backup (Doc ID 330793.1)

對於這個問題，給出的解決方案是做恢復

CAUSE

Cold backup of database did not include online redo logs.

The error stack would indicate that there are online redo log files on disk that are older than what the controlfile is expecting. In other words, the redo logs and controlfile do not match.

SOLUTION

Online redo logs are not required for cold backups. Once the cold backup has been restored, and you only need to open the database at this point, you can recreate the online redo logs as follows: 

1) mount the database:

 

2) perform a cancel-based recovery, and CANCEL when prompted:

 

3) recreate the online logs:

但是我目前的環境是一個測試環境，很多歸檔檔案都因為空間的原因給刪掉了，所以想做恢復都難，但是可以看出是由於控制檔案和redo的資訊不匹配導致的。
對於這個問題可以採用其他的臨時解決方法，最終的目標就是能把庫正常啟用。所以採用瞭如下的方法。
idle> alter database clear logfile group 1;
Database altered.
根據v$log的資訊，對log group 2也做了clear操作。但是log group 3就碰到了一些問題。
idle> alter database clear logfile group 3;
alter database clear logfile group 3
*
ERROR at line 1:
ORA-00350: log 3 of instance TEST11G (thread 1) needs to be archived
ORA-00312: online log 3 thread 1: '/u02/ora11g/oradata/TEST11G/redo03.log'
如果忽略這個錯誤，資料庫還是無法正常open.
alter database open
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 27129
Session ID: 125 Serial number: 7
所以還是需要特別的操作。因為這個時候logfile 3還沒有將日誌內容刷到歸檔路徑去。我們根據自己的情況做一個取捨，目前的目標是保證可用性，所以可以考慮直接做clear操作。
idle> alter database clear unarchived logfile '/u02/ora11g/oradata/TEST11G/redo03.log';
Database altered.

idle> alter database open;
Database altered.
需要注意的是 clear unarchived logfile的使用場景是清楚正常關閉狀態下的日誌組，如果是shutdown abort等方式就不適用了。