About automatic disappearance of Redo log file

I had free Oracle9i Release 1(9.0.1) CD and I installed Oracle9i on my PC.
When using Database assistant to create a database(I choose not to create a database during installation of 9i), after clone of database, it will start database, error comes.
It says: Error write to redo01.log file, I check that file, it existed in the related folder, while at that time it disappears, once I had redo01, 02, 03 log file. It confused me.
Does anyone give something on that?
Thanks.

Well, seriously you need to read basic oracle documents.
To give short answers to your question.
Redo logs are required for instance and crash recovery of your system.
You need to have minimum two redo groups with minimum one redo member for each group. They are written in a circular fashion, i.e. one after one. If you maintain your database in archivelog mode, before rewriting/reusing the filled redo group member, that will be archived through arch process to a archive file, this can be used for database recovery.
Every database must required two redo groups and you can't delete them.
Jaffar

Similar Messages

Question about how Oracle manages Redo Log Files

Good morning,
Assuming a configuration that consists of 2 redo log groups (Group A and B), each group consisting of 2 disks (Disks A1 & A2 for Group A and Disks B1 and B2 for group B). Further, let's assume that each redo log file resides by itself in a disk storage device and that the device is dedicated to it. Therefore in the above scenario, there are 4 disks, one for each redo log file and, each disk contains nothing else other than a redo log file. Furthermore, let's assume that the database is in ARCHIVELOG mode and that the archive files are stored on yet another different set of devices.
sort of graphically:
    GROUP A             GROUP B
      A1                  B1
      A2                  B2The question is: When the disks that comprise Group A are filled and Oracle switches to the disks in Group B, can the disks in Group A be taken offline, maybe even physically removed from the system if necessary, without affecting the proper operation of the database ? Can the Archiver process be temporarily delayed until the disks (that were removed) are brought back online or is the DBA forced to wait until the Archiver process has finished creating a copy of the redo log file into the archive ?
Thank you for your help,
John.

Hello,
Dropping Log Groups
To drop an online redo log group, you must have the ALTER DATABASE system privilege. Before dropping an online redo log group, consider the following restrictions and precautions:
* An instance requires at least two groups of online redo log files, regardless of the number of members in the groups. (A group is one or more members.)
* You can drop an online redo log group only if it is inactive. If you need to drop the current group, first force a log switch to occur.
* Make sure an online redo log group is archived (if archiving is enabled) before dropping it. To see whether this has happened, use the V$LOG view.
SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;
GROUP# ARC STATUS
1 YES ACTIVE
2 NO CURRENT
3 YES INACTIVE
4 YES INACTIVE
Drop an online redo log group with the SQL statement ALTER DATABASE with the DROP LOGFILE clause.
The following statement drops redo log group number 3:
ALTER DATABASE DROP LOGFILE GROUP 3;
When an online redo log group is dropped from the database, and you are not using the Oracle Managed Files feature, the operating system files are not deleted from disk. Rather, the control files of the associated database are updated to drop the members of the group from the database structure. After dropping an online redo log group, make sure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped online redo log files.
When using Oracle-managed files, the cleanup of operating systems files is done automatically for you.
Your Database wont be affected as you can operate with 2 redo log files in each group as The minimum number of redo log files required in a database is two because the LGWR (log writer) process writes to the redo log files in a circular manner. so the process will hang becuase you are having 2 only groups if you want to remove 1 add a third one and make it the current group then remove the one you want to be offline.
Please refer to:
http://download.oracle.com/docs/cd/B10500_01/server.920/a96521/onlineredo.htm#7438
Kind regards
Mohamed
Oracle DBA

Need to understand when redo log files content is wrote to datafiles

Hi all
I have a question about the time when redo log files are wrote to the datafiles
supposing that the database is in NOARCHIVELOG mode, and all redo log files are filled, the official oracle database documentation says that: *a filled redo log file is available
after the changes recorded in it have been written to the datafiles* witch mean that we just need to have all the redo log files filled to "*commit*" changes to the database
Thanks for help
Edited by: rachid on Sep 26, 2012 5:05 PM

rachid wrote:
the official oracle database documentation says that: a filled redo log file is available after the changes recorded in it have been written to the datafiles It helps if you include a URL to the page where you found this quote (if you were using the online html manuals).
The wording is poor and should be modified to something like:
<blockquote>
+"a filled online redo log file is available for re-use after all the data blocks that have been changed by change vectors recorded in the log file have been written to the data files"+
</blockquote>
Remember if a data block that is NOT an undo block has been changed by a transaction, then an UNDO block has been changed at the same time, and both change vectors will be in the redo log file. The redo log file cannot, therefore, be re-used until the data block and the associated UNDO block have been written to disc. The change to the data block can thus be rolled back (uncommitted changes can be written to data files) because the UNDO is also available on disc if needed.
If you find the manuals too fragmented to follow you may find that my book, Oracle Core, offers a narrative description that is easier to comprehend.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: Oracle Core

Dataguard Solution for standby redo log file groups

Respected Experts,
My database version is 10.2.0.1.0 and Red Hat 5 os.I want to create a standby database using RMAN.
Can any one help me with the full steps.And i'm also confuse about number of standby redo log file members
need to be created.
Thanks and Regards
Monoj Das

My database version is 10.2.0.1.0 and Red Hat 5 os.I want to create a standby database using RMAN.To configure standby either you can use duplicate target database for standby
or
1) restore standby controlfile
2) mount standby database
3) restore database
and configure standby paraemter then start MRP, will do.
http://docs.oracle.com/cd/B19306_01/server.102/b14239/create_ps.htm
Can any one help me with the full steps.And i'm also confuse about number of standby redo log file members
need to be created.It depends which parameter you want to use, if you mention log_archive_dest_2='service ARCH ' then no need to create any standby redo log file groups,
If you use log_archive_dest_2='service LGWR ' here transport will be in terms of redo and you need standby redo log files on standby database. Which is realtime.
When you use LGWR, data lost will be less if in case of any online redo log file lost. which is recommended.
HTH.

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.

Removing Redo Log Files? What's Normal?

Hello,
I'm new to Oracle and I've been using Informix for years. We currently have Oracle 9.2 running on Windows 2000 Server machine and apparently the redo log files keep filling up the disk drives they reside on. This is happening about every two weeks since we go out and delete the files when we remember.
My question is does Oracle have a "normal" way of removing old redo logs automatically rather than having to remove them manually? In the Informix world I can set the logical logs so that they write over previously used logs once they are no longer used. Is there a similar way to configure Oracle?
Thanks for helping out.
Gregg Walker

Do not delete your old log files: you need them.
That's how Oracle does recovery when you lose a datafile or a drive. You copy over the missing stuff from your back-up and then Oracle re-applies the chnages from the REDO logs thereby bringing your database back up to date. No work lost. Result!
Of course, if you don't take up a backup then holding on to REDO logs is pointless. In which case, set the database to run in NOARCHIVELOG mode.
However, I strongly advise you to run in ARCHIVELOG mode. You may find this part of the administrator's guide informative: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/archredo.htm#4553
Cheers, APC

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

Oracle standby/redo log file shipping keeps needing logs re-registering

Hi
We have Log File Shipping enabled and the prod system ships redo logs over to the LFS server. It's kept 24 hours behind. It usually ships the logs (and I believe automatically registers them) without issue.
EXCEPT - it keeps complaining about missing redo log files.
The file is usually there; but just needs registering with:
alter database register or replace logfile '/oracle/S1P/saparch/S1Parch1_636443_654987192.dbf';
(we found if we left out the 'or replace' it takes a very long time or even hangs)
It then plods on and applies the next... can go for another 2 or 3... or 20... but then often gets stuck again, and you need to register the next.
Can spend whole days on this...!!
We did try running a script to register the next 1365 redo logs! It failed on 4, so I ran it again... it worked on those 4, but turned up 3 others it had worked with before! HUH?!? So manually did those 3 ... fine... it carried on rolling forward... but got stuck after 10 minutes again when it hit another it reckoned needed registering (we'd already done it twice!!).
Any ideas?
Ross

Hi
We have Log File Shipping enabled and the prod system ships redo logs over to the LFS server. It's kept 24 hours behind. It usually ships the logs (and I believe automatically registers them) without issue.
EXCEPT - it keeps complaining about missing redo log files.
The file is usually there; but just needs registering with:
alter database register or replace logfile '/oracle/S1P/saparch/S1Parch1_636443_654987192.dbf';
(we found if we left out the 'or replace' it takes a very long time or even hangs)
It then plods on and applies the next... can go for another 2 or 3... or 20... but then often gets stuck again, and you need to register the next.
Can spend whole days on this...!!
We did try running a script to register the next 1365 redo logs! It failed on 4, so I ran it again... it worked on those 4, but turned up 3 others it had worked with before! HUH?!? So manually did those 3 ... fine... it carried on rolling forward... but got stuck after 10 minutes again when it hit another it reckoned needed registering (we'd already done it twice!!).
Any ideas?
Ross

Backup vs redo log files

Hi,
Can anyone tell me what's the real difference between a backup file and a redo log file/archived redo log file and the scenarios (examples) when each of them can be used (for example, "......") ? Both are used for database/instance recovery. I have read the concepts of there 2 terms, but I need some additional information about the difference.
Thanks!

Roger25 wrote:
What i still don't understand is how redo mechanism works; I know, redo logs records changes made to the database and it's used to re-do informations in case of a system failure/crash, for example. Ok, let's say I have a huge update, but when the system crash has occured, the transaction is neither comitted, nor rolled back. Then, how this redo is useful? If a system crash occur, all those updates aren't rolled back automatically? So the database state is as before executing that huge update? So in this case, 'what to redo'?No, with the system's crash, the transaction never gets a chance to get committed (and even rolled back) because a commit is only supposed to happen if there is an explicit or implicit commit statement is issued. Now, for the redo , with the statement, a commit marker is entered at the end of the redo stream of that transaction denoting that it's finally over now and for the corresponding transaction, the status is cleared from the transaction table that's stored in the Undo segment in which the Undo information of that transaction is stored. If you have given a huge update, the redo would be very highly required as you should be knowing that it's not all the time that the dirty buffers that are written to the data files unlikely the redo log files which are written every 3 econds. This means, there is a very fair chance that many changes have yet not even propagated to the data files for which the change vectors are now already there in the redo log files. Now, for the sake of clarity, assume that this transaction was actually committed! So now, without those changes be applied to the data files how Oracle can actually show the committed reults when the database next time would be opened? For this purpose, the redo change vectors are required. And for the uncommitted transactions , the applcation of the redo change vectors would keep on updating the Checkpoint numbers of the data files and would eventually get them synched with the control file and redo log files, without which the database would never be opened.
HTH
Aman....

How to remove a redo log file

Hi Experts,
I want to remove a wrong redo log file from 10G R2 database in window.
how to do that without loss data?
my steps as
1. alter system switch logfile;
2. select * from v$log;
which ARC and sataus do I can drop redo log file based on above SQL
no archive and active status?
ALso Which account should I do above action?
fExamp, system account added redo log file, i only
can drop by system? how about sys?
Thanks help in detail steps
Jim
Edited by: user589812 on Dec 23, 2008 4:35 PM

Jim,
Check this link out for how to drop a redo log file
Make sure a redo log group is archived (if archiving is enabled) before dropping it. To see whether this has happened, use the V$LOG view.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/onlineredo.htm#i1006489
SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;
   GROUP# ARC STATUS
        1 YES ACTIVE
        2 NO CURRENT
        3 YES INACTIVE
        4 YES INACTIVE
Drop a redo log group with the SQL statement ALTER DATABASE with the DROP LOGFILE clause.
The following statement drops redo log group number 3:
ALTER DATABASE DROP LOGFILE GROUP 3;

Restore in noarchivelog mode ( redo log files have been dropped )

1, A full backup taken using RMAN is available on disk.
2, The current control files were NOT damaged and do not need to be restored.
3, All data files are damaged .
4, The database is in NOARCHIVELOG mode.
I restore database :
1. RMAN> STARTUP MOUNT
2. RMAN> RESTORE DATABASE;
3. RMAN> recover database;
in this step , I got the information about needing redo log files ; but the redo log
files have been dropped , what should i do ?
else
I want to know there is the command 'recover database using backup control file'
in rman or not ?
Tks

Possibly loss of data (because information in online redo logs is lost):
recover database until cancel;
(cancel immediately)
alter database open resetlogs; (to build a new set of redo logs)
It's not necessary to use a backup controlfile here.

Why it automatically recover current redo log in RMAN command window?

Firstly, I restore controlfile and datafiles from a backupset.
Then when I recover database in RMAN command window like below:
RMAN> recover database;
Starting recover at 15-AUG-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
starting media recovery
archive log thread 1 sequence 9 is already on disk as file /u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_9_90sd0slz_.arc
archive log thread 1 sequence 10 is already on disk as file
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_10_90sd0tsb_.arc
archive log thread 1 sequence 11 is already on disk as file
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_11_90sd110b_.arc
archive log thread 1 sequence 12 is already on disk as file
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_12_90sd2ksr_.arc
archive log thread 1 sequence 13 is already on disk as file
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_13_90sd2mc6_.arc
archive log thread 1 sequence 14 is already on disk as file
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_14_90sd2qrm_.arc
archive log thread 1 sequence 15 is already on disk as file
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_15_90sd2s0w_.arc
archive log thread 1 sequence 16 is already on disk as file /u01/app/oracle/oradata/lonion/redo03.log
archive log filename=/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_9_90sd0slz_.arc thread=1 sequence=9
archive log filename=/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_10_90sd0tsb_.arc thread=1 sequence=10
archive log filename=/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_11_90sd110b_.arc thread=1 sequence=11
archive log filename=/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_12_90sd2ksr_.arc thread=1 sequence=12
archive log filename=/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_13_90sd2mc6_.arc thread=1 sequence=13
archive log filename=/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_14_90sd2qrm_.arc thread=1 sequence=14
archive log filename=/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_15_90sd2s0w_.arc thread=1 sequence=15
archive log filename=/u01/app/oracle/oradata/lonion/redo03.log thread=1 sequence=16
media recovery complete, elapsed time: 00:00:04
Finished recover at 15-AUG-13
RMAN>
But, when I recover database in SQL*Plus command window like below:
[oracle@lonion ~]$ uniread sqlplus /nolog
[uniread] Loaded history (2178 lines)
SQL*Plus: Release 10.2.0.1.0 - Production on Thu Aug 15 19:25:38 2013
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn /as sysdba
Connected.
SQL>
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
SQL> recover database using backup controlfile;
ORA-00279: change 2147842454 generated at 08/15/2013 18:34:28 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_9_%u_.a
rc
ORA-00280: change 2147842454 for thread 1 is in sequence #9
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 2147842651 generated at 08/15/2013 18:40:25 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_10_%u_.
arc
ORA-00280: change 2147842651 for thread 1 is in sequence #10
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_9_90sd
0slz_.arc' no longer needed for this recovery
ORA-00279: change 2147842653 generated at 08/15/2013 18:40:26 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_11_%u_.
arc
ORA-00280: change 2147842653 for thread 1 is in sequence #11
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_10_90s
d0tsb_.arc' no longer needed for this recovery
ORA-00279: change 2147842656 generated at 08/15/2013 18:40:32 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_12_%u_.
arc
ORA-00280: change 2147842656 for thread 1 is in sequence #12
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_11_90s
d110b_.arc' no longer needed for this recovery
ORA-00279: change 2147842684 generated at 08/15/2013 18:41:21 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_13_%u_.
arc
ORA-00280: change 2147842684 for thread 1 is in sequence #13
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_12_90s
d2ksr_.arc' no longer needed for this recovery
ORA-00279: change 2147842686 generated at 08/15/2013 18:41:23 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_14_%u_.
arc
ORA-00280: change 2147842686 for thread 1 is in sequence #14
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_13_90s
d2mc6_.arc' no longer needed for this recovery
ORA-00279: change 2147842689 generated at 08/15/2013 18:41:27 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_15_%u_.
arc
ORA-00280: change 2147842689 for thread 1 is in sequence #15
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_14_90s
d2qrm_.arc' no longer needed for this recovery
ORA-00279: change 2147842691 generated at 08/15/2013 18:41:28 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_16_%u_.
arc
ORA-00280: change 2147842691 for thread 1 is in sequence #16
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_15_90s
g0or9_.arc' no longer needed for this recovery
ORA-00279: change 2147842986 generated at 08/15/2013 19:14:29 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_17_%u_.
arc
ORA-00280: change 2147842986 for thread 1 is in sequence #17
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_16_90s
g0os5_.arc' no longer needed for this recovery
ORA-00308: cannot open archived log
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_17_%u_
.arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
SQL> recover database using backup controlfile;
ORA-00279: change 2147842986 generated at 08/15/2013 19:14:29 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_08_15/o1_mf_1_17_%u_.
arc
ORA-00280: change 2147842986 for thread 1 is in sequence #17
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/lonion/redo01.log ---- Yon see, proceeding this process, it can't automatically apply the current redo log.
Log applied.
Media recovery complete.
SQL>
Question Coming:
Now, my question is that 「Why it automatically recover current redo log in RMAN command window but not in SQL*Plus」?
BTW: Please pay attention to the red font.

It also seems not work.
SQL> recover automatic database using backup controlfile;
ORA-00279: change 2148632889 generated at 09/26/2013 12:45:22 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_09_26/o1_mf_1_48_%u_.
arc
ORA-00280: change 2148632889 for thread 1 is in sequence #48
ORA-00278: log file
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_09_26/o1_mf_1_48_%u_
.arc' no longer needed for this recovery
ORA-00308: cannot open archived log
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_09_26/o1_mf_1_48_%u_
.arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_09_26/o1_mf_1_48_%u_
.arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log
'/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_09_26/o1_mf_1_48_%u_
.arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file
or directory
Additional information: 3
SQL>
It must specify the redo log.
SQL> recover database using backup controlfile;
ORA-00279: change 2148632889 generated at 09/26/2013 12:45:22 needed for thread
1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/LONION/archivelog/2013_09_26/o1_mf_1_48_%u_.
arc
ORA-00280: change 2148632889 for thread 1 is in sequence #48
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/lonion/redo02.log
Log applied.
Media recovery complete.
SQL>

Hoping for a quick response : EXP and Archived REDO log files

I apologize in advance if this question has been asked and answered 100 times. I admit I didn't search, I don't have time. I'm leaving on vacation tomorrow, and I need to know if I'm correct about something to do with backup / restore.
we have 10g R2 running a single instance on a single server. The application vendor has "embedded" oracle with their application. The vendor's backup is a batch file using EXP - thus:
exp system/xpwdxx@db full=y file=D:\Orant\admin\db\EXP\db_full.dmp log=D:\Orant\admin\db\EXP\db_full.txt direct=y compress=y
This command is executed nightly at midnight. The files are then backed up by our nightly backup to offsite storage media.
Te database is running in autoarchive mode. The problem is, the archived redo files filled the drive they were being stored on, and it is the drive the database is on. I used OS commands to move 136G of archived redo logs onto other storage media to free the drive.
My question: Since the EXP runs at midnight, when there is likely NO activity, do I need to run in AutoArchive Mode? From what I have read, you cannot even apply archived redo log files to this type of backup strategy (IMP) Is that true? We are ok losing changes since our last EXP. I have read a lot of stuff about restoring consistent vs. inconsistent, and just need to know: If my disk fails, and I have to start with a clean install of Oracle and nothing else, can I IMP this EXP and get back up and running as of the last EXP? Or do I need the autoarchived redo log files back to July 2009 (136G of them).
Hoping for a quick response
Best Regards, and thanks in advance
Bruce Davis

Bruce Davis wrote:
Amardeep Sidhu
Thank you for your quick reply. I am reading in the other responses that since I am using EXP without consistent=y, I might not even have a backup. The application vendor said that with this dmp file they can restore us to the most recent backup. I don't really care for this strategy as it is untested. I asked them to verify that they could restore us and they said they tested the dmp file and it was OK.
Thank you for taking the time to reply.
Best Regards
BruceThe dump file is probably ok in the sense it is not corrupted and can be used in an imp operation. That doesn't mean the data in it is transactionally consistent. And to use it at all, you have to have a database up and running. If the database is physically corrupted, you'll have to rebuild a new database from scratch before you can even think about using your dmp file.
Vendors never understand databases. I once had a vendor tell me that Oracle's performance would be intolerable if there were more than 5 concurrent connections. Well, maybe in HIS product ..... Discussions terminated quickly after he made that statement.

Moving the online redo log files to different location

We just installed few more drives into our sandbox system and I want to move the online redo log files for better performance. We've got the SAPARCH directory moved to a different location.
Does anyone know how/where I can change the parameters so redo log files are pointed at different drives? It's not in the init<SID>.ora file...
Regards,
Sumit

Hi Sumit,
The following link contains information about moving the redo logs:
http://www.stanford.edu/dept/itss/docs/oracle/9i/server.920/a96521/onlineredo.htm
Best regards,
Alwin

Online redo log files being removed physically

Grid Infra version: 11.2.0.4
RDBMS Version: 11.2.0.4
Although this is a RAC DB, this is not a RAC-specific question. Hence posting it here.
Few months back, I remember issuing a command similair to below (DROP LOGFILE GROUP ...) and the redo log files were still physically present in the diskgroup.
If I remember correctly, the file is not deleted physical so that we can use the REUSE functionality (ALTER DATABASE ADD LOGFILE MEMBER '+REDO/orcl/onlinelog/redo1b.log' reuse to group 11; ) ie. you can use the REUSE command to add the logfile of the same name which is physically present in OS Filesystem/Diksgroup to redo log group.
But today, after I issued the below command, I checked the diskgroup location from ASMCMD
SQL> alter database drop logfile group 31;
Database altered.
From ASMCMD, I can that the file has disappeared physically. Is this a new feature with 11.2.0.4 or am I missing something here ?
ASMCMD> ls +DATA/msblprd/onlinelog/group_31.548.833154995
ASMCMD-8002: entry 'group_31.548.833154995' does not exist in directory '+DATA/msblprd/onlinelog/'

Just to add to what Aman has said.
It is a bad practice not to let OMF decide the placement of Online redo logs because of this issue especially when you use ASM.
Executing rm command in Linux/Unix is easy but Dropping ASM aliases in the disk group can be a hassle.
This is documented.
"When a redo log member is dropped from the database, the operating system file is not deleted from disk. Rather, the control files of the associated database are updated to drop the member from the database structure. After dropping a redo log file, ensure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log file."
http://docs.oracle.com/cd/E11882_01/server.112/e25494/onlineredo.htm#ADMIN11324
BTW . You don't even need to set db_create_online_log_dest_n to enable OMF for ORLs.
SQL> show parameter log_dest
NAME                                 TYPE        VALUE
db_create_online_log_dest_1          string
db_create_online_log_dest_2          string
db_create_online_log_dest_3          string
db_create_online_log_dest_4          string
db_create_online_log_dest_5          string
SQL> show parameter db_create_file_dest
NAME                                 TYPE        VALUE
db_create_file_dest                  string      +MBL_DATA
alter database add logfile thread 4
group 31 ('+MBL_DATA','+MBL_FRA') size 4096M,
group 32 ('+MBL_DATA','+MBL_FRA') size 4096M,
group 33 ('+MBL_DATA','+MBL_FRA') size 4096M,
group 34 ('+MBL_DATA','+MBL_FRA') size 4096M ;
Database altered.
And redo logs will be neatly placed as shown below
   INST     GROUP# MEMBER                                             STATUS           ARC
         4         31 +MBL_DATA/bsblprd/onlinelog/group_31.276.832605441 UNUSED           YES
                      +MBL_FRA/bsblprd/onlinelog/group_31.297.832605445 UNUSED           YES
                   32 +MBL_DATA/bsblprd/onlinelog/group_32.547.832605451 UNUSED           YES
                      +MBL_FRA/bsblprd/onlinelog/group_32.372.832605457 UNUSED           YES
                   33 +MBL_DATA/bsblprd/onlinelog/group_33.548.832605463 UNUSED           YES
                      +MBL_FRA/bsblprd/onlinelog/group_33.284.832605469 UNUSED           YES
                   34 +MBL_DATA/bsblprd/onlinelog/group_34.549.832605475 UNUSED           YES
                      +MBL_FRA/bsblprd/onlinelog/group_34.359.832605481 UNUSED           YES

About automatic disappearance of Redo log file

Similar Messages

Maybe you are looking for