ANBOB™

近日一银行客户巡检发现一内存使用率高的oracle 19c(19.4) RAC数据库环境，因为是linuxone拆分的多机器，内存分配不是很充足，在当前动辄1T内存可能并不易发现，分析内存使用主要是因为Oracle的多个后台进程ora_wNNN_xxx进程，每个进程PGA使用近600MB。WNNN后台进程是SMCO(Space Management Coordinator Process)的slave进程，从oracle 11g引入的智能空间预分配space preallocation的新特性，在oracle 12c后SMCO也负责生命周期管理ILM(Information Lifecycle Management).由于SMCO 或W00n在完成space preallocation过程中遇到的问题时，可以考虑禁用该特性.

当事务查询或使用了flashback query（如expdp中指定了flashback_scn）中指定的时间或SCN小于表及附属对象的LAST_DDL_TIME时，会遇到ORA-01466: unable to read data – table definition has changed的报错，因为一些alter table 或truncate table等DDL操作会使表相关的UNDO数据失效，导致查询之前的数据镜像报错，提示很明显，表的结构发生了变化，常见EXPDP导出过程中，报错如下:

一套oracle 11gR2数据库环境， SQL监控工具在采集SQL性能指标时，报错 ORA-00600: internal error code, arguments: [733], [1258291280], [top call heap], 记录一下该问题。

希望是龙年春节前的最后一个故障， 一客户Oracle 19c RAC环境中，做index rebuild online操作进行过程中，kill重建索引的会话，后面查询索引相关的表提示如下报错：ORA-00600: internal error code, arguments: [kkdlfjou_1], [], [], [], [], [], [], [], [], [], [], []

上周有个客户咨询Oracle数据库历史时间SQL性能变慢的问题, 还是个偏重要的核心业务，当然最终确认因为人员的一些变更操作非专业性，导致JOB未运行，产生的数据累积，思考一些问题，Oracle 9i没有AWR, 没有ASH, 甚至当时或当前国内也是没有太多的技术团队储备，是不是像极了现在的国产库现状？

之前曾经在《oracle add column xx default value 增强(二)》记录过，在日常运维中增加column是常见的操作，对于大表增加列时是否会导致回写表还是只修改数据字典影响DDL的执行时间和停机窗口长短。之前也在《“alter table ” modify column in Oracle、MySQL、PostGreSQL(数据库比较系列十三)》记录修改column时不同库的表现， 这里简单记录测试一下当前主流的几个库对于add column的现象。

在Oracle存储空间中，表空间的大小（dba_data_files size）几乎等于空闲空间的大小（dba_free_space size）加上段的大小（dba_segments size）。通常情况下，这两个值之间的差异是很小的，可能是由于一些header和bitmap block未计算在其中，但这些差异通常是很小的，以KB或MB为单位。然而，同事遇到了在一个bigfile表空间发现巨大的差异，达到了10TB以上。现在的问题是，这些空间去了哪里？

最近遇到一套oracle 12c r2 RAC 多租户 +ADG的环境， 所有PDB中使用expdp导出失败报错 ORA-31626 ORA-31637 ORA-12805， 尝试改用exp更奇怪的现象是，exp部分表报EXP-00064错误，但该表确实不是嵌套表，而且CTAS创建一个复制表就可以正常导出exp, 但expdp同样报错，表列类型就只是number,char,blob。经过反复诊断测试找到问题并还原..

最近有个客户的Oracle Exadata x8 数据库主机操作系统总是频繁的重启，重启前在DB,CRS层没有任何错误信息， 当时的OS负载也比较低，仅从exawatcher的mpstat能发现在重启前15s左右部分CPU core sys使用达100%。 操作系统有配置kdump生成了dump信息，发现在CPU在等待Watchdog detected hard LOCKUP on cpu 11， 堆栈调用中包含rds_send_remove_from_sock，简单记录。

试想一种场景：如果一个tablespace有100个数据文件， 90%+表空间USED，后来drop table 70%, 现在因为ASM DISKGROUP 紧张，要回收部分datafile（drop）归还ASM 给其它TABLESPACE使用 , 原表空间move table/lob 都是按oracle内部算法find free extent 从所有可用datafile(bitmap in header for LMT )， 目前除了新扩存储空间，move到新表空间还有其他方法吗？这是一个难题。

在Oracle PL/SQL中，在循环中捕获异常并继续执行可以通过使用异常块实现。如循环kill session 可能会遇到session marked killed报错中断，或flush shared pool 中的sql时，因为有部分sql keep， 遍历时会遇到ora-6596 错误 ，下面是一个简单的示例，演示了如何在PL/SQL循环中捕获异常并继续执行：

在Oracle 12c中你可以使用 “ALTER TABLE…MOVE ONLINE”， 在线移动LOB段 (Large Object)到其它表空间,而不会影响在线业务. 在移动空间或整理表空间碎片场景提供了遍历,此方法适用与CLOB和BLOB。 下面演示一下使用方法。

前几天看到有OB用户留言，提到OceanBase很可能是出于对他们需求的考虑，而应用中以前对ORACLE报错的依赖。这表明现在数据库厂家在满足各种甲方要求时也颇为无奈，在应用的兼容性上做了种种让步。就对于会话1事务中，会话2 select for update nowait相同的报错场景，我简单测试一下在其它国产库上是否还不如Oceanbase. 为了方便横向对比，这里我再简单的附上ORACLE 与OB的报错。

常常有客户配置oracle dataguard 1对多或级连(cascade) standby， 当需要一个测试环境时，通常考虑拿一个standby激活或snapshot dg，但如果在激活为可读写数据库时(Failover)，如果提前DG参数没有清理，可能导致剩余standby database无法继续应用日志，这里简单记录。

最近一个客户的Oracle 11g RAC 一个节点操作系统（Linux7）重启后，CRS无法启动，另一个节点(NODE2)未重启暂时正常。查看GI日志是Vote disk无法读取，sd设备dd正常，kfed read asmdisk失败，使用udev映射，说明问题出在udev, 简单记录该问题。

故事从一个客户正在将数据库平台从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从主查询过滤。下面简单测试。