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

From: Shane Borden <sborden76_at_gmail.com>
Date: Mon, 29 Apr 2019 18:03:15 -0400
Message-Id: <A7CBDD6A-82C8-4516-925B-323052D8F8BC_at_gmail.com>



2 things here.

First, I’m pretty sure for real time apply, I think you have to specify the following recovery command:

        alter database recover managed standby using current logfile disconnect from session;

        instead of:

        alter database recover managed standby disconnect from session;

Second, I believe that even in a non-rac standby, you still have to create the standby redo logs with a thread number. I have had issues before when I did not do this. Also make sure you create at least one additional standby log than what the primary has.

Thanks,

Shane Borden
sborden76_at_gmail.com
407-963-4883

> On Apr 29, 2019, at 5:43 PM, Sandra Becker <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:03:15 CEST

Original text of this message