Exadata x5 Raid电池对IO性能的影响
前段时间一套Oracle Exadata X5环境遇到了严重的IO问题，从AWR top event IO延迟相当高，问题前虽然IO性能并不是很好，但这次突然的性能减半，影响对于cell multiblock physical read和direct path write，cell smart table scan wait avg ms翻倍，甚至达到100ms以上，对于oracle环境是无法接受的，当然通过分析问题在硬件层，更换RAID卡电池后恢复，10几年前遇到过因为RAID卡电池没电，影响无法使用RAID cache导致IO性能衰减的问题
Troubleshooting Exadata X8 machine node reboot frequently rds_send_remove_from_sock
最近有个客户的Oracle Exadata x8 数据库主机操作系统总是频繁的重启，重启前在DB,CRS层没有任何错误信息， 当时的OS负载也比较低，仅从exawatcher的mpstat能发现在重启前15s左右部分CPU core sys使用达100%。 操作系统有配置kdump生成了dump信息，发现在CPU在等待Watchdog detected hard LOCKUP on cpu 11， 堆栈调用中包含rds_send_remove_from_sock，简单记录。
Exadata 故障3例:ORA-27302: failure occurred at: skgxpcnclrpc， 内存耗尽，Cellserver disk error
上周遇到几例Oracle Exadata Machine上的故障，简单记录一下问题现象，涉及db 实例重启失败报措OS资源相关skgxpcnclrpc， 与内存耗尽后进程系统失败，IO hang/error , 及cell 存储节点坏盘日志的输出。
Exadata Instance crash ORA-600 [ksz_cln_proc1] and restart fail due to breakdown of one CellServer (案例)
cell03存储主机的文件系统异常，导致ASM Hang,数据库实例crash, 虽然是NORMAL级别的冗余，但是数据库实例此时不能于ASM通信，重启CRS进程恢复，可使用剩余的2条CELL继续为数据库提供服务。 在延长了disk_repair_time时间后，等待时间后强置重启CELL03主机操作系统后，一切恢复。
自动化运维工具之：dcli 批量管理主机
dcli 为Oracle Exadata Machine中提供的管理cell的工具，全名 Distributed Command Line Interface，在Exadata， Exalogic， Exalytics等系列一体机都自带这个工具, 该工具是一套python脚本，可以用文本工具直接查看编辑， 在当前的IT管理中批量管理几百台机器已不是什么稀奇的事， 所以在日常一些批量共性的常规检查和运维就需要一种维护工具自动实现或者叫自动化运维工具， 当前较流行的有puppet和ansible 产品
