ANBOB™

最近，一位使用 openGauss 数据库的客户遇到了一个突发情况：应用程序突然无法处理事务，并在应用日志中报错： ERROR: cannot execute CREATE TABLE in a read-only transaction， 经过分析，发现这是由于数据库的 CM（Cluster Manager）集群管理软件触发了某种保护机制所致。这种情况令人费解，在 Oracle 数据库中即使文件存储空间耗尽也仅在alert log中打印错误信息，或有些OS资源使用高在RAC时会在LMHB日志中提示, 而不是直接将业务置为只读模式，从而广泛影响应用。

在十年前简单测试过oracle 9i 的加密解密用法之dbms_obfuscation_toolkit(二)，其中有md5单向加密， 最近在oracle迁移到opengauss项目中用到了md5， 这里简单记录替换方案，在pg或og中直接就有md5 function. 在mysql及Mysql系的产品和ocenabse, 达梦一样存在该函数md5。

在openGauss 数据库中如果存在多个用户如A和B， 希望B用户可以在用户A的同名schema下创建table对象，需要授权给用户B，在oracle中如create any table的系统权限或者是user Proxy 高级用法，在我之前的笔记Oracle 23c 几个开发相关新特性中,在oracle 23c 才引入grant xx ON SCHEMA xx to xx的语法，就是这样的功能在openGauss中有不同的用法。今天在一个项目遇到了这个问题，下面演示一下这个情况。

在oracle迁移opengauss数据库时，可能会遇到在oracle数据库中使用dbms_crypto 加密的数据 ,在目标数据库opengauss有时也不需要完全等同，仅实现加密功能即可，需要我们改写对应的存储过程，或自定义包装function, 也需要合理规划数据迁移的一些方法，比如需要先解密，在目标库重新加密，尤其是加密方法不同，避免迁移源加密数据到目标库后无法解密，当然如果应用层能实现加密功能那是极好的

我和我们的团队最近在迁移oracle到openGauss（postgresql）时现在有一些存储过程中使用了加密函数，其中有一些涉及到编码的package 如utl_i18、utl_raw、utl_encode，对一些明文数值进行raw或base64编码，这里记录一下oracle到opengauss后对应的函数实现, 基本也适用于postgresql，下一篇会记录加密函数。

近几年XC的快速推荐，我和我的团队一直在努力做从 Oracle 迁移到国产数据库的工作， 其中国产数据库像基于postgreSQL的kingbase/highgo等，还是opengauss等下游发行版产品，因为得于pg的优化器或对oracle的兼容性，在传统企业也广泛应用，企业应用程序像java开发的颇多，而java代码中对于数字的变量赋值的数据类型有多种，在postgresql/openGauss系的数据库与oracle存在差异，可能会导致PostgreSQL JDBC 驱动程序不像 Oracle JDBC 驱动程序那样转换该数据类型。数据类型不匹配的结果最终在 PostgreSQL系中是全表扫描，而不像oracle中的使用索引，导致SQL性能变差，下面做个演示

我们的一位客户的计费系统大量依赖于Oracle数据库的主键（PK）进行去重操作，且其事务频率极高。基于ORA-1报错的编程习惯，这种业务逻辑在Oracle环境下虽然运作尚可，但并不理想。近年来，我一直从事Oracle数据库迁移到国产数据库的咨询、评估及实施工作。在此过程中，我习惯考虑各种场景，这就像在使用一些老品牌的汽车时，虽然耐用性强，但如果换成国产汽车，可能就会遇到不同的问题。若前期考虑不周，类似的场景切换到国产数据库后，可能会出现意想不到的困难。

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

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该功能支持

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

The maximum size of large objects (LOBs) in Oracle, PostgreSQL, and MySQL varies depending on the type of LOB and the database system. Here are the details for each database:

在数据库中分析系统中的锁等待非常重要， 在oracle中有大量的脚本，在Postgresql中也需要积累一些工具， 可以快速分析锁等待， 这里推荐几个好用的脚本。

在oracle中A库直接远程访问B库常见的有dblink, 在postgresql中有postgres_fdw和外部表，在opengauss系中同样有postgres_fdw、oracle_fdw(for Oracle)、mysql_fdw(for MySQL)， 在EDB中postgres_fdw、oci_dblink(for Oracle)。但是发现对于opengauss到远程 opengauss的使用dblink访问时(有oracle应用迁移而来)， 在oracle中常用的select * from t1@dblink1访问时，提示 remote table ‘t1’ does not exist, 即使创建user mapping时使用的t1表schema用户。如果应用中存在原oracle语法需要调整，影响postgresql和opengauss, 简单记录opengauss中的问题。

在PostgreSQL数据库中，与硬件基础环境依赖相关的参数，默认配置通常不适合生产环境。正如 PostgreSQL wiki 页面所述，默认配置的选择是为了在各种可能缺乏大量资源的设备上更容易地安装数据库。Oracle数据库也存在类似的问题，因此在内存相关的参数上基于Advisor框架推出了ASMM和AMM自动管理，但大部分参数如优化器相关的，仍然是针对通用场景设计的。当然，也有大量的Oracle DBA基于自己的经验整理出了一些最佳实践参数。相较之下，PostgreSQL的参数数量远少于Oracle。下面整理了几个基础的数据库调优参数。

在存储过程内可以调用其他多个存储过程或函数，这是支持 存储过程（procedure）的数据库都支持的，近日在做oracle到opengauss系(MogDB)的plsql对象做复审时，发现在一个主存储过程内部调用了其它多个子存储过程，但只执行了其中的第一个子存储过程，Exception捕捉了错误提示SQLERRM is: query has no destination for result data， 后来发现是因为存储过程改写时内部调用子存储过程前加了”call” ,其实用”PERFORM”也没问题

在Oracle 11g升级到更高版本时，默认不再提供 wm_concat 函数，而是用 listagg 函数替代。然而，很多应用程序在12c或19c中可能自定义了类似 wm_concat 的函数，例如 my_wm_concat。这些函数被广泛使用在应用程序中。当这些应用程序的数据库迁移到国产数据库如OpenGauss或PostgreSQL时，如果希望数据库层面兼容而不修改应用代码，通常迁移工具只能做语句规则替换。

对于自定义函数的迁移，由于人工改写时对Oracle或OpenGauss/PostgreSQL不熟悉，这可能会浪费一些时间。 简单纪录一个案例。

前几日一客户问我在oracle执行unix_timestamp函数报错，心想这不是MySQL的函数吗？难道oracle引入了？找了一圈到oracle 23ai也没有自带该函数，可以自定义函数实现， 在去年的一个oracle迁移到PostgreSQL系数据库里，有套业务库大量使用epochs做为datetime，这里简单记录在oracle, mysql ,postgresql中如何做unix epoch到datetime的转换.

两年前，Rick Branson撰写了一篇备受关注的文章，题为《10 Things I Hate About PostgreSQL》，其中总结了他对PostgreSQL的十大批评点。作为一位拥有近20年PostgreSQL使用经验的专家，他提出的问题是客观的。尽管他本人深表认可PostgreSQL，并且是其坚定的拥护者，但他不赞同一些人对其无条件的赞美。简单地看看国产数据库在解决这些问题上的进展，或许可以提供一些参考。

在数据库中，有时需要一种快速简便的方法来生成随机字符串来填充文本列，因为目前PostgreSQL中没有生成随机字符串的函数，可以考虑使用 Orafce 扩展，其中包括一个生成随机字符串的PostgreSQL 函数。或者创建自定义函数实现，如果使用orafce中的dbms_random生成函数记的检查可能与oracle一些形为不同。

在Postgresql中可以使用format()打印SQL, 使用$[tag]$ 匹配引号，还可以使用format type格式化文本对齐与标识自动加引号，创建易于维护的脚本，没有硬编码文本，并且不会忽略标识符的双引号。