12/19

# 7 Configuring Single-Instance Databases for High Availability and Disaster Tolerance

Oracle Fail Safe provides high availability for single-instance Oracle databases (both Oracle Database Standard and Enterprise Editions) running on Windows clusters configured with MSCS.

By making a single-instance Oracle database highly available, you ensure that even when a cluster node is shut down or fails, applications that access that database will suffer only a momentary loss of connection with the database while the database is restarted on another cluster node. Applications can automatically reconnect to the database after such a failover event occurs using transparent application failover, resulting in a failover that is not apparent to users.

This chapter discusses the following topics:

- Discovering Standalone Single-Instance Databases

- Oracle Net Configuration for Standalone Single-Instance Databases

- Adding Single-Instance Oracle Databases to a Group

- Oracle Net Listener Resource Creation and Configuration

- Security Requirements for Single-Instance Databases

- Optimizations for Single-Instance Database Recovery

- Performing Administrative Tasks on a Single-Instance Fail-Safe Database

- Configuring Transparent Application Failover (TAF)

- Handling Errors and Troubleshooting Problems with Databases

## 7.1 Discovering Standalone Single-Instance Databases

Oracle Services for MSCS discovers standalone single-instance databases (those that are not in a group) to display them in the Oracle Fail Safe Manager tree view. Standalone single-instance databases created with the `Create Sample Database` command (sample databases) and standalone single-instance databases created using other methods are discovered in different ways, as follows:

- Sample standalone databases

  Sample standalone single-instance databases are discovered by looking in the Windows registry under the key:

  `HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\FailSafe\SampleDB`

- Other standalone single-instance databases

  Other standalone single-instance databases (those not created with `Create Sample Database` command) are discovered by parsing the `tnsnames.ora` file on each cluster node and looking for valid net service name entries. Standalone single-instance databases are discovered when the following conditions are true:

  - The standalone single-instance database has an instance on a cluster node.

  - The standalone single-instance database has a valid entry in the `tnsnames.ora` file, including:

    - A `SID` that matches the database instance on the node or a `SERVICE_NAME` that matches the service name in the database parameter file.

    - A host name or IP address (Oracle Fail Safe does not support the use of alias network names.)

  If no valid net service name entry can be found for an instance, then the instance name is used to represent the database instance in Oracle Fail Safe Manager.

To view the standalone single-instance databases (and other standalone resources) in the Oracle Fail Safe Manager tree view, expand each node folder, then expand the Standalone Resources folder.

## 7.2 Oracle Net Configuration for Standalone Single-Instance Databases

The following sections briefly summarize the Oracle Net configuration for standalone single-instance databases.

### 7.2.1 Updating the Oracle Net Configuration for a Database Created Using DBCA

If you use the Database Configuration Assistant (DBCA) to create a standalone single-instance database, then DBCA adds information about the new database in the Oracle Net configuration, as follows:

1. DBCA adds the `SID_DESC` parameter for the database to the default listener in the default `listener.ora` file. This `SID_DESC` parameter consists of the database `SID` name.

2. DBCA adds the net service name entry for the database to the `tnsnames.ora` file in the database's Oracle home only. This entry consists of the `SERVICE_NAME` parameter.

After DBCA configures the Oracle Net information, Oracle Fail Safe displays the new single-instance database in the Oracle Fail Safe Manager tree view (under Standalone Resources for the cluster node on which the database was created).

If there are multiple Oracle homes on the cluster node where the database is created, then run the `Verify Standalone Database` command in Oracle Fail Safe Manager on the new database. Oracle Fail Safe checks the t`nsnames.ora` files in all Oracle homes. When it detects that a `tnsnames.ora` file does not contain the net service name entry for the database, it asks if you want to update that file. If you select Yes, then Oracle Fail Safe adds a net service name entry for the new database.

If the default domain name values (for example, values of `names.default_domain` parameters in the `sqlnet.ora` files) are different across Oracle homes, then the net service name entry is not accessible from some Oracle homes. To resolve this problem, edit the `tnsnames.ora` file in each Oracle home and append the default domain name of the respective Oracle home to the net service name entry.

### 7.2.2 Listener Must Use IP Address, Not Host Name

If the system host name is used in the definition of a listener, then this listener listens on all IP addresses on that node, not just the IP address associated with the host name. This causes conflicts later when you add a database to a group and listeners configured with Oracle Fail Safe are defined to listen on a virtual address.

To avoid this problem, the listener must use the node IP address for its host entry instead of the host name. When you add a single-instance database to a group, if Oracle Fail Safe finds a listener using a host entry, then you are asked if you want Oracle Fail Safe to modify this entry to use an IP address. If you do not, then the Add Resource to Group operation does not continue.

The following is an example of an invalid entry in an Oracle Fail Safe environment:

        LISTENER =

            ....

            (ADDRESS=

                (PROTOCOL=TCP)

                (HOST=NTCLU-152)

                (PORT=1521)

           )

The following is an example of a valid entry in an Oracle Fail Safe environment:

          LISTENER =

            ....

            (ADDRESS=

                (PROTOCOL=TCP)

                (HOST=138.2.26.152)

                (PORT=1521)

           )

### 7.2.3 SID List Entries and Upgrades to Oracle Database Software

When you upgrade Oracle database software, you must also upgrade the listener. To maintain your entries in the listener `SID` list from an earlier version, move them to the version of the listener to which you are upgrading, as follows:

1. Locate the `listener.ora` files that correspond to the database software release from which you will be upgrading.

2. Copy the `SID_DESC` entries from the `SID` list of the listener you are upgrading from and add them to the `SID` list of the listener that corresponds to the Oracle database software release to which you are upgrading. For example, the updated SID list may appear similar to the following:

       SID_LIST_LISTENER =

         (SID_LIST =

           (SID_DESC =

             (SID_NAME = PLSExtProc)

             (ORACLE_HOME= c:\oracle)

             (PROGRAM = extproc)

           )

           (SID_DESC=

             (SID_NAME=ORCL)

           )

           (SID_DESC=

             (SID_NAME=OFS2)

           )

         )

3. Stop the listener of the database from which you are upgrading and change the startup state of the listener to manual.

4. Start the listener of the database to which you have upgraded.

   If you do not use the listener that corresponds to the release of the database software you are using, then you will run into problems when you perform the following Oracle Fail Safe operations:

   - Add database resource to group

   - Verify group

   - Remove database resource from group

### 7.2.4 Configuring Oracle Net on Nodes with Multiple Listeners

When Oracle Fail Safe searches for a standalone database listener, it looks at the listeners defined in all Oracle homes. When multiple Oracle servers are installed (in one or more Oracle homes), it is possible to have more than one listener. Even when there are multiple listeners, Oracle Fail Safe can find the standalone database listener.

After you install additional Oracle homes on your system, you must decide how many listeners to use and which listeners to use on the system. Then:

1. Remove the definitions of listeners that you do not use from the `listener.ora` files. This ensures that Oracle Fail Safe will not find unnecessary listeners.

2. Ensure that no two listeners listen on the same address of the `SID`. (An Oracle listener will not start if another active listener is already listening on the same address or `SID`.)

3. Start the listeners that you want to use. Ensure that these listeners are set to start automatically in the Windows Services startup list.

The state of a listener defined in a `listener.ora` file affects the result when Oracle Fail Safe searches for the listener of a standalone database. The following list shows the order in which Oracle Fail Safe looks for the listeners:

1. Listener is started.

2. Listener is stopped.

3. Listener has no Windows service defined.

For example, suppose you have a database with two listeners in two different Oracle homes, and assume that the listener in Home 1 is stopped and the listener in Home 2 is started. When Oracle Fail Safe looks through the two homes on the system, it finds the listener in Home 2 because in the first pass, Oracle Fail Safe looks only for listeners that are started. As soon as a started listener is found, Oracle Fail Safe stops looking. If a started listener is not found, Oracle Fail Safe looks through the list for stopped listeners, and so on.

Note:

Ensure that the listeners of standalone single-instance databases are in the state (stopped or started) that you intend before you run any Oracle Fail Safe operations.

### 7.2.5 Shared Server Configuration and a Standalone Database

When a database is configured for high availability, Oracle Fail Safe makes adjustments to the default listener. This affects the Oracle Net configuration for all databases, including standalone databases. Therefore, all standalone databases in an Oracle Fail Safe environment require some adjustments to the Oracle Net configuration if any database in the cluster has been made highly available.

If the shared server configuration for standalone single-instance databases relies on the default listener, then no listener parameters are specified in the database parameter file. (The default listener is a listener that listens on the host name of the node, the default port number, and TCP protocol.) In this case, the configuration will no longer work after Oracle Fail Safe has changed the default listener to use an IP address in place of the host name.

Resolve this problem by doing the following:

1. Add the `LOCAL_LISTENER` parameter to the database initialization parameter file. The `LOCAL_LISTENER` parameter specifies a network name that resolves to an address of the Oracle Net default listener.

   Locate the database initialization parameter file of the database and add the `LOCAL_LISTENER` parameter to the file.

       LOCAL_LISTENER = network-name

2. Determine the address of the Oracle Net default listener.

   Find the definition of the default listener in the `listener.ora` file of the database home. In the definition, identify the first address that uses the TCP protocol.

   For example, assume that the default listener is defined as follows:

       LISTENER =

         (DESCRIPTION_LIST=

           (DESCRIPTION=

             (ADDRESS_LIST=

               (ADDRESS=

                 (PROTOCOL=TCP)

                 (HOST=124.7.56.1)

                 (PORT=1521)

               )

             )

           )

         )

   Then the first address is:

       (ADDRESS_LIST=

               (ADDRESS=

                 (PROTOCOL=TCP)

                 (HOST=124.7.56.1)

                 (PORT=1521)

3. Create a `network-name` entry in the `tnsnames.ora` file.

   In the `tnsnames.ora` file, create an entry for the `network-name` using the address found in Step 2.

   In this example, the entry is as follows:

       network-name= (ADDRESS=

                          (PROTOCOL=TCP)

                          (HOST=124.7.56.1)

                          (PORT=1521)

                          )

   This change will take effect when the database is restarted.

## 7.3 Adding Single-Instance Oracle Databases to a Group

To configure a single-instance Oracle database for high availability, you add it to a group that currently contains at least one virtual address. Oracle Fail Safe adds all other resources that the single-instance Oracle database requires. Typically, the group includes the following resources:

- One or more virtual addresses, each of which consists of an IP address and network name

- The Oracle database instance

- All disks used by the Oracle database

- An Oracle Net network listener that listens on the virtual address (or addresses) of the group for connection requests to the databases in the group

- An Oracle Management Agent configured to use one of the group's virtual addresses (if Oracle Enterprise Manager will be used to manage the database)

### 7.3.1 Before You Get Started

Before you add a single-instance database to a group, note the following:

- All files used by the single-instance database must be on the shared cluster disks, with the exception of the database initialization parameter file, which can be placed on a private disk or on a shared cluster disk. See Section 7.3.3.3 for more information about the placement of the initialization parameter file.

- Resources must belong to one group only. Therefore, if two single-instance databases share the same disk drives, then both databases must be in the same group.

- In a failover, the data in a temporary table does not fail over. Operations that involve the use of temporary tables and tablespaces (such as sorts and hash joins) re-create any needed temporary objects when restarted on the failover node. However, you must review applications that rely on the existence of specific data in temporary tables to be sure they function as expected.

  Refer to the Temporary Tables discussion in the Oracle Database Concepts manual for more information about temporary tables.

- The group must contain at least one virtual address.

- Database service names must be unique across the cluster.

  To ensure that the properties of standalone and cluster resources are discovered and displayed correctly by Oracle Fail Safe Manager and Oracle Enterprise Manager, each resource must have a unique name within the cluster. It may be necessary to specify names that are different from default values or to change the default names of resources.

### 7.3.2 Configuration Steps

Table 7-1 pro vides a quick reference to the tasks needed to configure a single-instance Oracle database for high availability. For detailed instructions about a particular task, see the online help and tutorial. From the Oracle Fail Safe Manager menu bar, select Help, then select Search for Help on or Help, and then select Tutorial for step-by-step instructions.

Table 7-1 Steps for Configuring Databases

Step | Procedure | Oracle Fail Safe Manager Procedure
--- | --- | ---
1 | Ensure that the Oracle database software is installed on a private disk on each node in the cluster that you intend to be a possible owner for the Oracle database. | See the Oracle database documentation for installation information.
2 | Create a group and add one or more virtual addresses. | On the Groups menu, select Create to open the Create Group Wizard. The wizard helps you to set up failover and failback policies and automatically opens the Add Resource to Group Wizard to let you add a virtual address to the group. To add additional virtual addresses to the group select Resources, then select Add to Group.
3 | Create a sample database, if desired. | On the Resources menu, select Create Sample Database to create a sample standalone single-instance database on which you can try out the features of Oracle Fail Safe before using them on a production database. Do not use the sample database for production work.
4 | Verify the standalone database. | On the Troubleshooting menu, select Verify Standalone Database to validate the database and Oracle Net configuration for the database. This command ensures that Oracle Fail Safe can attach to the database, and confirms that the standalone database is located on a cluster disk.
5 | Add the Oracle database to the group. | On the Resources menu, select Add to Group, and then select Oracle Database to open the Add Resource to Group Wizard. The wizard helps you configure the single-instance Oracle database for high availability.
6 | Modify the tnsnames.ora file on each client system. | Configure clients (modify the `tnsnames.ora` file on each client system using a network configuration tool) to recognize the virtual server. See Section 7.4 for more information.

### 7.3.3 Configuration Data for Oracle Databases

Oracle Fail Safe Manager provides the Add Resource to Group Wizard to assist you in configuring a single-instance Oracle database for high availability. The pages presented in the wizard vary, depending on the number of virtual addresses currently in the group, and the number of nodes in the cluster.

Typically, each group has one virtual address, but more complex configurations may have more than one virtual address. To perform a typical configuration using the Add Resource to Group Wizard, you need the following data:

- Identity of the single-instance Oracle database, including the service name, instance name, database name, and specification for the database initialization parameter file

- The database `SYSDBA` (usually, `SYS`) account and password

If you add a database to a group that currently contains more than one virtual address, then you are also asked to specify the virtual address or addresses that you want your clients to use to access the database.

The following sections describe in detail the configuration requirements for single-instance databases.

#### 7.3.3.1 Choose Nodes

If you are addi ng a database to a group and the cluster consists of more than two nodes, then you are asked to specify the nodes, which must be possible owners for the database by specifying a list of selected nodes, as shown in Figure 7-1. To specify that a particular node must not be a possible owner for the database, select the node from the Selected Nodes list and click the left arrow.

Section 2.6.7 describes in detail the concept of the possible owner nodes list.

Figure 7-1 Choose Nodes Wizard Page When All Nodes Are Available

Description of "Figure 7-1 Choose Nodes Wizard Page When All Nodes Are Available"

If you are adding a single-instance database to a group and the cluster consists of two or more nodes, but one or more nodes are unavailable, then you are also asked to specify which nodes must be possible owners for the database. In this case, the wizard page displays which nodes are unavailable and why, as shown in Figure 7-2.

Figure 7-2 Choose Nodes Wizard Page When Any Node Is Unavailable

Description of "Figure 7-2 Choose Nodes Wizard Page When Any Node Is Unavailable"

#### 7.3.3.2 Virtual Address

If the group to which you are adding a single-instance database contains more than one virtual address, then the Add Resource to Group Wizard asks you which of the virtual addresses in the group you want clients to use when they access the database or databases in the group, as shown in Figure 7-3. This page is not displayed if the group to which you are adding a database contains only one virtual address.

Figure 7-3 Database Virtual Address Wizard Page

Description of "Figure 7-3 Database Virtual Address Wizard Page"

Oracle Fail Safe includes support for multiple virtual addresses in a group. All databases in a group must use the same virtual addresses, and the virtual addresses must be added to the group before you add the databases to the group. The sequence for building a group is as follows:

1. Create a group.

2. Add one or more virtual addresses to the group.

3. Add one or more single-instance databases to the group.

For example, if a group contains a database that is using two virtual addresses and you add a second database to the group, then the second database must use the same virtual addresses as the first database that was configured into the group. Oracle Fail Safe Manager checks to ensure that the same virtual addresses are used for all single-instance databases that you add to a group.

See Section 4.7 for information about configuring a resource in a group with multiple virtual addresses.

#### 7.3.3.3 Database Identity

The Add Resource to Group Wizard requests database identity information to uniquely identify the single-instance database that is being configured for high availability, as shown in Figure 7-4.

Figure 7-4 Database Identity Wizard Page

Description of "Figure 7-4 Database Identity Wizard Page"

Oracle Fail Safe uses this data to configure the database into the cluster (for example, to update the `tnsnames.ora` file). It also passes the data that you supply to MSCS, where it is registered for use when the database is brought online, taken offline, or when Is Alive polling is performed. Oracle Fail Safe requests the following information:

- Servic e name

  This is the net service name. This is the name that will appear in the Oracle Fail Safe Manager tree view and the MSCS tree view. This is the name that client applications specify in a connection request.

  If you do not specify a domain name in the Oracle Net service name, then Oracle Fail Safe will choose a domain name to append to the net service name, as described in Section 7.4.3.1.

- Insta nce name

  This is the name of the database instance, also referred to as a `SID`.

- Database name

  This is the `db_name` parameter used to identify the database in the initialization parameter file. It is the name that was used when the database was created (for example, in the `SQL CREATE DATABASE` statement).

- Name and locat ion of the initialization parameter file

  When an Oracle database starts up, it uses the initialization parameter file to specify the name of the database, the amount of memory to allocate, the names of control files, and various limits and other system parameters.

  In most cases, you place the parameter file on a cluster disk so that it can be accessed regardless of which cluster node is currently hosting the database. However, you can place a copy of the initialization parameter file on each node's private disk, if you ensure that the file exists at the same location on all cluster nodes that are configured to run a database. You may decide to place the parameter file on each node's private disk to set different parameters for the database, depending on which node is hosting it. This can be useful if some nodes have less memory or processing capabilities than others. See Section 7.3.3.3.2 for special considerations for using this method on an Oracle9i database or a later database that was created with Database Configuration Assistant.

  Note:

  If needed, you can move the initialization parameter file after a database has been configured for high availability. See the Oracle Fail Safe Manager Help for information about how this is performed.

##### 7.3.3.3.1 Parameter File and Oracle9i and Later Databases That Use an SPFILE

Oracle Fa il Safe requires that a text initialization parameter file (`PFILE`) be specified in the Parameter File field. To use a binary server parameter file (`SPFILE`) with Oracle9i and later databases configured for high availability, specify the location of the `SPFILE` from within the `PFILE` using the `SPFILE=``SPFILE-location` parameter. For example, the contents of the PFILE may include the following parameters:

    SPFILE=I:\Oracle_Home\admin\oradb\pfile\spfileoradb.ora
    REMOTE_LOGIN_PASSWORDFILE=none

(If you specify an `SPFILE` in the `PFILE` that Oracle Fail Safe uses, then be careful if and when you export the `SPFILE`. If you use a `CREATE PFILE FROM SPFILE` command without including file specifications, then you will overwrite the `PFILE` that Oracle Fail Safe is using. Therefore, be sure to specify a unique file name for the `PFILE` to which the `SPFILE` is exported. See Oracle Database Administrator's Guide for detailed information about server parameter files.)

##### 7.3.3.3.2 Parameter File and Oracle9i and Later Databases Created with DBCA

When you use Database Configuration Assistant to create an Oracle9i or a later database, a text initialization parameter file (`init.ora`) is created in the `ORACLE_HIOME``\database` directory. This file contains the `IFILE` parameter. The `IFILE` parameter value is the file specification of another text initialization parameter file, which contains the initialization parameters of the database.

The file specification of the initialization parameter file `IFILE` parameter is stored in the Windows registry. By default, Oracle Fail Safe displays the file specification of the initialization parameter file that contains the `IFILE` parameter (except for databases created with the `Create Sample Database` command) in the Parameter File field. Databases created with the Create Sample Database command will display the initialization parameter file that the `IFILE` parameter specifies in the Parameter File field.

Oracle recommends that in a cluster environment, you enter the file that the `IFILE` parameter specifies in the Parameter File field. This provides the most direct route to the database initialization parameters. In addition, if you choose not to do this and you also choose to keep the parameter file on a private disk, then you must remember to copy both the initialization parameter file containing the `IFILE` parameter and the file that the `IFILE` parameter specifies to the private disk of each cluster node.

#### 7.3.3.4 Database Authentication

The Authentication page is presented if the account under which Oracle Services for MSCS was installed is not in one of the following Win dows operating system groups: the `ORA_DBA` group or the `ORA_``SID``_DBA` group associated with the database. When the account under which Oracle Services for MSCS was installed is in the `ORA_DBA` group or the `ORA_``SID``_DBA` group, it can use operating system authentication to access the database. If the account is not a member of the `ORA_DBA` group or the `ORA_``SID``_DBA` group, then it must use the `SYS` account to access the database.

This page lets you specify whether Oracle Services for MSCS should use operating system authentication or the `SYS` account to access the database and its instances, as shown in Figure 7-5.

Note:

The Database Authentication page is not presented if the account under which Oracle Services for MSCS was installed is already a member of a group that will let it access the database using operating system authentication.

To specify operating system authentication, select Use operating system authentication. To specify the database `SYS` account, select Use SYS account, then select SYS, and then enter and confirm the password for the account.

Figure 7-5 Database Authentication Wizard Page

Description of "Figure 7-5 Database Authentication Wizard Page"

If you select the "Use operating system authentication" option, then Oracle Services for MSCS opens the Confirm Add to DBA Group window, as shown in Figure 7-6.

The text in Figure 7-6 indicates that Oracle Services for MSCS was installed under the `nedcdomain\cluadmin` account. If you click Yes, then the `nedcdomain\cluadmin` account will be added to the Windows operating system group `ORA_OFS1_DBA`.

Figure 7-6 Confirm Add to DBA Group Window

Description of "Figure 7-6 Confirm Add to DBA Group Window"

#### 7.3.3.5 Database Password

If Oracle Services for MSCS detects that the standalone database has a password file associated with it, then the Add Resource to Group Database Wizard asks if you want Oracle Services for MSCS to create the password file on all nodes that will be possible owner nodes for the fail-safe database, as shown in Figure 7-7.

Oracle recommends that you select the "Yes, create the password file" option. A password file is often required when you perform remote operations. For example, Recovery Manager (RMAN) requires a password file when connecting to the target database over a nonsecure Oracle Net connection.

If you select the "No, do not create the password file" option, then all users must access the database using operating system authentication, and users will not be able to perform remote database administration operations.

Note:

If Oracle Services for MSCS does not detect password files for the database that you are adding to a group, then it does not present the Database Password page.

Figure 7-7 Database Password Wizard Page

Description of "Figure 7-7 Database Password Wizard Page"

Oracle Services for MSCS makes the following adjustments to the database initialization parameter file (if needed), depending on whether or not you choose to have Oracle Services for MSCS create the password file on all cluster nodes that are possible owner nodes for the database:

- Yes, create the password file

  Sets the `REMOTE_LOGIN_PASSWORDFILE` parameter to `EXCLUSIVE`.

- No, do not create the password file

  Sets the `REMOTE_LOGIN_PASSWORDFILE` parameter to `NONE`.

  Note:

  Oracle Services for MSCS does not support setting the Windows registry DBA_AUTHORIZATION parameter to the value of BYPASS.

If you want to change the password for the `SYS` account after the database has been added to a group, then you must also update the password through Oracle Fail Safe Manager. See Section 7.5.2 for information about how to update the password for this account after the database has been added to a group.

## 7.4 Oracle Net Listener Resource Creation and Configuration

When you add a single-instance database to a group, Oracle Fail Safe creates and configures the Oracle Ne t listener resource and the database resource in the group. When it brings the database online, Oracle Fail Safe first ensures that the listener resource is online. If Oracle Fail Safe is not able to connect to the database through the listener during Is Alive polling of the database resource, then it uses the bequeath protocol adapter to connect to the database. Oracle fail Safe also logs an event to notify users of the failure. If you see this event, then check the listener resource. The failure of the listener resource does not affect the existing connections to the database, but prevent new users from connecting to the database. The listener resource has its own restart policy, so it will be restarted automatically by the cluster in the event of failure.

Oracle Fail Safe creates a dependency between the database and the IP address associated with the listener but not on the listener itself. This dependency is created to avoid a situation in which clients would stop responding when an IP address was taken offline before the database.

### 7.4.1 Using Shared Sockets in Dedicated Server Mode

You can se t the `USE_SHARED_SOCKET` parameter to true to enable the use of shared sockets. If this parameter is set to true, then the network listener passes the socket descriptor for client connections to the database thread. As a result, the client does not need to establish a new connection to the database thread and data base connection time improves. Also, all database connections share the port number used by the network listener, which can be useful if you are setting up t hird-party proxy servers.

This parameter only works in dedicated server mode in a TCP/IP environment.

### 7.4.2 Client Connections to Highly Available Single-Instance Databases

Network objects (including databases) are identified by a network address. For a connection between a client and a database to be made, the network address in the `tnsnames.ora` file on the client and the network address in the `listener.ora` file on the server must match. In other words, a client uses a network address to send a connection request to a particular network object location, and the recipient listens for requests on this address and grants a connection based on its address information matching its client information.

When you add a single-instance database to a group, Oracle Fail Safe creates a listener for the group in the same Oracle home where the database resides. When Oracle Fail Safe configures the virtual address information, it updates the `tnsnames.ora` files in all Oracle homes on cluster nodes that are possible owners for the database, and on the client system from which you are running Oracle Fail Safe Manager. This enables Oracle Fail Safe to access the database instance using the updated configuration.

Section 7.4.3 describes how Oracle Fail Safe creates an entry in the `listener.ora` file and updates the `tnsnames.ora` file after you add a database to a group so that clients can connect to the database, regardless of which cluster node is hosting the database.

Note:

Oracle Fail Safe does not support the use of the `TNS_ADMIN` Windows environment variable or registry parameter. Oracle Fail Safe retrieves and updates Oracle Net files in the `Oracle_Home``\network\admin` directory; it ignores the `TNS_ADMIN` Windows environment variable or registry parameter if either is specified.

### 7.4.3 Updated Oracle Net Configuration After Adding a Database to a Group

When you add a single-instance database to a group, Oracle Fail Safe changes the Oracle Net configuration for the database in the `tnsnames.ora` file, the `listener.ora` file, and the `sqlnet.ora` file as described in the following sections.

#### 7.4.3.1 Updates That Oracle Fail Safe Makes to the tnsnames.ora File

When you add a single-instance database to a group, Oracle Fail Safe updates the net service name entry in the `tnsnames.ora` file for the database to use the virtual addresses of the group. If there are multiple Oracle homes on the node, then all `tnsnames.ora` files are updated. In addition:

- Oracle Fail Safe may make adjustments to the net service name, and the `SERVICE_NAME` parameter or the `SID` parameter.

  When you create a sample single-instance database or add a single-instance database to a group, if you do not specify a domain name in the Oracle Net service name, then Oracle Fail Safe chooses a domain name to append to the net service name as follows:

  - Oracle Fail Safe looks for the default domain name in the Oracle home of the latest database version on the node. If found, this default domain name is appended to the net service name. For example, assuming Oracle Database 10g is the latest database version on the node, if you specify `MyDB` as the Oracle Net service name, and the default domain name in the Oracle Database 10g home is `us.oracle.com`, then the net service name will become `MyDB.us.oracle.com`.

  - If there is no default domain name in the Oracle home of the latest database version on the node, then Oracle Fail Safe appends nothing to the net service name. For example, if you specify `MyDB`, then the net service name will also be `MyDB`.

  In either case, once the net service name is decided, Oracle Fail Safe checks the `tnsnames.ora` file for an existing entry with the same name and updates the `tnsnames.ora` file, as follows:

  - If an entry for the net service name exists, then Oracle Fail Safe updates the entry so that it connects to the virtual host. Oracle Fail Safe does not change the `CONNECT_DATA` parameter, including the `SERVICE_NAME`.

  - If an entry does not exist, then Oracle Fail Safe writes a new entry to the `tnsnames.ora` file. In this case, the `SID` is used in the `CONNECT_DATA` parameter, even if the target is an Oracle8i or later database. (Users can still connect to an Oracle8i or later database using a net service name that refers to the `SID`, rather than the service name.)

- If you define an archive log destination as a service name, as shown in the following example, then Oracle Fail Safe will not automatically update the `tnsnames.ora` file on all cluster nodes. You must manually edit or add the service name entry to the `tnsnames.ora` file on each cluster node.

      log_archive_dest_2='SERVICE=standby OPTIONAL REOPEN=120'

- On server nodes, addresses that use virtual host names configured only for inte rnal cluster communications will be placed at the top of the address list. Therefore, applications running on the server nodes, including the database resource monitor, will attempt to use addresses that use the private network interconnect among the cluster nodes before using addresses that use the public interconnect for connections to the database resource.

  On client nodes, addresses that use virtual host names configured only for internal cluster communications will not be included in the address list.

  Note:

  Oracle Fail Safe updates the `tnsnames.ora` files on all cluster nodes (that are possible owners for the single-instance database) and on the client node where you are running Oracle Fail Safe Manager. If you need to enable remote clients (that are not running Oracle Fail Safe) to process work against a single-instance Oracle database through a cluster node, you must edit the `tnsnames.ora` files to update the host name with the virtual address information. Edit each client's local `tnsnames.ora` file using a network configuration tool.

#### 7.4.3.2 Updates That Oracle Fail Safe Makes to the listener.ora File

When you add a single-instance database to a group, Oracle Fail Safe makes the following changes to the `listener.ora` file:

1. Removes the `SID_DESC` parameter from the standalone database listener

2. Creates a new Oracle Fail Safe listener that is configured to listen on the virtual address associated with the single-instance database

3. Adds the `SID_DESC` parameter to the new Oracle Fail Safe listener

4. Stops and restarts the standalone database listener to accept the changes that have been made

5. Starts the new Oracle Fail Safe listener

#### 7.4.3.3 Updates That Oracle Fail Safe Makes to the sqlnet.ora File

When you add a single-instance database to a group, if operating system authentication has been chosen for the database, then Oracle Fail Safe adds the `SQLNET.AUTHENTICATION_SERVICES=(NTS)` parameter to the `sqlnet.ora` file (assuming the parameter is not already set).

### 7.4.4 Using External Procedures with Databases Configured for High Availability

Oracle Fail Safe configures the address of an external procedure in the Oracle Net listener definition for a group (the `listener.ora` file). As the first database is added to a group, Oracle Fail Safe determines whether or not external procedures are configured in the original Oracle Net listener serving the database. If they are configured, then Oracle Fail Safe creates both an IPC listener address and a SID descriptor (`SID_DESC`) in the `listener.ora` file for the group.

Oracle Fail Safe creates the key of the IPC address by concatenating the prefix `EXTPROC` to the network name of the first virtual address in the group. Oracle Fail Safe uses the alphabetic order of the virtual address network names in the group to determine which network name is first. Therefore, if the network name of the first virtual address is `ntclu45`, then the key value is `EXTPROCntclu45` and the IPC address entry will be as follows:

    (ADDRESS=

       (PROTOCOL=IPC)

       (KEY=EXTPROCntclu45)

    )

Oracle Fail Safe copies the `SID` descriptor information from the original Oracle Net listener for the database to the Oracle Net listener for the group. For example, if the original Oracle Net listener for the database has the following `SID` descriptor, then the Oracle Net listener for the group will have the same descriptor:

        (SID_DESC=

          (SID_NAME=PLSExtProc)

          (ORACLE_HOME = C:\Oracle\Ora)

          (PROGRAM=extproc)

        )

When a PL/SQL or SQL application calls an external procedure, the application specifies the `EXTPROC_CONNECTION_DATA` net service name entry in the `tnsnames.ora` file. This entry contains the information needed by the listener to start a process for the external procedure. The IPC address of the Oracle Net listener in a group is added to the `EXTPROC_CONNECTION_DATA` net service name entry in all `tnsnames.ora` files on the cluster.

### 7.4.5 Support for Databases Using Shared Servers

The following sections describe how Oracle Fail Safe supports single-instance databases that u se a shared server configuration.

Note:

Whe n you set up a database to use a shared servers configuration, you must ensure that Oracle Fail Safe can continue to use a dedicated server connection for its internal operations. You do this by specifying the (`SERVER=DEDICATED`) parameter in the connect data portion of the net service name entry for the database in the `tnsnames.ora` file on each cluster server node. (By default, if shared servers are used and no `SERVER` parameter is specified, then the listener establishes a connection using shared servers.)

#### 7.4.5.1 Shared Servers for Oracle8i or Later Databases

To use a sh ared server configuration in an environment with Oracle8i or later database and Oracle Fail Safe, you may be required to make modifications to the database parameter file.

You can specify listener information in either the `LOCAL_LISTENER` or the `DISPATCHERS` parameter for a shared server configuration.

If the shared server configuration uses the `LOCAL_LISTENER` parameter to specify full listener information (full listener information specifies both host and port values), then Oracle Fail Safe automatically updates the database parameter file for the shared server configuration during the Add Resource to Group operation.

The single-instance database will run in shared server mode after you add it to a group. You do not need to make any further changes to the database parameter file.

The following example shows a shared server configuration that will be updated automatically by Oracle Fail Safe:

    dispatchers = "(PROTOCOL=TCP)(DISPATCHERS=1)"

    local_listener = "(ADDRESS=(PROTOCOL=TCP)(HOST=124.7.56.1)(PORT=1521))"

After you add the database to a group, Oracle Fail Safe updates the `LOCAL_LISTENER` parameter to use the listener information for the group.

However, if the shared servers configuration uses the `DISPATCHERS` parameter to specify full listener information, then you must remove the host and port values from the `DISPATCHERS` parameter. Oracle Fail Safe always writes the `LOCAL_LISTENER` parameter to the database parameter file.

When you remove a database from a group using Oracle Fail Safe Manager, it deletes the `LOCAL_LISTENER` parameter from the database initialization file. You must add the parameter back into the database initialization file by following the instructions in Section 7.2.5.

## 7.5 Security Requirements for Single-Instance Databases

To manage a single-instance Oracle database, use a database administrator account that has `SYSDBA` privileges. This lets you administer Oracle databases from a remote client.

When you create a single-instance sample database or add a single-instance database to a group, Oracle Fail Safe must use operating system authentication or the `SYS` user account to access the database. Use an authentication password file and set the initialization parameter, `REMOTE_LOGIN_PASSWORDFILE`, in the database initialization parameter file (`init` `database-name``.ora`) to either `SHARED` or `EXCLUSIVE` if users will access the database using the `SYS` account. Set the `REMOTE_LOGIN_PASSWORDFILE` to `NONE` if users will only access the database using operating system authentication.

Note:

Oracle Fail Safe does not support setting the Windows registry `DBA_AUTHORIZATION` parameter to the value of `BYPASS`.

Refer to Oracle Database Administrator's Guide for more information about database administrator authentication and the `REMOTE_LOGIN_PASSWORDFILE` parameter.

### 7.5.1 Synchronizing Password Files on Cluster Nodes

Database pas sword files are stored on private disks. Changes that you make to the password file on one cluster node are not automatically applied to the corresponding file on the other cluster nodes.

Therefore, if you add an account to the password file on one cluster node, then you must add that account to the password file on the other cluster nodes that are configured to run the database instance. If there are accounts in addition to `SYS` stored in a password file, then you must grant `SYSOPER` and `SYSDBA` privileges for the additional accounts on the other cluster nodes for a single-instance fail-safe database.

If you add a single-instance database to a group with the Oracle Fail Safe Manager Add Resource to Group Wizard, then Oracle Services for MSCS creates a database instance on the other nodes that are configured to run the database and uses the default value for the maximum number of users in the password file. The password file on the node where the instance is created contains only the password for the `SYS` account that you supply in the Add Resource to Group Wizard.

On the other nodes configured to run the database instance, perform the following steps to synchronize the password files on the other cluster nodes:

1. If the number of accounts in the password file exceeds the default maximum, then create a new password file. Otherwise, skip to Step 2.

   To create a new password file, refer to instructions about creating password files in the Administrator's Guide for your Oracle database release.

2. Move the group containing the single-instance database to another node configured to run the database instance.

3. Grant privileges to accounts other than `SYS` on the node to which you move the database.

4. Repeat Step 2 and 3 for each node in the cluster configured to run the database.

   Now the local copies of the password file are identical on all nodes configured to run the database instance.

### 7.5.2 Changing the SYSDBA Account Password

If you want to change the `SYSDBA` (`SYS`) account password for one or more databases after those databases have been added to groups, then use Oracle Fail Safe Manager to make this change so that Oracle Services for MSCS will use the correct password to access the database when it performs operations such as Is Alive polling.

You can use the Update Database Password Wizard, or the Authentication tab in the fail-safe database property sheets to update the `SYSDBA` password, as follows:

- To change the `SYSDBA` password for several databases, Oracle recommends that you use the Update Database Password Wizard. Access the Update Database Password Wizard in Oracle Fail Safe Manager by choosing Resources from the menu bar, then Update Database Password.

- To change the `SYSDBA` password for a single database, Oracle recommends that you use the database Authentication tab. From the tree view, choose the fail-safe database for which you want to change the password, then select the Authentication tab.

If operating system authentication is enabled (without the use of a password file), then you cannot change the `SYSDBA` account information using Oracle Fail Safe Manager unless you first remove the database from the group, then add it to the group again with the Add Resource to Group Wizard. When you add the database to the group again, select Use SYS Account on the Database Authentication page of the wizard.

See the online help for the following additional information:

- Detailed instructions on using the Update Database Password Wizard and the Authentication property page.

- Information about using these tools when the `SYSDBA` password has already been changed with a tool other than Oracle Fail Safe Manager.

### 7.5.3 Upgrad ing a Fail-Safe Database with the Oracle Database Upgrade Assistant

This section describes how to use the Oracle Database Upgrade Assistant to upgrade a single-instance fail-safe database from one release to another or to move a single-instance Oracle database from one Oracle home to another.

For each single-instance database that you want to upgrade or move to a new home, perform the following steps:

1. Remove the single-instance database from the group. In the Oracle Fail Safe Manager tree view, select the database, then from the menu bar select Resources followed by Remove from Group.

2. Run the Oracle Database Upgrade Assistant from the Oracle home to which you are moving or upgrading your single-instance database.

3. Be prepared to provide the location of the database parameter file for the single-instance database you are upgrading. During a database upgrade, the database parameter file is converted. If the database parameter file is on a cluster disk, then your parameter file is appropriately located for Oracle Fail Safe to make the conversion. If the database parameter file is located on a private disk, then the Oracle Database Upgrade Assistant only converts the local copy. In this case, you must edit the copy on the other cluster nodes and make the appropriate changes.

4. The Oracle Database Upgrade Assistant also asks you to specify the location of the converted database files. Either leave the data files in their current location, or specify a cluster disk that is currently accessible by the local node. If you choose the latter, then ensure the cluster disk is not being used by another group.

5. When all databases in the group have been upgraded or moved to a new home with the Oracle Database Upgrade Assistant, use Oracle Fail Safe Manager to put the databases back into the group and then place the databases online, as follows:

   1. On the Resources menu, select Add to Group.

   2. Follow the steps through the Add Resource to Group Wizard.

All databases in the group being moved must be from the same Oracle home. If one database in a group is moved with the Oracle Database Upgrade Assistant to a new Oracle home, then all databases in the group must be moved to the new Oracle home.

## 7.6 Optimizations for Single-Instance Database Recovery

Oracle databases configured with Oracle Fail Safe for high availability ensure fast failover and fast recovery during both unplanned and planned outages (such as software upgrades and scheduled maintenance). You can take advantage of Oracle fast-start and disaster-recovery features, control time spent during database recovery, and ensure continuous monitoring of databases configured with Oracle Fail Safe for high availability.

Oracle Fail Safe and Oracle database technology optimize the time it takes to shut down a database on one node and complete instance recovery on another node for both planned and unplanned failovers. The Oracle database checkpoint algorithms optimize the time it takes to perform instance recovery for planned and unplanned failovers.

When you use Oracle Fail Safe Manager (or `FSCMD`) to carry out a planned failover, Oracle Services for MSCS checkpoints the single-instance Oracle database before it is shut down. The single-instance database is started on the other node in a restricted mode so that instance recovery can be completed quickly and the database made available to the database clients promptly. (If you use MSCS to carry out a planned failover, then it does not checkpoint the database before shutting it down.)

Note:

After you add a single-instance database to a group, use only Oracle Fail Safe Manager or the `FSCMD` command to place the Oracle database online and take the database offline. Otherwise, the database will not be checkpointed first. In addition, if you use a tool other than Oracle Fail Safe Manager, FSCMD, or MSCS to take a database offline, then Oracle Fail Safe will consider it a failed resource and will attempt to place it back online.

For unplanned failover, the instance recovery time is controlled by the database recovery processing. See the Oracle database documentation for details on fast-start recovery operations.

## 7.7 Performing Administrative Tasks on a Single-Instance Fail-Safe Database

You perform administrative tasks on a database configured for high availability as you would for any database, with one exception. You must use Oracle Fail Safe Manager or the `FSCMD` command-line interface (see Chapter 5) to take a database offline (and stop cluster monitoring of the database) during any operation that restricts access to the database or for which you want to temporarily disable the possibility of failover. This includes not only cold backup operations but also administrative operations that must be performed while users continue to access the database, or operations that could affect response times during the periodic Is Alive polling of the database by MSCS.

Use the following steps to perform administrative tasks on a database that is configured in a group with Oracle Fail Safe Manager:

1. Use Oracle Fail Safe Manager or the `FSCMD` command to take the database offline, shut down the database, and suspend monitoring of the database by the cluster. All users connected to the database will be disconnected.

2. Use a tool such as SQL*Plus to start up the database and to perform your administrative tasks. While the database is started, users can access the database.

3. Once you have completed the administrative tasks, use a tool such as SQL*Plus to shut down the database.

4. Use Oracle Fail Safe Manager or the `FSCMD` command to place the database online again. The cluster will resume monitoring the database.

Chapter 5 provides an example of a script in which `FSCMD` commands are used to perform a backup operation.

If, during an administrative task, you perform an operation that changes the configuration of the database (such as adding a new tablespace and associated data file), then you must run the `Verify Group` operation. Adding a new data file can introduce a new disk dependency in the group. When you run the `Verify Group` operation, it checks to ensure that the disk is a cluster disk and that it does not already belong to another group. If adding the new data file introduces a new disk dependency in the group, then the disk is added to the same group as the database and the information in the cluster registry is updated to ensure that the new disk will correctly fail over with the database.

## 7.8 Configuring Transparent Application Failover (TAF)

For standalone single-instance databases, transparent application failover (TAF) instructs Oracle Net to reestablish a failed connection to a database by connecting to a different listener. This lets the user continue work using the new connection as if the original connection had never failed. The transparent application failover feature does not work the same way for a single-instance Oracle Fail Safe database as it does for a standalone single-instance database. For a Oracle Fail Safe database, a transparent application failover instructs Oracle Net to reconnect to the same listener, which has moved to another cluster node due to a group failover.

For a standalone database, the term failover in the phrase "transparent application failover" refers to Oracle Net failing over a connection from one listener to another. For a Oracle Fail Safe database, the term failover in the phrase "transparent application failover" is a bit of a misnomer as the application does not fail over, but the listener to which it is connected fails over, and then a connection is reestablished.

These differences in implementation do not affect how you manage transparent application failover.

To take advantage of transparent application failover when connected to a database configured with Oracle Fail Safe, the client application s must:

- Connect through Oracle Net to an Oracle database

With transparent application failover, clients do not need to explicitly reconnect after a group fails over. The OCI connection handles reconnection and state recovery automatically for the client application. In fact, applications that are not actively updating the database at the time of a failure may not notice that failover is occurring.

Refer to the Oracle Net Services Administrator's Guide for complete information about transparent application failover.

Note:

The transparent application failover feature is supported for Oracle Database Enterprise Edition. For Oracle Database 10g Release 10.1.0.3 and later, the transparent application failover feature is also supported for Oracle Database 10g Standard Edition.

## 7.9 Handling Errors and Troubleshooting Problems with Databases

The following sections describe how to specify a script to handle errors if they occur when Oracle Fail Safe attempts to bring a highly available single-instance database online and how to troubleshoot specific problems that you may encounter with single-instance Oracle databases configured for high availability. For general information about troubleshooting Oracle databases, see the Oracle database documentation.

### 7.9.1 Handling Errors That Occur When Bringing a Database Online

You can specify a scr ipt to handle errors that may occur when Oracle Fail Safe is attempting to place a single-instance database online. Oracle Fail Safe uses the same script for all single-instance fail-safe databases on the cluster.

To specify an error handling script:

1. Create a script to handle the error or errors.

2. Name the script `FsDbError.bat`.

3. Ensure that the script returns `0` if it succeeds and any nonzero integer if it fails.

4. Place the script in the following directory on each cluster node that is a possible owner for a database resource and ensure that the file owner has local Administrator privileges on that cluster node:

       Oracle_Home\fs\fssvr\scripts

If Oracle Fail Safe cannot bring a single-instance database online, then it spawns a process to run the script, then it passes the error code, the database name, the database `SID`, the TNS service name, and the database parameter file specification to the script and executes the script, as follows:

    FsDbError.bat error-code database-name SID TNS service name parameter-file-spec

For example:

    FsDbError.bat ORA-01113 OracleDB OracleDB OracleDB.WORLD D:\Ora\admin\OracleDB\pfile\initOracleDB.ora

The process in which the script is running waits for the script to finish within the period of time specified as the Pending Timeout value for database resources. If the script does not finish within the pending timeout period, then the script is terminated.

Oracle Fail Safe logs an event to the Windows Event log to indicate whether the script succeeded, failed, or was terminated by Oracle Fail Safe. If the script failed, the error code is also written to the event log.

Regardless of whether the script succeeds or fails, Oracle Fail Safe continues to attempt to bring the single-instance database online as defined in the database restart and failover policies.

### 7.9.2 Troubleshooting Problems

In most cases, the first step in troubleshooting a problem is to run the `Verify Cluster`, `Verify Group`, or `Verify Standalone Database` command. These tools are described in general in Chapter 6.

When you run a `Verify Group` command on a group containing a single-instance database, Oracle Fail Safe performs the following tasks:

- Queries each database in the group to determine which disks it uses. Then, it validates that the disks are cluster disks and have been added to the group. If the disk validation fails (for example, because a disk has been added to the database since it was configured for high availability), then the `Verify Group` operation prompts you before fixing the problem.

- Detects disk drive changes and updates resource dependencies, if necessary.

- Validates that the network name pings the correct IP address.

- Ensures that the Oracle Net configurations are correct.

- Repairs any misconfigured resources in the group.

You can run the `Verify Group` operation at any time. However, you must run it when any of the following occurs:

- A group or resource in a group does not come online.

- Failover or failback does not perform as you expect.

- You add more disks to a single-instance database that is configured in a group.

- A new node is added to the cluster.

For example, assume that you add a new disk to a single-instance database, but you do not use Oracle Fail Safe Manager to update the cluster configuration. If a server node subsequently shuts down, failover will not occur correctly because the cluster software was never notified that there was a change in the configuration. To prevent this from happening, you must verify the group containing a single-instance database whenever you make a structural change to the database. When you verify the group, Oracle Fail Safe automatically detects changes and updates the cluster configuration for you. In the previous example, Oracle Fail Safe would add the new disk to the group for you.

If any problems are found during the group verification, then Oracle Fail Safe prompts you to fix them or returns an error message that further describes the problem.

### 7.9.3 Problems Adding a Database to a Group

To troubleshoot problems when adding a single-instance database to a group:

- Run the `Verify Standalone Database` operation (described in Section 6.1.3).

  Running the `Verify Standalone Database` operation verifies that the database is a valid working standalone database.

  For example, if you try to add a standalone database to a group and it fails during the Oracle Net configuration, then Oracle Fail Safe rolls back the clusterwide operation and the database remains as a standalone database. To fix this problem, perform the following steps:

  1. Run the `Verify Cluster` operation to ensure that the cluster network configuration is correct.

  2. Run the `Verify Standalone Database` operation to ensure that the network (Oracle Net) is working.

  3. Attempt to add the standalone database to a group.

  4. If the Add Database to Group operation fails, then check the Oracle Net rollback file as described in Section 7.9.8.4.

- Ensure that the following conditions are met:

  - The single-instance database files are located on shared cluster disks

    For each disk in the configuration, Oracle Fail Safe determines if the disk resides on a shared storage interconnect. If database files are on nonclustered disks, then you must move the database files so that they are located on a shared cluster disk.

  - The following information must be correctly specified in the Add Resource to Group Wizard:

    - User name and password used to access the database

    - Database parameter file

    - (Net) service name

    - Database name

    - Instance name

### 7.9.4 Problems Placing a Group Online

If there is a problem placing a group that contains a single-instance database online, then try the following:

- Verify the group.

  When you use the `Verify Group` command (from the Oracle Fail Safe Manager Troubleshooting menu), Oracle Fail Safe checks the group configuration and attempts to fix any problems that it finds. If the `Verify Group` command cannot fix the problem, then it returns an error message that should help you to resolve the problem manually.

  If the `Verify Group` command finds a problem, then it will prompt you on how to proceed.

- Check the Oracle Net listener log.

  Oracle Net logs an entry to the listener log file every time an error is encountered or a database is accessed through the listener. Check for errors in the log file that may help you to identify the problem.

  - On an Oracle8i or later system, the log files reside in the `Oracle_Home``\NETWORK\LOG` directory

- Check the net service name of the single-instance database.

  The Oracle Fail Safe database resource DLL accesses each database in a group at the Is Alive interval. (The Is Alive interval appears on the Failover property page for the database in Oracle Fail Safe Manager.) It uses the database connection information to access the database. If the database access information has changed, then Oracle Fail Safe will fail to access the database. Hence, MSCS will not consider the database resource to be alive.

- Check the Oracle Net configuration data.

  The `listener.ora` file on the server system and the `tnsnames.ora` file on both the client and server systems must contain valid virtual server addresses for the groups in your cluster.

- Bring each resource in the group online individually.

  If more than one single-instance database is in the group, then this will help you to identify the database causing the problem.

- Ensure that the single-instance database `Pending Timeout` value is sufficient.

  If a group containing a database fails to come online or frequently fails over, then check that the `Pending Timeout` value is set correctly. Failure to come online and frequent failovers occur if the `Pending Timeout` value for the database is set too low.

  Set the `Pending Timeout` value to specify the length of time you want the cluster software to allow for the database to be brought online (or taken offline) before considering the operation to have failed. Set the value high enough to prevent a cluster system from mistaking slow response time for unavailability, yet low enough to minimize the failover response time when a failure does occur.

  You can set the `Pending Timeout` value by modifying the database properties, as follows:

  1. In the Oracle Fail Safe Manager tree view, select the database name.

  2. Click the Policies tab.

  3. In the Pending Timeout box, modify the `Pending Timeout` value.

- If users use the `SYS` account to access the database, then ensure that the initialization parameter `REMOTE_LOGIN_PASSWORDFILE` in the database initialization parameter file (`init` `database-name``.ora`) is set to `SHARED` or `EXCLUSIVE`.

- If users access the database using operating system authentication only, then ensure that the initialization parameter `REMOTE_LOGIN_PASSWORDFILE` in the database initialization parameter file is set to `NONE`.

- If the account password that Oracle Fail Safe uses to access a database has changed, then update that change in Oracle Fail Safe Manager.

  If the password for the account through which Oracle Fail Safe accesses a database changes and you do not update the information through Oracle Fail Safe Manager, then the attempts at polling the database will fail. See Section 7.5.2 for information about how to update database password changes for Oracle Fail Safe.

### 7.9.5 Group Fails Over During Processing-Intensive Operations

S ometimes, processing-intensive operations (such as an Import operation) can cause Is Alive polling to fail and may result in an undesired group failover. In such cases, you can disable Is Alive polling for the database by issuing the `FSCMD DISABLEISALIVE` command. However, be aware that when you disable Is Alive polling, Oracle Fail Safe suspends monitoring the instance until Is Alive polling is reenabled. You reenable Is Alive polling with the `FSCMD ENABLEISALIVE` command.

Oracle recommends that you run these `FSCMD` commands from within a script so that you can ensure that Is Alive polling is reenabled when the processing-intensive operation completes.

For information about the `FSCMD` commands, see Chapter 5.

### 7.9.6 Database Authentication

If there is a problem when Oracle Fail Safe tries to bring a single-instance database online or offline, then the problem may be caused by the way you have set up database authentication. Try the following to solve the problem:

- If you selected "Use this account" on the Authentication page in the Add Resource to Group Wizard, then ensure that the `REMOTE_LOGIN_PASSWORDFILE` initialization parameter in the database initialization parameter file (`init` `database-name``.ora`) is set to `SHARED` or `EXCLUSIVE`.

  Section 7.5 describes how to correctly set up this parameter for database authentication.

- Ensure that Oracle Fail Safe has access to the databases in the group.

  For some operations that Oracle Fail Safe performs, such as a group verification and polling the database to ensure that it is online, Oracle Fail Safe must have access to the databases in a group. If the database account password has changed, then you must update it in Oracle Fail Safe Manager. Otherwise, Oracle Fail Safe cannot monitor the database using Is Alive polling. This situation will be logged to the Windows Event Viewer.

  Section 7.5.2 describes how to correctly update the database password.

### 7.9.7 Problems with Sample Databases

If you receive errors when you create or delete a sample database, then check the following:

- If the `Create Sample Database` command cannot open the `Create Sample Database` script files, then reinstall or repair your Oracle Fail Safe installation and try the `Create Sample Database` operation again.

- If the `Delete Sample Database` command fails, then you may have selected a database that is not a sample database. Ensure that the database you selected is a sample database and try the delete operation again.

  Oracle Fail Safe stores information about sample databases in the Windows registry under the `HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\FailSafe\SampleDB key`.

  If a sample database that you have deleted is listed in the Oracle Fail Safe Manager tree view, then ensure that the Windows registry entries for that database have been cleared from the registry.

### 7.9.8 Problems with Virtual Server Configurations

If you encounter problems when trying to establish a connection to either a standalone database or a database configured in a group, then you must check the Oracle Net configuration for the database.

Oracle Fail Safe provides the `Verify Group` and `Verify Standalone Database` operations to help you verify and repair the Oracle Net configuration. See Section 6.1.2 and Section 6.1.3 for details.

#### 7.9.8.1 Problems Configuring the Virtual Address

Oracle Fail Safe changes the `listener.ora` and `tnsnames.ora` files, and stops and starts listeners when configuring the virtual address information. The following list describes potential problems and the action you can take to correct each problem:

- `FS-10070 Oracle Net:` `name`

  This message code reports any problems parsing (reading or updating) the Oracle Net `listener.ora` and `tnsnames.ora` files:

  - If these files are no longer valid due to improper update or file damage, then Oracle Fail Safe cannot use these to configure virtual server information. You must retrieve a valid version of these files or re-create the files using Oracle Net Assistant.

  - If these files are valid, then check that the net service name, the database `SID`, and the network name of the group used in the operation are correct. Incorrect information may cause the virtual server configuration to fail. You must ensure that a database `SID` is not included in more than one listener. On systems with multiple Oracle homes, check all of the `listener.ora` files.

- `FS-10066 Failed to start Windows service` `name` `for the Oracle Net listener`

  Oracle Fail Safe starts a listener after changing the definition of a listener or creating the definition of a new listener.

  The most common reason for this error is that another listener is already listening for a database. There can be only one listener on the system listening for a particular address or database `SID`. For example, if `LISTENER_A` has the following definition, then no other listener on the system can listen for key `ORCL` using the IPC protocol, or port 1521 on host server_A using the TCP protocol, or `ORCL SID` name:

      LISTENER =

          (ADDRESS_LIST=

              (ADDRESS=

                        (PROTOCOL=IPC)

                       (KEY=ORCL)

              )

              (ADDRESS=

                  (PROTOCOL=TCP)

                  (Host=server_A)

                  (Port=1521)

              )

          )

      SID_LIST_LISTENER =

          (SID_LIST=

              (SID_DESC=

                  (SID_NAME=ORCL)

              )

          )

  Any other listeners that try to use the same address or database SID as `LISTENER_A` will fail to start.

  When you encounter this problem, Oracle Fail Safe saves the `listener.ora` and `tnsnames.ora` files that contain definitions of the updated listeners and net service names as rollback files. The file names of the rollback files are `filename``_rlb.ora`.

  Read the rollback files to find the definition of the listener and check it against the definition of all other listeners running on the system. There must be no overlapping addresses or database `SID` names among the listeners. Again, check for all `listener.ora` files on systems using multiple Oracle homes.

- Another common cause for failing to start a listener is the virtual address. The virtual address used by the listener must be active on the node where Oracle Fail Safe tries to start the listener.

See the Oracle Net documentation (including information about the log directory) for additional information about troubleshooting problems with the network configuration.

#### 7.9.8.2 Problems Creating Listeners

Oracle Fail Safe Manager uses the Listener Control Utility (`LSNRCTL`) to create new listeners, and captures the output in a file located in your Oracle home.

For example, if the Oracle home and network directory path is `C:\ORANT\NETWORK\ADMIN`, and the virtual address on which the listener listens is ntclu-155, then the listener output files will be written to the following directory and file:

    C:\ORANT\NETWORK\LOG\fslntclu-155.out

Each listener has its own output file that is named using the listener name and the `.out` extension. (In the example, the listener name is `fslntclu-155`.) If you experience difficulties when creating a new listener, then you can use the output file to help you diagnose the problem.

#### 7.9.8.3 Archived listener.ora or tnsnames.ora Files

Whenever Oracle Fail Safe makes changes in the `listener.ora` or `tnsnames.ora` files, the original version of the file is archived. If you need to reference an Oracle Net net service name definition or a listener definition as it was before Oracle Fail Safe changed the definition, then you can look at the archived versions of the configuration files.

Oracle Fail Safe keeps up to two archived versions of configuration files. The file name of the archived version has a format of `filename``_000.ora` and `filename``_001.ora`. Note that `filename``_000.ora` is the most recent file.

#### 7.9.8.4 Rollback Files

Whenever Oracle Fail Safe encounters an error during an operation after Oracle Net configuration files have been changed, the updated version of the file is saved as `filename``_rlb.ora`. Then, the original version of the file is restored.

The rollback version of the file may be useful for problem diagnosis.

### 7.9.9 Security Access and Authentication Problems

Access and authorization problems occur most frequently when you are attempting to perform operations through Oracle Enterprise Manager.

The following list addresses some typical authentication problems:

- From Oracle Enterprise Manager, the following error is returned when you are trying to connect to Oracle Fail Safe:

  `FS-10101: Failed to authenticate the user` `username` `on the cluster.`

  In Oracle Enterprise Manager, ensure that the User Credentials for the cluster are those of a Windows Administrator on all cluster nodes and that the user name and domain are specified correctly. (This does not apply to Oracle Enterprise Manager release 2.0 or 2.1; preferred credentials for clusters cannot be specified with Oracle Enterprise Manager 2.0 or 2.1.)

- Jobs that you submit to Oracle Fail Safe from Oracle Enterprise Manager fail with the error `Failed to authenticate user.`

  - Ensure that you have a Windows account that was set up with "Log on as batch user" access rights on each node in the cluster.

  - In Oracle Enterprise Manager, ensure that the User Credentials for each node in the cluster match the user name and password for your local account on each node in the cluster.

- When you try to perform an operation on or access a database that is configured in a group, the `ORA-01031: Insufficient privileges` error is returned.

  - When you create a sample database or add a database to a group, ensure that the authorization information for the database uses the `SYS` account with a password.

  - If you are attempting to access the database from Oracle Enterprise Manager, then ensure that the User Credentials for each database match the database `SYS` account.

### 7.9.10 Clients Cannot Access a Database

If users and client applications are unable to access a database that is configured in a group, then perform the following steps to fix the problem:

1. Update the `tnsnames.ora` file to use the virtual server for the group.

2. Run the `Verify Group` command to validate the network (Oracle Net) configuration.

## 7.10 Using Highly Available Databases with Oracle Data Guard

While Oracle Fail Safe provides high availability to single-instance Oracle databases, Oracle Data Guard provides disaster tolerance. For example, Oracle Fail Safe can ensure nearly continuous high availability for a given system, but does not protect against a disaster that incapacitates the site where that system resides. Similarly, while Oracle Data Guard provides excellent disaster recovery features, the time required to switch operations from the primary site to a physically separate site can range from several minutes to hours. By combining Oracle Fail Safe with Oracle Data Guard, your databases can be highly available and disaster tolerant.

If you have an Oracle Support contract, then you can find information about using Oracle Data Guard with Oracle Fail Safe, by logging into OracleMetaLink and searching for note 259902.1 at

`http://metalink.oracle.com`