Hi Stefan ,
You are right my lab relied on the TAF (Transparent Application failover)
arguments set on the server side (option -e , -m , -w ,-z bellow ). But
that I guess is only enough for load balancing In RAC as Server side TAF
settings override client-side counterparts that might be configured in TNS
connect descriptors.
--- Add dynamic service to both databases
# srvctl add service -d mtldb -s *virtuo* -l PRIMARY -e SELECT -m
BASIC -w 1 -z 180
# srvctl add service -d mtlstd -s *virtuo* -l PRIMARY -e SELECT -m
BASIC -w 1 -z 180
Your tnsnames descriptors are definitely more relevant for a production
environment
Thanks
Koss
On Wed, Aug 21, 2019 at 12:18 AM Stefan Knecht <knecht.stefan@xxxxxxxxx>
wrote:
Nice write-up Koss.
This however is sub-optimal:
*PROD_DG* =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =montreal-01)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST =montreal-02)(PORT = 1521))
(CONNECT_DATA =(SERVER = DEDICATED)
(SERVICE_NAME = virtuo.evilcorp)))
Particularly for production, you're gonna want to at the very least
specify timeouts for the connections. If your primary instance (presumably
montreal-01) fails totally, connection attempts to it may hang indefinitely
(or for a long enough time to cause an incident) despite the failover
having already happened and montreal-02 happily working, clients may never
reach it.
Take a look at some of the examples here:
https://www.oracle.com/technetwork/database/availability/client-failover-2280805.pdf
SALES= (DESCRIPTION_LIST= (LOAD_BALANCE=off) (FAILOVER=on) (DESCRIPTION=
(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
(ADDRESS_LIST= (LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=oltpworkload))) (DESCRIPTION=
(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
(ADDRESS_LIST= (LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=oltpworkload))))
That way, you can control how long a connection attempt will take -
regardless of where the primary currently is. Otherwise, you may be at the
whim of the underlying platforms' TCP timeout settings, which may cause
surprisingly high wait times before the time out.
Stefan
On Wed, Aug 21, 2019 at 10:27 AM k.hadd <kouss.hd@xxxxxxxxx> wrote:
Sourav ,
Client automatic failover is totally fine through role based services
(11g+/Oracle restart).
Here is a detailed example I previously described in my blog
https://koussilicious.blogspot.com/2019/02/deploying-oracle-active-data-guard-12c_12.html
Check the section "7.2 :CONFIGURATION OF THE FAILOVER CLIENT" you may
find what you are looking for.
Regards
Koss
On Tue, Aug 20, 2019 at 2:29 PM Sourav Biswas <biswas.sourav@xxxxxxxxxxx>
wrote:
Thank you very much, Stefan and Rakesh !!!
I would certainly discuss these options with my clients.
Best Regards,
Sourav Biswas
+91-9650017306
------------------------------
*From:* Rakesh Ra <rakeshra.tr@xxxxxxxxx>
*Sent:* Monday, August 19, 2019 5:48 PM
*To:* knecht.stefan@xxxxxxxxx <knecht.stefan@xxxxxxxxx>
*Cc:* biswas.sourav@xxxxxxxxxxx <biswas.sourav@xxxxxxxxxxx>; Oracle-L
Freelists <oracle-l@xxxxxxxxxxxxx>
*Subject:* Re: Automation: DG Broker
Yes as Steve mentioned role based services can do the trick if you are
in 11.2 and above.. this doesn't requires a manual intervention.
On Mon, Aug 19, 2019, 15:27 Stefan Knecht <knecht.stefan@xxxxxxxxx>
wrote:
They way this was normally done is with 2 simple things:
- services which are tied to the database role
- connection strings that use the service (as opposed to SID) and
reference both the primary and standby site with a proper timeout
This works with single instance data guard setups as well as RAC data
guard setups.
No need to fiddle around with application servers or DNS at all.
Have a quick good on Oracle's MAA (maximum availabiltity architecture) -
there's loads of documentation on this out there.
On Mon, Aug 19, 2019 at 3:41 PM Sourav Biswas <biswas.sourav@xxxxxxxxxxx>
wrote:
Hi Everybody,
This is a client requirement related to Oracle Dataguard.
DG Broker is configured to perform "Failover". Which works fine and
fails over to Physical Standby when the conditions are met. Now, the client
wants, that once DG Broker performs "Failover" its should also notify the
Application DNS Server to redirect its traffic to new Primary Database.
This is part of automation workflow, where client wants to ensure there
is no manual intervention with Database Failover as well as Application
switch to new Primary Database.
Please suggest.
Thanks and Regards,
Sourav Biswas
+91-9650017306
--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction
Framework!
Visit us at zztat.net
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fzztat.net%2F&data=02%7C01%7C%7C8b72c2f41df544316a5508d7249f5240%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637018139003098690&sdata=MsHcI1hKVqm4QDIY8LgLBzgH0zk8wIxM8nroeuFwRJQ%3D&reserved=0>
|
@zztat_oracle | fb.me/zztat
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffb.me%2Fzztat&data=02%7C01%7C%7C8b72c2f41df544316a5508d7249f5240%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637018139003118701&sdata=aLOvbhzr6IB49SoX3dGdcBEvcvCmA0f9A1IsWwpksX0%3D&reserved=0>
| zztat.net/blog/
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fzztat.net%2Fblog%2F&data=02%7C01%7C%7C8b72c2f41df544316a5508d7249f5240%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637018139003138712&sdata=vp6iExZVYwApn77sFEwU6dwvl0DO6A8Bb9D%2BcUBGSlo%3D&reserved=0>
--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/
