Re: Implementing Archiving of Redo logs some more questions

On Fri, 14 Feb 2003 13:43:48 +0000, mokat6 wrote:

> Can someone give me an answer on the following:
>
> 1- Does it has any impact if the database (8i) is running in NO
> ARCHIVE mode but the init.ora parameter set >> LOG_ARCHIVE_START=TRUE
> or will this parameter ignored in no archive mode?

It's not ignored exactly. The ARCH process starts, sits there chewing up memory and CPU cycles, but doesn't actually do any work (ie, no archives are created).

So it's a daft thing to do, but it won't kill you.

>
> 2- when activating in the DB archiving logging:do i still have to do
> the following command ALTER SYSTEM ARCHIVE LOG START after first time
> open the database ? or is has the LOG_ARCHIVE_START=TRUE parameter in
> the ini.ora file already done this for me?

Both commands do exactly the same thing: switch on ARCH. But the alter system one only switches him on for the lifetime of the instance. The entry in the init.ora means he's automatically switched on each time the instance starts. If you've already edited your init.ora before getting the database into archive log mode and opening it, ARCH is already there.

>
>
> - I have the tow following archive locations
> log_archive_dest_1 = "LOCATION=E:\ARCH1"
> log_archive_dest_2 = "LOCATION=D:\ARCH2"
>
> 3- If I use the " Archive log list " command then I noticed that the
> the 2nd location on the D drive is mentioned as the archive log
> location. Why is that and why not the 1st location on the E drive or
> both?

A quirk. Just live with it. Use the v$archived_dest view to see things in full detail.

>
> 4- In case of recovery operation where is the database looking for
> the log files? In my case location 1, 2 or both as long as he find the
> right log?
>

In location 1, but if it can't find the log it needs there, it will flip over to location 2 automatically to see if it can find it there. This behaviour was intended to happen in 8i, but didn't (!!), but it works fine in 9i.

> 5- According to the default parameter settings must one location be
> available for archiving. I gues it does not matter which one of the
> two?
>

If you're using the LOG_ARCHIVE_DEST_n parameters, then you should check the documentation for the MANDATORY and OPTIONAL switches. By default, destination 1 is mandatory and all others are optional. Failure to archive to an optional destination doesn't cause anything very much to happen; failure to archive to a mandatory destination will cause your database to hang.

> 6-What is the prefered log swith time: every 30 minutes? The data is
> critical bot not that critical? Is the best way to get to a the 30 min
> or whatever to change the size of the redo log files?
>

There isn't a preferred time. Frequent switches cause lots of checkpoints, and checkpoints are bad for performance, but nice and secure. Infrequent switches are good for performance, but you risk either extremely long instance recoveries or lots of lost data. Somewhere in between those two extremes is something that's right for you and your organisation. You have to decide. Many DBAs seem to have come up with a switch every 30 minutes or 1 hour as a nice compromise -but you should think it through for yourself.

And yes, the easiest way to slow down or speed up log switches is to alter the size of your log files -except that you can't resize redo logs, so you have to add a new log group of the new size, and drop the old one.

Regards
HJR
> Thanks
Received on Fri Feb 14 2003 - 13:55:56 CST