提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
数据库oracle
故事从一个客户正在将数据库平台从Oracle迁移到OceanBase的过程中说起。在并轨生产运行过程中，应用报告了ORA-54错误号，这让Oracle的数据库管理员感到震惊，并花费了大量时间来进行分析。然而，他们最终发现这个错误是由OceanBase的驱动程序报出的。在尤其有些客户一点儿问题全中心排查躁动，这类报错让Oracle DBA分析oracle数据库，确实会让人要想爆粗，浪费了甲方的付费的乙方资源，同时还不利于故障定位。 下面对比一下oracle和oceanbase的resource busy报错。
朋友一篇《troubleshooting not JPPD cause View is a set query block》引起我的兴趣，想在测试环境尝试验证一下这个问题，除了统计信息外，这类问题可能是因为升级导致的或同版本的两个环境数据库执行计划不一致，可能因为DB参数不同或补丁修复相关，如何在那么多不同的配置中找它呢？在我们没有MOS或一些原厂内部资料时有没有一些小技巧? 之前有搞过一个pd_test.sql暴力尝试的方法，复现案例的过程往往有时也不易，这里从这个案例发现一些好玩的记录一下。
相信有时数据库Oracle出现ora-4031时trace中显示’KGH: NO ACCESS’出现在top 10，或检查v$sgastat可以发现’KGH: NO ACCESS’ 区占用较大空间, 主要是启用了ASMM或AMM时，从shared pool或streams pool 延迟切换内存给buffer cache, 以增加buffer cache大小时，原子池中会标记为’KGH: NO ACCESS’， 下面简单的记录。
最近一个客户一套较老的ORACLE RAC集群长时间无人看管，由于Oracle Grid Infrastructure（GI）的$ORACLE_HOME所在文件系统的inode耗尽，导致了gipcd无法启动，并且最终导致两个节点崩溃。 GI alert log提示gipcd无法启动，但实际是因为GI的$ORACLE_HOME所在文件系统inode耗尽,简单记录一下。
No space left on device (28)
在关系数据库中两表关联在oracle中使用IN( subquery)的语法很常见， 但kevin发现在MySQL中subquery使用MAX聚合参数时，会导致主查询Full scan而无法使用索引范围扫描, 当遇到大表时可能性能下降明显 ，测试发现有的库使用子查询做为驱动表，有的是使用filter从主查询过滤。下面简单测试。
最近有个客户发现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 又是一个较为罕见的等待事件。为了便于后续跟踪和分析，这里记录一下该问题及其相关细节。