Skip Headers

Oracle® Real Application Clusters Administrator's Guide
10g Release 1 (10.1)

Part Number B10765-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

2 Administering Database Instances in Cluster Databases

This chapter describes how to administer Oracle Real Application Clusters (RAC) database instances and RAC databases. This chapter explains the startup and shutdown tasks for database components and well as how to administer parameters and parameter files in RAC. The topics in this chapter are:

Database Component Overview

RAC databases comprise a control file, redo logs, datafiles, and one server parameter file (SPFILE) or one or more PFILEs, or client-side parameter files. The instances comprise the System Global Area (SGA) and the instance background processes.

Overview of Real Application Clusters Management Tools

The following section introduces the three tools you will most likely to use to manage an existing RAC database and its instances, Oracle Enterprise Manager, SQL*Plus, and the SRVCTL utility. In many cases, you use these tools the same way to manage a single-instance database but the following sections identify the important differences when managing a RAC database:

Overview of Administering Real Application Clusters with Enterprise Manager

Use the Web-based Enterprise Manager Database Control to manage a single RAC database. The Enterprise Manager Console provides a central point of control for the Oracle environment through a graphical user interface (GUI). You can use the Enterprise Manager Console to initiate a variety of cluster database management tasks. Use Enterprise Manager Grid Control to administer multiple RAC databases.

Enterprise Manager enables you to start, stop, and monitor databases, cluster database instances, and their listeners, as well as to schedule jobs or register events. You can perform these tasks simultaneously on multiple cluster databases. You can also use the Console to manage schemas, security, and cluster database storage features.

Overview of Administering Real Application Clusters with SQL*Plus

SQL*Plus commands operate on the current instance. The current instance can be either the local default instance on which you initiated your SQL*Plus session, or it can be a remote instance to which you connect with Net Services. Because the SQL*Plus prompt does not display the current instance, you should direct your commands to the correct instance. Starting a SQL*Plus session and connecting to the database without specifying an instance directs all SQL*Plus commands to the local instance. In this case, the default instance is also the current instance.

To connect to a different instance in SQL*Plus, issue a new CONNECT command specify a remote instance net service name as in the following example:

CONNECT user name/password@net_service_name

Connecting as SYSOPER or SYSDBA enables you to perform privileged operations, such as instance startup and shutdown. Multiple SQL*Plus sessions can connect to the same instance at the same time. SQL*Plus automatically disconnects you from the first instance whenever you connect to another one.


See Also:

Overview of Administering Real Application Clusters with SRVCTL

The SRVCTL tool manages configuration information that is used by several other Oracle tools. For example, Enterprise Manager uses the configuration information that SRVCTL generates to discover and monitor nodes in your cluster.

When you use SRVCTL to perform configuration operations on your cluster, SRVCTL stores configuration data in the Server Management (SRVM) configuration repository. SRVCTL performs other operations, such as starting and stopping instances, by calling SQL*Plus on each node. SRVCTL uses the same Oracle Cluster Registry (OCR) that is used with other Oracle administrative interfaces.

Starting and Stopping Instances and Real Application Clusters Databases

You can start up and shut down instances with Enterprise Manager, SQL*Plus or SRVCTL as described in the following sections. Both Enterprise Manager and SRVCTL provide options to startup and shutdown all of the instances in a RAC database with a single step.

You can only perform certain operations when the database is in a NOMOUNT or MOUNT state. Performing other operations requires that the database be OPEN. In addition, some operations require that only one instance be in the required state, while other operations require that all of the instances be in an identical state.

The procedures in this section assume that you are using a server parameter file (SPFILE) and are described in the following topics:

Before you can start a RAC instance your clusterware and any required operating system-specific processes. For more information about these processes, see your operating system documentation.

The procedure for shutting down RAC instances is identical to shutting down instances in single-instance Oracle, with the exceptions described here. Refer to the Oracle Database Administrator's Guide for more information about shutting down Oracle databases.

Starting up and Shutting down with Enterprise Manager

To access a cluster database instance, from the Home page, click the Targets tab, then click the cluster database name. On the Cluster Database Home page, the cluster database instances display at the bottom of the page. Click an instance name to go to the Cluster Database Instance Home page where you can start or stop the cluster database instance as well as see an overview of the cluster database instance activity such as CPU and space usage, active sessions, and so on.

To start a cluster database instance click Startup, or click Shutdown to stop it. To start or shutdown a cluster database, that is, all of the instances known to Enterprise Manager, select the database and click Startup or Shutdown on the Cluster Database page.

Starting up and Shutting down with SQL*Plus

If you want to start or stop just one instance and you are connected to your local node, you should first ensure that your current environment includes the SID for the local instance. Note that any subsequent commands in your session, whether inside or outside a SQL*Plus session, will be associated with that same SID.

To start or shutdown your local instance, initiate a SQL*Plus session and connect with the SYSDBA or SYSOPER privilege and then issue the required command. For example to start and mount an instance on your local node, execute the following commands within your SQL*Plus session:

CONNECT / AS SYSDBA 
   STARTUP MOUNT

You can start more than one instance from a single SQL*Plus session on one node by way of Oracle Net Services. To achieve this, you must connect to each instance in turn by using a Net Services connection string, typically an instance-specific alias from your TNSNAMES.ORA file.


Note:

To ensure that you connect to the correct instance, you must use an alias in the connect string that is associated with just one instance. If you use an alias to a service or with multiple addresses, you may not be connected to your intended instance.

For example, you can use a SQL*Plus session on a local node to perform a transactional shutdown for two instances on remote nodes by connecting to each in turn using the instance's individual alias name. Assume the alias name for the first instance is db1 and that the alias for the second instance is db2. Connect to the first instance and shut it down as follows:

CONNECT /@db1 AS SYSDBA
   SHUTDOWN TRANSACTIONAL

Then connect to and shutdown the second instance by entering the following from you SQL*Plus session:

CONNECT /@db2 AS SYSDBA 
   SHUTDOWN TRANSACTIONAL

Other startup and shut down keywords, such as NOMOUNT, MOUNT, IMMEDIATE, and so on, are described in the SQL*Plus User's Guide and Reference

It is not possible to start up or shut down more than one instance at a time in SQL*Plus, so you cannot start or stop all of the instances for a cluster database with a single SQL*Plus command. You may wish to create a script that will connect to each instance in turn and start it up and shut it down. However, you will need to maintain this script manually if you add or drop instances.

Intermittent Windows Shutdown Issue in RAC Environments

In an Oracle Real Application Clusters release 10.1.0.2 environment on Windows, a normal Windows shutdown may cause errors that prevent the Windows shutdown from completing. As a result, you may need to perform a power reset. The following steps are recommended to avoid this during Windows shutdowns. Before shutting down or restarting any Oracle cluster node, perform a graceful shutdown of all registered Cluster Ready Service (CRS) resources on the affected cluster node. Do this by using SRVCTL commands to shutdown:

  • All services on the node.

  • All database instances on the node.

  • All ASM instances on the node.

  • All node applications on the node.

Lengthy Startup of OracleDBConsole and OracleCRService on Windows

After a cluster node restart, the node may not be fully responsive for some period of time. During this time, Oracle is attempting to restart the process OracleDBConsolesid and the OracleCRService resource. Eventually, all of the resource startup operations will complete and the computer will operate normally.

Starting up and Shutting down with SRVCTL

Enter the following SRVCTL syntax from the command line, providing the required database name and instance name, or include more than one instance name to start more than one specific instance:

srvctl start instance -d db_name -i "inst_name_list" [-o start_options] [-c connect_str | -q]

Note that this command will also start all enabled and non-running services that have the listed instances either as preferred or available instances.

To stop one or more instances, enter the following SRVCTL syntax from the command line:

srvctl stop instance -d name -i "inst_name_list" [-o stop_options] [-c connect_str | -q]

This command will also stop the services related to the terminated instances on the nodes where the instances were running.

To start or stop your entire cluster database, that is, all of the instances and its enabled services, enter the following SRVCTL commands:

srvctl start database -d name [-o stop_options] [-c connect_str | -q]

srvctl stop database -d name [-o stop_options] [-c connect_str | -q]


See Also:

Appendix B, " Server Control (SRVCTL) Reference" for information about SRVCTL options and information about other administrative tasks that you can perform with SRVCTL

Overview of Initialization Parameter Files in Real Application Clusters

When you create the database, Oracle creates an SPFILE in the file location that you specify. This location can be an ASM disk group, cluster file system file, or a shared raw device. If you manually create your database, then Oracle recommends that you create an SPFILE from an initialization parameter file (PFILE).

All instances in the cluster database use the same SPFILE at startup. Because the SPFILE is a binary file, do not edit it. Instead, change SPFILE parameter settings using Enterprise Manager or ALTER SYSTEM SQL statements.

RAC uses a traditional PFILE only if an SPFILE does not exist or if you specify PFILE in your STARTUP command. Oracle recommends that you use SPFILE file to simplify administration, maintain parameter setting consistency, and to guarantee parameter setting persistence across database shutdown and startup events. In addition, you can configure RMAN to back up your SPFILE.

Setting Server Parameter File Parameter Values for Real Application Clusters

You can alter SPFILE settings with Enterprise Manager or by using the SET clause of the ALTER SYSTEM statement. In addition, the ALTER SYSTEM syntax enables you to override the effects of SPFILE settings that you make manually. However, if your SPFILE contains instance-specific settings, then these settings take precedence over settings made with ALTER SYSTEM commands.

The examples in this section appear in ASCII text although the SPFILE is a binary file. Assume that you start an instance with an SPFILE containing the following entries:

*.OPEN_CURSORS=500
prod1.OPEN_CURSORS=1000

For the instance with the Oracle system identifier (sid) prod1, the OPEN_CURSORS parameter remains set to 1000 even though it has a database-wide setting of 500. The instance-specific parameter setting in the parameter file for an instance prevents database-wide alterations of the setting. This gives you control over parameter settings for instance prod1. These two types of settings can appear in any order in the parameter file.

If another DBA runs the following statement, then Oracle updates the setting on all instances except the instance with sid prod1:

ALTER SYSTEM SET OPEN_CURSORS=1500 sid='*' SCOPE=MEMORY;

In the example instance with sid prod1, the parameter begins accepting ALTER SYSTEM values set by other instances if you change the parameter setting by running the following statement:

ALTER SYSTEM RESET OPEN_CURSORS SCOPE=MEMORY sid='prod1';

Then if you execute the following statement on another instance, the instance with sid prod1 also assumes the new setting of 2000:

ALTER SYSTEM SET OPEN_CURSORS=2000 sid='*' SCOPE=MEMORY;

In the following example, the server parameter file contains these entries:

prod1.OPEN_CURSORS=1000
*.OPEN_CURSORS=500

Running the following statement makes Oracle disregard the first entry from the server parameter file:

ALTER SYSTEM RESET OPEN_CURSORS SCOPE=SPFILE sid='prod1';

To reset a parameter to its default value throughout your cluster database, enter the statement:

ALTER SYSTEM RESET OPEN_CURSORS SCOPE=SPFILE sid='*';


Note:

Modifying SPIFLEs with anything except Enterprise Manager or SQL*Plus can corrupt the file and prevent database startup. To repair the file, you might need to create the PFILE and regenerate the SPFILE.

Specifying Comments in Server Parameter Files

Specify comments on the same line with the parameter setting. For example, if the initialization parameter file contains the following lines:

# first comment
OPEN_CURSORS = value # second comment

The string second comment is associated with the setting for OPEN_CURSORS. Oracle displays this comment in the V$PARAMETER and V$PARAMETER2 views. Oracle also displays comments such as the entry #first comment in the example.

Exporting the Server Parameter File for Backward Compatibility

You can revert to previous releases of RAC and convert from using the server parameter file to the traditional client-side PFILE. The procedure for this is described in Oracle Database Administrator's Guide.

Initialization Parameter Use in Real Application Clusters

Most initialization parameters can have different values on different instances as described in the Oracle Database Reference. A parameter that can optionally have a different value for each instance has a default value that is typically the same on all instances. You can change the value on one or more instances and your new values can be unique across your instances or the values can be the same on one or more of your instances. Other parameters must either be identical or unique as described in the following sections.

Parameters that Must Have Identical Settings on All Instances

Certain initialization parameters that are critical at database creation or that affect certain database operations must have the same value for every instance in RAC. Specify these parameter values in the SPFILE, or within each init_dbname.ora file on each instance. The following list contains the parameters must be identical on every instance:

  • ACTIVE_INSTANCE_COUNT

  • ARCHIVE_LAG_TARGET

  • CLUSTER_DATABASE

  • CONTROL_FILES

  • DB_BLOCK_SIZE

  • DB_DOMAIN

  • DB_FILES

  • DB_NAME

  • DB_RECOVERY_FILE_DEST

  • DB_RECOVERY_FILE_DEST_SIZE

  • DB_UNIQUE_NAME

  • MAX_COMMIT_PROPAGATION_DELAY

  • TRACE_ENABLED

  • UNDO_MANAGEMENT

The setting for DML_LOCKS must be identical on every instance only if set to zero.

Parameters That Must Have Unique Settings on All Instances

If you use the THREAD or ROLLBACK_SEGMENTS parameters, then Oracle recommends setting unique values for them by using the sid identifier in the SPFILE. However, you must set a unique value for INSTANCE_NUMBER for each instance and you cannot use a default value.

Oracle uses the INSTANCE_NUMBER parameter to distinguish among instances at startup. Oracle uses the THREAD number to assign redo log groups to specific instances. To simplify administration, use the same number for both the THREAD and INSTANCE_NUMBER parameters.

Specify the ORACLE_SID environment variable, which comprises the database name and the number of the THREAD assigned to the instance.

If you specify UNDO_TABLESPACE with automatic undo management enabled, then set this parameter to a unique undo tablespace name for each instance.

Summary of Parameter Use in Real Application Clusters Databases

This section summarizes considerations for using parameters in RAC databases.

CLUSTER_DATABASE  Enables a database to be started in cluster mode. Set this parameter to TRUE. CLUSTER_DATABASE_INSTANCES  Sets the number of instances in your RAC environment. A proper setting for this parameter can improve memory use. Set the CLUSTER_DATABASE_INSTANCES parameter to the same value on all instances. Otherwise, instance startup can fail. Normally, you should set this parameter to be equal to the number of instances in your RAC database. CLUSTER_INTERCONNECTS  Specifies the cluster interconnect when there is more than one interconnect. Refer to your Oracle platform-specific documentation for the use of this parameter, its syntax, and its behavior.

You typically do not need to set the CLUSTER_INTERCONNECTS parameter. For example, do not set this parameter for the following common configurations:

Oracle uses information from CLUSTER_INTERCONNECTS to distribute interconnect traffic among the various network interfaces if you specify more than one interconnect with this parameter. Note that the specified configuration inherits any limitations of the listed interconnects and the associated operating system IPC services, such as availability. Consider setting CLUSTER_INTERCONNECTS when a single cluster interconnect cannot meet your bandwidth requirements. You may need to set this parameter in data warehouse environments with high interconnect bandwidth demands from one or more databases as described here.

For example, if you have two databases with high interconnect bandwidth requirements, then you can override the default interconnect provided by your operating system and nominate a different interconnect for each database using the following syntax in each server parameter file where ipn is an IP address in standard dot-decimal format, for example: 144.25.16.214:

Database One: CLUSTER_INTERCONNECTS = ip1
Database Two: CLUSTER_INTERCONNECTS = ip2

If you have one database with high bandwidth demands, then you can nominate multiple interconnects using the following syntax:

CLUSTER_INTERCONNECTS = ip1:ip2:...:ipn

If you set multiple values for CLUSTER_INTERCONNECTS as in the preceding example, then Oracle uses all of the interconnects that you specify. This provides load balancing as long as all of the listed interconnects remain operational.

If there is an operating system error writing to the interconnect that you specify with CLUSTER_INTERCONNECTS, then Oracle returns an error even if some other interfaces are available. This is because the communication protocols between Oracle and the interconnect can vary greatly depending on your platform. Refer to your Oracle platform-specific documentation for more information.

DB_NAME If you set a value for DB_NAME in instance-specific parameter files, the setting must be identical for all instances. DISPATCHER Set the DISPATCHERS parameter to enable a shared server configuration, that is a server that is configured to allow many user processes to share very few server processes. With shared server configurations, many user processes connect to a dispatcher. The DISPATCHERS parameter may contain many attributes.

Oracle recommends that you configure at least the PROTOCOL and LISTENER attributes. PROTOCOL specifies the network protocol for which the dispatcher process generates a listening end point. LISTENER specifies an alias name for the Oracle Net Services listeners. Set the alias to a name that is resolved through a naming method such as a tnsnames.ora file. The tnsnames.ora file contains net service names. This file is needed on clients, nodes, the Enterprise Manager Central Control, and the Oracle Performance Manager node. Refer to Oracle Database Net Services Administrator's Guide for complete information about configuring the DISPATCHER parameter and its attributes and for configuring the shared server.

MAX_COMMIT_PROPAGATION_ DELAY This is a RAC-specific parameter. Do not alter the default setting for this parameter except under a limited set of circumstances. This parameter specifies the maximum amount of time allowed before the system change number (SCN) held in the SGA of an instance is refreshed by the log writer process (LGWR). It determines whether the local SCN should be refreshed from the SGA when getting the snapshot SCN for a query. SPFILE When you use an SPFILE, all RAC database instances must use the SPFILE and the file must be on shared storage. SESSIONS_PER_USER Each instance maintains its own SESSIONS_PER_USER count. If SESSIONS_PER_USER is set to 1 for a user, the user can log on to the database more than once as long as each connection is from a different instance. THREAD If specified, this parameter must have unique values on all instances. The THREAD parameter specifies the number of the redo thread to be used by an instance. You can specify any available redo thread number as long as that thread number is enabled and is not used.

Backing Up the Server Parameter File

Oracle recommends that you regularly back up the server parameter file for recovery purposes. Do this using the CREATE PFILE statement. For example:

CREATE PFILE='?/dbs/initdbname.ora'
FROM SPFILE='/dev/vx/rdsk/oracle_dg/dbspfile'

You can also recover by starting up an instance using a client-side initialization parameter file. Then re-create the server parameter file using the CREATE SPFILE statement. You can also use RMAN (Recovery Manager) to create backups of the server parameter file.


See Also: