OVM 3.0 Database Creating Lots of Archive Logs

Greetings - ever since we initially installed OVM 3.0 earlier this fall (~October), the OVM database has generated archive logs at a very rapid rate. It continually threatens to fill up our 16 GB filesystem dedicated to archive logs, even after daily backup and purging.
Our OVM database itself is about 4-6 GB large, and we would need to increase the archive log filesystem to about 20-25 GB in size, which we see as unreasonable for such a small database.
What is causing OVM to generate so many redo logs? Our best guess is that OVM is continuously gathering guest VM CPU usage on each physical server.
Is there a way to configure the OVM application in order to reduce the amount of redo/archive logs being created?
We are currently running 3.0.3, having upgraded each time a 3.0.* patch was released. OVMM running on OEL 6.1, database running on latest HP-UX.

majedian21 wrote:
Greetings - ever since we initially installed OVM 3.0 earlier this fall (~October), the OVM database has generated archive logs at a very rapid rate. It continually threatens to fill up our 16 GB filesystem dedicated to archive logs, even after daily backup and purging.I would log an SR with Oracle Support for this, so that Development can look at it. Sounds like your environment has lots of VMs running and yes, collecting usage stats for all of those environments. However, there may be some old data from the previous versions that's causing more stats to be collected than necessary.

Similar Messages

  • When creating a tablespace why should we enable LOGGING when a database is already on ARCHIVE LOG mode

    Question :
    When creating a tablespace why should we enable LOGGING when a database is already on ARCHIVE LOG mode ?
    Example:
    Create Tablespace
    CREATE SMALLFILE TABLESPACE "TEST_DATA"
    LOGGING
    DATAFILE '+DG_TEST_DATA_01(DATAFILE)' SIZE 10G
    AUTOEXTEND ON NEXT  500K MAXSIZE 31000M
    EXTENT MANAGEMENT LOCAL
    SEGMENT SPACE MANAGEMENT AUTO;
    LOGGING: Generate redo logs for creation of tables, indexes and  partitions, and for subsequent inserts. Recoverable
    Are they not logged and not recoverable if we do not enable LOGGING? What is that ARCHIVELOG mode does?

    What is that ARCHIVELOG Mode Does?
    Whenever your database is in archive log mode , Oracle will backup the redo log files in the form of Archives so that we can recover the database to the consistent state in case of any failure.
    Archive logging is essential for production databases where the loss of a transaction might be fatal.
    Why Logging?
    Logging is safest method to ensure that all the changes made at the tablespace will be captured and available for recovery in the redo logs.
    It is just the level at which we defines:
    Force Logging at DB level
    Logging at Tablespace Level
    Logging at schema Level
    Before the existence of FORCE LOGGING, Oracle provided logging and nologging options. These two options have higher precedence at the schema object level than the tablespace level; therefore, it was possible to override the logging settings at the tablespace level with nologging setting at schema object level.

  • Database large Number of archive log

    Oracle 11g
    window server 2008 R2
    My database working fine, from last week i have noticed that database generating large no of archive log.
    Database size is 30GB
    Only one table space is 16GB , other tablespaces not more 2 GB.
    I can not figured out why it  generating large no. of archive log. can any one help me to figure out.
    previous week i have only did these changes
    Drop index
    create index
    create new table from existing table.
    nothing else i  did.

    Hi
    As you say workload increases. See when the number of log switches goes high and take an AWR report or statspack report. Check the DML operations. Use below query to chk the log switches
    spool c:\log_hist.txt
    SET PAGESIZE 90
    SET LINESIZE 150
    set heading on
    column "00:00" format 9999
    column "01:00" format 9999
    column "02:00" format 9999
    column "03:00" format 9999
    column "04:00" format 9999
    column "05:00" format 9999
    column "06:00" format 9999
    column "07:00" format 9999
    column "08:00" format 9999
    column "09:00" format 9999
    column "10:00" format 9999
    column "11:00" format 9999
    column "12:00" format 9999
    column "13:00" format 9999
    column "14:00" format 9999
    column "15:00" format 9999
    column "16:00" format 9999
    column "17:00" format 9999
    column "18:00" format 9999
    column "19:00" format 9999
    column "20:00" format 9999
    column "21:00" format 9999
    column "22:00" format 9999
    column "23:00" format 9999
    SELECT * FROM (
    SELECT * FROM (
    SELECT TO_CHAR(FIRST_TIME, 'DD/MM') AS "DAY"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '00', 1, 0), '99')) "00:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '01', 1, 0), '99')) "01:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '02', 1, 0), '99')) "02:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '03', 1, 0), '99')) "03:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '04', 1, 0), '99')) "04:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '05', 1, 0), '99')) "05:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '06', 1, 0), '99')) "06:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '07', 1, 0), '99')) "07:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '08', 1, 0), '99')) "08:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '09', 1, 0), '99')) "09:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '10', 1, 0), '99')) "10:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '11', 1, 0), '99')) "11:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '12', 1, 0), '99')) "12:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '13', 1, 0), '99')) "13:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '14', 1, 0), '99')) "14:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '15', 1, 0), '99')) "15:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '16', 1, 0), '99')) "16:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '17', 1, 0), '99')) "17:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '18', 1, 0), '99')) "18:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '19', 1, 0), '99')) "19:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '20', 1, 0), '99')) "20:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '21', 1, 0), '99')) "21:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '22', 1, 0), '99')) "22:00"
    , SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '23', 1, 0), '99')) "23:00"
      FROM V$LOG_HISTORY
      WHERE extract(year FROM FIRST_TIME) = extract(year FROM sysdate)
      GROUP BY TO_CHAR(FIRST_TIME, 'DD/MM')
      ) ORDER BY TO_DATE(extract(year FROM sysdate) || DAY, 'YYYY DD/MM') DESC
      ) WHERE ROWNUM <8;
    spool off
    One common mistake is enabling debugging. You can  check in application code if any debugging is enabled. (insert every records for logging or support purpose)
    Regards
    Anand.

  • 91 Database - When to Backup Archive Logs?

    hi experts,
    I have a 9i db that runs in Archive mode. NOT using the catalog.
    A full database backup is made by RMAN at 7am while database is OPEN.
    An incremental backup are made every 3 hours.
    For RMAN to be able to perform a complete recovery, when should I backup the archive logs?
    Thanks, John

    Thanks Khurran and Anvar.
    As I'm new to Oracle (my background is SQL Server), I admit I'm a bit confused about the use of archive logs.
    I had a situation last week, where I needed to restore (to another server) froma backup made at month-end. I had the whole db backup but it was made while db was open. Therefore I needed to also restore the archive log(s) but did not have them. In the end, I had to restore db and force it to open. it was messy and not at all easy.
    My recovery window is 2 days.
    If I do the following, will I be able to restore to a point in time for the past 2 days?
    - controlfile is set for autobackup
    - run RMAN> backup databse plus archivelog; once per day, then run my incremental backup every 3 hours
    Thanks for your opinions. John

  • Recovery of database with loss of archived logs

    Hi,
    I tried restoring the database using the standard practice, however, I am encountering errors. It looks like we are missing archive log files, but I am not sure. Could anyone provide more insight to this problem and how to recover the database?
    Here are the steps we did.
    SVRMGR> connect internal
    Connected.
    SVRMGR> startup
    ORACLE instance started.
    Total System Global Area 1117552144 bytes
    Fixed Size 48656 bytes
    Variable Size 291995648 bytes
    Database Buffers 819200000 bytes
    Redo Buffers 6307840 bytes
    Database mounted.
    ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
    SVRMGR> recover database using backup controlfile until cancel;
    ORA-00279: change 663652622 generated at 02/13/02 06:20:02 needed for thread 1
    ORA-00289: suggestion : /oraclesw8_redolog/ARCHIVE_CP/infr/infr_1_13598.dbf
    ORA-00280: change 663652622 for thread 1 is in sequence #13598
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    Log applied.
    ORA-00279: change 663654936 generated at 02/13/02 07:04:14 needed for thread 1
    ORA-00289: suggestion : /oraclesw8_redolog/ARCHIVE_CP/infr/infr_1_13599.dbf
    ORA-00280: change 663654936 for thread 1 is in sequence #13599
    ORA-00278: log file '/oraclesw8_redolog/ARCHIVE_CP/infr/infr_1_13598.dbf' no longer needed for this recovery
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    AUTO
    ORA-00308: cannot open archived log '/oraclesw8_redolog/ARCHIVE_CP/infr/infr_1_13599.dbf'
    ORA-27037: unable to obtain file status
    SVR4 Error: 2: No such file or directory
    Additional information: 3
    ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
    ORA-01195: online backup of file 1 needs more recovery to be consistent
    ORA-01110: data file 1: '/oraclesw8_data00/oradata/infr/infr_system_01.dbf'

    Hi
    It looks like you may have to manually apply the last redo log.
    SVRMGR> SELECT member FROM v$log l, v$logfile f WHERE l.group# = f.group# AND l.status = 'CURRENT';
    Note the path of this log file.
    SVRMGR> Recover database until cancel
    When you get the message that you mentioned -
    Apply the log member from the select statement above. Give it
    the full path as it appears on the select statement.
    SVRMGR> Alter database open resetlogs;
    The system should respond with "Statement processed".
    Good Luck,
    Bob

  • Database backup with lost archive logs

    How can I get a database backup when all the archive logs have been lost?

    here's the full test of the backup:
    Recovery Manager: Release 9.2.0.7.0 - 64bit Production
    Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
    RMAN>
    connected to target database: ESKHDEV1 (DBID=4075873486)
    using target database controlfile instead of recovery catalog
    RMAN>
    echo set on
    RMAN> run {
    2> allocate channel oem_backup_disk1 type disk format '/sbdbarc/backups/eskhdev1/%U' maxpiecesize 2000 M;
    3> backup filesperset = 3 tag 'BACKUP_ESKHDEV1_00_101008022533' database;
    4> backup filesperset = 3 tag 'BACKUP_ESKHDEV1_00_101008022533' archivelog all not backed up;
    5> release channel oem_backup_disk1;
    6> }
    allocated channel: oem_backup_disk1
    channel oem_backup_disk1: sid=18 devtype=DISK
    Starting backup at 10-OCT-08
    channel oem_backup_disk1: starting full datafile backupset
    channel oem_backup_disk1: specifying datafile(s) in backupset
    input datafile fno=00013 name=/spte/oracle/oradata/ESKHDEV1/leafdat02.dbf
    input datafile fno=00011 name=/spte/oracle/oradata/ESKHDEV1KLXTEMP.dbf
    input datafile fno=00001 name=/spte/oracle/oradata/ESKHDEV1/system01.dbf
    channel oem_backup_disk1: starting piece 1 at 10-OCT-08
    channel oem_backup_disk1: finished piece 1 at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/2jjsq87q_1_1 comment=NONE
    channel oem_backup_disk1: backup set complete, elapsed time: 00:00:45
    channel oem_backup_disk1: starting full datafile backupset
    channel oem_backup_disk1: specifying datafile(s) in backupset
    input datafile fno=00002 name=/spte/oracle/oradata/ESKHDEV1/undotbs01.dbf
    input datafile fno=00008 name=/spte/oracle/oradata/ESKHDEV1/tools01.dbf
    input datafile fno=00005 name=/spte/oracle/oradata/ESKHDEV1/example01.dbf
    channel oem_backup_disk1: starting piece 1 at 10-OCT-08
    channel oem_backup_disk1: finished piece 1 at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/2kjsq897_1_1 comment=NONE
    channel oem_backup_disk1: starting piece 2 at 10-OCT-08
    channel oem_backup_disk1: finished piece 2 at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/2kjsq897_2_1 comment=NONE
    channel oem_backup_disk1: backup set complete, elapsed time: 00:01:20
    channel oem_backup_disk1: starting full datafile backupset
    channel oem_backup_disk1: specifying datafile(s) in backupset
    input datafile fno=00017 name=/spte/oracle/oradata/ESKHDEV1/parentidx01.dbf
    input datafile fno=00015 name=/spte/oracle/oradata/ESKHDEV1/lral3201.dbf
    input datafile fno=00010 name=/spte/oracle/oradata/ESKHDEV1/xdb01.dbf
    channel oem_backup_disk1: starting piece 1 at 10-OCT-08
    channel oem_backup_disk1: finished piece 1 at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/2ljsq8bn_1_1 comment=NONE
    channel oem_backup_disk1: backup set complete, elapsed time: 00:01:05
    channel oem_backup_disk1: starting full datafile backupset
    channel oem_backup_disk1: specifying datafile(s) in backupset
    input datafile fno=00012 name=/spte/oracle/oradata/ESKHDEV1/leafdat01.dbf
    input datafile fno=00006 name=/spte/oracle/oradata/ESKHDEV1/indx01.dbf
    input datafile fno=00003 name=/spte/oracle/oradata/ESKHDEV1/cwmlite01.dbf
    channel oem_backup_disk1: starting piece 1 at 10-OCT-08
    channel oem_backup_disk1: finished piece 1 at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/2mjsq8dp_1_1 comment=NONE
    channel oem_backup_disk1: backup set complete, elapsed time: 00:01:15
    channel oem_backup_disk1: starting full datafile backupset
    channel oem_backup_disk1: specifying datafile(s) in backupset
    input datafile fno=00014 name=/spte/oracle/oradata/ESKHDEV1/leafidx.dbf
    input datafile fno=00009 name=/spte/oracle/oradata/ESKHDEV1/users01.dbf
    input datafile fno=00004 name=/spte/oracle/oradata/ESKHDEV1/drsys01.dbf
    channel oem_backup_disk1: starting piece 1 at 10-OCT-08
    channel oem_backup_disk1: finished piece 1 at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/2njsq8g4_1_1 comment=NONE
    channel oem_backup_disk1: backup set complete, elapsed time: 00:01:15
    channel oem_backup_disk1: starting full datafile backupset
    channel oem_backup_disk1: specifying datafile(s) in backupset
    input datafile fno=00016 name=/spte/oracle/oradata/ESKHDEV1/parentdat01.dbf
    input datafile fno=00007 name=/spte/oracle/oradata/ESKHDEV1/odm01.dbf
    channel oem_backup_disk1: starting piece 1 at 10-OCT-08
    channel oem_backup_disk1: finished piece 1 at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/2ojsq8if_1_1 comment=NONE
    channel oem_backup_disk1: backup set complete, elapsed time: 00:01:35
    Finished backup at 10-OCT-08
    Starting backup at 10-OCT-08
    current log archived
    channel oem_backup_disk1: starting archive log backupset
    channel oem_backup_disk1: specifying archive log(s) in backup set
    input archive log thread=1 sequence=1260 recid=1236 stamp=667755183
    channel oem_backup_disk1: starting piece 1 at 10-OCT-08
    channel oem_backup_disk1: finished piece 1 at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/2pjsq8lf_1_1 comment=NONE
    channel oem_backup_disk1: backup set complete, elapsed time: 00:00:02
    Finished backup at 10-OCT-08
    Starting Control File and SPFILE Autobackup at 10-OCT-08
    piece handle=/sbdbarc/backups/eskhdev1/c-4075873486-20081010-02 comment=NONE
    Finished Control File and SPFILE Autobackup at 10-OCT-08
    released channel: oem_backup_disk1
    RMAN> delete noprompt obsolete device type disk;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 1
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: sid=18 devtype=DISK
    Deleting the following obsolete backups and copies:
    Type Key Completion Time Filename/Handle
    Backup Set 2 17-MAR-08
    Backup Piece 2 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_10_1_649591917.rbp
    Backup Set 6 17-MAR-08
    Backup Piece 6 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_14_1_649594217.rbp
    Backup Set 7 17-MAR-08
    Backup Piece 7 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_16_1_649594217.rbp
    Backup Set 8 17-MAR-08
    Backup Piece 8 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_17_1_649594353.rbp
    Backup Set 9 17-MAR-08
    Backup Piece 9 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_19_1_649595236.rbp
    Backup Set 10 17-MAR-08
    Backup Piece 10 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_18_1_649595236.rbp
    Backup Set 11 17-MAR-08
    Backup Piece 11 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_20_1_649595236.rbp
    Backup Set 12 17-MAR-08
    Backup Piece 12 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_21_1_649595381.rbp
    Backup Set 13 17-MAR-08
    Backup Piece 13 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_24_1_649595445.rbp
    Backup Set 14 17-MAR-08
    Backup Piece 14 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_22_1_649595445.rbp
    Backup Set 15 17-MAR-08
    Backup Piece 15 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_23_1_649595445.rbp
    Backup Set 16 17-MAR-08
    Backup Piece 16 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_25_1_649595471.rbp
    Backup Set 17 17-MAR-08
    Backup Piece 17 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_27_1_649604714.rbp
    Backup Set 18 17-MAR-08
    Backup Piece 18 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_26_1_649604714.rbp
    Backup Set 19 17-MAR-08
    Backup Piece 19 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_28_1_649604714.rbp
    Backup Set 20 17-MAR-08
    Backup Piece 20 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_29_1_649604850.rbp
    Backup Set 21 17-MAR-08
    Backup Piece 21 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_31_1_649604923.rbp
    Backup Set 22 17-MAR-08
    Backup Piece 22 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_30_1_649604923.rbp
    Backup Set 23 17-MAR-08
    Backup Piece 23 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_33_1_649606774.rbp
    Backup Set 24 17-MAR-08
    Backup Piece 24 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_32_1_649606774.rbp
    Backup Set 25 17-MAR-08
    Backup Piece 25 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_34_1_649606774.rbp
    Backup Set 26 17-MAR-08
    Backup Piece 26 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_35_1_649606900.rbp
    Backup Set 27 17-MAR-08
    Backup Piece 27 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_37_1_649606970.rbp
    Backup Set 28 17-MAR-08
    Backup Piece 28 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_36_1_649606970.rbp
    Backup Set 29 17-MAR-08
    Backup Piece 29 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_39_1_649607591.rbp
    Backup Set 30 17-MAR-08
    Backup Piece 30 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_38_1_649607591.rbp
    Backup Set 31 17-MAR-08
    Backup Piece 31 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_40_1_649607591.rbp
    Backup Set 32 17-MAR-08
    Backup Piece 32 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_41_1_649607707.rbp
    Backup Set 33 17-MAR-08
    Backup Piece 33 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_43_1_649607785.rbp
    Backup Set 34 17-MAR-08
    Backup Piece 34 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_42_1_649607785.rbp
    Backup Set 35 17-MAR-08
    Backup Piece 35 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_45_1_649609650.rbp
    Backup Set 36 17-MAR-08
    Backup Piece 36 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_44_1_649609650.rbp
    Backup Set 37 17-MAR-08
    Backup Piece 37 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_46_1_649609650.rbp
    Backup Set 38 17-MAR-08
    Backup Piece 38 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_47_1_649609777.rbp
    Backup Set 39 17-MAR-08
    Backup Piece 39 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_49_1_649609840.rbp
    Backup Set 40 17-MAR-08
    Backup Piece 40 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_48_1_649609840.rbp
    Backup Set 41 17-MAR-08
    Backup Piece 41 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_51_1_649611229.rbp
    Backup Set 42 17-MAR-08
    Backup Piece 42 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_50_1_649611229.rbp
    Backup Set 43 17-MAR-08
    Backup Piece 43 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_52_1_649611229.rbp
    Backup Set 44 17-MAR-08
    Backup Piece 44 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_53_1_649611355.rbp
    Backup Set 45 17-MAR-08
    Backup Piece 45 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_55_1_649611419.rbp
    Backup Set 46 17-MAR-08
    Backup Piece 46 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_54_1_649611419.rbp
    Backup Set 47 17-MAR-08
    Backup Piece 47 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_57_1_649612920.rbp
    Backup Set 48 17-MAR-08
    Backup Piece 48 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_56_1_649612920.rbp
    Backup Set 49 17-MAR-08
    Backup Piece 49 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_58_1_649612920.rbp
    Backup Set 50 17-MAR-08
    Backup Piece 50 17-MAR-08 /spte/oracle/backups/eskhdev1/df_ESKHDEV1_59_1_649613075.rbp
    Backup Set 51 17-MAR-08
    Backup Piece 51 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_61_1_649613158.rbp
    Backup Set 52 17-MAR-08
    Backup Piece 52 17-MAR-08 /spte/oracle/backups/eskhdev1/al_ESKHDEV1_60_1_649613158.rbp
    Backup Set 66 10-OCT-08
    Backup Piece 68 10-OCT-08 /sbdbarc/backups/eskhdev1/2bjsppct_1_1
    Backup Set 67 10-OCT-08
    Backup Piece 69 10-OCT-08 /sbdbarc/backups/eskhdev1/2cjsppea_1_1
    Backup Piece 70 10-OCT-08 /sbdbarc/backups/eskhdev1/2cjsppea_2_1
    Backup Set 68 10-OCT-08
    Backup Piece 71 10-OCT-08 /sbdbarc/backups/eskhdev1/2djsppgq_1_1
    Backup Set 69 10-OCT-08
    Backup Piece 72 10-OCT-08 /sbdbarc/backups/eskhdev1/2ejsppir_1_1
    Backup Set 70 10-OCT-08
    Backup Piece 73 10-OCT-08 /sbdbarc/backups/eskhdev1/2fjsppl6_1_1
    Backup Set 71 10-OCT-08
    Backup Piece 74 10-OCT-08 /sbdbarc/backups/eskhdev1/2gjsppnh_1_1
    Backup Set 72 10-OCT-08
    Backup Piece 75 10-OCT-08 /sbdbarc/backups/eskhdev1/c-4075873486-20081010-00
    Backup Set 73 10-OCT-08
    Backup Piece 76 10-OCT-08 /sbdbarc/backups/eskhdev1/c-4075873486-20081010-01
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/2bjsppct_1_1 recid=68 stamp=667739549
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/2cjsppea_1_1 recid=69 stamp=667739594
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/2cjsppea_2_1 recid=70 stamp=667739639
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/2djsppgq_1_1 recid=71 stamp=667739674
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/2ejsppir_1_1 recid=72 stamp=667739739
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/2fjsppl6_1_1 recid=73 stamp=667739814
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/2gjsppnh_1_1 recid=74 stamp=667739889
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/c-4075873486-20081010-00 recid=75 stamp=667739965
    deleted backup piece
    backup piece handle=/sbdbarc/backups/eskhdev1/c-4075873486-20081010-01 recid=76 stamp=667742372
    Deleted 9 objects
    RMAN-06207: WARNING: 48 objects could not be deleted for DISK channel(s) due
    RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status
    List of Mismatched objects
    ==========================
    Object Type Filename/Handle
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_10_1_649591917.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_14_1_649594217.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_16_1_649594217.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_17_1_649594353.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_19_1_649595236.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_18_1_649595236.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_20_1_649595236.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_21_1_649595381.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_24_1_649595445.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_22_1_649595445.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_23_1_649595445.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_25_1_649595471.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_27_1_649604714.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_26_1_649604714.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_28_1_649604714.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_29_1_649604850.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_31_1_649604923.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_30_1_649604923.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_33_1_649606774.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_32_1_649606774.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_34_1_649606774.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_35_1_649606900.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_37_1_649606970.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_36_1_649606970.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_39_1_649607591.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_38_1_649607591.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_40_1_649607591.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_41_1_649607707.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_43_1_649607785.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_42_1_649607785.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_45_1_649609650.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_44_1_649609650.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_46_1_649609650.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_47_1_649609777.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_49_1_649609840.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_48_1_649609840.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_51_1_649611229.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_50_1_649611229.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_52_1_649611229.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_53_1_649611355.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_55_1_649611419.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_54_1_649611419.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_57_1_649612920.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_56_1_649612920.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_58_1_649612920.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/df_ESKHDEV1_59_1_649613075.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_61_1_649613158.rbp
    Backup Piece /spte/oracle/backups/eskhdev1/al_ESKHDEV1_60_1_649613158.rbp
    RMAN> release channel;
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of release command at 10/10/2008 15:33:09
    RMAN-06474: maintenance channels are not allocated
    RMAN> exit;
    Recovery Manager complete.

  • How to create uniform size archive logs?

    DB version 11.2.0.3
    OS solaris.
    i have 6 online redo log groups.
    i want that my archive logs file always create of uniform size of 50MB each?

    Asad99 wrote:
    DB version 11.2.0.3
    OS solaris.
    i have 6 online redo log groups.
    i want that my archive logs file always create of uniform size of 50MB each?Why do you care about the size of an individual archivelog? What problem does that solve?
    Archivelogs are simply "backup" copies of the online redologs. So in general, an archivelog will be the same size as the online redolog that it is archiving. It may happen to be be smaller in some circumstances that cause a log switch before an online redo log is full.

  • Generating lots of archive logs

    Hi Friends,
    We have an EBS 11i on AIX 5L ...which has just been setup and ready for UAT...but the AppsDBA/Functional Consultant who didi it are not around anymore to ask for questiones. I just noticed the there are archive logs generated everyday...like 30 logs...when in fact the application is not being used. Is there concurrent programs
    that has been setup to update data on a background process, just like recursive updating which is not really necessary. How do I check if there are updates being done.
    Thanks a lot

    Do not stop this concurrent program as it is used to synchronize the Workflow local tables with the user and role information stored in the product application tables until each affected product performs the synchronization automatically.
    More details can be found in the following note:
    Note: 171703.1 - 11.5.x: Implementing Oracle Workflow Directory Service Synchronization
    https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=171703.1
    Did you check the total size of the log files? I believe you should not be worried now until the system is delivered to the users, you can monitor the number of log files generated daily then and based on that start your investigation.

  • Can't install Oracle XE on Windows 7 : the install ends fine but no database created and error in log file

    When i try to install Oracle XE 64bit 11g on a windows 7, the installation ends correctly, but no database is created (no datafiles) and in the log file I find :
    Oracle Database 11g Clusterware Release 11.2.0.2.0 - Production Copyright 1996, 2010 Oracle. All rights reserved.
    2015-03-24 15:24:14.733: [ default][3316]ut_read_reg:2:ocr registry key SOFTWARE\Oracle\olr cannot be opened. error 2
    [ CLSE][3316]clse_get_crs_home: Error retrieving OLR configuration [0] [Error opening olr registry key. Le fichier spécifié est introuvable.
    What's the problem?

    Oracle XE 64bit 11g on a windows 7
    Which edition ?

  • FSDB database running in no archived log mode - is this OK?

    I'm new to Exadata and a contractor at a client site, and noticed that the FSDB database is running in no archive mode and isn't getting backed up.
    I understand that the FSDB database is linked to the dbfs file system, so my question is - what should be backed up? The database, the file system, or both?
    TIA.

    No it would backup the whole dbfs database. as the dbfs databse is easily rereated the database metadata is not generally considered significant. the data on the dbfs filesystem may be more critical, but since this is typically used as staging often there is another copy of the files somewhere on the source systems and so loss and receration of the dbfs databsae would be no big deal. If on the other hand it is a big deal then yes the backup would be slightly larger than the filesystem. seeing issues we had with DBFS I am curious to know whether your dbfs filesystem seeming as it is so large is it being used as a permanent file store ?
    that really isn't the best use case for dbfs. It is generally best used as a temporary staging area.

  • Standby creating archives log files issue!

    Hello Everyone,
    Working on oracle 10g R2/Windows, I have created a dataguard with one standby database, but there is a strange issue that happen, and I'll need someone to shed the light to me.
    By default archived log created from the primary database should be the  sent to the stanndby database, but I found that the standby database has plus one archived log file.
    From the primary database:
    SQL> archive log list;
    Database log mode Archive Mode
    Automatic archival Enabled
    Archive destination C:\local_destination1_orcl
    Oldest online log sequence 1021
    Next log sequence to archive 1023
    Current log sequence 1023
    contents of C:\local_destination1_orcl
    1_1022_623851185.ARC
    from the standby database:
    SQL> archive log list
    Database log mode Archive Mode
    Automatic archival Enabled
    Archive destination C:\local_destination1_orcl
    Oldest online log sequence 1022
    Next log sequence to archive 0
    Current log sequence 1023
    contents of C:\local_destination1_orcl
    1_1022_623851185.ARC
    1_1023_623851185.ARC ---> this is the extra archive file created in the standby database, should someone let me know how to avoid this?
    Thanks for your help

    SELECT FROM v$version;*
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
    PL/SQL Release 10.2.0.1.0 - Production
    CORE 10.2.0.1.0 Production
    TNS for 64-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    The standby database is a physical standby database (not logical standby)
    Thanks against for your contribution, but I'm still not know why standby create and arhive files too?

  • Oracle 9i Streams - Lots of Archive generation.

    Hi,
    We are using Oracle 9i stream for data replication between two database servers running in ARCHIVELOG mode.
    We observed during data replication , with very few transactions, lots of redo, and hence the archived logs are getting generated, which is almost 2.5G per dae. What might be the reason for generation of lots of REDO ? This redo generation is almost 20 times more than the normal redo generation when replication process (capture, propagation and apply process) was not running. Stream replication do generate redo in multiple of normal redo, but not as big as we are getting. What might be the reason for the same.
    Kamlesh C

    Hello,
    You can query the v$sesstat and v$session view so as to find the session which generates
    the most redo. For instance:
    select a.sid, a.serial#, a.username, a.program, b.value "Redo blocks written"
    from v$session a, v$sesstat b
    where a.sid=b.sid
    and b.statistic# = (select statistic# from v$statname
                        where name = 'redo size')
    order by b.value;The query should be executed when the database is generating the Archived logs.
    Hope this help.
    Best regards,
    Jean-Valentin

  • 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

  • Archive log files are not being created

    I am doing some testing of the backup and recovery of our databases.
    I have a database which is in archive log mode.
    I have added some records to a table and I am expecting to see some archive files
    being written to but nothing is being produced.
    We are running Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
    The current archive information is as follows :
    SQL> archive log list;
    Database log mode Archive Mode
    Automatic archival Enabled
    Archive destination USE_DB_RECOVERY_FILE_DEST
    Oldest online log sequence 1
    Next log sequence to archive 3
    Current log sequence 3
    SQL> show parameter db_recovery_file_dest;
    NAME TYPE VALUE
    db_recovery_file_dest string /export/flash_recovery_area
    When I look in the directory as indicated above I see no files :
    cd /export/flash_recovery_area/MRESTORE/archivelog/2013_04_16
    (no files)
    I'm wondering if I am missing something obvious here.
    Thank you in advance.

    user6502667 wrote:
    I am doing some testing of the backup and recovery of our databases.
    I have a database which is in archive log mode.
    I have added some records to a table and I am expecting to see some archive files
    being written to but nothing is being produced.
    We are running Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
    The current archive information is as follows :
    SQL> archive log list;
    Database log mode Archive Mode
    Automatic archival Enabled
    Archive destination USE_DB_RECOVERY_FILE_DEST
    Oldest online log sequence 1
    Next log sequence to archive 3
    Current log sequence 3
    SQL> show parameter db_recovery_file_dest;
    NAME TYPE VALUE
    db_recovery_file_dest string /export/flash_recovery_area
    When I look in the directory as indicated above I see no files :
    cd /export/flash_recovery_area/MRESTORE/archivelog/2013_04_16
    (no files)
    I'm wondering if I am missing something obvious here.
    Thank you in advance.There can be several, but I'd say the most likely is that you simply didn't yet generate enough redo information to fill a redolog and thus trigger the writing of an archivelog.

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

Maybe you are looking for