PostgreSQL/GaussDB

Oracle迁移PostgreSQL系性能问题：not in

by

最近有客户在oracle迁移到Highgo数据库后，有些SQL运行时间timeout而中止，然后应用就开始调中间件的timeout时间如增加socketTimeout或removeAbandonedTimeout， 这是治标不治本的方法，主要是因为SQL时间变长了，查看了SQL 也是个简单的not in( …) 子查询。 这种SQL其实在oracle是有自动优化的，但PG没有

PostgreSQL性能问题： View无法谓词推进(predicates pushdown）

by

在 PostgreSQL 中，“视图（View）”、“连接（Join）”以及“谓词下推（Predicate Pushdown）”是直接影响 SQL 执行性能的重要优化环节。所谓谓词下推，是指优化器能够将外层查询中的 WHERE 条件或 Join 过滤条件，自动下推到视图或子查询内部执行，从而尽可能早地减少参与运算的数据量，降低扫描、排序和连接开销。

Alert: Don’t Migrate “nologing” Table in Oracle Database to PostgreSQL “unlogged”

by

因 PostgreSQL 功能丰富，且在处理复杂 SQL 时的性能表现不俗，越来越多客户正从 Oracle 迁移到基于 PostgreSQL 的国产数据库，例如 GaussDB、Kingbase、HighgoDB 等。但要注意：换皮容易换骨难。有些语句看起来“形似”，底层机制却截然不同，仅做语法层面的转换，可能带来致命后果。本文总结 Oracle → PostgreSQL 迁移中NOLOGGING 与 UNLOGGED 这种看似相似、实则差异巨大的特性。

Highgo（PostgreSQL系）ERROR: current transaction is aborted, commands ignored until end of transaction block

by

PostgreSQL 和 Oracle 在处理事务内 SQL 错误时的行为确实存在根本性的差异， 最近有个客户的应用系统从oracle迁移到Highgo(base on postgresql)后, 以过去的oracle开发习惯会有些不适应的地方，像在事务中遇到“ERROR: current transaction is aborted, commands ignored until end of transaction block”错误后，后续所有SQL会执行失败。

 PostgreSQL 集群“脑裂”（Split-Brain） 

by

在 PostgreSQL 集群中，“脑裂”（Split-Brain）是一种极其危险的故障场景，指集群中的两个或多个节点因通信中断，都误认为自己是唯一的主库，并同时接受写入操作，导致数据分叉和不一致。

一旦发生脑裂，原主库的数据状态会与新主库产生分歧，形成一条独立的时间线。这使得原主库无法简单地作为备库重新加入集群，因为它的 WAL 日志序列与新主库不再连续，直接加入会引发复制冲突。

Highgo瀚高数据库PL/SQL 中增加commit注意事项

by

在我之前的blog中有记录,从oracle迁移到基于postgresql的数据时的需要注意的地方，在那篇有记录select 会堵塞truncate, truncate又会堵塞所有的现象，有时truncate是在存储过程中从oracle迁移而来，在oracle中truncate是DDL，会触发隐式提交，但PostgreSQL的事务更符合我们对事务的理解，DDL并不会隐士提交，那如何实现本篇演示一下。

Kingbase 的密码有效期插件identity_pwdexp

by

数据安全已成为企业生命线。作为国产数据库的金科金仓（KingbaseES）提供了一系列强大的安全机制来保障数据资产。其中，密码有效期管理是防止因长期未更换密码而导致的安全隐患的重要手段。

今天，我们将深入探讨 KingbaseES v9 中用于实现这一功能的核心插件——identity_pwdexp.

Highgo Table Index Corruption：failed to re-find parent key & new index tuple() overlaps with invalid duplicate tuple

by

最近在某客户的生产数据库中发现了一些日志损坏的报错，数据库是瀚高Highgo v9(base on postgresql 14)， 这是postgresql中的已知问题，主要原因为index 索引损坏，且在线创建时可能也会出现的错误。 ERROR: failed to re-find parent key in index for “%TABLE” deletion target page

记录一个openguass（mogdb）checkpoint不推进的问题（续）

by

前几天《记录一个openguass（mogdb）checkpoint不推进的问题》写了一个问题，最近几天一直在尝试解决，在opengauss本人还不是专家，所以处理起来还是有一些心得，使用vacuum full和pg_repack对表重组，及检查relfilenode所属对象及如何检查是否是孤儿文件

记录一个openguass（mogdb）checkpoint不推进的问题

by

最近在基于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

测试主流数据库允许同一列(column)上创建重复索引？

by

之前在《有哪些技术可以减少PostgreSQL/openGauss数据库的存储空间？》记录过，在PG系的数据库上是支持同一列上创建多个索引，这种既浪费存储又增加了更新列时的额外的写代价，日常巡检需要即使发现并清理，下面再测试oracle,mysql（goldendb等），Gaussdb(opengauss系)，Kingbase（Postgresql系），oceanbase,达梦，崖山的情况。

Oracle优化器outer join to inner不如YashanDB

by

Oracle数据库优化器经过数十年的发展，已经具备了相当成熟的自动查询转换能力。无论是面对编写“欠佳”的SQL语句，还是原本规范但在执行时存在更优路径的SQL，优化器通常都能将其等价转换为较优或最优的执行方案,然而最近遇到一个场景却恰恰相反：Oracle优化器在该情况下存在一定的缺陷，而国产数据库YashanDB的表现却超出了预期。

Highgo在重建流复制备库时会自动清理主库的物理复制槽？

by

近期在一个国产化数据库highgoDB的数据库环境，一主三从架构，主库的归档产生的较为频繁，且主库的参数关于wal的保留时间配置(wal_keep_size)也偏低, 后来因为备库有重建需求，在重建时发现主库的WAL日志缺失了,重建前也并未手动清理对应的物理槽。难道HighgoDB可以自动清理？

Highgo oracle兼容模式的国产库copy force_null

by

最近在一个从oracle到基于postgresql的国产数据库项目上，遇到使用copy加载到数据库中的表字段是空值数据无法过滤，因为在oracle中的\0x00、NULL、”(空值) 与postgresql中不同，所以在像瀚高、kingbase等PG系的数据库，oracle兼容模式下对于‘’空值的处理要格外注意，下面简单的记录。

索引key长度限制Oracle、MySQL、PostgreSQL

by

近期在推进一个从 Oracle 迁移至 PostgreSQL 的项目时，我们遇到部分在 Oracle 中运行正常的索引无法在 PostgreSQL 中创建，系统报错：ERROR: index row size X exceeds maximum Y for index “index_name”。

经分析，这源于不同数据库对索引键（Index Key）长度的上限设计存在差异。为规避此类问题并助力迁移规划，我们特此整理了 Oracle, MySQL, PostgreSQL 三大主流数据库的索引键长度限制。

Highgo数据库模拟deadlock

by

Highgo数据库实际是Postgresql内核，这篇同样也适用于Kingbase, GaussDB一样存在的PG系，最近一客户上了Highgo数据库后晚上的批作业任务总是失败，查询JOB日志，显示因为deadlock失败，其实很好理解，提示的信息有会话、表、行的信息，这里模拟一下2个会话交叉更新相同记录产生的deadlock.