日归档：2015 年 4 月 5 日

Exadata上网卡参数的优化（主要是IB的MTU不同于一般值）

发表于 2015 年 4 月 5 日 由 Lunar

对比了一下普通主机和Exadata，发现主要的区别在于组播的配置，这个跟Exadata上使用IB的整个网络环境有关系（Infiniband card，IB Switch等等）： MTU是Maximum Transmission Unit的缩写。意思是网络上传送的最大数据包。 最大传输单元这个参数通常与通信接口有关（网络接口卡、串口等），MTU也不是越大越好，因为MTU越大，传送一个数据包的延迟也越大；并且MTU越大，数据包中 bit位发生错误的概率也越大。因此，需要针对网络來进行最佳化。 MTU的单位是字节。一般来说，如果本机的MTU比网关的MTU大，大的数据包就会被拆开来传送，这样会产生很多数据包碎片，增加丢包率，降低网络速度。 把本机的MTU设成比网关的MTU小或相同，就可以减少丢包。 一般普通的机器缺省配置组播是缺省值1500，这个跟以太网的帧的设计有关系。 以前，Ethernet一般把数据分割为一定大小的帧（frame）的单位来进行传送接收,但在规格上帧的尺寸被定为1,518字节。 但是随着通讯器材的发展，现在的万兆网等都支持大帧（jumbo frames），帧的尺寸根据机器各种各样,大部分对应9,000～16,000字节左右。 . . 要修改MTU的方法很简单（尽管很多人在RAC环境不正确的修改这个值导致了很多问题）： ifconfig eth0 mtu xxxx(你需要设置的值)，比如： ifconfig eth0 mtu 9000 修改后，使用 netstat -i 或者ifconfig |grep MTU来查看既可以。 目前，Oracle支持在私有网络（interconnect）使用超过1500的组播（具体设置也要根据前面说的，看环境，不是越大越好。通常没有好的设计，一般不改）。 . . 对于多播（MULTICAST），RAC要求必须开启，这个在Oracle官方的最佳实践中有明确说明： 对于多播的检测，Oracle也提供了详细的方法： 类似下面的，就是多播检测失败的情况： . 关于组播，在普通环境（非Exadata）有一些注意事项： 1，一般就采用缺省的1500，如果超过这个值，需要特殊的配置，具体请参考： … 继续阅读 →

发表在 体系架构 | 标签为 , , | 留下评论

修复由于修改主机名造成Standbalone异常（ORA-29701 raised in ASM I/O path）

发表于 2015 年 4 月 5 日 由 Lunar

前不久，我同事修改standbalone的主机名，只是单纯的从主机层面修改了，has等并没有做调整，虽然数据库奇迹般的open了（有些时候，数据库在此情况下是不能open的，直接就会报错），但是数据库更改主机名以后，ASM和数据库的alert都有报错，而且分析后，觉得这个报错不解决，会在后期使用中造成数据库crash。 修复这个问题的程很简单，有几点说明： 1，8i和8i以前叫做OPS，Oracle Parallel Server，9.0.1~11.1之间叫做RAC（Real Application Cluster），11.2以后叫做GI（Grid Infrastructure） 2，Standbalone结构就是单实例数据库使用ASM的场景，他只需要db和asm通信的cssd等结构，不需要crs。 3，启动，关闭和管理has流程类似rac，但是千万别混淆，Standbalone的叫做crsctl start/stop has，RAC的叫做crsctl start/stop crs(整套架构中所有进程由ohasd创建)，如果弄错了，会出现一些异常情况，在其他案例中，我们遇到过直接ASM报错的，后续在总结了那个案例分享出来。 4，不管是Standbalone还是RAC，修改主机名和IP等都需要特别小心，因为他们不像单机数据库一样，单纯的主机层面就该就可以，他们需要分别在has和crs中进行重配或者修改。 5，无论发生了什么，只要没有动ASM和DB，那么不用担心丢数据。因为has或者crs的结构都跟db是独立的，一般不会丢数据，最差的结果，重装一下，也可以把asm和db拉起来。 6，很多时候，在做类似该ip或者主机名，或者升级crs或者has的版本，或者升级数据库软件时，都建议对现有环境进行备份，要么借助NBU之类的工具，要么使用tar命令。千万别用ftp或者直接copy，这类的否不靠谱，不能用于文件恢复。 具体过程如下： ASM ALERT: 数据库的日志，DB ALERT: CRS和ohasd也有明显报错： 我猜测，此时如果做类似增加/删除文件数据库都会crash，果然，我让同事做rman备份，数据库就crash了。 处理的方法很简单，就是修改has的相关配置，讲新主机名配置进去。具体步骤如下： 首先记录当前的系统关键信息，因为修改完has后，需要将asm，db，diskgroup等关键信息重新注册到has中： 这里还发现了一个问题，这个库的ASM的在has中的信息和实际使用的spfile不一致 在所有的磁盘组中，我们发现实际上是找不到在has中注册的ASM实例使用的spfile的： 使用kfod检查会发现，大量磁盘的报错： 接下来，我就开始重建has了，首先是使用force都无法停止has，因为已经异常了，这个在意料之中的，没关系： 这些进程已经停不掉了，于是只能重启主机（kill ocssd.bin 一样会导致主机重启，因此直接手工reboot了）。 起来后，先删除现有的has配置： 然后执行重新配置： 这过程很快，比GI快多了，HAS还是结构简单啊，O(∩_∩)O哈哈~。 配置完成后，检查一下，服务都正常，只是需要将下面的服务改为自动启动： 使用NETCA重建监听: 添加asm： 在has中添加db： … 继续阅读 →

发表在 RAC | 标签为 | 留下评论

解决Exadata上IB检查脚本infinicheck的报错过程

发表于 2015 年 4 月 5 日 由 Lunar

今天检查Exadata的IB网络时，使用 infinicheck 检查，发现db节点有报错，cell节点正常。 当前主机是Exadata X5-2： infinicheck的执行结果（该命令可以有很丰富的参数，但是也可以不带任何参数，缺省就可以）： 从这里我们看到，凡是到db节点的都报错。 infinicheck命令底层是调用的rds-stress命令，例如： rds-stress -r 192.168.10.1 -p 10584 当然，除了infinicheck意外，还有其他很多检查方法，比如rds-ping(ExaWatcher和OSWatcher中调用的这个命令)。 很奇怪，为什么就db节点报错？ 于是，使用infinicheck 带参数-b -g 来检查和配置一下DB节点的IB的SSH连通性： 这里我犯了个错误：这个命令需要配置IB的基于IP的SSH(root)，而不是主机名 这里很清晰的告诉我们，ping不通，O(∩_∩)O哈哈~，这个就好办了。 接下来，我们手工ping看看： 那么ping第2个节点的主机名试试看，证实一下是不是解析的问题： 这里我们看到，果然是解析的问题。 由于IB网络是Exadata内部互联用的，因此没有在DNS解析，只在/etc/hosts中解析。 而/etc/hosts文件是由onecommand配置的（除非手工安装，否则使用了onecommand后，所有配置文件都由onecommand根据配置xml文件自动生成） 从这里我们看到，IB网络的IP配置格式是错误的，正确的是： 127.0.0.1 localhost.localdomain localhost 错误的是： 192.168.10.1 dm01db01-priv1.lunar.com dm01db01-priv1 修改了上述hosts文件后， 纠正hosts文件后，发现ping主机名的问题解决了： 这里还有个问题很奇怪，cell节点的hosts文件也是错误的，但是却可以ping通，怀疑跟DNS缓存有关系： 现在，再次使用infinicheck 带参数-b -g … 继续阅读 →

发表在 故障诊断 | 标签为 , | 留下评论