密码保护:Troubleshooting ASM diskgroup mount fail with ORA-15040&ORA-15041 ASM Disk Header corrupted
无法提供摘要。这是一篇受保护的文章。
Troubleshooting Oracle instance start fail join cluster wait control file enqueue
最近1 Oracle Exadata X7客户ora instance 2被驱逐后,重启db instance 2启动挂起,影响另一实例instance 1, 随后终止启动,实例1运行正常。分析db instance 2启动时在等待control file enqueue超时,OS 日志显示“RDS/IB: conn <192.168.*.3,192.168.*.6,4> racing for more than 1s, retry”
Troubloshooting Oracle RAC node reboot and OS log show “kernel: qla2xxx[ ] Abort command issued”
近期1客户Oracle RAC 节点OS重启,协助分析原因,db层无日志错误输出,RAC层有vote disk I/O timeout, OS层 qla2xxx [0000:81:00.0]-801c:7: Abort command 和DEVICE RESET 操作。qla2xxx 是QLogic FC HBA的驱动,怀疑重启是HBA卡导致IO失败,导致disk timeout, CRS发起reboot. 简单记录该问题。
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/KingBASE手动清理XLOG/WAL 文件?
openGauss/PostgreSQL/kingbase中的预写式日志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点以后人为收集了统计信息恢复正常。