Re: REAL TIME APPLY doesn't seem to be working correctly

From: Neil Chandler <neil_chandler_at_hotmail.com>
Date: Mon, 29 Apr 2019 22:17:26 +0000
Message-ID: <DB7PR10MB209032524624DF6E195AA11285390_at_DB7PR10MB2090.EURPRD10.PROD.OUTLOOK.COM>



Sandra,

Try recreating your Standy Redo Logs with the thread explicitly stated:

Check my blog post from January for details: https://chandlerdba.com/2019/01/03/data-guard-unexpected-lag/

Neil.
sent from my phone

On 29 Apr 2019, at 22:45, Sandra Becker <sbecker6925_at_gmail.com<mailto:sbecker6925_at_gmail.com>> wrote:

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 Tue Apr 30 2019 - 00:17:26 CEST

Original text of this message