ANBOB™

最近在客户的环境中遇到一个较为罕见的问题，数据库实例的alert日志持续报告ORA-4031错误，导致一系列级联问题，包括ORA-600错误、归档失败、ASM实例通信失败等现象。同时，INACTIVE连接数异常增加，进一步可能出现数据库链接数耗尽。问题的核心出现在ASM实例，日志中反复出现ORA-4031错误kglseshtTable ，尽管ASM实例的SGA已经配置为4GB，这个大小在正常情况下应当足够使用，但此次却是首次出现此类问题。

该环境为Oracle 11.2.0.3版本，部署在2节点RAC架构下，运行于RHEL Linux 6.9操作系统，并且已启用HugePages。

Critical to performance is that not every change is copied to the flashback buffer— only a subset of changes. If all changes to all blocks were copied to the buffer, then the overhead in terms of memory usage and the amount of extra disk I/O required to flush the buffer to disk would be crippling for performance. Internal algorithms limit which versions of which blocks are placed in the flashback buffer, in order to restrict its size and the frequency with which it will fill and be written to disk.

最近一客银行客户的Oracle环境，在部署了DSG做数据抽取后，数据库频繁的重启，希望分析一下原因， 环境oracle 12c 2nodes- RAC on RHEL x86-64 7.3 , 数据库实例为Datatguard Pyhical Standby端，使用多租户。开始LGwr等待 ‘reliable message’，后出现IPC Send timeout detected， 过几分钟后实例2驱逐，不久后实例1 crash 。Oracle home和/ 使用XFS 文件系统。 问题期间大量进程活动，从ps查看处于D状态，并且WCHAN等待为xlog_G开头的函数调用，这里记录一下该事件。

在 PostgreSQL 中，PL/pgSQL 不直接支持 TABLE OF 类型，这是 Oracle PL/SQL 中的一种集合类型。不过，PostgreSQL 提供了其他方式来实现类似的功能，例如使用数组、复合类型（composite types）和表值函数（table-valued functions）。最近在一个生产数据库oracle迁移到postgresql替换过程中，遇到了拆分由逗号分隔的字符串返回table的需求

最近在从orale迁移到Postgresql系的数据库时，迁移工具(Java JDBC)几张表迁移失败，源库和目标都是GBK字符集，但在迁移过程中提示ERROR: character with byte sequence 0xe4 0xb8 0xad in encoding “UTf8” has no equivalent in encoding “GBK”，说明在GBK数据库中有部分列数据的值是UTF8编码，这种以GBK字符集查询会乱码，验证在源库入库时错误，迁移时需要注意。

Recently, a customer’s Oracle database RMAN backup job failed. When doing a full backup, it took a long time to complete. After checking the database, it was found that the backup process was waiting for ‘enq: TC – contention’. The environment was Oracle 12.1 2-nodes RAC. I would like to record this problem.

我和我的团队近2年一直在做迁移oracle到国产库的项目，数据迁移相对于PLSQL对象兼容改写更加容易，一般迁移工具做好源和目标的data type映射基本就可以，但是有一些情况，如《Oracle国产化改造迁移时的问题: Number data type中的 invalid number》记录的那样无效number，有些数据在oracle中可以存储，但迁移到目标库时可能无法存储，最近我们在迁移一套oracle到postgresql系的国产库时，在date数据类型的列出现了无效日期数据0000年。

扩展统计信息（也称为列组扩展）是 Oracle 11g 中引入的重要统计信息改进之一。虽然 Oracle Cost Based Optimizer 能够获得正确的单列选择性估计，但它无法计算出查询谓词中存在的两个或多个相关列的联合的基数。为这种列的联合计算的列组扩展旨在帮助 CBO 弄清楚这种列的相关性，以便获得准确的估计。但在某些情况下，CBO 拒绝使用列组扩展。

当Oracle DBA开始接触PostgreSQL系数据库时，总是会对Schema和USER产生一些混淆。在 Oracle 中，Schema和USER是一对一的关系，Schema和USER之间没有真正的区别，在一些基于PG国产数据库可能在创建用户时递归创建了同名schema。在 PostgreSQL 中，情况有所不同：用户创建的所有对象都是在特定Schema（或命名空间）中创建的。其他用户可能有权也可能无权使用此对象，甚至有权在特定schema中创建新对象。与 Oracle 相比，PG Schema概念又有点像Oracle Tablespace。最近一套数据库在迁移PG系国产库时，遇到了synonym的问题，刚好再总结一下schema与user.

Oracle 提供了丰富的闪回功能，帮助用户在数据丢失或错误操作后快速恢复数据。最近，我们注意到 GaussDB 也支持部分闪回功能。在这里，我将记录一下在 GaussDB 中使用 drop、truncate 的闪回功能，以及闪回表和闪回查询的体验。或错误操作后快速恢复数据。

昨天Oceanbase V4.3发布会，因为工作忙原因无法现场参加学习，近几年国产数据库在快速迭代，无论是bug修复还是功能引进，OB的版本的迭代速度和客户发展速度是值得肯定，但是似乎在稳定性和知识库上还是存在一些问题，就在OB发布会的同一天，我们另一批人因为新上的Oceanbase在焦急的处理着故障，一个租户的内存耗尽，然后级联的活动会话增加,CPU耗尽到重启。SQL限流失败，提示ORA-00600: internal error code, arguments: -4013, No memory or reach tenant memory limit, 查看内存使用率。

在上一篇笔记中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可以实现，当然，清除缓冲区缓存并不是您通常想要在生产环境中执行的操作，但这对于教育或调试目的来说非常方便

在 OceanBase 数据库中，主备副本（Replica）的概念对于理解和优化查询性能非常重要。OceanBase 作为一个分布式数据库系统，通过多副本机制来保证数据的高可用性和容错性。每个数据分区（Partition）都有一个或多个副本，其中一个是主副本（Leader），其他为备副本（Follower）。本篇讨论如何确认某张表的leader 节点？如异常时无leader节点什么原因？

在 OceanBase 数据库中， “Queuing”表指在应用程序或特定业务场景中用于实现队列功能的表。因为OB是LSM Tree分级存储，默认设置下，一张表中删除的行在 OB 每日合并前并不是真的删除，而只是在内存里打了个删除标记，OB major freeze/merge期间才会真正处理为删除。而频繁的堆积”mark for delete”记录，之前的一些如全表扫描的执行计划会出现逐渐变慢问题。

今天一客户的TiDB数据库环境业务查询报错，单条SQL的执行内存上限，提示如下：
Your query has been cancelled due to exceeding the allowed memory limit for a single SQL query. Please try narrowing your query scope or increase the tidb_mem_quota_query limit and try again

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

中国信息安全测评中心发布《安全可靠测评工作指南》（试行），明确安全可靠测评工作的负责单位，测评对象范围，测评申请和实施相关流程等。安全可靠测评主要面向计算机终端和服务器搭载的中央处理器（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