-
Hi,
Can you tell me how to size my archivelog backup sets? I know I can set the max # of files in a backup set, and the max size of the backup set in bytes, but I don't understand the significance of these. It seems I would want my backup set as large as possible so I would have less backupsets to maintain, but what are the constraints I should be aware of? I currently have max files 100 and max kbytes at 500000, but I still get about 20 backup sets a day, which I then have to go back and delete. The list grows so quickly, I would like to make this more manageable.
Looking for suggestions...
Dawn
-
Are you referring to archive redo logs?
-
yes, backup copies of archived redo logs
-
Your question is not totally clear to me.
Your archived redo logs are required by certain backup sets in order to keep the backup sets valid.
-
Remember, that the size of your archive logs will match the size of your online redo logs.
A certain transaction level is going to produce a given level of redo log information. You can choose to archive this in a few large files or many small files, but the amount of information is the same.
I usually think of redo log sizing as it relates to performance not storage, and I try to get my logs to switch about every 1/2 hour. Otherwise you may be checkpointing to frequently, but that again depends on your instance recovery needs which may be better handled by init.ora parameters(fast_start_io, log_checkpoint_interval, etc).
The size of your redo logs is set at database creation but you can adjust dynamically by adding new redo log files with the ADD LOGFILE command and then bringing them online and the older ones offline with ALTER DATABASE. See your doc.
I hope that helps.
-
The size and number of Archive logs will depend upon the amount of redo generated in your database.
There is very little you can do about it except:
(a) Use Nologging mode to insert bulk data into tables (eg during a batch process).
(b) Temporarily turn off archiving when you are making bulk changes in database which you know you can remake changes if some failure happens.
Remember both these options you are compromising recoverability to some extent. So dont forget to take cold backups after these operations.
If you wish to reduce the number of archivelogs generated, you can increase the size of your online redo logs. Since archiving occurs at each log switch, your archive logs will be fewer although bulkier. However remember that you would increase recovery time by having larger online redo logs.
-
Let me try to clarify what I am asking - I am not talking about the size of the archive logs themselves - I am talking about the size of the backupsets that will contain copies of the archivelogs. RMAN allows you to set the max number of archivelogs contained in one backup set. That's what I want to increase, so I don't have so many backupsets to then be deleting as they become obsolete.
Am I making more sense to you?
-
I think you want to remove records of obsolete backup sets from the Recovery Catalog database. If this is not your intent, I apologize for wasting your time.
Look at the script rman1.sh located in
/$ORACLE_HOME/rdbms/demo
You can edit it to fit your needs and then delete all of the old records automatically.
You can also adjust the filesperset parameter to create more (or fewer) backup files. It is useful if you are trying to decrease the file size to stay under your OS limit.
Hope that helps.
[Edited by dknight on 09-18-2001 at 11:11 AM]
-
Have you tried looking through the online Oracle docs at http://tahiti.oracle.com ? They've got a great search feature that may really help you figure out exactly what you're looking for.
-
Thanks I checked out the script - it is only for backups of datafiles, not archivelogs, but I can still use it for my datafile backups. I will check out the online docs for 8i. Thanks for your help.
I think you answered my question - the only constraint on the size of the backupsets is what my OS will allow for a file.
I think I can safely increase the size of my backupsets like I want to. Thanks again.
Dawn
