Installing Oracle Parallel Server has an impact on how database files are used. Some files—for example, the datafiles—are shared among all instances. Other files are not. This section discusses each type of file in terms of how it is used in an OPS configuration.
In an OPS configuration, you need to be concerned about three types of initialization parameters:
Some parameters, such as GC_FILES_TO_LOCK, must be the identical across all instances. These are known as global constant parameters.
Certain other parameters, such as DB_BLOCK_BUFFERS, do not need to be the same for each instance.
Still other parameters, such as ROLLBACK_SEGMENTS, actually must be different for each instance.
Because the parameters for each instance in an OPS configuration won’t all match, each instance must have its own initialization parameter file (INIT.ORA). When you change a parameter in an OPS configuration, make sure to consider whether that parameter is a global constant parameter. If it is a global constant parameter and you change it, you must remember to change it in all of the parameter files. Chapter 7, goes into detail on the subject of OPS initialization parameters and the files used to manage them.
Tip
Place all common initialization parameters in one common parameter file. Then, use the IFILE directive in each instance-specific parameter file to include this common file. This eases the administrative burden of keeping the global common parameters in sync. For this scheme to work, the common parameter file must reside on a filesystem that’s accessible from all OPS nodes.
Datafiles are shared by all instances. Each instance in an OPS configuration must have access to all of the datafiles that make up a database. Each instance will verify access to all online datafiles at startup. In addition, whenever you add a new datafile, all instances verify access to that file. If an instance cannot access all online datafiles, it won’t be able to open the database, and Oracle will display an error message.
Under OPS, all instances share the control files for a database, and each instance must have access to all the control files. Control files for an OPS database contain some additional information not found in control files used with a single-instance database. When OPS is being used, the control files are used to keep track of the global constant parameters discussed earlier. When you start a new instance, the global constant parameters from the initialization file for that instance are compared to the values in the control file. If they don’t match, the instance will not start and an error will be reported. This prevents you from mistakenly getting these parameters out of sync.
Each instance in an OPS configuration has its own set of redo log files. However, each instance must have access to the redo log files used by all other instances. The reason for this is that if an instance fails, one of the other instances accessing the database will read the redo logs from the failed instance and recover any committed changes made by the failed instance that have not yet been written to the datafiles.
As with a standalone instance, each OPS instance must have at least two groups of redo log files. Further, in an OPS database, the redo log files are organized into threads. A thread is a set of two or more redo log groups. In a standalone configuration, all the redo log groups for a database are in one thread, and the instance cycles through each group in the thread as changes are made to the database. In an OPS configuration, you must have multiple threads—one for each instance. When an OPS instance starts, it is assigned one thread of the redo log. For an illustration, refer to Figure 6.4, which shows an OPS configuration in which each instance has its own thread of redo log.
Just as redo log groups are numbered, so are redo log threads. Each thread is identified by a thread number. Threads can have different numbers of redo log groups (at least two). The redo log files can be mirrored within a group, and the number of mirrored redo log members in each group may vary from group to group and thread to thread. However, for ease of administration, we recommend having the same number of redo log groups in each thread and the same number of members in each group.
When an instance starts, it acquires a thread of redo log. The specific thread acquired is the one specified by the initialization parameter THREAD. If THREAD is not specified (the default value is 0), the instance may acquire any one of the threads. In such a case, because the threads change, the specific redo log files used by an instance will change each time the instance is stopped and restarted. For a detailed discussion of redo threads and how to create and enable them, see Chapter 7.
Archiving of redo log files for each OPS instance is handled just as a standalone instance is. Each instance has its own ARCH process and writes to its own archive log destination. Since online redo logs are local to each instance, archived redo logs also are local to each instance. During normal operation, archived log files of one instance need not be accessible to other instances. However, when performing recovery using archived logs, archived log files of all instances must be accessible to the instance doing the recovery.
Each instance has its own alert log file and generates its own trace files. The locations of these files are set by initialization parameters specific to each instance. Each instance has its own destination for these files, and the directory for these files resides on the local node for that instance.