ANBOB™

试想一种场景：如果一个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 RAC集群长时间无人看管，由于Oracle Grid Infrastructure（GI）的$ORACLE_HOME所在文件系统的inode耗尽，导致了gipcd无法启动，并且最终导致两个节点崩溃。 GI alert log提示gipcd无法启动，但实际是因为GI的$ORACLE_HOME所在文件系统inode耗尽,简单记录一下。
No space left on device (28)

最近一套ogg环境反馈做了些磁盘维护后抽取进程abended， 查看ggs日志发现有提示OGG-00662 OCI ERROR ora-03113 ora-03115和OGG-02078 extract encountered a fatal error错误，启动后使用ggsci info ext xx查看RBA无变化,简单记录一下该案例。

在关系数据库中两表关联在oracle中使用IN( subquery)的语法很常见， 但kevin发现在MySQL中subquery使用MAX聚合参数时，会导致主查询Full scan而无法使用索引范围扫描, 当遇到大表时可能性能下降明显 ，测试发现有的库使用子查询做为驱动表，有的是使用filter从主查询过滤。下面简单测试。

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

在oceanbase中对于表与索引的访问路径在查看执行计划时，发现和oracle理解还是有一定的区别， 例如在oracle中full table scan只访问表, TABLE ACCESS BY INDEX ROWID 配合 index range scan或INDEX UNIQUE SCAN是索引扫描加回表，如果没有带TABLE ACCESS BY INDEX ROWID 表示不用回表，从索引中取到数据，也可以叫做index only scan 或者是covering index. 那是因为oracle是heap table(这里不算IOT索引组织表)， 所以索引与表分离， 但是像MySQL及同系的GoldenDB、GreatDB等、Oceanbase及达梦都是一种索引组织表，同Oracle中的IOT表及索引，创建的其它索引为二级索引。下面测试一下OB（以下表示oceanbase）的执行计划的显示.

在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， 我们都知道可能是两个节点间参数不一致. 简单记录一下处理，如果你遇到给希望可以参考减少诊断时间。

最近一套华为虚拟化环境中的虚拟主机RHEL linux 6.N 操作系统，调整了memory资源后做reboot重启失败，检查控制台输出提示一个文件系统Superblock last mount time is in the future是2059年，但当前时间是2023年，可能还并不是类似cmos电池问题，重置时间为1988年等之前的时间。启动界面提示要做fsck 手动修复，这里简单记录一下。

之前在我的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 多版本对象，当分区计数和详细信息之间不匹配报错。