Status Column Of v$log on standby database

DB Version : 11.2.0.1
OS Version : AIX 7.1
Status column of v$log is showing values as "CLEARING" & "CLEARING_CURRENT". It doesn't change even after adding the standby log files. Here are values from this view. I am not using real time apply feature and have delay of 120 Minutes.
SQL> select * from v$log;
    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
         1          1       3397  104857600        512          2 YES CLEARING              22886147 03-APR-13     22887606 03-APR-13
         3          1       3396  104857600        512          2 YES CLEARING              22886111 03-APR-13     22886147 03-APR-13
         2          1       3398  104857600        512          2 YES CLEARING_CURRENT      22887606 03-APR-13     22886111 03-APR-13
SQL> select group#,Thread#, sequence#,USER,archived,status,first_change# from v$standby_log;
    GROUP#    THREAD#  SEQUENCE# USER                           ARC STATUS     FIRST_CHANGE#
         4          1       3398 SYS                            YES ACTIVE          22887606
         5          1          0 SYS                            NO  UNASSIGNED             0
         6          0          0 SYS                            YES UNASSIGNED             0
         7          0          0 SYS                            YES UNASSIGNED             0is the status column showing value "CURREN" & "CLEARING_CURRENT" correct, since i have added standby redo logs, i was expecting value to be "INACTIVE" ? reason for expecting this value is because now, standby log files are in use and original log files will be used only in case of switchover or failover. Please comment.
Edited by: user11982706 on Apr 3, 2013 10:31 AM

size are same on both primary and standby. See the results from below query:
Primary
SQL> select GROUP#,THREAD#,bytes/1024/1024,STATUS from v$log;
    GROUP#    THREAD# BYTES/1024/1024 STATUS
         1          1             100 INACTIVE
         2          1             100 INACTIVE
         3          1             100 CURRENTStandby
SQL> select GROUP#,THREAD#,bytes/1024/1024,STATUS from v$log;
    GROUP#    THREAD# BYTES/1024/1024 STATUS
         1          1             100 CLEARING
         3          1             100 CLEARING_CURRENT
         2          1             100 CLEARING
SQL> select GROUP#,THREAD#,bytes/1024/1024,STATUS from v$standby_log;
    GROUP#    THREAD# BYTES/1024/1024 STATUS
         4          1             100 ACTIVE
         5          1             100 UNASSIGNED
         6          0             100 UNASSIGNED
         7          0             100 UNASSIGNEDSo, on standby size of online logs as well as standby logs is exactly same as primary and i have one more standby redo then primary as oracle recommends. Please comment....

Similar Messages

  • When is anything written to standby redo logs on standby database?

    I am on Oracle 10.2.0.4 on HP UNIX. I have read Oracle 10.2 concepts guide on technet.oracle.com, have read may article on metalink and internet, yet I am unable to verify when anything is written to standby redo logs on stand by database.
    I have a simple database reconfiguration: a primary database and one standby database.
    I created primary database and set up log_archive_dest_2 to use LGWR SYNC AFFIRM
    I have created standby redo logs on primary.
    alter database add standby logfile GROUP
    I create standby control file on primary.
    I copied all the primary information to create standby database. I have put standby database in managed recovery.
    I did archive log switches, I created a table and inserted information in table.
    I never saw standby redo logs updated on standby database by looking at timestamp of standby redo log files.
    I then setup database in maximum availability mode by running following on primary:
    Alter database set standby database to maximize availability
    When I do insert into my tables, I do see standby redo log files on primary database being updated, but I have never seen standby redo logs on standby database updated. Why?
    I am still at loss when actually standby redo logs are updated on standby database.
    When I read Oracle 9i database documentation on data guard, it says that you do not need standby redo logs on primary instead you need them on standby. Only reason, you need them on primary is from primary changes role to standby database, so standby redo logs on standby database should be updated instead of standby redo logs on primary.

    What is the PROTECTION_MODE ,PROTECTION_LEVEL values of your database.
    As per metalink:--
    Create standby redo log files, if necessary:
    Standby redo logs are necessary for the higher protection levels such as
    Guaranteed, Instant, and Rapid. In these protection modes LGWR from the
    Primary host writes transactions directly to the standby redo logs.
    This enables no data loss solutions and reduces the amount of data loss
    in the event of failure. Standby redo logs are not necessary if you are using
    the delayed protection mode.
    If you configure standby redo on the standby then you should also configure
    standby redo logs on the primary database. Even though the standby redo logs
    are not used when the database is running in the primary role, configuring
    the standby redo logs on the primary database is recommended in preparation
    for an eventual switchover operation.
    Standby redo logs must be archived before the data can be applied to the
    standby database. The standby archival operation occurs automatically, even if
    the standby database is not in ARCHIVELOG mode. However, the archiver process
    must be started on the standby database. Note that the use of the archiver
    process (ARCn) is a requirement for selection of a standby redo log.
    METALINK ID:- Doc ID: Note:219344.1
    Edited by: Anand... on Sep 15, 2008 2:15 AM

  • Manually apply archived log to standby database.

    Hi all,
    I am working on oracle 10g EE(10.2.0.4).I am having a very difficult database switchover case in my hand.
    1.> There are two database .one primary(prim) and another standby(standby).
    2.> Initially both of them was configured as oracle data guard, where prim was primary and standby was standby using rman .(RMAN>duplicate target database for
    standby dorecover).
    3.>But the rate of generation of archivelog is very high( 20 archivelog per hour with 200mb each).
    4.> So automatic shipping of archivelog has been disabled from primary.(log_archive_dest_state_2=defer and nullifying the value of log_archive_dest_2).
    5> Now after a period of time archived logs are shipped to dr site manually and applied manually.(alter database recover automatic standby database;)
    6.> Now there is a hardware problem occured at primary..it will take 72 hours to come up.
    How can i use standby database as primary for that 72 hour.As archive log apply is manually done and parameters are being changed,can i switch over these two?
    Is it possible to switchover and switch back these two database with such a configuration?

    How can i use standby database as primary for that 72 hour.As archive log apply is manually done and parameters are being changed,can i switch over these two?
    Is it possible to switchover and switch back these two database with such a configuration?
    As of now you can perform failover your standby to primary database. you should have flashaback enabled, so you have to create a restore point.
    Then it can be opened in read & write mode, So once you finished again you can go back to that point.
    http://docs.oracle.com/cd/B19306_01/server.102/b14239/manage_ps.htm#i1017111
    The above case applicable if you ready to loose, But it doesnt make sense. But in your case this doesnt work. Because once you start use of Standby as primary, there would be live/production data, which you need very much.
    So there is lot of work to do.
    You have to rebuild standby database and then switchover back to same location. So its a little trip work.
    Have you enabled Dataguard Broker ?
    Edited by: CKPT on Mar 13, 2012 1:43 PM

  • Adding online redo logs with standby database in place

    Hi group,
    I have decided to add one new member to my existing redo log groups and an additional redo log group to my primary database.
    That change went ok without problems. I assumed that with standby_file_management=auto the equivalent online redo logs are created on the standby database. But this is not the case.
    The documentation is unclear about this point and I did not find anything suitable on metalink. The docs suggest to cancel managed recovery on the standy, setting standby_file_management to MANUAL and then adding online logs, quote:
    "To add an online redo log, use a SQL statement such as this:
    SQL> ALTER DATABASE ADD STANDBY LOGFILE 'prmy3.log' SIZE 100K;"
    This however - IMO - adds a new STANDBY redo log to the standby database, what I need is an ONLINE redo log.
    Does anybody have some experience to share here?
    Facts:
    Solaris 8
    Oracle 9.2.0.6
    Thanks!
    Martin

    OK, for those who come across the same problem.
    You need to create a new standby controlfile, copy it as well as any new online redo log from production to the standby environment.
    Once the files are in place, start the standby as normal and open it read only to see if everything is ok:
    startup nomount
    alter database mount standby database;
    alter database open read only
    Only when there are no errors in your alert.log you are safe.
    Martin

  • Transfering archive logs in standby database

    hi,
    i am trying to create a standby database for a a test scenario using oracle 10g R2 and windows xp
    Primary DB = primary
    standby DB=stby
    iam able to ping databases from each other using tnsping , but iam not able to transfer archive logs from primary to standby
    pfile for primary is
    primary.__db_cache_size=67108864
    primary.__java_pool_size=4194304
    primary.__large_pool_size=4194304
    primary.__shared_pool_size=88080384
    primary.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0/admin/primary/adump'
    *.background_dump_dest='C:\oracle\product\10.2.0/admin/primary/bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\primary\control01.ctl','C:\oracle\product\10.2.0\oradata\primary\control02.ctl','C:\oracle\product\10.2.0\oradata\primary\control03.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0/admin/primary/cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_name='primary'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=primaryXDB)'
    *.job_queue_processes=10
    *.log_archive_dest_2='SERVICE=stby'
    *.log_archive_dest_state_2=ENABLE
    *.open_cursors=300
    *.pga_aggregate_target=16777216
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=167772160
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0/admin/primary/udump'
    log_archive_dest_1='LOCATION=C:\oracle\product\10.2.0\db_1\database\archive'
    log_archive_dest_state_1=ENABLE
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,stby)'
    pfile from standby
    primary.__db_cache_size=75497472
    primary.__java_pool_size=4194304
    primary.__large_pool_size=4194304
    primary.__shared_pool_size=79691776
    primary.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0\admin\adump'
    *.background_dump_dest='C:\oracle\product\10.2.0\admin\bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\stby.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0\admin\cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_name='primary'
    db_unique_name='stby'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=primaryXDB)'
    *.job_queue_processes=10
    *.open_cursors=300
    *.pga_aggregate_target=16777216
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=167772160
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0\admin\udump'
    standby_archive_dest='C:\oracle\product\10.2.0\stbyarch'
    db_file_name_convert='C:\oracle\product\10.2.0\oradata\primary','C:\oracle\product\10.2.0\oradata'
    log_file_name_convert='C:\oracle\product\10.2.0\oradata\primary','C:\oracle\product\10.2.0\oradata'
    standby_file_management=AUTO

    You do not point to the standby database from your primary, in order to get the archivelogs transfered. You need to set at least the parameter LOG_ARCHIVE_DEST_2 like this:
    SQL>alter system set LOG_ARCHIVE_DEST_2='SERVICE=stdby VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby';stdby has to be resolved by the tnsnames.ora on the primary server. Have a look here:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ps.htm#i67520
    That explains all you need to do to create a physical standby briefly.
    Kind regards
    Uwe
    http://uhesse.wordpress.com

  • Number of Standby Redo Logs on Standby Database

    Hello All:
    Per various docs i calculated and created the number of standby redo logs.
    I created 6 standby redo logs in addition to 3 online.
    However, i always see only two standby redo logs being used. Any ideas?
    Thanks
    San~

    try:
    alter system archive log current;
    and get information:
    select * from v$logfile;
    select * from v$log;
    Thanks.

  • Increase current redo log size in standby database in mount stage

    We have oracle 10g standby database. The standby database is always running in mount stage while apply logs manually not data guard is used.
    We have increase size or online redo log in primary . Now want to inrease in standby database also.
    how to increase the size of current online redo log in standby database while it in mount stage .
    in mount stage we cant run alter system switch logfile

    user11965804 wrote:
    We have oracle 10g standby database. The standby database is always running in mount stage while apply logs manually not data guard is used.
    We have increase size or online redo log in primary . Now want to inrease in standby database also.
    how to increase the size of current online redo log in standby database while it in mount stage .
    in mount stage we cant run alter system switch logfilein 10g Standby will be always in Mount status when MRP is running.
    When you increase size of online redo log files in primary, You should increase in standby also..
    Standby redo log file size should be equal or higher than primary. You no need to switch log files on Standby.
    You will have only standby redo log files in standby not ORL(online redo log files)
    You can use this below script to add standby redo log files.
    http://www.pythian.com/news/581/oracle-standby-redo-logs/

  • Standby database online redologs

    1-)
    I know that online redologs are not being used in physical standby database.
    Suppose I created a physical standby database with standby redologs.
    As far as I know online redologs are not used in standby database,(standby redologs are used)
    However, when I check the status of the online redologs in standby database I see that:
    "CLEARING_CURRENT" or "CLEARING".
    Their status is also changing once log switch occurs in production.
    Whats the reason for this and why does this status always change, if standby online redologs are not used, their status
    should not change.
    2-)
    What would happen if I delete the online redolog of the standby database from the operating system?
    Does the status again show: clearing,clearing current?

    Standby online logs are not used, but they have status CLEARING in preparation for a possible switchover/failover. So they are ready to become very fast active online logs.
    I would never delete any database files on OS level, although the standby online logs are not needed when the database runs in standby role, Oracle will complain about their missing. At least when you restart the standby.
    Werner

  • Standby database errors - Alter database open read only

    alter database open read only
    AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
    Signalling error 1152 for datafile 1!
    Beginning standby crash recovery.
    Serial Media Recovery started
    Managed Standby Recovery starting Real Time Apply
    Media Recovery Waiting for thread 1 sequence 216
    Mon Dec 20 11:58:18 2010
    Standby crash recovery need archive log for thread 1 sequence 216 to continue.
    Please verify that primary database is transporting redo logs to the standby database.
    Wait timeout: thread 1 sequence 216
    Standby crash recovery aborted due to error 16016.
    Errors in file /u01/app/oracle/diag/rdbms/mdm2/MDM2/trace/MDM2_ora_17442.trc:
    ORA-16016: archived log for thread 1 sequence# 216 unavailable
    Recovery interrupted!
    Completed standby crash recovery.
    Signalling error 1152 for datafile 1!
    Errors in file /u01/app/oracle/diag/rdbms/mdm2/MDM2/trace/MDM2_ora_17442.trc:
    ORA-10458: standby database requires recovery
    ORA-01152: file 1 was not restored from a sufficiently old backup
    ORA-01110: data file 1: '+MDMDG1/mdm2/datafile/system.280.738243341'
    ORA-10458 signalled during: alter database open read only...
    Mon Dec 20 12:13:46 2010
    ALTER DATABASE RECOVER managed standby database using current logfile disconnect
    Attempt to start background Managed Standby Recovery process (MDM2)
    Mon Dec 20 12:13:46 2010
    MRP0 started with pid=23, OS id=18974
    MRP0: Background Managed Standby Recovery process started (MDM2)
    started logmerger process
    Mon Dec 20 12:13:51 2010
    Managed Standby Recovery starting Real Time Apply
    Parallel Media Recovery started with 2 slaves
    Waiting for all non-current ORLs to be archived...
    All non-current ORLs have been archived.
    Media Recovery Waiting for thread 1 sequence 216
    Completed: ALTER DATABASE RECOVER managed standby database using current logfile disconnect
    The above lines are from alert log of standby database.
    Standby standbase
    SQL> alter database open read only;
    alter database open read only
    ERROR at line 1:
    ORA-10458: standby database requires recovery
    ORA-01152: file 1 was not restored from a sufficiently old backup
    ORA-01110: data file 1: '+MDMDG1/mdm2/datafile/system.280.738243341'
    Parameters set on primary are
    log_archive_dest_1 LOCATION=+MDMDG3/MDM1/ARCH VALID_FOR=(ALL_LOGFILES,ALL_ROLE ) DB_UNIQUE_NAME=MDM1
    log_archive_dest_state_1 ENABLE
    log_archive_dest_2 SERVICE=MDM2 SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=MDM2
    log_archive_dest_state_2 ENABLE
    dg_broker_config_file1 +MDMDG2/mdm/dg_config/dgconfig1_mdm.dat
    dg_broker_config_file2 +MDMDG2/mdm/dg_config/dgconfig2_mdm.dat
    fal_server MDM2
    standby_file_management AUTO
    log_archive_config dg_config=(MDM1,MDM2)
    db_file_name_convert MDM2, MDM1
    ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE availability ;
    Standby pfile
    *.archive_lag_target=900
    *.audit_file_dest='/u01/app/oracle/admin/MDM2/adump'
    *.audit_trail='db'
    *.compatible='11.2.0.0.0'
    *.control_files='+MDMDG1/MDM2/CONTROLFILE/controlfile01.ctl','+MDMDG2/MDM2/CONTROLFILE/controlfile02.ctl'
    *.db_block_size=8192
    *.db_create_file_dest='+MDMDG1'
    *.db_domain=''
    *.db_file_name_convert='MDM1','MDM2'
    *.db_name='MDM'
    *.db_recovery_file_dest='+MDMDG2'
    *.db_recovery_file_dest_size=10485760000
    *.db_unique_name='MDM2'
    *.dg_broker_config_file1='+MDMDG2/MDM/DG_CONFIG/dgconfig1_MDM.dat'
    *.dg_broker_config_file2='+MDMDG2/MDM/DG_CONFIG/dgconfig2_MDM.dat'
    *.diagnostic_dest='/u01/app/oracle'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=MDM2XDB)'
    *.fal_server='MDM11','MDM12'
    *.instance_name='MDM2'
    *.log_archive_config='dg_config=(MDM1,MDM2)'
    *.log_archive_dest_1='LOCATION=+MDMDG3/MDM2/ARCH VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=MDM2'
    *.log_archive_dest_2='SERVICE=MDM1 ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=MDM1'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_state_2='ENABLE'
    *.log_archive_format='MDM_%t_%s_%r.arc'
    *.log_file_name_convert='MDM1','MDM2'
    *.memory_target=838860800
    *.nls_language='ENGLISH'
    *.nls_territory='UNITED KINGDOM'
    *.open_cursors=300
    *.processes=500
    *.remote_login_passwordfile='exclusive'
    *.sessions=555
    *.standby_file_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    On standby ASM
    ASMCMD [+] > find * *
    +MDMDG1/ASM/
    +MDMDG1/ASM/ASMPARAMETERFILE/
    +MDMDG1/ASM/ASMPARAMETERFILE/REGISTRY.253.737811541
    +MDMDG1/MDM/
    +MDMDG1/MDM2/
    +MDMDG1/MDM2/CONTROLFILE/
    +MDMDG1/MDM2/CONTROLFILE/controlfile01.ctl
    +MDMDG1/MDM2/CONTROLFILE/current.265.738243333
    +MDMDG1/MDM2/DATAFILE/
    +MDMDG1/MDM2/DATAFILE/CANVAS_POPULARITY_DATA.264.738243343
    +MDMDG1/MDM2/DATAFILE/CANVAS_POPULARITY_IDX.277.738243343
    +MDMDG1/MDM2/DATAFILE/MDM_SRC_DATA.282.738243343
    +MDMDG1/MDM2/DATAFILE/MDM_SRC_IDX.275.738243343
    +MDMDG1/MDM2/DATAFILE/MIPS_MDM_DATA.283.738243341
    +MDMDG1/MDM2/DATAFILE/MIPS_MDM_IDX.276.738243343
    +MDMDG1/MDM2/DATAFILE/SYSAUX.281.738243341
    +MDMDG1/MDM2/DATAFILE/SYSTEM.280.738243341
    +MDMDG1/MDM2/DATAFILE/TEST_TBSP1.273.738243345
    +MDMDG1/MDM2/DATAFILE/TEST_TBSP2.272.738243345
    +MDMDG1/MDM2/DATAFILE/UNDOTBS1.256.738243343
    +MDMDG1/MDM2/DATAFILE/UNDOTBS2.279.738243343
    +MDMDG1/MDM2/DATAFILE/USERS.278.738243347
    +MDMDG1/MDM2/ONLINELOG/
    +MDMDG1/MDM2/ONLINELOG/group_1.259.738243429
    +MDMDG1/MDM2/ONLINELOG/group_2.257.738243431
    +MDMDG1/MDM2/ONLINELOG/group_21.284.738243505
    +MDMDG1/MDM2/ONLINELOG/group_22.261.738243505
    +MDMDG1/MDM2/ONLINELOG/group_23.274.738243505
    +MDMDG1/MDM2/ONLINELOG/group_3.258.738243431
    +MDMDG1/MDM2/ONLINELOG/group_31.262.738243513
    +MDMDG1/MDM2/ONLINELOG/group_32.270.738243513
    +MDMDG1/MDM2/ONLINELOG/group_33.263.738243513
    +MDMDG1/MDM2/ONLINELOG/group_4.260.738243431
    +MDMDG2/MDM/
    +MDMDG2/MDM/DG_CONFIG/
    +MDMDG2/MDM2/
    +MDMDG2/MDM2/AUTOBACKUP/
    +MDMDG2/MDM2/AUTOBACKUP/2010_12_20/
    +MDMDG2/MDM2/AUTOBACKUP/2010_12_20/s_738242861.263.738244155
    +MDMDG2/MDM2/CONTROLFILE/
    +MDMDG2/MDM2/CONTROLFILE/controlfile02.ctl
    +MDMDG2/MDM2/CONTROLFILE/current.271.738243335
    +MDMDG2/MDM2/ONLINELOG/
    +MDMDG2/MDM2/ONLINELOG/group_1.270.738243429
    +MDMDG2/MDM2/ONLINELOG/group_2.269.738243431
    +MDMDG2/MDM2/ONLINELOG/group_21.268.738243505
    +MDMDG2/MDM2/ONLINELOG/group_22.272.738243505
    +MDMDG2/MDM2/ONLINELOG/group_23.262.738243505
    +MDMDG2/MDM2/ONLINELOG/group_3.273.738243431
    +MDMDG2/MDM2/ONLINELOG/group_31.266.738243513
    +MDMDG2/MDM2/ONLINELOG/group_32.265.738243513
    +MDMDG2/MDM2/ONLINELOG/group_33.264.738243513
    +MDMDG2/MDM2/ONLINELOG/group_4.261.738243431
    +MDMDG3/MDM/
    +MDMDG3/MDM/ARCH/
    +MDMDG3/MDM2/
    +MDMDG3/MDM2/ARCH/
    -- Please can I know how to open read only standby database.

    user5846399 wrote:
    ORA-16016: archived log for thread 1 sequence# 216 unavailable
    Recovery interrupted!archived log for thread 1 sequence# 216
    This file is needed for recovery, Find it and move it to the standby database side.

  • Cannot Clear Critical Alert for Physical Standby Databases

    10.2.0.4.0 Grid Control monitoring 10.2.0.4.0 databases and standby databases with 10.2.0.4.0 agents.
    The standby databases are running on Xen guests. The O/S is Red Hat 4 Advanced Server.
    I had a failure of Xen guest on Saturday that caused me to have to rebuild the standby servers. EM Grid Control successfully verifies the configurations and the status is normal for both physical standby databases. (A rebuilt logical standby database shows no alerts.)
    Grid Control database targets page shows a single critical alert for each physical standby database. The alert is for "number of missing media files is 4". The metric graph shows the count as 0 since before the rebuilds. I cannot clear the alerts from the Critical Alerts page. Grid Control reports "The selected alert(s) cannot be manually cleared. They will clear automatically once the metric is no longer in a critical or warning state.".
    Any suggestions?
    Thanks,
    Ray Westphal

    Thanks for the reply Anthony.
    The result of the query on both standby databases is '0'. The metric graph also shows the value at '0' since before rebuilds.
    And the OMS db and agents have been reset several times since I posted this.
    Ray Westphal.

  • Backups on Physical standby database?

    I am using dataguard and a physical standby database.How to assign backups on physical standby database to reduce the load on Primary database.
    environment: windows
    Database version:11.2.0.1.0
    What are the pro and cons on assigning RMAN backups jobs to physical standby database?

    Is it better to assign the RMAN backups on standby?i am using the RMAN catalog.Yes, Already mentioned to reduce contention on primary. You can register even standby.
    Do i need to change the setting to backup archive logs from standby database? If i won't backup the archive logs on Primary the FRA will be full and i can't access it ?You can include even archive logs with your database backup.
    How to assign the archive logs backups,full backup on standby database?Same script will work, Before that cancel MRP and after backup start MRP. That should be fine.
    Recently i tested backup from standby and restore, Please see below log.
    =================================================================================================
    Backup Scrpts:-
    =================================================================================================
    RMAN> run
    2> 3> ALLOCATE CHANNEL dev11 type disk;
    4> backup as compressed backupset
    5> format '/home/oracle/backup/DBF_FULLCOLD_BKP_%s'
    6> filesperset 30
    7> (database);
    backup current controlfile format
    8> 9> '/home/oracle/backup/CTL_FULLCOLD_BKP_%s';
    RELEASE CHANNEL dev1;
    RELEASE CHANNEL dev2;
    10> 11> 12> }
    using target database control file instead of recovery catalog
    allocated channel: dev11
    channel dev11: SID=1 device type=DISK
    Starting backup at 03-FEB-13
    Starting implicit crosscheck backup at 03-FEB-13
    Finished implicit crosscheck backup at 03-FEB-13
    Starting implicit crosscheck copy at 03-FEB-13
    Crosschecked 4 objects
    Finished implicit crosscheck copy at 03-FEB-13
    searching for all files in the recovery area
    channel dev11: starting compressed full datafile backup set
    channel dev11: specifying datafile(s) in backup set
    input datafile file number=00001 name=/u01/app/oracle/oradata/orcl/system01.dbf
    input datafile file number=00002 name=/u01/app/oracle/oradata/orcl/sysaux01.dbf
    input datafile file number=00003 name=/u01/app/oracle/oradata/orcl/undotbs01.dbf
    input datafile file number=00004 name=/u01/app/oracle/oradata/orcl/users01.dbf
    channel dev11: starting piece 1 at 03-FEB-13
    channel dev11: starting compressed full datafile backup set
    channel dev11: specifying datafile(s) in backup set
    input datafile file number=00001 name=/u01/app/oracle/oradata/orcl/system01.dbf
    input datafile file number=00002 name=/u01/app/oracle/oradata/orcl/sysaux01.dbf
    input datafile file number=00003 name=/u01/app/oracle/oradata/orcl/undotbs01.dbf
    input datafile file number=00004 name=/u01/app/oracle/oradata/orcl/users01.dbf
    channel dev11: starting piece 1 at 03-FEB-13
    channel dev11: finished piece 1 at 03-FEB-13
    piece handle=/home/oracle/backup/DBF_FULLCOLD_BKP_23 tag=TAG20130203T192535 comment=NONE
    channel dev11: backup set complete, elapsed time: 00:03:57
    channel dev11: starting compressed full datafile backup set
    channel dev11: specifying datafile(s) in backup set
    including current control file in backup set
    channel dev11: starting piece 1 at 03-FEB-13
    channel dev11: finished piece 1 at 03-FEB-13
    piece handle=/home/oracle/backup/DBF_FULLCOLD_BKP_24 tag=TAG20130203T192535 comment=NONE
    channel dev11: backup set complete, elapsed time: 00:00:02
    Finished backup at 03-FEB-13
    Starting backup at 03-FEB-13
    channel dev11: starting full datafile backup set
    channel dev11: specifying datafile(s) in backup set
    including current control file in backup set
    channel dev11: starting piece 1 at 03-FEB-13
    channel dev11: finished piece 1 at 03-FEB-13
    piece handle=/home/oracle/backup/CTL_FULLCOLD_BKP_25 tag=TAG20130203T192939 comment=NONE
    channel dev11: backup set complete, elapsed time: 00:00:03
    Finished backup at 03-FEB-13
    released channel: dev11
    =================================================================================================
    Backup Files:-
    =================================================================================================
    [oracle@oracle-stby backup]$ ls -ltr
    total 364572
    -rw-r----- 1 oracle oinstall 361684992 Feb  3 19:29 DBF_FULLCOLD_BKP_23
    -rw-r----- 1 oracle oinstall   1163264 Feb  3 19:29 DBF_FULLCOLD_BKP_24
    -rw-r----- 1 oracle oinstall  10092544 Feb  3 19:29 CTL_FULLCOLD_BKP_25
    [oracle@oracle-stby backup]$
    =================================================================================================
    Restore CONTROL FILE:-
    =================================================================================================
    RMAN> restore controlfile from '/home/oracle/backup/CTL_FULLCOLD_BKP_25';
    Starting restore at 03-FEB-13
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=19 device type=DISK
    channel ORA_DISK_1: restoring control file
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
    output file name=/u02/app/oracle/oradata/orcl/control01.ctl
    output file name=/u02/app/oracle/flash_recovery_area/orcl/control02.ctl
    Finished restore at 03-FEB-13
    RMAN> sql 'alter database mount';
    sql statement: alter database mount
    released channel: ORA_DISK_1
    RMAN>
    =================================================================================================
    Restore Database:-
    =================================================================================================
    RMAN> restore database;
    Starting restore at 03-FEB-13
    Starting implicit crosscheck backup at 03-FEB-13
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=19 device type=DISK
    Crosschecked 2 objects
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/orcl/system01.dbf
    channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/orcl/sysaux01.dbf
    channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/orcl/undotbs01.dbf
    Sun Feb 03 19:37:47 2013
    Checker run found 4 new persistent data failures
    Sun Feb 03 19:38:40 2013
    Full restore complete of datafile 3 /u01/app/oracle/oradata/orcl/undotbs01.dbf.  Elapsed time: 0:00:56
      checkpoint is 1595132
      last deallocation scn is 1519218
      channel ORA_DISK_1: piece handle=/home/oracle/backup/DBF_FULLCOLD_BKP_23 tag=TAG20130203T192535
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:02:07
    Finished restore at 03-FEB-13
    RMAN>
    =================================================================================================
    Open Database:-
    =================================================================================================
    SQL> alter database open resetlogs;
    Database altered.
    SQL> select open_mode,database_role from v$database;
    OPEN_MODE            DATABASE_ROLE
    READ WRITE           PRIMARY
    SQL>Edited by: CKPT on Feb 21, 2013 11:24 PM

  • How standby database works

    Hi!!
    I have created standby database (testcat) for primary database (test) using Duplicate Command of RMAN on same server (windows XP) on Oracle 11.2 . I know how to create standby database But i don't know how and when standby database works. I checked init.ora file of standby database it contains all parameters prefixed with *. as follow
    *.db_create_file_dest='F:\app\Administrator\oradata'
    *.db_domain=''
    *.db_recovery_file_dest='F:\app\Administrator\flash_recovery_area'
    *.db_recovery_file_dest_size=10737418240
    *.db_unique_name='testcat'
    *.DB_NAME='test'
    *.control_files="D:\APP\ORACLE\ORADATA\TESTCAT\CONTROLFILE\CONTROL_STAND1.CTL‘'
    While init.ora file of primary database contains entries like
    db_create_file_dest=F:\app\Administrator\oradata
    db_recovery_file_dest=F:\app\Administrator\flash_recovery_area
    db_recovery_file_dest_size=4039114752
    control_files="F:\APP\ADMINISTRATOR\ORADATA\TEST\CONTROLFILE\O1_MF_8TXW6QN0_.CTL"
    So I want to know is
              1. IS  there any difference between  parameter that start with .* and start without .*
              2. Can i set db_create_file_dest parameter in init.ora of standby database to another location.
               3. How redo log will be applied to standby database when I run ALTER DATABASE RECOVER ..... command
              4. where archived log files of standby database will stored?

    1. Fetch Archive Log (FAL) Client :- It requests for archived redo log files from the primary site.
    That means FAL Client is required (should exist) on standby database server. Am i right here?
    FAL Client is Standby database, FAL Client requre archived log from FAL Server (primary, Cascading standby database ) for Gap Resolution.
    2. Fetch Archive Log (FAL) Server:- It requests for archive redo logs from FAL Client (Standby database).That means FAL Server is required (should exist) on primary database server.
    If yes then, why it  is required because FAL Server request for archived redo logs from standby database while on other side standby database can not have redo logs as it runs in READ ONLY Access mode (So no DML and DDL) ?.
    Also primary database will be  always one step ahead in terms of archive logs than standby database and hence there is no need to request for archived logs from stanby. Am i right here?
    Yes you are right. Primary  is newer require archived log from  standby. You asked and answered.
    Regards
    Mahir M. Quluzade

  • Logs are not getting applied in the standby database

    Hello,
    I have created a physical standby database and in it the logs are not getting applied..
    following is an extract of the standby alert log
    Wed Sep 05 07:53:59 2012
    Media Recovery Log /u01/oracle/oradata/ABC/archives/1_37638_765704228.arc
    Error opening /u01/oracle/oradata/ABC/archives/1_37638_765704228.arc
    Attempting refetch
    Media Recovery Waiting for thread 1 sequence 37638
    Fetching gap sequence in thread 1, gap sequence 37638-37643
    Wed Sep 05 07:53:59 2012
    RFS[46]: Assigned to RFS process 3081
    RFS[46]: Allowing overwrite of partial archivelog for thread 1 sequence 37638
    RFS[46]: Opened log for thread 1 sequence *37638* dbid 1723205832 branch 765704228
    Wed Sep 05 07:55:34 2012
    RFS[42]: Possible network disconnect with primary database
    However, the archived files are getting copied to the standby server.
    I tried registering and recovering the logs but it also failed..
    Follows some of the information,
    Primary
    Oralce 11R2 EE
    SQL> select max(sequence#) from v$log where archived='YES';
    MAX(SEQUENCE#)
    37668
    SQL> select DEST_NAME, RECOVERY_MODE,DESTINATION,ARCHIVED_SEQ#,APPLIED_SEQ#, SYNCHRONIZATION_STATUS,SYNCHRONIZED,GAP_STATUS from v$archive_dest_status where DEST_NAME = 'LOG_ARCHIVE_DEST_3';
    DEST_NAME RECOVERY_MODE DESTINATION ARCHIVED_SEQ# APPLIED_SEQ# SYNCHRONIZATION_STATUS SYNCHRONIZED GAP_STATUS
    LOG_ARCHIVE_DEST_3 MANAGED REAL TIME APPLY ABC 37356 0 CHECK CONFIGURATION NO RESOLVABLE GAP
    Standby
    Oralce 11R2 EE
    SQL> select max(sequence#) from v$archived_log where applied='YES';
    MAX(SEQUENCE#)
    37637
    SQL> select * from v$archive_gap;
    no rows selected
    SQL> select open_mode, database_role from v$database;
    OPEN_MODE DATABASE_ROLE
    READ ONLY WITH APPLY PHYSICAL STANDBY
    Please help me to troubleshoot this and get the standby in sync..
    Thanks a lot..

    the results are as follows..
    SQL> select process, status, group#, thread#, sequence# from v$managed_standby order by process, group#, thread#, sequence#;
    PROCESS STATUS GROUP# THREAD# SEQUENCE#
    ARCH CLOSING 1 1 37644
    ARCH CLOSING 1 1 37659
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    ARCH CONNECTED N/A 0 0
    MRP0 WAIT_FOR_GAP N/A 1 37638
    RFS IDLE N/A 0 0
    RFS IDLE N/A 0 0
    RFS IDLE N/A 0 0
    RFS RECEIVING N/A 1 37638
    RFS RECEIVING N/A 1 37639
    RFS RECEIVING N/A 1 37640
    RFS RECEIVING N/A 1 37641
    RFS RECEIVING N/A 1 37642
    RFS RECEIVING N/A 1 37655
    RFS RECEIVING N/A 1 37673
    RFS RECEIVING N/A 1 37675
    42 rows selected.
    SQL>
    SQL> select name,value, time_computed from v$dataguard_stats;
    NAME VALUE TIME_COMPUTED
    transport lag +00 02:44:33 09/05/2012 09:25:58
    apply lag +00 03:14:30 09/05/2012 09:25:58
    apply finish time +00 00:01:09.974 09/05/2012 09:25:58
    estimated startup time 12 09/05/2012 09:25:58
    SQL> select timestamp , facility, dest_id, message_num, error_code, message from v$dataguard_status order by timestamp
    TIMESTAMP FACILITY DEST_ID MESSAGE_NUM ERROR_CODE MESSAGE
    05-SEP-12 Remote File Server 0 60 0 RFS[13]: Assigned to RFS process 2792
    05-SEP-12 Remote File Server 0 59 0 RFS[12]: Assigned to RFS process 2790
    05-SEP-12 Log Apply Services 0 61 16037 MRP0: Background Media Recovery cancelled with status 16037
    05-SEP-12 Log Apply Services 0 62 0 MRP0: Background Media Recovery process shutdown
    05-SEP-12 Log Apply Services 0 63 0 Managed Standby Recovery Canceled
    05-SEP-12 Log Apply Services 0 64 0 Managed Standby Recovery not using Real Time Apply
    05-SEP-12 Log Apply Services 0 65 0 Attempt to start background Managed Standby Recovery process
    05-SEP-12 Log Apply Services 0 66 0 MRP0: Background Managed Standby Recovery process started
    05-SEP-12 Log Apply Services 0 67 0 Managed Standby Recovery not using Real Time Apply
    05-SEP-12 Log Apply Services 0 68 0 Media Recovery Waiting for thread 1 sequence 37638 (in transit)
    05-SEP-12 Network Services 0 69 0 RFS[5]: Possible network disconnect with primary database
    05-SEP-12 Network Services 0 70 0 RFS[6]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 71 0 RFS[14]: Assigned to RFS process 2829
    05-SEP-12 Remote File Server 0 72 0 RFS[15]: Assigned to RFS process 2831
    05-SEP-12 Network Services 0 73 0 RFS[9]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 74 0 RFS[16]: Assigned to RFS process 2833
    05-SEP-12 Network Services 0 75 0 RFS[1]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 76 0 RFS[17]: Assigned to RFS process 2837
    05-SEP-12 Network Services 0 77 0 RFS[3]: Possible network disconnect with primary database
    05-SEP-12 Network Services 0 78 0 RFS[2]: Possible network disconnect with primary database
    05-SEP-12 Network Services 0 79 0 RFS[7]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 80 0 RFS[18]: Assigned to RFS process 2848
    05-SEP-12 Network Services 0 81 0 RFS[16]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 82 0 RFS[19]: Assigned to RFS process 2886
    05-SEP-12 Network Services 0 83 0 RFS[19]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 84 0 RFS[20]: Assigned to RFS process 2894
    05-SEP-12 Log Apply Services 0 85 16037 MRP0: Background Media Recovery cancelled with status 16037
    05-SEP-12 Log Apply Services 0 86 0 MRP0: Background Media Recovery process shutdown
    05-SEP-12 Log Apply Services 0 87 0 Managed Standby Recovery Canceled
    05-SEP-12 Remote File Server 0 89 0 RFS[22]: Assigned to RFS process 2900
    05-SEP-12 Remote File Server 0 88 0 RFS[21]: Assigned to RFS process 2898
    05-SEP-12 Remote File Server 0 90 0 RFS[23]: Assigned to RFS process 2902
    05-SEP-12 Remote File Server 0 91 0 Primary database is in MAXIMUM PERFORMANCE mode
    05-SEP-12 Remote File Server 0 92 0 RFS[24]: Assigned to RFS process 2904
    05-SEP-12 Remote File Server 0 93 0 RFS[25]: Assigned to RFS process 2906
    05-SEP-12 Log Apply Services 0 94 0 Attempt to start background Managed Standby Recovery process
    05-SEP-12 Log Apply Services 0 95 0 MRP0: Background Managed Standby Recovery process started
    05-SEP-12 Log Apply Services 0 96 0 Managed Standby Recovery starting Real Time Apply
    05-SEP-12 Log Apply Services 0 97 0 Media Recovery Waiting for thread 1 sequence 37638 (in transit)
    05-SEP-12 Log Transport Services 0 98 0 ARCa: Beginning to archive thread 1 sequence 37644 (7911979302-7912040568)
    05-SEP-12 Log Transport Services 0 99 0 ARCa: Completed archiving thread 1 sequence 37644 (0-0)
    05-SEP-12 Network Services 0 100 0 RFS[8]: Possible network disconnect with primary database
    05-SEP-12 Log Apply Services 0 101 16037 MRP0: Background Media Recovery cancelled with status 16037
    05-SEP-12 Log Apply Services 0 102 0 Managed Standby Recovery not using Real Time Apply
    05-SEP-12 Log Apply Services 0 103 0 MRP0: Background Media Recovery process shutdown
    05-SEP-12 Log Apply Services 0 104 0 Managed Standby Recovery Canceled
    05-SEP-12 Network Services 0 105 0 RFS[20]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 106 0 RFS[26]: Assigned to RFS process 2930
    05-SEP-12 Network Services 0 107 0 RFS[24]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 108 0 RFS[27]: Assigned to RFS process 2938
    05-SEP-12 Network Services 0 109 0 RFS[14]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 110 0 RFS[28]: Assigned to RFS process 2942
    05-SEP-12 Network Services 0 111 0 RFS[15]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 112 0 RFS[29]: Assigned to RFS process 2986
    05-SEP-12 Network Services 0 113 0 RFS[17]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 114 0 RFS[30]: Assigned to RFS process 2988
    05-SEP-12 Log Apply Services 0 115 0 Attempt to start background Managed Standby Recovery process
    05-SEP-12 Log Apply Services 0 116 0 MRP0: Background Managed Standby Recovery process started
    05-SEP-12 Log Apply Services 0 117 0 Managed Standby Recovery starting Real Time Apply
    05-SEP-12 Log Apply Services 0 118 0 Media Recovery Waiting for thread 1 sequence 37638 (in transit)
    05-SEP-12 Network Services 0 119 0 RFS[18]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 120 0 RFS[31]: Assigned to RFS process 3003
    05-SEP-12 Network Services 0 121 0 RFS[26]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 122 0 RFS[32]: Assigned to RFS process 3005
    05-SEP-12 Network Services 0 123 0 RFS[27]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 124 0 RFS[33]: Assigned to RFS process 3009
    05-SEP-12 Remote File Server 0 125 0 RFS[34]: Assigned to RFS process 3012
    05-SEP-12 Log Apply Services 0 127 0 Managed Standby Recovery not using Real Time Apply
    05-SEP-12 Log Apply Services 0 126 16037 MRP0: Background Media Recovery cancelled with status 16037
    05-SEP-12 Log Apply Services 0 128 0 MRP0: Background Media Recovery process shutdown
    05-SEP-12 Log Apply Services 0 129 0 Managed Standby Recovery Canceled
    05-SEP-12 Network Services 0 130 0 RFS[32]: Possible network disconnect with primary database
    05-SEP-12 Log Apply Services 0 131 0 Managed Standby Recovery not using Real Time Apply
    05-SEP-12 Log Apply Services 0 132 0 Attempt to start background Managed Standby Recovery process
    05-SEP-12 Log Apply Services 0 133 0 MRP0: Background Managed Standby Recovery process started
    05-SEP-12 Log Apply Services 0 134 0 Managed Standby Recovery not using Real Time Apply
    05-SEP-12 Log Apply Services 0 135 0 Media Recovery Waiting for thread 1 sequence 37638 (in transit)
    05-SEP-12 Network Services 0 136 0 RFS[33]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 137 0 RFS[35]: Assigned to RFS process 3033
    05-SEP-12 Log Apply Services 0 138 16037 MRP0: Background Media Recovery cancelled with status 16037
    05-SEP-12 Log Apply Services 0 139 0 MRP0: Background Media Recovery process shutdown
    05-SEP-12 Log Apply Services 0 140 0 Managed Standby Recovery Canceled
    05-SEP-12 Remote File Server 0 141 0 RFS[36]: Assigned to RFS process 3047
    05-SEP-12 Log Apply Services 0 142 0 Attempt to start background Managed Standby Recovery process
    05-SEP-12 Log Apply Services 0 143 0 MRP0: Background Managed Standby Recovery process started
    05-SEP-12 Log Apply Services 0 144 0 Managed Standby Recovery starting Real Time Apply
    05-SEP-12 Log Apply Services 0 145 0 Media Recovery Waiting for thread 1 sequence 37638 (in transit)
    05-SEP-12 Network Services 0 146 0 RFS[35]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 147 0 RFS[37]: Assigned to RFS process 3061
    05-SEP-12 Network Services 0 148 0 RFS[36]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 149 0 RFS[38]: Assigned to RFS process 3063
    05-SEP-12 Remote File Server 0 150 0 RFS[39]: Assigned to RFS process 3065
    05-SEP-12 Network Services 0 151 0 RFS[25]: Possible network disconnect with primary database
    05-SEP-12 Network Services 0 152 0 RFS[21]: Possible network disconnect with primary database
    05-SEP-12 Remote File Server 0 153 0 Archivelog record exists, but no file is found
    05-SEP-12 Remote File Server 0 154 0 RFS[40]: Assigned to RFS process 3067
    05-SEP-12 Network Services 0 155 0 RFS[37]: Possible network disconnect with primary database

  • Restored standby database from primary; now no logs are shipped

    Hi
    We recently had a major network/SAN issue and had to restore our standby database from a backup of the primary. To do this, we restored the database to the standby, created a standby controlfile on the primary, copied this across to the control file locations and started in standby recover and applied the logs manually/registered to get it back up to speed.
    However, no new logs are being shipped across from the primary.
    Have we missed a step somewhere?
    One thing we've noticed is that there is no RFS process running on the standby:
    SQL> SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
    PROCESS CLIENT_P SEQUENCE# STATUS
    ARCH ARCH 0 CONNECTED
    ARCH ARCH 0 CONNECTED
    MRP0 N/A 100057 WAIT_FOR_LOG
    How do we start this? Or will it only show if the arc1 process on the primary is sending files?
    The arc1 process is showing at OS level on the primary but I'm wondering if its faulty somehow?
    There are NO errors in the alert logs in the primary or the standby. There's not even the normal FAL gap sequence type error - in the standby it's just saying 'waiting for log' and a number from ages ago. It's like the primary isn't even talking to the standby. The listener is up and running ok though...
    What else can we check/do?
    If we manually copy across files and do an 'alter database register' then they are applied to the standby without issue; there's just no automatic log shipping going on...
    Thanks
    Ross

    Hi all
    Many thanks for all the responses.
    The database is 10.2.0.2.0, on AIX 6.
    I believe the password files are ok; we've had issues previously and this is always flagged in the alert log on the primary - not the case here.
    Not set to DEFER on primary; log_archive_dest_2 is set to service="STBY_PHP" optional delay=720 reopen=30 and log_archive_dest_state_2 is set to ENABLE.
    I ran those troubleshooting scripts, info from standby:
    SQL> @troubleshoot
    NAME DISPLAY_VALUE
    db_file_name_convert
    db_name PHP
    db_unique_name PHP
    dg_broker_config_file1 /oracle/PHP/102_64/dbs/dr1PHP.dat
    dg_broker_config_file2 /oracle/PHP/102_64/dbs/dr2PHP.dat
    dg_broker_start FALSE
    fal_client STBY_PHP
    fal_server PHP
    local_listener
    log_archive_config
    log_archive_dest_2 service=STBY_PHP optional delay=30 reopen=30
    log_archive_dest_state_2 DEFER
    log_archive_max_processes 2
    log_file_name_convert
    remote_login_passwordfile EXCLUSIVE
    standby_archive_dest /oracle/PHP/oraarch/PHParch
    standby_file_management AUTO
    NAME DB_UNIQUE_NAME PROTECTION_MODE DATABASE_R OPEN_MODE
    PHP PHP MAXIMUM PERFORM PHYSICAL S MOUNTED
    ANCE TANDBY
    THREAD# MAX(SEQUENCE#)
    1 100149
    PROCESS STATUS THREAD# SEQUENCE#
    ARCH CONNECTED 0 0
    ARCH CONNECTED 0 0
    MRP0 WAIT_FOR_LOG 1 100150
    NAME VALUE UNIT TIME_COMPUTED
    apply finish time day(2) to second(1) interval
    apply lag day(2) to second(0) interval
    estimated startup time 8 second
    standby has been open N
    transport lag day(2) to second(0) interval
    NAME Size MB Used MB
    0 0
    On the primary, the script has froze!! How long should it take? Got as far as this:
    SQL> @troubleshoot
    NAME DISPLAY_VALUE
    db_file_name_convert
    db_name PHP
    db_unique_name PHP
    dg_broker_config_file1 /oracle/PHP/102_64/dbs/dr1PHP.dat
    dg_broker_config_file2 /oracle/PHP/102_64/dbs/dr2PHP.dat
    dg_broker_start FALSE
    fal_client STBY_R1P
    fal_server R1P
    local_listener
    log_archive_config
    log_archive_dest_2 service="STBY_PHP" optional delay=720 reopen=30
    log_archive_dest_state_2 ENABLE
    log_archive_max_processes 2
    log_file_name_convert
    remote_login_passwordfile EXCLUSIVE
    standby_archive_dest /oracle/PHP/oraarch/PHParch
    standby_file_management AUTO
    NAME DB_UNIQUE_NAME PROTECTION_MODE DATABASE_R OPEN_MODE SWITCHOVER_STATUS
    PHP PHP MAXIMUM PERFORMANCE PRIMARY READ WRITE SESSIONS ACTIVE
    THREAD# MAX(SEQUENCE#)
    1 100206
    NOW - before you say it - :) - yes, I'm aware that fal_client as STBY_R1P and fal_server as R1P are incorrect - should be PHP - but it looks like it's always been this way! Well, as least for the last 4 years where it's worked fine, as I found an old SP file and it still has R1P set in there...?!?
    Any ideas?
    Ross

  • MV Logs not getting purged in a Logical Standby Database

    We are trying to replicate a few tables in a logical standby database to another database. Both the source ( The Logical Standby) and the target database are in Oracle 11g R1.
    The materialized views are refreshed using FAST REFRESH.
    The Materialized View Logs created on the source ( the Logical Standby Database) are not getting purged when the MV in the target database is refreshed.
    We checked the entries in the following Tables: SYS.SNAP$, SYS.SLOG$, SYS.MLOG$
    When a materialized view is created on the target database, a record is not inserted into the SYS.SLOG$ table and it seems like that's why the MV Logs are not getting purged.
    Why are we using a Logical Standby Database instead of the Primary ? Because, the load on the Primary Database is too much and the machine doesn't have enough resources to support MV based replication. The CPU usage is 95% all the time. The appplication owner won't allow us to go against the Primary database.
    Do we have to do anything different in terms of Configuration/Privileges etc. because we are using a Logical Standby Database as a source ?
    Thanks in Advance.

    We have a 11g RAC database in solaris OS where there is huge gap in archive log apply.
    Thread Last Sequence Received Last Sequence Applied Difference
    1 132581 129916 2665
    2 108253 106229 2024
    3 107452 104975 2477
    The MRP0 process seems not to be working also.Almost 7000+ archives lag in standby if compared with primary database.
    i suggest you to go with Incremental rollforward backups to make it SYNC, use this below link for step by step procedure.
    http://www.oracle-ckpt.com/rman-incremental-backups-to-roll-forward-a-physical-standby-database-2/
    Here questions.
    1) Whether those archives are transported & just not applied?
    2) Is in production do you have archives or backup of archives?
    3) What you have found errors in alert log file?
    post
    SQL> select severity,message,error_code,timestamp from v$dataguard_status where dest_id=2;
    4) What errors in primary database alert log file?
    Also post
    select     ds.dest_id id
    ,     ad.status
    ,     ds.database_mode db_mode
    ,     ad.archiver type
    ,     ds.recovery_mode
    ,     ds.protection_mode
    ,     ds.standby_logfile_count "SRLs"
    ,     ds.standby_logfile_active active
    ,     ds.archived_seq#
    from     v$archive_dest_status     ds
    ,     v$archive_dest          ad
    where     ds.dest_id = ad.dest_id
    and     ad.status != 'INACTIVE'
    order by
         ds.dest_id
    /Also check errors from standby database.

Maybe you are looking for