To connect as scott/tiger using the TNS Alias, a valid connection appears as follows:

"user id=scott;password=tiger;data source=sales";

ODP.NET also allows applications to connect without the use of the tnsnames.ora file. To do so, the entire connect descriptor can be used as the "data source".

The connection string appears as follows:

"user id=scott;password=tiger;data source=" + 
     "(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)" + 
     "(HOST=sales-server)(PORT=1521))(CONNECT_DATA="+
     "(SERVICE_NAME=sales.us.acme.com)))"

The Easy Connect and Easy Connect Plus naming methods enable clients to connect to a database without any configuration.

To use the Easy Connect naming method, ensure that EZCONNECT is specified by the NAMES.DIRECTORY_PATH parameter in the sqlnet.ora file as follows:

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

With this enabled, ODP.NET allows applications to specify the Data Source attribute in the form of:

//host:[port]/[service_name]

Using the same example, some valid connection strings follow:

"user id=scott;password=tiger;data source=//sales-server:1521/sales.us.acme.com"
"user id=scott;password=tiger;data source=//sales-server/sales.us.acme.com" 
"user id=scott;password=tiger;data source=sales-server/sales.us.acme.com"

If the port number is not specified, 1521 is used by default.

Easy Connect has been enhanced in ODP.NET 19c to support a wider application breadth, including clustered or cloud databases, and for ease of use. These improvements are called Easy Connect Plus and its features include:

• TCP/IP with SSL/TLS

• Any SQL*Net description level parameter can be used

• Multiple hosts and ports

• A straightforward name-value pair format

The syntax uses the question mark symbol ? to indicate the name-value pairs start and the ampersand symbol & to delimit each name-value pair. The entire connect string must be specified as a single string. Leading and trailing white spaces are ignored within parameter values. If whitespace is required as part of the value, it should be placed within double-quotes.

Easy Connect Plus syntax:

[[protocol:]//]host1{,host12}[:port1]{,host2:port2}[/service_name][:server][/instance_name][?parameter_name=value{&parameter_name=value}] 

Easy Connect Plus samples:

• tcps://salesserver1:1521/sales.us.example.com

• salesserver1:1521,salesserver2,salesserver3:1522/sales.us.example.com

• tcps://salesserver1:1521/sales.us.example.com?wallet_location=D:/oracle

• tcps://salesserver1:1521/sales.us.example.com?ssl_server_cert_dn=cn=sales,cn=OracleContext,dc=us,dc=example,dc=com

• tcps://salesserver1:1521/sales.us.example.com?https_proxy=www-proxy.mycompany.com&https_proxy_port=80

• salesserver1:1521/sales.us.example.com?connect_timeout=60&transport_connect_timeout=30&retry_count=3

ODP.NET can connect with connect identifiers mapped to connect descriptors in an LDAP-compliant directory server, such as Oracle Internet Directory and Microsoft Active Directory.

To configure LDAP for ODP.NET, Unmanaged Driver, follow these Oracle documentation instructions in Configuring the Directory Naming Method in Oracle Database Net Services Administrator's Guide.

To configure LDAP for ODP.NET, Managed Driver, follow the instructions in "settings section" and "LDAPsettings section."

Beginning with Oracle Database release 18c, version 18.1, organizations can use centrally managed users (CMUs) with Active Directory. This feature is designed for organizations who prefer to use Active Directory as their centralized identity management solution. Organizations can use Kerberos, PKI, or password authentication with CMU and Active Directory.

The data source enumerator enables the application to generically obtain a collection of the Oracle data sources that the application can connect to.

SSL Configuration Topics:

• Step 1: Confirm Client Wallet Creation

• Step 2: Use TCP/IP with SSL on the Client

• Step 3: Specify Required Client SSL Configuration (Wallet Location)

• Step 4: Set the Required SSL Version on the Client (Optional)

• Step 5: Set SSL as an Authentication Service on the Client (Optional)

Step 1: Confirm Client Wallet Creation

Before proceeding to the next step, you must confirm that a wallet has been created on the client and that the client has a valid certificate.

ODP.NET, Managed Driver supports file and Microsoft Certificate Store (MCS) based wallets.

• For file-based wallets, use Oracle Wallet Manager to check that the wallet has been created. See Step 1A: Confirm Wallet Creation on the Server in Oracle Database Security Guide for information about checking a wallet.

• For MCS, the Windows domain credentials will be used for the client credentials. Thus, a valid domain logon must be used while running the ODP.NET application. ODP.NET, Managed Driver will retrieve the credentials from the MY or Personal certificate store. Note that the server must also be configured to use MCS wallets. See Microsoft Certificate Services in Oracle Database Platform Guide for Microsoft Windows for information about setting up the server for MCS.

Step 2: Use TCP/IP with SSL on the Client

The ODP.NET Data Source must be modified to use SSL. Specifically, the transport protocol must be changed to use TCP/IP with SSL or what Oracle calls "tcps". An example ODP.NET Data Source for use with SSL is:

finance = (DESCRIPTION= 
  (ADDRESS = (PROTOCOL=tcps) (HOST=finance_server) (PORT=1575) )
  (CONNECT_DATA = (SERVICE_NAME=Finance.us.example.com) ) )

Step 3: Specify Required Client SSL Configuration (Wallet Location)

Edit the sqlnet.ora or .NET application configuration to specify the wallet location.

• An example of setting the SSL wallet location for file based wallets, where <wallet_location> is the specified location where the client wallet is stored:

  wallet_location = (SOURCE=(METHOD= File)
                            (METHOD_DATA=(DIRECTORY=<wallet_location>)))
  

• An example of setting the SSL wallet location for MCS based wallets is:

  wallet_location = (SOURCE=(METHOD= MCS))
  

Step 4: Set the Required SSL Version on the Client (Optional)

The SSL_VERSION parameter can be set through the sqlnet.ora or the .NET application.config, web.config, or machine.config file. Normally, it is not necessary to set this parameter. The default setting for this parameter is any, which allows the database server to apply any necessary restrictions to the SSL version accepted. An example setting in the sqlnet.ora is:

SSL_VERSION=3.0

Step 5: Set SSL as an Authentication Service on the Client (Optional)

Set the SQLNET.AUTHENTICATION_SERVICES parameter in the sqlnet.ora or application.config, web.config, or machine.config file to allow SSL to be used as a database external authentication methodology.

Note that SSL can be used as just a transport encryption vehicle. Hence, the "optional" designation for this setting.

If SSL is to be used as a database external Authentication Service, then a database externally authenticated user matching the client certificate must be created.

An example setting allowing SSL external authentication in the sqlnet.ora is:

SQLNET.AUTHENTICATION_SERVICES = (TCPS)

Steps for configuring SEPS:

• Step 1. Create the wallet file

• Step 2. Point the configuration to the client wallet

• Step 3. Turn on SEPS

Step 1. Create the wallet file

Use the mkstore utility to create the wallet file and insert the credentials.

Step 1a. Create a wallet on the client by using the following syntax at the command line:

mkstore -wrl wallet_location -create

For example:

mkstore -wrl c:\oracle\product\12.1.0\db_1\wallets -create
Enter password: password

Step 1b. Create database connection credentials in the wallet by using the following syntax at the command line:

mkstore -wrl wallet_location -createCredential db_connect_string username
Enter password: password

For example:

mkstore -wrl c:\oracle\product\12.1.0\db_1\wallets -createCredential orcl system
Enter password: password

Step 2. Point the configuration to the client wallet

In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set it to the directory location of the wallet you created in Step 1.

For example, if you created the wallet in $ORACLE_HOME/network/admin and your Oracle home is set to C:\app\client\<user>\product\<version>\client_1\, then you need to enter the following into your client sqlnet.ora file:

WALLET_LOCATION =
  (SOURCE =(METHOD = FILE)
           (METHOD_DATA =
              (DIRECTORY = C:\app\client\<user>\product\<version>\client_1\Network\Admin) ) )

Step 3. Turn on SEPS

Step 3. Turn on SEPS

SQLNET.WALLET_OVERRIDE = TRUE

This setting causes all CONNECT /@db_connect_string statements to use the information in the wallet at the specified location to authenticate to databases.

When external authentication is in use, an authenticated user with such a wallet can use the CONNECT /@db_connect_string syntax to access the previously specified databases without providing a user name and password. Note however, that the wallet file needs to be kept up to date with the database credentials. If the database credentials change, but the wallet file is not changed appropriately, then the connections will fail.

Please reference the following "key" when viewing the below Kerberos configuration examples:

• oracleclient = Kerberos/Windows Domain user ID used by the Oracle database client program to represent the Oracle Client user on the domain

• oracleserver = Kerberos/Windows Domain user ID used by the Oracle database server

• DOMAIN.COMPANY.COM = Kerberos/Windows domain

• dbhost.company.com = Oracle database server machine hostname

• kerberos_service_name = Kerberos service name

• dc.company.com = hostname for Kerberos Key Distribution Center (KDC) and Windows Domain Controller

Configuring Kerberos Authentication Topics:

• Step 1. Update Windows services file to include a "kerberos5" entry

• Step 2. Create client and server Kerberos users (Windows domain users for MSLSA)

• Step 3. Associate the DB server's Kerberos principal name with the DB server's Kerberos Service (SPN mapping) and generate the server keytab file

• Step 4. Confirm the mapping of server user to service principal

• Step 5. Setup server sqlnet.ora to point to the keytab file generated in step 2

• Step 6. Create a kerberos configuration file that points to the Kerberos KDC (Windows Domain Controller for MSLSA)

• Step 7. Configure the Oracle database client and server sqlnet.ora or .NET config to point to the above Kerberos configuration file

• Step 8. Point the client sqlnet.ora or .NET config to a credential cache file or to MSLSA

• Step 9. Set the client and server authentication services in the sqlnet.ora or .NET config to Kerberos5

• Step 10. Setup an externally authenticated database user that matches the Kerberos client user setup in step 1 (note the case)

• Step 11. Login to the client machine via the Windows Domain client user (for MSLSA) or perform an okinit to authenticate the client Kerberos user (for file based CC):

Step 1. Update Windows services file to include a "kerberos5" entry

Change the Kerberos entry in the Windows service file (C:\windows\system32\drivers\etc\services) from:

kerberos   88/tcp           krb5 kerberos-sec      #Kerberos

to:

kerberos   88/tcp kerberos5 krb5 kerberos-sec      #Kerberos

Step 2. Create client and server Kerberos users (Windows domain users for MSLSA)

As noted in the above "key", we will use oracleclient and oracleserver as our client and server Kerberos user IDs, respectively.

ODP.NET supports MSLSA using Windows domain users which have the following attributes:

• "Kerberos DES" unchecked

• "Kerberos AES 128 bit" checked

• "Kerberos AES 256 bit" checked

• "Kerberos preauthentication not required" checked

Step 3. Associate the DB server's Kerberos principal name with the DB server's Kerberos Service (SPN mapping) and generate the server keytab file

Run the following commands on the Kerberos KDC (Windows Domain Controller for MSLSA) as an administrator:

> ktpass -princ kerberos_service_name/dbhost.company.com@DOMAIN.COMPANY.COM /crypto all /mapuser oracleserver@DOMAIN.COMPANY.COM /pass <oracleserver password> /out v5srvtab 
 
> setspn -A kerberos_service_name/dbhost.company.com@DOMAIN.COMPANY.COM oracleserver

Step 4. Confirm the mapping of server user to service principal

Also on the Kerberos KDC, run the following command, noting the output:

> setspn -L oracleserver 
 
Registered ServicePrincipalNames for CN=oracleserver,CN=Users,DC=domain,DC=company,DC=com: 
        kerberos_service_name/dbhost.company.com 
kerberos_service_name/dbhost.company.com@DOMAIN.COMPANY.COM  

Step 5. Setup server sqlnet.ora to point to the keytab file generated in step 2

Add the following line to the server sqlnet.ora:

sqlnet.kerberos5_keytab = c:\krb\v5srvtab

Step 6. Create a kerberos configuration file that points to the Kerberos KDC (Windows Domain Controller for MSLSA)

An example kerberos configuration file (krb.conf):

[libdefaults] 
default_realm = DOMAIN.COMPANY.COM 
 
[realms] 
DOMAIN.COMPANY.COM = { 
  kdc = dc.company.com 
 } 
 
[domain_realm] 
.domain.company.com = DOMAIN.COMPANY.COM 
domain.company.com = DOMAIN.COMPANY.COM 
.DOMAIN.COMPANY.COM = DOMAIN.COMPANY.COM 
DOMAIN.COMPANY.COM = DOMAIN.COMPANY.COM 

Step 7. Configure the Oracle database client and server sqlnet.ora or .NET config to point to the above Kerberos configuration file

Edit the client or server sqlnet.ora to include:

sqlnet.kerberos5_conf = C:\krb\krb.conf

Or edit the client application config to include (in the settings section):

<setting name="sqlnet.kerberos5_conf" value="C:\krb\krb.conf" />

Step 8. Point the client sqlnet.ora or .NET config to a credential cache file or to MSLSA

Example pointing to Credential Cache file:

sqlnet.kerberos5_cc_name = c:\krb\krb.cc

Example pointing to MSLSA:

sqlnet.kerberos5_cc_name = MSLSA: 

Step 9. Set the client and server authentication services in the sqlnet.ora or .NET config to Kerberos5

sqlnet.authentication_services=(Kerberos5)

Step 10. Setup an externally authenticated database user that matches the Kerberos client user setup in step 1 (note the case)

create user "ORACLECLIENT@DOMAIN.COMPANY.COM" identified externally; 
grant connect, create session to "ORACLECLIENT@DOMAIN.COMPANY.COM";

Step 11. Login to the client machine via the Windows Domain client user (for MSLSA) or perform an okinit to authenticate the client Kerberos user (for file based CC):

okinit oracleclient 

Step 12. Run the ODP.NET application

Steps in configuring the NTS for the ODP.NET Client:

• Step 1. Ensure OSAUTH_PREFIX_DOMAIN is set correctly

• Step 2. Setup the externally identified database user

• Step 3. Setup the client configuration to utilize NTS as the authentication methodology

Step 1. Ensure OSAUTH_PREFIX_DOMAIN is set correctly

Make sure OSAUTH_PREFIX_DOMAIN is set appropriately. If you desire the externally identified user ID to include the domain, set it to true, otherwise false. The parameter is a registry setting that can be found at HKLM/software/oracle/HOME<ORACLE_SID>. For example, if your ORACLE_SID is r1, it is located at HKLM/software/oracle/HOMEr1.

Step 2. Setup the externally identified database user

Assuming a Step 0 setting of true, use the following commands to setup the externally identified database user associated with the desired Windows domain user:

create user "MYDOMAIN\MYUSER" identified externally; 
grant connect, create session to "MYDOMAIN\MYUSER";

Step 3. Setup the client configuration to utilize NTS as the authentication methodology

Edit the client sqlnet.ora or app config to add NTS to the sqlnet.authentication_services. For example.

sqlnet.authentication_services = (NTS)

Managed and unmanaged ODP.NET support the following encryption standards and algorithms:

• Advanced Encryption Standard (AES)

  • AES 128-bit

  • AES 192-bit

  • AES 256-bit

• Triple-DES (3DES)

  • 112-bit

  • 168-bit

ODP.NET, Managed Driver uses the following settings to configure network encryption:

• SQLNET.ENCRYPTION_CLIENT

• SQLNET.ENCRYPTION_TYPES_CLIENT

ODP.NET provides a comprehensive set of database schema information. Developers can extend or customize the metadata that is returned by the GetSchema method on an individual application basis.

To do this, developers must create a customized metadata file and provide the file name to the application as follows:

1. Create a customized metadata file and put it in the CONFIG subdirectory where the .NET framework is installed. This is the directory that contains machine.config and the security configuration settings.

   This file must contain the entire set of schema configuration information, not just the changes. Developers provide changes that modify the behavior of the schema retrieval to user-specific requirements. For instance, a developer can filter out internal database tables and just retrieve user-specific tables

2. Add an entry in the app.config file of the application, similar to the following, to provide the name of the metadata file, in name-value pair format.

   <oracle.dataaccess.client>
     <settings>
       <add name="MetaDataXml" value="CustomMetaData.xml" />
     </settings>
   </oracle.dataaccess.client>
   

When the GetSchema method is called, ODP.NET checks the app.config file for the name of the customized metadata XML file. First, the GetSchema method searches for an entry in the file with a element named after the provider, in this example, oracle.dataaccess.client. In this XML element, the value that corresponds to the name MetaDataXml is the name of the customized XML file, in this example, CustomMetaData.xml.

If the metadata file is not in the correct directory, then the application loads the default metadata XML file, which is part of ODP.NET.

When connection pooling is enabled (the default), the Open and Close methods of the OracleConnection object implicitly use the connection pooling service, which is responsible for pooling and returning connections to the application.

The connection pooling service creates connection pools by using the ConnectionString property as a signature, to uniquely identify a pool.

In managed and Core versions of ODP.NET, connection strings themselves must be an exact match in their entirety. If keywords are supplied in a different order or a space is added to the connection string, a new pool is created. If a pool already exists with the requested signature, a connection is returned to the application from that pool.

In unmanaged ODP.NET, a new pool is created only when connection string attribute values change. Extra spaces or changing keyword order do not create a new pool.

When a connection pool is created, the connection pooling service initially creates the number of connections defined by the Min Pool Size attribute of the ConnectionString property. This number of connections is always maintained by the connection pooling service for the connection pool, except when Fast Connection Failover removes invalid connections or Connection Lifetime is exceeded. In these two cases, the connection number could drop below the Min Pool Size. ODP.NET would then attempt to restore the minimum pool size level upon the next connection request.

At any given time, these connections are in use by the application or are available in the pool.

The Incr Pool Size attribute of the ConnectionString property defines the number of new connections to be created by the connection pooling service when more connections are needed in the connection pool.

When the application closes a connection, the connection pooling service determines whether or not the connection lifetime has exceeded the value of the Connection Lifetime attribute. If so, the connection pooling service destroys the connection; otherwise, the connection goes back to the connection pool. The connection pooling service enforces the Connection Lifetime only when Close() or Dispose() is invoked.

The Max Pool Size attribute of the ConnectionString property sets the maximum number of connections for a connection pool. If a new connection is requested, but no connections are available and the limit for Max Pool Size has been reached, then the connection pooling service waits for the time defined by the Connection Timeout attribute. If the Connection Timeout time has been reached, and there are still no connections available in the pool, the connection pooling service raises an exception indicating that the connection pool request has timed-out. Upon a connection timeout, ODP.NET distinguishes whether the timeout occurred due to the database server failing to deliver a connection in the allotted time or no connection being available in the pool due to the maximum pool size having been reached. The exception text returned will either be "Connection request timed out" in the case of the former or "Pooled connection request timed out" in the case of the latter.

The Validate Connection attribute validates connections coming out of the pool. This attribute should be used only when absolutely necessary, because it causes a round-trip to the database to validate each connection immediately before it is provided to the application. If invalid connections are uncommon, developers can create their own event handler to retrieve and validate a new connection, rather than using the Validate Connection attribute. This generally provides better performance.

The connection pooling service closes connections when they are not used; connections are closed every 3 minutes. The Decr Pool Size attribute of the ConnectionString property provides connection pooling service for the maximum number of connections that can be closed every 3 minutes.

Beginning with Oracle Data Provider for .NET release 11.1.0.6.20, enabling connection pooling by setting "pooling=true" in the connection string (which is the case by default) will also pool operating system authenticated connections.

Publication of individual unmanaged ODP.NET performance counters is enabled or disabled using the Windows Registry value PerformanceCounters of type REG_SZ. This registry value is under:

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\ODP.NET\Assembly_Version

where Assembly_Version is the full assembly version number of Oracle.DataAccess.dll.

Similarly to the .NET config file, multiple performance counters can be obtained by adding the valid values. For example, if PerformanceCounters is set to 3, then both HardConnectsPerSecond and HardDisconnectsPerSecond are enabled.

Commonly, ODP.NET performance counters are monitored using Perfmon. The counters are published under the following Category Names:

• ODP.NET, Core Driver

• ODP.NET, Managed Driver

• ODP.NET, Unmanaged Driver

Administrators can choose the individual ODP.NET counters to monitor after selecting one or more of these categories. PerfMon shows all ODP.NET counters, but only the explicitly enabled counters generate statistics.

After choosing the counters to monitor, administrators then select the running instance(s) to monitor. ODP.NET instances must be actively running for them to appear in PerfMon. Otherwise, no instances will appear available to monitor. After instance selection occurs, they are added to PerfMon as counters to monitor.

Performance counters can monitor at the application domain, pool, or database instance level. Database instance level monitoring only applies if load balancing or Fast Connection Failover features are enabled.

The instance name format is as follows:

<Application Domain Name> [<Process Id>, <Application Domain Id>][<Connection String/Pool Name>][<Instance Name>]. The entry is limited to 127 characters. There is a restriction length on every field in the instance name. The following table shows the maximum number of characters allocated for each field:

When the length of a field value exceeds the length limit, the string is truncated and appended with "..." to fit within the length limit and indicate the continuation. For example, for a given application called Program.exe with a connection string user id=hr;Password=<password>;data source=inst1;max pool size=125;min pool size=50, one may see the following similar to the following for a process that has two application domains:

• Program.exe [123, 1]

• Program.exe [123, 1][ user id=hr;data source=inst1;max pool siz...]

• Program.exe [123, 1][ user id=hr;data source=inst1;max pool siz...] [instA]

• Domain 2[123, 2]

• Domain 2[123, 2][ user id=hr;data source=inst1;max pool siz...]

• Domain 2[123, 2][ user id=hr;data source=inst1;max pool siz...] [instB]

• Domain 2[123, 2][ user id=hr;data source=inst1;max pool siz...] [instC]

Since connection pool attributes can be similar in their first 70 characters, applications can set a Pool Name to uniquely identify each one in the monitoring tool. For example, when using Pool Name, the process will show up as follows:

Domain 2[123, 2][Pool Name][instC]

Given the delays that failovers can cause, applications may wish to be notified by a TAF callback. ODP.NET supports the TAF callback function through the Failover event of the OracleConnection object, which allows applications to be notified whenever a failover occurs. To receive TAF callbacks, an event handler function must be registered with the Failover event.

When a failover occurs, the Failover event is raised and the registered event handler is invoked several times during the course of reestablishing the connection to another Oracle instance.

The first call to the event handler occurs when Oracle Database first detects an instance connection loss. This allows the application to act accordingly for the upcoming delay for the failover.

If the failover is successful, the Failover event is raised again when the connection is reestablished and usable. At this time, the application can resynchronize the OracleGlobalization session setting and inform the application user that a failover has occurred. No significant database operation should occur immediately after a FailoverEvent.Begin event. SQL and major database operations should wait until the FailoverEvent.End event. FailoverEvent.Begin is primarily used to reject failover or to trace it. FailoverEvent.Begin can also be used for non-database application operations, such as informing the end user a failover is in progress and to wait until it completes before proceeding. Transactions can be used in the FailoverEvent.End callback phase, such as to file fault tickets or audit. These transactions must be committed before the callback completes.

If failover is unsuccessful, the Failover event is raised to inform the application that a failover did not take place.

The application can determine whether or not the failover is successful by checking the OracleFailoverEventArgs object that is passed to the event handler.

The following example registers an event handler method called OnFailover:

// C#
 
using System;
using Oracle.DataAccess.Client; 
 
class TAFCallBackSample
{
  public static FailoverReturnCode OnFailover(object sender, 
                                              OracleFailoverEventArgs eventArgs)
  {
    switch (eventArgs.FailoverEvent)
    {
      case FailoverEvent.Begin :
        Console.WriteLine(
          " \nFailover Begin - Failing Over ... Please standby \n");
        Console.WriteLine(
          " Failover type was found to be " + eventArgs.FailoverType);
        break;
 
      case FailoverEvent.Abort :
        Console.WriteLine(" Failover aborted. Failover will not take place.\n");
        break;
 
      case FailoverEvent.End :
        Console.WriteLine(" Failover ended ...resuming services\n");
        break;
 
      case FailoverEvent.Reauth :
        Console.WriteLine(" Failed over user. Resuming services\n");
        break;
 
      case FailoverEvent.Error :
        Console.WriteLine(" Failover error gotten. Sleeping...\n");
        return FailoverReturnCode.Retry;
 
      default :
        Console.WriteLine("Bad Failover Event: %d.\n", eventArgs.FailoverEvent);
        break;
    }
    return FailoverReturnCode.Success;
  } /* OnFailover */
 
  static void Main()
  {
    OracleConnection con = new OracleConnection();
 
    con.ConnectionString = "User Id=scott;Password=tiger;Data Source=oracle;";
    con.Open();
    con.Failover += new OracleFailoverEventHandler(OnFailover);
    Console.WriteLine("Event Handler is successfully registered");
 
    // Close and Dispose OracleConnection object
    con.Close();
    con.Dispose();
  }
}

The Failover event invokes only one event handler. If multiple Failover event handlers are registered with the Failover event, only the event handler registered last is invoked.