ANBOB™

SQL语言当今在数据查询分析这块地位至今无法撼动，曾经的NoSQL也开始疲软，口号从”no SQL”也变成了“not only SQL”或“no , SQL！”， 但SQL的开发能力参差不齐，有些是从ORACLE数据库转到postgreSQL的，相同SQL的结果不并相同，在性能上也并不是所有人都可以编写高效正确查询，这里简单列几个在PG中几个SQL注意事项。

openGauss/PostgreSQL中的预写式日志WAL（Write Ahead Log），又名Xlog或redo log,相当于oracle的online redo log, 不同的是oracle online redo log是提前创建几组滚动使用，但在opengauss中只需要本配置参数控制WAL日志的周期，数据库会一直的创建并自动清理，但存在一些情况WAL日志未清理导致目录空间耗尽，或目录空间紧张时手动删除wal日志时，比如如何确认在非归档模式下哪些WAL日志文件可以安全删除？

最近有家银行客户一套核心凌晨跑批时报出了ORA-04036,与12c后增加的PGA_AGGREGATE_LIMIT有关，环境oracle RAC 12.1.0.2 on AIX， 临时增加了PGA_AGGREGATE_LIMIT参数大小解决，事后找我分析原因
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

一家内衣品牌的客户，环境oracle 11.2.0.4 rac on linux, db alert log日志中出现应用查询提示oracle ORA-07445: exception encountered: core dump [kkqteSetSubPartNums()+355] [SIGSEGV] [ADDR:0x7FEFCA3BDFB8] [PC:0x7818D8F] [Invalid permissions for mapped object] [] 和ORA-00600: 内部错误代码, 参数: [kghrst:ds], [0x7FFC26461030]， 简单记录该问题

最近遇到这个案例大量FG prorcess堵塞，19c (19.4) 2nodes RAC, 等待Library Cache Load Lock， 堵塞会话为REC0， 该进程等待gc cr block lost. 同时在rec0进程trace文件中提示
IPCLW:[0.0]{-}[WAIT]:PROTO: [1661188358080974]ipclw_data_chunk_process:1165 Discarding msg with seq # 875492546, expecting 2730385062
IPCLW:[0.0]{-}[WAIT]:PROTO: [1661188358080974]ipclw_data_chunk_process:1165 Discarding msg with seq # 875492587, expecting 2730385062

Oracle 19c RAC实例大量会话hang,等待事件为’enq: TX – contention’， 做hanganalyze 堵塞进程为RECO， ‘buffer busy waits’<='enq: TX - contention' (cycle) RECO与前台进程形成死锁， 分布式事务表dba_2pc_pendings无记录。简单记录处理过程.

前一段时间发布了openGauss 5.0，做为激进派的我们生产环境立即安装一套，可以在使用MTK工具迁移库时提示”charset”语法错误，为关键字KeyWord，在关键字有一个限制，所以关键字越少那从其它库迁移时在SQL文本、对象名上限制改动就越少， 每个版本关键字数量也在变化，不过最新的Postgresql要比openGauss少约1/3， 之前这套库从oracle迁移到opengauss3.1不存在该问题， 如果有数据库迁移时使用该关键字当心。

最近有个银行客户咨询，他们一个系统有个SQL在凌晨1点左右执行计划突然变差了，数据库为oracle 11.2.0.4 RAC， 从AWR看数据库该时段实例级几乎空闲，上线很久的业务，问题时间点无人为操作，SQL特征是查询一个分区表，2个列上查询条件，并不包含分区键列， 其中有一个列使用了绑定变量，执行计划有原来使用绑定变量列的索引改为全表分区扫描，直到白天10点以后人为收集了统计信息恢复正常。

有一个项目从oracle迁移到了opengauss（MogDB发行版）后，有部分应用在运行一段时间后会超时， 日志中一些Socket closed错误， 执行的是从数据库中unload一些查询数据离线存储，常见的问题有网络防火墙， 或有一些timeout配置，或网络闪断等，逐一排除，当然在出问题时，应用厂家可能出于责任原因并不会坦诚，变更的是DB，会把怀疑方向指向DB, 但最终确认是中间件配置问题， 这里简单记录一下.

在openGauss数据库后期维护中难免有数据迁移或复制， 比如从oracle异构数据迁移，或在同一个server中复制一个schema到另一schema， 或是从另一个server复制到本server， 有一些命令行工具可以高效率的处理这些需求，并且可以迁移数据不生成落地文件，提升迁移速度,这里简单记录三种需求。

Postgresql系为了避免像oracle ora-1555的问题，使用非undo的机制， 但需要周期性的做VACUUM，否则表上的dead tuples就没有办法复用或回收。 并且在PG或OG数据库Vacuum的最老位置是系统级的，如果有一个长事务存在，那长事务时间的其它表也没办法Vacuum，因为它不确认你是否会查其它表， 随时间推移，对于update,delete较多的表就会导致表膨胀较为明显，影响系统性能， 如果无法限制应用，此时可以定期的KILL一些长事务会话..

对于oracle DBA查看数据库实例参数可以在sqlplus中使用show prameter xxx 模糊匹配非隐藏参数或已修改隐藏参数，当然也可以查询v$ 的视图， 在openGauss或postgresql当前版本中需要匹配输入参数名，当然参数名我们不可能完全记的全名，模糊搜索需要手动创建个shell方法。