ANBOB™

在ORACLE 12.2版本中使用LSNRCTL STATUS或lsnrctl service查看监听信息时，如果启用了EM Express，从12.1版本增加了EM express的端口和访问信息;从12.2的版本起如果多租户环境，每个PDB增加了一个对应的GUID+DB_DOMAIN的服务名，无论PDB是open还是close都存在。该服务是数据库的internal service，使用该服务也可以访问PDB,但是不建议使用。

数据库第二个节点被驱逐出集群，并且多次自动重启以失败告终，驱逐原因在GI Alert log显示是私网通信丢失，而重启失败也是因为ASM无法启动，ASM db alert显示IPC Send timeout. 当时ping和tracert并没发现什么异常，从OSW中的netstat -s查看IP packet reassembles failed时间段值大量增长， 这是一套oracle 11.2.0.4 2Nodes RAC on RHEL 6.6的环境

如果当前数据库正在执行的一个长SQL出现性能问题，想取得运行时的变量时，在之前的版本中可以使用Errorstack level 3 event dump该会话的cursor信息，从trace文件中取得变量。 在11g r2版本的SQL Monitoring 相关的视图V$SQL_MONITOR.BIND_XML也可以方便的取变量值

dcli 为Oracle Exadata Machine中提供的管理cell的工具，全名 Distributed Command Line Interface，在Exadata， Exalogic， Exalytics等系列一体机都自带这个工具, 该工具是一套python脚本，可以用文本工具直接查看编辑， 在当前的IT管理中批量管理几百台机器已不是什么稀奇的事， 所以在日常一些批量共性的常规检查和运维就需要一种维护工具自动实现或者叫自动化运维工具， 当前较流行的有puppet和ansible 产品

在oracle12.1版本中，同一CDB中的所有PDB使用的都是相同的字符集从CDB继承而来，这样影响了PDB的迁移灵活性，从12.2起同一CDB中每个PDB可以使用不同的字符集， 如CDB是AL32UTF8，其中的PDB1为WE8ISO8859P1 , PDB2为ZHS16GBK， 从其它CDB plug-in一个JA16EUC字符集的PDB也是允许的，在plug-in PDB的过程中PDB会原封不动的进入目标CDB，过程中并不会转换字符集，并且以后新insert的数据是直接使用的原PDB的字符集。

闪回数据库在10G版本时引入，用于闪回数据库到指定时间点，在12C 多租户结构中增加了PDB概念，在恢复时通常为了节约时间和一致性做最小粒度的恢复，在12.1版本如果对CDB中的某个PDB做闪回时需要创建辅助实例和CDB，有些像表空间的基于时间点的恢复 ,在12C r2版本新特性引入了PDB级别的flashback，不再需要辅助实例。

有时因为表空间转移或整理碎片的目的需要MOVE TABLE， 但是该操作在12.2之前如果有业务在运行中常常因为排它锁的原因而失败无法有时间点切入。或move 成功后会导致索引无效而又影响了业务，move table online在12C R2版本引入解决了这个问题..

数据库中的dblink创建时如果使用了tnsnames.ora中的别名，那么在日后梳理数据库中所有的DBLINK 与哪些主机的数据库有连接时？通过DBA_DB_DBLINKS视图可能无法直接取到数据库源端地址， 通常需要登录数据库主机使用tnsping 别名的方式来解析IP， 但是如果当时创建dblink时在session级使用了非默认的tnsnames.ora如指定了TNS_ADMIN，查找对应的tnsnames.ora和解析工作变的更佳复杂。所幸在oracle 12.2版本中提供了新的package DBMS_TNS, 可以不登录主机（终端）在数据库内部就可以解析。

日常工作中sqlplus是维护数据库使用最多的工具， 通常把一切配置到login.sql中在sqlplus调用时自动运行，以前都是通过SQLPATH或当前目录的方式， 12.2 因为安全特性的原因，如果没有配置ORACLE_PATH环境变量指定，当前目录中的login.sql默认不再自动执行。

当数据库升级到12c后，有些功能的改变可能影响到原应用的可用性，如数据库升级12c R2后原来的10G或更老的客户端或10g或更老的JDBC 驱动连接数据库里失败提示下面的错误信息：
ORA-28040: No matching authentication protocol error

12.2的online pdb relocate 实现了PDB 在线几乎零停机时间在不同CDB之间的迁移，且在relocate过程中源库一直是open read-write状态，使用了增量日志的方式追加减少了最源库和网络资源的影响。降低了PDB操作和移动如上云、下云i的代价。

PDB refresh功能有些像PDB HOT Clone , 同时又像PDB级的Data Guard(实际不是),PDB refresh可以手动同步刷新或自定义同步间隔自动同步. 应用场景是开发和测试环境的搭建, 因为是增量的同步也减少了对源数据库的影响, 或作为一种online的备份库. PDB refresh是数据库自带的功能, 不用借助其它第三方工具…

物化视图是一种高级优化技术当用于数据分析报表类数据库, 把多表join的视图数据物化为真实的表数据存储. 我个人认为如果在OLTP中如果非用上了物化视图一定是应用的设计架构存在缺陷. 但是物化视图快速刷新可有时会出现性能问题, 根本原因是ORACLE的刷新引擎自作聪明的隐式加入的Hint.

在12.1版本中Clone一份PDB源库需要打开在read only只读模式, 在12.2版本中引入了local undo mode, 源PDB在read/write 读写模式也可以Clone. 这样可以在复制一份测试环境时对源库影响降到最低, 同时local undo mode也是ORACLE推荐的.

oracle 12C的index treedump比11G有了一点小变化, 这里简短的记录一下.
branch: 0x300252b 50341163 (0: nrow: 3, level: 1)
leaf: 0x300252c 50341164 (-1: row:485.0 avs:823)

前几日一数据库实例alert日志中出现了ORA-600 [kpncxcc-1], kpn开头的函数通常用于服务器之间通信, 从trace中也可以发现是一条调用了dblink的select, 在MOS未发现已知BUG.
ERROR:
ORA-00600: internal error code, arguments: [kpncxcc-1], [12], [5], [7], [], [], [], [], [], [], [], []

ORA-00600: internal error code, arguments: [krccaub_2], [9], [10], [], [], [], [], []
Sat Feb 25 05:14:31 2017
CTWR: terminating instance due to error 487

在12c以前的版本中服务注册一直都是PMON进程负责,从12c起引入了LREG (listener registration)后台进程接管了这部分工作减轻PMON的工作,同样如果LREG 进程死了实例也会crash.

在12C以前oracle不会主动维护全局临时表(global temporary tables)的统计信息, 并且如果手动收集也只是存在一份统计信息,即使不同的会话级临时表的数据量不一致,一旦存在对所有的会话可见,从12.1起可以使用GLOBAL_TEMP_TABLE_STATS 控制GTT表的统计信息是所有会话共享还是session级私有…

这是一套11.2.04 2节点4实例2数据库的CLUSTER, 每个节点上有2个实例, 每过一段时间其中1个节点上1个实例就会挂起hang死和实例驱逐重启, 主机环境是基于X86 64的Solaris OS (sunos 5.10)操作系统, 496 CPUs, 1TB的内存, 使用RAW裸设备存储…