ANBOB™

2020/08/10 16:02:13 CLSRSC-325: Configure Oracle Grid Infrastructure for a Cluster … succeeded
昨天一客户安装19c在非第一个节点运行root.sh时，提示下面的错误，但是检查实例状态都已启动正常。
Error 4 opening dom ASM/Self in 0x9e3add0 <------------- Domain name to open is ASM/Self <------------- Error 4 opening dom ASM/Self in 0x9e3add0

在12c 版本以后”ges resource dynamic”逐渐增长最终导致shared_pool可能会超过手动管理的shared pool size达到sga_max_size后出现ora-4031. 与之相关的oracle bug就好几个，这最近因为这个问题导致lmd hang堵塞了其它实例的前台进程，关掉了这个节点临时恢复，简单记录。

没有维护过oracle 8\9那个版本时，可能不会太接触这个热备份模式， 这个技术已经被RMAN所替代很多年，但是就是这个东西，让我们在最近一次19c 数据库故障中走了弯路， 数据库的内部某个机制触发了begin backup， 因为异常crash后又归档缺失，还尝试从备份做了恢复，最终还是使用bbed修改数据文件头异常恢复

ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name “DW00” prematurely terminated
ORA-00600: internal error code, arguments: [KKZGPKORID], [0], [], [], [], [], [], [], [], [], [], []

ORA-00600 [PITL1]
ORA-00600 [kdt_bseg_srch_cbk PITL1]
ORA-00700: soft internal error, arguments: [kgegpa:parameter corruption]

Oracle数据库40年来还真是“急人所急 想人所想”，不断努力在一套软件中集成所有解决方案，以至于导致有人抱怨“她”太“胖”了。有没有想过oracle数据库中的读写分离场景？首先会想到使用Active DataGuard，但是如果不要DG,只在一套数据库RAC中不同节点实现呢？如一个节点写，其它节点只读呢。

This is due to sys.exp_obj$. EXP_CNT mismatch rows of sys.exp_stat$
Following SQL is used to check issue data of some objects. if there are some rows return, that means data issue.

主要是在11g引入的安全特性延迟密码认证在3-10秒，在延迟期间以X模式持有row cache lock防止同一用户的并发失败尝试。通常是配置28401 event禁用延迟认证特性,但这也不是“万能药”，像这次的案例。 除了密码延迟认证，PASSWORD_LIFE_TIME和FAILED_LOGIN_ATTEMPTS 也是用户的警惕的地方。

TTS(Transportable Tablespace)在大型数据库迁移方案看较常见,复制数据文件实现了在线，但是导出元数据阶段需要把表空间改为只读，写业务要中断，那就存在一个问题，导出metadata元数据需要多少时间？有没有不可预见的问题？19c DATAPUMP引入新特性TTS_CLOSURE_CHECK为此而生

In Oracle 12.2.0.1.0 (12cR2), “row cache mutex” replaced 12.1.0.2.0 (12cR1) and 11g “latch: row cache objects”, similar to “latch: library cache” substitution by “library cache: mutex X” in the previous release. High waits on “row cache mutex” when looking up user or role information in user row cache (dc_users)

无论出于安全、特性、性能、支持周期都需要考虑升级数据库，但是也会导致有些功能改变而影响软件使用或管理方式，升级后经验格外重要，因为oracle官方提供的功能无法模拟各行业生产环境中所有的应用场景， 尤其是从最近要面临的11g升级19c大版本升级，防止踩雷，像wm_concat 在新版本不支持一样。

ORA-00600: internal error code, arguments: [kcbbxsv_nwp], [], [], [], [], [], [], [], [], [], [], []
kge_experr : Found error ORA-600 not in expected list.
kge_experr: Dumping error frames [top = 1 : barrier top = 0]
kge_experr : [0] : Error = ORA-600 :
Call stack = ksedsts()+426<-kge_snap_callstack()+77<-kgeadse()+557<-kgerinv_internal()+44 <-kgerinv()+40<-kserin()+180<-kcbbxsv()+17478<-kcbb_coalesce_int()+326<-kcbb_coalesce()+438< -kcbbwthc()+817<-kcbbdrv()+8765<-ksb_act_run_int()+117<-ksb_act_run()+130<-ksbcti()+18

上周在使用TTS传输表空间从11.2.0.4到19C， 在最后impdp metadata的环节提示ora-942 结果提示有大量索引没有创建成功，但是查看报错的表实际是存在的， 后来发现这是一个收权问题导致的。后分析这种场景是发生在如一开始给了一个用户如create ANY table/index的系统权限或者dba 角色或是on object上的权限，后来创建了跨SCHEMA的index（indexes and tables differenct owners）或FK 约束时，再后来安全整改收回大权限，就导致了这个问题。

DRM is driven by the following
1.) _gc_affinity_time = Time in minutes at which statistics will be evaluated (default = 10 mins)
2.) _gc_affinity_limit = # of times a node accesses a file/object (default = 50)
3.) _gc_affinity_minimum = minimum # of times per minute a file/object is accessed before affinity kicks in
(default = 600 per minute per cpu )
4.) _lm_drm_disable = LEVEL disable drm in different level( default=0 )

在使用TTS迁移一个8T 的11.2.04到19c PDB时，发现expdp和imdp元数据过程中statistic占用了约1个多小时的时间， 但是我检查了实时步骤中确实有写exclude=statistics，猜测是参数没启作用，不能忍. 结果发现这是一个预期行为

数据库会话同样会占用数据库资源，如客户端异常断开在客户端成为一个dead session会永远存在，如果客户端没有断开也没有活动就是一个idle session， 如果这个idle session做了一些修改未提交，然后下班或去吃饭、上WC、开会等，这时就会堵塞其他人对相同的数据做修改，这类会话可以叫做idle blocker session. 在自治数据库中这些session 都可以被释放或者kill / teminal 终结掉，下面对不同的session如何被释放

From 12.2, DataPump import (impdp) will always use non-parallel index creation during import overriding parameter ‘parallel’ in command line or parameter file.

无法提供摘要。这是一篇受保护的文章。

方法一使用了bbed修改 index key的方法， 因为表列上只有这一个索引，所以只改一个索引就可以。这里还使用相同的方法模拟ora-8102,使用第二种方法，删除bootstrap$中的index I_OBJ4 记录解决。

Sometimes due to sudden power failure and other reasons, the database data dictionary is inconsistent, such as hits ora-8102, the indexes key and the table key value does not match, often delete the index, rebuild the index can be resolved, but if the object_id <60 bootstrap$ internal The index is damaged, and the normal situation needs to be backed up and restored, because some of the indexes in these bootstrap $ cannot be rebuilt by setting event 38003