10个PostgreSQL中常见SQL错误
SQL语言当今在数据查询分析这块地位至今无法撼动,曾经的NoSQL也开始疲软,口号从”no SQL”也变成了“not only SQL”或“no , SQL!”, 但SQL的开发能力参差不齐,有些是从ORACLE数据库转到postgreSQL的,相同SQL的结果不并相同,在性能上也并不是所有人都可以编写高效正确查询,这里简单列几个在PG中几个SQL注意事项。
如何在openGauss/PostgreSQL手动清理XLOG/WAL 文件?
openGauss/PostgreSQL中的预写式日志WAL(Write Ahead Log),又名Xlog或redo log,相当于oracle的online redo log, 不同的是oracle online redo log是提前创建几组滚动使用,但在opengauss中只需要本配置参数控制WAL日志的周期,数据库会一直的创建并自动清理,但存在一些情况WAL日志未清理导致目录空间耗尽,或目录空间紧张时手动删除wal日志时,比如如何确认在非归档模式下哪些WAL日志文件可以安全删除?
Troubleshooting ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
最近有家银行客户一套核心凌晨跑批时报出了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
Troubleshooting Oracle 11g ORA-07445 [kkqteSetSubPartNums()+355] and ORA-00600 [kghrst:ds]
一家内衣品牌的客户,环境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], 简单记录该问题
Troubleshooting oracle 19c wait ‘Library Cache Load Lock’ ,blocker REC0 wait ‘gc cr block lost’
最近遇到这个案例大量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
Troubleshooting Oracle 19c hang wait ‘enq: TX – contention’ when RECO distributed Transaction recovery
Oracle 19c RAC实例大量会话hang,等待事件为’enq: TX – contention’, 做hanganalyze 堵塞进程为RECO, ‘buffer busy waits’<='enq: TX - contention' (cycle) RECO与前台进程形成死锁, 分布式事务表dba_2pc_pendings无记录。简单记录处理过程.
Alert: openGauss V5.0 vs. V3 keywords增加了 “charset” bug
前一段时间发布了openGauss 5.0,做为激进派的我们生产环境立即安装一套,可以在使用MTK工具迁移库时提示”charset”语法错误,为关键字KeyWord,在关键字有一个限制,所以关键字越少那从其它库迁移时在SQL文本、对象名上限制改动就越少, 每个版本关键字数量也在变化,不过最新的Postgresql要比openGauss少约1/3, 之前这套库从oracle迁移到opengauss3.1不存在该问题, 如果有数据库迁移时使用该关键字当心。
Troubleshooting Performance SQL执行计划改变因为Height Balanced Histogram 的Popular Value
最近有个银行客户咨询,他们一个系统有个SQL在凌晨1点左右执行计划突然变差了,数据库为oracle 11.2.0.4 RAC, 从AWR看数据库该时段实例级几乎空闲,上线很久的业务,问题时间点无人为操作,SQL特征是查询一个分区表,2个列上查询条件,并不包含分区键列, 其中有一个列使用了绑定变量,执行计划有原来使用绑定变量列的索引改为全表分区扫描,直到白天10点以后人为收集了统计信息恢复正常。
oracle to openGauss: 迁移后中间件socket closed,这锅DB不背
有一个项目从oracle迁移到了opengauss(MogDB发行版)后,有部分应用在运行一段时间后会超时, 日志中一些Socket closed错误, 执行的是从数据库中unload一些查询数据离线存储,常见的问题有网络防火墙, 或有一些timeout配置,或网络闪断等,逐一排除,当然在出问题时,应用厂家可能出于责任原因并不会坦诚,变更的是DB,会把怀疑方向指向DB, 但最终确认是中间件配置问题, 这里简单记录一下.
How to migrate data from Oracle or another Schema or another openGauss to openGauss(PostgreSQL)?
在openGauss数据库后期维护中难免有数据迁移或复制, 比如从oracle异构数据迁移,或在同一个server中复制一个schema到另一schema, 或是从另一个server复制到本server, 有一些命令行工具可以高效率的处理这些需求,并且可以迁移数据不生成落地文件,提升迁移速度,这里简单记录三种需求。
How to Shell Script to execute SQL scripts( kill session) using psql/gsql for openGauss or PostgreSQL?
Postgresql系为了避免像oracle ora-1555的问题,使用非undo的机制, 但需要周期性的做VACUUM,否则表上的dead tuples就没有办法复用或回收。 并且在PG或OG数据库Vacuum的最老位置是系统级的,如果有一个长事务存在,那长事务时间的其它表也没办法Vacuum,因为它不确认你是否会查其它表, 随时间推移,对于update,delete较多的表就会导致表膨胀较为明显,影响系统性能, 如果无法限制应用,此时可以定期的KILL一些长事务会话..
‘show parameter ‘ for openGauss or PostgreSQL
对于oracle DBA查看数据库实例参数可以在sqlplus中使用show prameter xxx 模糊匹配非隐藏参数或已修改隐藏参数,当然也可以查询v$ 的视图, 在openGauss或postgresql当前版本中需要匹配输入参数名,当然参数名我们不可能完全记的全名,模糊搜索需要手动创建个shell方法。