Re: What is the size of arc files

Comments embedded.

rhugga_at_yahoo.com (Keg) wrote in message news:<6c795a35.0410040910.6be5b894_at_posting.google.com>...
> 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..)
>

Not entirely true. The LARGEST the archive logs could be is the defined size of the redo logs; they can be smaller as there may not be enough space in the current redo log to place the next transaction to hit the database, wnich causes a logfile switch to take place, making the archived transaction size smaller than the declared size of the log.

> >
> > 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)
>

Again, not necessarily true. The max_dump_file_size parameter, if set, determines the size of .trc files. If the default of UNLIMITED is used then it is an operating system dependent limit, and Oracle will happily write to each .trc file up until the operating system says halt; if not, then Oracle will cease writing to a trace file when the size set for max_dump_file_size has been reached.

> >
> > 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)
>

Let us hope you regularly check the usability of those tapes to ensure you don't end up with doorstops when the need is urgent. And, let us hope you check those tapes immediately after they are written, again to ensure you have a tape you can use should tne occasion arise.  

> Hope this helps.
> > suggestion will be of great help to me.
> >
> > Regards
> > Umesh

David Fitzjarrell Received on Mon Oct 04 2004 - 23:45:27 CDT