ANBOB™

在服务器运维中，由于未配置NTP服务或存在CPU时钟精度问题，操作系统时间常会逐渐产生偏差。当需要修正这类时间差异时，通常希望在不停库的前提下完成操作以避免影响业务。
对于采用本地文件系统的Oracle单实例数据库，时间修正主要风险在于业务逻辑中若直接调用SYSDATE函数，可能导致事务时间戳跳跃（如业务单据时间异常），但一般不会影响数据库可用性。然而在Oracle RAC（Real Application Clusters）环境中，时间同步问题可能引发更严重的后果——包括集群实例崩溃和强制重启。

继续oracle “killed” 状态的session无法释放的问题，持有的锁可能会堵塞业务，之前有几种情况可以尝试，也有需要要重启实例才能解决的，这里再记录一种oracle 19c RAC的case, “killed” session在操作系统层的进程已不存在。在数据库中尝试kill session也无法正常清理，后台清理进程无法自动清理。

最近一个比较新鲜的案例，环境ORACLE 2-nodes RAC,有3个PDB 多租户架构，在节点2在仅做了某1个PDB级的PGA大小参数后,实例2 crash,并且，重启node2 db instance后，逐个open PDB, 仅当open 此PDB时，实例2会再次crash, 并提示错误:
2025-04-15T12:33:53.433625+08:00
Errors in file /u01/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_lmon_50145.trc:
ORA-29740: evicted by instance number 2, group incarnation 121

Exporting BasicFile LOBs can be quite a pain. If your maintenance window is too short, here is a way to make the export faster.When Data Pump starts to export a table with a BasicFile LOB, only one worker will be assigned (due to the limited parallel access methods). If you have a large table, it will take a lot of time for that one worker to process the table.

最近一个客户的数据库出现了短暂1分钟左右的高负载，环境为oracle 11.2.0.4 2nodes RAC , 看当时的top event主要是buffer busy wait和log file sync, 关于buffer busy wait 在Troubleshooting Oracle wait event ‘buffer busy wait’ 有记录过分析方法，是一种hot block现象， 而log file sync又是提交类的，当两者同时发生时，可能是后者影响前者，首先建议排查I/O， 而另1个节点此时正在做RMAN增量备份，简单记录该问题.

最近遇到一客户一套Oracle 19c(19.13) RAC 所有实例在提示ORA-00600 [krccfl_chunk] crash，并且无法启动，该问题发生前提是启用了Block Change Tracking，但并不是它的问题，而是前一天做了一个增加表空间的错误操作，如果有低于19.17的RAC数据库，并且启用了BCT时，注意这个未公开的bug，如果加文件人为失误. 可能会导致您所有的业务中断，这里简单记录。

最近一套oracle 19c的环境出现较高的cursor: mutex x等待，查询SQL ID有近4000+ version count, 从12c “_cursor_obsolete_threshold “参数值达8k，所以这么高的version也未过期，cursor: mutex x是因为version count高引起，哪什么引起high version count呢?MOS上有一篇比输全面的doc. 通过 v$sql_shared_cursor可以发现主要是USER_BIND_PEEK_MISMATCH和ROLL_INVALI

2025年初，DeepSeek 作为一家专注于大规模深度学习模型研发与部署的前沿企业，以其卓越的技术突破，推动了大模型智能应用在多个领域的蓬勃发展。其成功不仅证明了人工智能的强大潜力，众多大模型的崛起，也为AI与医疗的深度融合提供了更广阔的想象空间。如可以提高疾病诊断的精准度，加速药物研发，推动个性化治疗方案的发展等。此外，AI还能改善医疗管理效率，提升了医生的工作体验，同时增强了患者的就医体验。那AI医疗和数据库还有关吗？

oracle 的gateway透明网管支持像oracle dblink一样访问异构数据库如mysql, sql server等，在十四年前当时在维护oracle和sql server时，安装配置过还写了个整理了《安装透明网关 for sql server》，时间过的真快，没想到这次oracle的交接已经全面展开，在过渡阶段可能会存在一些异构数据库的访问，使用 Oracle ODBC 网关和异构服务技术从 Oracle 系统访问 MySQL 数据，本文介绍如何使用 ODBC Driver for MySQL 创建MySQL 和 Oracle 的数据库链接，并通过 SQL*Plus 工具查询 MySQL 数据。

这前总是通过 修改optimizer_feature_enable为不同版本，然后对比级联的参数变化，比较不同的数据库版本之间的参数差异，在Oracle 有个 ORAdiff app: https://oradiff.oracle.com/ 你也可以自己查询。

在 Oracle GoldenGate 中使用集成模式时，STREAMS_POOL 起着至关重要的作用。集成进程从“STREAMS POOL”获取共享内存。STREAMS POOL 是 SGA 的内存组件之一。STREAMS_POOL_SIZE 的大小应根据数据库系统中使用的集成提取的数量来确定。我们还应该考虑在数据库中使用 STREAMS POOL 的其他进程。最近一个案例ogg异常报错，因ora-4031 streams pool不足，简单记录。

在oracle多表关连中有SQL hint可以干预CBO产生的不合理的表join顺序，如ordered, leading等，但PostgreSQL和部分基于PG国产数据库如Highgo V9.5， 目前也还不支持SQL hint。当遇到SQL性能问题，明确某个join 顺序更好时，如何影响PG数据库优化器执行指定的执行计划呢？如果您真的需要SQL hint，在pg中可以安装 pg_hint_plan 扩展，但目前应该是因为highgo的oracle和pg的双兼容模式，如果实现pg_hint_plan在解析器上隔离上要复杂了些，所以暂未实现，又或者不想安装第三方扩展，在这种情况下，记录几个可以强制执行join ordered的替代方法。

在oracle数据库中， 避免磁盘故障对于避免数据损坏至关重要，但有时，即使 ASM 具有冗余，也可能会发生多个故障。最近有个客户给两个存储做了2个Faigroup+1 Quorum  third voting disk on a NFS server，在测试高可用时，断开一个存储链路后发现些疑问，一个是断开期间有业务近10秒的挂起，另一个是重启节点后实例无法启动。

前一段在Postgresql中的函数有Volate属性，像Volatile 是每次执行，而另外Immutable 和Stable可以所有会话或单个查询中对于相同的值cache结果，减少不必要的执行，如同oracle的DETERMINISTIC FUNCTIONS，确定性函数的意义在于，如果 Oracle 可以确定当前对该函数的调用使用的输入与上一次调用相同，那么它可以使用上一次结果并避免调用。 那cache大小有没有限制？ 正像有些标量子查询循环，《Cost-Based Oracle Fundamentals》书中的Scalar Subqueries章节 提到了该限制

oracle 11g r2 RAC 其中一个节点实例1 crash并重启，日志查看有提示“ Linux-x86_64 Error: 24: Too many open files”
** DBGRL Error: Linux-x86_64 Error: 24: Too many open files
Additional information: 1
** DBGRL Error: Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x5C] [PC:0x8238B00, lxhh2ci()+4] [flags: 0x0, count: 1]
Cannot open /proc/self/exe for reading: errno=24

Oracle standby database恢复错误，因为源库使用的ASM OMF文件名格式， 有配置xx_file_name_convert参数， 替换了standby controlfile文件缺失，无法找到对应文件。standby database reocver无法启动，查看db alert log如下:

WARNING: The converted filename ‘+DATADG/stdbillb/datafile/cdr3.289.1088277783’
is an ASM fully qualified filename.
Changing the filename to ‘+DATADG/MUST_RENAME_THIS_DATAFILE_773.4294967295.4294967295’.
Please rename it accordingly.

最近有个客户安装oracle 19c RAC 在XC 环境，操作系统使用Kylin Linux V10, 在检查DB 实例使用的interconnect network时发现使用的public network，而非规划的private network, 但时检查 ASM Instance是正常, 使用oifcfg检查也正常，在db alert log中提示“failed to init gpnp”， 错误日志”NZ error code : 29106″, 提示简单记录一下这个风险。

《Oracle、Oceanbase、Kingbase、GaussDB、达梦数据库比较系列(二十七):子查询中的函数投影裁剪》 测试在inline subquery中包含函数列投影时裁剪或叫SLP(select list pruning) ,如果函数的Volate属性是volatile的影响，函数的不稳定性除了影响投影还有join 的view包含该函数时，影响谓词条件的推入等，最近在highgoDB遇到了一个SQL性能问题，其实所有pg系数据库如gaussdb,opengauss,kingbase等都存在。下面演示一下这个问题。

在MySQL或PostgreSQL中对partition不是很友好，如分区格式、性能、或索引限制，如pg中的pk索引必须带分区键，但是在oracle中的分区有时设计就不是很科学，就像当初上线时没必要用oracle一样，现在国产数据库上线可能”这个杀鸡焉用宰牛刀”的现象又回重演，如简单的逻辑小型库，非要上线某分布式数据库，恐怕还在沾沾自喜。 oracle partition有的分区表随着业务下线，像最大分区停留在几年前，迁移到其它数据库时，是否可以排除或创建为非分区仅留格式？所以在国产化改造过程并不是简单的迁移，而是一次优化的机会。

在有些开发习惯中，如查询分页或统计查询，有些开发是基于明细的查询而外层直接加1层汇聚查询，如select count(*) from (select ….)， 但子查询中可能有一些函数或主查询根本不需要的列， 在oracle中的查询转换中如select-project-join或select list pruning， 或VIEW merge SPJ,CVM 都是为了不影响SQL结果一致性，而优化低效的SQL. 但是从oracle迁移到其它数据库中，因为CBO的差异，导致SQL性能大量衰减，需要手动改写SQL， 最近从oracle迁移到pg系国产库，发现一个view中使用了function, 而外部查询根本不关系该列值，就是一个无效的查询列，无意义的函数调用， 需要注意。