Re: Simple archivelog question

"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
Received on Wed Oct 02 2002 - 15:33:04 CDT