Seriously, you "hate this archivelog thing?"
I guess you hate being able to recover a database to a point in time.
Well, I hate it when it gets full and waiting to be freed. But I like it when it can recover to a point in time
Of course everyone hate the bad and I like the good, until vk82 provided the right solution
Woe to the organization which hired you.
Senior Oracle DBA
How did you 'I remove everything in the fast_recovery_area so the size will be free'?
rm -f /u02/oracle/fast_recovery_area/BATCH/archivelogs/*/*
So you blew away any possibility of recovering the database. And for naught, because the database (specifically rman and the archiver) had no way of knowing you did that, and so still believed the FRA was being consumed by those archivelogs that you did not value. And then you compounded the problem by following bad advice and taking your db OUT of archivelog mode.
Do you understand that your database is now totally unrecoverable? Do you understand that it will not be enough to put the db back into archivelog mode, but you must re-establish your backup position by taking a new, full, inc 0 backup AFTER you put the db back into archivelog mode? Do you understand that you you need to be doing regular housekeeping on your FRA by using the documented features of rman?
Yeah I sure do understand that , thats why I did archivelog it again and perform full backup. For the full backup script I have there at the end CROSSCHECK ALL and DELETE OBSOLETE.
That is how I handled the maintenance of files in FRA.
>CROSSCHECK ALL and DELETE OBSOLETE
If you are correctly using the FRA with
d. NOT specifying a FORMAT clause in your BACKUP ARCHIVELOG command (because a FORMAT would override the USE_DB_RECOVERY_FILE_DEST
Oracle would be automatically deleting obsolete files from the FRA when usage hits 90% or 93% (can't remember which).
So, if you are using the FRA correctly, your correct action would be to not rely on your backup script but to *increase* db_recovery_file_dest_size
Hemant K Chitale