10月28号 青岛项目中的oralce rac 出现死机的情况。
故障现象：
ORACLE RAC 挂掉，虚拟机死机。
DBA和现在负责的同事，重新安装系统和ORACLE RAC 故障现象依旧
Linux 系统日志显示 写入磁盘错误
Oracle 日志显示 不能访问物理存储
第一次死机
对比互联网上搜索到的方法对比 发现SCSI总线不一样。
参考文档http://www.doc88.com/p-5416264066182.html
按照网上的方法，修改SCSI 控制1的总线为LSI Logic 并行。修改好后，开启虚拟机的电源，发现机器进不了操作系统。
SCSI控制器0 和SCSI控制器1全部改为 LSI logic 并行 机器可以启动。
SCSI共享总线一样。于是没有修改
进入操作系统后，数据库运行正常。
好景不长，大概6个小时以后，数据库停止运行。但是虚拟机并没有死机。总算有点进步。
第二次死机
继续百度参考文档
主要有两个方面的改变
第一 改变磁盘的模式为独立—永久模式
第二 开启多写入模式
打开虚拟机的SSH SHELL模式，使用客户端登录主机。使用vi 命令编辑 虚拟机的VMX文件
加入参数
scsi1:0.sharing = "multi-writer"
scsi1:1.sharing = "multi-writer"
继续在命令行下 输入 获取虚拟机的注册号
vim-cmd vmsvc/getallvms |grep -i testrac1
刷新配置以使更改生效
分别在esxi1 的主机上运行
vim-cmd vmsvc/reload 36
在esxi2 的主机上运行
vim-cmd vmsvc/reload 28
注意：以上操作必须在虚拟机关机状态下操作，RAC1 和RAC2都操作一遍。
操作完成后，开启虚拟机电源，再次进去SHELL 查看testrac1.vmx 居然发现新添加的参数自动变成了
scsi1:0.sharing = " normal"
scsi1:1.sharing = " normal"
继续百度
参考资料http://www.linuxidc.com/Linux/2011-02/31976p11.htm
参考资料http://wenku.baidu.com/view/a72b0912a216147917112810.html?re=view
其中 disk.locking=”fales” 这个参数出现的次数比较多，于是关闭testrac1和testrac2。并新增参数
scsi1:0.sharing = "multi-writer"
scsi1:1.sharing = "multi-writer"
disk.locking=”fales”
关闭虚拟机电源，刷新配置以使更改生效，
分别在esxi1 的主机上运行
vim-cmd vmsvc/reload 36
在esxi2 的主机上运行
vim-cmd vmsvc/reload 28
然开启虚拟机电源
重启虚拟机。顺利进入系统，ORACLE 启动正常。然并卵这次坚持了24个小时，数据库停止运行
第三次死机
再次百度
还是参考在 vSphere 6.x VSAN 数据存储上使用 Oracle RAC (2126079)
发现共享总线为 NORMAL 妹的 貌似我这边没有这个选项
打开自己的web client 对比查看 发现normal 应该对应的是无。这个选项
参考另外一个文档
根据上面的文档重新配置 发现虚拟机电源启动之后一直停留在启动页面，左上角光标一直不停的闪烁
我一开始以为是引导扇区被破坏，
然后使用光盘进去单用户模式修复引导。重复几次都不行。始终进不了系统。尝试重新安装选择升级覆盖GURB引导
结果还是不行。
怀疑是共享磁盘造成的原因。于是关闭虚拟机，删除共享磁盘。开启虚拟机电源。系统正常进入linux 桌面。
进入桌面后关闭虚拟机电源
重新添加共享磁盘。根据文档这次把SCSI控制器全部改为准虚拟
修改完成之后，重启启动。其中一台RAC报错。显示磁盘被锁
关闭虚拟机，重新进入的shell 模式添加参数。，并刷新生效。为了测试各参数的效果，分别添加
disk.locking=”fales”
任然只有一台虚拟机可以启动
分别测试SCSI磁盘总线为准虚拟&LSI LOGIC&LSI,SAS,并且SCSI共享总线设置为无的情况下该参数失效。
接下来进行第二次测试。SCSI 总线为准虚拟，SCCSI 共享总线为无，参数为多点写入
scsi1:0.sharing = "multi-writer"
scsi1:1.sharing = "multi-writer"
关闭虚拟机，重新进入的shell 模式添加参数。，并刷新生效。
测试结果。顺利进入LINUX 桌面。但是 oracle 启动不了。
分析
经过3天的测试，找问题，依然没有完全解决问题， 从三天的测试结果来看 无非是 SCSI 总线， SCSI 共享总线，和 磁盘锁定，多点写入参数的组合
实验结果如下
|
SCSI 总线 |
SCSI 总线总线 |
磁盘模式 |
磁盘非锁定 disk.locking=”fales”
|
多点写入 scsi1:0.sharing = "multi-writer" |
故障现象 |
|
准虚拟 |
物理 |
默认 |
没有添加 |
没有添加 |
数据库挂掉，虚拟机死机 |
|
LSI Logic |
物理 |
默认 |
没有添加 |
没有添加 |
6个小时左右数据库挂掉 |
|
LSI Logic |
物理 |
独立持久 |
添加 |
添加 |
24小时左右数据库挂掉 |
|
准虚拟 |
物理 |
独立持久 |
添加 |
添加 |
24小时左右数据库挂掉 |
|
LSI Logic |
物理 |
独立持久 |
添加 |
没有添加 |
超过24小时挂掉 |
|
准虚拟 |
物理 |
独立持久 |
添加 |
没有添加 |
超过24小时挂掉 |
|
准虚拟 |
无 |
独立持久 |
添加 |
没有添加 |
只能启动一台RAC |
|
LSI Logic |
无 |
独立持久 |
添加 |
没有添加 |
只能启动一台RAC |
|
准虚拟 |
无 |
独立持久 |
添加 |
添加 |
可以启动系统，ORACLE 启动不了报找不到ASM磁盘 |
|
LSI Logic |
无 |
独立持久 |
添加 |
添加 |
可以启动系统，ORACLE 启动不了报找不到ASM磁盘 |
仔细分析最后两种情况应该是LINUX系统共享磁盘的配置和虚拟机的磁盘共享存在不协调的问题。：很奇怪的是手工向共享磁盘里面狂写数据，然后删除，一切正常。Oracle db
像共享磁盘准确的说是ASM管理的共享磁盘写入数据，就会出现不能写盘的情况。而同样的共享的并行文件系统IBM的GPFS却不存在这个问题。
查看dev 下绑定的ASM磁盘。发现磁盘消失了，oracle 肯定启动不了
使用脚本重新绑定
for i in b c;
do
echo "KERNEL==\"sd*\", BUS==\"scsi\", PROGRAM==\"/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/\$name\", RESULT==\"`/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/sd$i`\", NAME=\"asm-disk$i\", OWNER=\"grid\", GROUP=\"asmadmin\", MODE=\"0660\"" >> /etc/udev/rules.d/99-oracle-asmdevices.rules
done
然后查看/99-oracle-asmdevices.rules 文件
发现根本获取不到SCSI ID号，更别提绑定磁盘了。
查看所有的SCSI设备 发现因为在虚拟机上共享总线设置的为NONE 在操作系统层面把这个共享磁盘当成了本地盘来操作。根本就没有SCSI_ID。
网上查到另外一种说法，VMWARE 在本地磁盘上屏蔽了 SCSI_ID号需要通过添加disk.EnableUUID = "TRUE"参数来显示SCSI_ID号
又寄出百度 搜索得参考文档如下
http://fatboy.blog.51cto.com/6671737/1594690
http://blog.itpub.net/14184018/viewspace-701675/
其中要用到udevtest udevinfo 等命令
在rehl 6 中要换成
udevadm -a -p /sys/block/sdc/sdc1
209715200
1677721600
比较一下 不同的，并且好记录的参数为 KERNEL ATTR{size}
把下列参数修改为
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="36000c29414cba14d3ebabec77013108d", NAME="asm-diskb", OWNER="grid", GROUP="asmadmin", MODE="0660"
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="36000c29d7b4be947333d99066a636a94", NAME="asm-diskc", OWNER="grid", GROUP="asmadmin", MODE="0660"
KERNEL=="sdb", SUBSYSTEM=="block", SYSFS{size}=="209715200", NAME="asm-diskb", OWNER="grid", GROUP="asmadmin", MODE="0660"
KERNEL=="sdc", SUBSYSTEM=="block", SYSFS{size}=="1677721600", NAME="asm-diskc", OWNER="grid", GROUP="asmadmin", MODE="0660"
或者 （注意：下面这种仅适用于虚拟机情况。且不同虚拟机的硬盘虚拟设备节点号一样）
参考文档http://www.examw.com/oracle/jishu/203503/
ACTION=="add", KERNEL=="sdb", NAME="asm-diskb", OWNER="grid", GROUP="asmadmin", MODE="0660"
ACTION=="add", KERNEL=="sdc", NAME="asm-diskc", OWNER="grid", GROUP="asmadmin", MODE="0660"
~
/sbin/start_udev
Udev 绑定的磁盘出来了。 重启虚拟机。 Oracle 也起来了
到目前稳定运行了30多个小时。
4号下午的时候，负责和联系联想的同事转啊转啊，终于转到了VMwARE，并且联系上了原厂工程师。
对了我们购买的VMWARE 是联想的OEM版，直接联系VMWARE是没有卵用的。必须经过联想。
关于配置Oracle RAC最佳配置参考VMware文档。
文档链接：http://www.vmware.com/files/pdf/solutions/oracle/Oracle_Databases_VMware_RAC_Deployment_Guide.pdf
最佳配置文档第17页
In the device list, select SCSI controller 1
In the SCSI Bus Sharing section, select None,keep the default selection.
In the SCSI Controller Type section, click Change Type.
Select VMware Paravirtual.
Click OK, and click OK again.
Add configuration parameters for each Oracle RAC virtual machine as described in
Disabling simultaneous write protection provided by VMFS using the multi-writer flag
然而在最佳实践一文中漏掉了ASM 创建磁盘组的过程。UDEV绑定这块没有描述。导致ORACLE 后面不能启动。
难道是可以直接使用吗？ 测试一下
RAC1 /2 关机，新添加一块10G的硬盘 添加多写入参数。刷新使其生效，打开虚拟机的电源。进去linux 系统
在节点1对新增加的磁盘分区 fdisk /dev/sdd
节点2 同步 # partprobe /dev/sdd
运行asmca
表示不能直接创建。本地磁盘必须绑定之后才能使用。
总结。 关于这次故障主要是两个层面没有协调好。
两个层面
虚拟机 SCSI 使用准虚拟，共享总线无，磁盘模式为独立永久，开启多点写入参数。
操作系统 udev绑定共享存储不能使用SCSI_ID号，要使用其他的唯一参数。
话说回来，为啥同样的配置在VSHPERE 5.X的版本上使用正常？？？？？？？？？？？？？？
为啥同样的并行文件系统GPFS 可以正常运行，而ASM却出现问题呢？？？？？？
ORACLE 和 VMWARE 这对组合 是否还是存在一些问题？
有C++难题，加我！