Archived log destination

Hi,
In init.ora file,the archive destination is "oracle_home/database/archive" but all archived logs are placed in "oracle_home/rdbms/". why it is stored in that place, please tell me.
Thanks,
Venkat P.

venkat P. wrote:
Hi,
In init.ora file,the archive destination is "oracle_home/database/archive" but all archived logs are placed in "oracle_home/rdbms/". why it is stored in that place, please tell me.What's Your db version?
Is spfile or pfile is in use?
sqlplus> show parameter spfile;
If spfile is in use and You looked into init.ora, then of course You could observe difference in archive log destinations.
Are several archive_log destinations set and are they enebled?
sqlplus> show parameter log_archive_dest;
sqlplus> show parameter log_archive_dest_state;

Similar Messages

  • Primary/standby and 3rd archive log destination?

    Running Oracle EE 10.2.0.4 linux 64 bit. I have a primary and standby configuration using data guard, with appropriate LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2 for the primary and standby - all works as expected. I want to multiplex the log files by adding a 3rd archive log destination to a different disk. I'm not clear on whether or not specifying a second 'primary' archive destination will write to both dest_1 and dest_3 or just alternate between the 2? I want to make sure that both DEST_1 and DEST_3 are written to (there can be a lag for DEST_3) -
    Is the following all I need or are there additional parameters to LOG_ARCHIVE_DEST_n I'm missing?
    LOG_ARCHIVE_DEST_3 = 'valid_for=(ONLINE_LOGFILE,ALL_ROLES)', 'location="/myThirdLoc"'
    Thanks -

    The database hang because of the redo log file is full. my test database is 16.7G and I gave the recovery filesystem 19 G for the redo log. Apparently it is not enough. After i set up the backup with daily incremental and run for 5 days, the recovery is full and db hang. How do you free up the space or set up the backup so that it can recycle the space? My DB is 10g r2 on RHEL3.

  • Standby database Archive log destination confusion

    Hi All,
    I need your help here..
    This is the first time that this situation is arising. We had sync issues in the oracle 10g standby database prior to this archive log destination confusion.So we rebuilt the standby to overcome this sync issue. But ever since then the archive logs in the standby database are moving to two different locations.
    The spfile entries are provided below:
    *.log_archive_dest_1='LOCATION=/m99/oradata/MARDB/archive/'
    *.standby_archive_dest='/m99/oradata/MARDB/standby'
    Prior to rebuilding the standby databases the archive logs were moving to /m99/oradata/MARDB/archive/ location which is the correct location. But now the archive logs are moving to both /m99/oradata/MARDB/archive/ and /m99/oradata/MARDB/standby location, with the majority of them moving to /m99/oradata/MARDB/standby location. This is pretty unusual.
    The archives in the production are moving to /m99/oradata/MARDB/archive/ location itself.
    Could you kindly help me overcome this issue.
    Regards,
    Dan

    Hi Anurag,
    Thank you for update.
    Prior to rebuilding the standby database the standby_archive_dest was set as it is. No modifications were made to the archive destination locations.
    The primary and standby databases are on different servers and dataguard is used to transfer the files.
    I wanted to highlight one more point here, The archive locations are similar to the ones i mentioned for the other stndby databases. But the archive logs are moving only to /archive location and not to the /standby location.

  • Archive log destinations

    We have a database with log_archive_dest1 set to /disk1... OPTIONAL and log_archive_dest1 set to db_recovery_file_dest. If log write fails to dest1 which is optional then the database continues to write to the db_recovery_file_dest since location one is optional.
    My question is will the opposite be true: If db_recovery_file_dest is full (and the only thing going there is archive logs, will the database still archive to dest1 withoug halting the database until space is made available at the db_recovery_file_dest location?

    No. The answer is no (unfortunately).
    What is your LOG_ARCHIVE_MIN_SUCCEED_DEST set to?
    If you want to prevent the database from stopping when you have this problem of filling up your primary destination, you can have multiple destinations and set your min succeed dest to a higher number than 1. Then, it will use another destination if the primary fills up.
    Reference (good article):
    =================
    http://download-west.oracle.com/docs/cd/A81042_01/DOC/server.816/a76957/miginito.htm
    The first destination, the standby destination, and either of the backup destinations are mandatory (minimum succeed destination count is 3).
    With these assumptions, issue the following SQL statements to change your old archive log destination parameters to the new ones:
    ALTER SYSTEM SET LOG_ARCHIVE_MIN_SUCCEED_DEST = 1;
    ALTER SYSTEM SET LOG_ARCHIVE_DUPLEX_DEST = ' ';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST = ' ';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1 = 'enable';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = 'enable';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3 = 'enable';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4 = 'enable';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION=/oracle/dbs/arclog MANDATORY';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=stndby1 MANDATORY';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_3 = 'LOCATION=/backup/dbs/arclog OPTIONAL';
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_4 = 'LOCATION=/backup2/dbs/arclog OPTIONAL';
    ALTER SYSTEM SET LOG_ARCHIVE_MIN_SUCCEED_DEST = 3;
    Edited by: ji li on Oct 16, 2009 10:29 AM

  • Changing the location of archive log from flash recovery area PLZ HELP!!!

    Hi All,
    My archive log is being stored in flash memory area which got full and the production server went down.
    alert log file details.....
    ORA-19809: limit exceeded for recovery files
    ORA-19804: cannot reclaim 43432960 bytes disk space from 2147483648 limit
    *** 2010-04-25 14:22:49.777 62692 kcrr.c
    ARCH: Error 19809 Creating archive log file to
    '/oracle/product/10.2.0/flash_rec
    overy_area/EDWREP/archivelog/2010_04_25/o1_mf_1_232_%u_.arc'
    *** 2010-04-25 14:22:49.777 60970 kcrr.c
    kcrrfail: dest:10 err:19809 force:0 blast:1I removed the files and started the database,
    Can someone kindly tell me as to how to avoid this problem in future by keeping archive log destination in flash recovery area.
    I want to change the location of archive log files, can someone please guide me as to hiow to do that
    I changed the size of flash recovery area for the time being, but i am afraid it will be full again!!
    SQL> select * from v$flash_recovery_area_usage;
    FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
    CONTROLFILE                   0                         0               0
    ONLINELOG                     0                         0               0
    ARCHIVELOG                99.44                         0              57
    BACKUPPIECE                   0                         0               0
    IMAGECOPY                     0                         0               0
    FLASHBACKLOG                  0                         0               0
    6 rows selected.
    SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE = 4G ;
    System altered.
    SQL> select * from v$flash_recovery_area_usage;
    FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
    CONTROLFILE                   0                         0               0
    ONLINELOG                     0                         0               0
    ARCHIVELOG                49.72                         0              57
    BACKUPPIECE                   0                         0               0
    IMAGECOPY                     0                         0               0
    FLASHBACKLOG                  0                         0               0
    6 rows selected.regards,
    Edited by: user10243788 on Apr 25, 2010 6:12 AM

    user10243788 wrote:
    Hi All,
    My archive log is being stored in flash memory area which got full and the production server went down.
    alert log file details.....
    ORA-19809: limit exceeded for recovery files
    ORA-19804: cannot reclaim 43432960 bytes disk space from 2147483648 limit
    *** 2010-04-25 14:22:49.777 62692 kcrr.c
    ARCH: Error 19809 Creating archive log file to
    '/oracle/product/10.2.0/flash_rec
    overy_area/EDWREP/archivelog/2010_04_25/o1_mf_1_232_%u_.arc'
    *** 2010-04-25 14:22:49.777 60970 kcrr.c
    kcrrfail: dest:10 err:19809 force:0 blast:1I removed the files and started the database,
    Can someone kindly tell me as to how to avoid this problem in future by keeping archive log destination in flash recovery area.
    I want to change the location of archive log files, can someone please guide me as to hiow to do that
    I changed the size of flash recovery area for the time being, but i am afraid it will be full again!!
    SQL> select * from v$flash_recovery_area_usage;
    FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
    CONTROLFILE                   0                         0               0
    ONLINELOG                     0                         0               0
    ARCHIVELOG                99.44                         0              57
    BACKUPPIECE                   0                         0               0
    IMAGECOPY                     0                         0               0
    FLASHBACKLOG                  0                         0               0
    6 rows selected.
    SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE = 4G ;
    System altered.
    SQL> select * from v$flash_recovery_area_usage;
    FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
    CONTROLFILE                   0                         0               0
    ONLINELOG                     0                         0               0
    ARCHIVELOG                49.72                         0              57
    BACKUPPIECE                   0                         0               0
    IMAGECOPY                     0                         0               0
    FLASHBACKLOG                  0                         0               0
    6 rows selected.regards,
    Edited by: user10243788 on Apr 25, 2010 6:12 AMPointing the archive log dest (and/or the FRA) to a new location, or enlarging them, will do no good if you are not performing regular housekeeping on the archivelogs. You will just keep knocking down the same problem over and over.
    If you simply delete the archivelogs at the OS level, the database will never know about it and it will continue to think the destination is full, based on records kept in the control file.
    For regular housekeeping, you need to be doing something similar to this in rman:
    run {
      backup archivelog all not backed up 1 times tag='bkup_vlnxora1_arch';
      delete noprompt archivelog all backed up 1 times to device type disk;
    run {
    delete noprompt obsolete;
    crosscheck archivelog all;
    delete noprompt expired archivelog all;

  • Duplexing the Archive Log - is there a potential performance hit

    Good Afternoon Oracle People -
    I apologize if this question is silly or out of place.
    Basically, we are looking at options for implementing a (cheap) DR solution for our Oracle Database.
    Bottom line objective is to have a second copy of our production system (not running, offline) with a usable archive log to recover from at a remote site with a similar set of disk technologies etc. 
    The sites are linked by 100MBPs link - so any access to secondary site is relatively fast.
    What I was thinking of doing is creating an iSCSI target on the destination SAN and adding this as a disk into the production database.  Then, I was going to go in and define a duplex archive log destination to this iSCSI target.
    My fear is that if the archiver waits for the write to the destination, I would imagine that this would slow down database access.  Is this a valid concern?  Or does Oracle treat the Duplex as a replicated (slower) copy?
    Again, sorry if this question is stupid - i have tried the google machine but couldn't find anything, and it isn't all that clear from the documentation. 
    Kind Regards,
    Aleksei

    Or does Oracle treat the Duplex as a replicated (slower) copy?
    Oracle treats it in a way you tell Oracle to treat it – please take a look at LOG_ARCHIVE_DEST_n parameters such as MANDATORY and OPTIONAL, MAX_FAILURE, etc
    There are two major things to consider:
    ->Is the throughput of the destination enough to handle max archive log generation?
    You need to take a look at the size of archive logs and how frequently they are
    generated during peak load.
    ->What happens when the destination is not available?
    HTH,
    Iordan Iotzov

  • Removing archived log files

    Hello all,
    Using Oracle 10g R2 ( 10.2.4.0) under UNIX Sun Solaris 10 , I have two rman backup types
    1-L0 backup
    2-L1 Backup ( Incremental cummulative)
    Facts:
    -Due to space pressure on archived log destination I'm trying to get less archived files possible under the archived log fs thus at any given time the archived log files destination contains archived log files aged no more than 22hours.
    * The backup runs each day at 4PM and there is custom script that remove and compressed archived log files ( out of backup jobs windows) from midnight until 3:45PM
    * From the above removal schedule task L0 or L1 backup will always have 24 hours worth of archived log files available during the backup.
    -The Backup files Windows retention period is 22 hours meaning that each backup type L0 or L1 removes previous backup files aged more than 22hours.
    -Tracking file is enabled
    Target:
    Knowing that our backup retention windows is 22hours.
    Our next goal is to get less than 2 hours from 24 hours of archived log files available when L0 or L1 backup.
    Would this affect L1 backup? and how?
    Thank in advance for your response
    Alex

    user8979607 wrote:
    Hello all,
    Using Oracle 10g R2 ( 10.2.4.0) under UNIX Sun Solaris 10 , I have two rman backup types
    1-L0 backup
    2-L1 Backup ( Incremental cummulative)
    Facts:
    -Due to space pressure on archived log destination I'm trying to get less archived files possible under the archived log fs thus at any given time the archived log files destination contains archived log files aged no more than 22hours.
    * The backup runs each day at 4PM and there is custom script that remove and compressed archived log files ( out of backup jobs windows) from midnight until 3:45PM
    * From the above removal schedule task L0 or L1 backup will always have 24 hours worth of archived log files available during the backup.
    -The Backup files Windows retention period is 22 hours meaning that each backup type L0 or L1 removes previous backup files aged more than 22hours.
    -Tracking file is enabled
    Target:
    Knowing that our backup retention windows is 22hours.
    Our next goal is to get less than 2 hours from 24 hours of archived log files available when L0 or L1 backup.
    Would this affect L1 backup? and how?
    Thank in advance for your response
    AlexI'm not sure what you are talking about with Backup files Windows retention period ... 22 hours".
    I don't know what you mean by "Our next goal is to get less than 2 hours from 24 hours of archived log files available when L0 or L1 backup."
    If you are not taking your database backups with rman you are on shaky ground. The principles are simple. To recover your database from a failure, you will need to start with an L0 backup. The rman RESTORE command will then restore individual blocks from any applicable and available L1 backups. You would follow that with a RECOVER command, that would attempt to apply all necessary redo from available archivelogs. If the necessary archivelogs have been deleted, rman will attempt to restore them from a backup. You can use rman to backup AND DELETE archivelog files to keep the archivelog destination cleaned out.
    I take an L0 backup once a week, an L1 the other 6 days, and archivelogs twice a day. The only time I've had a problem with the archivelog dest filling up is when some buggy code that has a loop goes into production and starts flooding redo.
    Exactly how are you taking your database backups? If you are not using rman, then you are already on shaky ground.

  • RMAN-08591: WARNING: invalid archived log deletion policy

    Hi,
    My database is 11.2.0.1 running on OEL 5.
    We have stndby database running on other server, i have configured rman like this
    CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
    But while running db backup, getting the error
    RMAN-08591: WARNING: invalid archived log deletion policy.
    RMAN retention policy is set to redundancy 1.
    The archive files are deleting even though they are not applied on standby.
    Thanks,

    kkrm333 wrote:
    Hi,
    My database is 11.2.0.1 running on OEL 5.
    We have stndby database running on other server, i have configured rman like this
    CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
    But while running db backup, getting the error
    RMAN-08591: WARNING: invalid archived log deletion policy.
    RMAN retention policy is set to redundancy 1.
    The archive files are deleting even though they are not applied on standby.
    Thanks,
    bcm@bcm-laptop:~$ oerr rman 8591
    8591, 3, "WARNING: invalid archived log deletion policy"
    // *Cause: An invalid ARCHIVELOG DELETION POLICY was supplied. The archived
    //         log deletion policy was APPLIED but there was no mandatory
    //         archived log destinations.
    // *Action: One of the following:
    //          1) Change archived log deletion policy using CONFIGURE command
    //          2) Make one or more of standby destination as MANDATORY.

  • Archive log

    Hi,
    I am executing some script in AIX for Oracle.
    I need to find out the name of all the archived log files from v$archived_log which has been created last one hours.
    Regards,
    Indraneel

    conn / as sysdba
    archive log list
    exit
    cd <archived log destination>
    find . -ctime 1 -print
    this will print all the files in that directory that was created 1 hour before.

  • Two copies archive logs with only one defined

    Hi,
    On a 11g database, I have only got flash_recovery_area defined. When switched into archive log mode, I have expected only one copy of archive logs produced in the defined USE_DB_RECOVERY_FILE_DEST location, but there is another copy generated as well under $ORACLE_HOME/dbs directory. How to explain that? and how to DISABLE the second copy to be produced?
    Thanks for any help
    Zhuang Li
    PS: more info
    In spfile:
    orcl.__java_pool_size=50331648
    orcl.__large_pool_size=16777216
    orcl.__oracle_base='/usr/oracle11g'#ORACLE_BASE set from environment
    orcl.__pga_aggregate_target=1828716544
    orcl.__sga_target=1056964608
    orcl.__shared_io_pool_size=0
    orcl.__shared_pool_size=654311424
    orcl.__streams_pool_size=0
    *.audit_file_dest='/usr/oracle11g/admin/orcl/adump'
    *.audit_trail='db'
    *.compatible='11.1.0.0.0'
    *.control_file_record_keep_time=30
    *.control_files='/db/orcl1/control0^@^@C^AC"^@^@^@^@^@^C^@^@^@^@^@^@^A^D{^S^@^@1.ctl','/db/orcl1/control02.ctl',
    '/db/orcl1/control03.ctl'
    *.db_block_size=8192
    *.db_domain=''
    *.db_name='orcl'
    *.db_recovery_file_dest='/usr/oracle11g/flash_recovery_area'
    *.db_recovery_file_dest_size=6442450944
    *.diagnostic_dest='/usr/oracle11g'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
    *.job_queue_processes=5
    *.open_cursors=300
    *.pga_aggregate_target=1824522240
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_max_size=1258291200#internally adjusted
    *.sga_target^@^@C^AC"^@^@^@^@^@^D^@^@^@^@^@^@^A^DCS^@^@=1056964608
    *.undo_tablespace='UNDOTBS1'
    ==============================
    SQL> select destination from V$ARCHIVE_DEST;
    DESTINATION
    /usr/oracle11g/R1/dbs/arch
    USE_DB_RECOVERY_FILE_DEST
    10 rows selected.
    SQL> SQL> archive log lis
    SP2-0718: illegal ARCHIVE LOG option
    SQL> archive log list
    Database log mode Archive Mode
    Automatic archival Enabled
    Archive destination USE_DB_RECOVERY_FILE_DEST
    Oldest online log sequence 2549
    Next log sequence to archive 2551
    Current log sequence 2551
    SQL>
    ===================
    SQL> show parameter archive
    NAME TYPE VALUE
    archive_lag_target integer 0
    log_archive_config string
    log_archive_dest string
    log_archive_dest_1 string
    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
    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
    log_archive_duplex_dest string
    log_archive_format string %t_%s_%r.dbf
    log_archive_local_first boolean TRUE
    log_archive_max_processes integer 4
    log_archive_min_succeed_dest integer 1
    log_archive_start boolean FALSE
    log_archive_trace integer 0
    standby_archive_dest string ?/dbs/arch

    This is the way 11g install sets up the archive destination intially after creating the database using DBA.
    What you can do is to go to the Recovery Settings in Enterprise Manager. You would notice that Archive Log Destination number 1 is set to usr/oracle11g/R1/dbs/arch while number 10 is set to USE_DB_RECOVERY_FILE_DEST
    Remove the entry for Number 1 (leave it blank). Apply the settings. This will force Oracle to only log to flash_recovery_area.
    <br>
    Oracle Database FAQs
    </br>

  • RMAN-20242: specification does not match any archive log in the recovery ca

    Hi,
    I'm working with an 9i Oracle RAC (yes, I know this version is out of support...). I'm launching my backup from node 1 with this script
    run {
    sql 'alter system switch logfile'
    sql 'alter system archive log current'
    allocate channel TSM1 type 'sbt_tape' connect *
    parms='ENV=(TDPO_OPTFILE=/home/adsmadm/rman_INF01T01/opt/tdpo.opt)'
    allocate channel TSM2 type 'sbt_tape' connect *
    parms='ENV=(TDPO_OPTFILE=/home/adsmadm/rman_INF01T01/opt/tdpo.opt)'
    backup
    format 'brman_arch_%s_%p'
    (archivelog like '/logs/bbdd/oracle/INF01T01/archiver/%' channel TSM1 delete input )
    (archivelog like '/logs/bbdd/oracle/INF01T03/archiver/%' channel TSM2 delete input )
    release channel TSM2
    release channel TSM1
    And fail with this error:
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of backup command at 08/13/2012 22:36:43
    RMAN-06004: ORACLE error from recovery catalog database: RMAN-20242: specification does not match any archive log in the recovery catalog
    I've take a look to the archives directories and both nodes have archives:
    ora10g:/opt/ora10g > ls -lrt /logs/bbdd/oracle/INF01T01/archiver
    total 97896
    -rw-r----- 1 ora10g dba 2048 Aug 13 22:36 T0001S00000061440648489222.ARC
    -rw-rw---- 1 ora10g dba 38132224 Aug 13 22:36 T0001S00000061430648489222.ARC
    -rw-r----- 1 ora10g dba 11984896 Aug 13 22:36 T0002S00000044040648489222.ARC
    ora10g:/opt/ora10g > ls -lrt /logs/bbdd/oracle/INF01T03/archiver
    total 392984
    -rw-r----- 1 ora10g dba 49364992 Mar 24 2009 T0002S00000007020648489222.ARC
    -rw-r----- 1 ora10g dba 49364992 Mar 25 2009 T0002S00000007030648489222.ARC
    -rw-rw---- 1 ora10g dba 19314688 Mar 25 2009 T0002S00000007040648489222.ARC
    -rw-rw---- 1 ora10g dba 4733952 Mar 25 2009 T0002S00000007050648489222.ARC
    -rw-rw---- 1 ora10g dba 4608 Apr 09 2009 T0002S00000007440648489222.ARC
    -rw-rw---- 1 ora10g dba 2541056 Sep 26 2009 T0002S00000015420648489222.ARC
    -rw-rw---- 1 ora10g dba 49373184 Sep 28 2009 T0002S00000015430648489222.ARC
    -rw-rw---- 1 ora10g dba 3410432 Feb 11 2010 T0002S00000018680648489222.ARC
    -rw-rw---- 1 ora10g dba 599552 Feb 12 2010 T0002S00000018710648489222.ARC
    -rw-rw---- 1 ora10g dba 6574080 Mar 03 2010 T0002S00000019200648489222.ARC
    -rw-rw---- 1 ora10g dba 1663488 Mar 08 2010 T0002S00000019340648489222.ARC
    -rw-rw---- 1 ora10g dba 431104 Apr 07 2010 T0002S00000020160648489222.ARC
    -rw-rw---- 1 ora10g dba 13811712 Apr 19 2010 T0002S00000020460648489222.ARC
    I've tried to made a crosscheck but, only found node1 archives:
    RMAN> change archivelog all crosscheck;
    validation succeeded for archived log
    archive log filename=/logs/bbdd/oracle/INF01T01/archiver/T0001S00000061430648489222.ARC recid=10685 stamp=791246196
    validation succeeded for archived log
    archive log filename=/logs/bbdd/oracle/INF01T01/archiver/T0001S00000061440648489222.ARC recid=10686 stamp=791246196
    validation succeeded for archived log
    archive log filename=/logs/bbdd/oracle/INF01T01/archiver/T0002S00000044040648489222.ARC recid=10687 stamp=791246197
    Crosschecked 3 objects
    Any idea about the way to solve it?
    Thanks in advance!
    dbajug

    Hi,
    Connect to target through rman
    crosscheck archivelog all;
    Then re run the backup. This will work if those two locations provided are archive log destinations.
    In case the issue still persists then
    Connect to target through rman
    catalog start with '/logs/bbdd/oracle/INF01T01/archiver/';
    catalog start with '/logs/bbdd/oracle/INF01T03/archiver/';
    Then re run the backup.
    Thanks,
    Vivek
    Edited by: 952807 on Aug 16, 2012 5:21 PM

  • How to exam archive logs

    System filled up archive-logs disk unexpectedly. This may caused by some unknown application process. How can I tracking this?

    Hi James:
    You better find out which application fills up the archive log destination "unexpectedly". You should also write a script to monitor the archive log destination. If its usage reaches to a certain percentage, says 80%, then kicks off a backup process to backup the archive logs.

  • Archive log full frequently

    hi ,
    i have been getting the ORA-00257 : archiver error connect internal only, until freed
    is it possible to monitor this archive log to see when it might be filling up ?
    pls advise

    If you are on Oracle9i, the best (probably the only) option is to is write some script to monitor the archive log destination file system. If the utilization goes beyond a certain percentage, if you can have the script notify you.
    Thanks
    Chandra Pabba

  • Using 2 file systems to place archive logs

    We currently have LOG_ARCHIVE_DEST parameter set to place archive logs to /u10 file system. However it no longer has enough space and system admin added second dedicated file system /u11 to place archive logs. So we would like to start using both of them. If first gets full we want to make sure second is in use until backup job deletes them. If this possible to do in current version that we have (8.1.7) and what changes should we make to start utilizing both file systems.
    Thanks.
    Edited by: user594143 on Sep 8, 2008 3:47 PM

    I am not sure whether this was introduced from 8i but 9i & 10g both versions have this feature.
    You can use the ALTERNATE feature of log_archive_dest_n to set an alternate destination if the primary destination fails. In the sense, if the primary (mandatory) archive log destination fails because of either full or any other reason, the database starts archiving to the ALTERNATE destination. After you clear the primary destination, you have to manually switch the destinations to PRIMARY and ALTERNATE.
    SQL> alter system set log_archive_dest_1='LOCATION=/u00/app/oracle/admin/archive_1 MANDATORY NOREOPEN ALTERNATE=log_archive_dest_2';
    SQL> alter system set log_archive_dest_2='LOCATION=/u01/app/oracle/admin/archive_2 OPTIONAL';
    SQL> alter system set log_archive_dest_state_1=enable;
    SQL> alter system set log_archive_dest_state_2=alternate;
    Thanks,
    Harris.

  • ARC0: Failed to archive log# 1 seq# 1361

    Hi.
    Sat Apr 26 04:00:01 2003
    Current log# 2 seq# 1362 mem# 0: /redolog02/TRADEDB1/log/log02_01.ora
    Current log# 2 seq# 1362 mem# 1: /redolog01/TRADEDB1/log/log02_02.ora
    Sat Apr 26 04:00:01 2003
    ARCH: Beginning to archive log# 1 seq# 1361
    Sat Apr 26 04:00:01 2003
    ARC0: Beginning to archive log# 1 seq# 1361
    ARC0: Failed to archive log# 1 seq# 1361
    Sat Apr 26 04:00:03 2003
    ARCH: Completed archiving log# 1 seq# 1361
    these are the last few lines of my DB alert log file.I have scheduled a shell script to backup all the archive log script but whenever the script is running I am getting this error.
    Can any one explain me what this means.Looks like archiving is done with out any problem.
    I am using "alter system archivelog current" in the script.
    regards
    Joe

    Although this is not a serious problem, it does cause your database to stop briefly. It indicates that you do not have enough redo log groups.
    Essentially, Oracle writes redo information to log group 1 until it is full, then switches to log group 2. While lgwr is writing to group 2, arc writes group 1 to the archive log destination. If arc is not finished archiving group 1 before group 2 fills, then it has nowhere to switch to (i.e. group 1 is not available for lgwr to write to yet). In normal operation, when Oracle is managing log switches, you would see an error about unable to switch logs from lgwr. However, by issuing the archivelog current, arc does all the work. Since it is unable to do the log switch required to archive the current log, it generates the failed to archive message, and waits for group 2 to finish archiving.
    If this is only a problem when doing the backup, you can probably ignore it. However, if you see log switch errors in normal operation, you should add another logfile group, so there will be more time between switches into any sngle group.
    TTFN
    John

Maybe you are looking for