|Oracle9i Real Application Clusters Installation and Configuration
Release 1 (9.0.1)
Part Number A89868-02
This chapter discusses considerations and procedures for manually creating Real Application Clusters databases. The topics in this chapter are:
This section describes the following
CREATE DATABASE options specific to Real Application Clusters.
Use this information when writing database creation scripts. A sample database creation script for Real Application Clusters databases appears in the script
clustdb.sql which resides in the
$ORACLE_HOME/srvm/admin directory on UNIX or in the
%ORACLE_HOME%\srvm\admin directory on Windows NT and Windows 2000 platforms.
MAXINSTANCES option of
CREATE DATABASE limits the number of instances that can access a database concurrently.
MAXINSTANCES defaults to the maximum value specific to your operating system.
For Real Application Clusters, set
MAXINSTANCES to a value greater than the maximum number of instances you expect to run concurrently. For example, assume you have three instances, A, B, and C. If instance A fails and instance B recovers it, you can start instance C before instance A is fully recovered. In this case, set
4 or more.
MAXLOGFILES option of
CREATE DATABASE specifies the maximum number of redo log groups that can be created for the database. The M
AXLOGMEMBERS option specifies the maximum number of members or copies for each group. Set
MAXLOGFILES to the maximum number of threads possible, multiplied by the maximum anticipated number of groups for each thread.
MAXLOGHISTORY option of
CREATE DATABASE specifies the maximum number of redo log files that can be recorded in the log history of the control file. The log history is used for automatic media recovery of Real Application Clusters databases.
For Real Application Clusters, set
MAXLOGHISTORY to a large value, such as 1000. The control files can then only store information about this number of redo log files. When the log history exceeds this limit, Oracle overwrites the oldest entries. The default for
0 (zero), which disables log history.
MAXDATAFILES option is generic, but Real Application Clusters databases tend to have more datafiles and log files than standard systems.
Create your database using the default of
NOARCHIVE log mode. This reduces system overhead while you create your database. You can later implement archive logging using the
ALTER DATABASE statement with the
ARCHIVELOG option. Refer to "Setting the Log Mode" for information on setting the log mode.
Oracle9i Database Administrator's Guide for more information about archive logging
You can use the
CREATE CONTROLFILE statement to change the value of the following database parameters for a database:
To prepare a new database for Real Application Clusters, create and configure the additional database objects as described under the following headings:
Oracle strongly recommends that you use automatic undo management. This feature automatically manages undo space.
To use automatic undo management, use the
CREATE DATABASE statement with the
UNDO TABLESPACE clause to create an undo tablespace. You can also use the
CREATE UNDO TABLESPACE statement to create additional undo tablespaces for additional instances.
When you use the
CREATE DATABASE statement and you have enabled automatic undo management, if you do not specify the
UNDO TABLESPACE clause, Oracle creates an undo tablespace by default. The name and size of the default file varies depending on your operating system. However, if you are using raw devices, this automatically created file will be on your file system where it cannot be shared. In this case, you must specify a name for the undo tablespace.
If you create your database in Rollback Segment Undo mode, you must first create and bring online one additional rollback segment in the
SYSTEM tablespace before creating rollback segments in other tablespaces. The instance that creates the database can create this additional rollback segment and new tablespaces, but it cannot create database objects in non-
SYSTEM tablespaces until you bring the additional rollback segment online.
Then you must create at least two rollback segments for each instance of Real Application Clusters. To avoid contention, create these rollback segments in a tablespace other than the
SYSTEM tablespace, for example, the
Oracle9i Real Application Clusters Administration for more information about automatic undo management
If you use Rollback Segment Undo mode and manually manage rollback segments, Oracle Corporation recommends that you make the rollback segments private. This enables you to closely control which instances use which rollback segments. To do this follow these steps:
ROLLBACK_SEGMENTSparameter to specify the rollback segment in the initialization parameter file by naming it as a value for the parameter. This reserves the rollback segment for that instance.
ALTER ROLLBACK SEGMENTto bring the rollback segment online. You can also restart the instance to use the reserved rollback segment.
You should specify a particular private rollback segment in either the server parameter file with the appropriate instance identifier, or in only one instance-specific initialization parameter file so that the segment is associated with only one instance. If an instance attempts to acquire a public rollback segment that another instance has already acquired, then Oracle generates an error message and prevents the instance from starting up. Private rollback segments stay offline until brought online or until the owning instance restarts and acquires it.
Any instance can create public rollback segments. Once created, public rollback segments are available for any instance. When an instance uses a rollback segment, the instance uses the rollback segment exclusively until the instance shuts down. When the instance shuts down, the instance releases the rollback segment for use by other instances.
Use the SQL statement
CREATE PUBLIC ROLLBACK SEGMENT to create public rollback segments. Public rollback segments are owned as
PUBLIC in the data dictionary view
DBA_ROLLBACK_SEGS. If you do not assign a rollback segment to an instance by setting a value for the
ROLLBACK_SEGMENTS parameter, the instance uses public rollback segments. The procedures you use to create and manage rollback segments are the same regardless of whether you have enabled or disabled Real Application Clusters.
Typically, the parameter file does not specify public rollback segments because they are by default available to any instance needing them. However, if another instance is not already using a particular public rollback segment, you can assign the rollback segment to the instance by declaring a value in the
ROLLBACK_SEGMENTS parameter for that instance.
An instance brings a public rollback segment online when the instance acquires the rollback segment at startup. However, starting an instance that uses public rollback segments does not ensure that the instance uses a particular public rollback segment. The exception to this is when the instance acquires all available public rollback segments.
If you need to keep a public rollback segment offline and do not want to drop it and re-create it, you must prevent other instances that require public rollback segments from starting up.
Oracle9i Database Administrator's Guide for more information about rollback segments
When running Real Application Clusters, two or more instances concurrently access a single database and each instance must have its own thread of redo. This section explains how to configure these online redo threads for clusters.
Each database instance has its own thread of online redo, consisting of its own online redo log groups. Oracle Corporation recommends that you create at least two members for each redo log group to prevent data loss. Create each thread with at least two redo log groups and enable each thread so the instance can use it.
For improved performance and to minimize the overhead of software mirroring, or multiplexing, put the members of each redo log group on separate physical disks or on separate disk arrays. The
CREATE DATABASE statement creates thread number 1 as a public thread and enables it automatically. Use the
ALTER DATABASE statement to create and enable subsequent threads.
Threads can be either public or private. The initialization parameter
THREAD assigns a unique thread number to the instance. If you set
THREAD to zero, which is the default, the instance acquires a public thread.
CREATE DATABASE statement creates thread number 1 as a public thread and enables it automatically. Subsequent threads must be created and enabled with the
ALTER DATABASE statement. For example, the following statements create and enable thread 2 with two groups of three members each.
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 3 (disk1_file4, disk2_file4, disk3_file4) SIZE 100M REUSE, GROUP 4 (disk1_file5, disk2_file5, disk3_file5) SIZE 100M REUSE; ALTER DATABASE ENABLE PUBLIC THREAD 2;
If you do not specify the
THREAD parameter in your initialization file, you must specify the
THREAD clause when creating new redo log groups. If you do specify the
THREAD parameter, you can omit the
THREAD clause when creating new redo log groups and the newly created redo log groups will be assigned to the thread of the instance that you used to create them.
Oracle9i Real Application Clusters Administration for more information about threads of redo
Disable a public or private thread with the
ALTER DATABASE DISABLE THREAD statement. You cannot disable a thread if an instance using the thread has the database mounted. To change a thread from public to private, or vice versa, disable the thread and then enable it again. An instance cannot disable its own thread. The database must be open when you disable or enable a thread.
When you disable a thread, Oracle marks its current redo log file as needing to be archived. If you want to drop that file, you might need to first archive it manually.
An error or failure while a thread is being enabled can result in a thread that has a current set of log files but is not enabled. You cannot drop or archive these log files. In this case, disable the thread, even though it is already disabled, then re-enable it.
You typically set the redo log mode,
NOARCHIVELOG, when you create your database. Although rarely necessary, you can later change the archive mode using the
ALTER DATABASE statement. When archiving is enabled, online redo log files cannot be reused until they are archived.
The redo log mode is associated with the database rather than with individual instances. If the redo log is being used in ARCHIVELOG mode, for most purposes all instances should use the same archiving method, either automatic or manual.
To switch archiving modes:
falsein the parameter file.
LOG_ARCHIVE_STARTparameter to true.
LOG_ARCHIVE_DEST_nparameters as needed.
ALTER DATABASEstatement with either the
CLUSTER_DATABASEparameter set to
You can change the configuration of the redo log, such as adding, dropping, or renaming a log file or log file member, while the database is mounted with Real Application Clusters either enabled or disabled. The only restriction is that you cannot drop or rename a log file or log file member currently in use by any thread. Moreover, you cannot drop a log file if that would reduce the number of log groups to less than two for the thread it is in.
Any instance can add or rename redo log files, or members, of any group for any other instance. As long as there are more than two groups for an instance, a redo log group can be dropped from that instance by any other instance. Changes to redo log files and log members take effect on the next log switch.
Oracle9i Real Application Clusters Administration for more information about archiving redo log files
Create your database manually if you already have scripts, or if you have database requirements that differ greatly from the types of databases that the DBCA creates as described in Chapter 4. The two major steps you must perform to manually create a database are:
Perform the following tasks before manually creating a Real Application Clusters database:
Refer to the following section for procedures on manual database creation.
Perform the following tasks to manually create a new database:
Review all the steps in this chapter before performing them.
Oracle strongly recommends that you make complete backups of all existing databases before creating a new database in case database creation accidentally affects existing files. Backups should include parameter files, database files, redo log files, control files, and network configuration files.
In Real Application Clusters, each node has its own instance. The instances collectively form a Real Application Clusters database. Being aware of database- and instance-level information enables you to more easily complete Tasks 2 through 12.
To determine database- and instance-level information:
The name of your database.
The domain name of your database.
Global Database Name
A name that comprises the database name and database domain.
|Database Name||Database Domain||Global Database Name||SID Prefix|
The node name defined by the Cluster Manager (CM) software
On UNIX and Windows NT and Windows 2000, use the command
|Node Name||Host Name||Thread ID||SID|
If this is the first Oracle9i database created on this cluster, then you must initialize the clusterwide SRVM configuration. Do this by executing the following command:
The first time you use the SRVCTL Utility to create the configuration, start the Global Services Daemon (GSD) on all nodes so that SRVCTL can access your cluster's configuration information. Then execute the
srvctl add command so that Real Application Clusters knows what instances belong to your cluster using the following syntax:
Then for each instance enter the command:
To use Oracle Enterprise Manager, manually create an entry in the oratab file on each node. This entry identifies the database. Oracle Enterprise Manager uses this file during service discovery to determine the database's name and the
ORACLE_HOME from which the database runs.
oratab file is stored in
/etc/oratab or /var/opt/oracle/oratab, depending on your operating system. The syntax for this entry is as follows where db_name is the database name given to your database,
$ORACLE_HOME is the directory path to the database, and
N indicates that the database should not be started at reboot time:
Use the database name and Oracle home you specified in Task 2: Specify the Database and Instance Settings
A sample entry follows for a database named
The SID must be defined for each node's instance in the cluster. To simplify administration, Oracle Corporation recommends that you use SID
s that consist of the database name as the common base and the thread ID of the node's instance that you specified in Task 2: Specify the Database and Instance Settings. For example, if
db is the database name, then the first instance in the cluster has a SID of
db1 and the second instance has a SID of
db2. The SID specification is operating system-specific as described under the following headings:
On UNIX, set the
ORACLE_SID environment variable.
On Windows NT and Windows 2000, set the ORACLE_SID registry value in:
After creating the SIDs, create an OracleServicesid service. You can use this service to start or stop an instance from the Control Panel. To create OracleServicesid:
CRTSRVbatch file to create a unique service corresponding to the instance of the node.
For example, to create a service for a SID of
OracleServicedb1, enter the following:
When an Oracle instance starts, it refers to the parameter file for configuration information. Oracle Corporation recommends that you use the server parameter file to designate both global and instance-specific settings. Using this parameter file greatly simplifies parameter administration.
Name the server parameter file initdb_name.ora. To designate instance-specific settings in this file, use the SID prefix and place these entries after the generic, global entries. Specify instance-specific settings using the instance_name.parameter_name=value syntax.
You can also make parameter files for the database you are about to create by copying the initialization parameter file located in the
%ORACLE_HOME%\srvm\admin directory on Windows NT and Windows 2000. Rename these files and edit and customize them for your database.
Edit the following parameters in the new
.ora parameter file:
Edit the following instance-specific parameters in the file:
Examples of instance-specific settings in the server parameter file are:
REMOTE_LOGIN_PASSWORDFILEis set to
Use the Password Utility
ORAPWD to create password files.
ORAPWD is automatically installed with the Oracle9i utilities. Password files are located in the
$ORACLE_HOME/dbs directory on UNIX and in the
%ORACLE_HOME%\database directory on Windows NT and Windows 2000. They are named
.ora on Windows NT and Windows 2000, where sid identifies the database instance you specified in Task 2: Specify the Database and Instance Settings.
To create a password file on each node:
ORAPWDto create the password file.
$ORACLE_HOME/binwith the following syntax:
%ORACLE_HOME%\binwith the following syntax:
FILE specifies the password file name and
PASSWORD sets the password for the
CREATE DATABASE script on one of the nodes by using the
clustdb.sql sample script, located in the
$ORACLE_HOME/srvm/admin directory on UNIX or in the
%ORACLE_HOME%\srvm\admin directory on Windows NT and Windows 2000. The sample script is for a two-node cluster. If you use the sample script, edit the following:
You must use the
PFILE parameter to derive the initial parameter settings from which you create the server parameter file.
CONNECT SYS/oracle AS SYSDBAline to use the password you created in Task 7: Create the Password Files. You must also be authorized to connect as SYSDBA.
$ORACLE_HOME/rdbms/adminon UNIX and
%ORACLE_HOME%\rdms\adminon Windows NT and Windows 2000, to reflect the Oracle home you specified in Task 2: Specify the Database and Instance Settings.
SYSTEMrollback segment, instances cannot share public rollback segments. An instance explicitly acquires private rollback segments when it opens a database.
To create the new database, run the
CREATE DATABASE SQL script (
clustdb.sql) from the SQL*Plus prompt:
The location of the
clustdb.sql script is
$ORACLE_HOME/srvm/admin on UNIX and
%ORACLE_HOME%\srvm\admin on Windows NT and Windows 2000 platforms.
When you execute this script, Oracle creates the following:
SYSTEMtablespace and the
Then Oracle mounts and opens the local database instance for use.
Make a full backup of the database to ensure you have a complete set of files from which to recover in case of media failure.
|Configuration File||Description||Configuration Requirements|
Includes addresses of each network listener on a server, the SIDs of the databases for which they listen, and various control parameters used by the listener.
Includes the names resolution method.
See Also: "Profile (sqlnet.ora File)" for a sample configuration