14
Creating a Database and Objects for Multiple Instances

This chapter describes:

Creating a Database for a Multi-instance Environment

This section covers aspects of database creation specific to OPS:

Summary of Tasks

Database creation tasks specific to OPS can be summarized as follows:

Set initialization parameters for every instance, including log archiving.
With parallel server disabled, enter the CREATE DATABASE statement, setting MAXINSTANCES and other important options specific to OPS.
Create rollback segments for each node.
Dismount the database then remount it with the parameter setting PARALLEL_SERVER=TRUE in the initialization file. Then start up the parallel server.

See Also:
"Creating a Database" in the Oracle8i Administrator's Guide.

Setting Initialization Parameters for Database Creation

Certain initialization parameters critical at database creation or that affect certain database operations must have the same value for every instance in OPS. Be sure these are identical across all instances before creating a database for a multi-instance environment.

Using ARCHIVELOG Mode

To enable the ARCH process while creating a database, set the initialization parameter LOG_ARCHIVE_START to TRUE. Then change the mode to ARCHIVELOG with the ALTER DATABASE statement before starting up the instance that creates the database.

Alternatively, you can reduce overhead by creating the database in NOARCHIVELOG mode. This is the default. Then change to ARHIVELOG mode.

You cannot use the STARTUP command to change the database archiving mode. After creating a database, use the following Server Manager commands to change to archiving mode and reopen the database with parallel server enabled:

   ALTER DATABASE CLOSE;
   ALTER DATABASE ARCHIVELOG;
   SHUTDOWN;
   STARTUP;

Database Creation and Start Up

Use the standard procedure to create a database.

Note:
The CREATE DATABASE statement mounts and opens the newly created database, leaving the parallel server disabled. You must close and dismount the database, then remount it with parallel server enabled.

Start Server Manager.
Connect with SYSDBA privileges.
Start up an instance with the NOMOUNT option.
Issue the CREATE DATABASE statement.
Create additional rollback segments and threads, as needed.
Close and dismount the database.
```
	SHUTDOWN
```
Update the initialization files to be sure they point to the proper rollback segments and threads,
Make sure parallel server is enabled.
Remount the database.
```
	STARTUP [ OPEN databasename ]
```
See Also:
"Starting Instances" .

Setting CREATE DATABASE Options

This section describes CREATE DATABASE options specific to OPS.

Setting MAXINSTANCES

The 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; on most systems the default is two.

For OPS, set MAXINSTANCES to a value greater than the maximum number of instances you expect to run concurrently. This way, if instance A fails and is being recovered by instance B, you will be able to start instance C before instance A is fully recovered.

Setting MAXLOGFILES and MAXLOGMEMBERS

The MAXLOGFILES option of CREATE DATABASE specifies the maximum number of redo log groups that can be created for the database, and the MAXLOGMEMBERS option specifies the maximum number of members or copies per group.

For OPS, set MAXLOGFILES to the maximum number of threads possible, multiplied by the maximum anticipated number of groups per thread.

Setting MAXLOGHISTORY

The 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 OPS.

For OPS, you should 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, old history entries are overwritten. The default for MAXLOGHISTORY is zero, which disables the log history.

Setting MAXDATAFILES

The MAXDATAFILES option is generic, but OPS tends to have more data files and log files than standard systems. On your platform the default value of this option may be too low.

Creating Database Objects to Support Multiple Instances

To prepare a new database for OPS, create and configure the following additional database objects.

Creating Additional Rollback Segments

You must create at least one rollback segment for each instance of a parallel server. To avoid contention, create these rollback segments in a tablespace other than the SYSTEM tablespace.

You must 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.

Using Private Rollback Segments

To allocate a private rollback segment to one instance, follow these steps:

Create the rollback segment with the SQL statement CREATE ROLLBACK SEGMENT, omitting the keyword PUBLIC. Optionally, before creating the rollback segment you can create a tablespace for it.
Specify the rollback segment in the instance's parameter file by naming it as a value for the parameter. This reserves the rollback segment for that instance.
Use ALTER ROLLBACK SEGMENT to bring the rollback segment online. You can also restart the instance to use the reserved rollback segment.

A private rollback segment should be specified in only one parameter file so that it is associated with only one instance. If an instance attempts to acquire a private rollback segment that another instance has already acquired, Oracle generates a message and prevents the instance from starting up.

Using Public Rollback Segments

Any instance can create a public rollback segment that can then be claimed by any instance when it starts up. Once a rollback segment has been claimed, it is only used by the instance that claimed it until the instance shuts down, releasing the rollback segment for use by another instance.

To create a public rollback segment, use the SQL statement CREATE PUBLIC ROLLBACK SEGMENT.

Typically, the parameter file for any particular instance does not specify public rollback segments because they are assumed to be available to any instance needing them. However, if another instance is not already using it, you can name a public rollback segment as a value of the ROLLBACK_SEGMENTS parameter.

Public rollback segments are identified as having the owner PUBLIC in the data dictionary view DBA_ROLLBACK_SEGS.

If the parameter file omits the ROLLBACK_SEGMENTS initialization parameter, the instance uses public rollback segments by default.

A public rollback segment is brought online when an instance requiring public rollback segments starts up and acquires it. However, starting an instance using public rollback segments does not ensure that any particular public rollback segment comes online unless the instance acquires all available public rollback segments. Once acquired, a public rollback segment is used exclusively by the acquiring instance.

Bringing online, taking offline, creating, and dropping rollback segments, whether private or public, is the same whether OPS is enabled or disabled.

Private rollback segments stay offline until brought online or until the owning instance restarts. A public rollback segment stays offline until brought online for a specific instance or until an instance requiring a public rollback segment starts up and acquires it.

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.

Monitoring Rollback Segments

You can use the Server Manager command MONITOR ROLLBACK to display information about the status of the rollback segments that the current instance uses.

Alternatively, you can query the dynamic performance views V$ROLLNAME and V$ROLLSTAT for information about the current instance's rollback segments.

Use the Server Manager command CONNECT @instance-path to change the current instance before using the MONITOR command or querying the V$ views. You must have Net8 installed to use the CONNECT command for an instance on a remote node.

You can also query the data dictionary views DBA_ROLLBACK_SEGS and DBA_SEGMENTS for information about the current status of all rollback segments in your database.

For example, to list the current rollback segments, you can query DBA_ROLLBACK_SEGS with the following statement:

   SELECT segment_name, segment_id, owner, status 
      FROM dba_rollback_segs

This query displays the rollback segment's name, ID number, owner, and whether it is in use, as shown in the following example:

SEGMENT_NAME             SEGMENT_ID     OWNER     STATUS 
------------------------ ----------     ------    ------------ 
SYSTEM                            0     SYS       ONLINE
PUBLIC_RS                         1     PUBLIC    ONLINE
USERS1_RS                         2     SYS       ONLINE
USERS2_RS                         3     SYS       OFFLINE
USERS3_RS                         4     SYS       ONLINE
USERS4_RS                         5     SYS       ONLINE
PUBLIC2_RS                        6     PUBLIC    OFFLINE

In this example, rollback segments identified as owned by user SYS are private rollback segments; the rollback segments identified as owned by user PUBLIC are public rollback segments.

The view DBA_ROLLBACK_SEGS also includes information (not shown) about the tablespace containing the rollback segment, the datafile containing the segment header, and the extent sizes. The view DBA_SEGMENTS includes additional information about the number of extents in each rollback segment and the segment size.

Configuring the Online Redo Log for OPS

Each database instance has its own "thread" of online redo, consisting of its own online redo log groups. When running OPS, two or more instances concurrently access a single database and each instance must have its own thread. This section explains how to configure these online redo threads for multiple instances with OPS.

You must create each thread with at least two redo log files (or multiplexed groups), and you must enable the thread before an instance can use it.

The CREATE DATABASE statement creates thread number 1 as a public thread and enables it automatically. You must use the ALTER DATABASE statement to create and enable subsequent threads.

Creating Threads

Threads can be either public or private. The initialization parameter THREAD assigns a unique thread number to the instance. If THREAD is zero, which is the default, the instance acquires an available public thread.

Each thread must be created with at least two redo log files or multiplexed groups. You must also enable each thread before an instance can use it.

The 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 thread 2 with two groups of three members each, as shown in Figure 6-1 :

   ALTER DATABASE ADD LOGFILE THREAD 2 
    GROUP 4 (disk1_file4, disk2_file4, disk3_file4) SIZE 1M REUSE 
    GROUP 5 (disk1_file5, disk2_file5, disk3_file5) SIZE 1M REUSE; 
   ALTER DATABASE ENABLE PUBLIC THREAD 2;

If you omit the keyword PUBLIC when you enable the thread, it will be a private thread that cannot be acquired by default. Only one thread number may be specified in the ALTER DATABASE ADD LOGFILE statement, and the THREAD clause must be specified if the thread number of the current instance was chosen by default.

Disabling Threads

You can disable a public or private thread with the statement ALTER DATABASE DISABLE THREAD. 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, you must 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. These log files cannot be dropped or archived. In this case, you should disable the thread, even though it is already disabled, then enable it.

Setting the Log's Mode

The mode of using the redo log, ARCHIVELOG or NOARCHIVELOG, is set at database creation. Although rarely necessary, the archive mode can be changed by the SQL statement ALTER DATABASE. When archiving is enabled, online redo log files cannot be reused until they are archived. To switch archiving modes, the database must be mounted with OPS disabled, but the database cannot be open.

The redo log mode is associated with the database rather than with individual instances. For most purposes, all instances should use the same archiving method, either automatic or manual, if the redo log is being used in ARCHIVELOG mode.

Changing the Redo Log

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 OPS either enabled or disabled. The only restrictions are 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.

See Also:
"Archiving the Redo Log Files".

Providing Locks for Added Datafiles

If datafiles are added while OPS is running, evaluate whether enough locks are available to cover the new files.

Added datafiles use the unassigned locks created when the value for GC_FILES_TO_LOCKS was set. If the remaining locks are not adequate to protect the new files and avoid contention, provide more locks by adjusting the GC* parameters. Performance problems are likely if you neglect to make these adjustments.

In a read-only database, extra locks are not necessary even if you added many new datafiles. In a database heavily used for inserts, however, you might need to provide more locks.

If you determine you need more locks, do the following:

Shut down your system.
Modify the GC_FILES_TO_LOCKS initialization parameter to provide enough locks for the additional datafiles.
Restart the system.

Changing the Value of CREATE DATABASE Options

You can use the CREATE CONTROLFILE statement to change the value of the following database parameters for an existing database:

MAXINSTANCES
MAXLOGFILES
MAXLOGMEMBERS
MAXLOGHISTORY
MAXDATAFILES

See Also:
Oracle8i SQL Reference for a description of the statements CREATE CONTROLFILE and ALTER DATABASE BACKUP CONTROLFILE TO TRACE.

14Creating a Database and Objects for Multiple Instances