ANBOB™

在oracle中持续的为online（Zero Downtime）引入了大量的特性，但在国内可能用的很少，互联网搞出的“灰度发布”一词也是这个目的， 在对正常运行时间要求较⾼的数据库上，将代码更改发布到执行频繁的程序包中的 PL/SQL 会带来很多挑战。在执行程序包时，⽆法获得DDL 锁来编译程序包，那么如何在不停机的情况下做到这一点呢？

一套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 失败，手动处理，没有更新集群状态。