ANBOB™

最近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”

近期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. 简单记录该问题。

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

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。

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

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

前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还有两种特殊情况

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

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

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

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

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

openGauss/PostgreSQL/kingbase中的预写式日志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, 但最终确认是中间件配置问题， 这里简单记录一下.