ANBOB™

最近一套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，那需要重启吗？

最近某电力行业客户Oracle数据库反馈I/O 慢，查看 gv$asm_operation现在存在几块DROPING状态的OFFLINE的disk,正在做reblance（power 1），业务高峰期DISK BUSY 接近100% ，因为是SATA HDD，DB业务性能受到影响，且该ASM DISKGROUP 100TB以上RBLA预计要2天多的时间， 有没有办法停止当前的RBLA呢？

Datagaurd是oracle 数据库常用的容灾保护方案，但standby不再需要或删除后，在primary 需要清理之前的配置，通常认为很容易，比如禁用日志传输，no force logging, 清理log_archive _destN \LOG_ARCHIVE_CONFIG相关的参数等。是否很容易？ 但里面隐藏着一个风险。上周一个政F行业客户遇到个案例，主库Oracle RAC 11.2.0.4原来有dataguard，但是清理后，直到有1个节点重启后实例无法启动，

Oracle提供了非常有用的工具和视图来帮助数据库管理员进行数据库管理。其中包括一些处理空间问题的方案。其中一个这样的视图是DBA_TABLESPACE_USAGE_METRICS, DBA_TABLESPACE_USAGE_METRICS是基于GV$FILESPACE_USAGE，另外有些ORACLE周边工具为了简化查询，利用该VIEW日常监控表空间使用率，一客户反馈页面无返回数据，记录一下监控工具的遗漏.

前不久某银行客户oracle 19c（19.6） RAC，其中一节点计划性操作系统重新启动后，gipcd无法正常启动，导致CRS无法启动的问题。之前曾经记录过2篇Troubleshooting Oracle 19c GIPC start fail with “EXCEPTION[ ret gipcretBadArg (37) ] “和Exadata X7, RAC gipcd 无法启动，因为Network socket files， 这里简单记录.

最近一个交通行业的客户近400TB的数据库，需要导出100T的历史数据后清理，但使用Datapump Expdp导出过程遇到了好几个问题且是已知bug ,简单记录. 首先注意如果使用NFS作为expdp的directory, 确认的使用正确的mount option, 同时如果远程是一些其它文件系统如ZFS或Vxfs ，要注意日志和碎片带来的性能影响，建议先在本地文件系统测试导出正常。

最近一证券客户反馈一SQL执行时间突然变长，平时执行2秒，问题时间312秒，并且发现问题时间段的temp表空间使用率耗尽, 十几分钟后问题又消失， SQL的执行计划未改变，但单次执行逻辑读大量增加，同时伴有少数据物理读变化， 几个小时后找到我帮分析一下原因，下面记录一种分析思路.

昨日一客户Oracle DBWR I/O操作挂起， checkpoint无法完成，数据库实例未crash，环境操作系统Suse Linux v10, Oracle 11.1.0.7 单机数据库， 10TB使用raw存储数据文件格式， 昨晚有存储机柜断电，之后数据库alert log出现”WARNING:io_getevents timed out 600 sec”, 但vmsta和iostat查看cpu, memory, vmstat R B 列为0, iostat 的await和util%很低，

最近半年遇到了至少有4例因为oracle内存耗尽出现的OOM kill oracle进程，DB instance crash的现象， 常见原因是内存分配不合理，如过大的Hugepage或没配置Hugepage， 或过大的SGA，或有备份导出任务占用过多的cached内存。 之前整理过《Troubleshooting Out-Of-Memory(OOM) killer db crash when memory exhausted》, 仅记录一下问题现象

最近有个客户的某业务其中一条insert into txxxx values(seq.nextval, xx, xx ,xx);的SQL从Oracle Exadata X5迁移到X8上以后，sql性能有几百ms的差异，因该SQL是应用APP界面中登录写日志的一个SQL, 比较影响体验的一个关键SQL, 希望找到其中的原因，是否其它SQL存在相同的问题?

Oracle 19c启动失败报错ora-600 [kzsrsyncdbwithpwdfile-1:user row cache], 信息如下
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kzsrSyncDBWithPwdFile-0:user row
cache], [], [], [], [], [], [], [], [], [], [], []

当两张大表做join访问时，我们希望优化器使用hash join的方式连接提高查询性能，但是在主流的oracle,mysql,postgresql或openGauss中变现稍有差异，所以在数据库替换时需要注意，简单记录一下对于equi join(=)，non-equi-join(<>),Semijoin(exists), Antijoin(not exists/in), outer join(left/right join)时的不同表现。

最近一个Oracle Exadata x5 2节点RAC 11.2.0.4环境，每个节点中有2套DB实例。 Node1正常运行，计划性重启Node 2后，CRS启动正常，主机上1个db的 instance 2启动正常， 但另1个db的node2 db instance启动失败，提示下面的错误：
ORA-01105: mount is incompatible with mounts by other instances
ORA-01154: database busy. Open, close, mount, and dismount not allowed now