RAC archive log management on AIX

Overview of RAC archive log sharing

Whether the database is single-node or cluster, the way it carries things is strictly in the order of timestamps. This determines that the log records should be read in strict chronological order during database recovery to Restore database files. Therefore, a complete log sequence is required for cluster database recovery.
When the database is running in archive mode, logs are "partially" managed on the instance, so the archiving operation is also "partially. Because the "Global" log file is required for recovery, in database archiving operations, how to archive the log collection in a common path is an administrator's goal.
AIX can set four possibilities for storing files on shared disks: GPFS (HACMP), NFS, ASM, or hacmp raw devices.
The hacmp raw device cannot be used as the archiving destination. Therefore, the file system is required for archiving. Therefore, the following three methods can be placed in a shared area:
Select:
GPFS: place the archive file to GPFS.
ASM: place the archive file in the ASM disk group.
NFS: You can place an archive file to NFS.

When you use GPFS for archiving, you do not need to set the archiving process. You can simply set the archiving path to GPFS by specifying the same LOG_ARCHIVE_DESTn parameter on each node. Because all instances in the cluster write archive logs to this directory, the archive files are summarized. Of course, if another archiving target can be specified for the database on the node, such as pointing to local storage, the possibility of archive errors will be reduced.
Using the ASM disk group as archive storage (for example, using an ASM disk group as the flash recovery zone) is also a recommended method for Oracle. Archive logs are written to the ASM disk group pointed to by the DB_RECOVERY_FILE_DEST parameter of each instance in the cluster, the disk group stores the total archived log data.
If NFS is used, each node in the cluster can mount the same NFS. Similarly, to improve security, you can set multiple archiving targets. For example, the first archiving target is a local directory and the second archiving target is NFS.
This is the archive storage structure currently selected by many users. If the archive is constructed in this way, you must note that the archive pointing to the NFS archive target should be set as non-emphasizing archive. When the archiving operation on NFS is mandatory, if a network fault occurs, the NFS Installation Point is no longer available and the archiving operation fails, which causes the database system to be suspended.

NFS configuration

1. Modify the/etc/hosts file of AIX and add

192.1.1.203 rac1

2. modify or add the/etc/exports file as follows:
/U01-sec = sys: krb5: krb5i: krb5: dh: none,-rw, root = rac1, access = rac1

3. Restart the NFS service:
#/Usr/sbin/mknfs '-N'
0513-029 The portmap Subsystem is already active.
Multiple instances are not supported.
Starting NFS services:
0513-029 The biod Subsystem is already active.
Multiple instances are not supported.
0513-059 The nfsd Subsystem has been started. Subsystem PID is 577600.
0513-059 The rpc. mountd Subsystem has been started. Subsystem PID is 856250.
0513-029 The rpc. statd Subsystem is already active.
Multiple instances are not supported.
0513-029 The rpc. lockd Subsystem is already active.
Multiple instances are not supported.
Completed NFS services.
4. export all:
# Exportfs-

5. Modify the/etc/hosts file on the client:
182.1.21.176 djfk

6. mount nfs:

Mount djfk:/u01/mnt