ANBOB™

enq:CR – block range reuse ckpt 出现该问题时分析等待链通常是前台进程等待CKPT进程在完成checkpoint, 通常是在DBWR进程在争用CPU或I/O 性能时，通常该event会非常短暂，如果该event已经在AWR dbtime中占据了较大占比时，需要引起关注。通常还伴随enq: RO – fast object reuse event, 当时如果做select 在内的DML SQL可能还出现library cache lock，等待ckpt进程。

最近有个datapump跨数据库迁移数据时，提示”ORA-39002: invalid operation”错误， 排除过目录文件权限和语法兼容问题，后来发现是目标库的Timezone Version低于源库的TZ version. 需要升级目标库的TZ VERSION

最近有个客户的表空间使用率使用50%左右就出现了ora-1653，我们知道ora-165N是空间无法扩展，这么多的free空间还无法扩展，其中有可能是存在碎片，也就是数据文件中不连续的”洞”free space， 在申请一个比较大的extents时，无法匹配连续空间而失败， 你是否想过查看数据文件上的段分布？或表空间的碎片情况？或move 哪个对象可以让datafile resize更小？

因为使用dblink需要分配undo段来标示分布式事务，如果在循环中使用dblink并commit，每次会分配新的undo段，同时undo retention如果保留时间较常，那可能会导致undo自动扩展很大(autoextent on )， 或者会出现undo段争用，从未过期的undo段偷窃， 就会影响正常的DML事务

就是因为HW的备份软件在备份前需要修改正常库的asm_diskstring 增加它的/dev/cdm*， 挂载它的存储设备到ASMDG， 因为他的软件bug导致期中一块盘处于中间态，磁盘名有，但iscsi未注册，挂载失败立即执行把它自己的ASMDG卸载，alter diskgroup xx dismount，但是这个动作又触发了ORACLE的ASM 自动disconnect 其它未使用diskgroup的预期行为

今天在测试一个小功能时发现个人用户密码已过期，当然这时只能去更改密码，改密码时递归更新密码最后更改时间来改变用户状态，此时profile延长过期天数PASSWORD_LIFE_TIME已无法解决， 但是大多数需求是希望是通过改密码的动作清除过期标记又不变原密码，当然这时又受到了user profile中PASSWORD_REUSE_TIME的限制， 你可能已想到了可以使用alter user identifed by VALUES ‘’; 但是这里也有个小细节。

Server processes 扫描 LRU 列表以获取free buffers （例如，在从磁盘读取块时，或为 CR 克隆缓冲区等时）。在将其扫描到阈值级别后，如果Server processes找不到free buffers，它会请求 DBWR 将 LRU 列表中的脏缓冲区写入磁盘，或a pinned buffer is freed。当 DBWR 写入脏缓冲区/释放固定缓冲区时，会话等待 ‘free buffer waits’。

前段时间一客户的Oracle数据库使用datapump做了迁移，发现相同数据LOB段迁移前后占用空间有原来的45G增长到了103GB, 朋友在墨天轮社区记录了这个问题click here, 主要原因是因为使用了不同的Lob Chunk Size，导致的空间浪费。这里简单的记录一下这个问题。

某年某月某一天，有个客户的oracle归档日志空间突然满了，实例挂起，客户的告警系统一如既往的保持沉默， 我们自己部署的“保镖”脚本被友军打上了#号，友军的“打手”脚本说sys用户密码已过期， wait!wait! are you kidding me? SYS user 密码过期？ 逻辑是这样的这套脚本是在DATAGUARD的standby 使用sys@tns方式远程查询已applyed 日志删除，在调用日志里提示“ORA-28002: the password will expire within 7 days“。

Troubleshooting 19c ORA-1: unique constraint (sys.i_indpart_bopart$) during ALTER TABLE SPLIT PARTITION
上一篇blog中提到LOCAL 分区，分区索引part#和分区表part#是相等的，上一篇在还原那个问题时，让part#占用时发现还不是那么简单，如果用10046跟split partition,时而insert,时而存在update, 其实oracle在这方面也是做了优化， 在split分区位置和个数也有性能上的细微的差别。

开始了19c的躺雷模式， 再次建议选择ORACLE 19C版本时安装19.11 以上RU。 最近一客户升级了19C, 本月拆分区时遇到了ora-1 内部字典表数据唯一性冲突， 下面简单记录，报错信息如下:

ALTER TABLE ANBOB.TLOG SPLIT PARTITION PART_110_MAX AT (110, TO_DATE(‘ 2022-02-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’)) INTO (PARTITION PART_110_202201 ,PARTITION PART_310_MAX )
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00001: unique constraint (SYS.I_INDPART_BOPART$) violated

Oracle 19c(19.9) RAC on linux, 应用执行一个update sql时报错ora-600, 错误日志如下
ORA-00600: internal error code, arguments: [kkshhcdel:wrong-bucket], [0x58445A790], [0x000000000], [0x67DFB5820], [], [], [], [], [], [], [], []

环境oracle 19c(19.7) on linux, 数据库做了failover后在open resetlogs数据库时，等待了很久的时间，数据库里查询wait event是’row cache lock’ & ‘cursor: pin S wait on X’， DB alert log显示下面的信息:可以看到不断的在输出TTnn Sleep 10 seconds and then try to clear SRLs in N time(s)， TTnn进程为异步模式下的REDO传输进程， 在清理standby redo log时hang, 还出现了row cache enqueue生成了SSD（system state dump）trace

如果正在使用oracle 19c rac 安装了19.10,19.11 RU后，关注一下使用了global temporary table(GTT)的运行时间，根据MOS Global temporary table (GTT) usage increased elapsed time after Jan RU 2021 (Doc ID 2798017.1) 记录响应时间会比之前慢9-10倍以上，属于 BUG 33127032，等待事件主要是“end: KI – contention”一个跨实例调用的序列化操作并不常见，通常P2值为59表示全局对象失效。

Oracle 11g 提供了一种特性SCAN LISTENER, 简化客户配置应用连接串，客户请求发给scan listener后实际还是会重定向给VIP listener与客户端建立联系， 标准配置是建议把scan name的域名配置到DNS中，如果不使用DNS只能识别一个scan ip, 配置在/etc/hosts中。 如果使用DNS服务器，对DNS的响应有较高要求，同时也增加了一个故障点

Oracle ANYDATA数据类型几年前在做expdp迁移时接触过，类型XML,LOB导出速度是慢之非常， 今天又一个客户在expdp时一个interval partition表时，部分分区导出报错ORA-21700: object does not exist or is marked for delete错误，依赖的对象不存在，查看表定义存在anydata列，也就是可能anydata这种任何数据类型都可以存储(但还是建议用lob类型代替)，但是存储的自定义类型又不存在了，这种情况很危险

在oracle database 21c版本开始materialized views可以自动的创建和维护，用于自冶数据库。 物化视图提供了显着提高查询性能的潜力，但需要大量的努力和技能来确定要使用的物化视图。结合了工作负载监控来确定需要哪些物化视图。基于决定，物化视图和物化视图日志被自动创建和维护，无需任何手动交互。对于复杂查询SQL的查询块(QB)，MVIEW查询重写技术可以优化此类查询

在Oracle Online文档的monitor database 章节中有描述Oracle 数据库可以自动跟踪某些SCHEMA的对象（例如表和物化视图）的活动和使用情况。
对象活动跟踪系统 (OATS) 跟踪与数据库对象相关的各种活动。可以在数据库级别和可插入数据库 (PDB) 级别执行跟踪。跟踪的活动包括对表的 DML 操作、表和分区扫描、分区维护操作 (PMOP)、物化视图重写和刷新以及索引等辅助结构的使用。

从Oracle 19.10 及更高版本中提供的sequence新增强功能“Sequence dynamic cache resizing ”， 在Oracle中如果应用中频繁的调用sequence的nextval值是可能存在性能问题，如enq:SQ 或row cache lock, 之前在一个客户的业务系统有一个非常糟糕的设计全库使用一个sequence, 所以及时cache值调到了2万依旧在高并发调用时sequence性能问题还是非常明显。

上周发布了新 Bug 33121934 Library cache lock / load lock / mutex x during connection storm， 也是在登录高并发时，因为更新最后登录时间特性出现的library cache lock等问题，之前是引入_disable_last_successful_login_time禁用，这次引入了2个新的隐藏参数可以细化行为的更新， 不用再那么频繁。