vip/public ip断网，导致instance crash-CSDN博客

Oracle 10.2.0.1 HP-UX 11.31 ia64

alert.log:

Mon Dec 26 14:11:16 2011
Shutting down instance (abort)
License high water mark = 486
Instance terminated by USER, pid = 1675
syslog:
Dec 26 14:10:14 wandadb1 cmnetd[29338]: lan0 is down at the data link layer.
Dec 26 14:10:14 wandadb1 cmnetd[29338]: lan0 failed.
Dec 26 14:10:14 wandadb1 cmnetd[29338]: Subnet 10.0.4.0 down
Dec 26 14:10:36 wandadb1 cmnetd[29338]: lan0 is up at the data link layer.
Dec 26 14:10:36 wandadb1 cmnetd[29338]: lan0 recovered.
Dec 26 14:10:36 wandadb1 cmnetd[29338]: Subnet 10.0.4.0 up
Dec 26 14:10:42 wandadb1 cmnetd[29338]: 10.0.4.161 failed.
Dec 26 14:10:42 wandadb1 cmnetd[29338]: lan0 is down at the IP layer.
Dec 26 14:10:42 wandadb1 cmnetd[29338]: lan0 failed.
Dec 26 14:10:42 wandadb1 cmnetd[29338]: Subnet 10.0.4.0 down
Dec 26 14:10:56 wandadb1 cmnetd[29338]: lan0 is down at the data link layer.
Dec 26 14:11:58 wandadb1 cmnetd[29338]: lan0 is up at the data link layer.
Dec 26 14:11:58 wandadb1 cmnetd[29338]: lan0 is still down at the IP layer.
Dec 26 14:12:04 wandadb1 cmnetd[29338]: 10.0.4.161 recovered.
Dec 26 14:12:04 wandadb1 cmnetd[29338]: Subnet 10.0.4.0 up
Dec 26 14:12:04 wandadb1 cmnetd[29338]: lan0 is up at the IP layer.
Dec 26 14:12:04 wandadb1 cmnetd[29338]: lan0 recovered.

crsd.log
2011-12-26 14:11:08.785: [ CRSAPP][4060] CheckResource error for ora.wandadb1.vip error code = 1
2011-12-26 14:11:08.792: [ CRSRES][4060] In stateChanged, ora.wandadb1.vip target is ONLINE
2011-12-26 14:11:08.793: [ CRSRES][4060] ora.wandadb1.vip on wandadb1 went OFFLINE unexpectedly
2011-12-26 14:11:08.793: [ CRSRES][4060] StopResource: setting CLI values
2011-12-26 14:11:08.817: [ CRSRES][4060] Attempting to stop `ora.wandadb1.vip` on member `wandadb1`
2011-12-26 14:11:09.348: [ CRSRES][4060] Stop of `ora.wandadb1.vip` on member `wandadb1` succeeded.
2011-12-26 14:11:09.349: [ CRSRES][4060] ora.wandadb1.vip RESTART_COUNT=0 RESTART_ATTEMPTS=0
2011-12-26 14:11:09.357: [ CRSRES][4060] ora.wandadb1.vip failed on wandadb1 relocating.
2011-12-26 14:11:09.455: [ CRSRES][4060] StopResource: setting CLI values
2011-12-26 14:11:09.458: [ CRSRES][4060] Attempting to stop `ora.wandadb1.LISTENER_WANDADB1.lsnr` on member `wandadb1`
2011-12-26 14:11:09.680: [ OCRSRV][29]th_select_handler: Failed to retrieve procctx from ht. constr = [44541328] retval lht [-27] Signal CV.
2011-12-26 14:11:10.040: [ CRSRES][4060] Stop of `ora.wandadb1.LISTENER_WANDADB1.lsnr` on member `wandadb1` succeeded.
2011-12-26 14:11:10.041: [ CRSRES][4060] StopResource: setting CLI values
2011-12-26 14:11:10.047: [ CRSRES][4060] Attempting to stop `ora.ufsa8.ufsa81.inst` on member `wandadb1`
2011-12-26 14:11:24.934: [ CRSRES][4060] Stop of `ora.ufsa8.ufsa81.inst` on member `wandadb1` succeeded.

Should the Database Instance Be Brought Down after VIP service crashes? [ID 391454.1]

[@more@]

Should the Database Instance Be Brought Down after VIP service crashes? [ID 391454.1]

		修改时间 29-JUL-2010 类型 HOWTO 状态 ARCHIVED

In this Document
Goal
Solution
References

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.2 - Release: 10.1 to 10.2
Information in this document applies to any platform.

Goal

Should a RAC database instance be taken down by CRS when the VIP service is brought down for whatever reason?
Is there a way to prevent it?

Solution

Yes, this is the expected behaviour, until Oracle release 10.2.0.3, when this dependency was removed (see MetaLink Note:401783.1 for details).
There is a dependency between the VIP and the database instance.
Checking a database instance service with crs_stat, it can be seen that the VIP is a required resource:

[CLUSTERWARE]> crs_stat -p ora.RACD.RACD1.inst
NAME=ora.RACD.RACD1.inst
...
DESCRIPTION=CRS application for Instance
FAILOVER_DELAY=0
FAILURE_INTERVAL=0
FAILURE_THRESHOLD=0
HOSTING_MEMBERS=raclnxd1
OPTIONAL_RESOURCES=
PLACEMENT=restricted
REQUIRED_RESOURCES=ora.raclnxd1.vip
This dependency cannot be removed.
The only exception that exists is between the VIP and the ASM instance. This dependency can be supportedly removed.
The dependency between the DB instance and the VIP must stay in place.

The ASM/DB instance dependency on VIP has been removed (effective 11.0 and 10.2.0.3.0, see MetaLink Note:401783.1 for details).