This content has been marked as final. Show 3 replies
I have not tried it myself, but if you look at the crs profile on how SCANs are defined, they are set to DISPERSION.
So they should not/never run on the same node, since the dispersion policy tells them differently.
# crsctl stat res ora.scan1.vip -p NAME=ora.scan1.vip TYPE=ora.scan_vip.type ... START_DEPENDENCIES=hard(ora.net1.network) dispersion:active(type:ora.scan_vip.type) pullup(ora.net1.network) ...
However this dependency is checked at startup time, and not always during runtime. So if you do a lot of test, your szenario is possible.
Have you tried waiting a while, if this resolves the issue?
If they stay on the same node, I would open an SR, because then it does not follow the dispersion policy.
It eventually redistributed to run on both nodes (we are running 2 node RAC). But the situation that all 3 SCAN IP running on the same node has persisted over 2 days.
We have started and stopped DB instances after that. Can registration / deregistration cause them to jump around?
Also, are they supposed to jump around after normal database connection?
no SCANs will only move with clusterware up and down (they run from Grid Infrastruktur).
Self registration of the database has no effect on the SCAN itself (other than that the SCAN knows the database).
You can start and stop a SCAN VIP, that will have the effect that after the start the SCAN VIP will move to another server.