Rac One Node : Create preferred node

In my previous Rac One Node post I gave a way to “stick” one Rac One Node database to a particular node of your cluster so that :

  1. It should re-start automatically on the “stick” node in case of database or node crash.
  2. It does not relocate automatically on other nodes.

In this post I’ll give a way to create a “preferred” node for a Rac One Node database so that:

  1. It should re-start and relocate automatically on the “preferred” node as soon as it is available.
  2. It relocates automatically on other nodes in case the “preferred” node crash.

Let’s go, first modify the SERVER_NAMES attribute of the associated server pool to keep only the “preferred” node:

To which pool belongs the db ?

crsctl status resource ora.bdto.db -p | grep -i pool
SERVER_POOLS=ora.BDTO

Which servers are part of this pool ?

crsctl status serverpool ora.BDTO -p | grep -i server
SERVER_NAMES=bdtnode1 bdtnode2

Modify the server pool to define the “preferred” node for the database (bdtnode2 for example):

crsctl modify serverpool ora.BDTO -attr SERVER_NAMES="bdtnode2"
crsctl status serverpool ora.BDTO -p | grep -i server
SERVER_NAMES=bdtnode2

Second step is to change the PLACEMENT attribute of the database.

Change the PLACEMENT attribute from restricted to favored:

crsctl status resource ora.bdto.db -p | grep -i place
ACTIVE_PLACEMENT=1
PLACEMENT=restricted

crsctl modify resource ora.bdto.db -attr PLACEMENT="favored"
crsctl status resource ora.bdto.db -p | grep -i place
ACTIVE_PLACEMENT=1
PLACEMENT=favored

Now the BDTO RAC One Node database:

  • will be re-started automatically on node bdtnode1 in case the “preferred” node bdtnode2 crash.
  • will be re-started and relocated automatically on the “preferred” node bdtnode2 as soon as it will be again available.

Remarks:

Be careful: The database will be relocated automatically on the “preferred” node as soon as it is up (Even if the database is currently running on other node).

If you try to relocate manually the database on the “non preferred” node:

srvctl relocate database -d BDTO -n bdtnode1

It will be done and the node bdtnode1 will be again member of the server pool (as a consequence the node “bdtnode2” is not anymore the “preferred” one).

Conclusion: You have the choice,

  • Stick the database to one node so that it does not relocate automatically on surviving nodes (This post).
  • Defined a “preferred” node and allow the database to relocate automatically on surviving nodes and on the “preferred” node as soon as it is available (The current post).
Advertisement

Rac One Node : Avoid automatic database relocation

Imagine you need to ensure that one of your many RAC One Node database:

  1. Should re-start automatically on the current node in case of database or node crash.
  2. Does not relocate automatically on other nodes.

So, you need somehow to “stick” this particular RAC One Node database to one node of your cluster.

For a good understanding of what RAC One Node is, you can have a look to Martin’s post.

Disabling the database will not help as it will not satisfy the second point mentioned above.

To answer this need, I’ll modify one property of the database’s server pool (database is administrator managed):

To which pool belongs the db ?

crsctl status resource ora.BDTO.db -p | grep -i pool 
SERVER_POOLS=ora.BDTO

Which servers are part of this pool ?

crsctl status serverpool ora.BDTO -p | grep -i server
SERVER_NAMES=bdtnode1 bdtnode2

Modify the server pool to “stick” the database to one node (bdtnode2 for example):

crsctl modify serverpool ora.BDTO -attr SERVER_NAMES="bdtnode2"
crsctl status serverpool ora.BDTO -p | grep -i server
SERVER_NAMES=bdtnode2

Now the BDTO RAC One Node database:

  • will not be re-started automatically on node bdtnode1 in case bdtnode2 crash.
  • will be re-started automatically on node bdtnode2 as soon as it will be again available.

Remarks:

  1. If the server pool “host” many databases, all of them will be affected by the change.
  2. If you try to relocate manually the database on the “excluded” node:
srvctl relocate database -d BDTO -n bdtnode1

It will be done and the “excluded” bdtnode1 will be again member of the server pool (as a consequence the database is not sticked to bdtnode2 anymore).

If you need another behaviour (create a preferred node), then you have to change the PLACEMENT attribute of the database (see this post).

Conclusion: The purpose of this post is not to explain why you could choose to stick one RAC One Node database to a particular node of your cluster, it just provide a way to do so 🙂