ANBOB™

当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

在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日志中提示, 而不是直接将业务置为只读模式，从而广泛影响应用。