Working with an Oracle Data Guard environment

In this topic, you will learn how to support switchover and failover operations when replicating from an Oracle Data Guard environment with multiple nodes consisting of one primary node and several standby nodes.

Update task/endpoint credentials

After a failover or switchover operation in a Data Guard environment, it is necessary to update the task/source endpoint. This can be done in one of the following ways:

• Update the source endpoint credentials by changing them from primary to standby, and vice versa.

• Maintain two Oracle source endpoints, one for primary and one for standby. Following a switchover or failover operation, switch between primary and standby nodes. All relevant tables need to be re-selected after making the switch.

• Use QEM command ReconfigureEndpointNoWait to switch between primary and standby Oracle source endpoints. This command will switch between the endpoints in a task without requiring the user to re-select the task table.

  For more information, see Qlik Enterprise Manager.

• Create two tasks, one that points to the primary database and one that points to the secondary database. Ensure that the first task is active and that the second is stopped. Following a failover operation, the first task will stop and the second task will start. This procedure can also be scripted.

  Information noteThis option does not apply to switchover operations.

Handle switchover scenario:

When a task runs with a primary node and a switchover is executed on the database side:

1. Stop the task.

2. Switch the endpoint from the primary node to a standby node. If it has a variant name and only the IP address changes, do not change server name.

3. Resume the task. The task will continue from the checkpoint where the task was stopped, and will continue applying changes if there are any.

Handle failover scenario:

Replicate preparation

The following procedure describes how to configure Replicate to handle a failover operation in a Data Guard environment:

1. Create a task that points to the primary database.

2. In the advanced settings for the primary Oracle source endpoint, set the supportResetLog=true internal parameter.

   For more information, see Additional settings and summary.

3. Run the task. It will be active until a failover occurs.

Failover procedure

In case of a failover scenario, perform the following steps:

1. Ensure that the task pointing to the primary database has stopped. If it hasn't, stop it.

2. Open a command prompt (on Windows) or Linux shell (on Linux) on the Replicate server, and change directory to the bin folder of the Replicate installation.

   The default folder is C:\Program Files\Attunity\Replicate\bin for Windows and /opt/attunity/Replicate/bin for Linux.

3. Run the following command. It will output a checkpoint string that will be used when starting the task.

   repctl -d <data_folder> getcheckpoint <mytask>

   Where data_folder is the location of Replicate’s data folder and mytask is the task name.

   Example:

   repctl -d "C:\Program Files\Attunity\Replicate\data” getcheckpoint "dg1task"

   The output will be similar to the following:

   command getcheckpoint response:

   {

   "checkpoint": "checkpoint:V1#608#00000000.02180113.00000001.0000.00.0000:354.8739.16#0#0#*#0#13"

   }

4. Run the following command to start the task with the checkpoint string from the previous step. This will ensure that the task starts from the correct position, so that no events are lost.

   repctl -d <data_folder> connect; execute <mytask> flags=09 operation=02 cdcposition=<checkpoint>; disconnect;

   Where <data_folder> is the location of Replicate’s data folder, <mytask> is your task name, and <checkpoint> is the checkpoint string.

   Example:

   repctl -d "C:\Program Files\Attunity\Replicate\data" connect; execute dg1task flags=09 operation=02 cdcposition=checkpoint:V1#608#00000000.02180113.00000001.0000.00.0000:354.8739.16#0#0#*#0#13; disconnect;

5. Replicate will now capture all the events that were not previously captured, and continue capturing future events. Ensure that the failover process has finished before restarting the task from where it was stopped, and that the current primary is set to work again.