Thanks for the info.
JW
"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
news:41ad6ed9$0$24377$afc38c87_at_news.optusnet.com.au...
> John Wood wrote:
> > First, I would like to thankyou for all the advises you guys gave in
this
> > post.
> >
> > I read in some books saying that it would be more efficient for Oracle
if we
> > can configure that the LGWR would do a log switch when CheckPoint. As
the
> > default CheckPoint timeout is 1800, does that mean we better have about
30
> > minutes for the log switch interval ?
>
> The rate at which you wish to switch logs is largely a function of how
> much data you are prepared to lose in a worst-case scenario. The current
> log has never been archived... so if you only switch logs every two
> hours, potentially 1 hour 59.99 minutes-worth of data might be lost if
> the current log were to be deleted or corrupted.
>
> > I plan to have to two Archive Log destination, one will be mandatory at
> > local drive, say drive E; the other will be optional, at a network
mapped
> > drive, say V on a different node. This is just to serve as a backup of
the
> > Archive Log files, as it is recommanded to have two different copies of
> > archive log files.
>
> I know what it is intended to serve as. And I know what's recommended.
> And I'll simply restate that it is NOT recommended, nor actually
> supported, to archive to a remote destination unless you do it with the
> log_archive_dest_n='service=xxx' configuration. Mapped network drives
> don't count.
>
> Don't do it. It will potentially cripple your database's performance,
> and in any case will invalidate any support contract you might have.
>
> > This way I don't have to back up the database using
> > RMAN's command 'backup database plus archivelog', I just need to do
'backup
> > database' to save some time in the backup process.
>
> It is a false economy.
>
> The one thing you don't muck about with in Oracle is backing up
> properly. And mucking about with archiving so that you can muck about
> with backup commands is just asking for trouble.
>
> Stick to what's tried, trusted, supported and (most importantly) safe.
>
> Regards
> HJR
Received on Wed Dec 01 2004 - 08:36:26 CST
