ANBOB™

今天在客户一套库发现了个bug, select count(*) 与select *明细记录数不一致， 环境mogdb 508， 前者使用index only scan, 后者是index scan , 这种情况在oracle有时也能遇到，通常是索引条目与table条目不一致，如因为lost write导致，可以drop 并create index重建索引恢复，但是opengauss中还是第一次，在postgresql中控制记录的除了table, index还有可见性的vm，简单记录一下该问题。

日志是数据库用于诊断解决问题的途径，在生产环境中开启过多可能会导致性能问题，过少可能缺失日志，配置时有必要微调默认的日志配置参数，对应多个log_xxx参数，要达到理想的平衡，需要深入了解各种 PostgreSQL logging 指令是关键。定制日志记录设置以精确满足您的监控和故障排除需求。或何时可以动态的开启。

翰高数据库 Highgo是基于PostgreSQL的数据库，但是版本较多有基于postgresql 9 、12、14多个版本，同时在兼容模式上也并不统一，如支持pg, oracle和正在增加的MySQL兼容模式，如V9.5版本可以实现一份数据，两种解析引擎模式的支持，同时在V9版本登录时还有实例级用户和数据库用户级，简单整理总结以扫盲。

在PostgreSQL中的时间类型较多，如TIME, DATE, INTERVAL, TIMESTAMP,和Timestamp With Timezone(TIMESTAMPTZ) ， 而timestamp类型精确度非常高，如date类型是只有年月日，time又只有时间分秒，而timestamp是两者组合，同时可以带时区，如有在些基于postgresql国产数据库中为了兼容sysdate，注意函数的返回精确度，防止数据迁移丢失精度，但有时用户希望使用精度较低，如按日期检索和创建索引时有点有趣。为了说明这一点这里测试一下。

随着数字经济的快速发展和数据量的激增，高性能数据库系统成为企业业务的核心基础设施之一。在全栈国产化的背景下，如何构建高效、可靠的存储架构，实现 100 万 IOPS 的性能目标， 做为集中式数据库的基础设施提供支持，成为企业关注的重点。本文探讨通过 NVMe SSD 和硬件 RAID 卡组合，构建集中式数据库系统的技术路径。如利用 4 块NVMe SSD，在 RAID 0 下实际性能可超过 1,600,000 IOPS，完全满足高负载数据库的需求。

前两篇在《VIEW dependencies in Oracle、MySQL、PostGreSQL(数据库比较系列十一)》《Alert : PostgreSQL inline Subquery or View 包含volatile functions 阻止谓词推进(Predicate PushDown)》记录了因为view 包含Volatile Function导致的性能问题，通常，PostgreSQL 函数可以按如下方式标记：VOLATILE、STABLE、IMMUTABLE , 而这也是算最被广泛忽视的性能问题点，这篇文档整理个SQL列出所有包含”VOLATILE” Function 的View, 判断是否可以修改稳定性属性。

《Oracle、Oceanbase、Kingbase、GaussDB、达梦数据库比较系列(二十七):子查询中的函数投影裁剪》 测试在inline subquery中包含函数列投影时裁剪或叫SLP(select list pruning) ,如果函数的Volate属性是volatile的影响，函数的不稳定性除了影响投影还有join 的view包含该函数时，影响谓词条件的推入等，最近在highgoDB遇到了一个SQL性能问题，其实所有pg系数据库如gaussdb,opengauss,kingbase等都存在。下面演示一下这个问题。

在有些开发习惯中，如查询分页或统计查询，有些开发是基于明细的查询而外层直接加1层汇聚查询，如select count(*) from (select ….)， 但子查询中可能有一些函数或主查询根本不需要的列， 在oracle中的查询转换中如select-project-join或select list pruning， 或VIEW merge SPJ,CVM 都是为了不影响SQL结果一致性，而优化低效的SQL. 但是从oracle迁移到其它数据库中，因为CBO的差异，导致SQL性能大量衰减，需要手动改写SQL， 最近从oracle迁移到pg系国产库，发现一个view中使用了function, 而外部查询根本不关系该列值，就是一个无效的查询列，无意义的函数调用， 需要注意。

最近在迁移oracle到一个基于PostgreSQL系国产数据库时，发现存在一个问题，为了增加数据迁移顺利，把在oracle中在表列上定义的not null约束，全部更改了外部的CHECK not null 约束，这样就可以在建表、导数完成后再增加check约束。虽然这种功能上几乎一样，但是在性能上还是有一些区别，这篇简单的记录。

我和我的团队一直在做oracle到国产新创的工程，在oracle数据库中如加载菜单或上下关系的记录时，使用一种start with connect by prior的关键字提供分层查询和遍历方法， 但是对于基于Postgresql的数据库中需要改写，可以借用通用表表达式(CTE)的方法with RECURSIVE（）, 同时对于排序时ORDER SIBLINGS BY可以对分层查询分组排序。这里简单的演示。

在 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字符集查询会乱码，验证在源库入库时错误，迁移时需要注意。

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

当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 的闪回功能，以及闪回表和闪回查询的体验。或错误操作后快速恢复数据。

在上一篇笔记中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 作为主键？在大数据集时性能上存在一些差异，同时还有一些安全因素。