Alert: Oracle 19c ORA-30481 or ORA-7445 [qecgoc2()] _optimizer_aggr_groupby_elim

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

12c 新特性rowsets(_rowsets_enabled=true) bug,19c bug ORA-00600 [qesrLoopOverSetRowP:rows]

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

, ,

Troubleshooting 19C DG standby crash with ORA-07445 [kcbzwb()+2265] [SIGSEGV]

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

Troubleshooting LGWR waits for event ‘DLM cross inst call completion’ 案例

客户一套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执行计划的统计信息

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

Troubleshooting: Oracle 19c wait event ‘latch: MGA shared context root latch’

最近一套客户环境从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秒,

,

Know more about PGA_AGGREGATE_LIMIT 12c 19c

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.

Troubleshooting ORA-32000 when modify ASM spfile (oracle 19.11)

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

adrci show ‘No ADR base is set‘ 解决办法

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

Transportable Tablespace Failed with ORA-39360(TSLTZ datatype), How to continue ?

前几日在做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.

,

19c(19.4) RAC crash CSSD with ASSERT clsssc.c error On LinuxONE

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

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

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

,

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

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

Troubleshooting DB session spin call java function

一天客户问有个SQL执行中好像是hang了,当前的session对应的v$session.event是‘gc current grant 2-way ’, 之前运行都是秒级,现在已经跑了1个小时还未结束,通常看到这个event会怀疑是GC出了问题,然后就走错了路, 下面看一下这个案例。

,

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.

Oracle 12C新特性: Attribute Clustering

提起表的cluster factor集群因子可能都并不陌生,反映了表上数据分散的程度,Attribute Clustering这是Oracle数据库版本12.1.0.2中的一项新功能,该功能允许dba在将表记录在insert写到磁盘时能否保持顺序,保持较好的cluster factor,

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 检查时会出现如下报错:

,

Oracle19c手动清理PDB SYSAUX中的大对象如WRI$_ADV_OBJECTS (ORA-65040)

近期一客户19c RAC CDB数据库的SYSAUX表空间增长超大,分析原因为Optimizer statistics advisor特性导致的WRI$_ADV_OBJECTS对象记录数变多, 以下为清理方法。