Oracle CRS 10.2.0.3 patchset brings long awaited removal of previously required dependencies of databases and ASM instances on a VIP. Actually, 10.2.0.2 patchset lifted the requirement for dependency between ASM instance and VIP but not for database instances. In 10.2.0.2 this dependency wasn’t removed by default.
For those who don’t know that – in case public interface(s) fail(s) (or whatever the case when VIP failure detected) and VIP relocated to another node, CRS shutdowns ASM instance and ALL database instance on the node with failed VIP. When I was working for another good company, we had a lengthy argument with Oracle about supported way of removal for this dependency – there is a way to remove it manually but this wasn’t supported and, particularly, FAN (Fast Application Notification) functionality was not guarantied to work properly in this case.
There are several reasons why one wouldn’t want to have database and ASM instances to be dependent on the VIP.
Several interfaces
There might be more than single interface used to connect to the database instances by different applications. VIP failover followed by shutdown of all database instances would terminate all services even though they might still be available over other interfaces. Large data-centers often have dedicated networks for certain types of traffic and/or different applications.
Recovery time
It takes time to start ASM and database instances back when VIP is returned to its original node. Recovery from network failure would take only few seconds without shutting ASM and database instances down.
Non-RAC database hosted on the same cluster
You wouldn’t want to use VIP to connect to a non-RAC database anyway and wouldn’t want this database to go down on VIP failure.
I hope Oracle will come up with multiple VIPs at some point so that we don’t need to poke around with user VIPs to use multiple interfaces.
7 Comments. Leave new
Did it shut down on one error on the VIP, or after a certain amount of errors or time?
As soon as VIP is detected as failed – CRS tries to relocate it to other public interfaces of the “home” node (can be more than one public interface actually) and then moves it to another node. There is no reason to wait. Right? VIPs are there to avoid TCP timeout issue.
in this article, would if the public IP failed will be followed by VIP failed too?
“There are several reasons why one wouldn’t want to have database and ASM instances to be dependent on the VIP.”
the above sentence, could you explain in more details?
thanks
in this article, would if the public IP failed will be followed by VIP failed too?
Yes. if public interface fails than VIP fails as well. However, you should be able to define more than one public interfaces. In this case if one interface fails, CRS will try to move VIP to another public interface. To be honest I never tried it but I think the theory is correct. I might want to try it one day for the sake of it.
“There are several reasons why one wouldn’t want to have database and ASM instances to be dependent on the VIP.â€
the above sentence, could you explain in more details?
Well, I listed some right after that sentence in the sections:
Let me know know if you need clarification on any of them.
PS: I see that we’ve got one more blog on Oracle scene. Welcome! ;-)
Just wanted to know if you have any customers who have removed the dependency of the Database instances on the VIP in 10.1.0.x RAC by doing what is mentioned in
ML note 4865736.8 and have had any issues after doing this
We wanted to do that on one site with 10.1.0.3 (or 4 can’t recall exactly). After long debates with Oracle advanced support group and development they didn’t agree to do that mainly because they were not sure how it would affect FAN functionality even though we didn’t need it there.
We did tested it though and it worked quite well without dependencies. So if you want to run potentially unsupported – that should work.
Another workaround, and that’s what was used in production, is to set CHECK_INTERVAL attribute to 0. This way VIPs are not checked at all and never fail (network was redundant and very reliable there anyway). They still failover on node failure though. I don’t remember if user VIPs are there in 10.1 – they can be used instead of standard VIPs without dependencies. However, there is slight difference in behavior of user VIPs – IIRC, they don’t switch back after failed node becomes available again but this can be handled via server based FAN events, for example.
[…] log files. I am not sure if Oracle supports this. Also check : VIP Dependencies Lifted in Oracle 10.2.0.3 | The Pythian Blog I would suggest to raise SR for the same. Regards Reply With […]