ANBOB™

很久以前记录过一篇 Oracle Estimate of the duration of a rollback operation (估算rollback事务回滚剩余时间) ，oracle的大事务cancel或kill后的回滚操作，rollback所花费的时间通常比原来的操作还要长，而且在回滚完成前有可能会堵塞其它事务，在PostgreSQL中因为没有使用undo而是多版本，所以忽略rollback的时间，这是PG的强项，但是在MySQL中和oracle一样同样存在回滚问题，这里简单记录如何估算MySQL中的事务回滚时间。

一个客户应用原来直接使用opengauss 驱动连接正常，但是出于加密的应用需求，外包了一层增加了应用驱动，在连接串不变前提下，连接数据库报错：
Error Connecting to database FATAL : no pg_hba.conf entry for host”x.x.x.x”, user”weejar”, database”postgres”, SSL off

我之前写过一篇关于的文章。在将 Oracle 迁移到国产数据库的过程中，为了进行负载重演，一些国产数据库需要在 Oracle 源库上进行 DBReplay 的 capture。然而，这种操作对源生产环境会带来一定风险，不仅有 license 商务风险，还存在可用性风险，比如空间或性能问题。在之前的文档中，我建议将 capture 产生的 WCR rec 文件存储在高吞吐量且稳定的文件系统设备上。然而还是因为没有足够的重视wcr文件存储，最近还是因为 WCR 文件存放在NFS写入问题，导致了源数据库的全库 hang 死等重大故障。这里简单记录一下这个事件。

IEW dependencies in Oracle、MySQL、PostGreSQL(数据库比较系列十一)之前一文记录了postgresql对于table上创建了view以后，修改表列长度时会报错””ERROR: cannot alter type of a column used by a view or rule””, 最近一套就应用需要开启加密功能，大量的表字段需要增加长度，但又有大量的view， 如果view全删修改后再创建确实不少的工作量，基于postgresql的opengauss新开源分支的部分发型版已经支持了该修改，这里是指mogdb,另一个流行商业版vb还存在一些缺陷。这里演示mogdb V5该功能支持

最近，在对一套Oracle 19c RAC（Real Application Clusters）进行计划内的维护操作时，遇到了一个预料之外的问题。原本打算通过一个常规的滚动停实例操作来维护其中一个节点，即通过执行 crsctl stop crs 命令来停止节点1的实例。然而，在执行此命令后，意外地发现节点2的实例也随之自动终止了。这一情况发生在Oracle 19.11版本中，如果此类问题频发，无疑会对未来的维护操作带来不确定性。

在去年《Troubleshooting Oracle RAC node OS shutdown (‘crsctl stop crs -f’) cause db instance stop on another node》我们也曾遇到过类似的问题，当时使用的版本是19.10。

最近在Oracle 12C环境中，一个用户在尝试登录备用数据库（standby）时失败。在修复主数据库（primary db）并执行datapatch之后，发现大量包（package）失效，导致正常业务运行也出现错误。特别是在递归调用一个触发器（trigger）时，出现了错误：ORA-00904: “DECL_OBJ#”。此外，尝试禁用或删除该触发器时也失败。这是一个需要重点记录的问题。

Recently, a customer’s Oracle database encountered a performance problem, waiting for “row cache lock”. Analysis showed that the cache# p1 value pointed to the dc_realtime_tabst 。

Starting from 12.2.0.1 Grid infrastructure home does have tomcat installed on the GI_HOME. A security scan may find Tomcat security vulnerability CVE-2024-21733 in your Oracle RAC environment. How do I fix it ？

客户一套ORACLE 3 node RAC, 因为需要节点3 主机停机维护， 重启后CRS无法启动， 其它两个节点node 1 ,node2 运行正常。 node 3启动过程中 ora.asm 资源启动hang ，等待enq: dd – contention , 简单记录分析步骤。

最近有家半导体客户的oracle RAC间隔性出现了2次活动会话高负载的堵塞现象，找到我协助分析， 当时的主要活动会等待是buffer busy wait, enq: tx … 的hot object现象，同时有较高的log file sync 单次延时，当分析数据库性能问题时，从top event入手没错，但是也要防止被带偏，也可能是因为其它的影响，简单记录这个事件。

最近有个客户遇到了enq: TM – contention, 确认表上有大量的FK，并且存在FK 无索引的现象，同是一张表有近60个FK ，同时子表又有几十个子表的多层FK（外键关连） , 关于这个event十多年前有记录过一个笔记”Tuning enq: TM – contention with foreign key (外键引起的队列)”, 现在这个客户也是认可是有外键缺失索引的问题，但非要找到当时的堵塞者SQL, 当然如果SQL很快如果没进ASH, 可能就不好分析了，这里使用分享logminer如何查找线索。

最近遇到两起运行在 Linux 7 上的数据库主机问题。由于操作系统内核的内存使用率高，导致 Oracle RAC 的性能受损或无法使用。内存主要被 Slab 的 SUnreclaim 区域占用。这些案例有一个共同特点：都使用了分布式文件存储系统。这次的情况是生产环境中有 750G 的内存，而 SLAB 使用了接近 200G 的内存，且主要是由 SUnreclaim 区域占用的。特此记录这个案例。

在ORACLE中，SQL Profile 是对 SQL 语句文本的数据库级匹配。由于相同的 SQL 文本在不同用户下可能会受到影响，因此需要一些方法来避免这种情况。OceanBase 提供了 outline 功能，可以用于固定执行计划。那么在 OceanBase 中是否存在与 ORACLE 类似的、影响不同用户的问题呢？多个用户的相同 SQL 语句和相同的表是否共享同一个 outline 呢？outline 是全库共享的还是用户级私有的？

在关系数据库性能优化技术中，有时存在数据库优化器评估问题，产生了错误的执行计划或执行计划改变，导致SQL执行效率变差，在无法或短时间内修改应用SQL代码时，需要从数据库端快速固定指定的执行计划，问题:
多个用户多个table(含索引)相同结构，对于相同的SQL文本，是否会互相影响？
多个用户相同的table， 对于相同的SQL文本，是否会互相影响？

前几天，一位朋友的Oracle RAC 2-nodes（Linux 6物理主机，HPE）系统计划进行HBA固件升级。幸运的是，他们采用了滚动节点的升级方式。在节点1升级FC HBA固件（Firmware version）并重启后，CRS启动失败，所有ASM DISK丢失，且在重启时遇到了操作系统无法启动的惊险情况。这里，我分享一下处理这种问题的经验。

最近，我注意到一位朋友在处理一个以G字开头的MySQL系国产数据库时遇到了一些问题。具体来说，该数据库占用了超过1TB的临时文件，导致文件系统告警，之前kill session并且未能释放。这是由于在杀掉dbproxy上的session后，db node上的session仍然存在。这样的情况可能是非原生分布式数据库的一个风险点，因为每个data node都是一个独立的MySQL实例。最终，我们通过登录到data node并手动kill session解决了问题。我在另一款国产MySQL系分布式数据库GoldenDB上进行了类似的模拟测试，仅记录处理方法。

数据是企业的重要生产要素，确保数据不丢失是大多数客户的核心目标。然而，要实现这一目标的高可用容灾方案不仅依赖于数据库产品的架构支持，还需要硬件成本的投入。同城双机房的配置在客户中较为普遍，如果追求RPO=0，无论是分布式数据库还是集中式数据库，个人了解到目前主流的数据库使用架构

在学习OceanBase时，测试环境是必不可少的。我在个人笔记本电脑（18核CPU，32GB内存）上的VBOX虚拟机中创建了一个配置为8核CPU、16GB内存和100GB磁盘空间的虚拟机，并在其上安装了OceanBase V4.2.1环境（Oracle租户），以便后续进行语法研究。以下是安装过程的简单记录。

在MySQL 5.6或从5.6 升级到8.0后有可能会遇到ERROR 1071 (42000):Specified key was too long; max key length is 767 bytes 报错，提示是遇到了索引KEY的最大上限767 字节。在本文中，我将解释此错误发生的原因以及如何解决它。

上周，Percona 发布了一篇警告博客，提醒用户<不要升级到 MySQL 8.0.37 之后的任何版本>。然而，现在访问 MySQL 官方下载页面，依然可以在主推的下拉列表中看到这些版本。
Percona 在文章中提到，Jean-François Gagné 在 bug.mysql.com 上报告了一个编号为 #115517 的 bug。不幸的是，这个 bug 目前处于私密状态。简而言之，如果您创建大量表（例如 10000 个），MySQL 守护进程在重新启动时会崩溃。当然，也有人认为这是危言耸听，因为单个数据库实例中有超过1万张表的用户可能不足0.0000001%。