ANBOB™

对于一个连续7*24小时的业务，如果session 1正在select查询一张大表，而另一个session尝试drop 相同的表，会发生什么？对于最流行的MVCC数据库oracle,mysql,postgreql需要对比，因为drop不只是字典表更新标记，还需要回收物理空间。在这几个数据库中的表现一样吗？Oceanbase和goldenDB及GreatDB的表现.

近期一个客户在vm环境外挂虚拟共享盘部署的oracle，类似AIX双机主备， 近期1主机异常hang死，另一主机启动数据库报错如下

ORA-01122: database file 2 failed verification check
ORA-01110: data file 2: ‘/oradata/anbob/sysaux01.dbf’
ORA-01200: actual file size of 1990400 is smaller than correct size of 2064640 blocks

之前有简单测试golang连接oracle和postgresql，最近刚好有客户问GOlang连接redis如何增加密码，这里简单记录，安装redis省略参考, go安装参考《Go语言(GO lang)连接Oracle Database使用godror》。

无法提供摘要。这是一篇受保护的文章。

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