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

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。

注意升级Oracle 19c:SE2标准版不再支持RAC

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

Troubleshooting ORA-01017 when ABMR(auto block media recover) on physical standby

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

Alert: SEC_CASE_SENSITIVE_LOGON and ORA-1017 after upgrade to 12.2 、18c、19c

从oracle 12c R2开始SEC_CASE_SENSITIVE_LOGON=FALSE的配置会认为deprecated ,12.2默认参数值为TRUE. 如果升级后该参数还是从以前版本带到新版本中,那就使情况变的复杂,有可能会遇到ora-1017密码错误的提示, 在配置静态监听时就更有意思。

Alert: Patch 28553832(11g R2 Extended Support patch) need apply upgrade to 19c

Direct Upgrade to Oracle Database 19c的版本有11.2.0.4,12.1.0.2,12.2.0.1,18c. 在最近11G (11204)升级19C的方案测试时遇到了上面的错误, 是不是很惊喜?在GI升级19c时需要检查patch 28553832是否安装,而且不允许跳过。这个从Patches to apply before upgrading Oracle GI and DB to 19c or downgrading to previous release (Doc ID 2539751.1) 可以确认。

Troubleshooting performance event ‘enq: CF – contention’

CF enqueues are control file enqueues, which occur during parallel access to the control file,it is a system enqueues generally only held for a very short time. the CF locks are used to serialize controlfile transactions and read and writes on shared portions of the controlfile.Control file enqueue is an expensive operation. For operations like updating checkpoint SCNs for datafiles, for no-logging operations, such enqueue on controlfile is taken.

Alert: oracle 12\18\19\20c 不要滥用“_ORACLE_SCRIPT”=true

“_ORACLE_SCRIPT”参数首先是个隐藏参数,所以很少有文档中描述他打开了哪些开关,因为它是oracle内部维护时使用,在ORACLE_HOME下的脚本中不少都有alter session set “_oracle_script”=ture的SQL, 但是注意执行完后即使的再改回false. 千万不要为了突破oracle的默认限制而随意使用_oracle_script参数,生产库除了oracle要求更不建议修改,因为后期有可能会遇到不些不必要的麻烦。