ANBOB™

近期1客户Oracle RAC 节点OS重启，协助分析原因，db层无日志错误输出，RAC层有vote disk I/O timeout， OS层 qla2xxx [0000:81:00.0]-801c:7: Abort command 和DEVICE RESET 操作。qla2xxx 是QLogic FC HBA的驱动，怀疑重启是HBA卡导致IO失败，导致disk timeout, CRS发起reboot. 简单记录该问题。

osw是oracle检测系统资源的轻量级脚本级，是oracle的标准license许可，在oracle环境中不需要额外购买可以单独安装部署，建议也相信国产数据库后面应该也会出相应的工具，昨天一同事说是在分析一套19c的osw数据里提示错误如下：

一套医院的Oracle数据库用户平时并发并不高，但时长出现数据库无法响应，导致应用活动并发数逐渐增加，OS load能达大几百甚至1000+， 这是一个4物理CPU,144core的硬件，CPU usage sys和user并不高，数据库查询v$session活动会话高时event是大部分进程on cpu, 操作系统层是%iowait高，

最近信C进程加速， 一些行业可能面临替换CentOS、RedHat linux的ZZ任务， Oracle可能还要3-4年的缓和期，当前Oracle官方在12c已经增加了对中标麒麟的认证， 但目前没有任证的OS如果基于centOS的货也可以安装并运行生产环境， 在Kylin V10安装了个单实例oracle 11.2.0.4还算不复杂，下面简单分享

最近操作系统的问题有点多，上周有套Oracle数据库RAC部分节点的日志在频繁输出“systemd-logind: Failed to start user slice user-1002.slice, ignoring: The maximum number of pending replies per connection has been reached (org.freedesktop.DBus.Error.LimitsExceeded)” 信息，找我协助分析一下。

ile cache用于缓存文件数据的最小和最大内存数量由可调的内核参数filecache_min(5)和filecache_max(5)控制。参数filecache_min指定的部分内存专门用于加速文件I/O活动。内存不能用于任何其他目的，即使它不需要缓存文件数据。参数filecache_max指定filecache的最大大小。

近日一客户应用反馈数据库使用较慢，每个数据库的性能分析应该先从操作系统负载分析开始，当CPU耗尽时，其它指标可能失真变的没有意义， 当系统缓慢时不应仅从DB里找原因，数据库中几乎无负载，查看OS层发现idle接近个位数， 操作系统为AIX， 从OS层定位top process的命令通常有topas, ps, vmstat,nmon -t等，发现ps和topas显示cpu占比存在较大差异，4%和90%. 简单记录一下。

对于oracle、Postgresql都建议配置Hugepages， 通常RHEL linux上看到的hugepage size默认都是2M, 并且在Oracle 19c的db alert log中实例启动时有对于hugepage 使用个数的提示， 但是只有4k, 2M， 最近发现一客户IBM linuxone环境的Linux默认hugepage size为1MB(for IBM Z the hardware page size is 1 MB.), 那在配置hugepage时， DB alert log关于hugepage会如何显示？

当前数据库种类较多，像oracle等闭源数据库在诊断特殊疑难问题时需要分析内部C函数的call stack， 目前的oradebug short_stack或errorstack,linux系统中的pstack只是dump当前的调用， 还有现在的开源数据库虽然可以查看源代码，但是没法较方便的方法在运行的进程过程中持续跟进多个内部调用的call stack. 增加了故障分析的复杂性和诊断时间， 这里看到了一种使用strace跟踪的方法记录一下。

最近上海某客户一套ORACLE RAC发生1节点驱逐， 问题前CPU利用率并不高， CRS日志有I/O响应和IPC超时错误, 部分进程hang死，操作系统是RHEL7.5, 在操作系统meesage提示如下信息：
“kernel: NMI watchdog: BUG: soft lockup – CPU#25 stuck for 22s!”

一客户的一套ORACLE RAC 2-nodes on AIX, 年迈的大块头25G memory, 平时反馈就非常慢，一日因存储故障实例重启后，有1实例无法启动而另1实例正常，检查启动日志在ASM 实例正在starting后报错， 手动启动ASM 超时报错，ORA-00445: background process “LMD0” did not start after 120 seconds ，这是一个比较古老且常见的问题，

系统资源的最大利用是系统优化的目标，但是过度”优化”系统的容错性就相对较差，如果出现丝毫的卡顿就会“雪崩”，前段时间分析的一个案例，号称是亚洲最好的一套HP小机配置，有Oracle原厂操刀调试的一套Oracle 12c R1环境，不过确实效率很高，突然有一天因RAC 节点之间的private network 高latency导致频繁的 gc 相关等待，从而导致性能问题。

有时跟踪 Data Guard 后台服务很有帮助，因此我们可以查看匹配的 NSSn 和 RFS 跟踪。对于深入研究，我们还希望在 Data Guard 配置的两端运行 tcpdump 捕获，并且可能在中间的网络组件上运行。为了最大限度地减少设备上的处理开销和捕获文件中的噪音，我们希望数据包过滤器尽可能具体。

Linux中CPU负载高必须引起关注，通常需要先查看CPU使用类型，CPU使用分为us(用户进程)还是sy(内核调用)， sys通常不应该超过user , 数据库专用主机主要来自用户级的 CPU 时间（无论是“user”还是“nice”）。因此，当 CPU 时间的大部分时间花在内核（sys）中时，这表明出现了问题, %sys一般也不超过10%, 但是%sys超高这样的问题遇到好多次，原因有：NFS4 bug、 swap IO、安装了linux杀毒如卡巴斯基、3rd party modules、NUMA、cpu 中断、内核参数配置错误等

有个客户的多套RAC节点总是频繁的重启， 故障并没有时间规律，环境Oracle RAC 11G r2 ON OEL 6.9 , 当然首先建议要排除一些硬件共性的配置，如是否电源电压不稳?机器所在区域空调是否差? 是否同一个宿主机上的VM? 硬件是否有报错？ 一线同学说都排查过也做了些调整并未解决。 下面分享一些处理建议。

Trace File Analyzer(TFA) 是oracle用于分析和收集日志的程序，可以安装在独立或集群节点的数据库节点上。从Oracle12.2开始，这个工具包含在 RDBMS 软件中，当我们运行 root.sh 脚本时，这也是可选的，如果不需要，我们仍然可以跳过它,从19c开始Oracle将ORAchk，EXAchk，TFA等多个诊断工具合并入Autonomous Health Framework(AHF)，作为一个独立的安装软件，也被集成到了RAC安装介质中，AHF可以使用root或者非root用户安装，但是用root可以收集更全的日志

A core dump is an image copy of a processes state at the instant it ‘aborted’. It is produced in the form of a file called ‘core’ usually located in the current directory.

OSW工具不用多说oracle数据库环境建议采集OS系统数据的脚本集， 采集的数据可以拿到其它机器，如WINDOWS上分析输出图形， 在ORACLE 12c后 AHF自动健康框架中已自带， 同时还有oracheck等，当troubleshooting时使用tfactl 可以一并收集相对全面的日志数据,几年前记录过2篇OSW，不做过多介绍，这里简单记录一下在Windows上使用oswbba.jar分析时的一些小问题。

一套oracle single instance on AIX环境，数据库未启动，客户硬件只是扩容了内存OS重启后，sqlplus启库无法登录，sqlplus / as sysdba命令挂起。

1, rename sqlnet.ora
2, 检查了/etc/hosts
3, 尝试了listener可以启动

最近同事遇到一个案例，Oracle数据库频繁重启，数据库日志也是各种后台进程IO hang, 环境VMWARE，RHEL6, multipath, 华为存储。iostat显示问题时间段共享存储设备io 为0，%util 100%. RHEL官方有过相同案例，这里简单的记录。