Below are different kind of problems where you have recovery issues in standby. Before you take any decision check with your colleagues.
1) Check on source :
SQL> select dest_id,error from v$archive_dest_status;
2) To know the redo apply rate :
set linesize 500
col item format a40
col type format a20
col total noprint
col units format a20
col timestamp noprint
col apply_rate_in_min 999.99
col “app_rt|red_sz_mb” format a20
select start_time , type ,item , units , sofar , total,timestamp ,
(select round( a.sofar/b.sofar /60 ,2)||’ ‘||round(c.sofar/b.sofar)
from v$recovery_progress a , v$recovery_progress b , v$recovery_progress c
where a.item=’Elapsed Time’ and b.item=’Log Files’ and c.item=’Redo Applied’
and a.start_time = b.start_time and a.start_time = c.start_time and
d.start_time = c.start_time) “app_rt|red_sz_mb” from v$recoverY_progress d;
3) Check FRA area in standby if recovery is not moving.
4) Check archivelog (mount point) free space on target.
5) Check if archive log is missing.
6) check if archive log is corrupted (rare option)
7) check if fal is working properly or not.
8) Always open alert log windown when troubleshooting on primay and standby.
9) One option is Try to restart recovery.
10) Try to bounce standby DB instance.
11) IF recovery is not moving and MRP is not responding when u do cancel then kill MRP and check with team before doing it.
12) Sometimes you can make recovery fast by disabling flash, Increase db_cache, increase parallel recovery to 48. (If you need to process so many archives)
(check with your Lead/colleagues before changing anything in production).
Note : If you have any suggestions please provide your feedback in comments.
Srikanth
Nice precautionary and recovery steps. Thanks for posting.
Sunil
Nice article