Real-time apply cascaded logical standby database

Hi
I have a primary database orcl
Pysical standby database orcl_std
Cascaded logical standby database orcl_tri which receives archivelogs from orcl_std
Real time apply is enabled both in orcl_std (physical standby) and orcl_tri (logical standby)
When I create a table in primary orcl, I am unable to see it on orcl_tri (Although real time apply is enabled)
However, when I switch log in primary, I can see the new table on orcl_tri.
My question is, why realtime apply is not working in my scenerio ?
orcl_std : ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION USING CURRENT LOGFILE;
orcl_tri: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Oracle 11.2.0.3.0

Hi mseberg,
Thanks for your reply.
There is no load or network issue as I`ve just created these databases for the experiement.
I have the same output from standby and primary databases.
SQL> select bytes/1024/1024 from  v$standby_log;
BYTES/1024/1024
             10
             10
             10I can see below output in standby alertlog
Fri Nov 16 08:39:51 2012
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
ALTER DATABASE START LOGICAL STANDBY APPLY (orcl)
with optional part
IMMEDIATE
Attempt to start background Logical Standby process
Fri Nov 16 08:39:51 2012
LSP0 started with pid=37, OS id=16141
Completed: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
LOGMINER: Parameters summary for session# = 1
LOGMINER: Number of processes = 3, Transaction Chunk Size = 201
LOGMINER: Memory Size = 30M, Checkpoint interval = 150M
LOGMINER: SpillScn 1953318, ResetLogScn 995548
LOGMINER: summary for session# = 1
LOGMINER: StartScn: 0 (0x0000.00000000)
LOGMINER: EndScn: 0 (0x0000.00000000)
LOGMINER: HighConsumedScn: 1955287 (0x0000.001dd5d7)
LOGMINER: session_flag: 0x1
LOGMINER: Read buffers: 16
Fri Nov 16 08:39:55 2012
LOGMINER: session#=1 (Logical_Standby$), reader MS00 pid=30 OS id=16145 sid=49 started
Fri Nov 16 08:39:55 2012
LOGMINER: session#=1 (Logical_Standby$), builder MS01 pid=39 OS id=16149 sid=44 started
Fri Nov 16 08:39:55 2012
LOGMINER: session#=1 (Logical_Standby$), preparer MS02 pid=40 OS id=16153 sid=50 started
LOGMINER: Turning ON Log Auto Delete
LOGMINER: Begin mining logfile during commit scan for session 1 thread 1 sequence 202, +DATA/orcl_std/archivelog/2012_11_15/thread_1_seq_202.349.799450179
LOGMINER: End mining logfiles during commit scan for session 1
LOGMINER: Turning ON Log Auto Delete
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 202, +DATA/orcl_std/archivelog/2012_11_15/thread_1_seq_202.349.799450179
LOGMINER: End   mining logfile for session 1 thread 1 sequence 202, +DATA/orcl_std/archivelog/2012_11_15/thread_1_seq_202.349.799450179
Fri Nov 16 08:40:04 2012
LOGSTDBY Analyzer process AS00 started with server id=0 pid=41 OS id=16162
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS03 started with server id=3 pid=45 OS id=16175
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS04 started with server id=4 pid=46 OS id=16179
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS01 started with server id=1 pid=42 OS id=16167
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS05 started with server id=5 pid=47 OS id=16183
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS02 started with server id=2 pid=44 OS id=16171Do you think real-time apply wasnt setup properly ?

Similar Messages

  • Real time apply for logical standby

    Hi
    Oracle 11.2.0.3.0
    I have a primary database orcl and logical standby database orcl_std.
    Real time apply is enabled. I have standby redologs in both primary and standby sides and I`ve started recovery with below command:
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    When I create a new table in primary database, I am unable to see it on standby database (Although real time apply is enabled)
    However, when I switch log in primary, I can see the new table in standby database.
    My question is, why realtime apply is not working in my scenerio ? I was expecting to see the new table immediately in standby database once it is created in primary database. Why am I supposed to wait for log switch in real time apply ?

    Using Real-Time Apply to Apply Redo Data Immediately
    http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_apply.htm#i1022881
    1.What is compatible parameter, it should be 11.1
    2.Try to check parameters mentioned in below link:
    http://easyoradba.com/2011/01/10/real-time-apply-in-oracle-data-guard-10g/
    Regards
    Girish Sharma
    Edited by: Girish Sharma on Nov 15, 2012 12:37 PM

  • When to use Real Time Apply for Logical standby..!!

    Hello All,
    I have been trying many ways to speed up the archival on primary and improve sql apply on logical standby, but still we are getting about 45-50 mins of delay between primary and logical standby.
    We wanted to have our transactions applied on logical standby within couple minutes. Which i guess wont be possible in async mode.
    That's why i am planning to implement Real Time apply between primary and logical standby.
    Now since both our databases are too far away from each other (Primary is in US and logical is in India) would it be recommended to implement real time apply in such scenario? And if implemented would it affect Primary DB Performance?
    Also if there might be some packet loss or network hitch would Primary will try again and keep logical DB in Sync with Primary?
    Any help or suggestions would be great.
    Thanks.

    yes, real time apply is recommended in your scenario.
    however due to the geographical distance between your primary and standby; I would suggest to keep your standby in current mode - max performance ; ASYNC- itself. It would not affect the performace of the primary.
    As long as you set the FAL parameters and configure tnsnames properly and ensure proper deletion policy for archivelog cleanup in primary ( so that it's not deleted before shipping if need be), you shouldn't find any problem with primary & standby synching.
    Good Luck.
    Cheers.

  • Slow SQL Apply on Logical Standby Database in Oracle10g

    Hi,
    We are using Oracle 10g Logical Standby database in our production farm but whenever there is bulk data load (5-6 GB data) on the primary database, the logical standby seems to be hung. It takes days to apply the 5-6 GB data on the logical standby.
    Can anybody give me some pointers how can I make my SQL Apply fast on the logical standby for bulk data.
    Thanks
    Amit

    Hi there,
    I've a similar problem. I did an insert of 700k on a table. It takes me over 1 1/2 hours to see the data. Notice, I increased the "max_sga" to 300m and "max_servers" to 25" and didn't help the performance at all.
    My version is 10.2.0.3 with the patch 6081550.
    APPLIED_SCN APPLIED_TIME RESTART_SCN RESTART_TIME LATEST_SCN LATEST_TIME MINING_SCN MINING_TIME
    1015618 29-NOV-2007 18:28:51 1009600 29-NOV-2007 18:28:51 1017519 29-NOV-2007 19:54:07 1015656 29-NOV-2007 18:32:14

  • Redo data not applied on logical standby database 10g

    after a network problem within the primary and the logical standby database. The redo data is not applied on the logical standby even if all the archived log are sent to it.
    The below is the output from v$archive_gap and DBA_LOGSTDBY_LOG
    SQL> select * from v$archive_gap;
    no rows selected
    SQL> SELECT SEQUENCE#, FIRST_TIME, APPLIED
    FROM DBA_LOGSTDBY_LOG
    ORDER BY SEQUENCE#; 2 3
    SEQUENCE# FIRST_TIME APPLIED
    3937 24-FEB-10 01:48:23 CURRENT
    3938 24-FEB-10 10:31:22 NO
    3939 24-FEB-10 10:31:29 NO
    3940 24-FEB-10 10:31:31 NO
    3941 24-FEB-10 10:33:44 NO
    3942 24-FEB-10 11:54:17 NO
    3943 24-FEB-10 12:05:30 NO
    Any help?
    Thanks

    ORA-00600: internal error code, arguments: [krvxgirp], [], [], [], [], [], [], []
    LOGSTDBY Analyzer process P003 pid=48 OS id=8659 stopped
    Wed Feb 24 16:49:04 2010
    Errors in file /oracle/product/10.2.0/admin/umarket/bdump/oradb_lsp0_8651.trc:
    ORA-12801: error signaled in parallel query server P003
    ORA-00600: internal error code, arguments: [krvxgirp], [], [], [], [], [], [], []
    and below an Warning: Apply error received: ORA-26714: User error encountered while applying. Clearing. from oradb_lsp0_8651.trc
    Thanks

  • Logical standby real time apply problem

    Hi all,
    The real time apply for logical standby on my Oracle 10.2 DB is not working
    SELECT SEQUENCE#, FIRST_TIME, APPLIED
    FROM DBA_LOGSTDBY_LOG
    ORDER BY SEQUENCE#;
    SEQUENCE# FIRST_TI APPLIED
    2113 07/10/09 NO
    2115 07/10/09 NO
    2116 07/10/09 NO
    There is no error inside alert log.
    Any help
    Thanks

    Using Real-Time Apply to Apply Redo Data Immediately
    http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_apply.htm#i1022881
    1.What is compatible parameter, it should be 11.1
    2.Try to check parameters mentioned in below link:
    http://easyoradba.com/2011/01/10/real-time-apply-in-oracle-data-guard-10g/
    Regards
    Girish Sharma
    Edited by: Girish Sharma on Nov 15, 2012 12:37 PM

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

    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

    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.

  • Real time apply dataguard

    Hello
    I have some doubts about real time apply.
    If a transaction occurs in production, lgwr will automatically write this transaction to standby redologs in standby database.
    Is this transaction applied to standby database immediately or wait for standby redolog switch and applied as soon as standby log is archived ?

    Thanks Uwe.
    Eventhough you mentioned this before, I just want to ask last time to confirm:
    Regarding real time apply;
    When a transaction occurs in production, this transaction is not applied directly to standby database.
    It is first transferred to standby redolog( by the log writer of primary) and from there to standby database immediately. (I dont know which background proces is responsible for this)
    Is this right?By default, the archives are transferred(on completion) to standby database server using ARCH process and received by Remote File Server process (RFS) on standby database server. Optionally, you may choose to do the same using standby redo logs instead of archive log files (LGWR and LNS processes comes into picture). The standby redo logs are compulsory for real time apply regardless of protection mode.
    If you're using SRL, then redo data is transferred to SRL and once the SRL is archived the changes are written to the database using Managed Recovery Process (MRP) and hence minimizes the data loss in case of failover and minimizes the time in case of switchover and failover.
    If you're using Real Time Apply, then the standby redo log data is directly written to the database using LSP or MRP without waiting for SRL to be archived.
    Regards,
    S.K.
    Edited by: Santosh Kumar on Sep 22, 2009 3:53 PM

  • How to identify that my physical standby database in use real time apply?

    Hi,
    Can any one give me the SQL to identifiy that my physical standby database is in real time applying redo logs?
    Its urgen please....
    Thanks.

    You could just look at the alert log. Look for "Recovery of Online Redo Log"
    Or you could select from v$standby_apply_snapshot to see if the standby is up-to-date.
    select thread#, to_char(snapshot_time,'dd-mon-yyyy:hh24:mi'),
    to_char(applied_time,'dd-mon-yyyy:hh24:mi'),
    to_char(newest_time,'dd-mon-yyyy:hh24:mi') from V$STANDBY_APPLY_SNAPSHOT;

  • 10gR2 Logical Standby database not applying logs

    No errors are appearing in the logs and I've started the apply process :ALTER DATABASE START LOGICAL STANDBY APPLY but when I query dba_logstdby_log, none of the logs for the last 4 days shows as applied and the first SCN is still listed as current. Any thoughts on where I should start looking?
    the latest event in DBA_LOGSTDBY_EVENTS is the startup of the log mining and apply.
    I do not have standby redo logs so I cannot do real time apply, though I am looking to implementing this. Obviously, this is pretty new to me.

    Sorry I didn't mention this before, the logs are being transferred, I verified their location on the os and it matches the location in the dba_logstdby_log view.

  • Sql Apply issue in logical standby database--(10.2.0.5.0) x86 platform

    Hi Friends,
    I am getting the following exception in logical standby database at the time of Sql Apply.
    After run the command alter database start logical standby apply sql apply services start but after few second automatically stop and getting following exception.
    alter database start logical standby apply
    Tue May 17 06:42:00 2011
    No optional part
    Attempt to start background Logical Standby process
    LOGSTDBY Parameter: MAX_SERVERS = 20
    LOGSTDBY Parameter: MAX_SGA = 100
    LOGSTDBY Parameter: APPLY_SERVERS = 10
    LSP0 started with pid=30, OS id=4988
    Tue May 17 06:42:00 2011
    Completed: alter database start logical standby apply
    Tue May 17 06:42:00 2011
    LOGSTDBY status: ORA-16111: log mining and apply setting up
    Tue May 17 06:42:00 2011
    LOGMINER: Parameters summary for session# = 1
    LOGMINER: Number of processes = 4, Transaction Chunk Size = 201
    LOGMINER: Memory Size = 100M, Checkpoint interval = 500M
    Tue May 17 06:42:00 2011
    LOGMINER: krvxpsr summary for session# = 1
    LOGMINER: StartScn: 0 (0x0000.00000000)
    LOGMINER: EndScn: 0 (0x0000.00000000)
    LOGMINER: HighConsumedScn: 2660033 (0x0000.002896c1)
    LOGMINER: session_flag 0x1
    LOGMINER: session# = 1, preparer process P002 started with pid=35 OS id=4244
    LOGSTDBY Apply process P014 started with pid=47 OS id=5456
    LOGSTDBY Apply process P010 started with pid=43 OS id=6484
    LOGMINER: session# = 1, reader process P000 started with pid=33 OS id=4732
    Tue May 17 06:42:01 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1417, X:\TANVI\ARCHIVE2\ARC01417_0748170313.001
    Tue May 17 06:42:01 2011
    LOGMINER: Turning ON Log Auto Delete
    Tue May 17 06:42:01 2011
    LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01417_0748170313.001
    Tue May 17 06:42:01 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1418, X:\TANVI\ARCHIVE2\ARC01418_0748170313.001
    LOGSTDBY Apply process P008 started with pid=41 OS id=4740
    LOGSTDBY Apply process P013 started with pid=46 OS id=7864
    LOGSTDBY Apply process P006 started with pid=39 OS id=5500
    LOGMINER: session# = 1, builder process P001 started with pid=34 OS id=4796
    Tue May 17 06:42:02 2011
    LOGMINER: skipped redo. Thread 1, RBA 0x00058a.00000950.0010, nCV 6
    LOGMINER: op 4.1 (Control File)
    Tue May 17 06:42:02 2011
    LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01418_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1419, X:\TANVI\ARCHIVE2\ARC01419_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01419_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1420, X:\TANVI\ARCHIVE2\ARC01420_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01420_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1421, X:\TANVI\ARCHIVE2\ARC01421_0748170313.001
    LOGSTDBY Analyzer process P004 started with pid=37 OS id=5096
    Tue May 17 06:42:03 2011
    LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01421_0748170313.001
    LOGSTDBY Apply process P007 started with pid=40 OS id=2760
    Tue May 17 06:42:03 2011
    Errors in file x:\oracle\product\10.2.0\admin\tanvi\bdump\tanvi_p001_4796.trc:
    ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []
    LOGSTDBY Apply process P012 started with pid=45 OS id=7152
    Tue May 17 06:42:03 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1422, X:\TANVI\ARCHIVE2\ARC01422_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01422_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1423, X:\TANVI\ARCHIVE2\ARC01423_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01423_0748170313.001
    Tue May 17 06:42:03 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1424, X:\TANVI\ARCHIVE2\ARC01424_0748170313.001
    LOGMINER: session# = 1, preparer process P003 started with pid=36 OS id=5468
    Tue May 17 06:42:03 2011
    LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01424_0748170313.001
    Tue May 17 06:42:04 2011
    LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1425, X:\TANVI\ARCHIVE2\ARC01425_0748170313.001
    LOGSTDBY Apply process P011 started with pid=44 OS id=6816
    LOGSTDBY Apply process P005 started with pid=38 OS id=5792
    LOGSTDBY Apply process P009 started with pid=42 OS id=752
    Tue May 17 06:42:05 2011
    krvxerpt: Errors detected in process 34, role builder.
    Tue May 17 06:42:05 2011
    krvxmrs: Leaving by exception: 600
    Tue May 17 06:42:05 2011
    Errors in file x:\oracle\product\10.2.0\admin\tanvi\bdump\tanvi_p001_4796.trc:
    ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []
    LOGSTDBY status: ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []
    Tue May 17 06:42:06 2011
    Errors in file x:\oracle\product\10.2.0\admin\tanvi\bdump\tanvi_lsp0_4988.trc:
    ORA-12801: error signaled in parallel query server P001
    ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []
    Tue May 17 06:42:06 2011
    LogMiner process death detected
    Tue May 17 06:42:06 2011
    logminer process death detected, exiting logical standby
    LOGSTDBY Analyzer process P004 pid=37 OS id=5096 stopped
    LOGSTDBY Apply process P010 pid=43 OS id=6484 stopped
    LOGSTDBY Apply process P008 pid=41 OS id=4740 stopped
    LOGSTDBY Apply process P012 pid=45 OS id=7152 stopped
    LOGSTDBY Apply process P014 pid=47 OS id=5456 stopped
    LOGSTDBY Apply process P005 pid=38 OS id=5792 stopped
    LOGSTDBY Apply process P006 pid=39 OS id=5500 stopped
    LOGSTDBY Apply process P007 pid=40 OS id=2760 stopped
    LOGSTDBY Apply process P011 pid=44 OS id=6816 stopped
    Tue May 17 06:42:10 2011

    Errors in file x:\oracle\product\10.2.0\admin\tanvi\bdump\tanvi_p001_4796.trc:
    ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []submit an SR to ORACLE SUPPORT.
    refer these too
    *ORA-600/ORA-7445 Error Look-up Tool [ID 153788.1]*
    *Bug 6022014: ORA-600 [KRVXBPX20] ON LOGICAL STANDBY*

  • How Real Time Apply works while physical standby is open in Read Only mode

    Hi,
    With Active data guard option, we can open physical standby DB in read only mode, while redo log are being applied. (Real Time Query)
    Standby Redo log (SRL) enables Real Time Apply (with "USING CURRENT LOGFILE" clause in recover database command on standby DB)
    I am interested to know, how Real Time Query works ?
    What is the mechanism with allows us to open physical standby DB in read only mode while redo logs are being applied continuously ?
    Regards,
    Sujit

    Dear user7419391,
    That is a new feature in Oracle Database 11g. MRP can use the real time apply in 10g but the concept here is different.
    Taken from the following document;
    http://www.ascent.co.za/documents/oracle/Oracle%20databse%2011g%20Active-Data-Guard%20datasheet.pdf
    *Unique Advantages of Oracle Active Data Guard*
    +Active Data Guard is an evolution of Data Guard technology, providing unique+
    +performance advantages while leveraging all other enhancements included in Oracle+
    +Data Guard 11g. For example, any Data Guard 11g physical standby database can+
    +be easily converted to a Snapshot Standby. A Snapshot Standby is open read-write+
    +and is ideally suited as a test system, able to process transactions independent of the+
    +primary database. A Snapshot Standby maintains protection by continuing to receive+
    +data from the production database, archiving it for later use. When tests are+
    +complete, a single command discards changes made while open read-write and+
    +quickly resynchronizes the standby database with the primary.+
    The other link in the previous post is excellent and you really have to read it to understand the active data guard aspects.
    Regards.
    Ogan

  • Starting a Physical Standby DB which is configured with real-time apply

    Hi,
    I wanted to get clarification on the correct procedure for starting and stopping a physical standby database. The Dataguard documentation states the following:
    1. Start and mount the database:
    SQL> STARTUP MOUNT;
    2. Start log apply services:
    To start Redo Apply, issue the following statement:
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    2> DISCONNECT FROM SESSION;
    To start real-time apply, issue the following statement:
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    2> USING CURRENT LOGFILE;
    My configuration is using real-time apply based on the information provided by the RECOVERY_MODE column of the V$ARCHIVED_DEST_STATUS view. Should I execute both ALTER statements or just the second one. If only the second one, how will the database re-synchronize, especially after a long down time. Also, must I do anything on the primary database prior to starting up the physical standby?
    I'm using Oracle 10g SP1 on a linux server.

    No. But you can recover until the last arch file generated on the primary, then you cancel the recovery and then use query#2 to start applying real-time. Refer to Note:343424.1 on Metalink.

  • 11gr2 Dataguard Active Standby - Unable to get Real-Time apply working

    As above, I am unable to get real time apply to work WITHOUT it switching my standby back to MOUNT state. There does not seem to be anyting obvious from the broker, or alert logs.
    On the Standby:
    SQL> alter database recover managed standby database cancel;
    Database altered.
    SQL> alter database open read only;
    Database altered.
    SQL> select open_mode from v$database;
    OPEN_MODE
    READ ONLY
    SQL> alter database recover managed standby database using current logfile disconnect;
    Database altered.
    SQL> select open_mode from v$database;
    OPEN_MODE
    MOUNTED
    Primary:-
    SQL> SELECT status, recovery_mode FROM v$archive_dest_status where dest_name = 'LOG_ARCHIVE_DEST_2';
    STATUS RECOVERY_MODE
    VALID MANAGED REAL TIME APPLY
    Edited by: Imran on Apr 17, 2012 10:56 PM

    Hello;
    This is expected.
    Works the same exact way on my system. How Redo Data is applied is set when the database is MOUNTED.
    See - 6 Redo Apply Services
    Data Guard Concepts and Administration 11g Release 2 (11.2) E10700-0
    The document is vague on this at best, but think about the error you get if you try to start apply twice.
    Data Guard Real-Time Apply FAQ [ID 828274.1]
    Best Regards
    mseberg
    Edited by: mseberg on Apr 17, 2012 10:04 AM
    h1. Test
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    SQL> alter database recover managed standby database cancel;
    Database altered.
    SQL> alter database open read only;
    Database altered.
    SQL> alter database recover managed standby database using current logfile disconnect;
    Database altered.
    SQL> select open_mode from v$database;
    OPEN_MODE
    READ ONLY WITH APPLY
    SQL> So I get different results ??
    Edited by: mseberg on Apr 17, 2012 10:40 AM
    h2. Still more
    I would like to change my answer. Based on my test and queries as shown below I believe REAL TIME apply is working. Note the last log says NO because its in progress.
    Checking last sequence in v$archived_log
    STANDBY               SEQUENCE# APPLIED    COMPLETIO                                               
    STANDBY                     343 YES        16-APR-12                                               
    STANDBY                     344 YES        16-APR-12                                               
    STANDBY                     345 YES        16-APR-12                                               
    STANDBY                     346 YES        16-APR-12                                               
    STANDBY                     347 YES        17-APR-12                                               
    STANDBY                     348 NO         17-APR-12                                               
    6 rows selected.
    ----------------Last log on Primary--------------------------------------|
    MAX(SEQUENCE#)                                                                                     
               348                                                                                     
    1 row selected.Yes, I doubled check and it works on mine. I guess I read what I wanted to read.
    All my Standby redo are setup correctly ( size and numbers )
    READ ONLY WITH APPLYYour answer my be the Uwe answer at the end of this thread :
    Enabling the Active Dataguard and Real Time Apply
    Best Regards
    mseberg
    Edited by: mseberg on Apr 17, 2012 10:50 AM

  • Data guard real time apply vs archived log apply on physical standby

    Dear DBA's,
    last week i configuared DR , now the phyiscal stanby database is archive apply mode,
    i want to confirm is it better to apply the archived log or should i cahnge it to real time apply .
    give me sugesstions.
    Thanks and Regards
    Raja...

    One question are you using ARCH transport to move the redo? or have you configured standby redo logs and logwr transport (either async or syncronous), if you are using the archiver to transport the logs then you can not use real time apply.
    If you are using log writer to transpor the redo the realtime apply reduces the recovery time required if you need to failover as trher should be less redo to apply to bring the standby up to date, which mode you use to transport redo will depend on what is acceptable in terms of data loss and the impact on performance.

Maybe you are looking for