Re: Simple archivelog question

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:<lCIm9.44961$g9.127980_at_newsfeeds.bigpond.com>...
> "Charlie Edwards" <charlie3101_at_hotmail.com> wrote in message
> news:217ac5a8.0210020855.775df0a2_at_posting.google.com...
> > I'm not a DBA, so I tend to not worry about the intricacies of backup
> > and recovery, leaving that to those more qualified.
> >
> > However, I rather suspect that my database is not in archivelog mode.
> >
> > How can I tell (bearing in mind I don't have access to V$DATABASE :-()
> > whether this is the case? The background processes in V$SESSION
> > perhaps?
> >
>
> Does that mean you don't have any V$ privileges? Because you might try
> v$archive_processes (depending on your version). You could try typing
> 'archive log list' in sqlplus. You could grep for the arch process(es) if on
> a Unix box. You could get your hands on the init.ora and see whether
> 'log_archive_start' has been set to true (actually, most of these tell you
> that ARCH is switched on, not whether you are in archivelog mode, and the
> two are not necessarily related... but we presume that on a properly-managed
> database, your DBA would not have been daft enough to do the one without
> arranging for the other).
>
> Also try and see what the 'log_archive_dest' parameter is set to, and then
> check the contents of that directory, and look at the time stamps to see if
> fresh archives are being produced.
>
> > These days, is there a good reason for _not_ running in archivelog
> > mode?
>
> Yes, it's an overhead. Which means that you can compromise performance by
> archiving. As ever, you can have absolute performance, or absolute security,
> but not both at the same time: you have to pick a point on the balance
> between the two where you are happy.
>
> If this was a training database, you probably don't care about being able to
> recover, so you'd swing far over to the performance side of the equation,
> and to hell with archiving. If this was a development database, perhaps the
> same sort of thing would be true, and you'd just take cold backups.
>
> If this was a production database where some data loss could be tolerated,
> you might also forget about archiving and just take cold backups.
>
> If this was a production database where no data loss could be tolerated, or
> where there was no downtime permitted for taking cold backups, then you'd
> definitely have to switch ARCH on.
>
> It's all a question of knowing what's at risk without archiving, and what
> the costs are with it, and then working out whether you are prepared to take
> the risks, or pay the costs.
>
> Regards
> HJR
>
>
>
> >
> > Thanks,
> >
> > CE

Thanks for your help on this.

I am a bit curious as to the performance issue, however.

Tom Kyte (http://asktom.oracle.com/pls/ask/f?p=4950:8:1382355) says: <quote>
Archive logging, in a properly configured system, adds 0% performance degradation. It is all about IO. If you have the right number of devices and
IO channels -- no worries, no "degradation". </quote>

I guess the key is having a sufficient hardware configuration so that the IO issues will be minimised.

But I suppose, as you say, "you can compromise performance by archiving" if your hardware isn't up to it (which is possibly the case here).

Thanks,

CE Received on Thu Oct 03 2002 - 04:06:36 CDT