To run a parallel server database in ARCHIVELOG mode, set the following three initialization parameters on each instance:

If you are having each instance write archived redo log files to a filesystem local to the node on which that instance is running, you can take either of two approaches to naming that location. One approach is to use the same name for all the archive log filesystems. While each node will have its own filesystem, the name will be uniform across all nodes. Doing this allows you to specify the archive log destination in the common initialization parameter file. The other approach is to use a different directory for each instance’s archived log files. If your filesystem names are different on each node, you will have to specify the archived log destination in the instance-specific parameter files.

Another thing to be aware of when using local filesystems for archived log files is that the archived logs for each instance will be generated on the local node and will be accessible only to the instance that created them. During media recovery, you will have to collect the archived logs from all instances and put them in a location accessible to the instance that is actually performing the recovery.

Using an NFS-mounted directory allows all instances to archive to the same destination and also makes the archived logs of all instances accessible globally. The advantage of this approach is that, during a recovery, you don’t have to perform the extra task of collecting all the archived logs and moving them to a location accessible from the instance performing the recovery. One drawback to this approach is the unreliability of NFS filesystems. If the filesystem goes down for some reason, all the instances will hang because the archiver processes won’t be able to write to the archive log destination. The use of an NFS-mounted directory as an archive log destination requires a special setup. You should contact Oracle Support before using an NFS-mounted directory as your archive destination.

Use the ALTER DATABASE command with the ARCHIVELOG option to put a database into ARCHIVELOG mode. You can do this only while the database is mounted, but not opened, by a single instance in EXCLUSIVE mode. Follow these steps to enable ARCHIVELOG mode for an OPS database:

To reverse the process and put an OPS database into NOARCHIVELOG mode, follow steps 1, 3, and 4 as described earlier and then issue the following command from Server Manager:

ALTER DATABASE NOARCHIVELOG;

Follow steps 7, 8, and 9 to complete the operation.

Oracle8i introduces some changes in database archiving. You can now have as many as 10 archiver processes. These will be named ARC0, ARC1, and so forth up to ARC9. A higher number of archiver processes helps in managing high archiving loads. Oracle8i also allows you to archive to more than one destination. This is accomplished using a new form of the LOG_ARCHIVE_DEST parameter that has a number on the end. For example, you can now use LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, and so forth to set multiple archivelog destinations.

You can take advantage of the multiple archivelog destination feature in an OPS environment to improve the recoverability of the database. Using this feature, you can configure each instance to archive redo logs to the local disk, as well as to a remote destination. To archive to a remote destination, you can use NFS to mount a directory from another OPS node, and then specify this NFS-mounted directory as the second archivelog destination in your initialization parameter file.

If you have only locally archived redo logs, you have the potential of losing data in the event of a complete node failure. Having multiple copies of archive logs in local as well as remote destinations makes recovering your database easier in the event of a node failure.

Refer to Oracle Corporation’s Oracle8i Administrator’s Guide and Oracle8i Parallel Server Setup and Configuration Guide for more details.