SQL Apply Rolling Upgrade

Hi,
I would like to upgrade our Oracle database from release 9i to oracle 10g.
Anybody have used "SQL Apply Rolling Upgrade" with a SAP application to upgrade the database ?
Thank's in advanced
Francesc

Hi Cristian,
well you can do / try that, but it is not supported in a SAP environment.
SQL Apply means Logical Standby database and this is explicitly not supported in a SAP environment - for more details please check SAPnote #105047 (sub point 14 - Oracle Data Guard).
However from a technical point of view it is possible as none of these restrictions usually apply a SAP environment ( Data Type and DDL Support on a Logical Standby Database ).
Regards
Stefan

Similar Messages

  • Rolling upgrade in MAA database with 2 node RAC on each site

    All,
    I have 2 node rac on SITE A, and it has Physical Standby database on SITE B it also 2 node RAC. Currently it is on 10.2.0.4 on AIX systems. We have mission crictical application runing and we can't aford the downtime of 5 to 6 hr to upgrade our CRS,ASM,DB oracle homes to 11G or even 10.2.0.5. I read rolling upgrade document on metalink and also documnet as well, and come up with following sequence.
    SITE A==Primary Site, SITE B == Standby database
    1) Shutdown DB on SITE B
    2) Take the OS Level Backup of Binaries only on SITE B (Both node), I think this is just a Precautionary Measure
    3) Start the DB on SITE B Still Physical Standby database let it synch with primary Site SITE A
    4) Convert SITE B to Logical standby database
    5) let it run for some time and be the two site SYNCH
    6) now stop archivelog shipping to STANDBY SITE SITE B
    7) Shutdown SITE B and apply the patch/upgrade binaries (CRS/ASM/DB)
    8) Start and upgrade the DB on SITE B
    9) Start the logical standby apply (SQL APPLY) and let it catch up with SITE A
    10) Now Switchover to logical standby database on SITE B and ask application to connect to SITE B
    11) Make sure the archivelogs are moving from SITE B to SITE A and SQL Apply is runing.
    12) Now Stop archive log flow from SITE B to SITE A
    13) Stop the database/ASM/CRS on SITE A
    14) upgrade the SITE A binaries (CRS/ASM/DB)
    15) Start and upgrade the DB on SITE A
    16) Start the logical standby apply (SQL APPLY) and let it catch up with SITE B
    17) Now Switchover Back to SITE A and let the application connect to SITE A
    At this point by SITE B is a Logical Standby database
    I think these summaries the steps involved in rolling upgrade, but I can't understand how I can go back to my MAA with physical standby database mode?
    Does anyone has done this? Can anyone give me some tips or comments on my steps??
    Help me if you can... thanks in advance.

    Hi,
    Is it you want to know the OS/Kernel side setting? You must comply with the following kernel requirements to install the clusterware.
    http://docs.oracle.com/cd/B28359_01/install.111/b28259/pre_hpux.htm#BABJHCJI
    Thanks.

  • Database rolling upgrade cpu patch with minimal service outage

    Oracle 11gR2 Primary Instance
    Oracle 11gR2 Active Physical Standby
    Requirement of applying CPU and CVE patches with minimal downtime. I believe that I've been able to apply CPU patch to Active Standby after deferring redo transport and applying patch to active physical standby first and then performing a manual switchover to have the standby become the primary and former-primary become the standby and they apply CPU Patch there and then perform another role transition to its original role.
    Appreciate your experience with primary and active physical standby rolling upgrades/patches. Thanks

    Hello;
    I believe you are over thinking this. All you have to do on the Standby is install the patch. No switchover, no SQL. No nothing.
    The SQL will move from the Primary to the Standby.
    Check the readme for the patch closely or post the patch number if you want to confirm.
    OR
    How do you apply a Patchset,PSU or CPU in a Data Guard Physical Standby configuration [ID 278641.1]
    ( If it helps I had the same thoughts after my first Data Guard setup !! )
    If you are trying to avoid downtime entirely the switchover will take about as long as the patch.
    If you have RAC this is interesting :
    http://javeedkaleem.blogspot.com/2010/05/how-to-apply-oracle-database-patch.html
    As is this :
    http://docs.oracle.com/cd/B28359_01/server.111/b28282/schedule_outage.htm
    Best Regards
    mseberg

  • Oracle physru rolling upgrade problem

    Hi, I'm having a problem with the Oracle Physru script provided from MOS note # 949322 I was hoping I could get some help with.
    My system contains of two Oracle 11.1.0.7.0, one primary and one physical standby.
    The hosts are two Oracle Solaris 10 Sparc x64 machines.
    My goal is to update from 11.1.0.7.0 to 11.1.0.7.8 using the script that is provided, however I'm bumping into problems at the step where the script is checking the Apply lag on the logical standby (function "get_apply_lag"). The lag seems to increase, and to be that indicates a problem with the redo apply process. However, when I query the DBA_LOGSTDBY_EVENTS View i get the following:
    SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS ORDER BY EVENT_TIMESTAMP, COMMIT_SCN;
    EVENT_TIME STATUS EVENT
    20-SEP-11 16:02:12 ORA-16111: log mining and apply setting up
    20-SEP-11 16:02:12 Apply LWM 848622, HWM 848622, SCN 848622
    Showing the output from Primary archive dest 2:
    SQL> show parameter log_archive_dest_2;
    NAME TYPE VALUE
    log_archive_dest_2 string service="test08db2", LGWR ASYNC NOAFFIRM delay=0 OPTIONAL compression=DISABLE max_failure=0 max_connections=1 reopen=300 db_unique_name="db_test08db2" net_timeout=30 valid_for=(online_logfile,primary_role)
    SQL>  select from v$LOGSTDBY_STATS;*
    NAME VALUE
    logminer session id 1
    number of preparers 1
    number of appliers 11
    server processes in use 15
    maximum SGA for LCR cache (MB) 50
    maximum events recorded 2000000000
    preserve commit order TRUE
    transaction consistency FULL
    record skipped errors Y
    record skipped DDLs Y
    record applied DDLs N
    NAME VALUE
    record unsupported operations Y
    realtime apply Y
    apply delay (minutes) 0
    coordinator state IDLE
    coordinator startup time 20-SEP-11 16:02:11
    coordinator uptime (seconds) 727
    txns received from logminer 62
    txns assigned to apply 29
    txns applied 29
    txns discarded during restart 33
    large txns waiting to be assigned 0
    NAME VALUE
    rolled back txns mined 4
    DDL txns mined 2
    CTAS txns mined 0
    bytes of redo mined 8195884
    bytes paged out 0
    pageout time (seconds) 0
    bytes checkpointed 709802
    checkpoint time (seconds) 0
    system idle time (seconds) 479
    standby redo logs mined 0
    archived logs mined 4
    NAME VALUE
    gap fetched logs mined 2
    standby redo log reuse detected 0
    logfile open failures 0
    current logfile wait (seconds) 0
    total logfile wait (seconds) 0
    thread enable mined 0
    thread disable mined 0
    distinct txns in queue 0
    41 rows selected.
    SQL> select type, high_scn, status, pid from v$logstdby order by type;
    TYPE HIGH_SCN STATUS PID
    ANALYZER 850320 ORA-16116: no work available 20702
    APPLIER 848808 ORA-16116: no work available 20719
    APPLIER 850320 ORA-16116: no work available 20731
    APPLIER 850204 ORA-16116: no work available 20727
    APPLIER 848895 ORA-16116: no work available 20725
    APPLIER 848665 ORA-16116: no work available 20705
    APPLIER 848677 ORA-16116: no work available 20709
    APPLIER 848728 ORA-16116: no work available 20713
    APPLIER 848740 ORA-16116: no work available 20715
    APPLIER 848796 ORA-16116: no work available 20717
    APPLIER 848842 ORA-16116: no work available 20721
    TYPE HIGH_SCN STATUS PID
    APPLIER 848854 ORA-16116: no work available 20723
    BUILDER 850320 ORA-16116: no work available 20221
    COORDINATOR 850326 ORA-16116: no work available 20119
    PREPARER 850318 ORA-16116: no work available 20223
    READER 850326 ORA-16116: no work available 20217
    16 rows selected.
    Physru Script Output:_
    ### Initialize script to either start over or resume execution
    Sep 20 14:35:41 2011 [0-1] Identifying rdbms software version
    Sep 20 14:35:41 2011 [0-1] database nobilldb is at version 11.1.0.7.0
    Sep 20 14:35:42 2011 [0-1] database nobilldb is at version 11.1.0.7.0
    Sep 20 14:35:44 2011 [0-1] verifying flashback database is enabled at db_test08db1 and db_test08db2
    Sep 20 14:35:44 2011 [0-1] verifying available flashback restore points
    Sep 20 14:35:45 2011 [0-1] verifying DG Broker is disabled
    Sep 20 14:35:46 2011 [0-1] looking up prior execution history
    Sep 20 14:35:46 2011 [0-1] purging script execution state from database db_test08db1
    Sep 20 14:35:46 2011 [0-1] purging script execution state from database db_test08db2
    Sep 20 14:35:47 2011 [0-1] starting new execution of script
    ### Stage 1: Backup user environment in case rolling upgrade is aborted
    Sep 20 14:35:47 2011 [1-1] stopping media recovery on db_test08db2
    Sep 20 14:35:48 2011 [1-1] creating restore point PRUP_0000_0001 on database db_test08db2
    Sep 20 14:35:49 2011 [1-1] backing up current control file on db_test08db2
    Sep 20 14:35:50 2011 [1-1] created backup control file /opt/oracle/product/11.1.0.7/dbs/PRUP_0001_db_test08db2_f.f
    Sep 20 14:35:50 2011 [1-1] creating restore point PRUP_0000_0001 on database db_test08db1
    Sep 20 14:35:51 2011 [1-1] backing up current control file on db_test08db1
    Sep 20 14:35:52 2011 [1-1] created backup control file /opt/oracle/product/11.1.0.7/dbs/PRUP_0001_db_test08db1_f.f
    NOTE: Restore point PRUP_0000_0001 and backup control file PRUP_0001_db_test08db2_f.f
    can be used to restore db_test08db2 back to its original state as a
    physical standby, in case the rolling upgrade operation needs to be aborted
    prior to the first switchover done in Stage 4.
    ### Stage 2: Create transient logical standby from existing physical standby
    Sep 20 14:35:53 2011 [2-1] verifying RAC is disabled at db_test08db2
    Sep 20 14:35:53 2011 [2-1] verifying database roles
    Sep 20 14:35:54 2011 [2-1] verifying physical standby is mounted
    Sep 20 14:35:54 2011 [2-1] verifying database protection mode
    Sep 20 14:35:55 2011 [2-1] verifying transient logical standby datatype support
    Sep 20 14:36:00 2011 [2-2] starting media recovery on db_test08db2
    Sep 20 14:36:11 2011 [2-2] confirming media recovery is running
    Sep 20 14:36:12 2011 [2-2] waiting for v$dataguard_stats view to initialize
    Sep 20 14:36:13 2011 [2-2] waiting for apply lag on db_test08db2 to fall below 30 seconds
    Sep 20 14:36:13 2011 [2-2] apply lag is now less than 30 seconds
    Sep 20 14:36:14 2011 [2-2] stopping media recovery on db_test08db2
    Sep 20 14:36:15 2011 [2-2] executing dbms_logstdby.build on database db_test08db1
    Sep 20 14:36:27 2011 [2-2] converting physical standby into transient logical standby
    Sep 20 14:36:52 2011 [2-3] opening database db_test08db2
    Sep 20 14:37:28 2011 [2-4] configuring transient logical standby parameters for rolling upgrade
    Sep 20 14:37:29 2011 [2-4] starting logical standby on database db_test08db2
    Sep 20 14:37:37 2011 [2-4] waiting until logminer dictionary has fully loaded
    Sep 20 14:37:58 2011 [2-4] dictionary load 17% complete
    Sep 20 14:38:09 2011 [2-4] dictionary load 32% complete
    Sep 20 14:38:19 2011 [2-4] dictionary load 43% complete
    Sep 20 14:38:30 2011 [2-4] dictionary load 59% complete
    Sep 20 14:38:40 2011 [2-4] dictionary load 62% complete
    Sep 20 14:38:50 2011 [2-4] dictionary load 70% complete
    Sep 20 14:39:01 2011 [2-4] dictionary load 72% complete
    Sep 20 14:39:11 2011 [2-4] dictionary load 75% complete
    Sep 20 14:40:54 2011 [2-4] dictionary load is complete
    Sep 20 14:41:00 2011 [2-4] waiting for v$dataguard_stats view to initialize
    Sep 20 14:41:01 2011 [2-4] waiting for apply lag on db_test08db2 to fall below 30 seconds
    Sep 20 14:42:02 2011 [2-4] current apply lag: 316
    Sep 20 14:42:32 2011 [2-4] current apply lag: 316
    Sep 20 14:43:03 2011 [2-4] current apply lag: 376
    Sep 20 14:43:33 2011 [2-4] current apply lag: 376
    Sep 20 14:44:03 2011 [2-4] current apply lag: 437
    Sep 20 14:44:34 2011 [2-4] current apply lag: 437
    Sep 20 14:45:04 2011 [2-4] current apply lag: 497
    Sep 20 14:45:35 2011 [2-4] current apply lag: 497
    Sep 20 14:46:05 2011 [2-4] current apply lag: 558
    Sep 20 14:46:36 2011 [2-4] current apply lag: 558
    Sep 20 14:47:06 2011 [2-4] current apply lag: 618
    I would appreciate any help I could get, I'm stuck =/
    Regards,

    http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-upgrades-made-easy-131972.pdf

  • Rolling Upgrades in Rac

    Hi All,
    can you please explain abt rolling upgrades in rac env
    suppose i am having rac setup on 10.2.0.1 if i want to apply patch set 10.2.0.4 is it required downtime
    As per the readme of 10.2.0.4
    1)Stop every thing on node 1 and apply patch set
    2)stop every thing on node 2 and apply patch set
    3)stop the database and run the catupgrd.sql script.
    My question is for running catupgrd script i have to bring down the db so what the meaning of rolling upgrade??
    And in this type of sece which type of upgrade is best one rolling or non-rolling.
    KK
    Edited by: user12061936 on May 20, 2010 2:35 PM

    Hi HTH
    Thank you for clearing my doubts regarding Rolling upgrades and i have gone though the link and i have noticed the following steps
    For Standalone system
    1) Install Oracle 10g to a separate Oracle Home on the same server
    2) Create a 10g database with only the base tablespaces: SYSTEM, SYSAUX, UNDO, and TEMP
    3) On the 9i database, put all your tablespaces into read only mode (write downtime begins)
    4) Perform a transportable tablespace export of all non-system tablespaces (as a sysdba user)
    5) Shut down the 9i database (true downtime begins)
    6) Start up the 10g database
    7) Perform a transportable tablespace import into the 10g database (end true downtime)
    8) Make all your tablespaces read/write (end write downtime)
    The above steps is going to work only for 9i to 10g or can we use it to any version to version.
    BY using TTS is it suggestable method to do the upgrade??
    KK
    Edited by: user12061936 on May 21, 2010 11:41 AM

  • Rolling Upgrade of Oracle 10gR2 RAC with Physical Standby (DG)

    Hi DBAs,
    I want to do a rolling upgrade of Oracle 10.2.0.3 (2 node RAC+ASM) with Physical Standy Dataguard to Oracle 10.2.0.4 also applying CPU (April2009).
    Please suggest the best way to perform this upgrade and patching with no downtime.
    Thanks
    -Samar-

    Unfortunately rolling upgrade is only possible with a logical standby in place:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/upgrades.htm#CHDBJAGG
    That doesn't help you at this time, but 11g has a way to do it with a physical standby. Even here you need an intermediate logical standby:
    http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/rollup.htm#CHDHCBGA
    Werner

  • Rolling upgrade from 11.2.0.2 to 11.2.0.3

    Windows 2008. 2 node RAC
    I attempted a rolling upgrade from 11.2.0.2 to 11.2.0.3 in a dev environment in prep to do my prod. I hit all kinds of issues and when googling I found there was a known issue with rolling upgrades between these versions and there was a patch I was meant to have applied before starting the rolling upgrade. I rolled back to 11.2.0.2 but for the life of me, I cant find reference to that patch now.
    anyone know what it is?
    /still looking/

    Hello,
    Please refer below document
    Things to Consider Before Upgrading to 11.2.0.3 Grid Infrastructure/ASM (Doc ID 1363369.1)
    You can check the section related to 11.2.0.2.
    It is better to check complete document carefully before attempting the upgrade.
    Regards,
    Vijay

  • 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

  • Is it possible to delay a rolling upgrade after a single domain is updated?

    Hello,
    I am working on new Azure services for my group. For various reasons, we have decided that a Staging / VIP-Swap deployment is not useful for our group and will be going with a rolling upgrade. What I am interested in, is knowing if there is a way to
    "pause" a rolling upgrade after the first update domain until it is released to complete. Or, for a set time ( 30 minutes, etc ), to allow us the opportunity to essentially have a A-B deployment of our webrole, to observe behavior while receiving
    production traffic before the release has completely deployed.
    Thanks for your help
    Jeff

    hello Jeff,
    Currently, base on my experience, delay a rolling upgrade or "pause" a rolling upgrade after the first update domain until it is released to complete, it may be difficult. I suggest you could can submit a feature suggestion on
    http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting. I suggest you could get more detail about upgrade domain and fault domain (http://blog.toddysm.com/2010/04/upgrade-domains-and-fault-domains-in-windows-azure.html).
    Best Regards,
    Will
    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click
    HERE to participate the survey.

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

  • 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

  • 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

  • SQL apply is very slow on Logical Standby..!!

    Hello all,
    We are having Data Guard setup in our environment where we are having Primary, Physical Standby as well as logical standby databases..
    DB Version : 10.2.0.1 in all databases (Pri, Phy and Logical)
    OS : RHEL4
    Only Oracle is running on this Box..
    Since last month we are facing problems in Logical Standby database where it seems SQL apply has become very slow..
    Archive log files are successfully transferring from Primary but since SQL apply has become slow logical standby is lagging behind primary by two days..
    How do i speed up this SQL apply..?? Any ideas and suggestions are most welcome..
    I checked TOP command to find out which oracle processes are consuming maximum CPU and i have found ora_p000_oracle, ora_p001_oracle, ora_p002_oracle, ora_p003_oracle, ora_p004_oracle, ora_p005_oracle, etc processes are consuming highest CPU and Load Average has always been above 1..
    Any help would be greatly appreciated..
    Thanks - HP

    Hello;
    These Oracle notes might help :
    Slow Performance In Logical Standby Database Due To Lots Of Activity On Sys.Aud$ [ID 862173.1]
    Oracle10g Data Guard SQL Apply Troubleshooting [ID 312434.1]
    Developer and DBA Tips to Optimize SQL Apply [ID 603361.1]
    Best Regards
    mseberg

  • Scshutdown fails - "Rolling Upgrade in progress"

    Anybody seen this before?
    bash$ sudo scshutdown -g 0 -y
    scshutdown: Cannot shutdown the cluster. Rolling Upgrade in progress.
    bash$
    No one has (with intention) started an upgrade on this cluster.. Its SC3.1 U2 on Solaris 8.

    While you are saying that no one hast started an upgrade, is it possible that this cluster got recently patched with current Sun Cluster patches?
    If so, you might want to check if the follwoing binary exists on your cluster:
    /usr/cluster/bin/scversions
    If it exists, just call it.
    If you see something like:
    # scversions
    Upgrade commit is NOT needed. All versions match.
    then I don't know what your problem is. However, if it says something different, you might want to try:
    # scversions -c
    and see if the problem went away.
    Greets
    Thorsten

Maybe you are looking for