DataGuard in RAC and redo apply performance in consolidated environments


My customer has five standby databases in the same 2-node RAC cluster. Today, after an ASM data diskgroup full, several databases had to recover quite some archivelogs.

The load on the first node immediately went to the roof when I restarted the redo apply, after adding space to the diskgroup.

This because, by default, the redo apply starts on the first available instance of the RAC cluster, which in this case was the first instance for all DBs.

Two things I learned:

1. Move apply instance

To move the apply instance for a DB called dbname to the second instance:

DGMRTL> EDIT DATABASE dbname SET STATE='apply-on' WITH APPLY INSTANCE=dbname2;

No need to stop the apply before, the dataguard broker takes care of everything.

2. Enable multiple apply instances

This works without problems in current versions of 19c, but be aware of the cpu and memory usage it brings:

DGMGRL> EDIT DATABASE dbname SET PROPERTY ApplyInstances=2;  // or "=all" for all instances

I took the change to suggest Oracle Product Manager to have dataguard apply process to start either randomly or on the node with the least load, to make easier to manage on consolidated environments.

Leave a comment

Your email address will not be published. Required fields are marked *