标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,682)
- DB2 (22)
- MySQL (73)
- Oracle (1,544)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (565)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
分类目录归档:Data Guard
ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
客户反馈,rac有一个节点无法open(可以mount),在open过程报如下错误
alert日志内容中报错主要为:
ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
Thu Feb 29 17:46:15 2024 Successful mount of redo thread 1, with mount id 354054158 Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE) Lost write protection disabled Completed: ALTER DATABASE MOUNT /* db agent *//* {1:32636:2} */ ALTER DATABASE OPEN /* db agent *//* {1:32636:2} */ Picked broadcast on commit scheme to generate SCNs ARCH: STARTING ARCH PROCESSES Thu Feb 29 17:46:16 2024 ARC0 started with pid=39, OS id=15401176 ARC0: Archival started ARCH: STARTING ARCH PROCESSES COMPLETE ARC0: STARTING ARCH PROCESSES Thu Feb 29 17:46:18 2024 ARC1 started with pid=41, OS id=11993228 Thu Feb 29 17:46:18 2024 ARC2 started with pid=42, OS id=15007986 Thu Feb 29 17:46:18 2024 ARC3 started with pid=43, OS id=12779724 ARC1: Archival started ARC2: Archival started ARC1: Becoming the 'no FAL' ARCH ARC1: Becoming the 'no SRL' ARCH ARC2: Becoming the heartbeat ARCH WARNING: The 'LOG_ARCHIVE_CONFIG' init.ora parameter settings are inconsistent with another started instance. This may be caused by the 'DB_UNIQUE_NAME' init.ora parameter being specified differently on one or more of the other RAC instances; the DB_UNIQUE_NAME parameter value MUST be identical for all instances of the database. Errors in file /oracle/oracle/diag/rdbms/xff/xff1/trace/xff1_lgwr_12976288.trc: ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance LGWR (ospid: 12976288): terminating the instance due to error 16188 Thu Feb 29 17:46:18 2024 System state dump requested by(instance=1, osid=12976288 (LGWR)),summary=[abnormal instance termination]. System State dumped to trace file /oracle/oracle/diag/rdbms/xff/xff1/trace/xff1_diag_13041806.trc Thu Feb 29 17:46:18 2024 ORA-1092 : opitsk aborting process Thu Feb 29 17:46:19 2024 License high water mark = 1 Instance terminated by LGWR, pid = 12976288 USER (ospid: 15532254): terminating the instance Instance terminated by USER, pid = 15532254
检查LOG_ARCHIVE_CONFIG和DB_UNIQUE_NAME参数配置
SQL> select inst_id,value,name,length(value) from gv$parameter where name in ('log_archive_config','db_unique_name'); INST_ID VALUE NAME LENGTH(VALUE) ---------- ------------------------------ ------------------------------------- ------------- 2 log_archive_config 2 xff db_unique_name 8 1 log_archive_config 1 xff db_unique_name 8
设置尝试log_archive_config配置为”和reset 均数据库无法正常启动
SQL> alter system set log_archive_config='' sid='*'; 系统已更改。 SQL> alter system reset log_archive_config scope=both sid='*'; 系统已更改。
设置log_archive_config=NODG_CONFIG数据库启动成功
SQL> alter system set log_archive_config=NODG_CONFIG scope=both sid='*'; 系统已更改。 SQL> alter database open; 数据库已更改。 SQL> exit 从 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options 断开
Oracle 19C 备库DML重定向—DML Redirection
在19c之前,oracle Data Guard备用数据库上不能执行DML操作,但是,从19c开始备库就可以进行DML操作了;Active Data Guard备用数据库上运行DML操作,可以在备用数据库上运行只读应用程序,偶尔执行DML(太频繁影响主库性能),备库上的DML操作可以透明地重定向到主数据库并在主数据库上运行。也包括PL/SQL块中的DML语句。Active Data Guard会话将等待,直到将相应的更改发送到Active Data Guard备用数据库并将其应用于Active Data Guard备用数据库为止。在DML操作期间将保持读取一致性,并且运行DML的备用数据库可以查看其未提交的更改。但是,所有其他备用数据库实例只有在提交事务后才能查看这些更改。
在主库上创建测试表
SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- BANNER_FULL -------------------------------------------------------------------------------- BANNER_LEGACY -------------------------------------------------------------------------------- CON_ID ---------- Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.5.0.0.0 Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production 0 SQL> select database_role ,open_mode from v$database; DATABASE_ROLE OPEN_MODE ---------------- -------------------- PRIMARY READ WRITE SQL> create table system.t_xff as select * from dba_objects; Table created. SQL> select count(*) from system.t_xff; COUNT(*) ---------- 72407
在备库上进行dml操作
SQL> select database_role ,open_mode from v$database; DATABASE_ROLE OPEN_MODE ---------------- -------------------- PHYSICAL STANDBY READ ONLY WITH APPLY SQL> select count(*) from system.t_xff; COUNT(*) ---------- 72407 SQL> alter session enable adg_redirect_dml; Session altered. SQL> delete from system.t_xff; 72407 rows deleted. SQL> commit; Commit complete.
在主库上验证备库dml操作结果
SQL> select count(*) from system.t_xff; COUNT(*) ---------- 0 SQL>
在18c中可以通过_enable_proxy_adg_redirect隐含参数实现dml重定向
RFS[22349]: Database mount ID mismatch
今天检查数据库发现一套主库上面报大量RFS[22349]: Database mount ID mismatch之类的错误
[oracle@hisdb2 trace]$ tail -f alert_hisdb2.log LNS: Standby redo logfile selected for thread 2 sequence 133319 for destination LOG_ARCHIVE_DEST_2 Mon Nov 06 20:56:09 2023 RFS[27080]: Assigned to RFS process 15518 RFS[27080]: Database mount ID mismatch [0x7afb8c50:0x70b2cf7b] (2063305808:1890766715) Mon Nov 06 20:57:09 2023 RFS[27081]: Assigned to RFS process 16299 RFS[27081]: Database mount ID mismatch [0x7afb8c50:0x70b2cf7b] (2063305808:1890766715) Mon Nov 06 20:57:09 2023 RFS[27082]: Assigned to RFS process 16319 RFS[27082]: Database mount ID mismatch [0x7afb8c50:0x70b2cf7b] (2063305808:1890766715)
这种错误表示rfs进程在传输的时候检测到database mount id不匹配(也就是认为这个库不是主库该传输或者接受日志的),出现类似这样的错误,大概率是由于这个dg成员(主库和备库)中应该有不匹配的库,回想这个库近期的操作,突然想到对这个主库在虚拟化平台的备库做了一次克隆,然后吧克隆库激活作为测试库的操作.基于此种情况,先判断该库是否和上次克隆的库之间创建有会话连接
--主库 [oracle@hisdb2 trace]$ netstat -natp|grep 192.168.106.63 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 192.168.115.12:52785 192.168.106.63:1521 ESTABLISHED - tcp 0 0 192.168.115.14:1521 192.168.106.63:21598 TIME_WAIT - --克隆库 [oracle@HIS_DG ~]$ netstat -atpn|grep 192.168.115.12 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 ::ffff:192.168.106.63:1521 ::ffff:192.168.115.12:52785 ESTABLISHED 6126/oraclehisdb
两个库之间确实存在会话,检查克隆库相关的dg配置
[oracle@HIS_DG ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Mon Nov 6 21:01:05 2023 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> show parameter fal; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ fal_client string HISDBDG fal_server string HISDB SQL> select open_mode,database_role from v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ WRITE PRIMARY SQL> show parameter archive; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ archive_lag_target integer 1800 log_archive_config string log_archive_dest string log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_ DEST valid_for=(all_logfiles,a ll_roles) db_unique_name=hisdb dg log_archive_dest_10 string log_archive_dest_11 string log_archive_dest_12 string log_archive_dest_13 string NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_dest_14 string log_archive_dest_15 string log_archive_dest_16 string log_archive_dest_17 string log_archive_dest_18 string log_archive_dest_19 string log_archive_dest_2 string service=hisdb lgwr async valid _for=(online_logfiles,primary_ role) db_unique_name=hisdb
该库的dg配置没有清除,当该库变为主库时,log_archive_dest_2刚好指向主库,从而使得主库上出现了类似RFS[22349]: Database mount ID mismatch的错误.处理方法是清除掉克隆库上面dg备库相关配置
SQL> alter system set log_archive_dest_2=''; System altered. SQL> alter system set fal_server=''; System altered.
主库日志中未再出现类似错误
Mon Nov 06 20:48:08 2023 RFS[22349]: Assigned to RFS process 7383 RFS[22349]: Database mount ID mismatch [0x7afb8c50:0x70b2cf7b] (2063305808:1890766715) [oracle@hisdb1 trace]$ tail -f alert_hisdb1.log RFS[22352]: Database mount ID mismatch [0x7afb8c50:0x70b2cf7b] (2063305808:1890766715) Mon Nov 06 20:58:09 2023 RFS[22353]: Assigned to RFS process 14958 RFS[22353]: Database mount ID mismatch [0x7afb8c50:0x70b2cf7b] (2063305808:1890766715) Mon Nov 06 21:01:09 2023 RFS[22354]: Assigned to RFS process 18580 RFS[22354]: Database mount ID mismatch [0x7afb8c50:0x70b2cf7b] (2063305808:1890766715) Mon Nov 06 21:01:09 2023 RFS[22355]: Assigned to RFS process 18598 RFS[22355]: Database mount ID mismatch [0x7afb8c50:0x70b2cf7b] (2063305808:1890766715) Mon Nov 06 21:03:28 2023 Thread 1 advanced to log sequence 129769 (LGWR switch) Current log# 9 seq# 129769 mem# 0: +DATA/hisdb/onlinelog/group_9.276.976991877 Current log# 9 seq# 129769 mem# 1: +FRA/hisdb/onlinelog/group_9.2334.976991877 Mon Nov 06 21:03:28 2023 Archived Log entry 524082 added for thread 1 sequence 129768 ID 0x70864b41 dest 1: Mon Nov 06 21:03:28 2023 LNS: Standby redo logfile selected for thread 1 sequence 129769 for destination LOG_ARCHIVE_DEST_2
事后在MOS上有一篇文档供参考:Database mount ID mismatch ORA-16009: invalid redo transport destination (Doc ID 1450132.1)
发表在 Data Guard
评论关闭