机房断电，所以oracle的datagard的从库需要重新启动：
1 登录sqlplus启动，出现报错信息：
SQL> STARTUP MOUNT;
ORA-16032: parameter LOG_ARCHIVE_DEST_3 destination string cannot be translated
ORA-07286: sksagdi: cannot obtain device information.
Linux-x86_64 Error: 2: No such file or directory
2 去查看找下 LOG_ARCHIVE_DEST_3 的具体路径
[[email protected] ~]# su - oracle
[[email protected] ~]$ echo $ORACLE_HOME
/oracle/app/oracle/product/11.2.0/dbhome_1
[[email protected] ~]$ cd /oracle/app/oracle/product/11.2.0/dbhome_1
[[email protected] dbhome_1]$
[[email protected] dbhome_1]$ cd dbs
[[email protected] dbs]$ ll
总用量 13160
-rw-rw----. 1 oracle dba 1544 5月 4 14:49 hc_powerdes.dat
-rw-r--r--. 1 oracle dba 2851 5月 15 2009 init.ora
-rw-r-----. 1 oracle dba 24 8月 27 2013 lkPDDGUNQ
-rw-r-----. 1 oracle oinstall 1536 8月 27 2013 orapwpowerdes
-rw-r-----. 1 oracle dba 13451264 4月 27 05:00 snapcf_powerdes.f
-rw-r-----. 1 oracle dba 5632 8月 30 2013 spfilepowerdes.ora
3 # 找到了路径
[[email protected] dbs]$ strings spfile*.ora|grep dest_3
*.log_archive_dest_3=‘LOCATION=/data/oracle/oradgdata/standby_archive VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=pddgunq‘
4 check路径，排查问题
[[email protected] data]# ls -l /data/oracle/oradgdata/standby_archive
ls: 无法访问/data/oracle/oradgdata/standby_archive: 没有那个文件或目录
[[email protected] dbs]$ mkdir -p /data/oracle/oradgdata/standby_archive
mkdir: 无法创建目录"/data/oracle": 只读文件系统
[[email protected] dbhome_1]$ df -h
文件系统 容量 已用 可用 已用%% 挂载点
/dev/mapper/VolGroup-lv_root
50G 28G 19G 60% /
tmpfs 8.9G 3.0G 5.9G 34% /dev/shm
/dev/sda2 485M 76M 384M 17% /boot
/dev/sda1 200M 260K 200M 1% /boot/efi
/dev/mapper/VolGroup-lv_home
76G 37G 36G 51% /home
/dev/sdb1 1008G 221G 737G 24% /data
5 解决问题
/data已经存在了，只是无法使用，google，看到2种解决方案
mkdir: 无法创建目录‘XX’: 只读文件系统
touch: 无法触碰 “XX”: 只读文件系统,
建立文件和目录都提示错误，
解决方法如下:
第一，重起服务器
我的这样就好了。
第二，
如果第一不好使的话，
就得进行修复硬盘了，
开机进入修复模式，
看你是在哪个目录下能建立文件，然后用 fsck.ext3 -y ..挂载分区...进行修复就ok了。
参考： http://hi.baidu.com/lijunyi0198/item/2558f8c613618f61f6c95d04
reboot试试看
6 再次登录sqlplus start从库
SQL> STARTUP MOUNT; ORACLE instance started. Total System Global Area 5344731136 bytes Fixed Size 2213136 bytes Variable Size 3489663728 bytes Database Buffers 1811939328 bytes Redo Buffers 40914944 bytes Database mounted. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; Database altered. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE * ERROR at line 1: ORA-01153: an incompatible media recovery is active SQL> alter database open; alter database open * ERROR at line 1: ORA-10456: cannot open standby database; media recovery session may be in progress
# 有报错信息，看到这里，需要暂时中止media recovery了。
SQL> recover managed standby database cancel; Media recovery complete.
7 试图再自动 recover下，不过还是fail，只要再次中止
SQL> recover automatic standby database ;
ORA-00279: change 10386441904 generated at 04/18/2014 17:56:46 needed for
thread 1
ORA-00289: suggestion :
/data/oracle/oradgdata/standby_archive/1_7368_821708334.dbf
ORA-00280: change 10386441904 for thread 1 is in sequence #7368
ORA-00278: log file
‘/data/oracle/oradgdata/standby_archive/1_7368_821708334.dbf‘ no longer needed
for this recovery
ORA-00308: cannot open archived log
‘/data/oracle/oradgdata/standby_archive/1_7368_821708334.dbf‘
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log
‘/data/oracle/oradgdata/standby_archive/1_7368_821708334.dbf‘
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Media recovery complete.
8，查看下当前datagard的状态
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE -------------------------------------------------------------------------------- ARC0: Archival started ARC1: Archival started ARC2: Archival started ARC3: Archival started ARC4: Archival started ARC5: Archival started ARC6: Archival started ARC7: Archival started ARC8: Archival started ARC9: Archival started ARCa: Archival started MESSAGE -------------------------------------------------------------------------------- ARCb: Archival started ARCc: Archival started ARCd: Archival started ARCe: Archival started ARCf: Archival started ARCg: Archival started ARCh: Archival started ARCi: Archival started ARC1: Becoming the ‘no FAL‘ ARCH ARC2: Becoming the heartbeat ARCH ARCj: Archival started MESSAGE -------------------------------------------------------------------------------- Media Recovery Start: Managed Standby Recovery Managed Standby Recovery not using Real Time Apply Media Recovery Waiting for thread 1 sequence 7368 Fetching gap sequence in thread 1, gap sequence 7368-7392 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 7368-7392 DBID 3391761643 branch 821708334 FAL[client]: All defined FAL servers have been attempted. Attempt to start background Managed Standby Recovery process MRP0: Background Managed Standby Recovery process started Managed Standby Recovery not using Real Time Apply MESSAGE -------------------------------------------------------------------------------- Media Recovery Waiting for thread 1 sequence 7368 Fetching gap sequence in thread 1, gap sequence 7368-7392 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 7368-7392 DBID 3391761643 branch 821708334 FAL[client]: All defined FAL servers have been attempted. MRP0: Background Media Recovery cancelled with status 16037 MRP0: Background Media Recovery process shutdown Managed Standby Recovery Canceled Managed Standby Recovery not using Real Time Apply Attempt to start background Managed Standby Recovery process MESSAGE -------------------------------------------------------------------------------- MRP0: Background Managed Standby Recovery process started Managed Standby Recovery not using Real Time Apply Media Recovery Waiting for thread 1 sequence 7368 Fetching gap sequence in thread 1, gap sequence 7368-7392 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 7368-7392 DBID 3391761643 branch 821708334 FAL[client]: All defined FAL servers have been attempted. 52 rows selected.
9 再试试直接修改状态到open吧
# 打开standary从库
SQL> alter database open; Database altered. SQL> select open_mode from v$database; OPEN_MODE -------------------- READ ONLY # 将备库置于自动恢复状态 SQL> recover managed standby database disconnect from session; Media recovery complete.
10 # check，检查主从的归档日志情况
# 主库状态:
SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination /oracle/app/oracle/flash_recovery_area/archivelog Oldest online log sequence 7777 Next log sequence to archive 7779 Current log sequence 7779 SQL>
#从库状态：
SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination /data/oracle/oradgdata/standby_archive Oldest online log sequence 7778 Next log sequence to archive 0 Current log sequence 7779 SQL>
最后问猫猫，怎么样才能彻底check下datagard主从数据一致，结果被猫猫美女一顿狂批，多看点datagard官方文档，别老问她，得自己去专研去总结。
哈哈，看来是得抽功夫去恶补下oracle datagard了。
[Oracle datagard]从库恢复之 ORA-16032: parameter ORA-07286:问题