Imagine you need to ensure that one of your many RAC One Node database:
- Should re-start automatically on the current node in case of database or node crash.
- 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.
- If the server pool “host” many databases, all of them will be affected by the change.
- 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 🙂