hi there,
version 10.2.0.4 linux 64 bit
i was getting error
Error 12516 03-SEP-2012 12:15:35
PING[ARC1]: Heartbeat failed to connect to standby 'paceview'. Error is 12516.
Error 12516 03-SEP-2012 12:16:35
PING[ARC1]: Heartbeat failed to connect to standby 'paceview'. Error is 12516.
Error 12516 03-SEP-2012 12:17:35
PING[ARC1]: Heartbeat failed to connect to standby 'paceview'. Error is 12516.
Error 12516 03-SEP-2012 12:18:35
PING[ARC1]: Heartbeat failed to connect to standby 'paceview'. Error is 12516.
Error 12516 03-SEP-2012 12:19:35
PING[ARC1]: Heartbeat failed to connect to standby 'paceview'. Error is 12516.
Error 12516 03-SEP-2012 12:20:35
PING[ARC1]: Heartbeat failed to connect to standby 'paceview'. Error is 12516.
Error 12516 03-SEP-2012 12:21:35
PING[ARC1]: Heartbeat failed to connect to standby 'paceview'. Error is 12516.
Error 12516 03-SEP-2012 12:22:35
PING[ARC1]: Heartbeat failed to connect to standby 'paceview'. Error is 12516.
Warning 3113 03-SEP-2012 12:24:36
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
so i found lagging ,Now that I know the cause, the focus was now on the resolution
on primary
SQL> select to_char(current_scn) from v$database;
TO_CHAR(CURRENT_SCN)
----------------------------------------
138180108522
SQL> select scn_to_timestamp(138180108522)from dual;
SCN_TO_TIMESTAMP(138180108522)
---------------------------------------------------------------------------
03-SEP-12 03.30.03.000000000 PM
on standby
SQL> select to_char(current_scn) from v$database;
TO_CHAR(CURRENT_SCN)
----------------------------------------
138180104606
i ran the same query to know the timestamp associated with the SCN of the standby database as well (note, I ran it on the primary
database, though; since it will fail in the standby in a mounted mode):
SQL> select scn_to_timestamp(138180104606) from dual;
SCN_TO_TIMESTAMP(138180104606)
---------------------------------------------------------------------------
03-SEP-12 12.39.20.000000000 PM
2. [Standby] Shutdown the standby database
3. [Primary] On the primary, take an incremental backup from the SCN number where the standby has been stuck:
RMAN> run {
2> allocate channel c1 type disk format '/backup/rman/paceview/%U.rmb';
3> backup incremental from scn 138180104606 database;
4> }
rman >backup current controlfile for standby format '/backup/rman/paceview/standby.rmb';
5. [Primary] Copy these files to standby host:
scp * oracle@xxxx xxx:/backup/rman/paceview/
6. [Standby] Bring up the instance in nomount mode:
SQL> startup nomount
connect rman target /
rman>restore standby controlfile from '/backup/rman/paceview/standby.rmb';
rman>sql 'alter database mount standby database';
RMAN> catalog start with '/backup/rman/paceview/';
RMAN> recover database;
Starting recover at 03-SEP-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=37 devtype=DISK
starting media recovery
archive log thread 1 sequence 11 is already on disk as file /PGHProdDB/archive/paceview/1_11_792774613.dbf
archive log thread 1 sequence 12 is already on disk as file /PGHProdDB/archive/paceview/1_12_792774613.dbf
archive log thread 1 sequence 14 is already on disk as file /PGHProdDB/archive/paceview/1_14_792774613.dbf
archive log thread 1 sequence 15 is already on disk as file /PGHProdDB/archive/paceview/1_15_792774613.dbf
archive log thread 1 sequence 16 is already on disk as file /PGHProdDB/archive/paceview/1_16_792774613.dbf
archive log thread 1 sequence 17 is already on disk as file /PGHProdDB/archive/paceview/1_17_792774613.dbf
archive log thread 1 sequence 18 is already on disk as file /PGHProdDB/archive/paceview/1_18_792774613.dbf
archive log thread 1 sequence 19 is already on disk as file /PGHProdDB/archive/paceview/1_19_792774613.dbf
archive log filename=/PGHProdDB/archive/paceview/1_11_792774613.dbf thread=1 sequence=11
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/03/2012 15:45:38
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/PGHProdDB/archive/paceview/1_11_792774613.dbf'
ORA-00283: recovery session canceled due to errors
ORA-12801: error signaled in parallel query server P002
ORA-00600: internal error code, arguments: [3020], [3], [5825], [12588737], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file#
on which step i should focuse on to resolve this issue
thanks
abdul
Edited by: abdul_ora on Sep 3, 2012 4:09 PM