ANBOB™

当前oracle 18c on-premise 还没正式发布，我只是用XD版简单测试几个小功能::
Feedback sql id
private temporary table
CANCEL SQL statement
SEQUENCE增强
Read-only Oracle Home (ROOH)
DBMS_SESSION.SLEEP
Inline External Table

Oracle RAC环境中有时常因为LMS进程取不到足够的CPU而hang,最终在lmhb监控进程发现lms hung超过70秒后而终止实例。lmhb是11G R2引入的RAC环境中新的后台进程，用于监控LMON、LMD、LMSn等RAC关键的后台进程

临时表空间是被分成不同的extent,在11g r2中每个extent为1MB，extent maps是cache在本地的SGA中，并在再重启时不会保存extent map所以在实例重启后可以完全释放临时表空间的扩展， 临时表空间(cache extent map)是按需扩展的，用完后会标记为free但不会回收(如果不重启)

朋友有套数据库出现了ora-600 [kclfadd_1]引起数据库实例crash, 数据库版本10.2.0.2 2-nodes RAC, 找我帮分析原因，定位BUG后，在不升级版本并安装oneoff patch后，节点2实例无法启动，在startup 过程种从alert log看在提示了一些后台进程启动后，到LCK0 进程启动后没有任何报错挂起，节点1正常

ORA-00600: [kwqidrdq: loop] reported on dequeue of a message from an Advanced Queueing (AQ) Multi-Consumer Queue Table.

Oracle ILOM服务快照工具用于收集Oracle服务人员使用的数据来诊断系统问题，除非Oracle Service要求收集，否则平时我们不用使用该工具。

cell03存储主机的文件系统异常，导致ASM Hang,数据库实例crash, 虽然是NORMAL级别的冗余，但是数据库实例此时不能于ASM通信，重启CRS进程恢复，可使用剩余的2条CELL继续为数据库提供服务。 在延长了disk_repair_time时间后，等待时间后强置重启CELL03主机操作系统后，一切恢复。

12C R2 3Nodes RAC on Linux using multipath 环境的crash总是不定时的crash(几天一次), 使用的是LINUX的多路径软件的默认配置。从日志看是CKPT进程hang超过了70秒所以LMON进程终止了实例， 从CKPT的trace文件中Call Stack看I/O的可能性较大。

点1的活动会话已接近4000，几乎全是Library cache lock的会话，blocker session 在等待DFS lock handle ，当shared pool里的对象需要为新的对象释放空间时如sql cursor, LCK进程降低Row Cache 大小期间使数据库临时hang， 因为在RAC环境中LCK进程负责释放持有row cache的用户进程协调工作及Library cache 的请求， 如果LCK出现性能问题也就会导致library cache object无法请求和会话补KILL后的释放row cache堵塞。

数据库当前的请求SCN大于当前最大允许SCN时会提示ORA-600[2252], 最大允许SCN是有本地系统时间决定。一个可能性是本地库主机时间向前调了，还有个可能性是通过DBLINK 分布式事务同步SCN时，远程库 SCN大于本地允许的最大scn.

We limit the default display of database character sets that can be used for a new database in Oracle Database 11 via DBCA (Database Creation Assistant) based on the recommended list.

alert log中出现了大量的”WARNING: too many parse errors”，是以前的版本中从未见过，这也是12.2的新特性，自动生成解析失败的信息写入db alert log, 即使没有在数据库启用event 10035，当JDBC 中scroll sensitive resultset 启用时，JDBC驱动就会在用户SQL中自动增加ROWID

The V$backup_corruption view shows corrupted blocks discovered during an RMAN backup. But once the corruption on this blocks has been fixed this view is not updated.

alert log frequently show the below worning ———– […]

library cache: mutex X等待事件是当一个会话以 exclusive mode持有library cache mutex时，另一个会话当前无论何时申请此mutex时必须等待其释放。很多时候对 library cache做不同的操作时都需要申请一个mutex, 所以最重要的是确认mutex的位置”location”, 该位置有助于分析该类等待事件的原因

前几日在一客户搭建ASM环境，存储工程师为每个LUN划分了1TB大小，但是当创建ASM DISKGROUP时显示为每个ASM DISK约为4PB 大小， 当然不是存储工程师开的玩笑，也不是上帝的馈赠，实际是ASM在AIX 平台上的当ASM DISK LUN 在1T及以上的BUG.

oracle官方网站在2017/8/18已提供了Ogg最新版本12.3下载，在Oracle 数据库12.2版本中提供了大量的新特性，OGG12.3配合ORACLE 数据库12c R2版本的新特性，提供更高的性能和吞吐量，最新发布的OGG12.3也是支持Oracle 12c R2第一个版本，引入了新的微服务架构和众多特性

朋友一套12C R2多组户架构3节点RAC数据库反应数据库响应缓慢，因远程不方便，只拿到事后一份AWR，数据库出现较高的cursor: mutex X 和cursor: mutex S，sql verison能达到7000多，并且high version的SQL都是递归内部SQL, 12.2的隐藏参数_CURSOR_OBSOLETE_THRESHOLD原来现在默认已加大到了8192，

第一个是从2017年开始改变了季度更新的方式，改变了过去的PSU为RUR (Release Update Revision) ，和改变 ProactiveBP 为 RU (Release Update),第二个是oracle 12c的下一个版本不再延续12.2.0.2 和12.2.0.3的形式发布，从201708月更新MOS note#742060.1确认了计划分别与2018年年第1季度和2019年第1季度发现未来的两个版本oracle 18.1 和oracle 19.1

ORACLE12C的下一个版本是18.1（12.2.0.2），这里我要分享的这个新特性是12.2 已经悄悄引入但undocument的，这个特性因为没有某些原因在12.2中都没有公开，但是SQL语法已经可用，暂时称做Sequence SCALE EXTEND 。注意公开前不建议在用户应用中使用。