ANBOB™

前两天在停止一个CRS 时发现因为HAIP不存在， crsctl stop crs无法正常关闭CRS， 甚至使用-f 选项， 处理方法很简单，手动增加一个haip就可以。 环境是12c R2 on RHEL.

from 11.2.0.4, oracle use versioned KGL handle to store partitioned information, when DDL is execute against a partitioned object, it’s will increment a counter which is used is used in the KGL handle name that stores stores partitioning details. the counter is limited to 5 digits so once it exceed that digit count it migth pick up an old KGL versioned handle which would have stale data present.

wrh$_active_session_history记录的这些历史信息，可以通过dba_hist_active_sess_history视图进行聚合查询，wrh$_active_session_history是一个分区表，Oracle会自动进行数据清理。Oracle根据保留策略确定需要清除哪些,对于大型AWR表，数据是根据DBID,SNAPID存储在分区中。 如果分区中的所有记录都已过期，才会在自动清理数据时使用drop partition. 如果分区中有任何一条记录该分区都不会清除， 当SYSAUX表空间一直增长，如超过20Gb 时需要检查一下是否有AWR 的表一直未清理，如wrh$_active_session_history

节点2驱逐后无法再加入集群，日志显示是网络通信问题，查看开始时驱逐的原因也是VD CRS-1615:No I/O has completed 和 Network communication missing， 同时DISK HB和Network HB同时失败，并且存储和private network是双链路，用的也不是同一交换机。什么会导致同时出问题呢？

Oracle DB “secondary” index 叫辅助索引或次要的索引，名称是相对primary index命名的，但是在19c的dbms_auto_index.drop_secondary_indexes中可以看出删除的索引也并不是除了primary key以外的全部索引， 主键、外键、唯一键同样也会保留。 该功能可能目前也只能用于测试环境中， 如先把次要的索引全部删除，然后测试让数据库自动创建及删除维护相应的索引。

ora.crf是Cluster Health Monitor（以下简称CHM）提供服务的资源， 用来自动收集操作系统（CPU、内存、SWAP、进程、I/O以及网络等）的使用情况。 当然还是建议生产环境部署OSW来收集记录更久的信息， OSW是调用的OS 命令，而CHM 调用的是OS API,开销低、实时性强。 开始的版本是每秒一次，从11.2.0.3应该是变为每5秒一次。

简单记录一起存储突然断电导致的11.2.0.4 2-Nodes RAC恢复案例。
ORA-00600: internal error code, arguments: [2131], [33], [32], [], [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [ORA_NPI_ERROR], [600], [ORA-00600: internal error code, arguments: [kffbAddBlk04], [], [], [], [], [], [], [], [], [], [], []
ORA-00345: redo log write error block 120471 count 109
ORA-00312: online log 1 thread 1: ‘+DATADG/anbob/onlinelog/group_1.261.897563031’
ORA-15081: failed to submit an I/O operation to a disk

这是一个非常典型的dataguard 环境中存在的bug, 在oracle 11.1-12.1版本之间一直存在的BUG，当Physical Standby Dataguard 环境发现switchover或者failover后，在验证索引块上存在无效的scn时抛出的错误ORA-600 [2663]，或者有时附带ORA-600 [ktbdchk1: bad dscn]， 该BUG不会导致当前数据块上有数据丢失，也不会有数据勘误在索引块上。 这里简单记录.

1. Set 450502, level 1 -> to control block rejections for any index block.
2. Set underscores to reduce the limit from 10000 to something lower. If the limit is good enough, do not have to set these parameters.
3. If the limit must be reduced to below 1024 (using the underscore) additionally set event 450503 – it forces the code to accept whatever user sets.
4. Set 43822 – to control rejections for root/branch split.

This is expected behavior. ORA_TEMP_%_DS_% is only used when gathering histogram. SYS.ORA_TEMP_1_DS_% are global temporary tables created by dbms_stats to generate histograms for tables.

一个12C R2的2节点RAC, 节点1 8点左右数据库实例连接hang, 从数据库DB alert log中发现ORA-6544 [pevm_peruws_callback-1] [4021]错误, 可见前期出现大量的library cache 等待，影响了SQL解析和连接，因情况紧急kill 实例重启后恢复正常。

Oracle 12c很多情况下TRACE目录使用率增长迅速， 之前有总结过两篇异常情况，但是最近还是比较多，记录一下另一种情况。
Oracle12c R2注意事项： 因BUG生成大量的trace file 包含KRB: (rman module)
Oracle12c R2注意事项：ORA-12805问题

一个2节点RAC on HPUX平台的数据库实例1突然因为I/O 错误，数据文件读写失败，自动重启后不久再次因为Vating Disk不可用crs crash， 另一节点正常。后暂时停止问题节点,排查硬件的底层环境问题,确认数据库主机节点的SFP（Small Form-factor Pluggable）光衰减严重，导致数据传输丢帧，频繁重发数据帧导致数据库存储I/O延迟过高（58ms-100s）或间断，数据库IO错误。

2019.6.23 已过去，默认11.2.0.3 后的版本Compatibility 已auto Auto-rollover，开始解决方法还要大版本升级，目前Oracle 又陆续放出了几个低版本的opatch， 修复ORA-600 2552不用再大版本升级了，目前opatch 已经从10.2.0.4以后的版本都可以装one-off patch解决。更多信息可以看之前我的 《预警：2019年ORACLE SCN 兼容性特性( Compatibility)自动改变的影响》， 这里记录一下11.2.0.1 的修复方法.

如果V$Database_block_corruption 有记录有短时间内无法修复，如果告警天天告确实烦人，几年前有写过一篇Know more about V$BACKUP_CORRUPTION ， 这里有个DG 环境中因为primary db 没有启用force logging, 结果Standby db上好多nologging corrupted block. 解决方法之前也有写过 利用RMAN增量备份(Incremental Backup)修复standby 环境中的nologging corupted blocks ， 这里我想临时把这些记录清理掉，后期再修复。

最近有看到还有人在考oracle 11g, 12c 的OCP， 是陈年的OCP 有技术含量么？ 在我个人认为2009年后拿到的都一个样，16年前的8i OCP要过4门，
从2019年开始 Oracle 认证有了新的变化：
1， 以后不再有OCA ， 新Oracle OCP 只需要2门课程的考试(1Z0-082+1Z0-083)

DBMS_SCHEDULER 是一种新的JOB调度形式，提供了功能更加强大和跟踪的功能，说是新是相对DBMS_JOB, schedure从10G时引入已经十多年， 用于替换DBMS_JOB, 如果你升级19c 时原来的库有dbms_job对象，会在preupgrade.jar中提示Warning JOB_TABLE_INTEGERITY.注意从ORA 19C开始 DBMS_JOB总是以DBMS_SCHEDULER的形式创建，

在SQL的初始解析阶段PostgreSQL和ORACLE rdbms有很多相似之处， 如开始会进行语法、语义的检查，那些元数据存在system表空间(oracle）或 system catalog(PostgreSQL). 然后根据之前预准备的统计信息（可能动态采样）,CBO 会为SQL执行生成一个执行计划. 但是在解析完成后ORACLE和PG(以下用PG代替PostgreSQL)会存在一些差异，oracle会把执行计划存储在shared pool（Libaray cache）中对于所有会话可以共享，但是PG存储在program的本地内存中

一套Oracle 12.2.0.1 4-nodes RAC on Linux 环境, 又一个BUG会生成大量的日志信息如下， 之前分享过一个生成大量trace的笔记
Oracle12c R2注意事项： 因BUG生成大量的trace file 包含KRB: (rman module), 这里记录另一个bug.
# db alert log
2019-08-02T16:45:30.696722+08:00
Errors in file /u01/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_cjq0_24035.trc:
ORA-12805: parallel query server died unexpectedly

Indexes exist for versions 7.2.2 and 8.0.3. Author: Ric […]