ANBOB™

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%很低，

达梦数据库简称DM，目前最新的版本是8.0版本，简称DM8。支持Windows、Linux和Unix操作系统，本次安装将采用Linux操作系统（Oracle Linux OS7），以高度兼容oracle颇受用户喜爱，前几天的blog提到语法兼容并不一定性能一定好，还是建议要按目标数据库的机制原生语法，后面测试一个前几天看到的执行计划，这里仅安装

最近半年遇到了至少有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

对于一个连续7*24小时的业务，如果session 1正在select查询一张大表，而另一个session尝试drop 相同的表，会发生什么？对于最流行的MVCC数据库oracle,mysql,postgreql需要对比，因为drop不只是字典表更新标记，还需要回收物理空间。在这几个数据库中的表现一样吗？Oceanbase和goldenDB及GreatDB的表现.

近期一个客户在vm环境外挂虚拟共享盘部署的oracle，类似AIX双机主备， 近期1主机异常hang死，另一主机启动数据库报错如下

ORA-01122: database file 2 failed verification check
ORA-01110: data file 2: ‘/oradata/anbob/sysaux01.dbf’
ORA-01200: actual file size of 1990400 is smaller than correct size of 2064640 blocks

之前有简单测试golang连接oracle和postgresql，最近刚好有客户问GOlang连接redis如何增加密码，这里简单记录，安装redis省略参考, go安装参考《Go语言(GO lang)连接Oracle Database使用godror》。

无法提供摘要。这是一篇受保护的文章。

最近1 Oracle Exadata X7客户ora instance 2被驱逐后，重启db instance 2启动挂起，影响另一实例instance 1, 随后终止启动，实例1运行正常。分析db instance 2启动时在等待control file enqueue超时，OS 日志显示“RDS/IB: conn <192.168.*.3,192.168.*.6,4> racing for more than 1s, retry”

近期1客户Oracle RAC 节点OS重启，协助分析原因，db层无日志错误输出，RAC层有vote disk I/O timeout， OS层 qla2xxx [0000:81:00.0]-801c:7: Abort command 和DEVICE RESET 操作。qla2xxx 是QLogic FC HBA的驱动，怀疑重启是HBA卡导致IO失败，导致disk timeout, CRS发起reboot. 简单记录该问题。

最近一客户的Oracle 19c环境在使用expdp导出分区变慢任务积压很严重，对于这个客户每月几万分区的EXPDP备份无法忍受，几M小空分区都要6分钟以上，导出速度和导出需求一样不科学☺。对datapump进程可以做sql trace跟踪，同时从导出时间段的AWR的TOP SQL看，这库似乎也没啥正常业务负载， TOP 1 SQL是DATA pump worker在查询v$open_cursor

Oracle数据库在12.1.0.2 以上版本asm中，如果normal冗余的磁盘组Failgroup少于3个或者High冗余的Failgroup少于5个是不允许删除Failgroup的 。或配置Normal或Flex冗余 ASM 磁盘组，具有 3 个常规故障组和至少 1 个仲裁故障组, 当Drop 1 个常规故障组时, rebalance 结束时，在 v$asm_operation 中可以看到 ORA-59048。

最近一个200TB的oracle需要创建standby dataguard, 大量的bigfile 表空间，这么大的数据库适合不落的duplicate方式，在搭建过程出现了bug，修复单个报错的文件遇到了问题，思路如何提速时发现了这个特性，意识到好久没有看oracle新特性了。USING BACKUPSET这个特性很棒。