Re: What is the size of arc files

rhugga_at_yahoo.com (Keg) wrote in message news:<6c795a35.0410050503.6960010d_at_posting.google.com>...
> fitzjarrell_at_cox.net (David Fitzjarrell) wrote in message news:<9711ade0.0410042045.6423cef1_at_posting.google.com>...
> > 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.
>
> Well I was assuming he wanted this info for projecting long term
> storage requirements and thus you wouldn't care about X number of
> archive logs being Y Kb smaller.
>

That is not a valid reasoning for offering an incomplete answer to his question. Archived logs are not identical copies of the redo logs, they are copies of the completed transactions contained therein. It is just as likely an archived log will be smaller than the redo log it was copied from for reasons of space or a forced log switch. Your reponse could give the OP a reason to question archived logs smaller than his redo logs as either being incomplete or, possibly, a bug in Oracle (which is usually the first cry from someone whose understanding of Oracle is lacking). The OP is confused enough as evidenced by his post; don't create more confusion with incomplete or incorrect responses.

> >
> > > >
> > > > 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.
>
> Yea, his question was another "How long is a piece of string" type
> query, so there was no way to answer it correctly. I just gave him an
> idea to work on and assumed system defaults since he made no reference
> to changing them.
>

Yes, it CAN be answered correctly, and I beiieve I did a better job of that than you did, and I did so with a far more complete response.  

> >
> > > >
> > > > 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.
>
> Yea, weekly test restores are a part of our backup strategy, as it
> should be at any shop. (well any shop where someone cares enough about
> keeping their job) This is what interns are for. Our hotbackups are
> also copied to a NAS device and kept for up to 1 month. The only
> reason we keep hotbackups/archive indefintely is for FDA purposes.
> (since this is data used in the research of drugs and etc...) My
> current shop would rarely have the need to restore to any point in
> time, since most data can be easily re-created as long as the data
> sets are still on disk. (ie: waiting 1 year to re-create a data sets
> would not be possible, since these data sets are sometimes 1+ TB)
>

Your cavalier attitued toward your interns is ill-placed. It's YOUR job, not your intern's. The intern does what he or she is told, and it's your responsibility to instruct them properly. Do not palm off onto an intern something which is your responsibility.  

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

David Fitzjarrell Received on Tue Oct 05 2004 - 13:32:18 CDT