LMSn not running in RT (real time) mode Oracle 19c RAC?

Oracle 希望在数据库主机CPU使用率枯竭时,尽可能让核心的几个后台进程可以最大优先级获取CPU, 当然CPU过高会导致I/O 响应时间变长和网络延迟增加,也会间接影响数据的整体性能, 使用ps -c在查看LMS时发现没有在RT模式引起了注意,在19c中 LMS还是有一些变化,下面简单的记录

Alert: Linux平台使用udev绑定ASM存储时,频繁的systemd-udevd导致CPU使用率高

最近查询时发现一套Linux(Suse Linux 12)平台上的Oracle主机CPU使用率偏高,该数据库并不繁忙,从top中发现大量的systemd-udevd 进程,是CPU的主要花费进程, 该现象并不局限于Suse,RHEL和OEL同样可能存在这些现象, 通常是当udev加载时,即使系统当前并无任何磁盘存储的调整,也会存在该现象。

Bugs fixed in each 19.0.0.0.0 Release Update and Release Update Revision(until 19.14)

Bugs fixed in each 19.0.0.0.0 Release Update and Release Update Revision This document lists the non-security important bugs( NOT ALL bug fixes) fixed in each 19.0.0.0.0 Release Update and Release Update Revision(RU/RUR). RU/RUR patches are cumulative and so each RU includes fixes from all previous RU’s/RUR’s. For details of the RU patches please see Document:2521164.1 … Read more

RHEL7(Linux7)安装Oracle 11g R2(11.2.0.4) RAC 问题小结

最近一例在11.2.0.4 2NODES RAC on linux7 增加节点时不是很顺利,此版本是ORACLE的认证版本但是还是兼容性还不是那么顺滑,9年前分享过在linux6上addnode还相对顺利《Oracle 11g R2 RAC addnode (增加RAC节点) 实践和注意事项》。 遇到的问题也较多涉及IB,网络,bug, 损坏,补丁等,简单记录。

Troubleshooting OGG Char datatype from mysql to ogg fill chr(0)

前几年处理过一个<当C语言的程序处理 chr(0) or ‘\0’ 时的ORA-01008 Case>故障案例, 近期又遇到一个案例是在Golden Gate同步数据时遇到的问题,发现ogg在同步时对于char类型的字段,不足指定长度时,OGG使用的是chr(0)补充, 而对于已有数据是默认chr 32(空格)补充,导致无法匹配问题。

x$kcbbes checkpoint

增量检查点会引发checkpoint queue(dirty queue)上的脏块递进地被写出,每三秒CKPT后台进程将计算检查点目标RBA(Redo Block Address),当增量检查点发生时所有在目标RBA相应时间之前被弄脏的buffer块都当被写出…

Troubleshooting Select 产生Redo分析案例

众所周知, 在oracle数据库中redo日志是非常重要的文件,oracle代码设计根据Write-Ahead-Logging预写协议,DBW不会在LGWR写入描述该块更改方式的redo之前将已更改的块写入磁盘, redo 日志文件中记录了所有的数据库变化,通常对于Select 查询类并不会修改数据,也不应该产生redo 记录,但是还是有几种特殊场景, 前几日一个客户提出疑问,他注意到在数据库SQLPLUS中set autotrace on中执行一条查询总是出现大量的redo和伴随physical read

Troubleshooting Performance event ‘control file sequential read’

前段时间整理过关于control file的一个等待《Troubleshooting performance event ‘enq: CF – contention’》, 这里再记录关于control file的另一个event( 这里没用等待), 此event只是通知类event,和db file sequential read类似为数据库的I/O类操作,但wait class并非USER I/O,而是SYSTEM I/O. 问题时段control file sequential read占到了AWR top 1 event, 占用约90%的DB TIME.

Troubleshooting DB load high wait ‘ON CPU’ by New ASH in 12c R2

本次数据库负载异常或故障突然CRASH,而AWR snapshot没有形成时,在12c后中的ASH每5分钟逐渐式flush disk,已不会刷新太频繁而增加系统负载,也不会等到AWR SNAPSHOT时间大粒度间隔而突然重启而ASH数据缺失无法分析。本次就是利用DASH中SQL两个时间段的SQL执行持续时间判断SQL变慢而导致的业务积压,而非SQL执行量增加,或执行计划变化。

Oracle数据库当遇到存储磁盘坏道时的处理(DBV-00102)

数据库环境有时会因为硬件磁盘问题导致数据不可读,而硬盘坏道”便是这其中最常见的问题, 当出现因为磁盘坏道里更加棘手,无法移动或跳过,更甚至因为有坏盘在换盘后RAID重组出现文件系统勘误导致文件为0bytes,增加恢复难度,例如使用dbv 检查时会出现如下报错:

Oracle 12c/19c ADR trace dest disk busy (100%) when ‘ls’ trace files

最近遇到几次故障升级oracle 12c后,相同的硬件有几次instance crash同时伴有LGWR 核心进程N seconds not move现象,OSW中vmstat ‘B’列会伴有突然大量的blocked(通常是I/O)问题,mpstat/iostat 显示$ORACLE_BASE所在本地文件系统出现90-100% busy现象, ps 显示LGWR和一些FG进程同时在等待相同事OS Kernel function address。