1

High Availability Present and Future

DAC 10g : Setting Fail Over for the DAC Server
DAC 10g does not have high availability built in. However, it is possible to set up
a fail-over server. This is useful as a stand-by mechanism, which requires
manual intervention if the primary host hosting the DAC Server goes down.
1. Restore the DAC repository in an Oracle RAC database.
2. Configure the DAC Server on two hosts:
2.1. In the Setup view, go to the DAC System Properties tab and set the DAC
Server Host property as the primary host.
2.2. Set the DAC Alternate Server Host property as the standby host.
Note: Only one DAC Server runs at a time.
3. Set the Auto-Restart ETL property in the DAC System Properties tab to false.
4. Monitor the health of the main DAC Server with a monitoring tool such as
Veritas.
4.1. Use the DAC command line utility for monitoring, using the getETLStatus
command. This will return an error code other than 0 if the DAC Server is
not running.
5. If the main DAC Server fails, Veritas can start the alternative DAC Server.
Note: The DAC Server can only be started from the machine where it is
installed. It cannot be remotely started.
6. Restart the failed ETL from the standby server using the DAC command line
utility. The action picks up an incomplete ETL and runs it. The DAC Client
cannot communicate with this alternate DAC Server.
7. Continue to ping the main DAC Server machine.
8. Once the main host becomes available, wait for any ETL currently running to
complete. After the ETL is done, stop the server on the alternate host by
running stopserver.bat/.sh prior to bringing it up again on the primary server.
Note: There can be unexpected behavior if both the main server and the
alternate server are allowed to run simultaneously, particularly when ETL
schedules are defined in the DAC repository for periodic running of ETLs.

DAC 11g High Availability Capability

Please note that the following write up provides a description of the intended design. This
design may change before the general release.

2

Starting with DAC 11g, the DAC Server runs as a service on WLS (Weblogic
Server). With DAC 11g, it is possible to set up multiple nodes on a cluster as fail
over nodes. Because the DAC service is a singleton there can be only one
instance of a DAC Server running against an instance of the DAC repository
only one of the nodes will be active in running the ETL.

The following diagram shows the architecture of how DAC can be deployed in
11g to obtain the HA/Failover capability.



In the BI Cluster, when one of the managed servers becomes unavailable, the
second managed server automatically picks up the job left undone by the first.
To enable this, set the DAC System Property called Auto Restart ETL to True.
3

This parameter is set to False by default. The second managed server also is
capable of authenticating any DAC user defined in a common credential store.

The interaction between DAC and Informatica for running ETL utilizes some of
the command line utilities provided by Informatica, such as:

Pmcmd.exe: This utility is used to start/stop workflows and to get
workflow status.
Pmrep.exe: This utility is used to get the list of sessions used in a
workflow.

DAC connects to the Informatica services via the domain information for both the
Integration and Repository services.

DAC requires a shared network location which is highly available where all the
configuration related information should be stored. This enables the multiple
managed servers to access crucial information, such as the connectivity file, log
file location, and so on.

For setting up Informatica for high availability, refer to the Informatica
documentation.

We recommend DAC and Informatica servers have a shared network drive for
DAC to produce the parameter files which can be consumed by Informatica.

Assume the following scenario: While an ETL is still running, the machine on
which the first managed server for DAC is running goes down. The second
managed server automatically gets started, and the execution graph status gets
reconstructed using the run history tables.

There are three possible scenarios for the workflows that were started by the first
managed server:

The workflow may still be running on the Informatica Integration
Service grid. If so, DAC will wait for it to complete.
The workflow may have completed, in which case DAC will not restart
the process again.
The workflow may have failed, in which case DAC will restart the
process again.

Note: For HA to work well, the DAC Server needs to run in an ENU locale,
because we parse the pmcmd/pmrep outputs to find the workflow status,
start/end times and other run statistics, such as number of rows processed,
Read/write through puts, and so on.

4

DAC Future Releases

Please note that the following write up provides a description of the intended design. This
design may change before the general release.

While DAC 11g addresses the HA/Failure recovery between DAC and
Informatica, the whole of the ETL process still runs on only one managed server.
In the future, we have plans to make DAC services to be clusterable.