昨天在查看一个adg备库时，偶然发现了一个oracle的大坑，就是审计日志文件(*.aud)过多的问题，在adump目录下竟然有接近500万个aud文件，经查阅资料得知，所有以sysdba用户访问数据库的情况，都会记录一个aud文件在adump目录下，即使audit_trail设置为none，也会记录aud文件。 这样的话，当某些情况频繁以sysdba登录数据库的话，经年累月的定时任务，会导致这个路径下积压大量的aud文件，可想而知，严重情况会导致inode占满，导致OS故障，后果不堪设想。 我们知道默认情况数据库…

某项目一个11g的老库集群3节点已运行多年，目前有一个adg备库用于读写分离。由于使用的老存储已无法扩容，主磁盘组空间捉襟见肘，不得已借用多次FRA的空间用于扩容表空间。 为临时解决空间不足的现状，临时申请1台物理主机新构建adg用于替换原有adg备库，释放存储给主集群。 新申请的主机测试不充分，后期发现与主集群之间带宽仅有50-60MB/s，为后期实施带来了困难，同时新主机未能提供同版本的CentOS6.5，而是7.4，也为后续实施造成了麻烦，尽管解决掉了问题，但是不得不说，这些时间浪费成本也不低。 本次采用du…

之前用sysbench测试过oracle，发现sysbench新版本对oracle的支持真是太不友好，倒是0.5版本可以用，但是lua脚本又不丰富。今次网搜了下，发现osdba大侠有一套解决方案，特记录在此以供参考。 国内链接在此： https://gitee.com/csudata/sysbench_bin github在此： https://github.com/osdba/sysbench_bin https://github.com/osdba/sysbench_lua 把sysbench_ora和oltp…

一个SQL查询很慢，查看执行计划出现了较多的“BITMAP CONVERSION FROM ROWIDS”，如下所示。 SQL_ID 1x9rd10ykjvjd, child number 0 ------------------------------------- select t.*, t.LIMIT_TIME - SYSDATE AS nowNumber, t.LIMIT_TIME - SYSDATE - i.manual_task_limit / 24 AS limitNumber from USER_W…

19.9 ADG环境，查看Flash Recovery Area Usage发现FLASHBACK LOG占用了90%多的FRA空间，而ARCHIVED LOG仅占用不到10%，这还了得，这是一个繁忙的生产环境，一般是不需要长时间的Flash Back的，得想办法清理一下，以免影响归档。【注：其实是不会影响归档的，具体的实践观察见后】 如下是清理前的占用情况: FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID …

在CentOS7.6下配置oracle 19.9时，如果没有显式设置HugePages为SGA所需的合适的值大小，而是设置了较大的值，尽管有时可以分配一些HugePages，但是一般不会是所设置的数目，结论是，必须显式设置合适的值。 如下关于wydb两个实例的alertlog输出，最后一次输出是正确设置并重启之后的： ---wydb1 2021-01-14T15:38:39.837037+08:00 PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ER…

一体机的19c新数据库，由于项目人员修改undo，导致出现有的pdb无法open的情况： 2021-01-26T12:03:43.957991+08:00 PDBAPP(3):Endian type of dictionary set to little PDBAPP(3):Undo initialization recovery: err:0 start: 2574325 end: 2574327 diff: 2 ms (0.0 seconds) 2021-01-26T12:03:44.456447+08:00 …

■2021-01-14 15:07 存储开始出现问题，主数据库2个节点(node1、node2)均报共享存储'I/O error' -------node1 alert 2021-01-14T15:07:24.122930+08:00 WARNING: Write Failed. group:1 disk:3 AU:81 offset:2022912 size:4096 path:/dev/asmdisks/su001_lun04 incarnation:0xf0f0720e asynchronous result…

关闭网络心跳ip后，此时磁盘心跳正常，数据库主集群的2个节点发生脑裂，导致数据库重新配置。 重新配置的基本原则：节点数多的子集群存活，如果子集群包含的节点数相同，那么包含最小编号节点的子集群存活。 所以2节点集群，如果停掉所有的心跳ip后，node1存活，继续对外提供服务。 实际日志顺序如下： 1、node2的数据库实例被强行终止 2、node1确认检测到node2实例终止后，自我调整后继续提供数据库服务 ■■停掉所有的心跳ip ■■node2 日志 2021-01-20T16:20:15.835897+08:00…

前期19c上出现的这个问题，后期在操作ASM磁盘时，再次复发： ORA-15137: The ASM cluster is in rolling patch state 此时确认两个节点的patch level完全一致，如下： [root@wydb01:0 ~]$ crsctl query crs softwarepatch wydb01 Oracle Clusterware patch level on node wydb01 is [376483838]. [root@wydb01:0 ~]$ crsctl q…