Know more about ORACLE’S RECYCLEBIN

Recyclebin回收站是oracle数据库对于drop table的一种回退机制,可以使用flashback before drop特性闪回已drop还在recyclebin中的对象。纵观其他数据库像SQL Server也提供了类似功能, MySQL可以利用recycle_bin插件,但是作用在MySQL slave实例上,当在master实例上进行drop操作时,slave实例可以拦截drop操作,先进行数据备份再进行删除操作。 而在PostgreSQL中可以利用event trigger和pg_event_trigger_dropped_objects 来手动实现drop时 rename对象的方式变相实现recyclebin功能, 当然也可以使用一些插件如Pgtrashcan、postgresql-recycle-bin;在Opengauss中也增强了flashback的功能,但是需要注意更新方式是使用Ustore还是Astore, recyclebin不支持Ustore,只支持Astore,而且同样支持Truncate。

How to Recover Oracle Standby Database Using an Incremental Backup?

Oracle Standby database容灾库有时因为一些原因缺少了Primary database的archivelog未应用而中断同步,如备库归档目录使用率100%,或主库未传输删除了归档等。重新搭建DATAGUARD对于较大的数据库可能是费时费力,通常可以采用增量备份的方式,最近刚好是在处理一个ogg不同步的问题时。

,

Troubleshooting performance event ‘enq:CR – block range reuse ckpt’

enq:CR – block range reuse ckpt 出现该问题时分析等待链通常是前台进程等待CKPT进程在完成checkpoint, 通常是在DBWR进程在争用CPU或I/O 性能时,通常该event会非常短暂,如果该event已经在AWR dbtime中占据了较大占比时,需要引起关注。

Troubleshooting ORA-39002: invalid operation during datapump TZ version Difference

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

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

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

Troubleshooting large amount of undo/redo generated due to dblink usage

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

,

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

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

, ,

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

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

,

Troubleshooting wait event ‘free buffer waits’

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

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

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

,

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

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

, ,

Oracle partition part# 如何增长

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

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

,

Troubleshooting 19c ora-600 internal error code [kkshhcdel:wrong-bucket]

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 hang ‘TTnn Sleep 10 seconds and then try to clear SRLs in N time(s)’ wait ‘row cache lock’ & ‘cursor: pin S wait on X’

环境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 wait event “enq: KI – contention” using Global temporary tables

如果正在使用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 RAC 环境中配置DNS性能问题或故障对使用SCAN Listener的影响

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

, ,

Troubleshooting Oracle ANYDATA 数据类型存储的自定义类型丢失后ORA-21700

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

,

Oracle 21c 新特性: Automatic Materialized Views

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

Oracle 21c 新特性:Object Activity Tracking System

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