 problem about space management of archived log files [message #130241] |
Thu, 28 July 2005 23:32  |
samwzm
Messages: 2
Registered: July 2005
|
Junior Member |
|
|
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
|
|
|
|
| Re: problem about space management of archived log files [message #130333 is a reply to message #130241] |
Fri, 29 July 2005 07:22  |
smartin
Messages: 1803
Registered: March 2005
Location: Jacksonville, Florida
|
Senior Member |
|
|
I can't help you with OEM, or with flash recovery area, but I can tell you that the size of your archive log files will be based on the size of your redo log files. So if your redo log file size is different on the two databases, that will explain why your numbers of archived logs are different. Perhaps you have more files on one database but each file is smaller.
And never apologize for providing long messages and details of the situation, it is those details which give people enough info to help (if they can). Oh and it generally doesn't hurt to check out bug fixes for patches on metalink, in case what you are experiencing is a known and/or fixed bug.
Oh and with a 2 gig database, and 20 gig available for backups and archive logs, you should be able to have a much longer retention and point in time recovery availability than one day.
|
|
|
|
| Re: problem about space management of archived log files [message #130375 is a reply to message #130333] |
Fri, 29 July 2005 10:55 |
samwzm
Messages: 2
Registered: July 2005
|
Junior Member |
|
|
thank you very much, smartin!
I am sorry that I didn't make it clear about flash recovery area space problem. in fact, the archived files' size of both the database are the same. because the archived file's number of the smaller db is much more than ones of the bigger db, so the smaller db consumes flash recovery area much faster than the bigger one.
thanks again,
sammy
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
