ANBOB™

Oracle 20-22c是12c后的下一个大版本集，也有了大的改变，如本身就云架构数据库定位从20c起不再支持非多租户，了解新版本可以了解数据库的发展方向，减少不必要的麻烦，如短时间内再次升级功能不再支持应用程序又要重写， 对于安全方面同样也有一些变化，这里简单的记录。

一套12C R2版本的4节点RAC数据库，记录一起高并发业务繁忙时，DDL导致数据库出现大量前台会话长时间等待”enq: US – contention” & “enq: IV – contention” ，该SQL（INSRT VALUE）的只是一个Children cursor无法执行(sql_start_exec 时间已过去数小时)，第二个的children cursor执行效率正常，最终KILL 这些长时间运行前端会话解决。

尽管新兴的分布式应用程序受益于去中心化信任模型中，但当今大多数应用程序都具有中央权限（银行，代管公司，交易交易所，政府办公室等），并且借助Oracle数据库中的区块链表，可以使这些应用程序更安全，而无需增加更改为托管服务器的复杂性去中心化模型。这就是使用Oracle Database 20c本机区块链表的原因

前段时间遇到的一个案例，当编译一个invalid procedure时，自已会话堵塞自己等待’library cache lock’. 数据库版本Oracle 12.2， 当然这个procedure里面用到了dblink 嵌套procedure跨了3个数据库，在查看procedures定义时发现附加了”EDITIONABLE”

之前测试过《DUL 支持Oracle 19c》，目前ORACLE 20C官方文档已发布， 按惯例2020年第一季度会发布ON cloud平台版本和工程系统，第二季度会发布可下载非工程系统版本，我先尝尝鲜搞个测试版本使用DUL测试是否继续支持20c,包括blockchain table.

从12c 版本开始新引入DBA_DB_LINK_SOURCES(link_sources$)记录了远程dblink 曾登录本地数据的会话信息（hostname、IP, dbname、用户名、logon_time、logon_count），在使用DBLINK的环境中有时会看到，dblink session在等待“Enq: SQ – contention ”

前几日有位小兄弟问为什么有时使用explain plan for ….., 然后用dbms_xplan.display查看执行计划， 有时会提示“Error: cannot fetch last explain plan from PLAN_TABLE” 错误？ 其实这个问题在Oracle 12c 以后应该基本不存在，因为这是explain plan一种悄悄的行为变化

oracle dul是oracle的恢复利器， 它的传奇功能不再解释，但是dul和其它工具一样也是需要段块信息恢复数据，但是从oracle 11g开始支持了延迟段创建，那么使用dul unload table, unload user默认是不会导出未生成段的表对象， 这样恢复的数据理论也会因为表不存在而丢失部分空表。但是表结构是在数据字典中可以手动生成建表语句。

Starting from version 12.2, only if the multi-tenant option is used, this is changed, and the wait event ‘log file parallel write’ only is shown if the submitted IOs are not available after they are submitted, and thus the logwriter process has to wait for them.

记录一下oracle 12.2 RAC 在 IBM AIX 7.2 Power System上的安装，GI安装过程很慢，总耗时4小时。安装建议首选参考oracle 官方文档。

最近突然有一个oracle 12c R2环境的trace目录使用率暴涨，分析发现一天创建了几十万个trace，几乎是每个会话创建一个trace, 当前数据库也并未启用event。简单记录

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

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

一个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问题

最近有看到还有人在考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的形式创建，

一套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

有时为了提升SQL执行速度或减少redo而使用NOLOGGING选项， 或者在segment 级使用NOLOGGING属性， 将使用最少的信息记录到online redo logfile，但是对于DataGuard环境是基于redo应用，所以这也是在DATAGUARD配置时需要在数据库级启用FORCE_LOGGING原因，如果缺少了日志必要的信息，在RECOVERY介质恢复期间将受影响的块标记为已损坏, 查询V$DATABASE_BLOCK_CORRUPTION.CORRUPTION_TYPE为NOLOGGING

相信近几个月好些DBA一定都被SCN compat(兼容级别)在2019年6月23日自动从1直接跳级到3的问题搞的紧张兮兮， 现在这个特殊日期已经过去几天，不知道是不是觉的风平浪静有些失望, 最近应该都开始检查是否SCN Compat是否已自动变为3， 在auto rollover未禁用的情况下，还是有些情况下SCN compat当前并没有改变，下面列几种情况。