8 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 Microsoft Windows Failover Clusters.

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 suffers 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:

8.1 Discovering Standalone Single-Instance Databases

Oracle Fail Safe Server discovers standalone single-instance databases (those that are not in a group) to display them in the Oracle Fail Safe Manager's Available Oracle Resources list. 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, select Oracle Resources in the left pane of the window.

8.2 Oracle Net Configuration for Standalone Single-Instance Databases

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

8.2.1 Updating the Oracle Net Configuration for a Database Created Using DBCA

If you use the Oracle 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 Available Oracle Resources list.

If there are multiple Oracle homes on the cluster node where the database is created, then select the Validate action in Oracle Fail Safe Manager on the new database. Oracle Fail Safe checks the tnsnames.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.

8.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=192.0.2.254)
            (PORT=1521)
       )

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

  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 while performing the following Oracle Fail Safe operations:

    • Add database resource to group

    • Verify group

    • Remove database resource from group

8.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 multiple listeners. 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 does not find unnecessary listeners.

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

  3. Start the listeners to be used. 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, 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 listener that is started is not found, Oracle Fail Safe looks through the list for listeners that are stopped, and so on.

Note:

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

8.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=192.0.2.1)
          (PORT=1521)
        )
      )
    )
  )

    Then the first address is:

    (ADDRESS_LIST=
        (ADDRESS=
          (PROTOCOL=TCP)
          (HOST=192.0.2.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=192.0.2.1)
                   (PORT=1521)
                   )

    This change will take effect when the database is restarted.

8.3 Adding Single-Instance Oracle Databases to a Group

To configure a single-instance Oracle Database for high availability, 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 a group's virtual addresses (if Oracle Enterprise Manager is used to manage the database)

8.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, except the database initialization parameter file, which can be placed on a private disk or on a shared cluster disk. See Section 8.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.

8.3.2 Configuration Steps

Table 8-1 provides 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. To access online help, select Help from the Actions menu on the right pane of Oracle Fail Safe Manager window. Or select Fail Safe Documentation in the middle pane of Oracle Fail Safe Manager, then select the HTML or PDF version of the Tutorial for step-by-step instructions.

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

In the Actions menu on the right pane of Microsoft Windows Failover Cluster Manager window, select Configure a Service or Application, the High Availability wizard opens. Select Other Server from the Select Service or Application page and click Next. Then in the Client Access Point page, set the network address and click Next. After this, choose a cluster disk from the list in the Select Storage page and click Next. Lastly, select a resource type and click Next to confirm your choices.

3

Create a sample database, if desired.

From Oracle Resources view, choose Create Sample Database action from the Actions menu in the right pane of the screen. You can use this sample database to 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.

Select the resource that you want to verify from the Available Oracle Resources list, then select Validate from the Actions menu of the Oracle Resources view. This operation performs validation checks to ensure that the standalone database is configured correctly on the node where it resides and to remove any references to the database that may exist on other cluster nodes.

5

Add the Oracle Database to the group.

Select the resource that you want to add from the Available Oracle Resources list, then select Add This Resource to a Group action from the Actions menu of the Oracle Resources view.This 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 8.4 for more information.

8.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 multiple 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 SYS password

If you add a database to a group that currently contains multiple 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.

8.3.3.1 Choosing Nodes

If you are adding 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 8-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 8-1 Add Resource to Group Wizard Page When All Nodes Are Available

Description of Figure 8-1 follows
Description of "Figure 8-1 Add Resource to Group 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, as shown in Figure 8-2.

Figure 8-2 Add Resource to Group Wizard Page When Any Node Is Unavailable

Description of Figure 8-2 follows
Description of "Figure 8-2 Add Resource to Group Wizard Page When Any Node Is Unavailable"

8.3.3.2 Selecting Virtual Address

If the group to which you are adding a single-instance database contains multiple 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 8-3. This page is not displayed if the group to which you are adding a database contains only one virtual address.

Figure 8-3 Add Resource to Group Virtual Host Wizard Page

Description of Figure 8-3 follows
Description of "Figure 8-3 Add Resource to Group Virtual Host 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.

8.3.3.3 Identifying Database Parameters

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

Figure 8-4 Database Parameters Wizard Page

Description of Figure 8-4 follows
Description of "Figure 8-4 Database Parameters 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 Microsoft Windows Failover Clusters, 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:

  • Service name

    This is the net service name. This is the name that appears in the Oracle Fail Safe Manager tree view and the Microsoft Windows Failover Cluster Manager 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 chooses a domain name to append to the net service name, as described in Section 8.4.3.1.

  • Instance 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 location of the initialization parameter file

    When an Oracle Database starts, 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, 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, a copy of the initialization parameter file can be placed 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 8.3.3.3.2 for special considerations for using this method on a database that was created with Oracle 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.
8.3.3.3.1 Parameter File and Databases That Use an SPFILE

Oracle Fail 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 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 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.)

8.3.3.3.2 Parameter File and Databases Created with DBCA

When you use Oracle Database Configuration Assistant to create a database, a text initialization parameter file (init.ora) is created in the ORACLE_HOME\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 displays 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.

8.3.3.4 Validating Database

The Authentication page is presented if the account under which Oracle Fail Safe was installed is not in one of the following Windows operating system groups: the ORA_DBA group or the ORA_SID_DBA group associated with the database. When the account under which Oracle Fail Safe 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 Fail Safe should use operating system authentication or the SYS account to access the database and its instances, as shown in Figure 8-5.

Note:

The Database Authentication page is not presented if the account under which Oracle Fail Safe was installed, is a member of a group that lets it access the database using operating system authentication.

Figure 8-5 Database Authentication Page

Description of Figure 8-5 follows
Description of "Figure 8-5 Database Authentication Page"

8.4 About 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 Net 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 prevents 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.

8.4.1 Using Shared Sockets in Dedicated Server Mode

You can set 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 database 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 third-party proxy servers.

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

8.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 run Oracle Fail Safe Manager. This enables Oracle Fail Safe to access the database instance using the updated configuration.

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

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

8.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 12c 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 12c home is example.com, then the net service name will become MyDB.example.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, when 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. (Users can still connect to a 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. On each cluster node, edit or add the service name entry to the tnsnames.ora file manually.

    log_archive_dest_2='SERVICE=standby OPTIONAL REOPEN=120'

  • On server nodes, addresses that use virtual host names configured only for internal cluster communications will be placed at the top of the address list. Therefore, applications running on the server nodes, including the database resource monitor, 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). If you must enable remote clients 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.

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

8.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 set).

8.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:\app\oracle\product\11.2.0\db_1)
      (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.

8.4.5 Support for Databases Using Shared Servers

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

Note:

When you set up a database to use a shared servers configuration, ensure that Oracle Fail Safe can continue to use a dedicated server connection for its internal operations. 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.)

8.4.5.1 Shared Servers for Databases

To use a shared server configuration, it may be necessary 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 runs in shared server mode after you add it to a group. Do not 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 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 8.2.5.

8.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 (initdatabase-name.ora) to either SHARED or EXCLUSIVE if users access the database using the SYS account. Set the REMOTE_LOGIN_PASSWORDFILE to NONE if users 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.

8.5.1 Synchronizing Password Files on Cluster Nodes

Database password 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 Fail Safe 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.

8.5.2 Changing the SYS Account Password

The password for the SYS account is normally stored in a password file that is located in the Oracle home associated with the database. Since each cluster node has an Oracle home that is used for a database that means that there are multiple password files that must be maintained when a database is a cluster resource. To change the password for the SYS account use the Oracle Fail Safe Manager utility so that the change can be propagated to each Oracle home in the cluster that is associated with the database. Do not attempt to manually change the SYS account password using SQL*Plus or any other utility since that will interfere with the password maintenance strategy used by Oracle Fail Safe.

The password for a database can be changed on the Properties page for a database resource. In Oracle Fail Safe Manager, select the database from the cluster resource list and then click on the Properties action in the Actions menu. The resource properties page is displayed. If operating system authentication is not used, then the password fields are displayed.

Description of db_gen_prop.gif follows
Description of the illustration db_gen_prop.gif

For a typical database, the password change will take effect immediately. However, if the database password file is being shared, that is, the database initialization parameter REMOTE_LOGIN_PASSWORDFILE has been set to SHARED, then the database must be re-opened before the password change can take effect. In other words, the database cluster resource must be taken offline and then brought back online, or the cluster group that owns the database has to be moved to another node in the cluster before the password can be changed. Oracle Fail Safe updates the password file while the database is offline.

8.5.3 Upgrading 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 you upgrade or move to a new home, perform the following steps:

  1. Remove the single-instance database from the group. Select the sample database you want to delete from the Available Oracle Resources list, then select Delete Sample Database from the Actions menu in the Oracle Resources view.

    Confirm Delete Sample Database dialog box opens. Click Yes.

  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. Specify the location of the converted database files as asked by the Oracle Database Upgrade Assistant. 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. To add an available resource to a group, select the resource you want to add to a group, then select Add This Resource to a Group action from the Actions menu of the Oracle Resources view.

    2. Add Resource to Group guided process wizard opens that guides through the configuration of the resource.

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.

8.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 PowerShell cmdlets) to carry out a planned failover, Oracle Fail Safe 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 Microsoft Windows Failover Clusters to carry out a planned failover, then it does not checkpoint the database before shutting it down.)

Note:

If you use a tool other than Oracle Fail Safe Manager, Oracle Fail Safe PowerShell cmdlet, or Microsoft Windows Failover Clusters to take a database offline, then Oracle Fail Safe considers it a failed resource and attempts 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.

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

Perform administrative tasks on a database configured for high availability as you would for any database, with one exception. Use Oracle Fail Safe Manager or the PowerShell cmdlets 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 Microsoft Windows Failover Clusters.

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 Fail Safe PowerShell cmdlets 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 the database and to perform your administrative tasks. While the database is started, users can access the database.

  3. Use a tool such as SQL*Plus to shut down the database once you complete the administrative tasks.

  4. Use Oracle Fail Safe Manager or the Fail Safe PowerShell cmdlets to place the database online again. The cluster will resume monitoring the database.

Chapter 5 provides an example of a script in which Fail Safe PowerShell cmdlets 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 Validate group operation. Adding a new data file can introduce a new disk dependency in the group. When you run the Validate group operation, it checks to ensure that the disk is a cluster disk and that it does not 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 correctly fails over with the database.

8.8 Database Homes

Starting with Oracle Database 12c Release 1 (12.1), Oracle Database supports the use of Oracle Home User, specified at the time of installation. Oracle Home User can be a Built-in Account or a Windows User Account. However, Oracle recommends using a Windows User Account. If a Windows User account is used, it must be a non-administrative, low-privileged account. Oracle Home User is associated with an Oracle home. Ensure that all nodes in a cluster that use the same Oracle home use the same Oracle Home User.

When Oracle Fail Safe accesses a database, it usually uses the same Oracle Database home to access any database on the system. The database home that Oracle Fail Safe uses, is chosen when the server starts. Oracle Fail Safe scans all database homes to look for the home that has the highest software version. Initially it only looks at homes that have their \bin path included in the system PATH environment variable. If Oracle Fail Safe does not find any database homes in the system PATH then it scans all the database homes looking for the home with the highest version.

Note that since Oracle Fail Safe chooses a database home when it first starts, it will not be aware of any database homes that are installed after Oracle Fail Safe started. The Oracle Fail Safe server and resource monitors must be restarted before Oracle Fail Safe considers a new database home for use. After installing a newer version of Oracle Database, the Cluster Service service should be restarted on all nodes so that Oracle Fail Safe can use the new database home.

If there are databases being managed by the cluster then there must be a database home installed on a local disk of each node in the cluster. If a database home is installed on a shared cluster disk then it's \bin directory should not be included in the system PATH environment variable.

There are two different Oracle Fail Safe components that may access a database:

  1. The Oracle Fail Safe server (OracleMSCSServices)

  2. The Oracle Fail Safe database resource DLL (FsResOdbs.dll)

The server will normally only access a database when configuring a database resource (add or delete resource) or during verify operations. During typical system operation the Oracle Fail Safe server does not access any databases.

The resource DLL is invoked by the Windows Cluster Service service when a database or listener resource is referenced by the cluster. For example, when a database is brought online, during IsAlive polling, when the resource fails over to another virtual node, and so on. On systems with multiple database homes, there may be a requirement to have each database on the system accessed, using the same database home software that is being used by the instance for that database. It is possible to configure a resource to run in a separate resource monitor process by selecting the "Run this resource in a separate resource monitor" check box on the resource properties page, displayed by the Oracle Fail Safe Manager. When that option is enabled, instead of always using the highest version database home on the system, the resource monitor process for the database uses the database home that is used to run the database instance when accessing the database. When referencing database listener resources, the resource DLL always uses the software from the \bin path used to start the listener service, regardless of the setting of the "Run this resource in a separate resource monitor" option.

See Section 4.3.1 for information regarding the user accounts used by Oracle Fail Safe components when accessing databases.

8.9 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 applications must connect through Oracle Net to an Oracle Database.

With transparent application failover, clients must not 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.

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

8.10.1 Handling Errors That Occur When Bringing a Database Online

Specify a script 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\FailSafe\Server\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.

8.10.2 Troubleshooting Problems

In most cases, the first step in troubleshooting a problem is to select the Validate cluster, Validate group, or Validate standalone database action. These tools are described in general in Chapter 7. If the Verify actions do not reveal the source of the problem, review the Windows Application Event Log to see if any error messages have been posted. When the operation fails, Oracle support may also ask to have tracing enabled. See Appendix A for more information on enabling Oracle Fail Safe tracing.

When you select Validate action for 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 Validate group action 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 select the Validate group action 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 does 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.

8.10.3 Problems Adding a Database to a Group

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

  • Select the database from the Available Oracle Resources list and then run the Validate standalone database action (described in Section 7.1.3).

    Running the Validate 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 Validate standalone database operation to ensure that the network (Oracle Net) is working.

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

    3. If the Add Database to Group operation fails, then check the Oracle Net rollback file as described in Section 8.10.7.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

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

  • Validate the group.

    When you select Validate (from the Oracle Fail Safe Manager group Actions menu), Oracle Fail Safe checks the group configuration and attempts to fix any problems that it finds.

    If the Validate group action finds a problem, then it returns an error message that should help you resolve the problem manually.

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

  • 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 Policies property page for the Oracle resources in Oracle Fail Safe Manager.) It uses the database connection information to access the database. If the database access information changes, then Oracle Fail Safe fails to access the database. Hence, Microsoft Windows Failover Clusters does 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 multiple single-instance database is in the group, then this helps you to identify the database causing the problem.

  • Ensure that the single-instance database Pending Timeout value specified in the Advanced Policies property page 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.

    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 (initdatabase-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 8.5.2 for information about how to update database password changes for Oracle Fail Safe.

8.10.5 Group Fails Over During Processing-Intensive Operations

Sometimes, 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 (Get-OracleClusterResource dbname).IsAliveEnabled=$false 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 (Get-OracleClusterResource dbname).IsAliveEnabled=$true command.

Oracle recommends that you run these PowerShell cmdlets 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 PowerShell cmdlets commands, see Chapter 6.

8.10.6 About 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 database authentication has been set up. Try the following to solve the problem:

  • If you select Use SYS account for authenticating database in the General property page of Oracle Database, then ensure that the REMOTE_LOGIN_PASSWORDFILE initialization parameter in the database initialization parameter file (initdatabase-name.ora) is set to SHARED or EXCLUSIVE.

    Section 8.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 it must be updated 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 Application Event log.

    Section 8.5.2 describes how to correctly update the database password.

8.10.7 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 Validate group and Validate standalone database operations to help you verify and repair the Oracle Net configuration. See Section 7.1.2 and Section 7.1.3 for details.

8.10.7.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. Ensure that a database SID is not included in multiple listeners. 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.

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

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

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

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

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

8.10.9 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. Select the Validate group action to validate the network (Oracle Net) configuration.

8.11 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 My Oracle Support and searching for note 259902.1 at

https://support.oracle.com