More archive logs

Hello All,
we are on 11.1.0.6 on AIX
On our database side, finding "excessive redo log generation" at a specific time only (between 11 -12 midnight)
How to find what exactly going on at that time whos causing so much redo generation.
Thanks

Thnaks for the update....
Yes I am licenced.
Taken AWR report, can you please suggest which part of the report give me the idea about root cause.
@faran,
Nothig been schedule at that time like backup script etc....
Mean by eccessive is we have 4 grups with each 2 members with 200 MB size each
Yesterday between said time its hight for rest of the time. 38 archives generated at this perticular time only.
Edited by: DOA on 7 Sep, 2012 1:48 AM

Similar Messages

Generating more archive logs

Hi all,,
my env is Oracle 10gR2,RHEL4.0,
In my dev Db one of user table contain more than 10Lac Records .in that some duplicate are present.
I am deleting record by record it is generating more Archive log file.due to that my is database hanged.
can you tell me what are the possible reasons for gen of more arch file.
Regards,
kk

Hi,
If the answer is not in previous post and if you're deleting (much) more than you're keeping (i mean very large volumes) i suggest :
(create a backup table as the one you're deleting in (same structure-> not constraints))
- backup the rows you want to keep in an other table
- truncate the original table
- re-insert the backuped rows
- truncate the backuped table

MAKING MORE ARCHIVE IN MATERIALIZED VIEW

Hi experts,
i created a materialised view and created index on that, but while refreshing the MV it is making more archive log file.
in index i also opted nologging option, still while refreshing it is still creating more archieve files.
what to do so that it should not create more archive while refreshing materlialised view.
thanks

10g to 8i can work, assuming
- 8i = 8.1.7
- You are applying at least the 8.1.7.4 patchset to the master (8i) or you are applying the latest patchset to the slave (10g). Realistically, you probably want to do both.
If you are talking about using the standard edition, I assume that you are only doing basic replication, not multi-master replication. I also assume you are aware of the limitations on hardware that come with Standard Edition 1-- I don't recall if you are limited to machines that have a capacity for 2 or 4 CPU's. Also, be aware that Oracle considers multi-core CPU's as multiple CPU's.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Archive log generating views

our database is running in archive log mode.
i want to know which are the sessions generated/generating(sysdate and sysdate -2) more archive log .
can i get it from the database view???

855516 wrote:
our database is running in archive log mode.
i want to know which are the sessions generated/generating(sysdate and sysdate -2) more archive log .
can i get it from the database view???use v$archived_log/v$log_history
sys@ORCL> select name,completion_time from v$archived_log where completion_time > sysdate-2;
NAME                                                                             COMPLETIO
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000042_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000043_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000044_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000045_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000046_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000048_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000049_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000050_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000051_0776788597.0001                      27-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000052_0776788597.0001                      28-MAR-12
C:\ORACLE\FLASH_RECOVERY_AREA\ARC0000000053_0776788597.0001                      28-MAR-12
11 rows selected.

Are there any possible reason RMAN generates some corrupt archive log files

Dear all,
Are there any possible reason RMAN generates some corrupt archive log files?
Best Regards,
Amy

Because I try to perform daily backup at lunch time and found out it takes more than 1 hour had no any progress. Normally we take around 40 minus. The following is the log file:
RMAN> Run
2> {
3> CONFIGURE CONTROLFILE AUTOBACKUP ON;
4> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u03/db/backup/RMAN/%F.bck';
5> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
6> allocate channel ch1 type disk format '/u03/db/backup/RMAN/backup_%d_%t_%s_%p_%U.bck';
7> backup incremental level 1 cumulative database plus archivelog delete all input;
8> backup current controlfile;
9> backup spfile;
10> release channel ch1;
11> }
12> allocate channel for maintenance type disk;
13> delete noprompt obsolete;
14> delete noprompt archivelog all backed up 2 times to disk;
15>
16>
using target database controlfile instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u03/db/backup/RMAN/%F.bck';
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u03/db/backup/RMAN/%F.bck';
new RMAN configuration parameters are successfully stored
old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
new RMAN configuration parameters are successfully stored
allocated channel: ch1
channel ch1: sid=99 devtype=DISK
Starting backup at 31-MAR-09
current log archived
After that I go to archive log directory "/u02/oracle/uat/uatdb/9.2.0/dbs" and use ls -lt command to see how many archive logs and my screen just hang. After we found out that we cannot use ls -lt command to read arch1_171.dbf
archive log, the rest of archive logs able to use ls -lt command.
We cannot delete this file as well. We shutdown database abort and perform check disk...... and fix the disk error and then open database again. Everything seems back to normal and we can use ls -lt command to read arch1_171.dbf.
The strange problem is we have the same problem in Development and Production..... one ore more archive logs seems to be corrupted under the same directories /u02/oracle/uat/uatdb/9.2.0/dbs.
Does anyone encounter the same problem?
Amy

Archive Logs Suddenly generating more

Hi to all,
My production database is Oracle 9i Enterprise Edition and sitting in Windows Box.
My Average Archive log file generation is 8 files a day. My single log file size is 50 MB.
Suddenly from last month 25th onwards my log files count is
70 on 25th
125 on 26th
120 on 27th
15th on 28th
7 on 29th
83 on 30th
135 on 31st
75 till now today...
How it is possible, I've not enabled single additional oracle feature till this day and my transactions never increased all these days. I dont find any problems in alert log files.
Can you people help me what will be the possible causes.
Please help me in this regard.
Vijay

Vijayaraghavan Krishnan wrote:
Hi to all,
My production database is Oracle 9i Enterprise Edition and sitting in Windows Box.
My Average Archive log file generation is 8 files a day. My single log file size is 50 MB.
Suddenly from last month 25th onwards my log files count is
70 on 25th
125 on 26th
120 on 27th
15th on 28th
7 on 29th
83 on 30th
135 on 31st
75 till now today...
How it is possible, I've not enabled single additional oracle feature till this day and my transactions never increased all these days. I dont find any problems in alert log files.
Can you people help me what will be the possible causes.
Please help me in this regard.
VijayPlease provide more information related to database, parameter, etc.

Archive Logs using more Space

May be you can help me out.
I have resized my redo logs, and when I checked my file system the log switchs were less frequent as expected, however if compared to the same period when the redo logs were smaller(1 hour earlier) the archive logs (db in archive log mode) had doubled the usual capacity on the file system.
Now Im sure Im being stupid here.
I had expect the file system usage would be the same but have bigger but fewer archive logs. I am sure the through put is the same. Is my theory correct, even through the facts are not matching up?

Thanks for confirming my thoughts. I was very surprised when the file system usage had changed and the last change was redo log size adjustment.
It is one of though times when you were the last to touch it and somthing is different you get the blame.
I suspect some process is being run that is generally not start at this time of day. just an unfortunate coincidence.
thanks I thought I was going mad.

How to find out who deleted the archive logs

Hi All,
Recently some archive logs were deleted from one of our servers. Is there any way to find out which user has deleted the archive logs through OS or through database ?
OS Version :-
SunOS Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise
Database Version:-
SQL*Plus: Release 9.2.0.8.0 - Production on Mon Apr 9 01:12:15 2012

888132 wrote:
Hi All,
Recently some archive logs were deleted from one of our servers. Is there any way to find out which user has deleted the archive logs through OS or through database ?
OS Version :-
SunOS Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise
Database Version:-
SQL*Plus: Release 9.2.0.8.0 - Production on Mon Apr 9 01:12:15 2012As explained by others, from oracle database there is no record if they are deleted from OS.
But you can probably find the history of OS command been run with history command :). You can get the date and time.
Following link can help
http://stackoverflow.com/questions/99755/how-do-i-get-the-command-buffer-in-solaris-10
http://www.cyberciti.biz/faq/unix-linux-bash-history-display-date-time/
http://www.linuxquestions.org/questions/solaris-opensolaris-20/in-solaris-command-line-how-to-get-the-previous-commands-573814/
But i suggest you to post in Sun OS forum to get more details as its nothing to do with Database(in this scenario)

How to find a session with high archive logs

Any query, to see which active session is generating high archive logs in oracle 8i &9i and high rbs usage

Though, there is no direct option or view where you can get this information.
However, you may can find out the session which are generating lot of redo and undo. I guess, when the session has lot of redo & undo, definately, it contribution towards archive would be more.
You can query v$sess_io and v$session to findout the the session which is generating lot of redo. i.e. lot of block changes occuring.
SELECT s.sid, s.serial#, s.username, s.program, i.block_changes
FROM v$session s, v$sess_io i
WHERE s.sid = i.sid
ORDER BY 5 desc
Also query v$transaction and v$session to find out the session that is generating lot of undo information.
Jaffar
Message was edited by:
Syed Jaffar

Recover database from archive log: Time based recovery

Hi,
Could you pelase help regarding the following:
I have power outage in my machine running oracle 9i on Solaris OS 9
Oracle is mounted but failed to open
Once it is started showing the error message
SQL> startup;
ORACLE instance started.
Total System Global Area 9457089744 bytes
Fixed Size 744656 bytes
Variable Size 3154116608 bytes
Database Buffers 6291456000 bytes
Redo Buffers 10772480 bytes
Database mounted.
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/opt/oracle/oradata/sysdb/indx/indx01.dbf'
So I tried to recover the database
SQL> recover database;
ORA-00279: change 1652948240 generated at 12/03/2007 13:09:08 needed for thread
1
ORA-00289: suggestion : /opt/oracle/oradata/nobilldb/archive/1_183942.dbf
ORA-00280: change 1652948240 for thread 1 is in sequence #183942
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 1652948816 generated at 12/03/2007 13:09:19 needed for thread
1
ORA-00289: suggestion : /opt/oracle/oradata/nobilldb/archive/1_183943.dbf
ORA-00280: change 1652948816 for thread 1 is in sequence #183943
ORA-00278: log file '/opt/oracle/oradata/nobilldb/archive/1_183942.dbf' no
longer needed for this recovery
The power outage at 16:00pm and the recovery archive log file '/opt/oracle/oradata/nobilldb/archive/1_183942.dbf' at 11 am
Always I am applying the next sequence it is giving the same message and asking the next sequence. I have more than 900 archive log from 11am to 4pm and each of them having the size of 100mb and it take 1 minute to get back from each to provide this error message.
How I can start my recovery from say 15:45 onwards until 16:15?
I have all archive logs in the proper destination.
Still my database is not opened and it is starts applying archive log since 5 hours back, please help me regarding this
Thanks in advance

Wrong forum. Post your question in the following forum:
General Database Discussions

What order are Archive logs restored in when RMAN recover database issued

Ok, you have a run block that has restored your level-0 RMAN backup.
Your base datafiles are down on disc.
You are about to start recovery to point in time, lets say until this morning at 07:00am.
run { set until time "TO_DATE('2010/06/08_07:00:00','YYYY/MM/DD_HH24:MI:SS')";
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
recover database;
So the above runs, it analyses the earlies SCN required for recovery, checks for incremental backups (none here), works out the archivelog range
required and starts to restore the archive logs. All as expected and works.
My question: Is there a particular order that RMAN will restore the archive logs and is the restore / recover process implemented as per the run block.
i.e Will all required archive logs based on the run block be restored and then the database recovered forward. Or is there something in RMAN that says restore these archive logs, ok now roll forwards, restore some more.
When we were doing this the order of the archive logs coming back seemed to be random but obviously constrained by the run block. Is this an area we need to tune to get recoveries faster for situations where incrementals are not available?
Any inputs on experience welcome. I am now drilling into the documentation for any references there.
Thanks

Hi there, thanks for the response I checked this and here are the numbers / time stamps on an example:
This is from interpreting the list backup of archivelog commands.
Backupset = 122672
==============
Archive log sequence 120688 low time: 25th May 15:53:07 next time: 25th May 15:57:54
Piece1 pieceNumber=123368 9th June 04:10:38 <-- catalogued by us.
Piece2 pieceNumber=122673 25th May 16:05:18 <-- Original backup on production.
Backupset = 122677
==============
Archive log sequence 120683 low time: 25th May 15:27:50 Next time 25th May 15:32:24 <-- lower sequence number restored after above.
Piece1 PieceNumber=123372 9th June 04:11:34 <-- Catalogued by us.
Piece2 PieceNumber=122678 25th May 16:08:45 <-- Orignial backup on Production.
So the above would show that if catalogue command you could influence the Piece numbering. Therefore the restore order if like you say piece number is the key. I will need to review production as to why they were backed up in different order completed on production. Would think they would use the backupset numbering and then piece within the set / availability.
Question: You mention archive logs are restored and applied and deleted in batches if the volume of archivelogs is large enough to be spread over multiple backup sets. What determines the batches in terms of size / number?
Thanks for inputs. Answers some questions.

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

Problem about space management of archived log files

Dear friends,
I have a problem about space management of archived log files.
my database is Oracle 10g release 1 running in archivelog mode. I use OEM(web based) to config all the backup and recovery settings.
I config "Flash Recovery Area" to do backup and recovery automatically. my daily backup schedule is every night at 2:00am. and my backup setting is "disk settings"--"compressed backup set". the following is the RMAN script:
Daily Script:
run {
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA$OEM_LEVEL_0';
backup incremental level 1 cumulative copies=1 for recover of copy with tag 'ORA$OEM_LEVEL_0' database;
the retention policy is the second choice, that is "Retain backups that are necessary for a recovery to any time within the specified number of days (point-in-time recovery)". the recovery window is 1 day.
I assign enough space for flash recovery area. my database size is about 2G. I assign 20G as flash recovery area.
now here is the problem, through oracle online manual, it said oracle can manage the flash recovery area automatically, that is, when the space is full, it can delete the obsolete archived log files. but in fact, it never works! whenever the space is full, the database will hang up! besides, the status of archived log files is very strange, for example, it can change "obsolete" stauts from "yes" to "no", and then from "no" to "yes". I really have no idea about this! even though I know oracle usually keep archived files for some longer days than retention policy, but I really don't know why the obsolete status can change automatically. although I can write a schedule job to delete obsolete archived files every day, but I just want to know the reason. my goal is to backup all the files on disk and let oracle automatically manage them.
also, there is another problem about archive mode. I have two oracle 10g databases(release one), the size of db1 is more than 20G, the size of db2 is about 2G. both of them have the same backup and recovery policy, except I assign more flash recovery area for db1. both of them are on archive mode. both of nearly nobody access except for the schedule backup job and sometime I will admin through oem. the strange thing is that the number of archived log files of smaller database, db2, are much bigger than ones of bigger database. also the same situation for the size of the flashback logs for point-in-time recovery. (I enable flashback logging for fast database point-in-time recovery, the flashback retention time is 24 hours.) I found the memory utility of smaller database is higher than bigger database. nearly all the time the smaller database's memory utility keeps more than 99%. while the bigger one's memory utility keeps about 97%. (I enable "Automatic Shared Memory Management" on both databases.) but both database's cup and queue are very low. I'm nearly sure no one hack the databases. so I really have no idea why the same backup and recovery policy will result so different result, especially the smaller one produces more redo logs than bigger one. does there anyone happen to know the reason or how should I do to check the reason?
by the way, I found web based OEM can't reflect the correct database status when the database shutdown abnormally. for example, if the database hang up because of out of flash recovery area, after I assign more flash recovery area space and then restart the database, the OEM usually can't reflect the correct database status. I must restart OEM manually to correctly reflect the current database status. does there anyone know in what situation I should restart OEM to reflect the correct database status?
sorry for the long message, I just want to describe in details to easy diagnosis.
any hint will be greatly appreciated!
Sammy

thank you very much, in fact, my site's oracle never works about managing archive files automatically although I have tried all my best. at last, I made a job running daily to check the archive files and delete them.
thanks again.

Question about import in archive log mode

Hello.
I am a developer, I have ordered to write a script that makes the import of a schema of a database (release 9.2.0.7). That import will be done once a day. I have seen that in my development environment the import creates 54 archivers files (10M aprox. each), that means more that half a Gb a day, it seems too much to me.
I cannot see why all those archivers can be useful. Would a good way of proceeding the following?
1. Forcing an archiver just before the import (I do not know how to do that) so that a backup could be done to the state before the import.
2. Disabling archive log mode during the import and enabling it just after the import (I do not know how to do that).
3. Forcing a new archiver just after the import (I do not know how to do that).
Thanks in advance.

540M is not that much.
One would question why you need to import every day,
there must be better ways to do this.
The three steps you propose look like an awful
scenario, as it would require the database to switch
from archivelog to noarchivelog and vice versa.
This would require the database to close twice a
day.
The scenario is also incomplete as one would need to
take a backup after the import
If you can convince your DBA to close the database
twice a day, he should write the script, which he can
easily derive from the docs.
But likely he will visit Billy Verreynne to borrow
his lead pipe, and rightly so ;)
Sybrand Bakker
Senior Oracle DBAThanks for the answer.
A few things:
- Sorry for my ignorance, I have no experience in database backups, I do not understand why I need to backup just after the import.
- That database is not critical, it is just for a team who will test on that database several applications, so the database will only need to be open during the office schedule.
- I have no dba. The client has a dba for several databases but I have no contact with him/her nor my boss has.

Why the flashback log'size smaller than the archived log ?

hi, all . why the flashback log'size smaller than the archived log ?

Lonion wrote:
hi, all . why the flashback log'size smaller than the archived log ?Both are different.
Flash logs size depends on parameter DB_FLASHBACK_RETENTION_TARGET , how much you want to keep.
Archive log files is dumped file of Online redo log files, It can be either size of Online redo log file size or less depending on online redo size when switch occurred.
Some more information:-
Flashback log files can be created only under the Flash Recovery Area (that must be configured before enabling the Flashback Database functionality). RVWR creates flashback log files into a directory named “FLASHBACK” under FRA. The size of every generated flashback log file is again under Oracle’s control. According to current Oracle environment – during normal database activity flashback log files have size of 8200192 bytes. It is very close value to the current redo log buffer size. The size of a generated flashback log file can differs during shutdown and startup database activities. Flashback log file sizes can differ during high intensive write activity as well.
Source:- http://dba-blog.blogspot.in/2006/05/flashback-database-feature.html
Edited by: CKPT on Jun 14, 2012 7:34 PM

More archive logs

Similar Messages

Maybe you are looking for