REAL TIME APPLY doesn't seem to be working correctly

From: Sandra Becker <sbecker6925_at_gmail.com>
Date: Mon, 29 Apr 2019 15:43:29 -0600
Message-ID: <CAJzM94Cc-oO6dmj7tyhNArio6PVNT0iOYFSjgKJ_zb__9HMakQ_at_mail.gmail.com>



OS: RHEL 7.5
Oracle: EE 12.1.0.2

We have created a standby database with REAL TIME APPLY, or so we thought. Everything says it's REAL TIME APPLY, but the logs are not being applied right away. We have to do a log switch before the log gets applied. I've recreated the standby redo logs as described in DocID 1956103.1, but it didn't make any difference. I cannot shutdown the primary for another two weeks if some change is needed there. The standby I can bounce as needed. I have 3 online redo groups in both the primary and standby. Due to company policy, I have had to obfuscate some of the values. Hopefully, they still match where they should. I'm open to suggestions/recommendations. We would like to understand what's going on and get the REAL TIME APPLY working as it is in the other database on this node.

Thanks in advance.

*Primary Configuration*

NAME                                                    VALUE

log_archive_config             DG_CONFIG=(prim,stdby)
log_archive_dest_1             location=/backup/db/archives
log_archive_dest_2             SERVICE=stdby NOAFFIRM ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby
log_archive_dest_state_1       ENABLE
log_archive_dest_state_2       ENABLE

fal_client                     prim
fal_server                     stdby





DEST_ID STATUS     RECOVERY_MODE           DATABASE_MODE   DEST_NAME
------- ---------- ----------------------- ---------------
------------------
      1 VALID      IDLE                    OPEN
LOG_ARCHIVE_DEST_1
      2 VALID      MANAGED REAL TIME APPLY MOUNTED-STANDBY
LOG_ARCHIVE_DEST_2 Standby Redo

THREAD# GROUP# SEQUENCE# MBYTES ARC STATUS

  • ------- ---------- ---------- --- ----------

      0 4 0 512 YES UNASSIGNED       0 1 0 512 YES UNASSIGNED       0 2 0 512 YES UNASSIGNED       0 3 0 512 YES UNASSIGNED
*Standby Configuration*

NAME                           VALUE

------------------------------ -------------------------------

fal_client                     stdby

fal_server                     prim

log_archive_config             DG_CONFIG=(stdby,prim)

log_archive_dest_1             location=/backup/db/archives

log_archive_dest_2

log_archive_dest_state_1 ENABLE

log_archive_dest_state_2 ENABLE

Standby Redo

THREAD# GROUP# SEQUENCE# MBYTES ARC STATUS

  • ------- ---------- ---------- --- ----------

      0 4 0 512 YES UNASSIGNED       1 1 0 512 YES UNASSIGNED       1 2 0 512 YES UNASSIGNED       1 3 0 512 YES UNASSIGNED
*Excerpt from alert.log*

ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH; alter database recover managed standby database disconnect from session Mon Apr 29 19:33:45 2019
Attempt to start background Managed Standby Recovery process (stdby) Starting background process MRP0
Mon Apr 29 19:33:45 2019
MRP0 started with pid=47, OS id=17095
Mon Apr 29 19:33:45 2019
MRP0: Background Managed Standby Recovery process started (stdby) Mon Apr 29 19:33:50 2019
 Started logmerger process
Mon Apr 29 19:33:50 2019
Managed Standby Recovery starting Real Time Apply Mon Apr 29 19:33:50 2019
Parallel Media Recovery started with 16 slaves Mon Apr 29 19:33:50 2019
Waiting for all non-current ORLs to be archived... Mon Apr 29 19:33:50 2019
All non-current ORLs have been archived. Completed: alter database recover managed standby database disconnect from session
Mon Apr 29 19:33:55 2019
Media Recovery Waiting for thread 1 sequence 4028 (in transit) Mon Apr 29 19:54:27 2019
Archived Log entry 179 added for thread 1 sequence 4028 rlc 990978301 ID 0x119275a8 dest 2:
Mon Apr 29 19:54:27 2019
Network Resource Management enabled for Process (pid 21521) for Exadata I/O Mon Apr 29 19:54:27 2019
Media Recovery Log /backup/sildb/archives/1_4028_990978301.arc Mon Apr 29 19:54:27 2019

.
.
.


-- 
Sandy B.

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Apr 29 2019 - 23:43:29 CEST

Original text of this message