LOB 不当的RETENTION 会导致严重的空间浪费(二)
之前记录过一篇关于lob 《 LOB 不当的chunk size会导致严重的空间浪费》,最近一个案例关于enq:hw 的wait event在lob段,而SQL语句是一个update,发现也存另一种情况因为retention过大,导致的lob快速扩展,简单记录。
提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
之前记录过一篇关于lob 《 LOB 不当的chunk size会导致严重的空间浪费》,最近一个案例关于enq:hw 的wait event在lob段,而SQL语句是一个update,发现也存另一种情况因为retention过大,导致的lob快速扩展,简单记录。
之前已经记录过多篇关于用户密码的问题, 今天又看到一则19c 在XTTS升级时,用户创建拼密码SQL脚本失败的问题,对于拼接user$.password和user$.spare$列时值错误,导致密码不能登录问题,对于19c中2个字段值哪种情况下没有值,简单的测试记录。
最近上海某客户一套ORACLE RAC发生1节点驱逐, 问题前CPU利用率并不高, CRS日志有I/O响应和IPC超时错误, 部分进程hang死,操作系统是RHEL7.5, 在操作系统meesage提示如下信息:
“kernel: NMI watchdog: BUG: soft lockup – CPU#25 stuck for 22s!”
oracle11g add default values columns(增加默认值列的改进)11年前 学习oracle初期测试过oracle 11g相对oracle 10g的增强, 对于增加列default not null 时只增加数据字典定义,而不有update 表现有数据,给对于大表比如上亿记录的列增加带来不小的提升, 今天看到同事在使用ogg 从19c to 11g同步DDL 又看到了这个现象。
最近遇到了2个客户出现在11.2.0.4环境中频繁出现ora-8103的问题,基本上都是索引对象object mismatch, 重建后过段时间会再现, 该类问题使用rman validate logical 还无法发现,算是当前oracle软件的一个未知bug.
最近在测试oracle to postgreSQL项目中,计划使用oracle standby database做为数据库初始化的静态数据,这没有任何问题, 那是否可以从standby database捕捉变化呢?如配置ogg extract抽取进程。
近日分析一个数据库checkpoint long time 未完成的一个case时,本想分析dbwr trace file中看看是否有报错,发现dbwr的trace file并不存在,并且重启数据库后也并未生成,发现这并非个案,好多环境中dbwr trace不存在, 下面记录一种启用方式。
最近一套ORACLE 19C RAC 因一个节点主机故障重启后,其中1节点启动失败, 2节点正常启动,网络traceroute 、 ping 、多播测试均正常,幸存节点也有尝试重启、包括Kill gipc gpnp 进程,及重建过node 1的tmp 下的network soket临时文件, node1 依旧启动失败, 启动分析Init启动进程发现是gipcd启动后直接terminal中断
10多年前测试过10g的logmnr用于从redo或archivelog中分析DDL DML记录, 当做一些误操作无法flashback技术恢复或无备份时,可以尝试用来从redo log中恢复一些操作, 最近测试了一个19c多租户环境中的logmnr,记录如何恢复某个PDB中deleted 记录。