ANBOB™

oracle升级是一项大工程，性能、语法、函数变化都可能导致应用无法使用，最近几年升级19c的较多，一定要做足升级前测试，并不是只有wm_concat函数没了，再手动创建一个那么easy, 前几年升级12c是发过一个案例《Troubleshooting ORA-00979: not a GROUP BY expression after upgrade Oracle 12C》 ，也是同一个SQL在升级后提示语法错误。 这里演示一个19c 的另一个语法问题，后面会陆续在微信公众号分享 《oracle19c 避雷系列》。

“rowsets”这是一个新的 Oracle 12c 特性, 是SQL层执行计划相关的内部优化，在12.1 中存在wrong result的bug, 解决办法同样是禁用rowsets或使用event 10055禁用特定的使用场景。如果在12.1中是建议禁用rowsets, 但毕竟是一个优化项，19c 版本也做了扩展建议保持启用

《PGA 一点认识》《Know more about PGA_AGGREGATE_LIMIT 12c 19c》 看到限制PGA的参数有_PGA_MAX_SIZE、 _SMM_(PX)_MAX_SIZE、PGA_AGGREGATE_TARGET、PGA_AGGREGATE_LIMIT ，最近看到一个案例在执行存储过程时，为了提高SQL性能手动增加_PGA_MAX_SIZE参数值，如在数据仓库环境可能更明显，当把参数_PGA_MAX_SIZE 调到4GB以上时（default 2GB），依旧遇到了ora-4030 错误, trace 文件中显示上限达4GB的上限，Process Map Dump 达65537行。

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

前几天朋友问无论使用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 文件启动成功。