Oracle 12c Alert log show ” ADVISORY: Please collect redo for investigation of ORA-8103″ frequently

叕一个oracle 12c频繁生成日志文件的问题,最近一套12.2的RAC突然又文件系统告警,生成了大量的trace文件,db alert log也在不停的显示如下内容:
ADVISORY: Please collect redo for investigation of ORA-8103. Use command:
ALTER SYSTEM DUMP REDO scn min 1 scn max 16716635042430 dba min 32 2094058 dba max 32 2094058;

Oracle 哪些进程可以KILL不会导致实例重启?

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的进程。

Troubleshooting failed to generate AWR snapshots at WRH$_SERVICE_STAT(gv$service_stats many ‘–UNKNOWN–‘)

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

Troubleshooting Expdp fail with ORA-31638 ,ORA-39077, ORA-06502

这是一个经常执行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导致的另一个问题。

Wait Event: L1 validation

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多租户环境,如何直接登录到PDB, 不指定TNS? 18c、 19c、20c

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

Troubleshooting query v$asm_disk v$asm_diskgroup hang

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.

Troubleshooting DB instance start fail ‘kggpnpInit: failed to init gpnp’ after apply DB PSU 11g,12c,18c,19c

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

MySQL 8新特性: Random Password Generation生成随机密码

近几年数据库安全在生产管理过程中尤为重视,MySQL同样和Oracle database一样提供了一些高级安全特性如TDE, Audit, Data masking, Firewall和密码安全管理策略等.
Oracle database中有密码verify function,目前还没有生成随机密码的功能, 但MySQL 8中撮供了该功能,下面测试一下“随机密码生成”特性。

Alert: 升级19C(19.6) impdp导入分区表使用network_link时ORA-39029 ORA-31671 ORA-00600 [qesmaGetPamR-NullCtx]

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

Oracle Listener(监听) connect slow performance tuning

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.

Oracle12c R2注意事项: 又一个BUG 生成大量的trace 含 kjshash() kjqghd()

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