1962破记录了
1962分,总算打破自己尘封已久的1862分记录了,看来是水平有所长进,不容易啊,时隔太久了,截图记录一下。
1962分,总算打破自己尘封已久的1862分记录了,看来是水平有所长进,不容易啊,时隔太久了,截图记录一下。
前期19c上出现的这个问题,后期在操作ASM磁盘时,再次复发:
ORA-15137: The ASM cluster is in rolling patch state
此时确认两个节点的patch level完全一致,如下:
1 2 3 4 |
[root@wydb01:0 ~]$ crsctl query crs softwarepatch wydb01 Oracle Clusterware patch level on node wydb01 is [376483838]. [root@wydb01:0 ~]$ crsctl query crs softwarepatch wydb02 Oracle Clusterware patch level on node wydb02 is [376483838]. |
解决办法,只需在任一节点执行:
crsctl stop rollingpatch
如下操作:
[crayo[……]
在查看补丁情况及冲突检查时,相关操作结果异常,如下
1 2 3 4 5 6 7 |
[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 code 73 |
可见节点2的oraInventory异常,会导致无法继续操作打补丁。
根据相关的错误提示,检查oraInventory配置文件,如下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
[root@wydb02:2 /]$ cat /u01/app/oraInventory/ContentsXML/inventory.xml <?xml version="1.0" standalone="yes" ?> <!-- Copyright (c) 1999, 2020, Oracle and/or it/s affiliates. All rights reserved. --> <!-- Do not modify the contents of this file by hand. --> <INVENTORY> <VERSION_INFO> <SAVED_WITH>12.2.0.7.0</SAVED_WITH> <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER> </VERSION_INFO> <HOME_LIST> <HOME NAME="OraGI19Home1" LOC="/u01/app/12.2.0/grid" TYPE="O" IDX="1" CRS="true"/> </HOME_LIST> <COMPOSITEHOME_LIST> </COMPOSITEHOME_LIST> </INVENTORY> |
对比节点1的配置内容:
[crayon-6006a5e58988e04134410[……]
从11g源数据库,用数据泵通过dblink方式不落地导入数据到19c,遭遇Bug# 30321076。
数据泵报错日志如下:
1 2 3 4 5 6 7 |
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 or more workers have prematurely exited. ORA-39029: worker 6 with process name "DW02" prematurely terminated ORA-31671: Worker process DW02 had an unhandled exception. Job "SYS"."IMPDP_202012292030" stopped due to fatal error at Tue Dec 29 23:41:33 2020 elapsed 0 03:08:44 |
数据库报错日志如下:
1 2 3 4 5 6 7 8 |
2020-12-29T23:40:38.766472+08:00 Errors in file /u01/app/oracle/diag/rdbms/wydb/wydb1/trace/wydb1_dw04_366112.trc (incident=862366) (PDBNAME=PDBAPP): ORA-00600: internal error code, arguments: [qesmaGetPamR-NullCtx], [], [], [], [], [], [], [], [], [], [], [] PDBAPP(3):Incident details in: /u01/app/oracle/diag/rdbms/wydb/wydb1/incident/incdir_862366/wydb1_dw04_366112_i862366.trc 2020-12-29T23:40:39.785513+08:00 PDBAPP(3):Non critical error ORA-00602 caught while writing to trace file "/u01/app/oracle/diag/rdbms/wydb/wydb1/incident/incdir_862366/wydb1_dw04_366112_i862366.trc" Error message: ORA-00602: internal programming exception: [PC:0x7F5612F60EF9] [ADDR:0x7F5600000001] ORA-00600: internal error code, arguments: [qesmaGetPamR-NullCtx], [], [], [], [], [], [], [], [], [], [], [] |
查询MOS关于"qesmaGetPamR-NullCtx"的bug和patch,得到Patch 30[……]
■■GTID的概念
1)全局事务标识:global transaction identifiers
2)GTID是一个事务一一对应,并且全局唯一ID
3)一个GTID在一个服务器上只执行一次,避免重复执行导致数据混乱或者主从不一致
4)GTID用来代替传统复制方法,不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制,而是使用MASTER_AUTO_POSTION=1的方式[……]
■■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 lspatche[……]
今天在试图处理一个数据库(11.2.0.1)的性能问题时,发现无法运行awr相关的查询、生成操作,继而发现后台进程mmon/mmnl缺失。
重启mmon/mmnl的方法,是在业务闲时启用restricted模式,再马上禁用:
alter system enable restricted session;
alter system disable restricted session;
为了尽可能的[……]
配置了dg_broker以后,默认的FSFO并未启动:
Fast-Start Failover: Disabled
这样如果主库意外故障,备库无法自动切换为主库,需要手动切换。
如果启动了FSFO,备库会自动切换为主库。以下是验证过程。
如果启动FSFO,需要主备库开启快速闪回功能,确认flashback_on为yes。
启动FSFO
DGMGRL> enable fast_start f[……]
[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[……]
©1996-2020 Liking's Oracle Blog, All Rights Reserved