曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
The services that applications connect to can be enabled for events by enabling the
AQ_HA_NOTIFICATIONS and FAILOVER attributes for the service using the
DBMS_SERVICE.CREATE_SERVICE or DBMS_SERVICE.MODIFY
_SERVICE procedures. For further information about these procedures, refer to
the PL/SQL Packages and Types Reference manual for Oracle Database 10g
Release 2.
Fast-Start Failover – Oracle Data Guard 10g Release 2 Page 17
When applications that meet the above criteria connect to the primary database,
they automatically become subscribers of the HA event notification. This
subscription information is registered in the REG$ system table.
In the case where the failover target is a physical standby database, TAF enabled
applications will receive notification causing them to disconnect from the old
primary and reconnect to the new primary database. This notification occurs
regardless of whether the new primary database is single instance or RAC. This
allows applications to connect to the new primary soon after getting the
notification instead of having to wait for the TCP timeout period, as would be the
case if it were a site failure. Getting this notification is beneficial even in the RAC
case if it was a whole site failure where the RAC monitors do not get a chance to
post the notifications.
A caveat: since system tables are not replicated to logical standby databases, if
failover were to occur to a logical standby database, applications connected to the
failed primary database will not get this notification, and will need to be manually
redirected to the new primary database – previously a logical standby.
EXAMPLE: CONFIGURING AUTOMATIC FAILOVER
In previous versions of Oracle if an entire primary site suffered a complete outage
(either all primary hosts or network) then ONS (JDBC & ODP) and OCI clients
would not be notified of the outage. All clients connected to that cluster would
wait for TCP timeout since the nodes of the cluster would not be able to close the
TCP sockets. When a failover to the standby occurs, the FAN ONS clients and
OCI clients had to be manually restarted in order to break out of this TCP wait.
In Oracle Database 10g Release 2 there is the ability to notify OCI clients that a
Data Guard failover has occurred using the DB_DOWN event. Once notified the
clients drop the connections to the failed primary and reestablish connections to
the new primary. In addition, it is now possible to automate the restart of middle
tier applications using the DB_ROLE_CHANGE system event, so that both FAN
ONS and non FAN ONS JDBC applications can connect to the new primary.
More specifically, when a failover occurs the new primary can be previously
configured so that the following takes place automatically:
• Enable primary specific service name(s)
• Update LDAP or other naming methods to point to the new primary host
• Notify FAN OCI clients (OCI apps) that the old primary is down and a
reconnection to the new primary should be performed
• Restart any middle tiers so that FAN ONS and non FAN ONS JDBC
clients can reconnect to the new primary
Fast-Start Failover – Oracle Data Guard 10g Release 2 Page 18
Configuring for Transparent Client Failover
The following illustrates the steps needed to configure for transparent client
failover in Oracle Database 10g Release 2.
Assumptions:
• Data Guard configuration with Fast-Start Failover enabled
• Clients using LDAP directory naming to resolve service names
• OCI applications meet the following requirements:
o Initialize the OCI Environment in OCI_EVENTS mode
o Connect to a service that has notifications enabled (Covered
within this document)
o Link with a thread library
Create a primary specific service
The clients and application should connect to the database using a primary specific
service name. This service will migrate to any database that currently holds the
primary role. In addition to being specific to the primary role the service must be
created with AQ_HA_NOTIFICATIONS set to TRUE to enable proper client
notification following a role transition.
1. Using DBMS_SERVICE create a service on the primary database that will be
unique to the primary database. Note that enabling AQ_HA_NOTIFICATIONS
is required.
SQL> exec dbms_service.create_service
(service_name => 'sales',
network_name => 'sales',
aq_ha_notifications => TRUE,
failover_method => 'BASIC',
failover_type => 'SELECT',
failover_retries => 180, failover_delay => 1);
2. Start the new service on all primary instances:
SQL> exec dbms_service.start_service('sales');
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
航空资料22(60)
