Archive log switch

-rw-r-----   1 oracle     oinstall   13427712 May 20 02:00 o1_mf_1_90491_4341nt0b_.arc
-rw-r-----   1 oracle     oinstall   13420544 May 20 02:01 o1_mf_1_90492_4341oov9_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:02 o1_mf_1_90493_4341q45y_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:02 o1_mf_1_90494_4341qytf_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:03 o1_mf_1_90495_4341s2w8_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:03 o1_mf_1_90496_4341szog_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:04 o1_mf_1_90497_4341v16m_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:05 o1_mf_1_90498_4341wsbl_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:05 o1_mf_1_90499_4341y0ps_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:06 o1_mf_1_90500_4341yyj1_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:06 o1_mf_1_90501_4342044h_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:07 o1_mf_1_90502_434217j9_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 02:10 o1_mf_1_90503_43426g1z_.arc
-rw-r-----   1 oracle     oinstall   13424640 May 20 05:01 o1_mf_1_90504_434d70c6_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:22 o1_mf_1_90505_434fhm1b_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:23 o1_mf_1_90506_434fjrgr_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:24 o1_mf_1_90507_434fkxkf_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:24 o1_mf_1_90508_434flzfp_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:25 o1_mf_1_90509_434fnngh_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:26 o1_mf_1_90510_434fp67w_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:27 o1_mf_1_90511_434fqwks_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:28 o1_mf_1_90512_434fslyn_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:29 o1_mf_1_90513_434fvr3c_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:30 o1_mf_1_90514_434fxrsq_.arc
-rw-r-----   1 oracle     oinstall   13427712 May 20 05:31 o1_mf_1_90515_434fzr8h_.arc
-rw-r-----   1 oracle     oinstall   13438976 May 20 10:00 o1_mf_1_90516_434xrhf9_.arcmine is 10.2.0.1 database...my log switch is happening intermittently....log file size is 20 MB
log_checkpoint_interval              integer     0
log_checkpoint_timeout               integer     1800
log_checkpoints_to_alert             boolean     FALSEHow can I set to happen log file switch at every 30 Minutes...

These are two different issues.
1. There are frequent log switches so the log file size could [should] be increased.
2. However, there are, at times, gaps of 3 hours and 5 hours between two
log switches. I presume that Deepa wants to ensure that a log switch occurs
"at least every 30minutes". It may occur more frequently than that (twice a
minutes) but the maximum gap between two log switches is desired as 30minutes.
That is what ARCHIVE_LAG_TARGET does.
It is not necessary that only in Standby databases would a DBA want a
maximum duration between log switches. You might be using this in a database
(as we have in Deepa's case !) where there are long "idle" stretches of time
with very little activity as well. Say, you have a background job periodically
backing up archivelogs using OS based methods (not RMAN) -- to tape
or to an NFS mount point or an offsite storage facility. ARCHIVE_LAG_TARGET
will help you ensure that the maximum data loss is 30minutes (even if there
was only 1 transaction of 1 row in those 30minutes) because that is what
your SLA might specify. This would be part of your media recovery / DR
requirements.
log_checkpoint_timeout is not to do with archiveloging but with checkpoints.
that is a complete different requirement -- that is for instance recovery not
media recovery / backup-restore / DR requirements.

Similar Messages

  • High Commit @ Log switch

    Dear Oracle Experts,
    From Oracle EM, high commit is observed in one of our database (10g with dataguard) when it is performing a archive log switch. Currently archivelog size is 50MB and in average one log switch per hour.
    According to Oracle EM, the following SQL seems to cause the problem.
    SELECT IDX_ID FROM DR$INDEX WHERE IDX_OWNER# = :B2 AND IDX_NAME = :B1
    What could be the problem? How can I fix this?
    Thanks in advance.

    I don't know how EM generates that information.
    However, what would be happening is this :
    1. Some sessions do some significant DML (this could be the CTX_DDL.SYNC_INDEX OR could be other INSERT/UPDATE/DELETE etc operations)
    2. Many other sessions do very small but very many transactions
    3. Both types of sesssions issue COMMITs
    4. When they issue COMMITs , they wait on the 'log file sync' event (This is in the COMMIT class of events). Essentially, they are waiting for LGWR to write redo to disk (from the redo log buffer in the SGA to the redo log files on disk).
    4a. The LGWR, if it cannot write fast enough to disk, may, itself, wait on the 'log file parallel write' wait
    5. On completion of the redo writes, LGWR posts back to the sessions
    6. The sessions then proceed with the next set of operations. Now, these could be Queries.
    7. EM attempts to identify the SQLs that were waiting on 'log file sync' a short while ago. It had tracked the SIDs , now it joins to V$SQL based on HASH_VALUE+ADDRESS or based on SQL_ID.
    8. By now, the SQL_ID for the current operation of those sessions is pointing to the Queries they are running.
    9. EM now reports the SELECT as the operation that the session was doing.
    Since step 4 and step 6 are at different points in time and EM is possibly running seperate queries, it is likely to be running getting two different "images" of the operations those sessions are doing -- from two different points in time.

  • Switching database to archive log mode

    1.When I switch the database to archive log mode,
    I have to do full offline(consistent) backup.
    2.When the database is working in archive log mode
    I can do inconsistent(online) backups.
    Why is there consistent backup needed after swiching
    to archive log mode, is there not inconsistent backup
    enough after switching (the databease operates
    in archive log mode and as in point 2 I can make inconsistent backups).

    Hello,
    Oracle recommands to do offline backup after switching to archivelog as an immediate crash-recovery procedure. Look at the following example:
    1/ You switch your base to archivelog.
    2/ Work is started right away.
    3/ Your DB crashes => You got your archived redo logs, but none of the other files.
    Now, let's put a
    1b/ Backup (offline) your database.
    Now, in 3, youg got everything you need to restore the base, because 3 can happen WHILE your are ONLINE Backing up the base.
    That's the point.
    Regards,
    Yoann.

  • Switching to Archive Log Mode

    If I have an application that hooks into an Oracle 8.1.7 database running in noarchive mode, would it be transparent to that application if I were to switch oracle to archive log mode? I can't think of anything that would require configuration changes for an application that connects via Net8 but just want to be somewhat sure.
    Stu

    I agree. However, if you have a problem with the archive like archive dest running out of space, or you forgetting to turn on auto archiving, the application will hang on a log switch. But, these are not problems caused by archivelog mode itself, but rather by improper configuration/administration.

  • Switch logfile VS Archive log current

    What is the difference between this two command?
    - SQL> alter system switch logfile;
    This command switch the current log and if in ARCHIVELOG mode, it will archive it as well. Am I rite?
    SQL> alter system archive log current;
    This command DID NOT switch to another log group, remain the same log group but archive the current log? Am I rite?
    Thanks

    You're right about your first question, not for the second. Here an extract from Oracle documentation :
    CURRENT Clause
    Specify CURRENT to manually archive the current redo log file group of the specified thread, forcing a log switch. If you omit the THREAD parameter, then Oracle Database archives all redo log file groups from all enabled threads, including logs previous to current logs. You can specify CURRENT only when the database is open.
    NOSWITCH
    Specify NOSWITCH if you want to manually archive the current redo log file group without forcing a log switch. This setting is used primarily with standby databases to prevent data divergence when the primary database shuts down. Divergence implies the possibility of data loss in case of primary database failure.
    You can use the NOSWITCH clause only when your instance has the database mounted but not open. If the database is open, then this operation closes the database automatically. You must then manually shut down the database before you can reopen it.

  • Getting time when online log switches; archiver start, ends

    Hi
    I am using "Oracle Database 10g Release 10.2.0.2.0 - 64bit Production"
    Is there a possibility to check the exact time
    -when do online redo log switch
    -when does Archiver start and finish his archiving online logs
    I would like to tune archiver performance.
    Thanks for answers
    Groxy

    In my current configuration I am getting a lot of "waits" (processes waiting form commit)
    I would like to see if there is any relation of archiving process with "waits" in my application. Redo logs currently siwtch upto 6 times /hour. My ideas is to increase redo log size from 150MB to e.g 300MB and give archiver less priority, so there are no peaks, which consumes significant amount of disk I/O and the process of archiving will be spreaded.
    Groxy

  • How to switch from data guard really time apply (redo) to archive log

    Hi
    Standby database configured with broker and applying the redo in really time; however, I want to change this to archive log apply mode without losing the broker configuration. Is it possible? If it is not possible to use broker to do archive log apply, can I remove the broker and use data guard to set up the standby to use archive log apply?
    Regards

    user3076922 wrote:
    Hi
    Standby database configured with broker and applying the redo in really time; however, I want to change this to archive log apply mode without losing the broker configuration. Is it possible? If it is not possible to use broker to do archive log apply, can I remove the broker and use data guard to set up the standby to use archive log apply?
    RegardsHi
    I think mseberg is answered correct, you can use enable/disable apply log with change of state on standby database with DGMGRL, as writen mseberg.
    or you can disable recover standby database with following script from SQL*Plus.
    SQL> alter database recover managed standby database cancel;Regards
    Mahir M. Quluzade
    www.mahir-quluzade.com

  • Oracle 10g - switch off archive logs

    Hi,
    I understand in oracle 10g, the following parameter is not longer available:
    LOG_ARCHIVE_START=FALSE
    Can i confirm that for now, only way to disable archive log is to execute the following command when in mount stage:
    alter database noarchivelog;
    There's not other parameter we can specify in pfile to disable it permantely?
    thanks

    You are correct. No other parameters.

  • Is there a way to identify manual log switches?

    Hi!
    A while ago I upgraded a 10g database to 11.2.0.2 64 Bit Windows.
    During the Upgrade we realized that redo logs were configured really small (~10MB) what resulted in a lot of log switches (a few hundred per day). So we adjusted redo log size to 100MB and set archive_lag_target to 1800.
    The amount of log switches went down a little but less far than we expected it. After further analysing the situation we recognized that Oracle is switching logs far before reaching the 100MB log size (and also far before reaching 1800s). All the archived logs have a size of about 15MB. I know that 11g invented something like "preemptive log switching" that switches logs round about 20% before reaching the maximum value (if I remember it correctly..). But switching already at 15% of the maximum size seems strange to me...
    I couldn't find any helpful stuff on Google or Metalink about that topic but today I had a different idea: what if it's the application software that's doing manual log switches?
    (I have no idea why it should do that but I can remember that the application user does require the sysdba privilege - don't ask me why, I didn't write it, I won't defend it...)
    So I checked the alert log but unfortunately I had to realize that there is no difference between an automatic switch and a manual one (only alter system archive log... does get an extra line).
    So my questions are:
    1) Does anybody know a way of distinguishing between an automatic log switch and a manual one? Is there a table or another logfile where this information is recorded?
    2) Has anybody experienced a similar situation where Oracle is switching the logs way before reaching the maximum size?
    Best regards,
    Marcus

    lebigmac wrote:
    1) Does anybody know a way of distinguishing between an automatic log switch and a manual one? Is there a table or another logfile where this information is recorded?
    Off the top of my head - I think the only way to do a manual log switch is to issue "alter system switch log file", and I think that any "alter system" command is written to the alter log in you version of Oracle. (I really ought to check both statements before posting this, but I've been up since 2:30 am).
    2) Has anybody experienced a similar situation where Oracle is switching the logs way before reaching the maximum size?
    It's very common with recent versions of Oracle when private redo threads come into play; but your example seems a little exaggerated. The log file switch has to start when there is enough space left in the log file for all the public and all (or maybe it's the previously used - i'll have to check my book) private redo threads. You could check x$kcrfstrand to see what this sizes look like: http://jonathanlewis.wordpress.com/?s=private+thread
    Regards
    Jonathan Lewis

  • I have one problem with Data Guard. My archive log files are not applied.

    I have one problem with Data Guard. My archive log files are not applied. However I have received all archive log files to my physical Standby db
    I have created a Physical Standby database on Oracle 10gR2 (Windows XP professional). Primary database is on another computer.
    In Enterprise Manager on Primary database it looks ok. I get the following message “Data Guard status Normal”
    But as I wrote above ”the archive log files are not applied”
    After I created the Physical Standby database, I have also done:
    1. I connected to the Physical Standby database instance.
    CONNECT SYS/SYS@luda AS SYSDBA
    2. I started the Oracle instance at the Physical Standby database without mounting the database.
    STARTUP NOMOUNT PFILE=C:\oracle\product\10.2.0\db_1\database\initluda.ora
    3. I mounted the Physical Standby database:
    ALTER DATABASE MOUNT STANDBY DATABASE
    4. I started redo apply on Physical Standby database
    alter database recover managed standby database disconnect from session
    5. I switched the log files on Physical Standby database
    alter system switch logfile
    6. I verified the redo data was received and archived on Physical Standby database
    select sequence#, first_time, next_time from v$archived_log order by sequence#
    SEQUENCE# FIRST_TIME NEXT_TIME
    3 2006-06-27 2006-06-27
    4 2006-06-27 2006-06-27
    5 2006-06-27 2006-06-27
    6 2006-06-27 2006-06-27
    7 2006-06-27 2006-06-27
    8 2006-06-27 2006-06-27
    7. I verified the archived redo log files were applied on Physical Standby database
    select sequence#,applied from v$archived_log;
    SEQUENCE# APP
    4 NO
    3 NO
    5 NO
    6 NO
    7 NO
    8 NO
    8. on Physical Standby database
    select * from v$archive_gap;
    No rows
    9. on Physical Standby database
    SELECT MESSAGE FROM V$DATAGUARD_STATUS;
    MESSAGE
    ARC0: Archival started
    ARC1: Archival started
    ARC2: Archival started
    ARC3: Archival started
    ARC4: Archival started
    ARC5: Archival started
    ARC6: Archival started
    ARC7: Archival started
    ARC8: Archival started
    ARC9: Archival started
    ARCa: Archival started
    ARCb: Archival started
    ARCc: Archival started
    ARCd: Archival started
    ARCe: Archival started
    ARCf: Archival started
    ARCg: Archival started
    ARCh: Archival started
    ARCi: Archival started
    ARCj: Archival started
    ARCk: Archival started
    ARCl: Archival started
    ARCm: Archival started
    ARCn: Archival started
    ARCo: Archival started
    ARCp: Archival started
    ARCq: Archival started
    ARCr: Archival started
    ARCs: Archival started
    ARCt: Archival started
    ARC0: Becoming the 'no FAL' ARCH
    ARC0: Becoming the 'no SRL' ARCH
    ARC1: Becoming the heartbeat ARCH
    Attempt to start background Managed Standby Recovery process
    MRP0: Background Managed Standby Recovery process started
    Managed Standby Recovery not using Real Time Apply
    MRP0: Background Media Recovery terminated with error 1110
    MRP0: Background Media Recovery process shutdown
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[1]: Assigned to RFS process 2148
    RFS[1]: Identified database type as 'physical standby'
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[2]: Assigned to RFS process 2384
    RFS[2]: Identified database type as 'physical standby'
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[3]: Assigned to RFS process 3188
    RFS[3]: Identified database type as 'physical standby'
    Primary database is in MAXIMUM PERFORMANCE mode
    Primary database is in MAXIMUM PERFORMANCE mode
    RFS[3]: No standby redo logfiles created
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[4]: Assigned to RFS process 3168
    RFS[4]: Identified database type as 'physical standby'
    RFS[4]: No standby redo logfiles created
    Primary database is in MAXIMUM PERFORMANCE mode
    RFS[3]: No standby redo logfiles created
    10. on Physical Standby database
    SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
    PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    RFS IDLE 0 0 0 0
    RFS IDLE 0 0 0 0
    RFS IDLE 1 9 13664 2
    RFS IDLE 0 0 0 0
    10) on Primary database:
    select message from v$dataguard_status;
    MESSAGE
    ARC0: Archival started
    ARC1: Archival started
    ARC2: Archival started
    ARC3: Archival started
    ARC4: Archival started
    ARC5: Archival started
    ARC6: Archival started
    ARC7: Archival started
    ARC8: Archival started
    ARC9: Archival started
    ARCa: Archival started
    ARCb: Archival started
    ARCc: Archival started
    ARCd: Archival started
    ARCe: Archival started
    ARCf: Archival started
    ARCg: Archival started
    ARCh: Archival started
    ARCi: Archival started
    ARCj: Archival started
    ARCk: Archival started
    ARCl: Archival started
    ARCm: Archival started
    ARCn: Archival started
    ARCo: Archival started
    ARCp: Archival started
    ARCq: Archival started
    ARCr: Archival started
    ARCs: Archival started
    ARCt: Archival started
    ARCm: Becoming the 'no FAL' ARCH
    ARCm: Becoming the 'no SRL' ARCH
    ARCd: Becoming the heartbeat ARCH
    Error 1034 received logging on to the standby
    Error 1034 received logging on to the standby
    LGWR: Error 1034 creating archivelog file 'luda'
    LNS: Failed to archive log 3 thread 1 sequence 7 (1034)
    FAL[server, ARCh]: Error 1034 creating remote archivelog file 'luda'
    11)on primary db
    select name,sequence#,applied from v$archived_log;
    NAME SEQUENCE# APP
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00003_0594204176.001 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00004_0594204176.001 4 NO
    Luda 4 NO
    Luda 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00005_0594204176.001 5 NO
    Luda 5 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00006_0594204176.001 6 NO
    Luda 6 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00007_0594204176.001 7 NO
    Luda 7 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00008_0594204176.001 8 NO
    Luda 8 NO
    12) on standby db
    select name,sequence#,applied from v$archived_log;
    NAME SEQUENCE# APP
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00004_0594204176.001 4 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00003_0594204176.001 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00005_0594204176.001 5 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00006_0594204176.001 6 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00007_0594204176.001 7 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00008_0594204176.001 8 NO
    13) my init.ora files
    On standby db
    irina.__db_cache_size=79691776
    irina.__java_pool_size=4194304
    irina.__large_pool_size=4194304
    irina.__shared_pool_size=75497472
    irina.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0\admin\luda\adump'
    *.background_dump_dest='C:\oracle\product\10.2.0\admin\luda\bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\luda\luda.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0\admin\luda\cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_file_name_convert='luda','irina'
    *.db_name='irina'
    *.db_unique_name='luda'
    *.db_recovery_file_dest='C:\oracle\product\10.2.0\flash_recovery_area'
    *.db_recovery_file_dest_size=2147483648
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
    *.fal_client='luda'
    *.fal_server='irina'
    *.job_queue_processes=10
    *.log_archive_config='DG_CONFIG=(irina,luda)'
    *.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/luda/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=luda'
    *.log_archive_dest_2='SERVICE=irina LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=irina'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_state_2='ENABLE'
    *.log_archive_max_processes=30
    *.log_file_name_convert='C:/oracle/product/10.2.0/oradata/irina/','C:/oracle/product/10.2.0/oradata/luda/'
    *.open_cursors=300
    *.pga_aggregate_target=16777216
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=167772160
    *.standby_file_management='AUTO'
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0\admin\luda\udump'
    On primary db
    irina.__db_cache_size=79691776
    irina.__java_pool_size=4194304
    irina.__large_pool_size=4194304
    irina.__shared_pool_size=75497472
    irina.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0/admin/irina/adump'
    *.background_dump_dest='C:\oracle\product\10.2.0/admin/irina/bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\irina\control01.ctl','C:\oracle\product\10.2.0\oradata\irina\control02.ctl','C:\oracle\product\10.2.0\oradata\irina\control03.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0/admin/irina/cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_file_name_convert='luda','irina'
    *.db_name='irina'
    *.db_recovery_file_dest='C:\oracle\product\10.2.0/flash_recovery_area'
    *.db_recovery_file_dest_size=2147483648
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
    *.fal_client='irina'
    *.fal_server='luda'
    *.job_queue_processes=10
    *.log_archive_config='DG_CONFIG=(irina,luda)'
    *.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/irina/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=irina'
    *.log_archive_dest_2='SERVICE=luda LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=luda'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_state_2='ENABLE'
    *.log_archive_max_processes=30
    *.log_file_name_convert='C:/oracle/product/10.2.0/oradata/luda/','C:/oracle/product/10.2.0/oradata/irina/'
    *.open_cursors=300
    *.pga_aggregate_target=16777216
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=167772160
    *.standby_file_management='AUTO'
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0/admin/irina/udump'
    Please help me!!!!

    Hi,
    After several tries my redo logs are applied now. I think in my case it had to do with the tnsnames.ora. At this moment I have both database in both tnsnames.ora files using the SID and not the SERVICE_NAME.
    Now I want to use DGMGRL. Adding a configuration and a stand-by database is working fine, but when I try to enable the configuration DGMGRL gives no feedback and it looks like it is hanging. The log, although says that it succeeded.
    In another session 'show configuration' results in the following, confirming that the enable succeeded.
    DGMGRL> show configuration
    Configuration
    Name: avhtest
    Enabled: YES
    Protection Mode: MaxPerformance
    Fast-Start Failover: DISABLED
    Databases:
    avhtest - Primary database
    avhtestls53 - Physical standby database
    Current status for "avhtest":
    Warning: ORA-16610: command 'ENABLE CONFIGURATION' in progress
    It there anybody that experienced the same problem and/or knows the solution to this?
    With kind regards,
    Martin Schaap

  • How to find out which archived logs needed to recover a hot backup?

    I'm using Oracle 11gR2 (11.2.0.1.0).
    I have backed up a database when it is online using the following backup script through RMAN
    connect target /
    run {
    allocate channel d1 type disk;
    backup
    incremental level=0 cumulative
    filesperset 4
    format '/san/u01/app/backup/DB_%d_%T_%u_%c.rman'
    database
    }The backup set contains the backup of datafiles and control file. I have copied all the backup pieces to another server where I will restore/recover the database but I don't know which archived logs are needed in order to restore/recover the database to a consistent state.
    I have not deleted any archived log.
    How can I find out which archived logs are needed to recover the hot backup to a consistent state? Can this be done by querying V$BACKUP_DATAFILE and V$ARCHIVED_LOG? If yes, which columns should I query?
    Thanks for any help.

    A few ways :
    1a. Get the timestamps when the BACKUP ... DATABASE began and ended.
    1b. Review the alert.log of the database that was backed up.
    1c. From the alert.log identify the first Archivelog that was generated after the begin of the BACKUP ... DATABASE and the first Archivelog that was generated after the end of the BACKUP .. DATABASE.
    1d. These (from 1c) are the minimal Archivelogs that you need to RECOVER with. You can choose to apply additional Archivelogs that were generated at the source database to contininue to "roll-forward"
    2a. Do a RESTORE DATABASE alone.
    2b. Query V$DATAFILE on the restored database for the lowest CHECKPOINT_CHANGE# and CHECKPOINT_TIME. Also query for the highest CHECKPOINT_CHANGE# and CHECKPOINT_TIME.
    2c. Go back to the source database and query V$ARCHIVED_LOG (FIRST_CHANGE#) to identify the first Archivelog that has a higher SCN (FIRST_CHANGE#) than the lowest CHECKPOINT_CHANGE# from 2b above. Also query for the first Archivelog that has a higher SCN (FIRST_CHANGE#) than the highest CHECKPOINT_CHANGE# from 2b above.
    2d. These (from 2c) are the minimal Archivelogs that you need to RECOVER with.
    (why do you need to query V$ARCHIVED_LOG at the source ? If RESTORE a controlfile backup that was generated after the first Archivelog switch after the end of the BACKUP ... DATABASE, you would be able to query V$ARCHIVED_LOG at the restored database as well. That is why it is important to force an archivelog (log switch) after a BACKUP ... DATABASE and then backup the controlfile after this -- i.e. last. That way, the controlfile that you have restored to the new server has all the information needed).
    3. RESTORE DATABASE PREVIEW in RMAN if you have the archivelogs and subsequent controlfile in the backup itself !
    Hemant K Chitale

  • Archive logs not getting shipped when we do a swtich

    Hi Team.
    I am facing an strange issue on one of our standby.
    After the setup of the standby when we enabled the MrM mode, the archive got shipped smoothly.After after sometime when we tried to switch log file and check if it was working or not.
    From the alert log of the DR , we can only see these msg " Media Recovery Waiting for thread 1 sequence ***". But the moment we cancel the MrM mode and re enable it , its ships the same smooth.
    So need some guidance to debug the same .
    Please advise .
    Thanks

    Hello;
    On something like this I would check BOTH the Primary and Standby alert logs.
    Here's a SWITCH I forced yesterday:
    Thu Sep 12 16:01:11 2013
    ALTER SYSTEM ARCHIVE LOG
    Thu Sep 12 16:01:11 2013
    Thread 1 advanced to log sequence 811 (LGWR switch)
      Current log# 1 seq# 811 mem# 0: /u01/app/oracle/oradata/PRIMARY/redo01.log
    Thu Sep 12 16:01:11 2013
    LNS: Standby redo logfile selected for thread 1 sequence 811 for destination LOG_ARCHIVE_DEST_2
    Notice the last line is logged on the Primary almost the very moment I do the switch. Does your Database in  Primary mode show that?
    Best Regards
    mseberg

  • Standby Database (Archive Log Mode)

    I'm going to be setting up a standby database.
    I understand that the primary database must be in archive log mode.
    Is there any reason for the standby database to be in archivelog mode?

    Since your primary Db is in archive log mode, so will be your standby, when it is made primary.But. you can use STANDBY REDO LOGS from 9i version, where these Standby Redo Logs then store the information received from the Primary Database.
    As per metalink:-
    >
    Standby Redo Logs are only supported for the Physical Standby Database in Oracle 9i and as well for Logical Standby Databases in 10g. Standby Redo Logs are only used if you have the LGWR activated for archival to the Remote Standby Database.If you have Standby Redo Logs, the RFS process will write into the Standby RedoLog as mentioned above and when a log switch occurs, the Archiver Process of the Standby Database will archive this Standby Redo Log to an Archived Redo Log, while the MRP process applies the information to the Standby Database. In a Failover situation, you will also have access to the information already written in the Standby Redo Logs, so the information will not be lost.
    >
    Check metalink Doc ID: Note:219344.1
    Regards,
    Anand

  • Question about Archive Log Deletion policy

    I've a problem to understand the Archive Log Deletion policy, and I I'd like to this problem explain with the following example.
    Messages of the database are in German, but I guess you'll understand them.
    SQL> startup
    ORACLE-Instance hochgefahren.
    Total System Global Area 5344731136 bytes
    Fixed Size                  2129240 bytes
    Variable Size            2684355240 bytes
    Database Buffers         2617245696 bytes
    Redo Buffers               41000960 bytes
    Datenbank mounted.
    Datenbank geöffnet.
    SQL> archive log list
    Datenbank-Log-Modus              Archive-Modus
    Automatische Archivierung             Aktiviert
    Archivierungsziel            E:\oracle\thetis_iv\arch
    Älteste Online-Log-Sequenz     17917
    Nächste zu archivierende Log-Sequenz   17919
    Aktuelle Log-Sequenz           17919
    SQL> alter system switch logfile;
    System wurde geändert.I created a brand new archive log.
    SQL> exit
    Verbindung zu Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options beendet
    D:\OracleDB\product\11.1.0\db_1\BIN>dir E:\oracle\thetis_iv\arch
    Datenträger in Laufwerk E: ist Volume
    Volumeseriennummer: 3EBD-77E5
    Verzeichnis von E:\oracle\thetis_iv\arch
    06.04.2011  15:04    <DIR>          .
    06.04.2011  15:04    <DIR>          ..
    06.04.2011  15:04        17.137.152 ARC17919_0721667907.001
                   1 Datei(en),     17.137.152 Bytes
                   2 Verzeichnis(se), 41.073.258.496 Bytes freiand this is the only archive log in the directory. Now I start rman:
    D:\OracleDB\product\11.1.0\db_1\BIN>rman target / catalog rmanrepo@rmanrepo
    Recovery Manager: Release 11.1.0.7.0 - Production on Mi Apr 6 15:05:35 2011
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    Mit Ziel-Datenbank verbunden: ENTWIV (DBID=21045568)
    Kennwort für Recovery-Katalog-Datenbank:
    Verbindung mit Datenbank des Recovery-Katalogs
    RMAN> show all;
    RMAN-Konfigurationsparameter für Datenbank mit db_unique_name ENTWIV sind:
    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
    CONFIGURE BACKUP OPTIMIZATION ON;
    CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
    CONFIGURE CONTROLFILE AUTOBACKUP OFF;
    CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'E:\oracle\thetis_iv\backup\CF_%F_ENTWIV.ORA';
    CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
    CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
    CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
    CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
    CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
    CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  'ENV=(TPDO_OPTFILE=D:\Services\Tivoli\TSM\AgentOBA64\tpdo.opt)';
    CONFIGURE MAXSETSIZE TO UNLIMITED; # default
    CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
    CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
    CONFIGURE COMPRESSION ALGORITHM 'BZIP2'; # default
    CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO 'SBT_TAPE';
    CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'D:\ORACLEDB\PRODUCT\11.1.0\DB_1\DATABASE\SNCFENTWIV.ORA'; # defaultThe archive log deletion policy says the the logfiles have to be backed up for two times before they get deleted.
    Now I backup all archive logs, that havn't been backed up for at least two times.
    RMAN> run { backup archivelog all not backed up 2 times
    2>       format '%d_AR_%Y%M%D_%s_%t'
    3>       tag 'ARCHIVE LOGS'
    4>       DELETE ALL INPUT;
    5>     }
    Starten backup um 06.04.2011 15:08:01
    Aktuelles Log archiviert
    Zugewiesener Kanal: ORA_SBT_TAPE_1
    Kanal ORA_SBT_TAPE_1: SID=253 Device-Typ=SBT_TAPE
    Kanal ORA_SBT_TAPE_1: Data Protection for Oracle: version 5.5.1.0
    Kanal ORA_SBT_TAPE_1: Backup Set für Archive Log wird begonnen
    Kanal ORA_SBT_TAPE_1: Archive Logs in Backup Set werden angegeben
    Eingabe-Archive-Log-Thread=1 Sequence=17919 RECID=147 STAMP=747759899
    Eingabe-Archive-Log-Thread=1 Sequence=17920 RECID=148 STAMP=747760081
    Kanal ORA_SBT_TAPE_1: Piece 1 wird auf 06.04.2011 15:08:02 begonnen
    Kanal ORA_SBT_TAPE_1: Piece 1 auf 06.04.2011 15:08:09 beendet
    Piece Handle=ENTWIV_AR_20110406_23_747760082 Tag=ARCHIVE LOGS Kommentar=API Version 2.0,MMS Version 5.5.1.0
    Kanal ORA_SBT_TAPE_1: Backup Set vollstõndig, abgelaufene Zeit: 00:00:08
    Kanal ORA_SBT_TAPE_1: Archive Logs werden gel÷scht
    Archive Log-Dateiname=E:\ORACLE\THETIS_IV\ARCH\ARC17919_0721667907.001 RECID=147 STAMP=747759899
    Archive Log-Dateiname=E:\ORACLE\THETIS_IV\ARCH\ARC17920_0721667907.001 RECID=148 STAMP=747760081
    Beendet backup um 06.04.2011 15:08:10
    RMAN> exit
    Recovery Manager abgeschlossen.
    D:\OracleDB\product\11.1.0\db_1\BIN> dir E:\oracle\thetis_iv\arch
    Datenträger in Laufwerk E: ist Volume
    Volumeseriennummer: 3EBD-77E5
    Verzeichnis von E:\oracle\thetis_iv\arch
    06.04.2011  15:08    <DIR>          .
    06.04.2011  15:08    <DIR>          ..
                   0 Datei(en),              0 Bytes
                   2 Verzeichnis(se), 41.090.396.160 Bytes freirman deleted all archive logs, even I they are on tape only once by now.
    Thats not what I expected. Where is my mistake?

    Hi,
    I do new tests it's very strange.
    BACKUP ARCHIVELOG command is not obeying the policy of archivelog.
    You can open a SR on MOS. (to check bugs)
    I reproduce the same test and the result was the same, it seems that this is a bug.
    CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;
    RMAN> backup archivelog all not backed up 2 times delete all input;
    Starting backup at 06-APR-11
    current log archived
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting archived log backup set
    channel ORA_DISK_1: specifying archived log(s) in backup set
    input archived log thread=1 sequence=15 RECID=16 STAMP=747753711
    input archived log thread=2 sequence=20 RECID=17 STAMP=747753714
    input archived log thread=1 sequence=16 RECID=19 STAMP=747753729
    input archived log thread=2 sequence=21 RECID=18 STAMP=747753729
    channel ORA_DISK_1: starting piece 1 at 06-APR-11
    channel ORA_DISK_1: finished piece 1 at 06-APR-11
    piece handle=+DATA/orcl/backupset/2011_04_06/annnf0_tag20110406t132210_0.304.747753731 tag=TAG20110406T132210 comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
    channel ORA_DISK_1: deleting archived log(s)
    archived log file name=+DATA/orcl/archivelog/2011_04_06/thread_1_seq_15.293.747753711 RECID=16 STAMP=747753711
    archived log file name=+DATA/orcl/archivelog/2011_04_06/thread_2_seq_20.295.747753715 RECID=17 STAMP=747753714
    archived log file name=+DATA/orcl/archivelog/2011_04_06/thread_1_seq_16.294.747753729 RECID=19 STAMP=747753729
    archived log file name=+DATA/orcl/archivelog/2011_04_06/thread_2_seq_21.298.747753729 RECID=18 STAMP=747753729
    Finished backup at 06-APR-11
    RMAN> list archivelog all;
    specification does not match any archived log in the repositoryOracle Docs Says:
    The BACKUP ARCHIVELOG ... DELETE INPUT command deletes archived log files after they are backed up.
    This command eliminates the separate step of manually deleting archived redo logs.
    With DELETE INPUT, RMAN deletes only the specific copy of the archived log chosen for the backup set.
    With DELETE ALL INPUT, RMAN deletes each backed-up archived redo log file from all log archiving destinations.
    As explained in "Configuring an Archived Redo Log Deletion Policy",
    the BACKUP ... DELETE INPUT and DELETE ARCHIVELOG commands obey the archived redo log deletion policy
    for logs in all archiving locations. For example, if you specify that logs should only be deleted when backed
    up at least twice to tape, then BACKUP ... DELETE honors this policy.http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmbckba.htm#BRADV89524
    But in ours case it's not honors this policy.
    Only with the FORCE command should this happen. But it is not our case.
    Oracle Docs:
    If FORCE is not specified on the deletion commands,
    then these deletion commands obey the archived log deletion policy.
    If FORCE is specified, then the deletion commands ignore the archived log deletion policy.http://download.oracle.com/docs/cd/E11882_01/backup.112/e10643/rcmsynta010.htm#RCMRF113
    Alternatively you can do the following:
    Set the commands separately.
    Check this:
    RMAN>  run {
    2> backup archivelog all not backed up 2 times ;
    3> delete archivelog all backed up 2 times to disk;
    4> }
    Starting backup at 06-APR-11
    current log archived
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting archived log backup set
    channel ORA_DISK_1: specifying archived log(s) in backup set
    input archived log thread=2 sequence=22 RECID=21 STAMP=747755128
    input archived log thread=1 sequence=17 RECID=20 STAMP=747755127
    channel ORA_DISK_1: starting piece 1 at 06-APR-11
    channel ORA_DISK_1: finished piece 1 at 06-APR-11
    piece handle=+DATA/orcl/backupset/2011_04_06/annnf0_tag20110406t134528_0.295.747755129 tag=TAG20110406T134528 comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
    Finished backup at 06-APR-11
    released channel: ORA_DISK_1
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=78 instance=orcl1 device type=DISK
    RMAN-08138: WARNING: archived log not deleted - must create more backups
    archived log file name=+DATA/orcl/archivelog/2011_04_06/thread_1_seq_17.298.747755127 thread=1 sequence=17
    RMAN-08138: WARNING: archived log not deleted - must create more backups
    archived log file name=+DATA/orcl/archivelog/2011_04_06/thread_2_seq_22.294.747755129 thread=2 sequence=22
    RMAN>Edited by: Levi Pereira on Apr 6, 2011 1:35 PM

  • Archive log mode in oracle 10g on windows environment

    Hi All,
    I have a production database (Oracle 10g 10.2.0.1.0) on windows 2003 server. yesterday i put the database into archivelog mode. when i query for spfile location it is shown in ORACLE_HOME\dbs location.
    but when i created pfile using the spfile it is created at ORACLE_HOME\database location. and there is another spfile also. i set the log_archive_dest at a location other than flash_recovery_area in pfile, but it is showing the DB_RECOVER_AREA.
    today i seen archives are creating in both locations.
    can a database have two spfiles. and working on them ?
    can i remove a spfile in /dbs location.
    pls. give me suggestion to rectify this
    thanks and regards.

    Salman Qureshi wrote:
    Hi,
    On windows platform, spfile and initfiles are by default created under ORACLE_HOME\database directory and this is also the default location, so, your spfile or initfile in this directory are actually in use.
    i set the log_archive_dest at a location other than flash_recovery_area in pfile, but it is showing the DB_RECOVER_AREA. You need to unset the "db_recovery_file_dest" parameter first.
    alter system set db_recovery_file_dest='';Now set your log_archive_dest as follows
    alter system set log_archive_dest_1="location=your_location";Don't user older "log_archive_dest" parameter
    SalmanYour assertion that "You need to unset the "db_recovery_file_dest" parameter first." is patently false.
    DB_RECOVERY_FILE_DEST is used for more than just archivelogs. Setting LOG_ARCHIVE_DEST_n to a location other than USE_DB_RECOVERY_FILE_DEST even while DB_RECOVERY_FILE_DEST is set is perfectly acceptable. In fact it is required if you want to continue to use the FRA for things other than archivelogs. Things, like - oh, say - backups!
    =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2011.02.15 07:42:18 =~=~=~=~=~=~=~=~=~=~=~=
    login as: oracle
    oracle@vmlnx01's password:
    Last login: Tue Feb 15 07:01:51 2011 from 192.168.160.1
    [oracle@vmlnx01 ~]$ sqlplus / as sysdbaFirst, note the date and time of logon, to compare to archivelog timestamps later ...
    SQL*Plus: Release 10.2.0.4.0 - Production on Tue Feb 15 07:42:27 2011
    Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing optionsNext, note the values for the log_archive_dest_n parameters. Actually, the value for #10 is the default if no log_arch_dest_n parms are set, but I like to set it explicitly to avoid ambiguity.
    SQL> show parameter log_archive_dest_
    NAME     TYPE VALUE
    log_archive_dest_1     string
    log_archive_dest_10     string LOCATION=USE_DB_RECOVERY_FILE_
    DEST
    log_archive_dest_2     string
    log_archive_dest_3     string
    log_archive_dest_4     string
    log_archive_dest_5     string
    log_archive_dest_6     string
    log_archive_dest_7     string
    log_archive_dest_8     string
    log_archive_dest_9     string
    NAME     TYPE VALUE
    log_archive_dest_state_1     string enable
    log_archive_dest_state_10     string enable
    log_archive_dest_state_2     string enable
    log_archive_dest_state_3     string enable
    log_archive_dest_state_4     string enable
    log_archive_dest_state_5     string enable
    log_archive_dest_state_6     string enable
    log_archive_dest_state_7     string enable
    log_archive_dest_state_8     string enable
    log_archive_dest_state_9     string enableAnd note the setting for db_recovery_file_dest ...
    SQL> show parameter db_recovery_file_dest
    NAME     TYPE VALUE
    db_recovery_file_dest     string /orafra
    db_recovery_file_dest_size     big integer 4GNow lets check what's in the recovery dest. Notice there is no directory timestamped today (15 Feb), so no archivelogs have been generated for today.
    SQL> !ls -l /orafra/VLNXORA1/archivelog
    total 28
    drwxr-x--- 2 oracle oinstall 4096 Feb 11 17:53 2011_02_08
    drwxr-x--- 2 oracle oinstall 4096 Feb 11 17:53 2011_02_09
    drwxr-x--- 2 oracle oinstall 4096 Feb 11 17:53 2011_02_10
    drwxr-x--- 2 oracle oinstall 4096 Feb 11 17:53 2011_02_11
    drwxr-x--- 2 oracle oinstall 4096 Feb 12 06:00 2011_02_12
    drwxr-x--- 2 oracle oinstall 4096 Feb 13 11:00 2011_02_13
    drwxr-x--- 2 oracle oinstall 4096 Feb 14 22:00 2011_02_14So lets force a log switch and check the results
    SQL> alter system switch logfile;
    System altered.
    SQL> !ls -l /orafra/VLNXORA1/archivelog
    total 32
    drwxr-x--- 2 oracle oinstall 4096 Feb 11 17:53 2011_02_08
    drwxr-x--- 2 oracle oinstall 4096 Feb 11 17:53 2011_02_09
    drwxr-x--- 2 oracle oinstall 4096 Feb 11 17:53 2011_02_10
    drwxr-x--- 2 oracle oinstall 4096 Feb 11 17:53 2011_02_11
    drwxr-x--- 2 oracle oinstall 4096 Feb 12 06:00 2011_02_12
    drwxr-x--- 2 oracle oinstall 4096 Feb 13 11:00 2011_02_13
    drwxr-x--- 2 oracle oinstall 4096 Feb 14 22:00 2011_02_14
    drwxr-x--- 2 oracle oinstall 4096 Feb 15 07:43 2011_02_15
    SQL> !ls -l /orafra/VLNXORA1/archivelog/2011_02_15
    total 1892
    -rw-r----- 1 oracle oinstall 1931776 Feb 15 07:43 o1_mf_1_82_6oo0qomc_.arcSo we see that, as expected, the archivelog was written to the FRA. Note the log sequence # of 82
    Also, let's check my "alternate" location, as yet undefinded to the db ..
    SQL> !ls -l /oraarch/vlnxora1
    total 0No files there.
    Now we will change the archivelog destination. Note that I am NOT touching the FRA definition
    SQL> alter system set log_archive_dest_1='location=/oraarch/vlnxora1' scope=both;
    System altered.
    SQL> alter system set log_archive_dest_10 = '' SCOPE=both;
    System altered.
    SQL> show parameter log_archive_dest_
    NAME     TYPE VALUE
    log_archive_dest_1     string location=/oraarch/vlnxora1
    log_archive_dest_10     string
    log_archive_dest_2     string
    log_archive_dest_3     string
    log_archive_dest_4     string
    log_archive_dest_5     string
    log_archive_dest_6     string
    log_archive_dest_7     string
    log_archive_dest_8     string
    log_archive_dest_9     string
    log_archive_dest_state_1     string enable
    NAME     TYPE VALUE
    log_archive_dest_state_10     string enable
    log_archive_dest_state_2     string enable
    log_archive_dest_state_3     string enable
    log_archive_dest_state_4     string enable
    log_archive_dest_state_5     string enable
    log_archive_dest_state_6     string enable
    log_archive_dest_state_7     string enable
    log_archive_dest_state_8     string enable
    log_archive_dest_state_9     string enable
    SQL> show parameter db_recovery_file_dest
    NAME     TYPE VALUE
    db_recovery_file_dest     string /orafra
    db_recovery_file_dest_size     big integer 4GSo, above we see that I do not have an archivelog destination set to the FRA, but the FRA is still set. I did not unset it, as you asserted was necessary. I still want my backups to go there.
    Next we'll do another log switch and check the results.
    SQL> alter system switch logfile;
    System altered.First, we'll check the (now unused) FRA destination. Notice that there is still just the one archivelog, sequence 82.
    SQL> !ls -l /orafra/VLNXORA1/archivelog/2011_02_15
    total 1892
    -rw-r----- 1 oracle oinstall 1931776 Feb 15 07:43 o1_mf_1_82_6oo0qomc_.arcNow check the new, non-fra destination. Notice that it now has an archivelog, sequence 83
    SQL> !ls -l /oraarch/vlnxora1
    total 96
    -rw-r----- 1 oracle oinstall 92160 Feb 15 07:45 1_83_732127364.dbf
    SQL> exit
    Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    [oracle@vmlnx01 ~]$ exit
    logout

Maybe you are looking for