一体机的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…
在查看补丁情况及冲突检查时，相关操作结果异常，如下 [oracle@wydb02:2 ~]$ $ORACLE_HOME/OPatch/opatch lsinv List of Homes on this system: Home name= OraGI19Home1, Location= "/u01/app/12.2.0/grid" LsInventorySession failed: RawInventory gets null OracleHomeInfo OPatch failed with error co…
从11g源数据库，用数据泵通过dblink方式不落地导入数据到19c，遭遇Bug# 30321076。 数据泵报错日志如下: ORA-39014: One or more workers have prematurely exited. ORA-39029: worker 3 with process name "DW02" prematurely terminated ORA-31671: Worker process DW02 had an unhandled exception. ORA-39014: One…
■■rebuild node2 within GI/RAC 由于种种原因已有集群的节点出现异常，无法修复，可以采用这个办法一步到位重建节点，大致步骤如下，详见官方文档。 ■dbca remove instance2 ■gridSetup.sh remove node2 ■gridSetup.sh add node2 ■dbca add instance2 正常的话，这个操作耗时2个小时左右。
19c用opatchauto打19.9补丁后无法操作ASM，操作磁盘组时，提示错误： ORA-15137: The ASM cluster is in rolling patch state 以下为一次耗时几天的操作记录，留作参考。 ■grid/oracle用户lspatches，完全一致 [grid@wydb01:1 ~]$ $ORACLE_HOME/OPatch/opatch lspatches 31780966;TOMCAT RELEASE UPDATE 19.0.0.0.0 (31780966) 31773…
今天在试图处理一个数据库(11.2.0.1)的性能问题时，发现无法运行awr相关的查询、生成操作，继而发现后台进程mmon/mmnl缺失。 重启mmon/mmnl的方法，是在业务闲时启用restricted模式，再马上禁用： alter system enable restricted session; alter system disable restricted session; 为了尽可能的减少设置restricted模式带来的影响，需两个语句一起执行。 启用restricted模式后，应用新连接数据库的会话…
[root@wydb02:1 ~]$ export PATH=$PATH:/u01/app/12.2.0/grid/OPatch [root@wydb02:1 ~]$ opatchauto apply /u01/soft/patch/31750108 OPatchauto session is initiated at Sat Nov 28 13:21:58 2020 System initialization log file is /u01/app/12.2.0/grid/cfgtoollogs/opatcha…