Troubleshooting ‘ORA-28041: Authentication protocol internal error’ change password 12c R2 DB

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

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

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

,

Oracle 如何指定作业(dbms_job, dbms_scheduler) 在指定的实例运行

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

,

注意升级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要求更不建议修改,因为后期有可能会遇到不些不必要的麻烦。

,

Alert: Oracle 19c DDL “COMMENT on Table” sql cursor no invalidation(deferred invalidation增强)

有时我们是希望做了一些改变后希望SQL再次解析生成更好的执行计划(maybe), 通常是comment DDL或grant select on xx to system等相对影响较小的操作。但是注意“COMMENT ON” DDL 在Oracle 19c中行为貌似又改变了(12c未改变,18c不确认),SQL CURSOR不再失效invalidation

, ,

Oracle 20C 关于Security安全的行为改变

Oracle 20-22c是12c后的下一个大版本集,也有了大的改变,如本身就云架构数据库定位从20c起不再支持非多租户,了解新版本可以了解数据库的发展方向,减少不必要的麻烦,如短时间内再次升级功能不再支持应用程序又要重写, 对于安全方面同样也有一些变化,这里简单的记录。

Troubleshooting Active Dataguard Hangs waiting for library cache lock on DBINSTANCE namespace

Oracle 11G r2 active dataguard端突然产生较大GAP,日志停止应用,大量前台查询进程等待”library cache load lock”, hanganalye 显示’rdbms ipc message’<='library cache lock' 等待链, library cache lock是一个parse lock,要知道在ADG 环境中也只有一个进程会在X-mode 持有lock,同时在ADG环境中存在一个相关bug, 这里记录一下这个问题。

Troubleshooting 11.2.0.4 show error ORA-12592, ORA-3137, ORA-3106

Network/TTC related error ORA-12592, ORA-3137, ORA-3106 may be signaled on SQL*Net TCP/IP transport.
Usually this problem is seen with following circumstances.
– Sending large size data to database server, for example, using sqlldr, expdp
– Database version is 11.2.0.4

, ,

Troubleshooting long wait “enq: US – contention” & “enq: IV – contention” after DDL, alert show “libcache interrupt action by LCK”

一套12C R2版本的4节点RAC数据库,记录一起高并发业务繁忙时,DDL导致数据库出现大量前台会话长时间等待”enq: US – contention” & “enq: IV – contention” ,该SQL(INSRT VALUE)的只是一个Children cursor无法执行(sql_start_exec 时间已过去数小时),第二个的children cursor执行效率正常,最终KILL 这些长时间运行前端会话解决。

, ,

Oracle 20C新特性一:Blockchain Tables(区块链表)

尽管新兴的分布式应用程序受益于去中心化信任模型中,但当今大多数应用程序都具有中央权限(银行,代管公司,交易交易所,政府办公室等),并且借助Oracle数据库中的区块链表,可以使这些应用程序更安全,而无需增加更改为托管服务器的复杂性去中心化模型。这就是使用Oracle Database 20c本机区块链表的原因

,

12c wait library cache lock self-deadlock when compile EDITIONABLE Procedure

前段时间遇到的一个案例,当编译一个invalid procedure时,自已会话堵塞自己等待’library cache lock’. 数据库版本Oracle 12.2, 当然这个procedure里面用到了dblink 嵌套procedure跨了3个数据库,在查看procedures定义时发现附加了”EDITIONABLE”

,

Oracle DUL支持Oracle 20c

之前测试过《DUL 支持Oracle 19c》,目前ORACLE 20C官方文档已发布, 按惯例2020年第一季度会发布ON cloud平台版本和工程系统,第二季度会发布可下载非工程系统版本,我先尝尝鲜搞个测试版本使用DUL测试是否继续支持20c,包括blockchain table.

,

oracle fast split partition

当拆分一个(partition)分区为两个分区时,其中一个分区为空,另一个非空分区保持了与原来分区相同的存储属性时,因为未产生数据移动,只通过内部切换data_object_id的内部调用,同时保证原来的Global 和 partition 索引一直处于USABLE(可用)状态,该特性叫做fast split partition. 这是9.2开始的老特性,IOT类型是从10.2 开始支持。

How to diag redo/archive log generation growth?(降低redo生成量)

redo中记录所有数据库的变化,包括所有数据文件上的变化,但不包含控制文件和参数文件的变化。redo最初记录在online redo logfile中,如果是归档模式会在填充满后生成离线的归档日志文件,有时会发现归档量突然某一天突增了需要查询原因, 更有甚者把降低redo生产量做为优化的目标。这里记录一些分析归档生成和分析变化的思路。

library cache lock或row cache lock, Failed Logon Delay 因为错误的密码尝试

数据库为了防止频繁的错误密码登录或暴力破解,如果user profile中配置了无限次失败而不lock用户,或当修改了应用用户的数据库密码,有遗漏的应用程序配置未及时更新,就会因密码错误而导致性能问题,Oracle 11g引入了密码延迟验证的新特性, 想法虽好但也成了问题特性。 错误的密码尝试在不同的版本中,对数据库带来的性能问题等待事件可能不同, Oracle 10g R2, 11g R1 等待事件的是row cache lock, 11g R2等待事件library cache lock, 12C是的等待事件Failed Logon Delay。

,