OceanBase开发者大会2024感受：OB不甘心只做分布式数据库
昨天我有幸受邀去上海参加了的OceanBase开发者2024度大会，作为观察团其一我也想谈谈我的个人理解，收获与感触颇丰，对于一个写了十几年技术博客的技术男，通过一篇描述性短文总结难度不亚于路遥当时写《平凡的世界》那段经典的开头。思来想去，我准备从“看见的”、“看不见的”、“瞬间的”和“永恒的”四个层面简短总结.
weejar zhang
Troubleshooting Oracle instance start failed with ORA-7445 [ipcor_net_get_ibdevname]
最近，有一位海南客户报告了Oracle 19c RAC数据库启动时出现的错误，提示ORA-07445: exception encountered: core dump [ipcor_net_get_ibdevname()+71][SIGSEGV]。这个崩溃报告的异常原因是由于Oracle的一个bug引起的，但根本原因是由于数据库无法访问某些特定设备的API而导致的。通常这样的问题源于硬件方面的原因。在这里，我只是简要记录一下问题的表现。
隐藏问题: Oracle 11g存在index full scan替代index fast full scan的低效执行计划
在Oracle数据库中，索引是提高查询性能的关键工具之一。通过使用索引，数据库可以快速地定位和检索数据，从而加快查询速度并降低系统资源消耗。在索引扫描过程中，有两种主要的方法：索引快速全扫描（Index Fast Full Scan）和索引全扫描（Index Full Scan）。然而，在某些情况下，数据库可能会出现错误的执行计划，选择索引全扫描而不是预期的索引快速全扫描，导致性能下降和资源浪费。该类问题可能不容易发现，仅是SQL性能差，或主要的等待事件为db file sequential read.
Troubleshooting Oracle ASM diskgroup dismount with ORA-15335 ORA-15066 ORA-15196 when delete instance use DBCA
环境为Oracle 11.2.0.4 2节点RAC的情况下，今天我们遇到了一个问题。同事在使用DBCA删除一个已经损坏的数据库实例时，意外地导致了当前唯一存活的数据库实例崩溃。进一步的检查发现，ASM磁盘组不可用，而ASM警报日志显示了ASM磁盘文件头损坏、ASM元数据损坏以及ORA-15196: 无效的ASM块头的错误。为什么删除数据库实例会导致ASM磁盘组不可用，并且发现ASM元数据损坏呢？
分析应用日志Caucho连接池MySQL随机com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
最近一客户的应用日志随机会出现一些数据库源访问错误，中间件使用Caucho的连接池，数据库为MySQL 5.7主从，前端有HAproxy, 应用server多个，报错也不是持续性，再次重试可能会就正常，错误日志DataAccessException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago.
Alert: Oracle RAC最大进程数限制受UDP port range影响
几年前测试oracle RAC的节点间UDP通信《The FG(server process) and remote node LMSn process communication over the interconnect?(用户进程会和另一节点的LMS进程直接通信么?)》测试过节点间存在Server进程与LMS的udp连接，使用的是HAIP(169.254.*.*), 而Linux操作系统的网络端口可用范围net.ipv4.ip_local_port_range 参数控制,适用于TCP和UDP，最大值是65535. 如果RAC中就一个private network 网卡，假设不排除所有进程都和某一个LMS进程通信如LMS1，LMS1分配1个IP addr+UDP port， 那FG进程的上限就是net.ipv4.ip_local_port_range /单个FG进程打开的UDP个数。
抱怨最多的PostgreSQL问题在国产数据库解决了哪些？
两年前，Rick Branson撰写了一篇备受关注的文章，题为《10 Things I Hate About PostgreSQL》，其中总结了他对PostgreSQL的十大批评点。作为一位拥有近20年PostgreSQL使用经验的专家，他提出的问题是客观的。尽管他本人深表认可PostgreSQL，并且是其坚定的拥护者，但他不赞同一些人对其无条件的赞美。简单地看看国产数据库在解决这些问题上的进展，或许可以提供一些参考。
Troubleshooting Oracle 12cR2 Standby database crash due to Corrrupted block
最近一套oracle 12c R2的数据库日志应用总是中断，并且在standby 节点发现了一些坏块，存储检查正常，并且primary db端并没有发现坏块，standby db alert log中发现了大量的ora-600报错，当前可能为logical corruption（Internal inconsistency in the block while the block may have good header and footer. The block checksum will be correct but the block structures may be corrupt.），ADG的ABMR并没有自动修复该错误。这里简单记录。
数据库主从同步（Master-Slave Replication）和Raft/Paxos
主从同步和Raft/Paxos是两种不同的技术，用于不同的目的。主从同步主要用于数据库的复制和读取性能优化，而Raft/Paxos主要用于确保分布式系统的一致性。虽然它们都涉及到数据的复制和分布式系统，但它们的设计目标、实现方式和一致性保证都有所不同。
如何在 PostgreSQL 中生成随机文本字符串？
在数据库中，有时需要一种快速简便的方法来生成随机字符串来填充文本列，因为目前PostgreSQL中没有生成随机字符串的函数，可以考虑使用 Orafce 扩展，其中包括一个生成随机字符串的PostgreSQL 函数。或者创建自定义函数实现，如果使用orafce中的dbms_random生成函数记的检查可能与oracle一些形为不同。
在PostgreSQL/openGauss系数据库中如何拼接SQL?
在Postgresql中可以使用format()打印SQL, 使用$[tag]$ 匹配引号，还可以使用format type格式化文本对齐与标识自动加引号，创建易于维护的脚本，没有硬编码文本，并且不会忽略标识符的双引号。
oracle 23c的分布式数据库GDS（Globally Distributed Database ）
长期以来，oracle数据库一直是集中式数据库的领导者，基于共享存储的RAC和日志流的DATAGUARD数据保护，提供了数据的最大高可用，支撑的全球各行业的核心业务。然而从Google的Spanner发起的分布式SQL开始，出像了像CockroachDB、TiDB 和 YugabyteDB 通过 Raft 共识复制和OceanBASE通过Paxos共识复制的分布式数据库,Oracle 现在似乎在这个赛道成了追随者。在Oralce 23C中添加了Raft复制，做为主备配置的替代方案，但是并不是重新构建一套新的数据库架构，而是基于现有的Partition、Oracle Sharding、GDS技术之上做了创新.
PostgreSQL OpenGauss 在drop table后空间未立即释放(Released)问题
去年在记录<案例：openGauss/postgreSQL 数据库手动清理膨胀Heap Bloat (dead tup)>时遇到过在opengauss系统drop table后，操作系统并未立即释放问题，当时没有过多研究，只是建议通过kill SESSIONS或重启可以达到效果，近日发现同事在postgresql中同样遇到了该问题，但Postgresql是进程模式可以和oracle一样通过kill OS 进程释放文件句柄，并且PostgreSQL在2021-02-11 Release的版本都改进这一问题，目前Opengauss V5依旧存在
Goldengate alter extract process after MySQL master Switchover to slave
Oracle数据库有dataguard主从，MySQL有主从或MGR，Goldengate同步支持从前两种数据库做数据抽取，但是在主从切换以后需要在Goldengate做相应的修改。这里记录一下MySQL因master 需要停机维护时，OGG主动切换到slave的方法。
当Linux内核升级后，Oracle 数据库需要relink 执行文件吗？
前几个月有个XD的客户遇到过linux bug导致OS频繁重启，当时整理了笔记
oracle 12c后 ‘日志文件分段’可能导致LGWR slow 等待’log file sync’
2c 引入了log segment功能，针对xml格式的alert log达到某大小后自动生成新文件，解决日志过大查看和监控采集的问题，我在很多年前专门写过listener log和alert log的text格式的shell用于切换，Log writer(LGWR)进程在switch时会写db alert log， 如果在写日志时有性能问题有可能会导致LGWR进程性能问题，导致实例出现等待log file sync。
Oracle、MySQL、PostgreSQL、openGauss、达梦、OB、Tidb数据库比较系列(二十): 事务隔离级别
事务隔离级别是数据库事务处理的基础，ACID 中的 “I”，即 Isolation，指的就是事务的隔离性。ANSI/ISO SQL 标准定义了4 种事务隔离级别，对于相同的事务，采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的，
Troubleshooting Oracle 19c Wrong result cdb_data_files caused by result cache
最近遇到一个oracle 19c（19.15）的多租户环境，在查询cdb_data_files时显示的文件大小偶尔不正确的现象，这可能影响我们对于数据库空间类检测，通过分析发现在多租户环境中查询CDB_或共享对象时(sharing=object )，递归查询中使用了result cache.简单记录。
Troubleshooting Oracle 19c ora_wNNN process memory usage high
近日一银行客户巡检发现一内存使用率高的oracle 19c(19.4) RAC数据库环境，因为是linuxone拆分的多机器，内存分配不是很充足，在当前动辄1T内存可能并不易发现，分析内存使用主要是因为Oracle的多个后台进程ora_wNNN_xxx进程，每个进程PGA使用近600MB。WNNN后台进程是SMCO(Space Management Coordinator Process)的slave进程，从oracle 11g引入的智能空间预分配space preallocation的新特性，在oracle 12c后SMCO也负责生命周期管理ILM(Information Lifecycle Management).由于SMCO 或W00n在完成space preallocation过程中遇到的问题时，可以考虑禁用该特性.
PostgreSQL中的effective_cache_size 参数
effective_cache_size 是一个参数，用于设置当 PostgreSQL 计划执行查询时，操作系统缓存和 Postgres 的共享缓冲区中将容纳多少数据的估计值。 此值用于确定数据库引擎对磁盘 I/O 的依赖程度，简而言之是planner对单个查询可用的磁盘缓存的有效大小的假设,这对数据库性能有重大影响。