Skip Headers

Oracle9i Real Application Clusters Administration
Release 2 (9.2)

Part Number A96596-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

4
Administering Real Application Clusters Databases with the Server Control Utility, SQL, and SQL*Plus

This chapter explains how to administer instances and databases in Real Application Clusters environments using the Server Control (SRVCTL) Utility, SQL, and SQL*Plus. The topics in this chapter include:

Administering Real Application Clusters Environments with SRVCTL

This chapter explains how to administer Real Application Clusters environments using Real Application Clusters with the Oracle Server Control (SRVCTL) Utility. This chapter includes the following topics:

Overview of Using SRVCTL to Administer Real Application Clusters

Oracle Corporation recommends that you use SRVCTL as the primary tool to administer the Real Application Clusters environment. SRVCTL manages configuration information that is used by several Oracle tools. For example, Oracle Enterprise Manager and Oracle Intelligent Agent use 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 SRVM configuration repository that is used with other Oracle administrative interfaces.

See Also:

Oracle9i Real Application Clusters Setup and Configuration for more information about the SRVM configuration repository


Note:

Before and after each configuration change, back up the SRVM configuration repository.


Before using SRVCTL, ensure that your Global Services Daemon (GSD) is running. Do this by executing the appropriate command to run the GSD based on your platform. Oracle should respond with a message stating that the GSD is already running. For information on GSD, Refer to "Global Services Daemon (GSD)".

Note:

To use SRVCTL, you must have already created the configuration information for the database that you want to administer. You must have done this either by using the srvctl add command as described in the chapter about manually creating Real Application Cluster databases, or by using the Database Configuration Assistant (DBCA). Both of these topics are described in Oracle9i Real Application Clusters Setup and Configuration.

See Also:

Oracle Intelligent Agent User's Guide for more information about the Oracle Intelligent Agent

Global Services Daemon (GSD)

The Global Services Daemon (GSD) records information such as connection requests from SRVCTL and stores these records the gsdaemon_node_name.log file in the $ORACLE_HOME/srvm/log directory. Clients of the GSD, such as SRVCTL, the DBCA, and Oracle Enterprise Manager, interact with the GSD to perform various manageability operations on the nodes in your cluster.

Clients of the Global Services Daemon (GSD), such as SRVCTL, the DBCA, and Oracle Enterprise Manager, interact with the GSD to perform various manageability operations on the nodes in your cluster database. You must start the GSD on all the nodes in your Real Applications Clusters database so that the manageability features and tools operate properly.

For example, if you start an instance using Oracle Enterprise Manager, then the Intelligent Agent launches a script that contains SRVCTL commands. The GSD executes these commands which correspond to the requested operation.

UNIX GSD Implementations

The name of the Global Services Daemon on UNIX platforms is gsd and is located in the $ORACLE_HOME/bin directory. The GSD records information such as connection requests from SRVCTL and stores these records the gsdaemon_node_name.log file in the $ORACLE_HOME/srvm/log directory, where node_name represents the instance number to support cluster file system environments.

Windows GSD Implementations

The name of the GSD service on Windows NT and Windows 2000 platforms is OracleGSDService and is located in the %ORACLE_HOME%\bin directory. The GSD service records information such as connection requests from SRVCTL and stores these records in the gsdaemon_node_name.log file in the %ORACLE_HOME%\srvm\log directory, where node_name represents the name of the node to support cluster file system environments.

SRVCTL Administrative Tasks

This section describes the tasks you can accomplish using the SRVCTL utility to administer Real Application Clusters. You can use SRVCTL to perform two types of administrative tasks as listed under the following sub-headings:

SRVCTL Cluster Database Tasks

SRVCTL Cluster Database Configuration Tasks

SRVCTL Command Syntax

This section describes the SRVCTL command syntax.

SRVCTL Syntax Components

SRVCTL syntax has the following components:

srvctl verb noun options

Where:

To see the online command syntax and options for each SRVCTL command, enter:

srvctl verb noun -h

To see a list of command verbs and nouns, enter:

srvctl

To see the version number of SRVCTL, enter:

srvctl -V

Concurrent SRVCTL Commands

One SRVCTL action is executed on one object at a time. SRVCTL does not support concurrent execution of commands on the same object.

Stopping SRVCTL Operations

If you enter Control-C to stop an SRVCTL operation, then the control-C is trapped. If SRVCTL displays progress messages for a command that is executing, then these messages stop and control returns to you. By default, the commands that are executing or queued to execute do not stop.

SRVCTL Error Messages

SRVCTL error messages are documented in Appendix C, "Real Application Clusters Management Tools Error Messages" of this book.

Common SRVCTL Syntax Components

The following are the common SRVCTL command syntax verbs and options. All operations performed with SRVCTL are case insensitive and case preserving.

Command Syntax

The following section describes the SRVCTL command syntax. The syntax described in this section is of the format:

srvctl verb noun [options]

Common Verbs

Table 4-1 lists the common verbs in alphabetical order. You can use these verbs with any SRVCTL command.

Table 4-1  Common SRVCTL Verbs
Verb Meaning

add

Add a database or instance

config

List the configuration for the database or instance

getenv

List the environment variables in the SRVM configuration

modify

Modify the instance configuration

remove

Remove the database or instance

setenv

Set the environment variable in the SRVM configuration

start

Start the database or instance

status

Status of the database or instance

stop

Stop the database or instance

unsetenv

Set the environment variable in the SRVM configuration to unspecified

Common Nouns

Table 4-2 lists the common nouns in alphabetical order. You can use these nouns with any SRVCTL command.

Table 4-2  Common SRVCTL Nouns
Noun (Abbreviation) Meaning

database (db)

Operation refers to objects for the database

instance (inst)

Operation refers to objects for the instances

Syntax Flags

Table 4-3 shows the various SRVCTL command syntax flags and their meanings.

Table 4-3  SRVCTL Syntax Flags
Flag Meaning

-h

Help

-i

instance

-n

node

-f

force

Common Options

Table 4-4 lists the common command options in alphabetical order. You can use these options with any SRVCTL command. Other options depend on the verb that is being executed.

Table 4-4  Common SRVCTL Command Options
Option Meaning

-d

Database name

-h

Print usage

-i

Comma-separated list of instance names for the operation

-n

Node name or comma separated node list

SRVCTL Commands

The following section describes the SRVCTL commands in alphabetical order.

SRVCTL Add

Adds configuration information for the database or for named instances. When adding an instance, the name that you specify with -i should match the INSTANCE_NAME and ORACLE_SID parameters.

srvctl add database -d database_name [-m domain_name] -o oracle_home [-s spfile] 
srvctl add instance -d  database_name  -i instance_name -n node_name  

Table 4-5  Command-Specific Options for SRVCTL Add
Command Option

-m

Database domain name, in the form "us.mydomain.com".

The database domain name for the -m option must match the DB_DOMAIN and DB_NAME parameters in INIT.ORA or SPFILE. When adding a database, the name that you specify with -d should match the DB_NAME parameter.

n

Node name that will support an instance.

-o

$ORACLE_HOME to locate lsnrctl (node option) and Oracle binaries (other options).

-s

SPFILE name.

Examples of SRVCTL Add

The following are examples of using the add command.

To add a new database:

srvctl add  database  -d mydb -o /ora/ora9

To add named instances to a database:

srvctl add instance -d mydb -i  mydb01 -n gm01 
srvctl add instance -d mydb -i  mydb02 -n gm02 
srvctl add instance -d mydb -i  mydb03 -n gm03 

SRVCTL Config

Displays the configuration that is stored in the SRVM configuration file.

srvctl config database 

Displays a list of configured databases.

srvctl config database -d database_name

Displays the specified database configuration in the following format:

nodename1 instancename1 oraclehome
nodename2 instancename2 oraclehome

Examples of SRVCTL Config

The following are examples of using the config command.

To display database configuration:

srvctl config database -d mydb

SRVCTL Getenv

The getenv operation gets and displays values for the environment from the SRVM configuration file.

srvctl getenv database -d database_name [-t name[,name,...]]
srvctl getenv instance -d database_name -i instance_name [-t name[,name,...]]

Example of SRVCTL Getenv

To list all environment variables for a database:

srvctl getenv database -d mydb

SRVCTL Modify

Modify enables modification of the instance-node configuration. Using modify preserves the environment in the SRVM configuration that would otherwise need to be re-entered. The configuration description is modified in the SRVM configuration repository. The change takes effect when the application is next restarted.

Modify with the instance option moves the named instance to a new node. This node cannot support another instance for the same database. The move is permanent.

srvctl modify instance -d database_name -i instance_name -n node_name

Example of SRVCTL Modify

The following is an example of using the modify command.

To modify a named instance to execute on another node:

srvctl modify  instance  -d mydb  -n my_new_node

SRVCTL Remove

This command removes the configuration information from the SRVM repository. Environment settings for the object are also removed. If you do not use the force flag (-f), then Oracle prompts you to confirm the removal.

You are then asked if you wish to proceed. With the force (-f) option, the remove proceeds without prompting.

srvctl remove database -d database_name [-f]
srvctl remove instance  -d database_name -i instance_name [-f]

Command-Specific Options for SRVCTL Remove

-f

Force the removal of the application without prompting.

Examples of SRVCTL Remove

The following are examples of using the remove command.

To remove the applications for a database:

srvctl remove  database  -d mydb 

To remove the applications for named instances of a database:

srvctl remove instance -d mydb -i  mydb01 
srvctl remove instance -d mydb -i  mydb02 
srvctl remove instance -d mydb -i  mydb03 

SRVCTL Setenv

The setenv operation sets values for the environment in the SRVM configuration file.

srvctl setenv database -d database_name -t name=value [,name=value,...]
srvctl setenv instance -d database_name [-i instance_name] -t name=value 
[,name=value,...]

Example of SRVCTL Setenv

The following is an example of using the setenv command.

Set environment for database:

srvctl setenv database -d mydb -t LANG=en

SRVCTL Start

Starts the database, all or named instances, and all listeners associated with the database if they are not already started.


Note:

For the start command, and for other operations that use a connect string, if you do not provide a connect string, then Oracle uses "/ as sysdba" to perform the operation on the instance. In other words, to execute such operations you must be a member of the OSDBA group. For more information on OSDBA group membership, refer to the Oracle9i Installation Guide.


srvctl start database -d database_name [-o  start_options] [-c connect_string] 
srvctl start instance -d database_name -i instance_name [,instance_name-list] 
[-o start_options] [-c connect_string]

Table 4-6  Command-Specific Options for SRVCTL Start
Command Option

-o

Options passed directly to startup command in SQL*Plus including PFILE.

-c

Connect string for connecting to the Oracle instance using SQL*Plus.



Examples of SRVCTL Start

The following are examples of the start command.

To start the database and all enabled instances:

srvctl start database -d mydb

To start instances:

srvctl start instance  -d mydb -i mydb1,mydb4

SRVCTL Status

Display the current state of the named database.

srvctl status database -d database_name
srvctl status instance -d database_name -i instance_name [,instance_name-list]

Examples of SRVCTL Status

The following are examples of using the status command.

Status of the database and all instances:

srvctl status database -d mydb

Status of named instances:

srvctl status instance -d mydb -i mydb1,mydb2

SRVCTL Stop

Stops the database and all or named instances. This does not stop listeners.

srvctl stop database -d database_name [-o stop_options] [-c connect_string]
srvctl stop instance -d database_name -i instance_name [,instance_name_list] [-o 
stop_options][-c connect_string]

Table 4-7  Command-Specific Options for SRVCTL Stop
Command Option

-c

Connect string for connecting to the Oracle instance using SQL*Plus

-o

Options passed directly to shutdown command in SQL*Plus



Examples of SRVCTL Stop

The following are examples of using the stop command.

Stop the database all instances:

srvctl stop database -d mydb

Stop named instances:

srvctl stop instance  -d mydb -i mydb1

SRVCTL Unsetenv

The unsetenv operation unsets values for the environment in the SRVM configuration file.

srvctl unsetenv database -d database_name-t name[,name,...]
srvctl unsetenv instance -d database_name[-i instance_name] -t name[,name,...]

Example of SRVCTL Unsetenv

The following is an example of using the unsetenv command.

Unset an environment variable back to unspecified:

srvctl unsetenv database -d mydb -t CLASSPATH

Importing and Exporting Raw Device Configurations with SRVCONFIG

You can use SRVCONFIG to import and export raw device configuration information whether the configuration file resides on a cluster file system file or on a raw device. You might do this to back up or restore the SRVM configuration information. For example, the following syntax exports the contents of the configuration information to the text file that you name:

srvconfig -exp file_name

As another example, the following imports the configuration information from the text file you name to the configuration repository for the Real Application Clusters environment in which you execute the command:

srvconfig -imp file_name

Upgrading Oracle8i Configurations to Oracle9i

If you are upgrading from Oracle8i to Oracle9i, upgrade your configuration information using the following post-installation procedure. Do this for each Real Application Clusters database:

  1. Stop all Global Services Daemons (GSD) by executing the gsdctl stop command.
  2. Execute the following command from the node in a UNIX cluster where the
    db_name.conf file is located:
    srvconfig -conv $Oracle_Home/ops/db_name.conf
    
    

Administering the GSD

You can use gsdctl commands to start, stop, and obtain the status of the GSD service on any platform. The options for gsdctl are:

Administering Real Application Clusters Databases Using SQL and SQL*Plus

Although Oracle Corporation recommends that you use SRVCTL to administer your Real Application Clusters database environment, you can also use SQL and SQL*Plus. Prior to performing the tasks with SQL and SQL*Plus as described in this section, ensure your Cluster Manager (CM) component is started on each node.

The SQL and SQL*Plus procedures you use to start your cluster database depends on your platform as explained under the following sub-headings:

Starting Databases in Cluster Mode on UNIX

To start a Real Application Clusters database in cluster mode:

  1. Ensure your Cluster Manager software is running. Instructions on Cluster Manager software administration appear in your operating system-specific documentation. If the Cluster Manager is not available or if Oracle cannot communicate with this component, Oracle displays the error ORA-29701: "Unable to connect to Cluster Manager".
  2. Start any required operating system-specific processes. For more information about these processes, see your operating system-specific documentation.
  3. If the listener is not started, start it on each of the nodes. Enter:
    LSNRCTL
    LSNRCTL> start [listener_name]
    
    

    Where listener_name is the name of the listener defined in the listener.ora file. It is not necessary to identify the listener if you are using the default listener named LISTENER.

    LSNRCTL displays a status message indicating that the listener started successfully. You can check that all expected services for that listener are listed in the services summary in the status message. You can also check the status of the listener with the LSNRCTL STATUS command.

  4. Start the database on one of the nodes by starting SQL*Plus. Then enter:
    CONNECT SYS/password as SYSDBA
    
        STARTUP PFILE=init$ORACLE_sid.ora
    
    

    The first instance to start in cluster mode determines the values of any global parameters for the other instances. When another instance attempts to start in cluster mode, the Real Application Clusters database compares the values of any global parameters in its parameter file with those already in use and issues messages if any values are incompatible. An instance cannot mount the database unless it has the correct values for its global parameters.

  5. On the remaining nodes, start the database:
    CONNECT SYS/password as SYSDBA
    
        STARTUP PFILE=$ORACLE_sid.ora; 
    

Starting Databases in Cluster Mode on Windows NT and Windows 2000

To start the Real Application Clusters database in cluster mode on Windows platforms:

  1. Start OracleServicesid instance on each node.

    • From the MS-DOS command line enter:
      C:\> net start OracleServicesid
      
      
    • From the Control Panel's Services window, select OracleServicesid, then click Start.
  2. If the listener is not started, start it on each of the nodes. Enter:
    LSNRCTL
    LSNRCTL> start [listener_name]
    
    

    Where listener_name is the name of the listener defined in the listener.ora file. You do not have to identify the listener if you are using the default listener named LISTENER.

    LSNRCTL displays a status message indicating that the listener started successfully. You can check that all expected services for that listener appear in the services summary in the status message. You can also check the status of the listener with the LSNRCTL STATUS command.

  3. Start the database on one of the nodes by starting SQL*Plus. Then enter:
    CONNECT SYS\password
    
    
        STARTUP PFILE=%ORACLE_HOME%\database\initsid.ora; 
    
    

    The first instance to start in cluster mode determines the values of any global parameters for the other instances. When another instance attempts to start in cluster mode, the Real Application Clusters database compares the values of any global parameters in its parameter file with those already in use and issues messages if any values are incompatible. The instance cannot mount the database unless it has the correct values for its global parameters.

  4. On the remaining nodes, start the database:
    CONNECT SYS\password
    
    
        STARTUP PFILE=%ORACLE_HOME%\database\initsid.ora; 
    

Using RETRY to Mount a Database in Cluster Mode

If you attempt to start an instance and mount a database in cluster mode while another instance is recovering the same database, your current instance cannot mount the database until the recovery is complete. Rather than repeatedly attempting to start the instance, use the STARTUP RETRY statement. This causes the new instance to retry mounting the database every five seconds until it succeeds or has reached the retry limit. Use the syntax:

STARTUP OPEN database_name RETRY

To set the maximum number of times the instance attempts to mount the database, use the SQL*Plus SET command with the RETRY option. You can specify either an integer such as 10, or the keyword INFINITE.

If the database can only be opened by being recovered by another instance, then using the RETRY does not repeat connection attempts. For example, if the database was mounted in exclusive mode by one instance, then trying the STARTUP RETRY command in cluster mode does not work for another instance.


Note:

Because an instance startup does not affect the datafiles, you can start an instance without mounting the datafiles.


Setting and Connecting to Instances

Before setting instances and connecting to them, you must install and configure Oracle Net for the Real Application Clusters nodes and any clients that access these nodes. This establishes remote connections from the clients to the nodes.

See Also:

SQL*Plus commands operate on the current instance with some exceptions as noted under the next heading, "The SET INSTANCE and SHOW INSTANCE Commands".

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. Because the SQL*Plus prompt does not show which instance is the current instance, be sure you 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 switch the current instance from the local instance to a remote instance, do one of the following:

Issue another CONNECT command with only your user ID and password. Specifying a remote instance with the CONNECT command while connected to the database by way of an instance enables you to switch from one instance to another without disconnecting.

See Also:
  • The Oracle9i Net Services Administrator's Guide for information on configuring net service names
  • Your operating system-specific Oracle documentation for more information about the exact format required for the connect string used in the SET INSTANCE and CONNECT commands

The SET INSTANCE and SHOW INSTANCE Commands

When using SET INSTANCE to specify an instance on a remote node for the STARTUP command, the parameter file for the remote instance must be accessible by the local node.

The SHOW INSTANCE command displays the net service name for the current instance. SHOW INSTANCE returns the value local if you have not used SET INSTANCE during the SQL*Plus session.

To reset to the default instance, use SET INSTANCE without specifying a net service name or specify local. Do not follow the SET INSTANCE command with the word default; this syntax specifies a connect string for an instance named default.

The CONNECT Command

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:

Verifying That Instances are Running

To verify that instances are running:

  1. On any node, enter:
    CONNECT SYS/password
    SELECT * FROM V$ACTIVE_INSTANCES;
    
    

    Oracle returns output similar to the following:

    INST_NUMBER INST_NAME          
    -----------  ----------------- 
               1 db1-sun:db1  
               2 db2-sun:db2  
               3 db3-sun:db3  
    
    

Where the output columns from this SELECT statement are as described in Table 4-8:

Table 4-8  Descriptions of V$ACTIVE_INSTANCES Columns
Column Description

INST_NUMBER

Identifies the instance number.

INST_NAME

Identifies the host name and instance name.

Shutting Down Real Application Clusters Instances

Shutting down Real Application Clusters instances is procedurally identical to shutting down instances in single instance environments with these exceptions:

Quiescing A Real Application Clusters Database

Quiescing a Real Application Clusters database is procedurally identical to quiescing a single-instance database except as described in this section. For example, you cannot open the database on one instance if the database is being quiesced. In other words, if you issued the ALTER SYSTEM QUIESCE RESTRICTED statement but Oracle has not finished processing it, you cannot open the database. Nor can you open the database if it is already in a quiesced state. In addition, the ALTER SYSTEM QUIESCE RESTRICTED and ALTER SYSTEM UNQUIESCE statements affect all instances in a Real Application Clusters environment, not just the instance that issues the command.

See Also:

The Oracle9i Database Administrator's Guide for details on the quiesce database feature and the Oracle9i SQL Reference for more information about the ALTER SYSTEM QUIESCE RESTRICTED syntax

How SQL and SQL*Plus Commands Affect Instances

Most SQL statements affect the current instance. For example, the statement ALTER SYSTEM SET CHECKPOINT LOCAL only affects the instance to which you are currently connected, rather than the default instance or all instances.

ALTER SYSTEM CHECKPOINT LOCAL also affects the current instance. By contrast, ALTER SYSTEM CHECKPOINT or ALTER SYSTEM CHECKPOINT GLOBAL affects all instances.

ALTER SYSTEM SWITCH LOGFILE affects only the current instance. To force a global log switch, use the ALTER SYSTEM ARCHIVE LOG CURRENT statement. The THREAD option of ALTER SYSTEM ARCHIVE LOG enables you to archive each online redo log file for a specific instance.

Table 4-9 describes how common SQL*Plus commands affect instances.

Table 4-9  How SQL*Plus Commands Affect Instances
SQL*Plus Command Associated Instance

ARCHIVE LOG

Always affects to the current instance.

CONNECT

Affects the default instance if no instance is specified in the CONNECT command.

HOST

Affects to the node running the SQL*Plus session, regardless of the location of the current and default instances.

RECOVER

Does not affect any particular instance, but rather the database.

SHOW INSTANCE

Displays information about the current instance, which can be different from the default local instance if you have redirected your commands to a remote instance.

SHOW PARAMETER and SHOW SGA

Display parameter and SGA information from the current instance.

STARTUP and SHUTDOWN

Always affects the current instance. These are privileged SQL*Plus commands.


Note:

The security mechanism that Oracle uses when you execute privileged SQL*Plus commands depends on your operating system. Most operating systems have a secure authentication mechanism when logging onto the operating system. On these systems, your default operating system privileges usually determine whether you can use STARTUP and SHUTDOWN. For more information, refer to your operating system-specific documentation.



Go to previous page Go to next page
Oracle
Copyright © 1998, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback