月归档：2015 年四月

11.2中修复CRS不能启动的例子-1-使用正常节点的gpnp profile修复损坏节点

发表于 2015 年 4 月 13 日 由 Lunar

SSD上的一个11.2 RAC的其中一个节点OS不能起来了，鼓捣半天还是不行 想想这个是2013年买的，才两年啊……，不知道是不是这个原因，反正很无语…… 另一个10多年前的活动硬盘上那个RedHat 2上的Oracle 8.0.6都还可以使用 . 就这个环境，从其他活动硬盘上复制了节点1的老的备份到SSD上，尝试修复整个RAC。 由于只修改了节点1的IP跟我现在VBOX中的配置一致即可，且节点2是正常的，因此，无需大招。 只要两件事情; 1,在OS层面修改节点1的网络配置: 2,把节点2的gpnp profile传给节点1 . 具体如下： 1，将2个节点的crsd都关闭，把节点2的profile.xml复制到节点1： 确认节点2的crs是关闭的： 2，确认当前的节点2的gpnp profile信息是正确的： 我这里主要是私有网络的IP地址应该为192.168.20.0网段： 即 可见这里是正确的。 注意这里，当所有CRS进程都不启动时，gpnp的信息来自于他自己的一个cache（猜测这个是从文件上保存的profile中读取到他自己的所谓cache的） . 3，查看节点1当前的gpnp profile，注意，其中的net2的信息，是错误的： 4，确认节点1的crs全部都是关闭的： 5，备份节点1当前的gpnp profile： 6，将节点2的gpnp profile复制到节点1： 7，启动节点1和节点2的crs（正常启动即可）： 8，可以看到，节点1已经可以正常启动了： 这里看到节点1的网络信息也正常了 再启动节点2： 除了network2（用于ADG的网络，还没有修改相应的配置），其他都正常了。

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

10.2.0.1 RAC中重建CRS的过程（比如错误的修改IP导致CRS不能启动）

发表于 2015 年 4 月 13 日 由 Lunar

VIP是oracle 10.1引入的一个绑定在public IP上的静态IP，它的信息岁PUBLIC网卡的信息一起保存在OCR(Oracle Cluster Registry)中。 很多时候客户有一个需求，比如在测试环境是一套IP，迁移到生产后是另一套IP。 这时如果客户不想重装系统，那么就需要修改RAC的IP。 . 通常这样的操作本身都是小操作，不需要大动干戈，但前提是一定按照官方流程操作，比如修改IP时，CRS是开启的还是关闭的？ 再或者一类常见错误是，修改IP时，需要的填写的是子网信息而不是IP地址，这也是一类常见的因为修改IP造成CRS不能启动的。 类似这些小地方不注意，就会造成CRS不能启动。 不论是10.2、11.1，还是11.2，这些东西基本的核心内容其实是变化不大的，不同的是11.2更加完善和提供了更多可选的修复方法（报错非官方支持的）。 . 总结一下大概的东西： 1，PUBLIC网络对应的主机名不能修改，如果要修改，官方说法是一定要重装CRS。 这里我感觉是这样的：如果把主机上那几个用主机名名门的目录名称修改为新的主机名，然后执行重新配置CRS的操作，理论上可以行。 比如10g是rootdelete.sh rootdeinstall.sh root.sh 11.2以后是deconfig和reconfig 不过测试环境和自己玩的也就算了，生产环境，我还是感觉按照官方说法靠谱，否则日后出现各种怪癖问题，那就是给自己挖坑了…… . 2，对于PUBLIC网络，不修改主机名，只修改PUBLIC IP，这个不需要修改CRS的配置，因为不论是10g, 11.1 ，还是11.2，CRS中都没有就具体IP 3，对于修改PUBLIC的网络接口名（interface）、子网（subnet）和掩码信息（netmask）等信息，需要使用oifcfg进行修改。 这个以前有客户问过，需要多久？ 答：理论上10分钟以内。如果需要验证和回退措施等检验，那么申请30分钟到1小时的停业务时间吧。 . 4，如果修改私有网络，在10.2和11.1，因为这些信息保存在CRS中，因此需要相应的修改CRS信息（使用oifcfg） 从11.2开始，CRS（Cluster Ready Service）升级为GI（Grid Infrastructure）。私有IP对应的私有主机名不再存储在OCR中了。 而是通过GNPN架构来管理（即 网络即插即用，后面会讲。OCR和私有IP对应的主机名也不再有依赖关系。 因此，可以随便修改而不需要在CRS层面改动任何东西。 . 5，如果修改错了，没关系，10.2和11.1的杀手锏是 … 继续阅读 →

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

在Exadata X5-2（HC）测试创建31g各类文件和10Tbigfile的效率

发表于 2015 年 4 月 7 日 由 Lunar

本周要使用SwingBench对Exadata X5-2（HC）进行压测，因此，我提前准备了需要的表空间和redo等等。 1，首先看一下创建31g的数据文件的速度： 新增一个31g的数据文件，普通类型的数据文件，大概12秒左右： 对比一下EF550全闪存（可用空间也是20T，Exadata X5-2 QuarterRack也带了20T的闪存）： 增加一个31g的临时表空间文件，大概不到20秒： 新增一个31g的undo表空间文件，大概不到30秒： 新增一个system的31g文件，时间比较长，大概不到80秒的样子： 新增一个SYSAUX表空间的文件大概20秒左右： 顺便测试了一下Exadata上创建10T bigfile的效率，具体命令如下： 这个过程执行了大概1小时，也就是在此环境下，创建10T的bigfile需要1小时时间，这个速度我感觉已经超快了： . 首先了解一下，offload和Smart Scan的关系。Offload在很多时候我们可以跟SmartScan理解为一致的东西。 它是指讲处理能力从数据库服务器下移到存储服务器的操作。 这一操作不仅转移了CPU的使用，更主要的是大大减少了返回到数据库层的IO： 1，减少存储系统和数据库服务器之间的传输数据量 2，减少数据库服务器上的CPU使用率（解压缩的操作发生在cell上） 3，减少存储层磁盘读取的时间 . 但是在某些情况下，还有一些其他非SmartScan类型的卸载（offload）操作： 1,智能文件创建（数据块在存储节点上被格式化） 2,Rman增量备份 . 在创建大表空间的时候，我们看到了等待事件“cell smart file creation” 这个正是我们期待看到的，这类IO走智能文件创建（Offload是Exadata的独门武器，而智能文件创建是非Smart Scan类型的一种IO卸载功能）。 整个创建bigtable的时间测算，测试期间，db节点和cell节点的CPU占用都很低： 每秒 6G 每分钟 360G 每小时 20T（既然是每小时20T，那么我的这个10T表空间为什么使用了1小时，而不是30分钟？） … 继续阅读 →

发表在 POC和性能调整 | 标签为 , | 留下评论

使用Oracle 11.2的DBMS_RESOURCE_MANAGER.CALIBRATE_IO对Exadata X5（HC）进行测试

发表于 2015 年 4 月 7 日 由 Lunar

之前测试的X3的flashcard的IOPS大概是满配200w左右（具体参见 《Exadata上的IOPS和MBPS》） 使用Exadata的calibrate命令测试X5-2的IOPS和MBPS 本次测试的机器是Exadata X5-2： CPU型号： 主机型号： . Oracle 11.2有一个DBMS_RESOURCE_MANAGER.CALIBRATE_IO，可以用来测试磁盘IO。 这里有几个需要注意的地方： 1，DBMS_RESOURCE_MANAGER.CALIBRATE_IO不能并行执行，否则会报错： 2，这个过程的测试，对于基准测试，我个人感觉非常不合适（数值严重偏低……不知道是不是需要调整什么参数，还是Exadata上就不应该用这个测试？） 3，测试中，指定延迟参数时，不能低于10秒（oracle的限制，估计是针对硬盘考虑的） 4，后面监控用的是Oracle已离职员工（凯耀，我的好兄弟）给的mon监控软件（底层基于开源的collect rpm包） 不过在新版本的exadata上貌似脚本还有些问题，因此，有些画图时丢失了（比如IOPS，比如flashcard的图） 5，测试脚本： 这里 102 是磁盘数量，10 是硬盘延迟 102的由来是因为，这个是一个Quarter Rack，使用onecommand安装后，缺省可用102个asmdisk，这个可以查询（V$ASM_DISK）。 下面是本次的测试结果： 这里看到IOPS大概1w多，吞吐量大概每秒3.5GB，最大延迟11秒。 这个数值跟使用mon（凯耀写的）监控的数量差不错： 这里看到磁盘的吞吐量大概每秒3.5GB/s，跟mon监控的差不多 IB的吞吐量大概是3.4GB/s 逻辑硬盘的IOPS是10000左右，跟使用cell上的calibrate的数值差不多 这是执行过程中的一个截图。

发表在 POC和性能调整 | 标签为 , , | 一条评论

使用Exadata的calibrate命令测试X5-2的IOPS和MBPS

发表于 2015 年 4 月 7 日 由 Lunar

之前测试的X3的flashcard的IOPS大概是满配200w左右（具体参见 《Exadata上的IOPS和MBPS》） 使用Oracle 11.2的DBMS_RESOURCE_MANAGER.CALIBRATE_IO对Exadata X5（HC）进行测试 使用Exadata的calibrate命令测试时需要注意： 1，这个不能再业务高峰期操作，否则可能造成应用hang等。 2，一般测试的时候，是把cellsrv进程宕掉，否则就要带-force参数。 3，在老板上上，如果这个命令报错，还有一种可能的原因，就是它需要生成一些临时的lun配置文件，然后自己格式化。 如果报错，可以手工自己删除这些临时的lun文件。 新版本目前没有发发现这类问题，因为Oracle已经修改了脚本，所有的文件生成目录都是带日期的（启动测试的日期）。 因此，不会因为不能格式化lun等信息报错，如图 4，Exadata的calibrate命令底层采用orion的方法，根据自己预定义的lun组合，然后压测N轮 （不同的lun组合，压测好多次，自动的过程，无需手工干预） 5，Exadata的calibrate采用只读方式（保护数据安全） 6，不能再一个cell上并发两个calibrate，否则会报错的。 . 本次测试的机器是Exadata X5-2： CPU型号： 主机型号： 估算flash card的IOPS： 因此，理论上，这台X5-2 quarter rack的flash lun的IOPS总和超过 450万 . 而在之前测试的X3的flashcard的IOPS大概是满配200w左右（具体参见 《Exadata上的IOPS和MBPS》）： 满配机器（14个cell）hard disk LUNs的MBPS推算： 1962*14个cell=27468 满配机器（14个cell）flash disk LUNs的MBPS推算： 4184*14个cell=58576 满配机器（14个cell）hard … 继续阅读 →

发表在 POC和性能调整 | 标签为 , , , , | 留下评论

Exadata上CPU相关的设置（感觉已经很好了，除了irqbalance）

发表于 2015 年 4 月 6 日 由 Lunar

有些情况下，Exadata上我们发现有IO降级的情况，但是检查磁盘和flashcard都没有损坏。 这时候，可能需要检查一下APIC timer功能是否正常（APIC timer没有正确开启可能导致iostat报告的吞吐量有降级的现象） 当发生这类问题时，可以对比vmstat的bi/bo（读和写的平均吞吐量），因为vmstat命令不受APIC timer的影响。 . APIC Timer(Advanced Programmable Interrupt Controller)是一种时钟中断设备，即 高级可编程中断控制器 CPU通过彼此发送中断来完成它们之间的通信，APIC 就是通过编程触发lapic设备周期产生中断，然后注入到vcpu。 2000年以后的CPU都支持，这是Intel多处理规范的核心。 APIC Timer的模式APIC定时器包含3种定时器模式: 周期触发periodic 一次性触发one-shot TSC-Deadline模式(最新的CPU里面支持)。 . 老版本的Exadata可以检查 dmesg|grep “Using local APIC timer interrupts”，来确认APIC timer是否正确开启。 新版本的Exadata可以检查 dmesg|grep “Using IOAPIC for interrupt routing”，来确认APIC timer是否正确开启。 . 例如，下面显示在这个1/4配置的Exadata … 继续阅读 →

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

一次数据库性能问题处理（11g自动维护任务，log file sync）

发表于 2015 年 4 月 6 日 由 Lunar

看到问题发生前30分钟的awr显示，系统负载超高： 查询数据库当前等待事件： 跟awr中的信息一致： 直觉是resmgr:cpu quantum引起了其他一系列问题，这个已经不是第一次遇到了。 等待事件 resmgr:cpu quantum 是11.2引入的oracle资源管理引起的，这个东西一般问题很多，大部分时候，我们装机时，都是直接禁用的。 11.2的oracle资源管理中有一项最坑的是周末的维护任务，这个遇到好几次了。 禁用方法： 1，关闭一些不需要的维护任务： 关闭数据库的空间Advisor，避免消耗过多的IO： 关闭数据库的SQL自动调整Advisor： 关闭数据库的weekday窗口的DEFAULT_MAINTENANCE_PLAN： 查看当前active的resource plan ，确认已经关闭： 此时awr可以看到系统负载已经下降一点点，但是依然很高： 上述修改后的数据库等待事件已经变味“log file sync”，具体如下： 相应的前台等待事件： 后台等待时间： 在LGWR的trace中，可能会出现类似如下的信息： 这是11.2的新特性，Adaptive Switching Between Log Write Methods（LGWR写模式自动切换），该功能bug一堆，经常导致commit缓慢而带来的“log file sync”。 通过设置如下隐含参数，禁用11.2这个LGWR写模式切换功能： 修改后，数据库等待事件已经变为正常的应用日常的等待事件了： 此时的AWR看到，系统负载已经降下来了： 该应用正常时间，数据库连接数如下： 故障暂时缓解了，应用反映已经正常，但是可以看到，上面的信息告诉我们，对于这个应用来说，需要调整的地方还很多： 1，系统参数全面检查 2，SQL优化（SQL语句的写法，index，统计信息检查等） … 继续阅读 →

发表在 Database | 标签为 , , | Comments Off on 一次数据库性能问题处理（11g自动维护任务，log file sync）

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 … 继续阅读 →

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