Linux多路经DM multipathd注意事项

对于服务器与存储分离的数据库环境中,业务数据存储在外挂存储设备上,常见于之前的oracle RAC等集中式数据库,同样也可以用于达梦或mysql数据库,服务器与存储连接常用的有基于NSF的NAS存储和基于Fabric协议的SAN存储,而企业中对于数据库常使用SAN存储,需要专业硬件如HBA卡和SAN交换机。进一步为了高可用一般是多条路径的方式。对于multipath环境遇到过几个客户配置了4条链路甚至6条,因为一批链路offline,没有switch链路,导致数据库一样会出现I/O失败现象。这里简单整理几个multipath相关的配置参数。

Troubleshooting Linux7 panic System crash shows exception RIP: pagetypeinfo_showfree_print

最近一套oracle RAC on Linux 7环境1节点操作系统重启,分析又是DB和CRS层无错误日志,还好OS有配置kdump, 生成了vmcore文件, 分析是在cat命令时触发操作系统panic, cpu 遭遇hard lockup,出现system crash. 调用堆栈显示exception RIP pagetypeinfo_showfree_print。

,

Troubleshooting Oracle Grid Infrastructure startup fails with Linux Inode full

最近一个客户一套较老的ORACLE RAC集群长时间无人看管,由于Oracle Grid Infrastructure(GI)的$ORACLE_HOME所在文件系统的inode耗尽,导致了gipcd无法启动,并且最终导致两个节点崩溃。 GI alert log提示gipcd无法启动,但实际是因为GI的$ORACLE_HOME所在文件系统inode耗尽,简单记录一下。
No space left on device (28)

,

Linux core.NNNN文件导致文件系统耗尽

在oracle rdbms on Linux的环境有时会在$ORACLE_HOME/dbs生成几十GB的core.NNNN的core dump文件,更甚至导致文件系统耗尽,影响oracle进程稳定性, core文件用于分析进程异常终止原因,不只是oracle数据库,在其它数据库环境也经常会产生,如openGauss系这类线程(threads) 式进程数据库如果遇到这类异常,就不会如oracle、postgresql这类进程(processes)式只影响某进程crash, 而是整个实例crash,这也是线程数据库缺点,但往往他们宣传时线程式时避而不谈。

,

Linux 重启失败Superblock(SB) last mount time is in the future

最近一套华为虚拟化环境中的虚拟主机RHEL linux 6.N 操作系统,调整了memory资源后做reboot重启失败,检查控制台输出提示一个文件系统Superblock last mount time is in the future是2059年,但当前时间是2023年,可能还并不是类似cmos电池问题,重置时间为1988年等之前的时间。启动界面提示要做fsck 手动修复,这里简单记录一下。

,

分析SQL*Net message from client连接间断性问题

之前在我的blog记录过Troubleshooting Dataguard SYNC同步模式时网络问题 一则网络诊断的问题,通常如果因为网络不通因数白名单或防护墙问题较常见,或网络不稳定丢包使用ping traceroute也可能辅助诊断,但是对于一些客户端执行了几个SQL后随机出现中断或挂起还是比较少见,这里结合一个案例提供一个诊断方法。

Troubleshooting ORA-00600 [kjucvl:!busy], [8] crash & Different datetime between RAC nodes after restart

最近一套oracle 11.2.0.3 2-nodes RAC on AIX环境数据库,触发ora-600 [kjucvl:!busy] 和 ORA-00600: , : [kjuscv]后db instance crash, 但重启后使用plsql dev客户连接实例的两个节点,sysdate返回不同的时间,同时从db alert log 的时间也能发现实例重启后日志倒退了8小时,看来还是timezone问题,简单记录。

,

注意:HAProxy可能限制MySQL的最大连接数

MySQL架构中经常会遇到和keepalived、HAProxy中间件的组合,解决MySQL的高可用与负载均衡的需求, 但是会给数据库配置带来复杂性。如果没有把这些组件与MySQL级联配置,可能会出现一些意向不到的问题,了解HaProxy就变的重要,近期一个客户在这样的环境做压力测试时,MySQL数据库的max_connections最大链接数已调整到10000, 但一应用反馈链接报错,从数据库上看链接最大也就在2000左右,并且MySQL日志未出现报错,

, , ,

Troubleshooting XFS filesystem损坏恢复,与ASM start fail案例

上个月那次“盆泼大瓢”式的暴雨差点导致一客户的服务器上船,但还是导致电源故障,在UPS支撑了一会儿中断,再次启动RAC中的一个节点,查看/u01 oracle 软件所在的文件系统无法使用, 重启后操作系统无法启动,后修复文件系统再次出现ASM无法启动问题,简单记录一下这个故障。

,

Troubleshooting Oracle db crash caused by Linux OOM kill 内存耗尽

最近半年遇到了至少有4例因为oracle内存耗尽出现的OOM kill oracle进程,DB instance crash的现象, 常见原因是内存分配不合理,如过大的Hugepage或没配置Hugepage, 或过大的SGA,或有备份导出任务占用过多的cached内存。 之前整理过《Troubleshooting Out-Of-Memory(OOM) killer db crash when memory exhausted》, 仅记录一下问题现象

Troubloshooting Oracle RAC node reboot and OS log show “kernel: qla2xxx[ ] Abort command issued”

近期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系列:ERROR. You do not have a compatible version of OSWatcher to use with oswbba.

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

,

Troubleshooting Linux high %iowait and many Processes stuck in D state

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

如何在麒麟Kylin Linux V10 SP1静默安装 Oracle 11g (11.2.0.4)单实例

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

,

Linux message show “systemd-logind: Failed to start user slice xx, The maximum number of pending replies per connection has been reached”

最近操作系统的问题有点多,上周有套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)” 信息,找我协助分析一下。

,

How to diag High Memory Utilization on HP-UX ? (内存使用高)

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

AIX 平台分析TOP CPU使用进程ps和topas差异

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

How to config Hugepage when 1M hugepagesize on IBM LinuxOne

对于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会如何显示?

How to trace DB processes system calls using Strace -k

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

Troubleshooting CRS Node Evictions on RHEL7 hang messages show ‘NMI watchdog: BUG: soft lockup’

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