Release 1 (9.0.1)
Part Number A89869-02
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle9i Real Application Clusters Administration Release 1 (9.0.1) Part Number A89869-02 |
|
This chapter explains how to administer instances and databases in Real Application Clusters environments using Server Control (SRVCTL), SQL, and SQL*Plus. The topics in this chapter include:
Chapter 5, "Administering Real Application Clusters Databases with Oracle Enterprise Manager" for information on using Oracle Enterprise Manager to administer Real Application Clusters
See Also:
Oracle Corporation recommends that you use SRVCTL to administer your Real Application Clusters database environment. SRVCTL manages configuration information that is used by several Oracle tools. For example, Oracle Enterprise Manager and the Intelligent Agent use the configuration information that SRVCTL generates to discover and monitor nodes in your cluster.
Before using SRVCTL, ensure that your Global Services Daemon (GSD) is running after you configure your database as described in Oracle9i Real Application Clusters Installation and Configuration. 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 more information on using the Global Services Daemon, 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 Oracle Database Configuration Assistant (DBCA), or by using the |
This section describes how to use the SRVCTL utility to administer instances in Real Application Clusters. You can use SRVCTL to perform two types of administrative tasks as listed under the following sub-headings:
For procedures on adding nodes, refer to Chapter 9, "Adding Nodes and Instances and Deleting Instances in Real Application Clusters"
See Also:
To see the online command syntax and options for each SRVCTL command, enter:
srvctl command option -h
Where command option is one of the valid options such as start, stop, or status. To see a list of available command options, enter:
srvctl
The remainder of this section describes the SRVCTL commands.
Use the srvctl start command to start all instances or a subset of instances in your Real Application Clusters database. For example, to start all the instances use the syntax:
srvctl start -p db_name
Or you can start specific instances using the syntax:
srvctl start -p db_name -i instance_name
This syntax starts the specific instance that you name. Using srvctl start also starts all listeners associated with an instance.
Use the -s option (lower-case s) as in the following syntax where stage is either inst or lsnr:
srvctl start -p db_name -s stage
Use this syntax to separately start instances and listeners.
Use the srvctl stop command to stop all instances or a subset of instances in your Real Application Clusters database. For example, to stop all instances use the syntax:
srvctl stop -p db_name
Or you can stop specific instances using:
srvctl stop -p db_name -i instance_name
Using srvctl stop also stops all listeners associated with an instance.
Use the -s option (lower-case s) as in the following syntax where stage is either inst or lsnr:
srvctl stop -p db_name -s stage
Use this syntax to separately stop instances and listeners.
Use the srvctl status command to determine what instances are running. For example, use the output from the following syntax to identify which instances are running:
srvctl status -p db_name
Use the -s option (lower-case s) as in the following syntax where stage is either inst or lsnr:
srvctl status -p db_name -s stage
Use this syntax to obtain the status of an instance or a listener.
Use the srvctl config command to identify the existing Real Application Clusters databases. You can use two syntaxes for srvctl config. For example, the following syntax lists all the Real Application Clusters databases in your environment:
srvctl config
The following syntax lists the instances for the Real Application Clusters database name that you provide:
srvctl config -p db_name
The Oracle Enterprise Manager auto-discovery process also uses output from this command to discover the configurations for databases in your Real Application Clusters.
Use the srvctl get env command to obtain environment information for either a specific instance or for an entire Real Application Clusters database. For example, the output from the following syntax displays environment information for the entire Real Application Clusters database identified by the name you provide:
srvctl get env -p db_name
The following syntax displays environment information for a specific instance:
srvctl get env -p db_name -i instance_name
The remaining SRVCTL commands update your configuration information. If you use these commands, you must also use SQL to add or remove database objects as needed so that your instance or database can operate. For example, you must add redo log groups and thread IDs for instances if you use the srvctl add instance command.
The srvctl add db command creates the configuration for the Real Application Clusters database. For example, the following syntax adds the configuration information for a Real Application Clusters database to the configuration repository.
srvctl add db -p db_name -o oracle_home
This database is identified by the name that you provide in the command syntax. You must then execute the srvctl add instance command to add instance configurations to the database.
Use the srvctl add instance command to add static configuration information for an instance. For example, the following syntax adds an instance using the instance name that you provide:
srvctl add instance -p db_name -i instance_name -n node_name
As mentioned, this command only updates the configuration; it does not create the database. Execute the srvctl add db command before using the srvctl add instance command.
Use the srvctl delete instance command to delete static configuration information for a Real Application Clusters instance. For example, the following syntax deletes the configuration for the instance identified by the database name that you provide:
srvctl delete instance -p db_name -i instance_name
Use the srvctl delete db command to delete the static configuration for a Real Application Clusters database. For example, the following syntax deletes the Real Application Clusters database identified by the name that you provide:
srvctl delete db -p db_name
Use the srvctl rename instance command to rename a Real Application Clusters database instance. For example, the following syntax renames the Real Application Clusters instance identified by the name that you provide:
srvctl rename instance -p db_name -i old_name -e new_name
Use the srvctl move instance command to move a Real Application Clusters instance from one node to another in the static configuration. For example, the following syntax moves the Real Application Clusters instance to the node identified by the node name that you provide:
srvctl move instance -p db_name -i instance_name -n new_node
Use the srvctl set env command to set the environment that Oracle uses when you start instances in a Real Application Clusters database that you name. For example, the following syntax sets the environment for an entire Real Application Clusters database:
srvctl set env -p db_name -t name=value
You can also set the environment for specific instances. For example, the following syntax sets the environment variable for the Real Application Clusters database instance that you name:
srvctl set env -p db_name -t name=value -i instance_name
An example of this command is:
srvctl set env -p proddb -t LANG=en
Use the srvctl unset env command to unset the environment that Oracle uses when you start instances in the Real Application Clusters database that you name. For example, the following syntax unsets the environment variable for an entire Real Application Clusters database:
srvctl unset env -p db_name -t environment_variable
An example of this command is:
srvctl unset env -p proddb -t LANG
You can also unset the environment for specific instances. For example, the following syntax unsets the environment variable for the Real Application Clusters database instance that you name:
srvctl unset env -p db_name -t environment_variable -i instance_name
An example of this command is:
srvctl unset env -p proddb -t LANG -i proddb1
Use SRVCONFIG to import and export raw device 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
While the following example imports 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
If you are upgrading from Oracle8i to Oracle9i, migrate your configuration information using the following post-installation procedure. Do this for each Real Application Clusters database:
.conf file is located:
srvconfig -conv $Oracle_Home/ops/db_name.conf
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. 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, the Intelligent Agent launches a script that contains SRVCTL commands. The GSD executes these commands which correspond to the requested operation.
The name of the Global Services Daemon on UNIX platforms is gsd. The GSD is located in the $ORACLE_HOME/bin directory. The GSD records information such as connection requests from SRVCTL and stores these records the gsdaemon.log file in the $ORACLE_HOME/srvm/log directory.
The name of the GSD service on Windows NT and Windows 2000 platforms is OracleGSD. The GSD service 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 gsdservice.log file in the %ORACLE_HOME%\srvm\log directory.
You can use gsdservice commands to install the GSD service in the Windows Services panel. You can also use this command to start and stop the GSD service. The options for gsdservice are:
gsdservice -install -- To install the GSD service in the Services panel
gsdservice -start -- To start the GSD service
gsdservice -remove -- To stop and delete the GSD service
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:
To start a Real Application Clusters database in cluster mode:
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.
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.
CONNECT SYS/password as SYSDBA
STARTUP PFILE=$ORACLE_sid.ora;
To start the Real Application Clusters database in cluster mode on Windows platforms:
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.
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.
CONNECT SYS\password
STARTUP PFILE=%ORACLE_HOME%\database\initsid.ora;
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 data files, you can start an instance without mounting the data files. |
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.
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:
CONNECT command specifying a remote instance net service name as in this example:
CONNECT SYSTEM/MANAGER@net_service_name
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:
|
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.
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:
|
To verify that instances are running:
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-1:
| Column | Description |
|---|---|
|
|
Identifies the instance number. |
|
|
Identifies the host name and instance name. |
Shutting down Real Application Clusters instances is procedurally identical to shutting down instances in single instance environments with these exceptions:
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.
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.
Oracle9i Database Administrator's Guide for more information on shutting down Oracle databases
See Also:
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 |
Most SQL statements apply to the current instance. For example, the statement ALTER SYSTEM SET CHECKPOINT LOCAL only applies to the instance to which you are currently connected, rather than the default instance or all instances.
ALTER SYSTEM CHECKPOINT LOCAL also applies to the current instance. By contrast, ALTER SYSTEM CHECKPOINT or ALTER SYSTEM CHECKPOINT GLOBAL applies to all instances.
ALTER SYSTEM SWITCH LOGFILE applies only to 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 online redo log files for a specific instance.
Table 4-2 describes how common SQL*Plus commands affect instances.
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|