ANBOB™

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, 而外部查询根本不关系该列值，就是一个无效的查询列，无意义的函数调用， 需要注意。

最近有个客户在做迁移oracle到Oceanbase时，使用的是原厂的OMS数据迁移同步工具，在迁移或数据同步完数据库发现数据存在差异, 应该是一种基于logminer的log stream形式，发现一张表含有Lob字段在logminer的视图中对应的rowid只有update，没有insert， 经过事务xid的查找发现insert所对应的是ROW_ID为”AAAAAAAAAAAAAAAAAA”,显示这是一个无效的rowid, 如果是基于rowid那同步数据就可能丢失了。我发现oracle11g和23c这方面还有点差异，简单记录。

最近看到一个oracle 19c bug子查询无法展开导致的性能下降，而且影响19c的大部分版本，可以查看Bug 34044661 – Poor Performance Due to SQL Not Unnesting in Oracle 19C (Doc ID 34044661.8). 最近刚好在Oracle to Highgo（postgresql）后相同的SQL在highgo中性能变差，并且当前的Hightgo还不支持sql hint， 在研究SQL重写刚好把这个问题题简单记录。

最近遇到一起因oracle 数据库的归档空间耗尽，导致部分应用连接数据库时提示ORA-12514错误，而使用监听上现在的服务名连接数据库提示ora-257, DBA应该知道,ORA-12514错误显然是应用连接使用的服务名在listener没有办法匹配，而ora-257是归档空间满无法完成归档，怎么会ora-12514又和归档联系起来了呢？

最近在迁移oracle到基于postgresql的国产库发现了一些兼容性问题，联想到oracle对问题SQL是多么包容，我不确认已经实现oracle语法兼容的数据库，又有多少支持了Oracle在SQL查询转换中的功能，尤其是一些不必要的查询消除. 如order by elimination、Join Elimination、Common Sub-expression Elimination、subquery elimination， 这里记录一下Oracle 10053 Trace中的优化器优化形为。

最近在迁移oracle到一个基于PostgreSQL系国产数据库时，发现存在一个问题，为了增加数据迁移顺利，把在oracle中在表列上定义的not null约束，全部更改了外部的CHECK not null 约束，这样就可以在建表、导数完成后再增加check约束。虽然这种功能上几乎一样，但是在性能上还是有一些区别，这篇简单的记录。

我和我的团队一直在做oracle到国产新创的工程，在oracle数据库中如加载菜单或上下关系的记录时，使用一种start with connect by prior的关键字提供分层查询和遍历方法， 但是对于基于Postgresql的数据库中需要改写，可以借用通用表表达式(CTE)的方法with RECURSIVE（）, 同时对于排序时ORDER SIBLINGS BY可以对分层查询分组排序。这里简单的演示。

最近在客户的环境中遇到一个较为罕见的问题，数据库实例的alert日志持续报告ORA-4031错误，导致一系列级联问题，包括ORA-600错误、归档失败、ASM实例通信失败等现象。同时，INACTIVE连接数异常增加，进一步可能出现数据库链接数耗尽。问题的核心出现在ASM实例，日志中反复出现ORA-4031错误kglseshtTable ，尽管ASM实例的SGA已经配置为4GB，这个大小在正常情况下应当足够使用，但此次却是首次出现此类问题。

该环境为Oracle 11.2.0.3版本，部署在2节点RAC架构下，运行于RHEL Linux 6.9操作系统，并且已启用HugePages。

Critical to performance is that not every change is copied to the flashback buffer— only a subset of changes. If all changes to all blocks were copied to the buffer, then the overhead in terms of memory usage and the amount of extra disk I/O required to flush the buffer to disk would be crippling for performance. Internal algorithms limit which versions of which blocks are placed in the flashback buffer, in order to restrict its size and the frequency with which it will fill and be written to disk.

最近一客银行客户的Oracle环境，在部署了DSG做数据抽取后，数据库频繁的重启，希望分析一下原因， 环境oracle 12c 2nodes- RAC on RHEL x86-64 7.3 , 数据库实例为Datatguard Pyhical Standby端，使用多租户。开始LGwr等待 ‘reliable message’，后出现IPC Send timeout detected， 过几分钟后实例2驱逐，不久后实例1 crash 。Oracle home和/ 使用XFS 文件系统。 问题期间大量进程活动，从ps查看处于D状态，并且WCHAN等待为xlog_G开头的函数调用，这里记录一下该事件。

在 PostgreSQL 中，PL/pgSQL 不直接支持 TABLE OF 类型，这是 Oracle PL/SQL 中的一种集合类型。不过，PostgreSQL 提供了其他方式来实现类似的功能，例如使用数组、复合类型（composite types）和表值函数（table-valued functions）。最近在一个生产数据库oracle迁移到postgresql替换过程中，遇到了拆分由逗号分隔的字符串返回table的需求

最近在从orale迁移到Postgresql系的数据库时，迁移工具(Java JDBC)几张表迁移失败，源库和目标都是GBK字符集，但在迁移过程中提示ERROR: character with byte sequence 0xe4 0xb8 0xad in encoding “UTf8” has no equivalent in encoding “GBK”，说明在GBK数据库中有部分列数据的值是UTF8编码，这种以GBK字符集查询会乱码，验证在源库入库时错误，迁移时需要注意。

Recently, a customer’s Oracle database RMAN backup job failed. When doing a full backup, it took a long time to complete. After checking the database, it was found that the backup process was waiting for ‘enq: TC – contention’. The environment was Oracle 12.1 2-nodes RAC. I would like to record this problem.

我和我的团队近2年一直在做迁移oracle到国产库的项目，数据迁移相对于PLSQL对象兼容改写更加容易，一般迁移工具做好源和目标的data type映射基本就可以，但是有一些情况，如《Oracle国产化改造迁移时的问题: Number data type中的 invalid number》记录的那样无效number，有些数据在oracle中可以存储，但迁移到目标库时可能无法存储，最近我们在迁移一套oracle到postgresql系的国产库时，在date数据类型的列出现了无效日期数据0000年。

扩展统计信息（也称为列组扩展）是 Oracle 11g 中引入的重要统计信息改进之一。虽然 Oracle Cost Based Optimizer 能够获得正确的单列选择性估计，但它无法计算出查询谓词中存在的两个或多个相关列的联合的基数。为这种列的联合计算的列组扩展旨在帮助 CBO 弄清楚这种列的相关性，以便获得准确的估计。但在某些情况下，CBO 拒绝使用列组扩展。