1962破记录了

1962分,总算打破自己尘封已久的1862分记录了,看来是水平有所长进,不容易啊,时隔太久了,截图记录一下。

19c用opatchauto打19.9补丁后无法操作ASM(二)

前期19c上出现的这个问题,后期在操作ASM磁盘时,再次复发:
ORA-15137: The ASM cluster is in rolling patch state

此时确认两个节点的patch level完全一致,如下:

解决办法,只需在任一节点执行:
crsctl stop rollingpatch
如下操作:

[crayo[……]

阅读全文>>

oraInventory异常

在查看补丁情况及冲突检查时,相关操作结果异常,如下

可见节点2的oraInventory异常,会导致无法继续操作打补丁。
根据相关的错误提示,检查oraInventory配置文件,如下

对比节点1的配置内容:

[crayon-6006a5e58988e04134410[……]

阅读全文>>

ORA-600 [QESMAGETPAMR-NULLCTX]

从11g源数据库,用数据泵通过dblink方式不落地导入数据到19c,遭遇Bug# 30321076。
数据泵报错日志如下:

数据库报错日志如下:

查询MOS关于"qesmaGetPamR-NullCtx"的bug和patch,得到Patch 30[……]

阅读全文>>

MySQL-GTID-主从复制

■■GTID的概念
1)全局事务标识:global transaction identifiers
2)GTID是一个事务一一对应,并且全局唯一ID
3)一个GTID在一个服务器上只执行一次,避免重复执行导致数据混乱或者主从不一致
4)GTID用来代替传统复制方法,不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制,而是使用MASTER_AUTO_POSTION=1的方式[……]

阅读全文>>

19c GI/RAC重建节点2

■■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

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 lspatche[……]

阅读全文>>

mmon/mmnl进程缺失/重启

今天在试图处理一个数据库(11.2.0.1)的性能问题时,发现无法运行awr相关的查询、生成操作,继而发现后台进程mmon/mmnl缺失。
重启mmon/mmnl的方法,是在业务闲时启用restricted模式,再马上禁用:
alter system enable restricted session;
alter system disable restricted session;
为了尽可能的[……]

阅读全文>>

验证19c DG_BROKER快速启动故障切换FSFO

配置了dg_broker以后,默认的FSFO并未启动:
Fast-Start Failover: Disabled
这样如果主库意外故障,备库无法自动切换为主库,需要手动切换。
如果启动了FSFO,备库会自动切换为主库。以下是验证过程。

如果启动FSFO,需要主备库开启快速闪回功能,确认flashback_on为yes。

启动FSFO
DGMGRL> enable fast_start f[……]

阅读全文>>

19c GI打补丁到19.9节点2失败处理

[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 initial[……]

阅读全文>>