Stop/start logical standby db

Version 10203 on AIX
Have to stop/start logical standby db, new to data guard, Please confirm these are the steps to do that
on primary db
SQL > alter system switch logfile ;
SQL > alter system archive log current ; ( to make sure current transactions come thru)
check tail of alert log of standby to make sure these redologs shipped & mined
standby db
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; (stop SQL Apply)
SQL> shutdown immediate;
Lsnrctl stop listener_corp_remrpt-haprimary db
SQL > shutdown immediate ;
Lsnrctl stop listener_corp_remprd-ha
Dont shutdown abort for any case, if both dbs are going down, first stop SQL apply on standby, take primary down and then take standby down)
Startup
primary
SQL>startup;
Lsnrctl start listener_corp_remprd-ha
Standby
SQL > startup
SQL > alter database start logical standby apply immediate ;
Lsnrctl start listener_corp_remrpt-ha

Hi
As you posted ,you are using Real Time Sql apply,So,it is LGWR who transfer changes to standby site.It is very safe to follow these steps for new user.
1.Stop logical standby apply(Standby Database).
2.Shutdown Primary Database.
3.Shutdown logical standby Database.
At startup
1.Start Logical Standby Database.
2.Start Primary Database.
3.Start logical standby apply.
At the case when primary database is taking long time to shutdown processed ,You can also use
shutdown abort,but before doing abort be sure you have stop logical standby apply.When your primary database started,it automatically perform instance recovery.Primary site have to resolve gap in this case.
At the case when you must have to perform shutdown abort at primary database,you can do it.By doing it you will not loose anything.Primary database has to resolve gap and it will take time to be consistent with primary site.
Tinku

Similar Messages

  • Unable to start logical standby

    Hi All,
    I'm having some problems trying to start my logical standby. I managed to successfullly create a physical standby and ensured that it was collecting and applying archive logs. Running Oracle 10g on 11g Grid ASM
    I then converted it to a logical and i'm getting this problem : -
    SYS@Logical > ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
    ERROR at line 1:
    ORA-00254: error in archive control string ''
    ORA-06512: at "SYS.DBMS_INTERNAL_LOGSTDBY", line 615
    ORA-06512: at line 1
    The following is my parameters on the logical db
    log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=Primary
    log_archive_dest_3 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=Logical
    *log_archive_dest_2 points to another physical that is working ok.
    standby_archive_dest string LOCATION=USE_DB_RECOVERY_FILE_DEST
    db_recovery_file_dest string +FLASH_RECOVERY_AREA
    This is the only line relevant in my alert log
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
    ORA-254 signalled during: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE...
    These are the parameters on my primary db
    log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=Primary
    log_archive_dest_3 string SERVICE=logical LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=logical
    log_archive_dest_4 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=primary
    SYS@Primary > select SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI,FORCE_LOGGING from v$database;
    SUP SUP FOR
    YES YES YES
    Can anyone tell me what i'm doing wrong? I 've looked up google and metalink and it keeps coming down to me putting in a archive parameter wrong. I don't htink i'ts on the primary, or it would have errored with the creation of the physical database.
    Any help woudl be appreciated.
    Thanks.

    Hey Damorgan,
    I should have made it clear, sorry. That isn't the syntax I used to create the parameters, that is a screen grab of the parameter with me editing it to make it easier to read. So apologies for the confusion.
    To test the physical standby, I switched an archive log on the primary and then queried v$archived_log to make sure the logs were applied and compared the values between both the primary and physical. I did several log switches and it i could see it replicate on the physical.
    Do you have any other suggestions on how to check for a physical standby?

  • 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

  • Sequence of stopping starting Primary and standby DB

    Hi,
    what are the sequence of stopping starting Primary and standby DB ?
    To stop, which one ,primary or Standby, should be stopped first ?
    To Start which one first ?
    Thank you.

    Hi,
    what about the 10gR2 logical standbys? When I read the Note:278643.1 to apply the patch for logical database, it seemed that the sequence to stop and start the primary/logical standby was to stop the logical standby first before the stop of the primary one. Please advise me, for a simple situation just to stop and start the primary/logical standby to support a Unix server bounce, what is the sequence we should follow ? Do we have to run some commands to stop/start the SQL apply?
    Any idea or suggestion will be greatly appreciated.
    Thank you very much,
    yKe

  • Logical standby in noarchive mode

    Hello,
    does anybody know if it is possible to run a logical standby (10gR2) in noarchivelog mode?
    For my understanding it should be possible, why not... But I can't find a piece of documentation which prove this.
    Thanks in advance,
    Boris...

    I also was curious if setting up a Logical Standby in noarchivelog mode was possible. It looks like it is...
    We use this simply as a reporting copy of our data. Our analysts do not change any of this data. They just need it to be fairly current (~3 days). At this point, there isn't any need to generate archivelogs so we want to disable the feature to minimize our maintenance and our storage requirements.
    STANDBY DB:
    SQL> select log_mode, open_mode from v$database;
    LOG_MODE     OPEN_MODE
    ARCHIVELOG   READ WRITE
    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    Database altered.
    SQL> shutdown immediate;
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL> startup mount;
    ORACLE instance started.
    Database mounted.
    SQL>  alter database noarchivelog;
    Database altered.
    SQL> alter database open;
    Database altered.
    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    Database altered.Then I created an object on the production server:
    SQL> create table testuser.noarchivelog_testing as select * from dba_objects;
    Table created.
    SQL> alter system switch logfile;
    System altered.
    Mon Jun 22 11:13:26 2009
    Beginning log switch checkpoint up to RBA [0xe6.2.10], SCN: 1031235046
    Mon Jun 22 11:13:26 2009Now I see it on the standby:
    Mon Jun 22 11:13:43 2009
    RFS LogMiner: RFS id [25920] assigned as thread [1] PING handler
    RFS[1]: Archived Log: '/oracle/LH1/oraarch/LH1arch_1_229_680639127.arc'
    Mon Jun 22 11:13:46 2009
    RFS LogMiner: Registered logfile [/oracle/LH1/oraarch/LH1arch_1_229_680639127.arc] to LogMiner session id [1]
    Mon Jun 22 11:13:48 2009
    LOGSTDBY status: ORA-16204: DDL successfully applied
    Mon Jun 22 11:13:51 2009
    LOGMINER: End mining logfile: /oracle/LH1/oraarch/LH1arch_1_229_680639127.arc
    SQL> select count(*) from testuser.noarchivelog_testing;
      COUNT(*)
         24444

  • 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

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

    My environment is Primary database is 11.1.0.7 64bit on Windows 2003 Enterprise 64bit. Logical is on the same platform and oracle version but a different server. I created a physical standby first and it applied the logs quickly without any issues. I received no errors when I changed it over to a Logical standby database. The problem that is happening is as soon as I issue the command "alter database start logical standby apply;" the CPU usage goes to 100% and the SQL apply takes a long time to apply a log. When I was doing this on 10G I never ran into this, as soon as the log was received, it was applied within a couple of minutes. I don't think it could be a memory issue since there is plenty on the Logical standby server. I just can't figure out why the SQL apply is so slow and the CPU usage skyrockets. I went through all of the steps in the guide "Managing a Logical Standby Database" from Oracle and I don't see anything wrong. The only difference between the two databases is that on the Primary I have Large Page support enabled, I don't on the Logical. Any help would be greatly appreciated, I need to use this Logical to report off of.

    Thanks for the responses. I have found what is causing the problem. I kept noticing that the statements it was slowing down on were the ones where data was being written to the SYS.AUD$ table in the System tablespace on the Logical Standby database. A quick count of the records showed that I had almost 6 million records in that table. After I decided to truncate SYS.AUD$ on the Logical, the archive logs started to apply normally. I wonder why the Logical has a problem with this table and the Primary doesn't. I didn't even know auditing was turned on on the Primary database, it must be enabled by default. Now I know why my System table space has grown from 1gb to 2gb since November.
    Now that I fixed it for now, I am unsure what to do to keep this from happening. Can I turn off Auditing on the Logical and keep it on for the Primary? Would this stop data from being written to the SYS.AUD$ table on the Logical? It doesn't appear that there is any kind of cleanup on this table that is offered by Oracle, I guess I can just clean out this table occasionally but that is just another thing to add to the list of maintenance tasks. I notice that you can also write this audit data to a file on the OS. Has anyone here done that?

  • Logical Standby recover with RMAN

    Hi All,
    I have a test environment with Primary DB Server, Physical Standby and Logical Standby.
    The Logical Standby DB (cur_log_stdb) is backed up every evening by RMAN and I have a question:
    If I recover my Logical Standby DB from backup and switch replication to new Logical Standby DB (new_log_stdb) it will work or not?
    My steps e.g.:
    1. Make a new server for my new_log_stdb and repair structure of catalogs;
    2. Repair listener.ora and tnsnames.ora files from cur_log_stdb to new_log_stdb;
    3. Restore DB with RMAN from backup to new_log_stdb;
    4. On cur_log_stdb execute "alter database stop logical standby apply";
    5. Change a DNS name from cur_log_stdb to new_log_stdb;
    6. On new_log_stdb execute "alter database start logical standby apply immediate";
    I'm not sure that archivelogs will apply to the new_log_stdb for period since rman backup was created.
    But if this plan won't work how can I restore Logical Standby DB from RMAN backup and resume replication from Primary?
    Configuration:
    Oracle Linux 6.4
    Oracle Database 11.2.0.3
    Primary and Physical with Data Guard

    Hello;
    The only way to know for sure is to test it. You are asking somebody you don't know to confirm a recovery test for you. You have to perform the test yourself to be certain.
    If your plan does not work you can always rebuild the Standby.
    Best Regards
    mseberg

  • 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

  • Skip the DELETE command on logical standby

    Hi All,
    I want to skip the DELETE command on logical standby.
    DB Version - 10.2
    OS - Linux
    Primary DB and logical standby DB .
    In our DB schema some transaction tables. We delete data from those tables by delete commands.
    Delete command, also delete data from logical standby DB. But we want to skip on logical standby DB .
    I use following for that and get error.
    ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    EXECUTE DBMS_LOGSTDBY.SKIP (stmt =>'DELETE TABLE', schema_name =>'TEST',object_name =>'TRANS',proc_name => null);
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    But I got error
    ERROR at line 1:
    ORA-06550: line 1, column 7:
    PLS-00306: wrong number or types of arguments in call to 'SKIP'
    ORA-06550: line 1, column 7:
    PL/SQL: Statement ignored
    When I change stmt =>'DELETE TABLE' to stmt =>'DML', no error happen
    Please help me to solve this issue . This is urgent.
    Thanks in advance.
    Regards

    Dear aditi2,
    Actually it is so simple to understand the problem. Please read the following documentation and try to understand the SKIP procedure.
    http://download.oracle.com/docs/cd/B14117_01/appdev.101/b10802/d_lsbydb.htm#997290
    *SKIP Procedure*
    Use the SKIP procedure to define filters that prevent the application of SQL statements on the logical standby database.
    By default, all SQL statements executed on a primary database are applied to a logical standby database.
    If only a subset of activity on a primary database is of interest for application to the standby database,
    you can use the SKIP procedure to define filters that prevent the application of SQL statements on the logical standby database.
    While skipping (ignoring) SQL statements is the primary goal of filters,
    it is also possible to associate a stored procedure with a DDL filter so that runtime determinations can be made whether to skip the statement,
    execute this statement, or execute a replacement statement.
    Syntax
    DBMS_LOGSTDBY.SKIP (
         stmt                      IN VARCHAR2,
         schema_name               IN VARCHAR2,
         object_name               IN VARCHAR2,
         proc_name                 IN VARCHAR2,
         use_like                  IN BOOLEAN,
         esc                       IN CHAR1);Hope That Helps.
    Ogan
    Edited by: Ogan Ozdogan on 30.Tem.2010 13:03

  • Logical standby database keeps displaying ORA-16768

    I have a logical standby database setup on a remote host to accept cascaded logs from a physical standby. Everything was working fine until yesterday when I get the above error and log apply services stopped. When I go into Grid Control to Data Guard I see the error and it displays the failed SQL statement which is a create index statement. I have the option of clicking the SKIP button. When I click SKIP it appears to have processed it as the error goes away but then a few minutes later the error comes back, log apply stops and the failed SQL statement is the same create index statement. I guess the Skip doesn't mean Skip, it means Retry... My question is how do I get past this? Logs have been piling up.

    Hi,
    Ok I applied :
    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    Database altered.
    SQL> alter database start logical standby apply immediate;
    Database altered.
    SQL>
    And now I received this :
    ORA-16825: Fast-Start Failover and other errors or warnings detected for the database
    Cause: The broker has detected multiple errors or warnings for the database. At least one of the detected errors or warnings may prevent a Fast-Start Failover from occurring.
    Action: Check the StatusReport monitorable property of the database specified.
    What does it mean to check the status report.....
    I found this about monitorable status report !!
    DGMGRL> show database 'M3RPT' 'StatusReport';
    STATUS REPORT
    INSTANCE_NAME SEVERITY ERROR_TEXT
    * WARNING ORA-16821: logical standby database dictionary not yet loaded
    DGMGRL>
    What can I do ?
    Thanks a lot
    oldschool
    Edited by: oldschool on Jun 4, 2009 2:37 AM

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

  • Create table on Logical Standby Database

    Dear DBAs,
    here is my situation;
    1. My primary database (where the tables' owner is "ICC" having a DBA) is used for insert/update transactions.
    2. The logical stdby DB (dataguard structure with MAX availability) is used to generate reports, after updating some tables owned by the same user "ICC". note that these tables are excluded from the replication.
    3. The developers might need to create this kind of tables to generate another kind of reports.
    The issue is that when the standby apply is enabled or disabled, the user ICC is not able to create a new table, it gives ORA-01031: insufficient privileges. note that it's not practical to ask the DBA to disable the "APPLY" at any table creation.
    Do you have an idea about how to resolve.
    My database is 10gR2 path.10.2.0.4.0 on Windows 2003
    Thank you in advance

    If you stop applying log on the logical standby you can easily create a table over there. See oracle docs. The following list shows >how to re-create a table and restart SQL Apply on that table:
    >
    Stop SQL Apply:
    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    Ensure no operations are being skipped for the table in question by querying the DBA_LOGSTDBY_SKIP view:
    SQL> SELECT * FROM DBA_LOGSTDBY_SKIP;
    ERROR STATEMENT_OPT OWNER NAME PROC
    N SCHEMA_DDL HR EMPLOYEES
    N DML HR EMPLOYEES
    N SCHEMA_DDL OE TEST_ORDER
    N DML OE TEST_ORDER
    Because you already have skip rules associated with the table that you want to re-create on the logical standby >database, you must first delete those rules. You can accomplish that by calling the DBMS_LOGSTDBY.UNSKIP >procedure. For example:
    SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', -
    schema_name => 'HR', - object_name => 'EMPLOYEES');SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt >=> 'SCHEMA_DDL', -
    schema_name => 'HR', - object_name => 'EMPLOYEES');
    Re-create the table HR.EMPLOYEES with all its data in the logical standby database by using the >DBMS_LOGSTDBY.INSTANTIATE_TABLE procedure. For example:
    SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(shema_name => 'HR', -
    object-_name => 'EMPLOYEES', -
    dblink => 'BOSTON');
    Start SQL Apply:
    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;Regards.

  • Logical Standby - 9iR2

    Hi, i have a litle problem with Logical Standby database a few second the start apply the redo the view V$LOGSTDBY_STATS is empty.
    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    Database altered.
    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
    Database altered.
    SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
    NAME VALUE
    coordinator state APPLYING
    SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
    no rows selected

    Is the coordinator state process up and running for your Data Guard 9iR2 logical standby environment?
    Here is how to check:
    COLUMN LID FORMAT 9999
    COLUMN SERIAL# FORMAT 9999
    COLUMN SID FORMAT 9999
    SELECT SID, SERIAL#, LOGSTDBY_ID AS LID, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS;
    You should see processes similar to the following if things are setup correctly:
    SID SERIAL# LID SPID TYPE HIGH_SCN
    48 6 -1 11074 COORDINATOR 7178242899
    56 56 0 10858 READER 7178243497
    46 1 1 10860 BUILDER 7178242901
    45 1 2 10862 PREPARER 7178243295
    37 1 3 10864 ANALYZER 7178241034
    36 1 4 10866 APPLIER 7178239467
    35 3 5 10868 APPLIER 7178239463
    34 7 6 10870 APPLIER 7178239461
    33 1 7 10872 APPLIER 7178239472
    9 rows selected.
    I would review my setup and configuration steps for your Data Guard 9i Logical Standby environment.
    For more tips on monitoring see here:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ls.htm#CHDEFEFC
    And do review your setup and configuration. The steps are covered in the Oracle 9i Data Guard Concepts Guide. See here:
    http://download.oracle.com/docs/cd/B10501_01/server.920/a96653/toc.htm
    In particular, please review your setup per the guidelines in Chapter 4 of the guide.
    Regards,
    Ben Prusinski
    http://oracle-magician.blogspot.com/

Maybe you are looking for