ANBOB™

中国信息安全测评中心发布《安全可靠测评工作指南》（试行），明确安全可靠测评工作的负责单位，测评对象范围，测评申请和实施相关流程等。安全可靠测评主要面向计算机终端和服务器搭载的中央处理器（CPU）、操作系统以及数据库等基础软硬件产品.

Today, I noticed that the customer’s system tablespace usage is quite large, currently around 3.5TB. The largest object is the system.Logmnr_restart_ckpt$ table, which is already close to 2TB in size. The next largest is the aud$unified table used for unified auditing. In my blog yesterday 《Know more about Unified Auditing in Oracle 19c》

Today, a customer encountered a database issue in an Oracle 19c 4-node RAC environment on an Oracle Exadata machine. The database is experiencing a high number of active sessions—thousands in total—indicating waits for ‘enq: hw contention’ and ‘enq: tx contention.’ The blocked business session is executing the SQL statement “insert into AUD$UNIFIED…,” related to unified auditing of the database

在OceanBase数据库中，有多种维护操作用于确保数据的一致性和提高性能，其中包括冻结（Freeze）、转储（Dump）和合并（Merge）。这些操作对于数据库的健康运行至关重要。下面分别介绍如何查看这些操作的状态和相关信息。

You can easily track the duration of each export/import operation by directing the export/import job to write timestamps to the logfile using the LOGTIME parameter. For more details, refer to Expdp/Impdp LOGTIME.

However, simply having this information alone is often insufficient, even if you know there was a version or operating system change. What’s really needed to diagnose or analyze performance is concrete data—and that’s where the METRICS and LOGTIME parameters come in handy.

I have seen problems with Local Write Wait in the Oracle database, normal tables in the databases were being used for temporary working storage before that data was then written to another table. The content of the working storage tables was then cleared out by periodically truncating them.

在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中的事务回滚时间。

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