ANBOB™

最近有个客户发现oracle数据库中有些分区表并未收集统计信息，需要确认是统计信息作业是否启用？ 最近作业是否成功？如何列出需要收集统计数据的对象的问题？他的系统在周末收集统计数据，但想要检查本周是否有任何对象的统计数据已过时。如何加快统计信息收集？ 实际上，执行此检查非常容易， 使用dbms_stats包可以提供需要收集的对象列表。

在oracle rdbms on Linux的环境有时会在$ORACLE_HOME/dbs生成几十GB的core.NNNN的core dump文件，更甚至导致文件系统耗尽，影响oracle进程稳定性， core文件用于分析进程异常终止原因，不只是oracle数据库，在其它数据库环境也经常会产生，如openGauss系这类线程(threads) 式进程数据库如果遇到这类异常，就不会如oracle、postgresql这类进程(processes)式只影响某进程crash, 而是整个实例crash，这也是线程数据库缺点，但往往他们宣传时线程式时避而不谈。

一套测试环境因同事做过一些操作今天发现其中一个节点是crash，启动数据库第二个实例失败，提示ORA-01105: mount is incompatible with mounts by other instances， 我们都知道可能是两个节点间参数不一致. 简单记录一下处理，如果你遇到给希望可以参考减少诊断时间。

之前在我的blog记录过Troubleshooting Dataguard SYNC同步模式时网络问题 一则网络诊断的问题，通常如果因为网络不通因数白名单或防护墙问题较常见，或网络不稳定丢包使用ping traceroute也可能辅助诊断，但是对于一些客户端执行了几个SQL后随机出现中断或挂起还是比较少见，这里结合一个案例提供一个诊断方法。

最近一周遇到2例LGWR/CKPT 等待的问题，但这类问题往往只从top event分析容易走入误区，如显示top event是Log file switch (checkpoint incomplete) 或Log file switch或enq: CF – contention ,或是一个IDLE类的rdbms ipc message等待, 有时会在db alert log中显示ckpt has not moved for N sec等，建议先确认当时的IO系统是否正常。

在关系数据库中常见的一种需求统计表的记录的最大值或最小值，SQL中使用max min，为了最佳效率通常希望可以在列上创建索引，减少表段的IO量，如果可以可以使用更佳的执行计划如直接访问索引的头和尾（btree index的有序结构），减少index 块的访问，我们对比一下几款数据库在该方面的能力。

近期一套Oracle Database 12c （12.1.0.2.0）数据库在RAC ADG , 在standby端一个查询select语句涉及分区表， SQL解析时触发ora-600 [kksgaGetNoAlloc_Int0], [34], [24], 因为11.2.0.4对分区表对象在DDL后除了基础对象外引入了一个KGL handle 多版本对象，当分区计数和详细信息之间不匹配报错。

今天在调试我的oracle数据库巡检脚本odbhc时，发现一套19c rac 测试库的top 1 event为 “dispatcher listen timer” ， 影响脚本的显示，该数据库并没有配置共享会话模式，实际上是一个idle wait event算是AWR统计类Bug 19865595 ， 后期版本已修复。

最近在做一批Oracle database datafile 从1个ASM diskgroup 迁移到另1个ASM diskgroup时，单个datafile一直无法完成或挂起或多出几倍的时间，正常时1个datafile 30g在150s, 而突然间变的600s都没有完成， 数据库版本oracle 11.2.0.4 。 问题时尝试查询v$asm_diskgroup[_stats]或asmcmd lsdg一样很慢或hang。 登录ASM实例查询会话在等待“buffer busy”和”GCS lock esc” 这里简单的记录一下。

最近一个客户的数据库归档空间满，导致数据库挂起，无法连接，sys登录时提示ORA-00257: Archiver Error, 确认数据库使用的是flash recovery area，从oracle 10g R2提供了V$FLASH_RECOVERY_AREA_USAGE 可以查看flash recovery area中每类文件使用的比例，但是加起来不足10%，且当前flash recover area size已经达2TB, 因为无法远程，临时更改数据库归档路径为具体ASM DISKGROUP不再使用FRA, 这里简单记录一下排查方法

近期一个客户oracle 11g 11.2.0.4 的环境， 业务出现拥堵， 活动会话的等待事件是latch free, 并且P2# 显示是一个不常见的mostly latch-free SCN ，简而言之就是过去oracle版本用这个latch 保护scn，现在已经不在需要的一个latch bug.

如果你不幸数据库在启动时提示ora-600 16703,那很可能是从网上下载安装的oracle数据库软件安装介质中被人篡改了， 增加了启动时判断启动时间，然后删除tab$数据字典的老套的破坏方法， 这个网上的修复方法很多，情况有时也不同，建议找专业人事修复且不要造成二次破坏，这种如果只是最初的版本，修复还是相对比较简单，顺利的话个半小时，0数据丢失恢复

当您尝试在其中一个数据库会话正在执行 NOLOGGING 操作时，尝试将数据库置于 FORCE LOGGING 模式时，将观察到“enq： XR – database force logging”等待事件。这很容易证明。 连接到数据库（例如会话 1）并执行 NOLOGGING 操作：通过从不同的会话（例如会话 2）执行以下 SQL，将数据库置于 FORCE LOGGING 模式：您将观察到 Session-2 不会立即完成，而是等待enq: XR – database force logging。

oracle ASM 从12c后引入了诸多特性，如FLEX ASM、Increased ASM storage limits、ASM instance V$ACTIVE_SESSION_HISOTRY 、ASM Disk Scrubbing外，最近发现还有一个关于ASM DISK rebalance 的增强EXPLAIN WORK FOR命令。12c 中新的 EXPLAIN WORK FOR 语句测量给定 ASM rebalance所需的工作量，并将结果输入 V$ASM_ESTIMATE 动态视图中.

近日，一位客户的Oracle 19c（19.18）环境中出现了一些查询堵塞等待较高的“latch free”情况。通过分析AWR报告中的ASH（Active Session History）数据，我们发现某些查询频繁等待“latch free”，并且p2值对应的latch号为39，latch名称为“object stats modification”。

“latch free”等待事件在Oracle 11g之后相对较少见到，通常我们会看到具体的latch名称。 “object stats modification” latches 又是一个较为罕见的等待事件。为了便于后续跟踪和分析，这里记录一下该问题及其相关细节。

oracle 11g R2环境1组normal冗余的ASM DISKGROUP包含3个cell的，每个cell为1个failgroup, 每个failgroup有48块ASM disks.因为一些硬件原因1个cell掉了19块disk，但offline后并未reblance完成，超过了“_asm_disk_repair_time”时间内没有online，被磁盘组自动drop force, 手动reblance时因为有1块asm disk使用不均衡free接近0MB，所以rebance会提示ora-15041错误。 此时add force与undrop均报错ora-15047. 处理rebalance需要空间，但加空间需要等上一个reblance完成的死结循环中。

SQL Translation框架是 12c 中的一项新功能，使开发人员能够在不更改底层代码的情况下替换SQL代码。这个特性是sql profile baseline的增强，原来是可以不动SQL文本替换执行计划，现在是连sql文本都可以“隐式”替换。这功能可用于在异构数据库向oracle迁移时，替换SQL代码。

《如何恢复Truncate sys.IDL_UB1$？》之前分享过这个对象被清空时的恢复，近期又有用户发现system表空间占用较大，发现IDL_UB1$是top对象，于是乎采用取表DDL，rename原表名，新建该表，数据导出导入方式重建该表。但是发现rename IDL_UB1$表，新创建IDL_UB1$后，exp无法导出，所有DDL无法执行, 包括无法rename回退，庆幸的是当前数据库还没有重启，否则就无法正常启动了，恢复更加复杂。

前不久一套oracle 12c RAC环境，客户反馈数据库出现过行锁enq: tx row content和library cache lock。blocker session为dbms_scheduler执行的sql是在收集统计信息，同时db alert log频繁提示qsmqChkOCMV : Timeout while locking object:NNNN, 简单记录.

最近客户一套oracle 19.14 standalone Database做的cascade dataguard环境，暂且认为是A->B->C三台单实例, 但总是A->B的延迟，从oracle 12c后引入real time cascade，所以如果依赖该特性对延迟要求较高， 分析A->B延迟发现，B库总时会出现GAP,并且未自动FAL，需要人为干预, 并且主库alert日志报错出现:
ORA-03135: connection lost contact
TT02 (PID:64459): Error 3135 for LNO:3 to“xxx”。