Troubleshooting oracle wait “reliable message”

“reliable message”它是一个通用的等待事件,用于跟踪 Oracle 数据库中多种不同类型的通道通信。通常这是一个良性等待事件,可以忽略,如果占比过高需要诊断,一旦确定了较长的等待时间是否是由于频率、所涉及的 SQL 和包造成的 ,在oracle 11g较常见,主要有两个bug. Troubleshooting High Waits for ‘Reliable Message’ (Doc ID 2017390.1) 显示“If there is no performance issue, these waits can be ignored.”

Performance tuning ‘free buffer waits’ and ‘db file async I/O submit’

环境Oracle 11g(11.2.0.4) on RHEL6.9, 文件存储在SATA SSD的文件系统,每秒redo 50-100MB, 存在部分时间段40多组2GB online redo logfile 同时”active”状态的现象,cpu使用率60%左右。除了优化checkpoint外发现有2个少见的TOP event, 查看FG top event为’free buffer waits’, BG top event为 ‘db file async I/O submit’。

multi-version read consistency in Oracle、MySQL、PostGreSQL(数据库比较系列十二)

ANSI/ISO SQL 标准定义了4 种事务隔离级别,对于相同的事务,采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的,在Oracle 中READ COMMITTED 则有得到读一致查询所需的所有属性,在其他数据库中的读READ COMMITTED 可能会有不同的答案, 最近有个客户在测试migrate oracle to postgreSQL测试发现一个批处理的结果并非一致,

VIEW dependencies in Oracle、MySQL、PostGreSQL(数据库比较系列十一)

在有些程序员开发习惯中,喜欢为了应用代码的简洁或复用,而在数据库创建一个复杂关连查询的VIEW,甚至是VIEW套VIEW嵌套使用, 这里就有个问题如果上线后如发现依赖的表字段类型或长度不足时,修复一个view依赖的table列时发现在oracle、mysql、postgresql(本篇等同pg)中有不同的表现, 尤其是使用postgresql的用户需要格外注意, 因为pg 不允许直接修改

Troubleshooting ASM allocation is failed due to ORA-4030 though OS has enough free memories.

某客户一套Oracle 11.2.0.4 4-node RAC ON RHEL 7.6 环境 ,ASM High冗余Diskgroup 有600TB存储(没错是个超级大库), 其中有1个1TB的ACFS DG. 一日突然节点1个节点ASM和DB实例crash, 重启后正常, 分析当时的日志是ASM 实例的VDBG后台进程出现的ora-4030错误,目前需要分析一下原因。 简单记录。

Troubleshooting Oracle RAC a node Fails to Join the Cluster with “no network HB”

近日1客户环境的oracle 12cR2 6-nodes RAC多个节点脑裂后无法启动加回cluster, 分析日志又是经典的“has a disk HB, but no network HB“, 最近安全加固需求颇多,当心过度封锁影响到了RAC 间的interconnect 通信。 这里简单记录一下case现象的分析方法。

列顺序占用存储大小的影响 in Oracle、MySQL、PostGreSQL(数据库比较系列十)

在创建表时,如果相同的列类型,不同表列的顺序是否会影响数据库占用空间大小?使用oracle、mysql或postgresql是不是相同的表现呢? 不是的Postgresql近期发现空间使用会因为columns的顺序而占用不同的大小,当然也和实际的数据有关,简单的测试。

Troubleshooting 19C(19.4) CTSS start failed “Failed in clsctssslave_sync_with_master [9]” on LinuxONE

某客户一套linux container环境(LinuxOne大机)中的Oracle 19c RAC, 在启动阶段总是因为CTSS资源无法启动,导致Crs重启后需要手动干预, 通过kill local node gipcd.bin进程可以启动成功。多套环境有这问题,看来可能是Oracle软件在该环境存在缺陷,简单记录处理方法。