ANBOB™

随着数字经济的快速发展和数据量的激增，高性能数据库系统成为企业业务的核心基础设施之一。在全栈国产化的背景下，如何构建高效、可靠的存储架构，实现 100 万 IOPS 的性能目标， 做为集中式数据库的基础设施提供支持，成为企业关注的重点。本文探讨通过 NVMe SSD 和硬件 RAID 卡组合，构建集中式数据库系统的技术路径。如利用 4 块NVMe SSD，在 RAID 0 下实际性能可超过 1,600,000 IOPS，完全满足高负载数据库的需求。

最近遇到两起运行在 Linux 7 上的数据库主机问题。由于操作系统内核的内存使用率高，导致 Oracle RAC 的性能受损或无法使用。内存主要被 Slab 的 SUnreclaim 区域占用。这些案例有一个共同特点：都使用了分布式文件存储系统。这次的情况是生产环境中有 750G 的内存，而 SLAB 使用了接近 200G 的内存，且主要是由 SUnreclaim 区域占用的。特此记录这个案例。

前几天，一位朋友的Oracle RAC 2-nodes（Linux 6物理主机，HPE）系统计划进行HBA固件升级。幸运的是，他们采用了滚动节点的升级方式。在节点1升级FC HBA固件（Firmware version）并重启后，CRS启动失败，所有ASM DISK丢失，且在重启时遇到了操作系统无法启动的惊险情况。这里，我分享一下处理这种问题的经验。

现象oracle 19c RACon linux 7.6， GI alert log一直在输出“2024-04-28 01:07:20.305 [GIPCD(53662)]CRS-42216: No interfaces are configured on the local node for interface definition virbr0(:.*)”，但不影响RAC的稳定和使用，在安装clufy时有时也提示PRVF-7617，在oracle 11g还有bug 记录可能影响私网通信 简单记录处理方法。

最近，有一位海南客户报告了Oracle 19c RAC数据库启动时出现的错误，提示ORA-07445: exception encountered: core dump [ipcor_net_get_ibdevname()+71][SIGSEGV]。这个崩溃报告的异常原因是由于Oracle的一个bug引起的，但根本原因是由于数据库无法访问某些特定设备的API而导致的。通常这样的问题源于硬件方面的原因。在这里，我只是简要记录一下问题的表现。

主从同步和Raft/Paxos是两种不同的技术，用于不同的目的。主从同步主要用于数据库的复制和读取性能优化，而Raft/Paxos主要用于确保分布式系统的一致性。虽然它们都涉及到数据的复制和分布式系统，但它们的设计目标、实现方式和一致性保证都有所不同。

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

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

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

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

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

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

最近一套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问题，简单记录。

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

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

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

近期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还算不复杂，下面简单分享