Re: What is the size of arc files

umeshoracle_at_yahoo.com (U C) wrote in message news:<fd94e273.0410032325.9a5d7bd_at_posting.google.com>...
> Hi All,
> I would like to know few things from about different log files:
>
> 1) What is the size of arc file. When it creates new files and what is
> the maximum size that it can have.

This will be identical to your log file size which was defined when the database was created. I think dbca defaults to 10MB but some environments will have them much larger. The idea is to size them to where you get a log switch every 15 minutes or so. After about 1 week of normal usage, look at the file times of your archive logs and you can tell how frequently they are switching. On one of my databases we found our magic number to be 100MB. (giving us a log switch every 20 minutes or so, approx..)

>
> 2) What is the size of trc files. When it creates new files and what
> is the maximum size that it can have.

Well the udump trace files are normally small and depends on how large your database is (excluding any error spamming, etc....). Since it usually contains the commands to re-create the database (if added as a step to the hot backup), each datafile will cause the file to be slightly larger) However, errors will cause these file to grow as well, but there is no 'correct' answer to how large they can get. I would assume as large as the filesystem that houses them. (if 2+gb file sizes are supported on your platform)

>
> 3) What is the size of core folder and how many files can be in each
> core folder and of what size.

I'm not 100% here but I would assume this would be related to the size of your SGA. (Since it should contain a dump of oracle's memory segments)
>
> 4) If i am having nearly 250000 transaction a day then what will be
> size of my arch, core and trc.

This will also vary greatly depending upon your database. If those 250k transactions are just updating a user login table, then you will not have much redo, however, if these 250k transactions are doing heavy inserts/updates of large amounts of data, then your redo will be greater. Your logs contain every change to the database before it is actually considered a complete transaction.

One thing to note, however, is you don't want to create any I/O contention, that is more important than a log switch every 15 minutes. Ideally you should have dedicated log disks if you have the luxury of several luns. (look at Oracle's OFA, it goes into this a little) On my heavy I/O database I have 4 logical disks for my logging, 2 log groups, 2 members each. With this config there is never 'double I/O' on the same disk, the arch process is copying from an idle disk and the log writer process is writing to an idle disk. (and thus it rotates in this manner) This is an extreme case of I/O tuning and probably a bit overkill but I had the spare Luns so no biggie.

Also one thing about accumilation of archive logs, you only need to keep the logs since your last hot backup. (unless you want more granularity in your ability to restore to any point in time) I do a nightly hot backup and keep hot backups plus archive logs for the last week on local disk. (during this time they are archived to tape and kept indefinitely)

Hope this helps.
> suggestion will be of great help to me.
>
> Regards
> Umesh
Received on Mon Oct 04 2004 - 12:10:55 CDT