ANBOB™

在上一篇笔记中pg buffer中会记录除了数据外，还有XXXX_vm的Visibility Map， PostgreSQL 中的可见性映射在Vacuum期间起着至关重要的作用。它跟踪哪些表块仅包含可见元组，从而避免在vacuum操作期间扫描这些块。这显著优化了 I/O 操作，因为只处理可能包含死元组的块。同时对于Index only scan 时可见性映射文件也是决定是否需要回表的判断。

在 PostgreSQL 16 之前原生版本中，除了重新启动实例外，没有其他方法可以清除缓冲区缓存。没有像 Oracle 中 FLUSH BUFFER_CACHE 这样直接用于清空数据库缓存的命令。PostgreSQL 的缓存管理主要依赖于操作系统和自身的共享内存 ，在近期发布的 PostgreSQL 17 中pg_buffercache_evict可以实现，当然，清除缓冲区缓存并不是您通常想要在生产环境中执行的操作，但这对于教育或调试目的来说非常方便

今天朋友问如果truncate table如何在postgresql中恢复？另外还有drop , delete删除数据类操作，除了使用常规备份恢复，如果在oracle恢复有flashback query, recyclebin, 或在数据文件中的block补覆盖前抽取如基于rowid抽或DUL类工具扫描datafile , 在PostgreSQL开源软件中似乎只有备份恢复，那有没有其他手段呢？

在PostgreSQL有可能因为硬件(磁盘控制器或某些内存)或bug等未知原因，导致数据文件的page corrupted损坏,只限于少数页面，有没有办法从部分损坏的 Postgres DB 中恢复数据？
psql: FATAL: could not read block 0 in file “base/xxxx/xxxx”: read only 0 of 8192 bytes.
—
ERROR: invalid page in block xxxxxx of relation base/xxxx/xxxx

在关系型数据库中做为主键使用UUID还是整数序列是一直有人讨论的话题，在oracle、Postgresq、MySQL、Sql Server(GUID) 都有类似的对象， 那应该使用整数（ serials， sequences）还是 UUID 作为主键？在大数据集时性能上存在一些差异，同时还有一些安全因素。

最近，一位使用 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”也没问题