ANBOB™

oracle后台进程当出现问题时，有些进程kill会导致实例立即重启，像smon, pmon,ckpt.. , 而有些进程kill并不会影响实例可用性， 甚至会立即做进程级重启从db alert log可以观测到，如mmon,rec,jnnn, pnnn等， 前两天看到Poder在其BLOG分享v$process的基表X$KSUPR中中有记录哪些是oracle的致命进程,在X$KSUPR.KSUPRFLG第3位, 下面我做个测试， kill 点X$KSUPR.KSUPRFLG第3位都不为1的进程。

此数据库存在大量的expdp JOB， 查看库的AWR时发现已经很久没有生成snapshot, 分析后发现在收集gv$service_stats(X$KEWSSVCV) 超时， X$KEWSSVCV 有百万行”–UNKNOWN–” service name的统计信息，虽然这个问题是因为datapump 的”BUG”（(non-existent on MOS) ）导致,但这算是一个数据库长期不重启带来的“不好的影响”。

这是一个经常执行expdp做表级备份的数据库，版本Oracle 11.2.0.4 2nodes RAC，在12.2之前存在一个bug就是expdp调用的内部sequence在达到6位数后而导致的失败ORA-31638 \ ORA-39077\ORA-06502 ，bug修复后是增加了当此sequence达到6位数后drop并自动re-create。 下面记录一下这个问题。下一篇我会分享这个库同样expdp导致的另一个问题。

The ‘L1 validation’ looks like a segment space management issue. Although it’s not documented (yet) v$event_name suggests that the p1 and p2 parameter are the “segheader” and “l1bmb”. L1 BMB – stands for L1 bitmap block.

Oracle 20C non-CDB将不再支持，多租户架构（multitenant architecture ）已深入Oracle内核， 没有理由再拒绝CDB，有时计划核心业务库上在CDB中只有一个PDB, DBA在主机本地登录数据库，感觉每次都要sqlplus 直接登录cdb$root后，还要再alter session set container=xx切换到PDB，或者使用pdb的service_name,很麻烦，那有没有办法可以像非多租一样直接登录到PDB呢？ 有！

在一些生产容灾环境中有一种定期clone一份数据库的需求，如BCV存储快照技术 ，当然最近几年CDP, CDM技术的出现也是基于存储快照实现数据库历史时间的恢复。Oracle 在18c中同样提供了一种自动生成并清理历史数据库快照的技术PDB Snapshot Carousel…

An Oracle 11.2.0.4.7 4-nodes RAC on linux env, the fourth instance has this problem just, When the monitoring tool queries the usage of ASM DISKGroup, the query of V$asm_disk and v$asm_diskgroup has not been completed. from ASM INSTANCE found that waiting for ‘enq: DD – contention’ and final blocker session is waiting for ‘GPnP Get Item’ event. but query v$asm_diskgroup_stat work fine.

近期客户环境中有友商在测试XTTS时遇到了在把表空间修改为read only只读时遇到的ora-1640错误，说明与此表空间相关存在事务未结束，最终确认最在一个PREPARED状态的分布式事务…
ORA-01640: cannot make tablespace read-only with changes by in-doubt transactions

ORACLE RAC环境记的之前GI和DB的version 前4位相同是可以兼容的，甚至有时DB PSU比GI PSU新，最近有朋友遇到只安装了DB PSU后，RAC中实例启动失败的问题, db alert show:
USER(3037)]CRS-2316:Fatal error: cannot initialize GPnP, CLSGPNP_ERR (Generic GPnP error).
kggpnpInit: failed to init gpnp
WARNING: No cluster interconnect has been specified

Oracle 19.1 or 19.4 on AIX ,There are cases where this error has occurred, An instance terminated because a DBWR raised ORA-600[kjcsmpav:1] during a buffer allocation.
ORA-600: internal error code, arguments: [kjcsmpav:1], [0x7000xxxxxxx], [4], [0], [211], [220], [], [], [], [], [],

Restore RMAN backup from standby database to another server create a test database, and to Database Point in Time Recovery. but faced ora-1547 ora-1152 ora-1110 During recover.

RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
RMAN不能再正常删除归档日志，它们都将返回RMAN-08137，这导致归档日志文件系统被填满， 最终导致数据库实例hang， 等待online redolog归档。常见于有dataguard或基于redo的逻辑同步环境。

升级oracle 19c的计划基本都已提上日程，数据泵也是一种对于小型数据库常用的解决方案，但是还是有个bug在那悄悄等着，对于本地没有存放dumpfile存储空间时常常使用network_link“不落地式”的导入方式， 这里记录一个同步时遇到ORA-39014、ORA-39029、ORA-31671案例。

上周同事在安装Oracle 19c RAC环境时，全新的软件在安装了当前最新的19.6 RU后，DBCA创建数据库居然花了4个小时左右，环境RHEL 7.5 , 本地全SSD 硬盘，共享存储是”菊厂”的高端全闪阵列，这样的速度不能忍。

The next bottleneck the Listener could encounter is too many concurrent connection requests. The Listener process, it is constrained by CPU speed and available memory. there are techniques that can assist in scaling the Listener. The first is to adjust the request queue-size (QUEUESIZE) of the Listener process, the second is to increase the number of Listeners.

如果 Oracle client version 较低(<11.2.0.3)，且数据库升级到 Oracle 12.2 并且应用了 April 2018 PSU 、18C 、19C databases 后, 当用户密码过期后，使用低版本的oracle client尝试修改用户密码时会遇到下面的错误,: ORA-28041: Authentication protocol internal error.

Oracle 12c R2 又一bug，DIAG目录一天生成100GB的trace文件， 之前分享过几篇，这里再记录一种情况，遇到该现象时，需要先查看生成的trace文件进程是前台还是后台， trace的文件内容，当前数据库是否有配置诊断类event. 这个trace文件是有前台进程生成的，trace文件中包含kjshash和kjqghd。

在RAC环境有时需要指定JOB 只运行在某个节点，如DBMS_schduler job调用OS shell的情况等对本地节点有依赖时，这里只是简单的记录一下方法

从Oracle 19c版开始，在标准第二版（SE2）中将不再允许使用Oracle RAC，客户可以选择保留18C，而不会影响其当前的RAC配置。标准版从19C后限制更加苛刻。虽然当前的18 SE 目前支持到2021年，总之从趋势上看是在逐渐淘汰SE标准版，还在使用SE的需要提前考虑了。

oracle 11.2.0.4 RAC physical standby env, 在Standby端DG日志同步正常，但是当standby出现坏块后，standby 做ABMR时，提示ora-17627 ora-1017 用户密码错误的提示。从主库复制了密码文件，手动登录同时也是正常的。 因为standby上有业务不能轻易尝试，这里只简单记录分享一下排查方法。