ITPub博客

首页 > 数据库 > Oracle > 老司机遇到的ORACLE 12C安装问题-技术人生系列第二十五期-我和数据中心的故事

老司机遇到的ORACLE 12C安装问题-技术人生系列第二十五期-我和数据中心的故事

Oracle 作者:记录每一次错误 时间:2018-12-03 14:23:30 0 删除 编辑

编者注:今天我们继续邀请到我们的朋友赫总为我们分享他的技术故事;一个安装问题,我们来看Henry在处理的过程中是如何一步一步定位问题,找出真相,最后帮客户解决问题的。如果是读者你,作为老司机,是不是也有可能经历类似的事情,遇到类似的问题你又会如何解决呢?且看我们的RAC专家Henry的分享。

如果读完文章有所收获,还请帮忙转发,您的转发是我们持续分享的动力。

老司机翻了车

用户现场有 一位经验丰富的 DBA 安装了一套 RAC 系统。前期 GI RDBMS 软件等安装的都非常顺利,但是在使用 DBCA 创建实例的时候出现了错误,折腾了许久,也没有搞定,这才向我们求助;

问题描述如下

我在安装 RAC 系统,在 DBCA 最后一步的时候提示了以下错误:

PRCR-1079 : Failed to start resource ora.xxx.db
CRS-5017: The resource action "ora.xxx.db start" encountered thefollowing error: 
ORA-03113: end-of-file on communication channel
Process ID: 56652
Session ID: 1713 Serial number: 4731
. For details refer to "(:CLSN00107:)" in"/oracle/app/grid/diag/crs/node1 /crs/trace/crsd_oraagent_oracle.trc".
CRS-2674: Start of 'ora.xxx.db' on 'node1' failed
CRS-2632: There are no more servers to try to place resource 'ora.xxx.db' onthat would satisfy its placement policy

配对要“合法”

首先,我们得关注一下问题发生的环境:

OS平台: Linux X-86—64 Red Hat Enterprise 7

数据库版本: 企业版 12.2.0.1

OS 的版本和 DB 的版本都比较新,我们就不得不怀疑ORACLE的版本是不是没有在对应的操作系统上根本没有认证;那我们检查一下,在MOS系统中到“ Certification ”栏,然后输入DB和OS的版本进行查询


Search 结果如下:


看来人家的结合是领过证的,合法的!那就继续吧;

日志要分析

既然是DBCA出现了问题,我们可以看看alert日志了;分别打开两个节点的日志,节点二上DB的日志,看起来一切正常,而且节点二实例状态已经是open状态,那么问题就集中在节点一上了,节点一上DB的日志里提示如下错误:

2017-06-05T15:35:06.561357+08:00

Starting ORACLE instance (normal) (OS id: 47573)

.....

NOTE: remote asm mode is remote (mode 0x2; from cluster type)

2017-06-05T15:35:07.774215+08:00

Cluster Communication is configured to use IPs from: GPnP

IP: 169.254.30.247 Subnet: 169.254.0.0

IP: 169.254.142.159 Subnet: 169.254.128.0

KSIPC Loopback IP addresses(OSD): 

127.0.0.1 

KSIPC Available Transports: UDP:TCP

KSIPC: Client: KCL Transport: UDP

KSIPC: Client: DLM Transport: UDP

KSIPC CAPABILITIES :IPCLW:GRPAM:TOPO:DLL

KSXP: ksxpsg_ipclwtrans: 2 UDP

cluster interconnect IPC version: [IPCLW over UDP(mode 3) ]

IPC Vendor 1 proto 2

Oracle instance running with ODM: Oracle Direct NFS ODM Library Version 4.0 

============================================================

NOTE: PatchLevel of this instance 0

============================================================

.....

2017-06-05T15:35:56.361018+08:00

No connectivity to other instances in the cluster during startup. Hence, LMON is terminating the instance.

 Please check the LMON trace file for details. Also, please check the network logs   of this instance along with clusterwide network health for problems and then re-start this instance.

看日志里,确实写的很清楚,节点 2 已经启动了,而节点 1 是后启动的, 1 节点的实例启动的时候发现没有办法和已经启动的节点 2 上的实例进行通信,具体原因让我们问 LMON;那就顺藤摸瓜,我们来看看LMON的trace信息吧,信息如下


xxx_lmon_56365.trc

======================

kjxgfdumpco - Dumping completion objects:

kjxgmpoll: invoke the CGS substate check callbacks (tmout enabled).

kjxgmpngchk: 0 pending request

invoke callback kjxgrssvote_check (addr 0xa5f31e0)

kjxgrssvote_check: IMR prop state 0x3 (verify)

kjxgrssvote_check_memverify: some instances have not sent MEMI yet

kjxgrssvote_check: wait-for inst map: 2 


No reconfig messages from other instances in the cluster during startup. Hence, LMON is terminating the instance. Please check the network logs of this instance as well as the network health of the cluster for problems


2017-06-05 15:46:52.056 :kjzduptcctx(): Notifying DIAG for crash event

----- Abridged Call Stack Trace -----

ksedsts()+346<-kjzduptcctx()+868<-kjzdicrshnfy()+1113<-ksuitm_opt()+1678<-kjxgrssvote_check_memverify()+1844<-kjxgrssvote_check()+1187<-kjxgmccs()+2219<-kjxgmpoll()+3092<-kjxggpoll()+485<-kjfmact()+365<-kjfcln()+6477<-ksbrdp()+1079<-opirip()+609<-opidrv()+602

<-sou2o()+145<-opimai_real()+202<-ssthrdmain()+417<-main()+262<-__libc_start_main()+245 

----- End of Abridged Call Stack Trace -----


*** 2017-06-05T15:46:52.093328+08:00

LMON (ospid: 56365): terminating the instance

ksuitm: waiting up to [5] seconds before killing DIAG(56318)

Warning: 2 processes are still attach to shmid 9601043:

太晦涩的一些函数就不一一看了,我们看好懂的部分先!

仔细看 L 妈妈( LMON )说:

No reconfig messages from other instances in thecluster during startup. Hence, LMON is terminating the instance.

我们知道在 RAC 的系统里当一个节点启动或者离开集群的时候是一定会发生 reconfiguration 的,这个在 alert 日志会有体现,正常的系统我们会看到

ReconfigurationStart

….

ReconfigurationComplete

这个过程会持续几秒到最多 300 秒( IPC send timeout 就会有节点离开了),这里会涉及到一些我们常见的 RAC 进程之间的通信,如 LMON LMD LMS LCK0 等。而节点 1 LMON 作为主要的 reconfiguration 进程却说它没有收到任何其它节点的 message ,这对于 LMON 来说是不正常的,它让我们去检查 network

Please check the network logs of this instance as wellas the network health of the cluster for problems


网络要检查


那我们就继续摸瓜了,我们先检查防火墙和网络的情况吧;

节点网络配置情况:

Node 1

=======

[grid@node1~]$ oifcfg getif

eth0  133.37.85.0 global  public

pri_eth1   1.1.23.0 global  cluster_interconnect,asm

pri_eth2   1.1.24.0 global  cluster_interconnect,asm

 

[grid@node1~]$ oifcfg iflist -p -n

eth0  133.37.85.0 UNKNOWN  255.255.255.0

pri_eth1  1.1.23.0 UNKNOWN  255.255.255.0

pri_eth1   169.254.0.0  UNKNOWN  255.255.128.0

pri_eth2  1.1.24.0 UNKNOWN  255.255.255.0

pri_eth2   169.254.128.0  UNKNOWN  255.255.128.0

 

pri_eth1:flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

       inet 1.1.23.53  netmask 255.255.255.0  broadcast 1.1.23.255

       ether 00:50:56:a3:2f:de  txqueuelen 1000  (Ethernet)

       RX packets 524021  bytes 423920984 (404.2 MiB)

       RX errors 0  dropped 11 overruns 0  frame 0

       TX packets 422996  bytes 260152436 (248.1 MiB)

       TX errors 0  dropped 0 overruns 0  carrier 0 collisions 0

 

pri_eth1:1:flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

       inet 169.254.30.247  netmask 255.255.128.0  broadcast 169.254.127.255

       ether 00:50:56:a3:2f:de  txqueuelen 1000  (Ethernet)

 

pri_eth2:flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

       inet 1.1.24.53  netmask 255.255.255.0  broadcast 1.1.24.255

       ether 00:50:56:a3:54:64  txqueuelen 1000  (Ethernet)

       RX packets 414236  bytes 293540363 (279.9 MiB)

       RX errors 0  dropped 11 overruns 0  frame 0

       TXpackets 355985  bytes 206542680 (196.9MiB)

       TX errors 0  dropped 0 overruns 0  carrier 0 collisions 0

 

pri_eth2:1:flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

       inet 169.254.142.159  netmask 255.255.128.0  broadcast 169.254.255.255

       ether 00:50:56:a3:54:64  txqueuelen 1000  (Ethernet)

可以看到一点点特别的,这套RAC有两个私网网卡,同时,也就有两个HAIP;不过这不是什么问题,两个网卡运行正常,haip也都分别绑定在两个私网网卡上;

节点2的信息类似,这里就不贴出来了;

Selinux 设置:

# cat /etc/selinux/config 


# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

#     enforcing - SELinux security policy is enforced.

#     permissive - SELinux prints warnings instead of enforcing.

#     disabled - No SELinux policy is loaded.

SELINUX=disabled

# SELINUXTYPE= can take one of three two values:

#     targeted - Targeted processes are protected,

#     minimum - Modification of targeted policy. Only selected processes are protected. 

#     mls - Multi Level Security protection.

SELINUXTYPE=targeted

IPTables 设置

[root@wyjh-db1-rac ~]# service iptables status

Redirecting to /bin/systemctl status  iptables.service

Unit iptables.service could not be found.

再让客户帮忙检查、确认:

1.        私网之间的互相 ping 是通的;

2.        私网使用独立交换机,没有任何防火墙;

这个时候就陷入这样的怪圈:网络是通的,没有防火墙,但是 LMON 说没有收到任何包; 会不会是 LMON 异常了或者 OS 太忙了,没有调度呢?新的 OS 也不应该忙啊。

让用户重新启动节点 1 ,在这个过程迅速收集双节点的 LMON strace pstack 也没有发现异常。


新发现,新目标

正在犯愁的过程中,客户提供了更新的信息:


“我这里有重大发现,我发现我删除了一个私网网卡之后节点就能起来了,但是把另外一块网卡加回来问题就又出现了,而且重装了一遍 GI 依然如此”


这个时候问题就相对清晰了,看起来好像是 HAIP 出现了异常了,难道是 11.2.0.3 上的路由的 bug 又在 12.2 上出现了?

于是再检查HAIP的日志,用grep  -I “route”*.trc的方式找是否有被删除的路由,结果大失所望,路由都在,HAIP工作的非常正常!


开始怀疑是 BUG ,这个时候用户下班了, 我趁机会迅速搭建了一套 12.2 RAC 环境, 并且也使用了双网卡,如果问题可重现,基本上可以开个 bug 了。而且可喜的是我搭建的环境也可以重现客户的问题。

重现后的相关日志trace显示, OS 层, Oracle 的集群层,甚至两个节点的 LMON 的进程在这个期间都是正常工作的,所以我坚信这个问题还是在网络层面,可是为什么多一个网卡就不行呢?


我还是想看一看这个网络的包究竟“卡”在了那里。

 

我刚搭建的测试环境,没有业务,于是我对两台主机的私网的两块网卡同时开启了tcpdump。抓取的方法,我重演了一下如下图:


在启动失败之后停止抓包。

然后开启节点 1, 后再启动节点 2 ,节点 down 掉之后停止 tcpdump ,拿到 dump 包之后,我用 wireshark 对生成的包通过 IP 地址 + 协议 + 端口的方式进行了过滤和比较:

这些端口的包:


居然在在对端 节点2 一个都没有找到:


看起来这些包根本就没有到对端就丢失了。 这也确实印证了 LMON 提示的没有收到 message 的信息确实是正确的。


通常到这儿,我们确实可以判定是网络的问题,应该可以甩给网络管理员检查网络了,但是,我这里是个 VM 搭建的虚拟机,这里是没有任何交换机和防火墙的!

那么问题来自于 OS 的限制?   除了 SELInux  IP Table 在我的知识范畴里确实没有其它可以拦截网络包的东西了 除非是 OS 有参数限制了!

要找就找关键字

开始猜谜游戏了,于是我在 OS 里输入sysctl命令过滤想试着找找:关键字: block  filter;

通过block并没有找到相关的信息,而通过filter则找到了下面的信息:


[root@nascds10~]# sysctl -a|grep filter

 

net.ipv4.conf.eth1.arp_filter= 0

net.ipv4.conf.eth1.rp_filter= 1

net.ipv4.conf.eth0.arp_filter= 0

net.ipv4.conf.eth0.rp_filter= 1

net.ipv4.conf.lo.arp_filter= 0

net.ipv4.conf.eth0.arp_filter= 0

net.ipv4.conf.eth0.rp_filter= 1

net.ipv4.conf.lo.rp_filter= 0

net.ipv4.conf.default.arp_filter= 0

net.ipv4.conf.default.rp_filter= 1

net.ipv4.conf.all.arp_filter= 0

net.ipv4.conf.all.rp_filter = 0


我其实对着几个参数不是特别了解,于是逐个查找,细读下来总有收获,可以发现 Linux rp_filter  的解释如下:


We saw what an asymmetric route is in thesection "Essential Elements of Routing in Chapter 30. Asymmetric routesare not common, but may be necessary in certain cases.  The default behavior of Linux is to consider asymmetric routingsuspicious and therefore to drop any packet whose source IP address is notreachable through the device the packet was received from, according to therouting table .
However, this behavior can be tuned via /proc on a per-device basis, as wewill see in Chapter 36. See also the section "Input Routing" inChapter 35.

上边的解释引起了我的注意,虽然我不太了解网络,但是我看到了这个反向路由的原则中有 drop any packet 的字样。 而且 Linux 6  Linux 7 上默认的值是和 Linux5  是不一样

再查, Linux 对设置的值表述如下:


rp_filter- INTEGER
    0 - No source validation.
    1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is testedagainst the FIB and if the interface is not the best reverse path thepacket check will fail. By default failed packets arediscarded.
    2 - Loose mode as defined in RFC3704 Loose Reverse Path  Each incoming packet's sourceaddress is also tested against the FIB and if the source address is notreachable via any interface  the packet check will fail.


既然发现了可疑的地方,来试试吧, 把他们都设置成旧版本的 OS 的默认值: .

重启节点 2 的实例后,正常启动了!


老司机的疏忽

故事到这里应该就圆满结束,但是作为一个老司机,我知道客户还是会问“为什么呢?”的!!

于是我到 Oracle 的文档里找了一下这个参数 rp_filter  ,而结果却让我大跌眼镜,因为 Oracle 12.2 的安装文档里有明确的写到这一段:


5.14   Multiple Private Interconnects and Oracle Linux

With Oracle Linux kernel 2.6.31, which also includes Oracle UnbreakableEnterprise Kernel 2.6.32, a bug has been fixed in the Reverse Path Filtering.As a consequence of this correction, Oracle RAC systems that use multiple NICsfor the private interconnect now require specific settings for the rp_filter parameter. This requirement also applies to all Exadata systems that arerunning Linux kernel 2.6.32 and above. Without these rp_filter parametersettings systems, interconnect packets can be blocked or discarded.

The rp_filter values set the Reverse Path filter to no filtering (0), to strict filtering (1), or to loose filtering (2) Set the rp_filter value for the private interconnects to either 0 or 2 .  Setting the private interconnect NIC to 1 can cause connection issues on the private interconnect. It is notconsidered unsafe to disable or relax this filtering, because the privateinterconnect should be on a private and isolated network.

For example, where eth1 and eth2 are the privateinterconnect NICs, and eth0 is the public network NIC, setthe rp_filter of the private address to 2 (loosefiltering), the public address to 1 (strictfiltering), using the following entries in /etc/sysctl.conf:

net.ipv4.conf.eth2.rp_filter = 2

net.ipv4.conf.eth1.rp_filter = 2

net.ipv4.conf.eth0.rp_filter = 1

OracleLinux 5.6 (Oracle Linux 5 Update 6) includes a fix using initscripts-8.45.33-1.0.4.el5.i386.rpm,which sets the kernel parameter net.ipv4.conf.default.rp_filter to2 (relaxed mode). For that reason, after youapply the Unbreakable Linux kernel on top of Oracle Linux 5.6, you may not needto make manual changes, because the rp_filtervalue of all NICs is set to 2.If you require more strict reverse path filtering on the public network, thenset the public NIC rp_filter to 1.

这下原因清楚了, Oracle 都给官方解释了,复制粘贴给客户就可以了。

官方文档里搜索 rp_filter 你也就可以迅速找到了!

最后的总结

总结一下吧:

1.        由于我和客户现场的 DBA 都没有仔细阅读安装文档,导致他碰见了这个问题,而我对这个问题我分析的也本末倒置了,产生的原因对我来说是一个“忙”字。但是恰恰是因为忙,才能有一次详尽的分析过程,这个过程希望给大家提供一个分析类似问题的思路和方法。

2.        无论 12.2 也好新出的 OS 也好会有一些调整和改变,特别是经验丰富的 DBA 是需要时常看看文档更新一下这些新的变化的。这些不会都在 New Feature 里都写上的。

本文转载于中亦安图

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31547066/viewspace-2222482/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
性格开朗,有较强的学习能力,对oracle数据库的体系结构,搭建RAC,timesten,goldengate,分布式数据库,dataguard,系统调优有较深入的了解, 尤其是oracle优化,深入学习的主机命令,对数据库的优化,SQL语句的优化有深入的认识,目前正在shell脚本,mysql,以后会有计划学习大数据和python。

注册时间:2018-07-23

  • 博文量
    182
  • 访问量
    325206