ANBOB™

Queries that do “full table scan” are the ones that don’t use indexes. However, it is more suitable to use a full table scan for small tables, and it will not cause performance problems. Or when the data on the large table is seriously skewed and a large proportion of data records need to be returned, a full table scan will also be better than an index scan.

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的预期行为

经典知识库：Oracle 19c避雷经验分享-2022云和恩墨大讲堂 时间： 2022年02月17日 20:0 […]

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

Trace File Analyzer(TFA) 是oracle用于分析和收集日志的程序，可以安装在独立或集群节点的数据库节点上。从Oracle12.2开始，这个工具包含在 RDBMS 软件中，当我们运行 root.sh 脚本时，这也是可选的，如果不需要，我们仍然可以跳过它,从19c开始Oracle将ORAchk，EXAchk，TFA等多个诊断工具合并入Autonomous Health Framework(AHF)，作为一个独立的安装软件，也被集成到了RAC安装介质中，AHF可以使用root或者非root用户安装，但是用root可以收集更全的日志

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

Oracle 数据库中的 varchar 和 varchar2 数据类型都用于存储字母数字值的动态长度。但它们之间存在一些差异。varchar 数据类型是适用于所有关系数据库产品（Oracle、MySQL、PostgreSQL 和等）的 ANSI 标准数据类型，存储长度不同数据库差异较大。而 varchar2 数据类型是 Oracle 标准数据类型。VARCHAR是Varchar2的同义词，当我们创建 varchar 数据类型时，Oracle 服务器会在内部自动将 varchar 数据类型转换为 varchar2 数据类型。而部分国产库是VARCHAR2是VARCHAR的同义词。

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

A core dump is an image copy of a processes state at the instant it ‘aborted’. It is produced in the form of a file called ‘core’ usually located in the current directory.

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

OSW工具不用多说oracle数据库环境建议采集OS系统数据的脚本集， 采集的数据可以拿到其它机器，如WINDOWS上分析输出图形， 在ORACLE 12c后 AHF自动健康框架中已自带， 同时还有oracheck等，当troubleshooting时使用tfactl 可以一并收集相对全面的日志数据,几年前记录过2篇OSW，不做过多介绍，这里简单记录一下在Windows上使用oswbba.jar分析时的一些小问题。

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数据库中的一些Automatic特性
DATE : 12/24/2021

墨天轮
https://www.modb.pro/dtc2021