提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
最近在某客户的生产数据库中发现了一些日志损坏的报错，数据库是瀚高Highgo v9(base on postgresql 14)， 这是postgresql中的已知问题，主要原因为index 索引损坏，且在线创建时可能也会出现的错误。 ERROR: failed to re-find parent key in index for “%TABLE” deletion target page
最近有个客户的oracle 11g环境遇到单个表空间临近耗尽的问题(30TB)，同时单个表空间的datafile 个数已经达到了物理上限1023, 且每个datafile已经达到了单个文件的上限30g（8k block size）, 表空间中的对象仅一张历史分区表，仅其中一个字段存储的是XML内容，实际为clob类型，占据了整个表空间的90%以上，业务是7*24小时无间断，如何调整把影响最小？
近期在客户执行 MySQL 用户创建及授权操作时，数据库实例发生异常。经排查确认，原因为 MySQL 权限表损坏，导致权限变更操作触发实例异常。
考虑到数据库规模约 80GB，为保证恢复效率与稳定性，采用业务数据逻辑导出、新建数据库并重建用户权限后再导入数据的方式完成恢复。数据库运行正常业务恢复。
都2026年了，SQL优化居然还有是改写SQL文本的条件前后顺序，前面有案例
在 Red Hat Enterprise Linux 7（RHEL 7） 系统上，若未注册 Red Hat 订阅服务（subscription），默认的 yum 命令将无法使用，为解决此问题，可将 RHEL 7 的 yum 源更换为 CentOS 7 的阿里云镜像源。以下是详细操作步骤（适用于 RHEL 7.9 或其他 7.x 版本）
Oceanbase ODC开发平台提供了可视化开发、WEBSQL、SQL窗口等功能，可以做认为是一个开发客户端，近期有个客户在此平台执行SQL时，出现了一次间断性报错，无人干预稍后再试恢复了正常，后面记录一个该案例的诊断过程，报错日志如下：ErrorCode = 0, SQLState = 08000, Details = unexpected end of stream, read 0 bytes from 4
oracle 的10046和10053 event是SQL优化时研究优化器的一些手段，前面测试过Oceanbase 的10053 event，本篇尝试YashanDB的。及以一个小例子看看在order by消除等查询转换是否支持。
在oracle异常恢复中常见就是scn不一致场景，通常是重建control file，推SCN ， openresetlogs打开，堆SCN的方法有很多比如oradebug poke, event 10015/21307096 , _minmum_giga_scn,gdb/dbx, 修改控制文件，修改文件头，adjust_scn等方式，但因版本不同有些方法并不适用，刚好今天遇到了ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1] 错误，修复方法中有可以推scn，刚好小测一下oracle 26ai 是否还支持event推SCN.
经过多年对oracle database on-premises 新版本的等待终于结束了，2026年1月27日起，Oracle AI Database 26ai Enterprise Edition for Linux x86-64现在可以在本地使用,将 Oracle 最新的人工智能原生创新直接引入客户数据中心, 这次发布不仅仅是一次版本更新——它是向智能、自我管理和对开发人员友好的数据平台的根本性转变。注入了人工智能和自动化，并且还在SQL、安全性、性能、可管理性和开发方面提供了大量增强。
前几天《记录一个openguass（mogdb）checkpoint不推进的问题》写了一个问题，最近几天一直在尝试解决，在opengauss本人还不是专家，所以处理起来还是有一些心得，使用vacuum full和pg_repack对表重组，及检查relfilenode所属对象及如何检查是否是孤儿文件
之前写过一篇《Oracle数据库中 Scalar-subquery 缓存和 DETERMINISTIC Function》记录了在oracle中标量子查询时，如果子表的相同的关连值时，可以利用cache，减少运行时的执行调用，PostgreSQL 在V14(14.4) 引入了Memoize 新特性也是类似的优化，在Opengauss系目前还不支持，这种测试在Gauss会查询转换为left out join，最近测试了两天的YashanDB是否支持SS cache,因为没有monitor hint和starts列，比较费时。
最近在基于opengauss的mogdb v508上遇到了一个备库 流复制（Streaming Replication）环境中，备机（standby）的 restart point 无法推进，停留在1个月前的一天，该库并未重启或断电，只是在前一晚有对库里大量表做DDL，日志告警Waring: coluld not record restart point at 6F04/98156BB8 because ther are unresolved references to invalid pages
之前在《有哪些技术可以减少PostgreSQL/openGauss数据库的存储空间？》记录过，在PG系的数据库上是支持同一列上创建多个索引，这种既浪费存储又增加了更新列时的额外的写代价，日常巡检需要即使发现并清理，下面再测试oracle,mysql（goldendb等），Gaussdb(opengauss系)，Kingbase（Postgresql系），oceanbase,达梦，崖山的情况。
Oracle数据库优化器经过数十年的发展，已经具备了相当成熟的自动查询转换能力。无论是面对编写“欠佳”的SQL语句，还是原本规范但在执行时存在更优路径的SQL，优化器通常都能将其等价转换为较优或最优的执行方案,然而最近遇到一个场景却恰恰相反：Oracle优化器在该情况下存在一定的缺陷，而国产数据库YashanDB的表现却超出了预期。
前几天写过一篇
tpcc最常用的在线事务处理（OLTP）测试基准测试，近期在客户一套生产硬件上对YashanDB做了个简单的测试，下面介绍在YashanDB单机数据库上运行基于BenchmarkSQL的TPC-C测试（非极致性能优化）。
最近有个客户Oracle RAC （11g）的因为interconnect network网络问题导致脑裂，节点驱逐，恢复后重启，应用有配置TAF，所以出现ORA-25402: 事务必须回滚等，并且有一段时间的连接超时，客户需要了解Reconfiguration过程时间长的原因，发现Oracle 23c 在RAC 的Reconfiguration又做创新如Recovery Buddy和调整reconfig和stop instance顺序，简单记录。
MySQL中一个经典的并发场景。当发生 Duplicate entry 错误时，事务仍然持有 S锁（共享锁），这在某些情况下确实可能导致死锁。这现象在Oracle中并不存在，在MySQL无论事务隔离级别是REPEATABLE READ还是READ COMMITTED都存在这个问题，2个会话相同的SQL可能就会导致死锁的现象，如有些业务习惯在一个事务先insert 再update 同一记录。
众所周知，在多表关连SQL上MySQL 优化器相对其他如oracle,postgreSQL有一些缺陷，今天看到了一个现象开始Join order是正常的在某张表做了delete后，产生了错误的cost, 改变了join 顺序，而产生了笛卡尔积，导致SQL性能下降，简单记录。
数据库有一些重要的文件如控制文件，redo, 回滚段undo, temp,表空间数据文件，有时因为在操作系统误操作或者是存储等原因导致文件损坏，如果没有前期安装主从同步的容灾方案，那这类异常恢复还是有一些需求，同时伴随高风险，在oracle数据库有较多的技术像重建ctl，推scn, 隐藏参数非一致open resetlogs, bbed, dul/odu等异常修复手段，达梦中如果出现记录几种常见修复。