ANBOB™

Starting from 12.2.0.1 Grid infrastructure home does have tomcat installed on the GI_HOME. A security scan may find Tomcat security vulnerability CVE-2024-21733 in your Oracle RAC environment. How do I fix it ？

当迁移Oracle数据库到其他数据库系统时，你可能会遇到一个棘手的问题：在Oracle表中存在无效的数字数据，导致在目标数据库（比如PostgreSQL系列）导入时报错。这些错误可能表现为类似“invalid input syntax for type numeric: ‘xxx’”的提示信息。最近，在将Oracle国产化改造项目迁移到商业发行的MogDB时，我也遇到了这个问题。看来Oracle的容错率太高了，不会像其他数据库那样严格检查数据的有效性。因此，我们需要一种方法来找出并修正这些错误数据。在本文中，我将分享一种解决这个问题的方法。

在Oracle数据库中，索引是提高查询性能的关键工具之一。通过使用索引，数据库可以快速地定位和检索数据，从而加快查询速度并降低系统资源消耗。在索引扫描过程中，有两种主要的方法：索引快速全扫描（Index Fast Full Scan）和索引全扫描（Index Full Scan）。然而，在某些情况下，数据库可能会出现错误的执行计划，选择索引全扫描而不是预期的索引快速全扫描，导致性能下降和资源浪费。该类问题可能不容易发现，仅是SQL性能差，或主要的等待事件为db file sequential read.

几年前测试oracle RAC的节点间UDP通信《The FG(server process) and remote node LMSn process communication over the interconnect?(用户进程会和另一节点的LMS进程直接通信么?)》测试过节点间存在Server进程与LMS的udp连接，使用的是HAIP(169.254.*.*), 而Linux操作系统的网络端口可用范围net.ipv4.ip_local_port_range 参数控制,适用于TCP和UDP，最大值是65535. 如果RAC中就一个private network 网卡，假设不排除所有进程都和某一个LMS进程通信如LMS1，LMS1分配1个IP addr+UDP port， 那FG进程的上限就是net.ipv4.ip_local_port_range /单个FG进程打开的UDP个数。

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

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 动态视图中.

近日，一位客户的Oracle 19c（19.18）环境中出现了一些查询堵塞等待较高的“latch free”情况。通过分析AWR报告中的ASH（Active Session History）数据，我们发现某些查询频繁等待“latch free”，并且p2值对应的latch号为39，latch名称为“object stats modification”。

“latch free”等待事件在Oracle 11g之后相对较少见到，通常我们会看到具体的latch名称。 “object stats modification” latches 又是一个较为罕见的等待事件。为了便于后续跟踪和分析，这里记录一下该问题及其相关细节。

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完成的死结循环中。

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

最近客户一套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”。

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], [], [], [], [], [], [], [], [], [], [], []

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

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。

最近遇到这个案例大量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

今天有个同事咨询，发现在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以后已做修正。

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

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

背景是了解到当晚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用户查询sys的user$、link$等基表，这些表是因为存有password hash值，在之前一些安全部门查询是否有弱密码时喜欢采集user$，之前授权select any dictionary系统权限或dba role可以，但在是12c后增强不再允许，还有像Toad这种第三方工具如11.6的老版本在连接数据库时还以检测select any dictionary 判断user$权限也提示ORA-1031错误

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