ANBOB™

最近在做一批Oracle database datafile 从1个ASM diskgroup 迁移到另1个ASM diskgroup时，单个datafile一直无法完成或挂起或多出几倍的时间，正常时1个datafile 30g在150s, 而突然间变的600s都没有完成， 数据库版本oracle 11.2.0.4 。 问题时尝试查询v$asm_diskgroup[_stats]或asmcmd lsdg一样很慢或hang。 登录ASM实例查询会话在等待“buffer busy”和”GCS lock esc” 这里简单的记录一下。

最近一个客户的数据库归档空间满，导致数据库挂起，无法连接，sys登录时提示ORA-00257: Archiver Error, 确认数据库使用的是flash recovery area，从oracle 10g R2提供了V$FLASH_RECOVERY_AREA_USAGE 可以查看flash recovery area中每类文件使用的比例，但是加起来不足10%，且当前flash recover area size已经达2TB, 因为无法远程，临时更改数据库归档路径为具体ASM DISKGROUP不再使用FRA, 这里简单记录一下排查方法

近期一个客户oracle 11g 11.2.0.4 的环境， 业务出现拥堵， 活动会话的等待事件是latch free, 并且P2# 显示是一个不常见的mostly latch-free SCN ，简而言之就是过去oracle版本用这个latch 保护scn，现在已经不在需要的一个latch bug.

如果你不幸数据库在启动时提示ora-600 16703,那很可能是从网上下载安装的oracle数据库软件安装介质中被人篡改了， 增加了启动时判断启动时间，然后删除tab$数据字典的老套的破坏方法， 这个网上的修复方法很多，情况有时也不同，建议找专业人事修复且不要造成二次破坏，这种如果只是最初的版本，修复还是相对比较简单，顺利的话个半小时，0数据丢失恢复

当您尝试在其中一个数据库会话正在执行 NOLOGGING 操作时，尝试将数据库置于 FORCE LOGGING 模式时，将观察到“enq： XR – database force logging”等待事件。这很容易证明。 连接到数据库（例如会话 1）并执行 NOLOGGING 操作：通过从不同的会话（例如会话 2）执行以下 SQL，将数据库置于 FORCE LOGGING 模式：您将观察到 Session-2 不会立即完成，而是等待enq: XR – database force logging。

oracle ASM 从12c后引入了诸多特性，如FLEX ASM、Increased ASM storage limits、ASM instance V$ACTIVE_SESSION_HISOTRY 、ASM Disk Scrubbing外，最近发现还有一个关于ASM DISK rebalance 的增强EXPLAIN WORK FOR命令。12c 中新的 EXPLAIN WORK FOR 语句测量给定 ASM rebalance所需的工作量，并将结果输入 V$ASM_ESTIMATE 动态视图中.

近日，一位客户的Oracle 19c（19.18）环境中出现了一些查询堵塞等待较高的“latch free”情况。通过分析AWR报告中的ASH（Active Session History）数据，我们发现某些查询频繁等待“latch free”，并且p2值对应的latch号为39，latch名称为“object stats modification”。

“latch free”等待事件在Oracle 11g之后相对较少见到，通常我们会看到具体的latch名称。 “object stats modification” latches 又是一个较为罕见的等待事件。为了便于后续跟踪和分析，这里记录一下该问题及其相关细节。

oracle 11g R2环境1组normal冗余的ASM DISKGROUP包含3个cell的，每个cell为1个failgroup, 每个failgroup有48块ASM disks.因为一些硬件原因1个cell掉了19块disk，但offline后并未reblance完成，超过了“_asm_disk_repair_time”时间内没有online，被磁盘组自动drop force, 手动reblance时因为有1块asm disk使用不均衡free接近0MB，所以rebance会提示ora-15041错误。 此时add force与undrop均报错ora-15047. 处理rebalance需要空间，但加空间需要等上一个reblance完成的死结循环中。

SQL Translation框架是 12c 中的一项新功能，使开发人员能够在不更改底层代码的情况下替换SQL代码。这个特性是sql profile baseline的增强，原来是可以不动SQL文本替换执行计划，现在是连sql文本都可以“隐式”替换。这功能可用于在异构数据库向oracle迁移时，替换SQL代码。

《如何恢复Truncate sys.IDL_UB1$？》之前分享过这个对象被清空时的恢复，近期又有用户发现system表空间占用较大，发现IDL_UB1$是top对象，于是乎采用取表DDL，rename原表名，新建该表，数据导出导入方式重建该表。但是发现rename IDL_UB1$表，新创建IDL_UB1$后，exp无法导出，所有DDL无法执行, 包括无法rename回退，庆幸的是当前数据库还没有重启，否则就无法正常启动了，恢复更加复杂。

前不久一套oracle 12c RAC环境，客户反馈数据库出现过行锁enq: tx row content和library cache lock。blocker session为dbms_scheduler执行的sql是在收集统计信息，同时db alert log频繁提示qsmqChkOCMV : Timeout while locking object:NNNN, 简单记录.

最近客户一套oracle 19.14 standalone Database做的cascade dataguard环境，暂且认为是A->B->C三台单实例, 但总是A->B的延迟，从oracle 12c后引入real time cascade，所以如果依赖该特性对延迟要求较高， 分析A->B延迟发现，B库总时会出现GAP,并且未自动FAL，需要人为干预, 并且主库alert日志报错出现:
ORA-03135: connection lost contact
TT02 (PID:64459): Error 3135 for LNO:3 to“xxx”。

最近一套oracle 11.2.0.3 2-nodes RAC on AIX环境数据库，触发ora-600 [kjucvl:!busy] 和 ORA-00600: , : [kjuscv]后db instance crash, 但重启后使用plsql dev客户连接实例的两个节点，sysdate返回不同的时间，同时从db alert log 的时间也能发现实例重启后日志倒退了8小时，看来还是timezone问题，简单记录。

试想一下如果你的OpenGauss或postgreSQL数据库主机告警使用率超过了90%， 且因为使用local 存储，所有硬盘槽位已用完，除了迁移或扩展外部存储以外，是否可以给数据库做”瘦身”， 在PostgreSQL数据库中，有几种技术可以帮助减少数据库存储空间的使用

上个月那次“盆泼大瓢”式的暴雨差点导致一客户的服务器上船，但还是导致电源故障，在UPS支撑了一会儿中断，再次启动RAC中的一个节点，查看/u01 oracle 软件所在的文件系统无法使用， 重启后操作系统无法启动，后修复文件系统再次出现ASM无法启动问题，简单记录一下这个故障。

一套oracle 19c 多租户环境，安装19.19RU时datapatch失败，日志提示其中某个PDB执行SQL时，ORA-25153: Temporary Tablespace is Empty (DBD ERROR: OCILobCreateTemporary) ，简单记录处理方法.

前段时间一套Oracle Exadata的环境， 2个ib做的private network和cell存储网络，但总有一条存储链路从db server到cell server ping不通，但是ibstat ibping rds-ping都正常， 因为一个IB链路出问题同样影响IO，无法做到高可用。后分析发现是出于安全检查只是从内存级修改了rp_filter值为1启用了严格的反向路径校验，禁用rp filter后恢复正常。

oracle最近的问题遇到了越来越少， 今日一客户oracle 19c数据库重启后pdb进入受限模式(restricted), 回想前几日有安装一个小补丁one-off patch，运行过datapatch当时没有重启应该是问题没有暴露出来，查看pdb_plug_in_violations确认问题原因并非该one-off patch,因早期该库是Dataguard standby激活，软件RU新于原主库。

上周一客户咨询如果只有几个RMAN备份集文件，无任何地方得知controlfile， 如何恢复数据库？通常我们做RMAN备份会建议spfile, controlfile, datafile，archivelog一起备份，但如果没有rman备份日志，也没有备份controlfile如何恢复呢？ 同时再增加一步，如果dbid 和dbname也不知道呢？

最近有个Exadata客户总是出现12c R1数据库等待library cache lock， 根据P3值能发现是Last_Successful_Logon_Time的namespace，关于该特性确实引入了一些问题，之前在《Oracle19c 建议的 One-off patch之disable LAST SUCCESSFUL LOGIN TIME》和Oracle 12c New Feature: Last Login Time for Non-Sys Users及对于登录相关的 LAST SUCCESSFUL LOGIN TIME的Library cache lock又出新参数 记录过该问题，是与登录相关的问题，如果我们在这个版本没有相应的补丁怎么办？是否可以通过降低链接频率规避问题发生？理论上是的。通常是配置SQLNET.EXPIRE_TIME，那需要重启吗？