Re: 9i RAC and LOG_ARCHIVE_TARGET_n on OCFS

Steffen Roegner wrote:

> Howdy,
>
> here is a little nut we tried to crack these days.
> We have a 4-node 9.2.0.4 RAC on Red Hat EL 3.0 running, utilizing a SAN
> with ocfs. Following Wim Coekaerts recommendations found on oss
> (http://oss.oracle.com/projects/ocfs/dist/documentation/ocfs_oracleworld.ppt)
>
> we were trying to separate archive directories for the archlog threads
> from each other - we used to have them in one partition alltogether in
> the beginning. ("Separate archive log files from datafiles, If possible
> separate out in separate directories"). This is apparently to prevent
> ocfs from fragmentation ...
>
> Anyway - the only way I know for doing that is setting the
> LOG_ARCHIVE_DEST_n instance specific, like so:
>
> node1.thread=1
> node1.log_archive_dest_1=/u01/archive/rac/thread1
> node2.thread=2
> node2.log_archive_dest_1=/u01/archive/rac/thread2
>
> We now use this configuration on a test RAC and it works. On the other
> hand, ORACLE Doc says explicitly:
>
> "Parameters That Must Be Identical Across All Instances
>
> Certain initialization parameters that are critical at database creation
> or that affect certain database operations must have the same value for
> every instance in Real Application Clusters. Specify these parameter
> values in the common parameter file, or within each init_dbname.ora file
> on each instance. The following list shows the parameters that must be
> identical on every instance.
>
> * CONTROL_FILES
> ...
> * LOG_ARCHIVE_DEST_n (Optional)"
> (http://download-west.oracle.com/docs/cd/B10501_01/rac.920/a96596/params.htm#21706)
>
>
> I cannot put this together - is there another (maybe more explicit) way,
> to assign a certain Archive Log Destination to an Archive thread?
>
> tia,
> Steffen

I'd suggest forgetting the advice you read as oss.oracle.com. Not only as Howard says does each instance need to be able to find the archive logs for all instances in case of recovery they also need to be able to find them to rollback transactions for failed nodes.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)