ANBOB™

在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

在OceanBase数据库中， 数据库事务分为普通事务和分布式事务。长事务和悬挂事务会导致资源长时间不释放，等待会话长时间被阻塞，“悬挂事务”通常指的是那些未能正常结束的事务，即事务既没有被成功提交（COMMIT），也没有被回滚（ROLLBACK），如同oracle数据库中的dba_2pc_pending两阶段的分布式事务。 这类事务处于未完成状态，可能会占用数据库资源，并对后续的事务处理产生影响。需要重点关注这类异常的事务。

在Oceanbase数据库日常运维中，像oracle一样数据库的存储空间当到在上限时会在日志或ocp中提示预警，可能磁盘空间物理大小限制或DB参数限制， 分析空间不足的原因在分布式数据库OCEANBASE中相比ORACLE要复杂一些， 如何查看当前的使用大小？ 是哪一类文件占用较大？ 如果是temp文件是DDL 还是SQL 查询产生的？ 有没有可能temp文件泄露没有释放？如何定位temp使用高？ 本篇仅记录一些方法

在关系型数据库中做为主键使用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数据库迁移到国产数据库的咨询、评估及实施工作。在此过程中，我习惯考虑各种场景，这就像在使用一些老品牌的汽车时，虽然耐用性强，但如果换成国产汽车，可能就会遇到不同的问题。若前期考虑不周，类似的场景切换到国产数据库后，可能会出现意想不到的困难。

最近一个客户oracle数据库中大量的活动会话在查询v$active_session_history, 原因是一个监控软件的刷新ASH数据，但是该SQL正常也都是秒回，该数据库一次查询近6分钟，好奇要分析一下这个案例，但因为客户环境无法远程，所以无分析过程，这里记录我的分析思路，同时在分析v$active_session_history 发现取完整的SQL定义并不是很容易，记录oradebug peek , objdump, gdb等方式读取内存中FIXED VIEW定义的方法。

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