vip/public ip斷網,導致instance crash
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.
[@more@]
Information in this document applies to any platform.
Is there a way to prevent it?
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).
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] |
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.2Information 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).
References
NOTE:401783.1 - Changes in Oracle Clusterware after applying 10.2.0.3 Patchset來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/19423/viewspace-1056964/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Azure PIP (Instance Level Public IP)
- Oracle RAC修改public, VIP, SCAN IPOracle
- rac 新增第二public ip 和 vip
- Oracle RAC修改public,private,vip scan IPOracle
- Oracle RAC中的Public IP, VIP和Internal IP,SCANOracle
- Latch導致MySQL CrashMySql
- RAC中的各種IP-PUBLIC-VIP-Private-SCAN IP
- How to modify Public ip and vip In 11gr2 Rac
- rac 改public 及vip IP---備份01
- 詭異的事情,RAC,public ip通,vip不通
- 11g RAC 修改PUBLIC-IP、VIP、PRIV-IP、SCAN-IP
- RAC_TNS故障轉移負載均衡、SCAN IP、VIP、PUBLIC IP負載
- fusion-io 卡使用率 100% 導致 Oracle RAC instance crash 問題Oracle
- oracle 10g rac modify public ip,private ip,vip實驗步驟Oracle 10g
- Oracle 12. 2 RAC public IP與vip 互換方法Oracle
- Oracle RAC環境下vip/public/private IP的區別Oracle
- 轉載一個step by step change public-ip and vip on RAC
- Overview of Instance and Crash RecoveryView
- 10g VIP網路卡斷開導致漂移,網路正常後一般如何恢復回去
- 如何定位導致Crash的程式碼位置
- Public Private VIP的區別
- linux start_udev 導致VIP漂移Linuxdev
- 執行SQL語句導致mysqld的crashMySql
- 故障分析 | MySQL : slave_compressed_protocol 導致 crashMySqlProtocol
- 導致IP被封的原因
- 【Oracle】-Difference between Instance recovery and Crash RecoveryOracle
- Rocks 頭結點更改public IP 上網IP地址薦
- rac更改public and private的網路卡和ip
- RAC_網路_VIP漂移_SCAN IP
- 更改VIP、IP
- 系統crash掉導致ORA-00600的處理
- 【MySQL】一條SQL使磁碟暴漲並導致MySQL CrashMySql
- Azure Public IP DNS域名DNS
- win rac public ip 修改
- 修改Public/Interconnect IP
- 網路問題導致更多的資料中心中斷
- 故障分析 | MySQL 5.7 使用臨時表導致資料庫 CrashMySql資料庫
- openGauss 由於RemoveIPC未關閉導致資料庫crashREM資料庫