Re: REAL TIME APPLY doesn't seem to be working correctly
Date: Tue, 30 Apr 2019 07:52:12 +0000 (UTC)
Message-ID: <154887096.2549602.1556610732450_at_mail.yahoo.com>
You should start using the data guard broker.It takes care of much of the really complicated setup.Pay attention to LogXptMode, data protection mode, and commands SHOW [configuration especially], VALIDATE [DATABASE]
On Tuesday, April 30, 2019, 12:44:28 AM GMT+3, Sandra Becker <sbecker6925_at_gmail.com> wrote:
OS: RHEL 7.5Oracle: 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 ConfigurationNAME 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 MANAGEDREAL 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 - 09:52:12 CEST