8
Real Application Clusters Storage Considerations

This chapter describes Real Application Clusters storage considerations. Topics in this chapter include:

• Overview of Storage in Real Application Clusters
• Datafiles in Real Application Clusters
• Parameter File Storage in Real Application Clusters
• Redo Log File Storage in Real Application Clusters
• Managing Undo Space in Real Application Clusters

Overview of Storage in Real Application Clusters

The primary difference between Real Application Clusters storage and storage for single-instance Oracle databases is that all datafiles and configuration files in Real Application Clusters must reside on either a cluster file system or on shared raw devices. You must also create at least two additional redo logs for each instance. You must also create one device for each instance for its own tablespace for automatic undo management, or one rollback segment tablespace for the database if you do not use automatic undo management.

If your platform does not support a cluster file system or if you do not want to use it to store datafiles for Real Application Clusters, then you must create additional raw devices as described in Oracle9i Real Application Clusters Setup and Configuration. The rest of this chapter provides additional information about Real Application Clusters-specific storage topics.

Datafiles in Real Application Clusters

All Real Application Clusters instances must be able to access the same datafiles. The composition of database files is the same for Oracle in both Real Application Clusters and in single instance Oracle. Therefore, you do not have to alter datafiles to use them in Real Application Clusters. The physical placement of the datafiles, however, changes. This is because, as mentioned, all instances must access the files.

Datafile Verification in Real Application Clusters

The first Real Application Clusters instance to start verifies access to all online files so it can determine whether to perform media recovery. Additional instances can operate without access to all of the online datafiles, but attempts to use an unverified file will fail and Oracle will generate an error message.

Adding Datafiles in Real Application Clusters

When you add a datafile to a tablespace or bring a datafile online, all instances verify access to the file. If an you add a new datafile onto a disk that other instances cannot access, then verification fails but the instances can continue running. Verification can also fail if instances access different copies of the same datafile.

If verification fails for any instance, then diagnose and fix the problem. Use the ALTER SYSTEM CHECK DATAFILES statement to verify access. To perform recovery, you do not need to recover entire files. Instead, you can recover individual blocks.

Parameter File Storage in Real Application Clusters

You can use two types of files for parameter administration: the server-side parameter file or one or more client-side parameter files. Oracle Corporation recommends that you administer parameters using server parameter files to simplify parameter administration and to take advantage of Oracle's advanced self-tuning capabilities. When Oracle self-tunes, it automatically modifies parameter settings in the server parameter file.

The Database Configuration Assistant (DBCA) creates the server parameter file as a binary file. By default, Oracle creates the server parameter file based on one parameter file (PFILE). The server parameter file uses an asterisk (*) to identify global parameter settings and the Oracle system identifier (SID) designator to indicate instance-specific settings.

You can only change parameter settings in the server parameter file using either Oracle Enterprise Manager or ALTER SYSTEM SET SQL statements. If you use the traditional client-side parameter files, then parameter changes that Oracle makes as a result of self-tuning are not preserved after shutdown.

Location of the Server Parameter File

If you use the DBCA to create your Real Application Clusters database, then the single-instance Oracle database default location that the DBCA provides for the server parameter file is inappropriate for Real Application Clusters. This is because all instances must use the same server parameter file. Therefore, you must override the default location provided by the DBCA.

The value you use to override the default location, however, depends upon your file system configuration. If your platform supports a cluster file system or if you are using a single-node Real Application Clusters database, then you can place the server parameter file on the file system. Otherwise you must enter a raw device name for the location of the server parameter file.

Redo Log File Storage in Real Application Clusters

In Real Application Clusters, each instance writes to its own set of online redo log files. The redo written by an instance is called a thread of redo. Each online redo log file is associated with a particular thread number. When an online redo log is archived, Oracle records its thread number to identify it in case Oracle performs recovery.

A private thread is a redo log created by using the ALTER DATABASE ADD LOGFILE statement with the THREAD clause. A public thread is a redo log created using the ALTER DATABASE ADD LOGFILE statement but without specifying a THREAD clause.

If the THREAD initialization parameter is specified, then the instance starting up acquires the thread identified by that value as a private thread. If the THREAD initialization parameter has the default value 0, then the instance acquires a public thread. Once acquired, the acquiring instance uses the redo thread exclusively.

Automatic Segment-Space Management

The ability of transactions from different instances to concurrently insert data into the same table occurs in Real Application Clusters without contention to locate free space for new records. To accomplish this, Oracle closely manages the blocks that have space for transactions that could cause rows to exceed their available space. Oracle does this for each database object, such as a table, cluster, or index.

To control space management, Oracle Corporation strongly recommends that you use automatic segment-space management. This feature uses bitmaps to manage free space within segments. If you prefer to use free lists, then create as many free lists groups as you have instances in your Real Application Clusters database.

Managing Undo Space in Real Application Clusters

Undo blocks are records of previous data values that were later changed by transactions, even if the transactions are not committed. Oracle requires undo blocks to maintain read consistency, to undo changes made by transactions that roll back or terminate, and to recover the database.

Oracle Corporation strongly recommends that you use automatic undo management to control undo space in Real Application Clusters. This feature is not only easier to administer than rollback segment undo, but the performance of space management with automatic undo management is superior to space management performance in rollback undo mode.

Private and Public Rollback Segments

If you use rollback segment undo mode, then each Real Application Clusters instance shares use of the SYSTEM rollback segment and requires at least one dedicated rollback segment. Instances can acquire either private or public rollback segments at startup and use them exclusively. The exception to this is the SYSTEM rollback segment. However, other instances can read rollback segments to create read-consistent snapshots or to perform instance recovery.

Oracle Corporation recommends that you use private rollback segments for each instance in Real Application Clusters, and that you use the same rollback segment identifiers each time you startup a particular instance. For private rollback segments, you must always specify the SID when using the ROLLBACK_SEGMENTS parameter. Instances use rollback segments until the rollback segments are taken offline or when the acquiring instance is shut down as specified in the rollback segment parameter.

A public rollback segment is offline and not used by an instance until an instance that needs a rollback segment starts up, acquires it, and brings it online. Once online, the acquiring instance uses the public rollback segment exclusively.