CRS-0184问题解决过程

近日,公司搭建的ORACLE 11G RAC 出现故障,整个故障的排错思路大概持续了一周左右,最终确定了问题原因,现在简介下ORACLE 11G RAC的环境:

jbdb1 IBM P740  AIX 6100-08-02-1316

jbdb2 IBM P740  AIX 6100-08-02-1316

Oracle 11G 11.2.0.3 grid and database

当日,软件人员说无法连接数据库,我就很纳闷,于是就登录到系统,通过查看群集发现整个RAC有异常,正当我查看群集状态时候出现:

hostname:/home/grid$crs_stat -t
CRS-0184: Cannot communicate with the CRS daemon.

通过登录两个节点发现同样的问题,ORACLE Cluster 无法启动crs群集管理,crs无法启动更谈不上什么服务了,数据库无法启动,服务中断。
    现在是没有什么办法只有先恢复应用再说,于是手动执行crsctl start cluster -all 结果还是不能启动crs对应的服务,错误依旧。最后进行crs的检测

hostname:/home/grid$crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4534: Cannot communicate with Event Manager

通过上面可以看到CRS无法通信,并且事件管理也无法通信连接。并且查询crs resource运行状态

节点1:

hostname:/home/grid$crsctl stat resource -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
      1        ONLINE  OFFLINE                               Instance Shutdown   
ora.cluster_interconnect.haip
      1        ONLINE  ONLINE       jbdb1                                        
ora.crf
      1        ONLINE  ONLINE       jbdb1                                        
ora.crsd
      1        ONLINE  OFFLINE                                                   
ora.cssd
      1        ONLINE  ONLINE       jbdb1                                        
ora.cssdmonitor
      1        ONLINE  ONLINE       jbdb1                                        
ora.ctssd
      1        ONLINE  ONLINE       jbdb1                    OBSERVER            
ora.diskmon
      1        OFFLINE OFFLINE                                                   
ora.drivers.acfs
      1        ONLINE  ONLINE       jbdb1                                        
ora.evmd
      1        ONLINE  INTERMEDIATE jbdb1                                        
ora.gipcd
      1        ONLINE  ONLINE       jbdb1                                        
ora.gpnpd
      1        ONLINE  ONLINE       jbdb1                                        
ora.mdnsd
      1        ONLINE  ONLINE       jbdb1   
  
  hostname:/home/grid$crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4534: Cannot communicate with Event Manager

节点2
hostname:/home/grid$crsctl stat resource -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
      1        ONLINE  ONLINE       jbdb2                    Started             
ora.cluster_interconnect.haip
      1        ONLINE  ONLINE       jbdb2                                        
ora.crf
      1        ONLINE  ONLINE       jbdb2                                        
ora.crsd
      1        ONLINE  INTERMEDIATE jbdb2                                        
ora.cssd
      1        ONLINE  ONLINE       jbdb2                                        
ora.cssdmonitor
      1        ONLINE  ONLINE       jbdb2                                        
ora.ctssd
      1        ONLINE  ONLINE       jbdb2                    OBSERVER            
ora.diskmon
      1        OFFLINE OFFLINE                                                   
ora.drivers.acfs
      1        ONLINE  ONLINE       jbdb2                                        
ora.evmd
      1        ONLINE  INTERMEDIATE jbdb2                                        
ora.gipcd
      1        ONLINE  ONLINE       jbdb2                                        
ora.gpnpd
      1        ONLINE  ONLINE       jbdb2                                        
ora.mdnsd
      1        ONLINE  ONLINE       jbdb2             
	  
hostname:/home/grid$crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4534: Cannot communicate with Event Manager

通过上面信息可知节点1的ora.asm offline,ora.crsd offline 同时也会伴随asm后台无法启动

节点2ora.crsd INTERMEDIATE,在整个排查过程中,尝试过重启两节点,但是重启完毕后,crs的状态还是一样的,数据库不可使用。被迫无奈判断问题,于是大胆关闭一个节点,同时喜剧的时刻发生了,节点2上是应用资源都正常,所有群集资源漂移至节点2上,包括底层的ASM还有数据库instance状态可用。

hostname:/home/grid$crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora.DATA.dg    ora....up.type ONLINE    ONLINE    jbdb2       
ora....BASE.dg ora....up.type ONLINE    ONLINE    jbdb2       
ora....ER.lsnr ora....er.type ONLINE    ONLINE    jbdb2       
ora....N1.lsnr ora....er.type ONLINE    ONLINE    jbdb2       
ora.asm        ora.asm.type   ONLINE    ONLINE    jbdb2       
ora.cvu        ora.cvu.type   ONLINE    ONLINE    jbdb2       
ora.gsd        ora.gsd.type   OFFLINE   OFFLINE               
ora.jbdb.db    ora....se.type ONLINE    ONLINE    jbdb2       
ora.jbdb1.vip  ora....t1.type ONLINE    ONLINE    jbdb2       
ora....SM2.asm application    ONLINE    ONLINE    jbdb2       
ora....B2.lsnr application    ONLINE    ONLINE    jbdb2       
ora.jbdb2.gsd  application    OFFLINE   OFFLINE               
ora.jbdb2.ons  application    ONLINE    ONLINE    jbdb2       
ora.jbdb2.vip  ora....t1.type ONLINE    ONLINE    jbdb2       
ora....network ora....rk.type ONLINE    ONLINE    jbdb2       
ora.oc4j       ora.oc4j.type  ONLINE    ONLINE    jbdb2       
ora.ons        ora.ons.type   ONLINE    ONLINE    jbdb2       
ora....ry.acfs ora....fs.type ONLINE    ONLINE    jbdb2       
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    jbdb2

没有办法后来查看crsd.log日志,在节点1上看到如下日志:

2015-01-11 13:09:49.196: [UiServer][12338] {1:55097:16132} Done for ctx=126cef9b0
2015-01-11 13:09:51.152: [GIPCHALO][2314] gipchaLowerDropMsg: dropping because of sequence timeout, waited 30009, msg 126d68dd8 { len 1160, seq 4382378, type gipchaHdrTypeRecvEstablish (5), lastSeq 0, lastAck 0, minAck 4382377, flags 0x1, srcLuid a0a5bfd0-2d6a5e20, dstLuid 00000000-00000000, msgId 4382376 }, node 126ceeb10 { host ‘jbdb2‘, haName ‘100e-6e24-76d3-7ed0‘, srcLuid 2a58b1e0-aa5c4864, dstLuid a0a5bfd0-2d6a5e20 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [79 : 79], createTime 2789741483, sentRegister 1, localMonitor 0, flags 0x4 }
2015-01-11 13:09:51.898: [GIPCHALO][2314] gipchaLowerProcessNode: no valid interfaces found to node for 2789821594 ms, node 126ceeb10 { host ‘jbdb2‘, haName ‘100e-6e24-76d3-7ed0‘, srcLuid 2a58b1e0-aa5c4864, dstLuid a0a5bfd0-2d6a5e20 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [80 : 80], createTime 2789741483, sentRegister 1, localMonitor 0, flags 0x4 }
2015-01-11 13:09:52.160: [GIPCHALO][2314] gipchaLowerDropMsg: dropping because of sequence timeout, waited 30008, msg 126da6958 { len 1160, seq 4382379, type gipchaHdrTypeRecvEstablish (5), lastSeq 0, lastAck 0, minAck 4382378, flags 0x1, srcLuid a0a5bfd0-2d6a5e20, dstLuid 00000000-00000000, msgId 4382377 }, node 126ceeb10 { host ‘jbdb2‘, haName ‘100e-6e24-76d3-7ed0‘, srcLuid 2a58b1e0-aa5c4864, dstLuid a0a5bfd0-2d6a5e20 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [80 : 80], createTime 2789741483, sentRegister 1, localMonitor 0, flags 0x4 }
2015-01-11 13:09:53.167: [GIPCHALO][2314] gipchaLowerDropMsg: dropping because of sequence timeout, waited 30009, msg 126d6b678 { len 1160, seq 4382380, type gipchaHdrTypeRecvEstablish (5), lastSeq 0, lastAck 0, minAck 4382379, flags 0x1, srcLuid a0a5bfd0-2d6a5e20, dstLuid 00000000-00000000, msgId 4382378 }, node 126ceeb10 { host ‘jbdb2‘, haName ‘100e-6e24-76d3-7ed0‘, srcLuid 2a58b1e0-aa5c4864, dstLuid a0a5bfd0-2d6a5e20 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [81 : 81], createTime 2789741483, sentRegister 1, localMonitor 0, flags 0x4 }
2015-01-11 13:09:54.173: [GIPCHALO][2314] gipchaLowerDropMsg: dropping because of sequence timeout, waited 30007, msg 126da91f8 { len 1160, seq 4382381, type gipchaHdrTypeRecvEstablish (5), lastSeq 0, lastAck 0, minAck 4382380, flags 0x1, srcLuid a0a5bfd0-2d6a5e20, dstLuid 00000000-00000000, msgId 4382379 }, node 126ceeb10 { host ‘jbdb2‘, haName ‘100e-6e24-76d3-7ed0‘, srcLuid 2a58b1e0-aa5c4864, dstLuid a0a5bfd0-2d6a5e20 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [82 : 82], createTime 2789741483, sentRegister 1, localMonitor 0, flags 0x4 }
2015-01-11 13:09:56.188: [GIPCHALO][2314] gipchaLowerDropMsg: dropping because of sequence timeout, waited 30008, msg 126d5cd18 { len 1160, seq 4382383, type gipchaHdrTypeRecvEstablish (5), lastSeq 0, lastAck 0, minAck 4382382, flags 0x1, srcLuid a0a5bfd0-2d6a5e20, dstLuid 00000000-00000000, msgId 4382381 }, node 126ceeb10 { host ‘jbdb2‘, haName ‘100e-6e24-76d3-7ed0‘, srcLuid 2a58b1e0-aa5c4864, dstLuid a0a5bfd0-2d6a5e20 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [84 : 84], createTime 2789741483, sentRegister 1, localMonitor 0, flags 0x4 }

通过上面日志发现“gipchaLowerProcessNode: no valid interfaces found to node for 2789821594 ms”信息,通过字面理解应该是群集心跳出现问题,可以在节点1和节点2上通过ping测试发现没有异常,于是就没有在意,反而把重点放在操作系统层面,就这样一连5天都是这样熬着,在这几天我尝试各种解决办法,操作系统层面,存储多路径、系统补丁、数据库bug均是无效,问题依旧,双节点同时启动RAC不可用,关闭一个节点后所有资源漂移正常,并且crs也正常,在这样一次次尝试我发现,存储层面和系统层面应该没有问题,否则所有资源是不会在一个节点上运行,这样问题应该出现在群集本身。定位问题后,就测试RAC的心跳通信。

ping 192.168.10.254 -t
正在 Ping 192.168.10.254 具有 32 字节的数据:
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=3ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=3ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
来自 192.168.10.254 的回复: 字节=32 时间=1ms TTL=255
192.168.10.254 的 Ping 统计信息:
    数据包: 已发送 = 12,已接收 = 8,丢失 =4 (33% 丢失),
往返行程的估计时间(以毫秒为单位):
    最短 = 1ms,最长 = 3ms,平均 = 1ms

通过上面的测试发现有数据包丢失虽然心跳地址任然通信,会不会RAC通过测定数据包丢失而判断心跳失效,从而发生类似“脑裂”的问题,结合crsd.log中gipchaLowerProcessNode: no valid interfaces found to node for 2789821594 ms”,通过上面信息判断问题出现在RAC心跳上,于是想利用独立交换机接入节点1、2的心跳网卡,通过这个操作,奇迹发送了,节点1、2的crs尽然启动了,群集资源也没有异常,可以查看crsd.log日志如下:

hostname:/grid/app/11.2/grid/log/jbdb2/crsd$tail -n 100 crsd.log
2015-01-15 17:19:06.666: [UiServer][11568] {2:24121:114} Done for ctx=11236f630
2015-01-15 17:19:20.233: [UiServer][11825] CS(11237a810)set Properties ( grid,11238c390)
2015-01-15 17:19:20.244: [UiServer][11568] {2:24121:115} Sending message to PE. ctx= 112004170
2015-01-15 17:19:20.300: [UiServer][11568] {2:24121:115} Done for ctx=112004170
2015-01-15 17:19:42.929: [    AGFW][10026] {2:24121:2} Received the reply to the message: RESOURCE_START[ora.jbdb.db 2 1] ID 4098:323 from the agent /grid/app/11.2/grid/bin/oraagent_oracle
2015-01-15 17:19:42.930: [    AGFW][10026] {2:24121:2} Agfw Proxy Server sending the reply to PE for message:RESOURCE_START[ora.jbdb.db 2 1] ID 4098:881
2015-01-15 17:19:42.932: [    AGFW][10026] {2:24121:2} Received the reply to the message: RESOURCE_START[ora.jbdb.db 2 1] ID 4098:323 from the agent /grid/app/11.2/grid/bin/oraagent_oracle
2015-01-15 17:19:42.933: [    AGFW][10026] {2:24121:2} Agfw Proxy Server sending the last reply to PE for message:RESOURCE_START[ora.jbdb.db 2 1] ID 4098:881
2015-01-15 17:19:42.946: [UiServer][11568] {2:24121:97} Container [ Name: ORDER
        MESSAGE: 
        TextMessage[CRS-5702: Resource ‘ora.jbdb.db‘ is already running on ‘jbdb2‘]
        MSGTYPE: 
        TextMessage[1]
        OBJID: 
        TextMessage[ora.jbdb.db 2 1]
        WAIT: 
        TextMessage[0]
]
2015-01-15 17:19:42.946: [ COMMCRS][11568]clscsendx: (11237cbb0) Connection not active
hostname:/grid/app/11.2/grid/log/jbdb2/crsd$crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora.DATA.dg    ora....up.type ONLINE    ONLINE    jbdb1       
ora....BASE.dg ora....up.type ONLINE    ONLINE    jbdb1       
ora....ER.lsnr ora....er.type ONLINE    ONLINE    jbdb1       
ora....N1.lsnr ora....er.type ONLINE    ONLINE    jbdb1       
ora.asm        ora.asm.type   ONLINE    ONLINE    jbdb1       
ora.cvu        ora.cvu.type   ONLINE    ONLINE    jbdb1       
ora.gsd        ora.gsd.type   OFFLINE   OFFLINE               
ora.jbdb.db    ora....se.type ONLINE    ONLINE    jbdb1       
ora....SM1.asm application    ONLINE    ONLINE    jbdb1       
ora....B1.lsnr application    ONLINE    ONLINE    jbdb1       
ora.jbdb1.gsd  application    OFFLINE   OFFLINE               
ora.jbdb1.ons  application    ONLINE    ONLINE    jbdb1       
ora.jbdb1.vip  ora....t1.type ONLINE    ONLINE    jbdb1       
ora....SM2.asm application    ONLINE    ONLINE    jbdb2       
ora....B2.lsnr application    ONLINE    ONLINE    jbdb2       
ora.jbdb2.gsd  application    OFFLINE   OFFLINE               
ora.jbdb2.ons  application    ONLINE    ONLINE    jbdb2       
ora.jbdb2.vip  ora....t1.type ONLINE    ONLINE    jbdb2       
ora....network ora....rk.type ONLINE    ONLINE    jbdb1       
ora.oc4j       ora.oc4j.type  ONLINE    ONLINE    jbdb1       
ora.ons        ora.ons.type   ONLINE    ONLINE    jbdb1       
ora....ry.acfs ora....fs.type ONLINE    ONLINE    jbdb1       
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    jbdb1 
hostname:/grid/app/11.2/grid/log/jbdb2/crsd$crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
      1        ONLINE  ONLINE       jbdb2                    Started             
ora.cluster_interconnect.haip
      1        ONLINE  ONLINE       jbdb2                                        
ora.crf
      1        ONLINE  ONLINE       jbdb2                                        
ora.crsd
      1        ONLINE  ONLINE       jbdb2                                        
ora.cssd
      1        ONLINE  ONLINE       jbdb2                                        
ora.cssdmonitor
      1        ONLINE  ONLINE       jbdb2                                        
ora.ctssd
      1        ONLINE  ONLINE       jbdb2                    OBSERVER            
ora.diskmon
      1        OFFLINE OFFLINE                                                   
ora.drivers.acfs
      1        ONLINE  ONLINE       jbdb2                                        
ora.evmd
      1        ONLINE  ONLINE       jbdb2                                        
ora.gipcd
      1        ONLINE  ONLINE       jbdb2                                        
ora.gpnpd
      1        ONLINE  ONLINE       jbdb2                                        
ora.mdnsd
      1        ONLINE  ONLINE       jbdb2  
hostname:/grid/app/11.2/grid/log/jbdb1/crsd$tail -n 100 crsd.log
2015-01-15 17:19:18.657: [   CRSPE][12082] {2:24121:115} Processing PE command id=157. Description: [Stat Resource : 112df6db0]
2015-01-15 17:19:41.343: [   CRSPE][12082] {2:24121:2} Received reply to action [Start] message ID: 881
2015-01-15 17:19:41.346: [   CRSPE][12082] {2:24121:2} Received reply to action [Start] message ID: 881
2015-01-15 17:19:41.346: [   CRSPE][12082] {2:24121:2} RI [ora.jbdb.db 2 1] new internal state: [STABLE] old value: [STARTING]
2015-01-15 17:19:41.346: [   CRSPE][12082] {2:24121:2} RI [ora.jbdb.db 2 1] new external state [ONLINE] old value: [OFFLINE] on jbdb2 label = [Open] 
2015-01-15 17:19:41.346: [   CRSPE][12082] {2:24121:2} Set State Details to [Open] from [ ] for [ora.jbdb.db 2 1]
2015-01-15 17:19:41.347: [   CRSPE][12082] {2:24121:2} CRS-2676: Start of ‘ora.jbdb.db‘ on ‘jbdb2‘ succeeded
2015-01-15 17:19:41.351: [  CRSRPT][12339] {2:24121:2} Published to EVM CRS_RESOURCE_STATE_CHANGE for ora.jbdb.db
2015-01-15 17:19:41.353: [   CRSPE][12082] {2:24121:97} Re-evaluation of queued op [START of [ora.jbdb.db 2 1] on [jbdb2] : local=0, unplanned=0114e51c50]. found it no longer needed:CRS-5702: Resource ‘ora.jbdb.db‘ is already running on ‘jbdb2‘
. Finishing the op.
2015-01-15 17:19:41.354: [   CRSPE][12082] {2:24121:97} PE Command [ Start Resource : 11200d6d0 ] has completed
2015-01-15 17:19:41.354: [   CRSPE][12082] {2:24121:97} UI Command [Start Resource : 11200d6d0] is replying to sender. 
2015-01-15 17:19:41.357: [   CRSPE][12082] {2:24121:97} PE Command [ Server Join: Resource Startup {jbdb2 } : 11211a670 ] has completed
2015-01-15 17:19:41.357: [    AGFW][10797] {2:24121:97} Agfw Proxy Server received the message: CMD_COMPLETED[Proxy] ID 20482:930
2015-01-15 17:19:41.358: [    AGFW][10797] {2:24121:97} Agfw Proxy Server replying to the message: CMD_COMPLETED[Proxy] ID 20482:930
2015-01-15 17:19:41.358: [   CRSPE][12082] {2:24121:97} Updated state details for server jbdb2from [AUTOSTARTING RESOURCES] to : []
2015-01-15 17:19:41.358: [  CRSOCR][11054] {2:24121:97} Multi Write Batch processing...
2015-01-15 17:19:41.360: [  CRSRPT][12339] {2:24121:97} Published to EVM CRS_SERVER_STATE_CHANGE for jbdb2
2015-01-15 17:19:41.364: [  CRSOCR][11054] {2:24121:97} Multi Write Batch done.
2015-01-15 17:19:41.364: [   CRSPE][12082] {2:24121:97} Resource Autostart completed for jbdb2
2015-01-15 17:19:41.506: [   CRSPE][12082] {2:24121:116} Processing PE command id=158. Description: [Stat Resource : 1118a75b0]
2015-01-15 17:19:41.841: [   CRSPE][12082] {2:24121:117} Processing PE command id=159. Description: [Stat Resource : 11200c5b0]
2015-01-15 17:19:42.080: [   CRSPE][12082] {2:24121:118} Processing PE command id=160. Description: [Stat Resource : 1118a75b0]
2015-01-15 17:21:40.306: [UiServer][12596] CS(11200c570)set Properties ( root,11200def0)

通过上面的日志和crs的状态,发现群集资源已经恢复,并且资源启动,数据库的状态及实例的状态、ASM等都运行正常,最终通过排查是RAC小型机的心跳网线配线架出现问题,导致心跳丢包,待所有问题解决后,长长舒了口气,终于可以睡个安心觉了。

时间: 2024-08-01 16:30:16

CRS-0184问题解决过程的相关文章

CrossApp 0.3.1示例编译问题解决过程

1 AlertTest.h找不到 问题成因:HelloCpp工程中头文件搜索路径没有增加Classes目录,需要自己加进去.(另外由于这些文件都是在子目录中,用递归模式也行,逐个子目录添加也行) 2 CrossApp lib编译错误. (1) Unknown register name 'q0' in asm 按照网上说法,把对应的#if defined(__ARM_NEON__)替换成 #if defined(_ARM_ARCH_7)即可. (2) "Cast from pointer to

记录sqoop同步失败问题解决过程,过程真的是很崎岖。(1月6日解决)

记录sqoop同步失败问题解决过程,过程真的是很崎岖.事发原因:最近突然出现sqoop export to mysql时频繁出错.看了下日志是卡在某条数据过不去了,看异常.看sqoop生成的mr并未发现问题.最后把要export的原始数据拿notepad++打开发现中断的数据是奇怪的乱码,查了一下是二进制的数据. 乱码数据生成原因:我理解,api接口时接收流数据时长度和实际长度不符. 解决办法:两块要解决,一是接口时做好容错,二是同步时还是要对这种二进制做兼容,因为谁也无法保证二进制数据不会再出

局域网上网问题解决过程

前几天局域网改了ip之后就突然不能上网,以为是ip冲突,于是又换一个,这样换了n个,依然上不了,每次都是改了以后显示已连接,数秒之后显示受限,以为是网卡驱动的原因,卸了装卸了又装,重复n遍之后木有任何效果.后来又以为是硬件原因,ping了局域网中其它机器的ip,能ping通,这说明网卡应该还是可以收发数据应该没坏的,但为什么就是不能上网呢?启动windows自带的问题诊断,显示dns未响应,(后来发现,这尼玛坑啊太多原因能导致这个结果了),于是乎又开始查看dns服务有没有启动,又换了几个常用dn

一个测试问题解决过程

邮件提醒来了一个测试问题需要我分派,文本框输入a:b:c(业务需要,内容以英文冒号分隔),"系统提示xxx格式不规范,系统未将全角:转换为半角.",我看完未过多细想,flex前端没做过,易用性问题,直接分派给功能开发人员小王同学,接下来发生了一些事情. 小王开始抱怨,有病啊,没事开什么全角输入,怎么测试呢-: 小王找我这问题不改了,让把问题打回,有一个理由控制BUG数量: 咋一看,小王说的有道理啊,琢磨了一下,不对啊,(情绪上不能对立,测试也是为了产品质量)测试不至于这么测吧,问题里说

shiro realm 注解失败问题解决过程

做为一名在.net混了八九年的老兵油子,转战java时间并不长,刚开始做项目完全是凭借对C#的认识来做,虽然遇到一些问题,但实际结果显示C#在语言上和java还是有很大相似度,而且微软的MVC与Spring MVC也是那么的神似,这也是为什么我在做项目前并未对java进行系统的学习也能做项目的原因.最近稍微有些空闲时间,所以决定从基础开始系统的学习java,这里并没有太多高深技术可分享的,本篇给大家分享我解决问题的一个经验:触类旁通或者叫举一反三,对了还有一点,对于存在可优化点的部分要不轻言放弃

一次网站停止访问的问题解决过程,原因令人崩溃

最近对单位网站进行了改版,在本机和测试服务器测试了很久都没有问题,于是今天就部署到服务器上线了.同时.net framework版本由2.0升级到4.0.部署完测试了一下,没问题,就放出来了.一公布,大家纷纷点击.不一会儿,有人报告说访问不了了.一试,果然.大家赶紧到服务器查看,没发现什么异常.过了一会又好了.正当大家莫名奇妙时,又访问不了了,大家首先判断是不是程序池满了,但是很快发现同一个服务器上的其他网站也打不开,这些网站并不是同一个程序池.然后在服务器上访问了一下,可以打开.又利用其他ip

Exchange 2013诡异问题解决过程分享

一.问题现象 我现在遇到一个问题,我的环境情况是:WIndows  server 2012 R2 + Exchange 2013 CU12(CAS使用NLB,Mailbox使用DAG)环境.我在外网用户使用Outlook 2013 配置Outlook Anywhere模式,在发送邮件过程中经常出现很久才能发送,发送到邮件一直保留在发件箱中.在客户端等待30分钟以上后邮件才能自动发出去,或者重启OUtlook也可将邮件发送出去.在计算机客户端的应用系统日志里面有Event ID Outlook 2

[mysql]一次主从数据不一致的问题解决过程

之前一篇: 主从更换ip之后重新建立同步 情况时这样的 昨天晚上主动2个机器都迁移了,然后今天才把主动重新连接上,但是从库的偏移量是从今天当前时刻开始的,也就是说虽然现在主动看似正常,其实是少了昨天的部分数据,由于从库的数据丢失了,早晚还是要填坑的. 问题 要解决问题就是怎么对比不一致,然后在不影响业务的情况下,修复数据不一致的问题,把从库缺少的数据补上 下面是能想到和找到的几个方案 1 从新从0开始同步,虽然对主库的使用没有影响,但是那么大的数据量,对性能,网络影响有点大,数据丢失的应该很少

red hat安装docker报依赖要求container-selinux>2.9问题解决过程

redhat版本号:Red Hat Enterprise Linux Server release 7.5 (Maipo)安装过程:1.移除旧版本:$ sudo yum remove docker \docker-client \docker-client-latest \docker-common \docker-latest \docker-latest-logrotate \docker-logrotate \docker-selinux \docker-engine-selinux \d