Data Guard缺少部分归档日志解决办法

最新推荐文章于 2023-03-18 23:13:45 发布
最新推荐文章于 2023-03-18 23:13:45 发布
阅读量1.7k 收藏
点赞数
分类专栏： oracle
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lijingkuan/article/details/50717767
版权

发现问题

测试环境搭建了一套RAC+DG的系统。数据库版本11203。
RAC双节点，DG单节点。
有段时间把DG节点关机，只开主节点RAC。（毕竟并没有线上业务，且大多用来做实验或数据统计用。）
一段时间之后，打开DG节点，发现无法open read only。
检查发现DG缺少部分归档日志，且该部分归档日志已经被删掉，没有备份。
此时有两种解决办法：
1.重新搭建DG环境。
2.不重新搭建DG环境，利用其他办法解决。
本文详细介绍了利用RMAN增量备份解决DG gap的问题。

操作步骤

1.确认问题存在，分析原因。

查看DG日志应用情况，确定日志应用进度。

thread 1: sequence# 214
thread 2: sequence# 112

SQL> select NAME,THREAD#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,ARCHIVED,APPLIED,DELETED from v$archived_log;

NAME                                                  THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# ARC APPLIED   DEL
-------------------------------------------------- ---------- ---------- ------------- ------------ --- --------- ---
/u01/app/oracle/archARC_1_0000000211_885898750.arc          1        211       5889618      5889672 YES YES       NO
/u01/app/oracle/archARC_2_0000000111_885898750.arc          2        111       5889621      5889675 YES YES       NO
/u01/app/oracle/archARC_1_0000000212_885898750.arc          1        212       5889672      5936547 YES YES       NO
/u01/app/oracle/archARC_1_0000000213_885898750.arc          1        213       5936547      5942602 YES YES       NO
/u01/app/oracle/archARC_1_0000000214_885898750.arc          1        214       5942602      5953350 YES YES       NO
/u01/app/oracle/archARC_2_0000000112_885898750.arc          2        112       5889675      5954190 YES NO        NO
/u01/app/oracle/archARC_1_0000000274_885898750.arc          1        274       9065115      9144171 YES NO        NO
/u01/app/oracle/archARC_1_0000000275_885898750.arc          1        275       9144171      9226083 YES NO        NO
/u01/app/oracle/archARC_1_0000000276_885898750.arc          1        276       9226083      9252006 YES NO        NO
/u01/app/oracle/archARC_2_0000000154_885898750.arc          2        154       9155657      9228653 YES NO        NO
..................
..................
/u01/app/oracle/archARC_2_0000000249_885898750.arc          2        249      14437971     14442095 YES NO        NO
/u01/app/oracle/archARC_2_0000000252_885898750.arc          2        252      14459559     14461551 YES NO        NO
/u01/app/oracle/archARC_1_0000000373_885898750.arc          1        373      14459562     14461565 YES NO        NO

155 rows selected.

SQL> 
SQL>

从以上可以看出DG节点日志应用SCN位于5953350和5954190之间。（根据thread 1 和thread 2日志SCN）

查看DG节点归档日志gap视图

SQL> 
SQL> select * from v$archive_gap;

   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
         1           215            273
         2           113            152

SQL>

查询数据库当前SCN

SQL> select current_scn from v$database;

CURRENT_SCN
-----------
    5953349

确认主库是否有添加数据文件
DG节点关机期间并未添加数据文件
相关SQL如下：

SQL> select FILE#,name from v$datafile where CREATION_CHANGE#> =5953349;

no rows selected

主库增量备份
增量备份的SCN要比当前数据库SCN小。（否则拷贝到DG节点做恢复的时候不起作用，后面有详细输出。）

[oracle@racnode1 ~]$ rman target /

RMAN> backup incremental from SCN 5953344  DATABASE FORMAT '/home/oracle/ljk_%U' TAG 'zengliangbk';

Starting backup at 22-FEB-16

using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=28 instance=RACDB_1 device type=DISK
backup will be obsolete on date 29-FEB-16
archived logs will not be kept or backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=+DATADG/racdb/datafile/data01.269.886180153
input datafile file number=00002 name=+DATADG/racdb/datafile/sysaux.261.885898927
input datafile file number=00001 name=+DATADG/racdb/datafile/system.260.885898771
input datafile file number=00003 name=+DATADG/racdb/datafile/undotbs1.262.885898975
input datafile file number=00007 name=+DATADG/racdb/datafile/index01.270.886180183
input datafile file number=00004 name=+DATADG/racdb/datafile/undotbs2.264.885899061
input datafile file number=00005 name=+DATADG/racdb/datafile/users.265.885899091
input datafile file number=00009 name=+DATADG/racdb/datafile/test2.301.888744571
channel ORA_DISK_1: starting piece 1 at 22-FEB-16
channel ORA_DISK_1: finished piece 1 at 22-FEB-16
piece handle=/home/oracle/ljk_11quirn3_1_1 tag=ZENGLIANGBK comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:03:06

using channel ORA_DISK_1
backup will be obsolete on date 29-FEB-16
archived logs will not be kept or backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 22-FEB-16
channel ORA_DISK_1: finished piece 1 at 22-FEB-16
piece handle=/home/oracle/ljk_12quirt0_1_1 tag=ZENGLIANGBK comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 22-FEB-16

备份控制文件（一定要有，否则在DG节点应用完增量备份之后，控制文件不会发生改变，跟应用增量之前一样。）

RMAN> backup current controlfile for standby format '/home/oracle/ljk_ctl.bak';

Starting backup at 22-FEB-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=158 instance=RACDB_1 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including standby control file in backup set
channel ORA_DISK_1: starting piece 1 at 22-FEB-16
channel ORA_DISK_1: finished piece 1 at 22-FEB-16
piece handle=/home/oracle/ljk_ctl.bak tag=TAG20160222T151222 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 22-FEB-16

将主库的增量备份和控制文件备份拷贝到DG节点

[oracle@stdby ~]$ ll
total 2137660
drwxr-xr-x 8 oracle oinstall       4096 Sep 22  2011 database
-rw-r----- 1 oracle oinstall 1065369600 Feb 22 15:28 ljk_11quirn3_1_1
-rw-r----- 1 oracle oinstall   18743296 Feb 22 15:28 ljk_12quirt0_1_1
-rw-r----- 1 oracle oinstall   18743296 Feb 22 15:11 ljk_ctl.bak

在DG节点应用增量备份
先把拷贝过来的备份加入到RMAN管理中

RMAN> catalog backuppiece "/home/oracle/ljk_11quirn3_1_1","/home/oracle/ljk_12quirt0_1_1";

cataloged backup piece
backup piece handle=/home/oracle/ljk_11quirn3_1_1 RECID=23 STAMP=904491054
cataloged backup piece
backup piece handle=/home/oracle/ljk_12quirt0_1_1 RECID=24 STAMP=904491057

RMAN> catalog start with '/home/oracle';
List of Cataloged Files
=======================
File Name: /home/oracle/ljk_ctl.bak

应用增量备份

RMAN> recover database noredo;

Starting recover at 22-FEB-16
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK
RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
ORACLE error from target database: 
ORA-19922: there is no parent row with id 0 and level 1

channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /u01/app/oracle/oradata/RACSTD/system.260.885898771
destination for restore of datafile 00002: /u01/app/oracle/oradata/RACSTD/sysaux.261.885898927
destination for restore of datafile 00003: /u01/app/oracle/oradata/RACSTD/undotbs1.262.885898975
destination for restore of datafile 00004: /u01/app/oracle/oradata/RACSTD/undotbs2.264.885899061
destination for restore of datafile 00005: /u01/app/oracle/oradata/RACSTD/users.265.885899091
destination for restore of datafile 00006: /u01/app/oracle/oradata/RACSTD/data01.269.886180153
destination for restore of datafile 00007: /u01/app/oracle/oradata/RACSTD/index01.270.886180183
destination for restore of datafile 00009: /u01/app/oracle/oradata/RACSTD/test2.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/ljk_11quirn3_1_1
channel ORA_DISK_1: piece handle=/home/oracle/ljk_11quirn3_1_1 tag=ZENGLIANGBK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:25

Finished recover at 22-FEB-16

应用备份的控制文件


RMAN> RESTORE STANDBY CONTROLFILE FROM '/home/oracle/ljk_ctl.bak';

Starting restore at 22-FEB-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
output file name=/u01/app/oracle/oradata/RACSTD/control01.ctl
output file name=/u01/app/oracle/oradata/RACSTD/control02.ctl
Finished restore at 22-FEB-16

遇到的问题

1.增量备份开始SCN如果小于当前DG的SCN，则增量备份无法应用。

RMAN> backup incremental from SCN 5954190 DATABASE FORMAT '/home/oracle/xff_%U' TAG 'XIFENFEI';

SCN 5954190大于DG节点SCN 5953349
应用增量备份的时候

RMAN> recover database noredo;

Starting recover at 22-FEB-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=22 device type=DISK

Finished recover at 22-FEB-16

2.应用增量备份的时候报错

ORA-19573: cannot obtain exclusive enqueue for datafile 6
出错原因：
日志应用进程已经启动，正在恢复数据库（虽然没有日志）。
解决办法：recover managed standby database cancel
应用增量日志需要DG处于mount状态

RMAN> recover database noredo;

Starting recover at 22-FEB-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=22 device type=DISK
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /u01/app/oracle/oradata/RACSTD/system.260.885898771
destination for restore of datafile 00002: /u01/app/oracle/oradata/RACSTD/sysaux.261.885898927
destination for restore of datafile 00003: /u01/app/oracle/oradata/RACSTD/undotbs1.262.885898975
destination for restore of datafile 00004: /u01/app/oracle/oradata/RACSTD/undotbs2.264.885899061
destination for restore of datafile 00005: /u01/app/oracle/oradata/RACSTD/users.265.885899091
destination for restore of datafile 00006: /u01/app/oracle/oradata/RACSTD/data01.269.886180153
destination for restore of datafile 00007: /u01/app/oracle/oradata/RACSTD/index01.270.886180183
destination for restore of datafile 00009: /u01/app/oracle/oradata/RACSTD/test2.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/ljk_11quirn3_1_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/22/2016 15:31:13
ORA-19870: error while restoring backup piece /home/oracle/ljk_11quirn3_1_1
ORA-19573: cannot obtain exclusive enqueue for datafile 6

3恢复控制文件时出错

原因：数据库处于mount状态
解决办法：将DG启动到nomout状态

RMAN> RESTORE STANDBY CONTROLFILE FROM '/home/oracle/ljk_ctl.bak';

Starting restore at 22-FEB-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=135 device type=DISK

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/22/2016 15:41:48
RMAN-06496: must use the TO clause when the database is mounted or open

4.新归档的日志无法应用

查看归档日志应用情况，发现新生成的归档日志都没有应用。

SQL> select NAME,THREAD#,SEQUENCE#,ARCHIVED,APPLIED from v$archived_log;
NAME                                                  THREAD#  SEQUENCE# ARC APPLIED
-------------------------------------------------- ---------- ---------- --- ---------
/u01/app/oracle/archARC_2_0000000254_885898750.arc          2        254 YES NO
/u01/app/oracle/archARC_2_0000000253_885898750.arc          2        253 YES NO
/u01/app/oracle/archARC_2_0000000255_885898750.arc          2        255 YES NO
/u01/app/oracle/archARC_2_0000000256_885898750.arc          2        256 YES NO
/u01/app/oracle/archARC_2_0000000257_885898750.arc          2        257 YES NO
/u01/app/oracle/archARC_1_0000000375_885898750.arc          1        375 YES NO
/u01/app/oracle/archARC_1_0000000376_885898750.arc          1        376 YES NO
/u01/app/oracle/archARC_1_0000000374_885898750.arc          1        374 YES NO
/u01/app/oracle/archARC_1_0000000377_885898750.arc          1        377 YES NO
/u01/app/oracle/archARC_1_0000000378_885898750.arc          1        378 YES NO
/u01/app/oracle/archARC_2_0000000258_885898750.arc          2        258 YES NO

查看alert日志寻找原因：
发现无法找到数据文件test2.301.888744571

Mon Feb 22 17:09:22 2016
alter database recover managed standby database using current logfile disconnect from session
Attempt to start background Managed Standby Recovery process (RACSTD)
Mon Feb 22 17:09:22 2016
MRP0 started with pid=24, OS id=11362 
MRP0: Background Managed Standby Recovery process started (RACSTD)
 started logmerger process
Mon Feb 22 17:09:27 2016
Managed Standby Recovery starting Real Time Apply
Mon Feb 22 17:09:27 2016
Errors in file /u01/app/oracle/diag/rdbms/racstd/RACSTD/trace/RACSTD_dbw0_11312.trc:
ORA-01157: cannot identify/lock data file 9 - see DBWR trace file
ORA-01110: data file 9: '/u01/app/oracle/oradata/RACSTD/test2.301.888744571'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
MRP0: Background Media Recovery terminated with error 1110
Errors in file /u01/app/oracle/diag/rdbms/racstd/RACSTD/trace/RACSTD_pr00_11365.trc:
ORA-01110: data file 9: '/u01/app/oracle/oradata/RACSTD/test2.301.888744571'
ORA-01157: cannot identify/lock data file 9 - see DBWR trace file
ORA-01110: data file 9: '/u01/app/oracle/oradata/RACSTD/test2.301.888744571'
Managed Standby Recovery not using Real Time Apply
Slave exiting with ORA-1110 exception
Errors in file /u01/app/oracle/diag/rdbms/racstd/RACSTD/trace/RACSTD_pr00_11365.trc:
ORA-01110: data file 9: '/u01/app/oracle/oradata/RACSTD/test2.301.888744571'
ORA-01157: cannot identify/lock data file 9 - see DBWR trace file
ORA-01110: data file 9: '/u01/app/oracle/oradata/RACSTD/test2.301.888744571'
Recovery Slave PR00 previously exited with exception 1110
MRP0: Background Media Recovery process shutdown (RACSTD)
Completed: alter database recover managed standby database using current logfile disconnect from session

查看文件目录和数据文件视图：

[oracle@stdby RACSTD]$ ll
total 5344984
-rw-r----- 1 oracle oinstall   18694144 Feb 22 17:33 control01.ctl
-rw-r----- 1 oracle oinstall   18694144 Feb 22 17:33 control02.ctl
-rw-r----- 1 oracle oinstall 1677729792 Feb 22 17:26 data01.269.886180153
-rw-r----- 1 oracle oinstall  314580992 Feb 22 17:26 index01.270.886180183
drwxr-x--- 4 oracle oinstall       4096 Aug 24 15:36 RACSTD
-rw-r----- 1 oracle oinstall   52429312 Aug 26 09:57 redo01.log
-rw-r----- 1 oracle oinstall   52429312 Aug 26 09:57 redo02.log
-rw-r----- 1 oracle oinstall   52429312 Aug 26 09:57 redo03.log
-rw-r----- 1 oracle oinstall   52429312 Aug 26 09:57 redo04.log
-rw-r----- 1 oracle oinstall   52429312 Feb 22 17:27 redo05.log
-rw-r----- 1 oracle oinstall   52429312 Feb 22 17:33 redo06.log
-rw-r----- 1 oracle oinstall   52429312 Feb 22 17:27 redo07.log
-rw-r----- 1 oracle oinstall   52429312 Feb 22 17:33 redo08.log
-rw-r----- 1 oracle oinstall   52429312 Feb 22 17:27 redo09.log
-rw-r----- 1 oracle oinstall   52429312 Feb 22 17:27 redo10.log
-rw-r----- 1 oracle oinstall 1184899072 Feb 22 17:26 sysaux.261.885898927
-rw-r----- 1 oracle oinstall  775954432 Feb 22 17:26 system.260.885898771
-rw-r----- 1 oracle oinstall   10493952 Feb 22 15:45 test2.dbf
-rw-r----- 1 oracle oinstall  671096832 Feb 22 17:26 undotbs1.262.885898975
-rw-r----- 1 oracle oinstall  209723392 Feb 22 17:26 undotbs2.264.885899061
-rw-r----- 1 oracle oinstall   61612032 Feb 22 17:26 users.265.885899091
SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/RACSTD/system.260.885898771
/u01/app/oracle/oradata/RACSTD/sysaux.261.885898927
/u01/app/oracle/oradata/RACSTD/undotbs1.262.885898975
/u01/app/oracle/oradata/RACSTD/undotbs2.264.885899061
/u01/app/oracle/oradata/RACSTD/users.265.885899091
/u01/app/oracle/oradata/RACSTD/data01.269.886180153
/u01/app/oracle/oradata/RACSTD/index01.270.886180183
/u01/app/oracle/oradata/RACSTD/test2.301.888744571

修改数据文件名称（修改之前备份）

[oracle@stdby RACSTD]$ cp test2.dbf test2.dbf.bak
[oracle@stdby RACSTD]$ mv test2.dbf test2.301.888744571

之后查看归档日志应用情况

SQL> select NAME,THREAD#,SEQUENCE#,ARCHIVED,APPLIED from v$archived_log;

NAME                                                  THREAD#  SEQUENCE# ARC APPLIED
-------------------------------------------------- ---------- ---------- --- ---------
/u01/app/oracle/archARC_2_0000000254_885898750.arc          2        254 YES YES
/u01/app/oracle/archARC_2_0000000253_885898750.arc          2        253 YES YES
/u01/app/oracle/archARC_2_0000000255_885898750.arc          2        255 YES YES
/u01/app/oracle/archARC_2_0000000256_885898750.arc          2        256 YES YES
/u01/app/oracle/archARC_2_0000000257_885898750.arc          2        257 YES YES
/u01/app/oracle/archARC_1_0000000375_885898750.arc          1        375 YES YES
/u01/app/oracle/archARC_1_0000000376_885898750.arc          1        376 YES YES
/u01/app/oracle/archARC_1_0000000374_885898750.arc          1        374 YES YES
/u01/app/oracle/archARC_1_0000000377_885898750.arc          1        377 YES YES
/u01/app/oracle/archARC_1_0000000378_885898750.arc          1        378 YES YES
/u01/app/oracle/archARC_2_0000000258_885898750.arc          2        258 YES YES

之后以open read only方式可以正常打开DG节点数据库。

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> alter database open;  

Database altered.

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY WITH APPLY
lijingkuan
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
[Oracle] Data Guard 之 Redo传输详解
09-10
Oracle Data Guard 是一个高可用性的解决方案，提供了两个主要服务：Redo传输服务和Redo应用服务。本文将着重讲解 Redo传输服务的实现机制。 一、Redo传输服务 Redo传输服务是 Oracle Data Guard 的核心组件之一...
dataguard容灾归档缺失恢复(pr归档还在）
Du.的博客
10-21 643
容灾库恢复
Oracle 培训笔记 8.27 redo undo checkpoint
08-27 728
1、redo --查看日志组 select * from v$log; members: 日志组成员数 archived: 归档，写满的日志的备份 status：  active：实例恢复需要  inactive：实例恢复不需要  current：当前正在
DG备库缺失归档文件GAP日志
weixin_33873846的博客
05-29 430
问题现象： XXXsdgebus-dg GAP手工注册归档 #出现GAP idle>select * from v$archive_gap; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1 140513 1...
DG关于备库日志缺失gap的问题
richard的专栏（bigdata.han@gmail.com）
01-18 1498
状态确认查询 当前没有应用完的最小日志文件序列 Select min(Sequence#) From V$archived_Log where Applied!='YES'; mrp当前正在应用的日志序列 select process,status,sequence# from v$managed_standby; 通过查询可以看出当前应用日志
dataguard却少日志文件的处理过程
heizistudio的专栏
11-29 2636
1、环境 主从oracle数据库运行在最高可用模式 数据一致   2、从库上，关闭数据库，使主库归档不能传送到备库 SQL> shutdown immediate ORA-01109: database not open  3、主库上创建新表、切换日志 SQL> insert into test0008 select * from dba_objects;
Oracle数据库Data Guard技术介绍.pptx
10-14
Oracle 数据库 Data Guard 技术是一种高可用性和灾难恢复解决方案，旨在保护 Oracle 数据库免受故障和数据丢失的影响。该技术通过在主数据库和备用数据库之间传输 redo 数据来实现高可用性和灾难恢复。 Data ...
ORACLE ACTIVE DATA GUARD技术白皮书.docx
10-14
通过这些特性，Active Data Guard消除了传统数据保护解决方案中的折衷，提供了最佳的数据保护、性能和易管理性。它不仅适用于计划内的维护操作，还能应对意外的系统中断，确保业务连续性。总的来说，Oracle Active ...
Oralce 归档日志开启与关闭示例
09-10
Oracle数据库的归档日志（Archived Logs...同时，归档日志也是Oracle RAC（Real Application Clusters）和Data Guard等高可用性解决方案的基础。因此，理解和正确管理归档日志对于维护数据库的稳定性和安全性至关重要。
Data guard实施
02-01
物理备库会接收和保存从主库传来的重做数据（Redo Data），采用块介质恢复的方式保持主备库之间的数据同步，支持归档日志或联机日志两种不同的同步方式，支持同步或异步两种不同的归档传输方式，支持最大性能、最大...
Oracle DG 手动备库应用缺失日志
03-18 457
'/u01/app/oracle/oradata/flash_recovery_area/ORCLST/archivelog/2023_03_18/o1_mf_1_17_l1cmd1wk_.arc'^C已经应用ID----------100200200300。
Oracle_dg归档丢失问题处理
ckth47350的博客
11-16 1196
Oracle_dg归档丢失问题处理 环境： OS：RedHat 6.3 DB: Oracle Database 11g Enterprise Edition Release 12.1.0.2.0 ...
dataguard归档不同步的问题解决思路及步骤
cuiyan1982的专栏
09-13 4605
系统版本：centos7.3 数据库版本：11.2.3 问题描述：新搭的dataguard，数据文件全部都可以同步到备库，截止到最后的归档都可以同步，但是此后主库的归档都同步不过去，备库没有错误日志生成，主库一直报  Error 12154 received logging on to the standby PING[ARC2]: Heartbeat failed to conn
Dataguard还原测试故障ORA-10458
清风弄影
05-16 1579
主机备份拷贝到备机上进行Rman 还原，完成后用standy controlfile替换。 SQL*Plus: Release 12.2.0.1.0 Production on Fri May 15 11:06:00 2020 Copyright (c) 1982, 2016, Oracle. All rights reserved. Connected to an idle instance. SQL> startup nomount; ORACLE instance started. Tota.
oracle dg 日志手动应用,物理DG 日志传输以及应用过程
weixin_32955881的博客
04-13 1002
mysql 中的主备会经常碰到主库和备库日志传输延迟，其中一个role突然宕机，这时候会发生什么？最近刚好在生产环境中碰到切换物理DG的需求，参照学习，准备研究一下oracle中主备切换时日志未及时应用，oracle怎么处置！1.redo日志同步传输：事务会等到redo日志传输到所有可以到达的备库之后再提交。这种一般是在最大保护性和最大可用性模式下使用。(NET_TIMEOUT表明LGWR将被阻塞...
Oracle Dataguard 漏传归档日志
清风弄影
03-13 478
Oracle dataguard因为设置为异步，非强制，有些时候会莫名漏掉一些日志不传递，很多时候都是看日志才发现日志无法应用了。 如果去找到底漏了那个日志很费功夫，于是就像写一个脚本。 1.在备份服务器上，新建一个checklog.vbs dim fso,fs,f,f1 dim startnum,endnum '设定其实数和结束数(这个需要根据自己的实际情况修改） startnum= e...
oracle dataguard 主库归档日志缺失，导致主备库不一致故障处理
killvoon的专栏
07-07 6665
背景描述： 主库上由于归档日志未及时清理，导致根目录满了，虚拟化环境，系统ping通，但连接不上，只好重启。 由于主库上堆积了大量归档日志未应用到备库，所以备库上一直在追加日志，然后在我低头沉思卖萌的瞬间，再抬头发现备库alert日志报错，缺失归档日志。 火急火燎的查看主库归档日志情况，特么的，原先100多g的归档全没了，开发那边真是为民请命，随手删了归档腾了空间。。。 问题处理思
oracle dataguard不同步,Oracle Dataguard中备库中归档日志不同步
weixin_39524703的博客
04-03 674
环境：RAC+单机 Dataguard问题：启动备库到ADG模式时，发现后台归档日志并不同步1、在备库中发现日志的归档日志不同步，内容如下：MRP0: Background Media Recovery process shutdown (strac)Managed Standby Recovery Canceled (strac)Completed: alter database recover...
备库丢失一个归档日志，导致主备库不能同步，在主库做一个增量备份，恢复到备库
gsforget321的博客
04-22 794
–主库上，查看已经应用在备库的最大LOG sequence# 号 select min(sequence#),max(sequence#) from v$archived_log where applied=‘YES’ and name =‘standby21’ MIN(SEQUENCE#) MAX(SEQUENCE#) 54397 67138 –主库上，查看顺序号...
data type must provide an itemsize解决办法
最新发布
05-20
这个错误通常出现在使用NumPy时，它表示数据类型没有指定正确的字节数。 解决办法可以尝试以下几种方法： 1. 检查数据类型是否正确。确保它与你的数据集相匹配。 2. 检查你的数据集是否为空。如果是空的，那么数据类型可能无法确定。 3. 尝试使用dtype参数显式指定数据类型，例如：np.array(my_data, dtype=np.float64)。 4. 如果你使用的是pandas DataFrame，尝试使用astype方法将列转换为正确的数据类型，例如：df['my_column'] = df['my_column'].astype(float)。 5. 如果以上方法都不起作用，那么可能需要重新安装NumPy。确保你使用的是最新版本，并尝试重新编译。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值