Oracle Database 11c: "Client Failover" in "Standby Databases" (Part I)

by Expert ORACLE ACE  :- Joel Perez  & Mahir M. Quluzade  
Estimated Oracle technologists receive a cordial greeting. Through this article, we will have the opportunity to address an issue of great importance as it is the concept of "Client Failover" in database environments "Standby"
Introduction
repeatedly when analyzing infrastructure and customer implementations, one of the first things we do is check how good practices are implemented or if they are really.
At the time of doing on "Standby Databases". We always do a typical question: What is the procedure or method applied / used to manage connections at the time applications has conducted a "Switchover" or "Failover"?
The answers are different, the most typical in many cases is:
"... As almost never do," Switchover "much less" Failover "is rare that we have to redirect our applications connections .. therefore given the time we have to perform this operation, we went to application server, there manually edit the "Tnsentry" which directs our production database, and then change to addresses in the "Standby" server ... which will be operating the database with primary role "
Overall many customers apply manual methods to re-direct their applications to servers with databases "Standby" once performed an operation type "Switchover" or "Failover".
Before going further in this matter is a question that should be all that implement solutions DBAs "Standby Databases" / "Data Guard".Oracle products enjoy a high level of technicality and even more so when they have several versions of development as the theme related to "Standby Databases" / "Data Guard". The question is this: If the above solutions have to perform highly technical operations "Switchover" / "Failover" and more, "Oracle Corp." would set aside the development and availability of a way for applications to be High scalability with the above?
The response to the event is: If, "Oracle Corp" has solution for this mode, the same is called "Client Failover" for application connections.The concept referred to "Client Failover" is not based only on context "Data Guard".
For more information about them here below some links which may cover in deeply all the information about:
Client Failover Best Practices for Highly Available Oracle Databases: Oracle Database 11g Release 2http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf
Client Failover Best Practices for Highly Available Oracle Databases Oracle Database 12chttp://www.oracle.com/technetwork/database/availability/client-failover-2280805.pdf
The aim of this article is to present a brief and effective one of the main techniques for implementing "Client Failover" solution "Data Guard" form. Through the links provided, you may cover the issue in a general context.
Let's begin ...
The figure below shows a typical configuration of a solution "Data Guard" is exposed
The first changes will be applied to the file "tnsnames.ora" & "sqlnet.ora" for servers and clients. In the figure we can see a server with IP: 192.168.56.146 conceptually which serves as the primary server and the second IP address: 192.168.56.136 as "Standby" server. In describing the "Tnsentry" find the inclusion of both servers. In the file "sqlnet.ora" including the parameter "SQLNET.INBOUND_CONNECT_TIMEOUT"
For more information on the use of "SQLNET.INBOUND_CONNECT_TIMEOUT" parameter, we place the textual reference here his description from the official Oracle documentation. http://docs.oracle.com/cd/B28359_01/network.111/b28317/sqlnet. htm # CIHCCCHD

The main objective of this article and technology we are discussing is to provide a setting in which it is possible that the client can connect either to the primary database regardless of whether this is in any of the servers without modifying the client files when a transition caused by a "Switchover" or "failover" occurs.
In the figure we have as an example the implementation of an operation of "Failover". Internally in the database of production and therefore so replicated database "Standby", will have a service that this case is called "ADMAPP". The same will be started "started" only in the primary database, the database "Standby" it will be stopped. The control mentioned settle it through a trigger on event "on Database Startup". As you can display the code is quite simple, if the role running the database at that time is a "Primary" then proceed to start otherwise I remain detained as is the default condition at the onset of database.

Ubiquémonos on stage in which it has already been carried out operation "Swithover" or "Failover". As a result of it the primary database transform its role to "Standby Database" and back to the original "Standby Database", which by the time play role as primary database.
In the case described, customers can connect without any problem under this new configuration because the "ADMAPP" service is started on the primary database that is working on the server (192.168.56.136). Analyzing Configuration "tnsentry" described, it observed that it supports the described connection.
So in this simple way we can establish "Client Failover" Database "Standby". The one shown here is the main concept. Additional information to know about what would happen to the operation of the "Observer" should be set, applying TAF and their effects .. etc .. all the cover in the next installment.
To conclude this paper we show an example of "tnsentry" to support the model described for RAC environment. As you can see, we have an entry for a RAC configuration, for that case would be the typical solution which forms the primary (Database production RAC) and the "Standby" side configured for this case to a server-based data "Single Instance". Description of the figure:
* "LOAD_BALANCE" & "FAILOVER" for the two items on the list (RAC & Settings "Single Instance") 
* As is natural and normal way, "LOAD_BALANCE" to the internal configuration of the RAC solution.
Hoping that this article will be useful.

Comments

Popular Posts