ORACLE 9i-23ai

数据库oracle

Troubleshooting RMAN backup hang waiting for Autobackup, DB alert log ORA-00230

by

昨天遇到一个问题oracle 19c(19.10), 最近一段时间的RMAN备份任务都失败了，错误中有ORA-00230: operation disallowed: snapshot control file enqueue unavailable， 看着是cf的enqueue请求失败。 处理起来比较简单，找到blocker session就可以解决了， 之前的《Troubleshooting performance event ‘enq: CF – contention’》记录过一些分析方法，本次的案例当前还没有匹配的已知bug,这里简单的记录。

How to find full table scan SQL in Oracle,MySQL,Postgresql ?(数据库比较系列五)

by

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.

Troubleshooting performance event ‘enq:CR – block range reuse ckpt’ & ‘enq: RO – fast object reuse’ due to truncate

by

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进程。

Scripts: 查找Oracle数据文件碎片和extents分布

by

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

Troubleshooting DB hang, v$asm_diskgroup query hang due to ASM I/O hang案例

by

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

Event# 恩墨大讲堂2022 《Oracle 19c避雷经验分享》

by

经典知识库：Oracle 19c避雷经验分享-2022云和恩墨大讲堂 时间： 2022年02月17日 20:00 – 2022年02月17日 21:00 线上直播 回放地址: https://www.modb.pro/event/550 PPT下载  https://www.modb.pro/doc/56350 演讲：  张维照 演讲提纲： 1.19c的版本介绍 2.19c RU与one-off的选择 3.19c的维护注意事项 4.19c一些已知问题案例 适合人群： Oracle数据库技术支持工程师、优化工程师、有oracle升级计划和Oracle运维DBA，以及所有的Oracle技术爱好者

ORA-28007: the password cannot be reused 如何破

by

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

工具： Autonomous Health Framework – TFA

by

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

Troubleshooting wait event ‘free buffer waits’

by

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

Oracle、MySQL、PostGreSQL、SQL Server数据库比较系列（三）: VARCHAR与VARCHAR2

by

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

LOB 不当的chunk size会导致严重的空间浪费

by

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

Alert: Oracle 12c/18c/19c “SYS” 用户密码也会自动过期

by

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

工具：oswbba java 分析

by

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

Oracle partition part# 如何增长

by

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分区位置和个数也有性能上的细微的差别。

Troubleshooting 19c ORA-1: unique constraint (sys.i_indpart_bopart$) during ALTER TABLE SPLIT PARTITION

by

开始了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