Troubleshooting ORA-600 [kkdlfjou_1] after index rebuild online session killed

希望是龙年春节前的最后一个故障, 一客户Oracle 19c RAC环境中,做index rebuild online操作进行过程中,kill重建索引的会话,后面查询索引相关的表提示如下报错:ORA-00600: internal error code, arguments: [kkdlfjou_1], [], [], [], [], [], [], [], [], [], [], []

,

Oracle ASM rebalance 完成还有多久?

oracle ASM 从12c后引入了诸多特性,如FLEX ASM、Increased ASM storage limits、ASM instance V$ACTIVE_SESSION_HISOTRY 、ASM Disk Scrubbing外,最近发现还有一个关于ASM DISK rebalance 的增强EXPLAIN WORK FOR命令。12c 中新的 EXPLAIN WORK FOR 语句测量给定 ASM rebalance所需的工作量,并将结果输入 V$ASM_ESTIMATE 动态视图中.

,

Troubleshooting Oracle 19c wait event latch free 39 “object stats modification”

近日有一套客户为oracle 19c(19.18)的环境,从ASH中可以发现一些查询堵塞等待较高的”latch free”, p2值latch#=39, latch name为 “object stats modification”,latch free从11g后较为不常见,多数都是具体的latch name, 可见这是一个比较稀缺的latch,记录一下这个问题。

,

Troubleshooting Oracle ASM ORA-15041 & ORA-15074 after disk offline DROPPED.

oracle 11g R2环境1组normal冗余的ASM DISKGROUP包含3个cell的,每个cell为1个failgroup, 每个failgroup有48块ASM disks.因为一些硬件原因1个cell掉了19块disk,但offline后并未reblance完成,超过了“_asm_disk_repair_time”时间内没有online,被磁盘组自动drop force, 手动reblance时因为有1块asm disk使用不均衡free接近0MB,所以rebance会提示ora-15041错误。 此时add force与undrop均报错ora-15047. 处理rebalance需要空间,但加空间需要等上一个reblance完成的死结循环中。

, ,

Oracle 12c feature: SQL Translation Framework(文本替换) & event 10601

SQL Translation框架是 12c 中的一项新功能,使开发人员能够在不更改底层代码的情况下替换SQL代码。这个特性是sql profile baseline的增强,原来是可以不动SQL文本替换执行计划,现在是连sql文本都可以“隐式”替换。这功能可用于在异构数据库向oracle迁移时,替换SQL代码。

,

Troubleshooting Oracle 19c cascade Dataguard Gap ORA-03135: connection lost contact

最近客户一套oracle 19.14 standalone Database做的cascade dataguard环境,暂且认为是A->B->C三台单实例, 但总是A->B的延迟,从oracle 12c后引入real time cascade,所以如果依赖该特性对延迟要求较高, 分析A->B延迟发现,B库总时会出现GAP,并且未自动FAL,需要人为干预, 并且主库alert日志报错出现:
ORA-03135: connection lost contact
TT02 (PID:64459): Error 3135 for LNO:3 to“xxx”。

, ,

ORA-00600: internal error code, arguments: [kzsrsyncdbwithpwdfile-1:user row cache]

Oracle 19c启动失败报错ora-600 [kzsrsyncdbwithpwdfile-1:user row cache], 信息如下
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kzsrSyncDBWithPwdFile-0:user row
cache], [], [], [], [], [], [], [], [], [], [], []

Troubleshooting Oracle 12c/19c expdp slow due to query for V$OPEN_CURSOR

最近一客户的Oracle 19c环境在使用expdp导出分区变慢任务积压很严重,对于这个客户每月几万分区的EXPDP备份无法忍受,几M小空分区都要6分钟以上,导出速度和导出需求一样不科学☺。对datapump进程可以做sql trace跟踪,同时从导出时间段的AWR的TOP SQL看,这库似乎也没啥正常业务负载, TOP 1 SQL是DATA pump worker在查询v$open_cursor

,

Oracle ASM rebanlance fail with ORA-59048 when drop failgroup disk

Oracle数据库在12.1.0.2 以上版本asm中,如果normal冗余的磁盘组Failgroup少于3个或者High冗余的Failgroup少于5个是不允许删除Failgroup的 。或配置Normal或Flex冗余 ASM 磁盘组,具有 3 个常规故障组和至少 1 个仲裁故障组, 当Drop 1 个常规故障组时, rebalance 结束时,在 v$asm_operation 中可以看到 ORA-59048。

,

Troubleshooting oracle 19c wait ‘Library Cache Load Lock’ ,blocker REC0 wait ‘gc cr block lost’

最近遇到这个案例大量FG prorcess堵塞,19c (19.4) 2nodes RAC, 等待Library Cache Load Lock, 堵塞会话为REC0, 该进程等待gc cr block lost. 同时在rec0进程trace文件中提示
IPCLW:[0.0]{-}[WAIT]:PROTO: [1661188358080974]ipclw_data_chunk_process:1165 Discarding msg with seq # 875492546, expecting 2730385062
IPCLW:[0.0]{-}[WAIT]:PROTO: [1661188358080974]ipclw_data_chunk_process:1165 Discarding msg with seq # 875492587, expecting 2730385062

, ,

Alert behavior changed from 11.2.0.4 “create or replace view” fail with ORA-01720

今天有个同事咨询,发现在11.2.0.4以后的版本create or replace view 修改view 视图时,即使view owner当前用户是dba role也无法create or replace方式重建view,如当前用户u1把select on u1.t1 给u2(without grant option), 用户u2创建 view 给了u3 select 查询. 按说u3对u1.t1是当前没有级联授权,所以u2在编辑view时会报错ORA-01720,而在11.2.0.3之前是正常编辑,但行为是不正确的, 从11.2.0.4以后已做修正。

Troubleshooting Oracle 19c RAC ORA-29770 with LMD hang, LMHB terminating the instance

前段时间一个oracle 19c RAC 1个节点异常重启,日志显示是lmd进程hang 丢失heartbaet 超过70s, Lmhb进程重启了实例, 操作系统资源空闲,从lmhb trace中确实lmd在做free memory的操作。

,

Troubleshooting Oracle RAC node OS shutdown (‘crsctl stop crs -f’) cause db instance stop on another node

ORACLE 2-NODES RAC只关闭了node1上的db instace,当然此时业务不受影响,node2上的实例正常依旧可以对外提供服务, 1小时后OS组准备就绪,在节点1关闭操作系统,同步收到了业务无法访问,查看node2 db实例已自动shutdown, 其它资源正常,手动立即起动db实例2恢复业务,刺激,为什么停实例1 CRS会触发停实例2 的db instance?

, ,

Troubleshooting Oracle 19c sessions hang wait “enq: SS – contention” and “DFS lock handle” event

背景是了解到当晚B库的节点1有大量的数据加载操作。实例2 FG 并行查询Sort segment allocations空间紧张,通知所有实例CIC 等待DFS LOCK HANDLE, 其它会话等它完成 等ENQ SS, 而实例1一直未答复sort segment清理完成。 因为 Sort Segments cleanup是后台进程SMON责任,实例1 DBW似乎在等SMON或DBW很忙未完成,TEMP表空间已大到1.5TB,

,

Oracle 12c后的安全增强查询sys.user$ ORA-01031

Oracle 12c后的安全增强可能会导致运维中出现些差异, 如有时需要非sys用户查询sys的user$、link$等基表,这些表是因为存有password hash值,在之前一些安全部门查询是否有弱密码时喜欢采集user$,之前授权select any dictionary系统权限或dba role可以,但在是12c后增强不再允许,还有像Toad这种第三方工具如11.6的老版本在连接数据库时还以检测select any dictionary 判断user$权限也提示ORA-1031错误

Oracle 23c 几个开发相关新特性

Oracle 23c是19c后又一个长期支持版本(long term release),因为疫情的影响和Oracle版本策略调整,19c后一直未发现可本地部署的版本,23c 目前还是beta版仅ACE Direct和合作伙伴等部分人员下载测试,今天10月份William Hardie发部了申请beta的申请方式,

How To fix Oracle 19c PDB clone cross differente RU CDB, Then PDB in restricted

几年前12c刚release时测试过一系列pdb的功能,其中有小测试一下12.2的pdb hot clone,最近看到一个案例是19c 在不同的RU版本的CDB之间通过PDB clone迁移的数据库,从19.6 clone到19.11后PDB 变为restricted受限模式,查询PDB_PLUG_IN_VIOLATIONS看到如下错误:
‘19.11.0.0.0 Release_Update 2104130040’ is installed in the CDB but ‘19.6.0.0.0 Release_Update 1912171550’ is installed in the PDB

“alter table ” modify column in Oracle、MySQL、PostGreSQL(数据库比较系列十三)

‘alter table’ DDL操作后期运维时比较常规的操作,但在oracle,MySQL,PostGreSQL中行为并不相同,Oracle还是三者中代价最低的,但是在Oracle DBA转向其它数据库运维时,以O的经验维护像MySQL、PostGreSQL时修改列的小动作可能会出现故障,比如空间耗尽、持续时间长、锁、执行计划变等现象。这篇分别测试一下三个数据库在ALTER TABLE modify column上的影响。

Troubleshooting ORA-00600: internal error code, arguments: [kcbbxsv_nwp] and opatch fail one-off patch

几年前在某个客户查看Oracle数据库 RAC补丁时发现节点间存在不一致的现象,当时在这篇《Using ‘opatch lsinventory’ show patched is real? (看到的补丁信息真的靠谱么?) 》记录过, 最近又遇到了一片“沼泽地”环境,运维人的窘境是无法要求建设阶段如何规范化,什么样的环境都要接,即使到处是坑。这里再分享一例有个ora-600错误引起的一系列问题。

, ,

如何在Oracle 19c expdp/impdp 脚本中不使用密码?

MySQL中容易泄露数据库用户密码的地方,如shell、SQL的历史记录、主从复制等,当然也包括部署的一些数据库脚本,如逻辑导出,Oracle也不例外,好多用户在用户密码复杂度上很苛刻,但如在数据库中部署的如RMAN、EXPDP等脚本还是明文的密码那就比较不规范,

,