Troubleshooting Oracle 12c/19c expdp slow due to query for V$OPEN_CURSOR

最近一客户的Oracle 19c环境在使用expdp导出分区变慢任务积压很严重,对于这个客户每月几万分区的EXPDP备份无法忍受,几M小空分区都要6分钟以上,导出速度和导出需求一样不科学☺。对datapump进程可以做sql trace跟踪,同时从导出时间段的AWR的TOP SQL看,这库似乎也没啥正常业务负载, TOP 1 SQL是DATA pump worker在查询v$open_cursor

,

Oracle ASM rebanlance fail with ORA-59048 when drop failgroup disk

Oracle数据库在12.1.0.2 以上版本asm中,如果normal冗余的磁盘组Failgroup少于3个或者High冗余的Failgroup少于5个是不允许删除Failgroup的 。或配置Normal或Flex冗余 ASM 磁盘组,具有 3 个常规故障组和至少 1 个仲裁故障组, 当Drop 1 个常规故障组时, rebalance 结束时,在 v$asm_operation 中可以看到 ORA-59048。

,

More abort Oracle 12c RMAN ACTIVE DUPLICATE

最近一个200TB的oracle需要创建standby dataguard, 大量的bigfile 表空间,这么大的数据库适合不落的duplicate方式,在搭建过程出现了bug,修复单个报错的文件遇到了问题,思路如何提速时发现了这个特性,意识到好久没有看oracle新特性了。USING BACKUPSET这个特性很棒。

, ,

PostgreSQL/openGauss explain解析(五): Bitmap Index Scan 和 Heap Blocks、Recheck Cond

在前面几个index only scan测试中如果没有改random_page_cost值,相信应该看到过Bitmap Index Scan 的执行计划,也可以使用参数enable_bitmapscan允许或禁用位图扫描,在oracle中CBO当1个表上两个索引(B树索引)先组合”bitmap and “再回表过滤数据,参数_b_tree_bitmap_plans可以禁用该形为,通常出现这种性能不值考虑组合索引,在PostgreSQL中同样biatmap scan可以用于单表多索引的联合过滤

, ,

PostgreSQL/openGauss explain解析(四): indexonlyscan和 覆盖索引

前2篇中对index only scan的测试能看出在 Oracle、MySQL(InnoDB)、PostgreSQL三类数据库中,对于OLTP高负载的场景中,oracle和mysql(innodb)都是块级别的MVCC是可以做到真正的index only scan, 而postgresql因为MVCC的可见性不存储在索引,在数据变更后会带来indexonlyscan with heap fetchesl回表,效率可能有所减退。通常在Oracle中如想做到index 覆盖到所有查询的列,会创建多列复合索引或function索引,避免索引查询回表,但在Postgresql或openGauss系中索引相对Oracle还有两种特殊情况

,

PostgreSQL/openGauss explain解析(三): Heap Fetches

在上一篇中提到了indexonlyscan, 在它执行计划中可以看到有一行Heap Fetches,这篇主要记录一下它的含义。因为Postgresql系的MVCC实现原理,索引中不存在可见性映射(Visibility information),在PostgreSQL中的indexonlyscan 也并不总是scan index only, 简而言之就是如果表(heap)的数据没有对应可见性映射文件(table’s visibility map.)或不是全部完全可见,indexonlyscan的执行计划还是要回表(heap)去检查数据,回表数据记录在heap fetches.

,

PostgreSQL/openGauss explain解析(二): indexonlyscan cost

PostgreSQL系(openGASUSS)数据库中的所有索引都是二级索引, 数据表段( heap)和索引段(index)分别存储,通常对于多列表的SQL只返回或where中仅少量的列时,希望可以只从索引中检索,而不用再从索引回表返回数据(本篇不考虑可见性)提高查询效率,像在oracle中有index full scan和index fast full scan的执行计划,在Postgresql中也支持Btree index的indexonlyscan, MySQL中同样支持,但发现PostGreSQL默认配置的SQL优化器通常判断索引的cost大于表扫描,导致仅查询索引列也未使用索引

使用dblink产生的”SELECT /*+ FULL(P) +*/ * FROM XXXXX P ” 解析

在MES平台看到一个提问,应用程序总时会自动产生类似”SELECT /*+ FULL(P) +*/ * FROM XXXXX P “这类SQL,确认不是应用代码中调用,看到FULL hint对于SQL调优人员可能会捶开发人员的冲动 ,同样对于SQL审核或SPA、 数据库国产迁移性能分析等需求抓到这类SQL可能就白白浪费感情。这SQL是数据库自动产生的吗?是!它是DBLINK调用的。

,

Troubleshooting oracle CRS start cssd fail with log show “unable to escalate to real time“

Oracle 11.2.0.4 RAC 安装完重启CRS启动失败,提示ocssd无法启动,ocssd日志中查看提示如下错误, 提示在提升CSSD进程为real time模式失败。
clssscSetPrivEnv: unable to set priority to 4
SLOS: cat=-2, opn=scls_set_priority_realtime, dep=1, loc=setsched
unable to escalate to real time

,

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 RAC ‘gc cr block lost’ and ‘Library Cache Load Lock’

最近遇到这个案例大量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一些长事务会话..