ORACLE 11G "real time apply" not work?????

Question

we have a database original on ORACLE 10.2.0.4 and we upgrade it to 11.1.0.7.
after that we create standby database and tried to use "real time apply" feature.
Primary database can transfer log files to standby database and standby database also can apply logs. The problem is it can NOT work on "real time apply".
Ant ideal what wrong?
=== procedures ====== (standby database)
SQL> startup mount;
ORACLE instance started.
Total System Global Area 2087780352 bytes
Fixed Size 2161272 bytes
Variable Size 1795163528 bytes
Database Buffers 251658240 bytes
Redo Buffers 38797312 bytes
Database mounted.
SQL> alter database open read only;
Database altered.
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
SQL> select PROTECTION_MODE, PROTECTION_LEVEL, DATABASE_ROLE, SWITCHOVER_STATUS, OPEN_MODE, GUARD_STATUS from v$database;
PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE SWITCHOVER_STATUS
OPEN_MODE GUARD_S
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY NOT ALLOWED
MOUNTED NONE
SQL> select process, status from v$managed_standby;
PROCESS STATUS
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
RFS IDLE
MRP0 APPLYING_LOG
6 rows selected.
========== Primary database init.ora file setup =====
### for DG use
db_unique_name = DBPMY
log_archive_config='dg_config=(DBPMY,DBSBY)'
log_archive_dest_1='LOCATION=/Archive/DBPMY/arch/arch MANDATORY'
log_archive_dest_2='service=DBSBY valid_for=(online_logfiles,primary_role) db_unique_name=DBSBY LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30'
*.log_archive_format='DBPMY_%r_%t_%s.arc'
log_archive_dest_state_1 = enable
log_archive_dest_state_2 = enable

Answer 1

There are a couple of things to look at.
1. Real time apply requires standby redo logs on the standby database. On the standby database run this query:
SELECT * FROM v$logfile where type = 'STANDBY';
if you get 0 rows back you'll need to create standby logfiles
The general guideline is to size them exactly like your redo logs but add one additional standby log to ensure it doesn't cause a bottleneck.
2. Get the size of your logfiles:
SELECT GROUP#, BYTES FROM V$LOG;
3. For example if you have 3 redo logs that are 50 MB in size, create 4 standby redo logs 50 MB each and don't multiplex them.
ALTER DATABASE ADD STANDBY LOGFILE ('/Archive/DBSBY/onlinelog/slog1.rdo') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE ('/Archive/DBSBY/onlinelog/slog2.rdo') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE ('/Archive/DBSBY/onlinelog/slog3.rdo') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE ('/Archive/DBSBY/onlinelog/slog4.rdo') SIZE 50M;
4. Cancel recovery on standby
recover managed standby database cancel;
5. Restart recovery using real time apply
recover managed standby database using current logfile disconnect;
6. To validate that real time is working you can check a few places.
-It will say in the database alert log on standby that it's using real time apply
OR
-Check primary
SELECT status, recovery_mode FROM v$archive_dest_status where dest_name = 'LOG_ARCHIVE_DEST_2';
If the recovery_mode is "MANAGED REAL TIME APPLY" then real time apply is working, if it's anything else then we'll need to check more things.
NOTE that if you are going to allow your current primary to switch roles and become a standby then you'll want to create standby redo logs on primary as well
Sometimes recovery gets "stuck" and simply resetting the destination parameters can resolve it:
alter system set log_archive_dest_2='service=DBSBY valid_for=(online_logfiles,primary_role) db_unique_name=DBSBY LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30';
There are some other things we can check next but let's start with the easiest fixes first.