ANBOB™

一套Oracle 19c （19.8）RAC dataguard环境，standby 总时自动crash， 报错提示是lms进程异常触发ora-7445 kcbzwb 在cache层的内部错误 ORA-07445 [kcbzwb()+2265] [SIGSEGV] ， 确认为oracle bug, 后期应该比较常见，记录一下。

客户一套Oracle 19c Dataguard的数据库环境，standby 端的总是会间隔性出现较大GAP， 同时DB alert log日志出现LGWR (ospid: 105521) waits for event ‘DLM cross inst call completion’ for N secs. 的现象，Standby端并未对外提供查询，同时也禁用了多实例日志应用，同时系统资源空闲LMS进程个数正常， 如果关闭其它节点只留apply log节点并不存在该问题， DLM 是Distributed Lock Manager 属于RAC架构中核心机制，实现多节点资源共享调度。

Row source statistics是在执行 rowsource（执行计划的一个步骤）期间花费的时间、返回的行数、缓冲区获取数和物理读取和写入以及工作区使用情况的一些统计数据。当启用统计信息收集时，这些统计信息填充在V$SQL_PLAN_STATISTICS和V$SQL_PLAN_STATISTICS_ALL（基于X$QESRSTAT和X$QESRSTATALL）中。

最近一套客户环境从12C 升级19c(19.9)后在我们的监控上Wait class “Concurrency”等待告警进入TOP, 但是从V$SESSION和ASH view中的活动(active)的会话并未显示这么严重等待， AWR的top event中同样也不存在， 但是算在了Wait Classes by Total Wait Time和Background Wait Events里面，具体的wait event为“latch: MGA shared context root latch” , 1小时的AWR些latch wait 时间高达55,141秒，

Prior to 12c,PGA_AGGREGATE_TARGET was the Parameter used to control amount of memory allocated to User Processes(mainly work areas). However PGA_AGGREGATE_TARGET is a soft target and not a hard limit. The actual PGA usage can be as high as three times of the value of PGA_AGGREGATE_TARGET.This can lead to memory swapping & performance degradation.

昨天在配置ASM instance参数时发现参数无法修改，提示ora-32000,即使是grid sysasm， 环境是新安装的oracle RAC，最近刚安装的19c 11RU，也并非是19.11 RU的新特性，主要还是安装过程中出过问题AUTOupgrade 失败，手动处理，没有更新集群状态。

前几天朋友问无论使用asmcmd rm还是rman 在删除一个归档日志时，提示ora-15028 文件正在被访问，分析是O002进程占用，该进程是oracle instance修改asm instance metadata的进程， 经测试是非致命进程，可以尝试kill, 不必重启instance. 下面是诊断方法。

oracle 11g后引入adrci 仓库管理trace文件，12c后更把把GI和DB全转到了adrci， 我还是比较喜欢用它小工具，今天一套友商安装的数据库使用adrci 查看日志提示No ADR base is set, 检查了$ORACLE_BASE环境变量也存在，同时也未使用symbolic links 目录，临时解决当然可以使用adrci中SET BASEADR_BASE DIR手动指定ADR BASE, 对于使用频繁的工具，手动set，不能忍。

对于UDTs自定义数据库类型是oracle扩展的数据类型，对一个对象存储更多的信息，在oracle8版本就存在， 可以在创建表对象用于列类型，前段在一套库迁移时遇到个问题，应用软件使用了ArcGIS 空间数据库组件， 对应数据库中的SDE schema用户，应用部署希望drop sde用户使用软件安装重新生成，但是这会导致其它用户的table使用了该用户的类型导致数据丢失。

Oracle 12c RAC 1个实例因硬件原因突然crash, 另一实例上的goldengate Extract 进程Lag At Chkpt 持续增加，read checkpoint并不动，开始是因为归档日志被rman备份任务备份后删除，但restore 归档日志从Recovery Checkpoint到当前确认都存在后依旧hang, 清除了BR 文件再次启动extract进程恢复正常

前几日在做oracle 迁移升级使用FTTS 从11.2.0.4 升级到19c pdb时，因为对象包含数据类型TimeStamp with Local Time Zone(TSLTZ )， 导入matadata过程中报错ORA-39360而终止，报错如下:
Full Transportable tablespace import fails with:
ORA-39360: Table “xxx” was skipped due to transportable import and TSLTZ issues resulting from time zone mismatch.

这是一套Oracle 19.4 的RAC 环境，硬件是IBM 大机LinuxONE(Zlinux), 节点出几次重启目前已确认是由于oracle代码级bug，cssd错误的Reference count 记录为0，导致再次ASSERT资源时异常终止。

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

The received warning means the kdump operation might fail and the crashdump parameter should be configured correctly. This is the procedure of kdumping:

The normal kernel is booted with crashkernel=… as a kernel option, reserving some memory for the kdump kernel. The memory reserved by the crashkernel parameter is not available to the normal kernel during regular operation. It is reserved for later use by the kdump kernel.
The system panics.

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

环境Oracle Exadata Machine(x7)环境， 节点1异常重启后无法启动，另他节点运行正常，从日志显示是gipc进程启动失败，清理network socket 文件启动成功。

Bugs fixed in each 19.0.0.0.0 Release Update and Releas […]

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

最近在整理巡检脚本时，发现在执行select client_name,status from dba_autotask_client;时耗时几十秒， 该SQL只是想检查数据库级的自动任务是否启用(如自动收集统计信息)， 返回的记录也并不多，只关心状态..

对于我这从事10余年的oracle dba从未像今年这样感觉到压力， 国产开源数据库铺天盖地的宣传，我依旧建议不要满目随大流式换库，因为数据库迁移经验对于不同的业务场景并非可以完全复制，昨天想装个openGauss小测一下，发现2.0新鲜发布，OpenGauss社区可以下载安装介质，openGauss内核源自PostgreSQL 9.2，是一款开源关系型数据库管理系统，采用木兰宽松许可证v2发行。