Logical Standby Apply Process Performance

Hello,
We are testing our logical standby database for sql apply process.We run batch jobs in our active database and monitor the standby database for the time it takes to bring the database in sync following are the steps we follow:
1) Insure active and standby are in sync.
2) Stop sql apply on standby database.
3) Run Batch job on active database.
4) After completion of the job on active,start sql apply on standby.
Following are the details of the time taken by sql apply,based on the previous runs:
1st. 654K volume = 4 hrs (2727 records per min)
2nd. 810K volume = 8 hrs 45 mins (1543 records per min)
3rd. 744K volume = 7 hrs 17 mins (1704 records per min)
Following are the details of the logical stdby parameters :
MAX_SGA 100
MAX_SERVERS 15
PREPARE_SERVERS 4
APPLY_SERVERS 8
MAX_EVENTS_RECORDED 10000
RECORD_SKIP_ERRORS TRUE
RECORD_SKIP_DDL TRUE
RECORD_APPLIED_DDL FALSE
RECORD_UNSUPPORTED_OPERATIONS FALSE
EVENT_LOG_DEST DEST_EVENTS_TABLE
LOG_AUTO_DELETE TRUE
LOG_AUTO_DEL_RETENTION_TARGET 1440
PRESERVE_COMMIT_ORDER TRUE
ALLOW_TRANSFORMATION FALSE
can we ensure SQL apply process to apply data in consistent volume,Is it okay for a sql apply process to take same amount of time what the actual batch takes in active instance,can we further tweak apply process to get better performance.
Please help.
Thank you !!

Following are the details of the time taken by sql apply,based on the previous runs:
1st. 654K volume = 4 hrs (2727 records per min)
2nd. 810K volume = 8 hrs 45 mins (1543 records per min)
3rd. 744K volume = 7 hrs 17 mins (1704 records per min)
Following are the details of the logical stdby parameters :
Hi,
By looking at the above apply rate, the apply process is working normally and not having issues.
Since it's a bulk batch data update in PRIMARY, it's obvious and quite normal that it will take time in STANDBY database to get applied and in sync with PRIMARY.
Still, if you need to consider improving the performance, look out for adjusting the APPLIER & PREPARER process. (parameteres, APPLY_SERVERS & PREPAR_SERVERS).

Similar Messages

  • Logical Standby Apply Processes Die when granting a user sysdba on Primary

    I've run into an issue where the sql apply processes are stopping when granting a user sysdba privilege on the primary.
    The error is insufficient privileges.
    Of course the workaround that we have used is to skip the transaction on the logical and then manually grant the sysdba privilege on the standby. I'm hoping there is a more elegant solution as I have 8 DBAs on my team and each on of the transactions will need to be skipped individually, and is a bit of a pain. Just thought I would ask if anyone out there has run into the same issue and has a better workaround.

    I think you misunderstand. We run our standby in guard_mode 'STANDBY', which allows sys to perform the grant operation directly on the logical. Where it is failing is when we grant on the primary. That or I misunderstand. Are you saying that if I put in the script on the primary, the alter session command, then it will propagate down cleanly? That is something I have not tried of course, but makes sense how that could work, unless it throws an error on the primary because it is not a standby.

  • Logical standby apply won't apply logs

    RDBMS Version: Oracle 10.2.0.2
    Operating System and Version: Red Hat Enterprise Linux ES release 4
    Error Number (if applicable):
    Product (i.e. SQL*Loader, Import, etc.): Oracle Dataguard (Logical Standby)
    Product Version:
    Hi!!
    I have problem logical standby apply won't apply logs.
    SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
    TYPE HIGH_SCN
    STATUS
    COORDINATOR 288810
    ORA-16116: no work available
    READER 288810
    ORA-16240: Waiting for logfile (thread# 1, sequence# 68)
    BUILDER 288805
    ORA-16116: no work available
    TYPE HIGH_SCN
    STATUS
    PREPARER 288804
    ORA-16116: no work available
    ANALYZER 288805
    ORA-16116: no work available
    APPLIER 288805
    ORA-16116: no work available
    TYPE HIGH_SCN
    STATUS
    APPLIER
    ORA-16116: no work available
    APPLIER
    ORA-16116: no work available
    APPLIER
    ORA-16116: no work available
    TYPE HIGH_SCN
    STATUS
    APPLIER
    ORA-16116: no work available
    10 rows selected.
    SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN, DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
    SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
    66 11-JAN-07 11-JAN-07 YES YES
    67 11-JAN-07 11-JAN-07 NO NO
    SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
    NAME
    VALUE
    coordinator state
    IDLE
    SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
    APPLIED_SCN NEWEST_SCN
    288803 288809
    INITPRIMARY.ORA
    DB_NAME=primary
    DB_UNIQUE_NAME=primary
    REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
    service_names=primary
    instance_name=primary
    UNDO_RETENTION=3600
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standy)'
    LOG_ARCHIVE_DEST_1=
    'LOCATION=/home/oracle/primary/arch1/
    VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
    DB_UNIQUE_NAME=primary'
    LOG_ARCHIVE_DEST_2=
    'SERVICE=standy LGWR ASYNC
    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
    DB_UNIQUE_NAME=standy'
    LOG_ARCHIVE_DEST_3=
    'LOCATION=/home/oracle/primary/arch2/
    VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
    DB_UNIQUE_NAME=primary'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    LOG_ARCHIVE_DEST_STATE_3=ENABLE
    LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
    LOG_ARCHIVE_MAX_PROCESSES=30
    FAL_SERVER=standy
    FAL_CLIENT=primary
    DB_FILE_NAME_CONVERT='standy','primary'
    LOG_FILE_NAME_CONVERT=
    '/home/oracle/standy/oradata','home/oracle/primary/oradata'
    STANDBY_FILE_MANAGEMENT=AUTO
    INITSTANDY.ORA
    db_name='standy'
    DB_UNIQUE_NAME='standy'
    REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE'
    SERVICE_NAMES='standy'
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standy)'
    DB_FILE_NAME_CONVERT='/home/oracle/primary/oradata','/home/oracle/standy/oradata'
    LOG_FILE_NAME_CONVERT=
    '/home/oracle/primary/oradata','/home/oracle/standy/oradata'
    LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
    LOG_ARCHIVE_DEST_1=
    'LOCATION=/home/oracle/standy/arc/
    VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
    DB_UNIQUE_NAME=standy'
    LOG_ARCHIVE_DEST_2=
    'SERVICE=primary LGWR ASYNC
    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
    DB_UNIQUE_NAME=primary'
    LOG_ARCHIVE_DEST_3=
    'LOCATION=/home/oracle/standy/arch2/
    VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
    DB_UNIQUE_NAME=standy'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    LOG_ARCHIVE_DEST_STATE_3=ENABLE
    STANDBY_FILE_MANAGEMENT=AUTO
    FAL_SERVER=primary
    FAL_CLIENT=standy
    Alert Log Banco "Standy" desde a inicialização do SQL Apply
    Thu Jan 11 15:00:54 2007
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
    Thu Jan 11 15:01:00 2007
    alter database add supplemental log data (primary key, unique index) columns
    Thu Jan 11 15:01:00 2007
    SUPLOG: Updated supplemental logging attributes at scn = 289537
    SUPLOG: minimal = ON, primary key = ON
    SUPLOG: unique = ON, foreign key = OFF, all column = OFF
    Completed: alter database add supplemental log data (primary key, unique index) columns
    LOGSTDBY: Unable to register recovery logfiles, will resend
    Thu Jan 11 15:01:04 2007
    LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
    Thu Jan 11 15:01:04 2007
    LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
    Thu Jan 11 15:01:04 2007
    ALTER DATABASE START LOGICAL STANDBY APPLY (standy)
    with optional part
    IMMEDIATE
    Attempt to start background Logical Standby process
    LSP0 started with pid=21, OS id=12165
    Thu Jan 11 15:01:05 2007
    LOGSTDBY Parameter: DISABLE_APPLY_DELAY =
    LOGSTDBY Parameter: REAL_TIME =
    Completed: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
    Thu Jan 11 15:01:07 2007
    LOGSTDBY status: ORA-16111: log mining and apply setting up
    Thu Jan 11 15:01:07 2007
    LOGMINER: Parameters summary for session# = 1
    LOGMINER: Number of processes = 3, Transaction Chunk Size = 201
    LOGMINER: Memory Size = 30M, Checkpoint interval = 150M
    LOGMINER: session# = 1, reader process P000 started with pid=22 OS id=12167
    LOGMINER: session# = 1, builder process P001 started with pid=23 OS id=12169
    LOGMINER: session# = 1, preparer process P002 started with pid=24 OS id=12171
    Thu Jan 11 15:01:17 2007
    LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
    Thu Jan 11 15:01:17 2007
    LOGMINER: Turning ON Log Auto Delete
    Thu Jan 11 15:01:26 2007
    LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
    Thu Jan 11 15:01:26 2007
    LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
    Thu Jan 11 15:01:26 2007
    LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_ATTRCOL$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_CCOL$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_CDEF$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_COL$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_COLTYPE$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_ICOL$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_IND$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDCOMPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDSUBPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_LOB$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_LOBFRAG$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_OBJ$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TAB$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABCOMPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABSUBPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TS$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TYPE$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_USER$ have been marked unusable
    Thu Jan 11 15:02:05 2007
    Indexes of table SYSTEM.LOGMNR_ATTRCOL$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_ATTRIBUTE$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_CCOL$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_CDEF$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_COL$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_COLTYPE$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_DICTIONARY$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_ICOL$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_IND$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_INDCOMPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_INDPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_INDSUBPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_LOB$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_LOBFRAG$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_OBJ$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TAB$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TABCOMPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TABPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TABSUBPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TS$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TYPE$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_USER$ have been rebuilt and are now usable
    LSP2 started with pid=25, OS id=12180
    LOGSTDBY Analyzer process P003 started with pid=26 OS id=12182
    LOGSTDBY Apply process P008 started with pid=20 OS id=12192
    LOGSTDBY Apply process P007 started with pid=30 OS id=12190
    LOGSTDBY Apply process P005 started with pid=28 OS id=12186
    LOGSTDBY Apply process P006 started with pid=29 OS id=12188
    LOGSTDBY Apply process P004 started with pid=27 OS id=12184
    Thu Jan 11 15:02:48 2007
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[1]: Assigned to RFS process 12194
    RFS[1]: Identified database type as 'logical standby'
    Thu Jan 11 15:02:48 2007
    RFS LogMiner: Client enabled and ready for notification
    Thu Jan 11 15:02:49 2007
    RFS LogMiner: RFS id [12194] assigned as thread [1] PING handler
    Thu Jan 11 15:02:49 2007
    LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
    Thu Jan 11 15:02:49 2007
    LOGMINER: Turning ON Log Auto Delete
    Thu Jan 11 15:02:51 2007
    LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
    Thu Jan 11 15:02:51 2007
    LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
    Thu Jan 11 15:02:51 2007
    LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
    Please, help me more time!!!!
    Thanks.

    Hello!
    thank you for the reply.
    The archive 1_68_608031954.arc that error of reading occurred, did not exist in the date of the error sees below:
    $ ls -lh /home/oracle/standy/arch2/
    total 108M
    -rw-r----- 1 oracle oinstall 278K Jan 11 15:00 1_59_608031954.arc
    -rw-r----- 1 oracle oinstall 76K Jan 11 15:00 1_60_608031954.arc
    -rw-r----- 1 oracle oinstall 110K Jan 11 15:00 1_61_608031954.arc
    -rw-r----- 1 oracle oinstall 1.0K Jan 11 15:00 1_62_608031954.arc
    -rw-r----- 1 oracle oinstall 2.0K Jan 11 15:00 1_63_608031954.arc
    -rw-r----- 1 oracle oinstall 96K Jan 11 15:00 1_64_608031954.arc
    -rw-r----- 1 oracle oinstall 42K Jan 11 15:00 1_65_608031954.arc
    -rw-r----- 1 oracle oinstall 96M Jan 13 06:10 1_68_608031954.arc
    -rw-r----- 1 oracle oinstall 12M Jan 13 13:29 1_69_608031954.arc
    $ ls -lh /home/oracle/primary/arch1/
    total 112M
    -rw-r----- 1 oracle oinstall 278K Jan 11 14:21 1_59_608031954.arc
    -rw-r----- 1 oracle oinstall 76K Jan 11 14:33 1_60_608031954.arc
    -rw-r----- 1 oracle oinstall 110K Jan 11 14:46 1_61_608031954.arc
    -rw-r----- 1 oracle oinstall 1.0K Jan 11 14:46 1_62_608031954.arc
    -rw-r----- 1 oracle oinstall 2.0K Jan 11 14:46 1_63_608031954.arc
    -rw-r----- 1 oracle oinstall 96K Jan 11 14:55 1_64_608031954.arc
    -rw-r----- 1 oracle oinstall 42K Jan 11 14:55 1_65_608031954.arc
    -rw-r----- 1 oracle oinstall 4.2M Jan 11 14:56 1_66_608031954.arc
    -rw-r----- 1 oracle oinstall 5.5K Jan 11 14:56 1_67_608031954.arc
    -rw-r----- 1 oracle oinstall 96M Jan 13 06:09 1_68_608031954.arc
    -rw-r----- 1 oracle oinstall 12M Jan 13 13:28 1_69_608031954.arc
    Alert log
    hu Jan 11 15:01:00 2007
    SUPLOG: Updated supplemental logging attributes at scn = 289537
    SUPLOG: minimal = ON, primary key = ON
    SUPLOG: unique = ON, foreign key = OFF, all column = OFF
    Completed: alter database add supplemental log data (primary key, unique index) columns
    LOGSTDBY: Unable to register recovery logfiles, will resend
    Thu Jan 11 15:01:04 2007
    LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
    Thu Jan 11 15:01:04 2007
    LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
    You it would know as to help me?
    Would be a BUG of the Oracle 10g?
    Thanks.

  • ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL

    I am using oracle 9.2.0.8 db version. I am trying to configure logical standby database. When I issue "ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL" i get following error.
    ERROR at line 1:
    ORA-01427: single-row subquery returns more than one row
    ORA-06512: at line 1

    Hello,
    Please, have a look on the Alert log fille, and post the error message if any.
    May be you'll have more information about the offending subquery.
    Best regards,
    Jean-Valentin

  • Increase Apply Process Performance

    Dear All,
    I want to know how can I increase Apply Process Performance in Oracle Streams Setup.
    I use Windows 2003 and Oracle 10g R2

    Check metalink Note:335516.1
    HTH...

  • Logical Standby Apply became TOO SLOW !!

    Hi,
    I recently have setup a logical standby database. Everything was fine until the apply procedure on the standby became too slow:
    SQL> alter session set nls_date_format = 'HH24:MI:SS (MM/DD)';
    Session altered.
    SQL> SELECT APPLIED_SCN, APPLIED_TIME, READ_SCN, READ_TIME, NEWEST_SCN, NEWEST_TIME FROM DBA_LOGSTDBY_PROGRESS;
    APPLIED_SCN APPLIED_TIME READ_SCN READ_TIME NEWEST_SCN
    NEWEST_TIME
    3036960310 18:33:28 (05/31) 3035938077 18:12:43 (05/31) 3060387972
    16:30:16 (06/02)
    SQL>
    The applied time changed about 20 minutes during last 46 hours. v$logstdby says:
    COORDINATOR: ORA-16116: no work available
    READER, BUILDER and PREPARER: ORA-16127: stalled waiting for additional transactions to be applied
    All APPLIERs: ORA-16116: no work available
    I really don't have any idea about this issue. Any help will be appreciated.
    regards

    One reason could be the SQL Apply engine performs too many slow full table scans, check metalink note:
    Determining if SQL Apply Engine is Performing Full Table Scans
    Doc ID: Note:255958.1
    If this is the reason for the slowness you have to tune your DML statements.
    Werner

  • ORA-01403 - Logical Standby Apply ends on delete/update statement

    - This thread is relocated to this forum; advice from Daniel Roy -
    After implementing 2 logical standby databases and running pretty smooth for a while 'strange' errors occur which puzzle me. Sometimes I skip a transaction or exclude a schema from replication and hold my breath for what next roars its ugly head.
    Despite fulfilling all logical standby prerequisites and maintaining primary keys on tables I now run into ORA-01403 errors. The updated table only contains 1 row and has a foreign key to another small table.
    I could instantiate these tables, but I want to understand why these errors occur and prevent them form happing or learn how to resolve them best.
    Anyone around who dealt with these matters and won?
    I'm running this implementation with Oracle 9.2.0.7 on Tru64 51.b
    I'm able to create the logical standby databases manually and with aid of the Data Guard Creation Wizard (EM10g 10.1).
    Can anyone also help me out with refining the faulty transaction from e.g. V$LOGMNR_CONTENTS? (Without disrupting the data guard setup).
    I've already retrieved redo info from archivelogs, but there must be an easy way.
    Regards,
    Erik

    Any way for you to turn tracing on for the DB where you see this ORA-01403 error? We could then probably find out exactly what goes wrong. It's very hard for us to know exactly what might be wrong, since we don't know your exact setup (except for this table). Let me know if that's not possible, and I could construct a logical DB setup to test (even tho it would be on Windows, I don't have Tru64).
    Daniel

  • Logical standby stuck at initializing SQL apply only coordinator process up

    Hi
    OS: solaris 5.10
    Hardware: sun sparc
    Oracle database: 11.2.0.1.0
    Primary database name: asadmin
    Standby database name: test
    I had been trying to convert a physical standby to logical standby database. Both the primary and standby reside on the same machine.
    The physical standby was created with a hot backup of primary.
    I had been following document id 278371.1 to convert the physical to logical standby and used the following steps:
    Relevant init parameters on primary:
    *.db_name='asadmin'
    *.db_unique_name='asadmin'
    *.log_archive_config='dg_config=(asadmin,test)'
    *.log_archive_dest_1='location=/u01/asadmin/archive valid_for=(all_logfiles,all_roles) db_unique_name=asadmin'
    *.log_archive_dest_2='SERVICE=test async valid_for=(online_logfiles,primary_role) db_unique_name=test'
    *.log_archive_dest_state_1='enable'
    *.log_archive_dest_state_2='enable'
    *.fal_client='asadmin'
    *.fal_server='test'
    *.remote_login_passwordfile='EXCLUSIVE'
    Relevant init parameters on standby database:
    *.db_name='test' -- Was asadmin before I renamed the DB during conversion to logical standby
    *.db_unique_name='test'
    *.log_archive_dest_1='location=/u01/test/archive valid_for=(all_logfiles,all_roles) db_unique_name=test'
    *.log_archive_dest_2='service=asadmin async valid_for=(online_logfiles,primary_role) db_unique_name=asadmin'
    *.log_archive_dest_state_1=enable
    *.log_archive_dest_state_2=defer
    *.remote_login_passwordfile='EXCLUSIVE'*.fal_server=test
    *.fal_client=asadmin
    Steps on primary:
    1) alter system set log_archive_dest_state_2=defer;
    2) shutdown immediate;
    3) Made sure that the physical standby has applied all of the redo sent to it following the shutdown.
    4) startup mount;
    5) ALTER DATABASE BACKUP CONTROLFILE to '/home/oracle/control01.ctl';
    6) ALTER SYSTEM ENABLE RESTRICTED SESSION;
    7) ALTER DATABASE OPEN;
    8) Verified that the supplemental logging is on.
    9) ALTER SYSTEM ARCHIVE LOG CURRENT;
    10) Checked for the checkpoint change no. at this point which is 72403818 and is present in archive log file 1_62_775102253.dbf
    11) EXECUTE DBMS_LOGSTDBY.BUILD;
    12) ALTER SYSTEM ARCHIVE LOG CURRENT;
    13) Checked for the archive log containing dictionary build which is 1_64_775102253.dbf
    14) ALTER SYSTEM DISABLE RESTRICTED SESSION;
    Details of archive logs and related checkpoint change nos:
    NAME FIRST_CHANGE# NEXT_CHANGE#
    /u01/asadmin/archive/1_61_775102253.dbf 72402901 72403817
    /u01/asadmin/archive/1_62_775102253.dbf 72403817 72404069
    /u01/asadmin/archive/1_63_775102253.dbf 72404069 72404211
    /u01/asadmin/archive/1_64_775102253.dbf 72404211 72405700
    Steps on standby:
    1) shutdown immediate;
    2) Copy the archivelog file 61(was created at primary after apply stopped at standby), 62(contains checkpoint no. 72403818), 63 and 64(contains dictionary build). Copy the backup controlfile from step 5 above to the controlfile location in standby init.
    3) startup mount;
    4) Rename all datafiles and redo log files (including standby redo log files) to the correct path on standby.
    5) alter database recover automatic from '/u01/test/archive' until change 72405700 using backup controlfile; -- This completed error-free
    6) alter database guard all; -- this completed error free
    7) alter database open resetlogs; -- this completed error free.
    8) nid target=sys/oracle12 dbname=test
    9) Changed the db_name in init file to new name test.
    10) Added a tempfile to temp tablespaces.
    11) ALTER DATABASE REGISTER LOGICAL LOGFILE '/u01/test/archive/1_61_775102253.dbf'; -- ORA-16225: Missing LogMiner session name for Streams
    12) ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL 72405700; -- This completed error free.
    Also enabled the log_archive_dest_state_2 on primary.
    After this output from some views:
    SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
    SESSION_ID STATE
    1 INITIALIZING
    SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;
    SID SERIAL# SPID TYPE
    587 22 15476 COORDINATOR
    SELECT PERCENT_DONE, COMMAND
    FROM V$LOGMNR_DICTIONARY_LOAD
    WHERE SESSION_ID = (SELECT SESSION_ID FROM V$LOGSTDBY_STATE);
    PERCENT_DONE
    COMMAND
    0
    SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
    TYPE HIGH_SCN STATUS
    COORDINATOR ORA-16111: log mining and apply setting up
    SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
    APPLIED_SCN NEWEST_SCN
    72405700 72411501
    SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L
    WHERE NEXT_CHANGE# NOT IN
    (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)
    ORDER BY THREAD#,SEQUENCE#;
    no rows selected
    SQL> SELECT EVENT_TIME, STATUS, EVENT
    FROM DBA_LOGSTDBY_EVENTS
    ORDER BY EVENT_TIMESTAMP, COMMIT_SCN; 2 3
    EVENT_TIME STATUS EVENT
    14-FEB-12 02:00:50 ORA-16111: log mining and apply setting up
    14-FEB-12 02:00:50 Apply LWM 72405699, HWM 72405699, SCN 72405699
    14-FEB-12 02:20:11 ORA-16128: User initiated stop apply successfully
    completed
    14-FEB-12 02:20:39 ORA-16111: log mining and apply setting up
    14-FEB-12 02:20:39 Apply LWM 72405699, HWM 72405699, SCN 72405699
    14-FEB-12 02:54:15 ORA-16128: User initiated stop apply successfully
    completed
    14-FEB-12 02:57:38 ORA-16111: log mining and apply setting up
    EVENT_TIME STATUS EVENT
    14-FEB-12 02:57:38 Apply LWM 72405699, HWM 72405699, SCN 72405699
    14-FEB-12 03:01:36 ORA-16128: User initiated stop apply successfully
    completed
    14-FEB-12 03:13:44 ORA-16111: log mining and apply setting up
    14-FEB-12 03:13:44 Apply LWM 72405699, HWM 72405699, SCN 72405699
    14-FEB-12 04:32:23 ORA-16128: User initiated stop apply successfully
    completed
    14-FEB-12 04:34:17 ORA-16111: log mining and apply setting up
    14-FEB-12 04:34:17 Apply LWM 72405699, HWM 72405699, SCN 72405699
    EVENT_TIME STATUS EVENT
    14-FEB-12 04:36:16 ORA-16128: User initiated stop apply successfully
    completed
    14-FEB-12 04:36:21 ORA-16111: log mining and apply setting up
    14-FEB-12 04:36:21 Apply LWM 72405699, HWM 72405699, SCN 72405699
    14-FEB-12 05:15:22 ORA-16128: User initiated stop apply successfully
    completed
    14-FEB-12 05:15:29 ORA-16111: log mining and apply setting up
    14-FEB-12 05:15:29 Apply LWM 72405699, HWM 72405699, SCN 72405699
    I also greped for lsp and lcr processes and found that lsp is up but do not see any lcr.
    The logs are getting transported to the archive destination on standby whenever they are archived on primary but are not getting applied to standby.
    Also in case the standby is down while a log is generated on primary it is not automatically transported to standby once the standby is up, means gap resolution is also not working.
    I see the following in alert log every time I try to restart the log apply, everything seems to be stuck at initialization.
    ALTER DATABASE START LOGICAL STANDBY APPLY (test)
    with optional part
    IMMEDIATE
    Attempt to start background Logical Standby process
    Tue Feb 14 05:15:28 2012
    LSP0 started with pid=28, OS id=23391
    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 0, ResetLogScn 0
    -- NOTHING AFTER THIS

    Hello;
    I noticed some of your parameters seem to be wrong.
    fal_client - This is Obsolete in 11.2
    You have db_name='test' on the Standby, it should be 'asadmin'
    fal_server=test is set like this on the standby, it should be 'asadmin'
    I might consider changing VALID_FOR to this :
    VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)Would review 4.2 Step-by-Step Instructions for Creating a Logical Standby Database of Oracle Document E10700-02
    Document 278371.1 is showing its age in my humble opinion.
    -----Wait on this until you fix your parameters----------------------
    Try restarting the SQL Apply
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATEI don't see the parameter MAX_SERVERS, try setting it to 8 times the number of cores.
    Use these statements to trouble shoot :
    SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
    SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE ;TRANSACTIONS%';
    SELECT COUNT(1) AS IDLE_PREPARERS FROM V$LOGSTDBY_PROCESS WHERE
    TYPE = 'PREPERER' AND STATUS_CODE = 16166;Best Regards
    mseberg
    Edited by: mseberg on Feb 14, 2012 7:37 AM

  • Slow apply on logical standby

    Hi ,
    oracle 10.2.0.3 enterprise edition logical standby
    We performed heavy updates on our production database due to which logical standby gone lots of logs behind with primary database and log are getting apply on logical standby very slowly.
    Kindly suggest how to speed up apply process on logical standby ....

    Santosh Pradhan wrote:
    Hi ,
    oracle 10.2.0.3 enterprise edition logical standby
    We performed heavy updates on our production database due to which logical standby gone lots of logs behind with primary database and log are getting apply on logical standby very slowly.
    Kindly suggest how to speed up apply process on logical standby ....Hope you are using "ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;" command
    Here please check the below note for Adjusting the Number of APPLIER Processes , also if redo transport is slow check the settings for "LOG_ARCHIVE_MAX_PROCESSES"
    http://docs.oracle.com/cd/B28359_01/server.111/b28294/manage_ls.htm#CHDBGBFC

  • 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*

  • Logical standby: SQL Apply too slow

    Hi all,
    I have a question regarding SQL Apply performance in logical standby. There are two kind of operations that are remarkably slow when applying them on logical standby. These are "truncate table" and "delete from table" operations.
    When logical standby pick up one of mentioned statements from logs one of appliers start working whereas rest others are waiting. It looks like standby hang and very slow sql apply is moving on gradually and finally when operation completes standby is behind primary for 4 or 5 or even 8 hours.
    What can be done in this regard to speed up sql apply and alleviate this situation?
    Best Regards,
    Alex

    Are you absolutely sure that the truncate is the problem (and deletes). How did you check it?
    You can use LogMiner to check what are most of the commands in the log currently applied. I use this:
    BEGIN
    sys.DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => '/home/oracle/arc_43547_1_595785865.arc', OPTIONS => sys.DBMS_LOGMNR.ADDFILE);
    END;
    BEGIN
    sys.DBMS_LOGMNR.START_LOGMNR( OPTIONS => sys.DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
    END;
    SELECT seg_owner,seg_name,table_name,operation,COUNT(1) FROM V$LOGMNR_CONTENTS
    GROUP BY seg_owner,seg_name,table_name,operation
    ORDER BY COUNT(1) DESC
    BEGIN
    sys.DBMS_LOGMNR.END_LOGMNR();
    END;
    Most of the times in our cases when SQL Apply is slow is because of high activity on particular object. This can be detected by high number of DMLs for that object using LogMiner. If this object is not needed on the logical standby you can skip it and thus SQL Apply will be faster because it will not apply changes for this particular one. If it's needed and this is not a regular rate, then you can skip it temporarily, turn on SQL Apply , after problematic logs are applied, turn off SQL Apply, instantiate the object and unskip it, turn on sql apply again.
    Another thing that can drastically slowdown SQL Apply is the size of memory available for SQL Apply(Alert log shows that max is ~4.5GB or something like this, I'm not sure )
    You can increase it with something like this:
    ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    BEGIN
    DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 3000); -- set to 3000 MB
    END;
    ALTER DATABASE START LOGICAL STANDBY APPLY;
    You have to increase it if the following reports:
    SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
    WHERE NAME LIKE '%page%' OR
    NAME LIKE '%uptime%' or name like '%idle%';
    that 'bytes paged out' increases if run every few seconds during slow SQL Apply.
    I hope that it's something that can be fixed using the above info. If no, please comment and share your investigations.
    Thanks

  • 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 ?

  • Create function as "/ as sysdba" not shipped/applied to logical standby

    As the subject states, I was creating a password verify function and profile that used the function as sys "/ as sysdba" .
    The function was not created on the logical standby and thus the profile create statement failed. The function was not even listed in the standby's alertlog, although the create profile statement was.
    I created the function manually on the standby by connecting / as sysdba and creating the function and then restarted logical standby apply. The standby then created the profile and continued without error.
    Is this a bug?
    Should the SYS 'create function' be shipped and applied or not?
    When the function create statement was run on the primary as a non-sys user with DBA privs, it created ok and was shipped and appeared on logical standby ok.
    Any ideas DataGuard Gurus?
    (9.2.0.7 on Solaris 8)

    I logged a Tar. Oracle says:
    "Ideally any object created on sys schema should get skipped automatically. sys is consider as internal schema and objects created in sys schema should get
    skipped"
    "But because of the internal Bug.3576307 "LOGICAL STANDBY IS NOT SKIPPING DDL IT SHOULD." it is not skipping the DDL executed on sys schema. This bug
    is fixed in 10.2.
    You can issue following statement to enable the DDL skip on sys schema.
    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    SQL> EXECUTE DBMS_LOGSTDBY.SKIP_ERROR(‘SCHEMA_DDL’, ‘SYS’, null, null)
    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
    After which all DDL errors encountered on any object in the SYS schema would be ignored and processing continued. This can render the TEST schema objects unusable and, if necessary, you can later recreate the tables
    using the INSTANTIATE_TABLE procedure."
    Makes sense now.

  • 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.

  • Logical Standby SQL Apply Using Incorrect Decode Statement

    We are seeing statements erroring out on our logical standby that have been rewritten (presumably by sql apply) with decode statements that don't appear to be correct. For example, here is one of the rewritten statements.
    update /*+ streams restrict_all_ref_cons */ "CADPROD"."OMS_SQL_STATEMENT" p
    set *"APPLICATION"=decode(:1,'N',"APPLICATION",:2)*,
    "STATEMENT"=dbms_reputil2.get_final_lob(:3,"STATEMENT",:4)
    where (:5='N' or(1=1 and (:6='N' or(dbms_lob.compare(:7,"STATEMENT")=0)or(:7 is null and "STATEMENT" is null)))) and(:8="APPLICATION")
    The problem comes in, we believe, with the attempt to write the value "APPLICATION" to the application column which is only a 10 character field. the value for the :1 bind variable is "N" and the value for :2 is null.
    We see the following error on the logical standby:
    ORA-00600: internal error code, arguments: [kgh_heap_sizes:ds], [0x01FCDBE60], [], [], [], [], [], []
    ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [kxtoedu+54] [PC:0x2542308] [ADDR:0xFFFFFFFFFFFFFFFF] [UNABLE_TO_READ] []
    ORA-12899: value too large for column "CADPROD"."OMS_SQL_STATEMENT"."APPLICATION" (actual: 19576, maximum: 10)
    Is this a configuration issue or is it normal for SQL Apply to convert statements from logminer into decode statements?
    We have an Oracle 10.2.0.4 database running on windows 2003 R2 64-bit os. We have 3 physical and 2 logical standby's, no problems on the physical standbys.

    Hello;
    I noticed some of your parameters seem to be wrong.
    fal_client - This is Obsolete in 11.2
    You have db_name='test' on the Standby, it should be 'asadmin'
    fal_server=test is set like this on the standby, it should be 'asadmin'
    I might consider changing VALID_FOR to this :
    VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)Would review 4.2 Step-by-Step Instructions for Creating a Logical Standby Database of Oracle Document E10700-02
    Document 278371.1 is showing its age in my humble opinion.
    -----Wait on this until you fix your parameters----------------------
    Try restarting the SQL Apply
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATEI don't see the parameter MAX_SERVERS, try setting it to 8 times the number of cores.
    Use these statements to trouble shoot :
    SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
    SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE ;TRANSACTIONS%';
    SELECT COUNT(1) AS IDLE_PREPARERS FROM V$LOGSTDBY_PROCESS WHERE
    TYPE = 'PREPERER' AND STATUS_CODE = 16166;Best Regards
    mseberg
    Edited by: mseberg on Feb 14, 2012 7:37 AM

Maybe you are looking for

  • Payment Program Document not automatically Cleared

    Hi, We created payments through F110 payment program and the vendor invoices were paid on 14th October. We then ran the program again on 31st October and the same invoices were paid again. We use the payment list to manually pay the telegraph transfe

  • How to SEND HTML formatted mail??

    How do I put HTML formatted text into an email I want to SEND? -- "Paste as HTML" in edit menu is dimmed, and I can't get it to un-dim... I want to paste formatted text from an HTML editor into an email... can I do this with Mail, or do I need some o

  • Regarding the file name checking

    Hi ,      I m using the below program which will upload the XL sheet , here i want to validate the file name which i m selecting from the destop. the file name should be named as "Suresh.XLS", where and how i can do validation for checking the file n

  • IDOC to AS2

    Hi, My senario is IDOC to AS2 ( Fixed lenghth Flat file) I am doing the Scenarios as IDOCto Flat file Then Flat file(.txt) to As2 as MainDocument. Weather AS2 accepts the Flatfile(.txt) file. How to proceed the Scenario.... Thanks

  • Including inline javascript code OR link to JS file

    We have some use cases, for which we want to allow authors/publishers to specify inline javascript OR link to a JS file on a CQ page. We enabled source editing mode for Rich Text Editor (using misctools plugin). Now I can enter HTML including <SCRIPT