ANBOB™

最近一套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不足，简单记录。

最近在做从Mogdb(openGauss)导入Highgo(PostgreSQL)的PG模式数据时，timestamp类型的数据库入库错误，使用的是MTK逻辑查询是insert的方式，错误内容如下：

anbob=# insert into test9(t) values (‘20240101 13:01:01Z’);
ERROR: datetime format picture ends before converting entire input string

Recently, I encountered a customer who needed more 20 seconds to login to the database server Hpux operating system through ssh, while the other one was normal. He consulted me and recorded the analysis method below.

在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章节 提到了该限制

在使用 PostgreSQL 时，分区表可以有效管理和优化大规模数据表的存储和查询性能。在一些国产库中兼容了oracle的创建语法格式，有些仅支持语法存储还是pg,有些是连语法都未支持，在PG中创建分区的方法让oracle DBA可能有些难以适应，在PG中的分区分为parent/partitioned 和 child/partition tables , PostgreSQL支持range, list, hash分区。这里记录一些PG系使用过程中的注意事项。

PostgreSQL 中有三种连接策略，它们的工作原理截然不同。如果 PostgreSQL 选择了错误的策略，查询性能可能会受到很大影响。本文介绍了连接策略、如何使用索引支持它们、它们可能出现的问题以及如何调整连接以获得更好的性能。

几年前整理过，在SQL使用 PBE(Parse Bind Execute) 时，如prepare statement, 如何生成gplan（通用执行计划）和cplan(定制执行计划)， 及解析共享在如数据倾斜时可能存在的执行计划错误，前几天在opengauss系数据库做了切换后，较多SQL产生了错误的执行计划，因为错误的cost估算，有hash join 改成了nl join同样也是PBE的错误场景，仅记录。

今天在客户一套库发现了个bug, select count(*) 与select *明细记录数不一致， 环境mogdb 508， 前者使用index only scan, 后者是index scan , 这种情况在oracle有时也能遇到，通常是索引条目与table条目不一致，如因为lost write导致，可以drop 并create index重建索引恢复，但是opengauss中还是第一次，在postgresql中控制记录的除了table, index还有可见性的vm，简单记录一下该问题。

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.

日志是数据库用于诊断解决问题的途径，在生产环境中开启过多可能会导致性能问题，过少可能缺失日志，配置时有必要微调默认的日志配置参数，对应多个log_xxx参数，要达到理想的平衡，需要深入了解各种 PostgreSQL logging 指令是关键。定制日志记录设置以精确满足您的监控和故障排除需求。或何时可以动态的开启。

翰高数据库 Highgo是基于PostgreSQL的数据库，但是版本较多有基于postgresql 9 、12、14多个版本，同时在兼容模式上也并不统一，如支持pg, oracle和正在增加的MySQL兼容模式，如V9.5版本可以实现一份数据，两种解析引擎模式的支持，同时在V9版本登录时还有实例级用户和数据库用户级，简单整理总结以扫盲。

在PostgreSQL中的时间类型较多，如TIME, DATE, INTERVAL, TIMESTAMP,和Timestamp With Timezone(TIMESTAMPTZ) ， 而timestamp类型精确度非常高，如date类型是只有年月日，time又只有时间分秒，而timestamp是两者组合，同时可以带时区，如有在些基于postgresql国产数据库中为了兼容sysdate，注意函数的返回精确度，防止数据迁移丢失精度，但有时用户希望使用精度较低，如按日期检索和创建索引时有点有趣。为了说明这一点这里测试一下。