今天在搭建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:
SQL> startup mount;
2) perform a cancel-based recovery, and CANCEL when prompted:
SQL> recover database until cancel;
cancel
3) recreate the online logs:
SQL> alter database open resetlogs;
但是我目前的环境是一个测试环境，很多归档文件都因为空间的原因给删掉了，所以想做恢复都难，但是可以看出是由于控制文件和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等方式就不适用了。