ANBOB™

在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，注意函数的返回精确度，防止数据迁移丢失精度，但有时用户希望使用精度较低，如按日期检索和创建索引时有点有趣。为了说明这一点这里测试一下。

随着数字经济的快速发展和数据量的激增，高性能数据库系统成为企业业务的核心基础设施之一。在全栈国产化的背景下，如何构建高效、可靠的存储架构，实现 100 万 IOPS 的性能目标， 做为集中式数据库的基础设施提供支持，成为企业关注的重点。本文探讨通过 NVMe SSD 和硬件 RAID 卡组合，构建集中式数据库系统的技术路径。如利用 4 块NVMe SSD，在 RAID 0 下实际性能可超过 1,600,000 IOPS，完全满足高负载数据库的需求。

最近有个客户安装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″, 提示简单记录一下这个风险。

在 MySQL 中，character_set 配置用于指定数据库、表、列或连接的字符集。字符集决定了如何存储和检索字符数据，例如 UTF-8、latin1 等。MySQL 中有八个与 character_set 相关的配置选项，如下所示。如果不仔细阅读MySQL字符集文档，可能很难知道这些配置选项的用途。此外，对于某些选项，除非进行进一步测试，否则很难知道 MySQL 如何使用它们。

前两篇在《VIEW dependencies in Oracle、MySQL、PostGreSQL(数据库比较系列十一)》《Alert : PostgreSQL inline Subquery or View 包含volatile functions 阻止谓词推进(Predicate PushDown)》记录了因为view 包含Volatile Function导致的性能问题，通常，PostgreSQL 函数可以按如下方式标记：VOLATILE、STABLE、IMMUTABLE , 而这也是算最被广泛忽视的性能问题点，这篇文档整理个SQL列出所有包含”VOLATILE” Function 的View, 判断是否可以修改稳定性属性。

《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重写刚好把这个问题题简单记录。