© 2018 KADIR ILKER TAYSI ALL RIGHTS RESERVED
This tutorial covers the situation where an application still has to be able to connect to the primary
database after a failover or a switcover is initiated on a dataguard system. This is not the actual
seamless application failover. It does not employ any clusterware components like FAN or TAF. That
is why I call this "EASY" Application Failover. It may actually have a different name but I didn't come
across with an Oracle document about it... so it is "Easy Applcation Failover with Datagaurd" for me.
2. HOW IT WORKS
The below diagram shows the architecture of the setup.
The logic behind the application continuity in the case of a swithover (or failover) depends on a
virtual service that can be started or stopped with a trigger depending on the role of the database
server. To be more precise, we should implement a role based service that will only be enabled when
the database server is in primary role. In fact, from the version 11.2 on, this role based service is not
handled by triggers but the clusterware as follows:
srvctl add service -db orcl -service vservice -role primary
However, it might be the case that we are working on a single instance database without a
clusterware, so the trigger methodology can still be used.
As a result, the service name that the application should be using, would be active only on the
primary side at a given time. Even the application may try to go to the standby (if it is the first
connection defined), it will see that there is no such service and proceed to the next adress in the list.