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
Global Services Daemon (GSD)
SRVCTL Command Syntax

Common SRVCTL Syntax Components

See Also:

Chapter 5, "Administering Real Application Clusters Databases with Oracle Enterprise Manager" for information about using Oracle Enterprise Manager to administer Real Application Clusters

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

Start and stop cluster databases
Start and stop cluster database instances
Obtain the statuses of a cluster database, cluster database instances

SRVCTL Cluster Database Configuration Tasks

Add and delete cluster database configuration information
Add an instance to and delete an instance from the configuration of a cluster database
Move instances in a cluster database configuration
Set and unset the environment for an instance in a cluster database configuration
Set and unset the environment for an entire cluster database in a cluster database configuration

SRVCTL Command Syntax

This section describes the SRVCTL command syntax.

SRVCTL Syntax Components

SRVCTL syntax has the following components:

srvctl verb noun options

Where:

srvctl is the SRVCTL command.
verb is an action word such as start, stop, or remove.
noun is an object upon which SRVCTL performs the action verb, such as database or instance. Or you can use abbreviations, which in this case are db and inst respectively.
options extends the use of preceding verb-noun combinations to include addition information for the command. That is, the -i option indicates that a comma-separated list of instance names will follow (sometimes the -i option only permits one value and not a list of names), or the -n option indicates that a node name or a comma-separated list of node names follows.

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:

Stop all Global Services Daemons (GSD) by executing the gsdctl stop command.
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:

gsdctl start -- To start the GSD service
gsdctl stop -- To stop the GSD service
gsdctl stat -- To obtain the status of the GSD service

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:

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".
Start any required operating system-specific processes. For more information about these processes, see your operating system-specific documentation.
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.
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.

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:

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

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:

Re-execute the CONNECT command specifying a remote instance net service name as in this example:
```
CONNECT SYSTEM/MANAGER@net_service_name
```
Disconnect from the database and execute a SET INSTANCE command as in this example:
```
SET INSTANCE net_service_name
```

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:

The Oracle9i Net Services Administrator's Guide or the proper specification of net_service_name
Oracle9i Database Administrator's Guide for information on connecting to the database using SYSDBA or SYSOPER privileges

Verifying That Instances are Running

To verify that instances are running:

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:

In Real Application Clusters, shutting down one instance does not interfere with the operation of other running instances.
To shut down a Real Application Clusters database mounted in shared mode, shut down every instance in the Real Application Clusters environment.
When you shut down an instance abnormally, Oracle forces all user processes running in that instance to log off the database. If a user process is currently accessing the database, Oracle terminates that access and displays the message "ORA-1092: Oracle instance terminated. Disconnection forced". If a user process is not currently accessing the database when the instance shuts down, Oracle displays the message "ORA-1012: Not logged on" upon the next call or request made to Oracle.
After a NORMAL or IMMEDIATE shutdown, instance recovery is not required. Recovery is required, however, after you issue the SHUTDOWN ABORT command or after an instance terminates abnormally. The SMON process of an instance that is still running performs instance recovery for the instance that shut down. If no other instances are running, the next instance to open the database performs instance recovery for any instances needing it.
The SHUTDOWN TRANSACTIONAL command with the LOCAL option is useful to shutdown an instance after all active transactions on the instance have either committed or rolled back. This is in addition to what this command does for SHUTDOWN IMMEDIATE. Transactions on other instances do not block this operation. If you omit the LOCAL option, then this operation waits until transactions on all other instances that started before the shutdown was issued either commit or rollback.
If multiple SQL*Plus sessions are connected to the same instance simultaneously, all but one must disconnect before the instance can shut down normally. You can use the IMMEDIATE or ABORT option of the SHUTDOWN command to shut down an instance when multiple SQL*Plus sessions (or any other sessions) are connected to it.

See Also:
Oracle9i Database Administrator's Guide for more information on shutting down Oracle databases

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***

*SQLPlus 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.

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

Administering Real Application Clusters Environments with SRVCTL

Overview of Using SRVCTL to Administer Real Application Clusters

Global Services Daemon (GSD)

UNIX GSD Implementations

Windows GSD Implementations

SRVCTL Administrative Tasks

SRVCTL Cluster Database Tasks

SRVCTL Cluster Database Configuration Tasks

SRVCTL Command Syntax

SRVCTL Syntax Components

Concurrent SRVCTL Commands

Stopping SRVCTL Operations

SRVCTL Error Messages

Common SRVCTL Syntax Components

Command Syntax

Common Verbs

Table 4-1 Common SRVCTL Verbs

Common Nouns

Table 4-2 Common SRVCTL Nouns

Syntax Flags

Table 4-3 SRVCTL Syntax Flags

Common Options

Table 4-4 Common SRVCTL Command Options

SRVCTL Commands

SRVCTL Add

Table 4-5 Command-Specific Options for SRVCTL Add

Examples of SRVCTL Add

SRVCTL Config

Examples of SRVCTL Config

SRVCTL Getenv

Example of SRVCTL Getenv

SRVCTL Modify

Example of SRVCTL Modify

SRVCTL Remove

Command-Specific Options for SRVCTL Remove

Examples of SRVCTL Remove

SRVCTL Setenv

Example of SRVCTL Setenv

SRVCTL Start

Table 4-6 Command-Specific Options for SRVCTL Start

Examples of SRVCTL Start

SRVCTL Status

Examples of SRVCTL Status

SRVCTL Stop

Table 4-7 Command-Specific Options for SRVCTL Stop

Examples of SRVCTL Stop

SRVCTL Unsetenv

Example of SRVCTL Unsetenv

Importing and Exporting Raw Device Configurations with SRVCONFIG

Upgrading Oracle8i Configurations to Oracle9i

Administering the GSD

Administering Real Application Clusters Databases Using SQL and SQL*Plus

Starting Databases in Cluster Mode on UNIX

Starting Databases in Cluster Mode on Windows NT and Windows 2000

Using RETRY to Mount a Database in Cluster Mode

Setting and Connecting to Instances

The SET INSTANCE and SHOW INSTANCE Commands

The CONNECT Command

Verifying That Instances are Running

Table 4-8 Descriptions of V$ACTIVE_INSTANCES Columns

Shutting Down Real Application Clusters Instances

Quiescing A Real Application Clusters Database

How SQL and SQL*Plus Commands Affect Instances

Table 4-9 How SQL*Plus Commands Affect Instances

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

Table 4-9 ***How SQL*Plus Commands Affect Instances***