ANBOB™

瀚高数据库在我好多年前预学习PostgreSQL时就有耳闻，有瀚高公司维护，该公司在PostgreSQL国际社区贡献度中也是中国排名靠前的组织，发起了另一个开源项目IvorySQL，同样是兼容oracle的postgresql数据库，两者都是在PostgreSQL路线做了大量的创新与生态工具，我记录体验一把HighGo企业版。

在oracle数据库中有dictionary(dict)和v$fixed_table可以查询数据字典表和v$相关的系统内部对象，查询数据库内部对象不记的完整名称是可以直接从两个根对象记录中查找(TanelPoder‘s d.sql) , 对初学OceanBase的新手，也希望可以找到数据库中自带了哪些数据字典或view？兼容了oracle哪些view数据来源是哪里？如同在oracle中查询V$FIXED_VIEW_DEFINITION.

oracle ASM 从12c后引入了诸多特性，如FLEX ASM、Increased ASM storage limits、ASM instance V$ACTIVE_SESSION_HISOTRY 、ASM Disk Scrubbing外，最近发现还有一个关于ASM DISK rebalance 的增强EXPLAIN WORK FOR命令。12c 中新的 EXPLAIN WORK FOR 语句测量给定 ASM rebalance所需的工作量，并将结果输入 V$ASM_ESTIMATE 动态视图中.

近日有一套客户为oracle 19c（19.18）的环境，从ASH中可以发现一些查询堵塞等待较高的”latch free”， p2值latch#=39, latch name为 “object stats modification”，latch free从11g后较为不常见，多数都是具体的latch name, 可见这是一个比较稀缺的latch，记录一下这个问题。

前段时间整理过一篇《有哪些技术可以减少PostgreSQL/openGauss数据库的存储空间？》，记录过postgresql系数据库出现的膨胀表(索引也一样)可能会导致数据库空间浪费，在openGauss中发现存在一个现象，比如对一张几千万行的table做过千万级大事务更新或平时更新比例较多时，autovacuum的清理并不理想，导致出现几十倍的空间膨胀，记录一则处理案例。

oracle 11g R2环境1组normal冗余的ASM DISKGROUP包含3个cell的，每个cell为1个failgroup, 每个failgroup有48块ASM disks.因为一些硬件原因1个cell掉了19块disk，但offline后并未reblance完成，超过了“_asm_disk_repair_time”时间内没有online，被磁盘组自动drop force, 手动reblance时因为有1块asm disk使用不均衡free接近0MB，所以rebance会提示ora-15041错误。 此时add force与undrop均报错ora-15047. 处理rebalance需要空间，但加空间需要等上一个reblance完成的死结循环中。

SQL Translation框架是 12c 中的一项新功能，使开发人员能够在不更改底层代码的情况下替换SQL代码。这个特性是sql profile baseline的增强，原来是可以不动SQL文本替换执行计划，现在是连sql文本都可以“隐式”替换。这功能可用于在异构数据库向oracle迁移时，替换SQL代码。

opengauss系数据库insert失败因缺少匹配分区表，提示inserted partition key does not map to any table partition ，在oracle中一样存在该问题，建议月末或年末提前查询下个月的分区是否存在，匹配oracle的dba_tab_partitions,在postgresq 11后查询pg_partitioned_table,而在openGauss中查询pg_partition.

《如何恢复Truncate sys.IDL_UB1$？》之前分享过这个对象被清空时的恢复，近期又有用户发现system表空间占用较大，发现IDL_UB1$是top对象，于是乎采用取表DDL，rename原表名，新建该表，数据导出导入方式重建该表。但是发现rename IDL_UB1$表，新创建IDL_UB1$后，exp无法导出，所有DDL无法执行, 包括无法rename回退，庆幸的是当前数据库还没有重启，否则就无法正常启动了，恢复更加复杂。

前不久一套oracle 12c RAC环境，客户反馈数据库出现过行锁enq: tx row content和library cache lock。blocker session为dbms_scheduler执行的sql是在收集统计信息，同时db alert log频繁提示qsmqChkOCMV : Timeout while locking object:NNNN, 简单记录.

最近客户一套oracle 19.14 standalone Database做的cascade dataguard环境，暂且认为是A->B->C三台单实例, 但总是A->B的延迟，从oracle 12c后引入real time cascade，所以如果依赖该特性对延迟要求较高， 分析A->B延迟发现，B库总时会出现GAP,并且未自动FAL，需要人为干预, 并且主库alert日志报错出现:
ORA-03135: connection lost contact
TT02 (PID:64459): Error 3135 for LNO:3 to“xxx”。

最近一套oracle 11.2.0.3 2-nodes RAC on AIX环境数据库，触发ora-600 [kjucvl:!busy] 和 ORA-00600: , : [kjuscv]后db instance crash, 但重启后使用plsql dev客户连接实例的两个节点，sysdate返回不同的时间，同时从db alert log 的时间也能发现实例重启后日志倒退了8小时，看来还是timezone问题，简单记录。