DataGuard主备归档存在gap的处理办法

最新推荐文章于 2023-07-18 13:40:50 发布
最新推荐文章于 2023-07-18 13:40:50 发布
阅读量341 收藏 1
点赞数
文章标签： 数据库
说明：RAC搭建单库DG，在应用日志时报错
SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

警告日志文件中报错如下：
Sat Dec 10 09:37:02 2016
FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 106-107
 DBID 3777632382 branch 926682304
FAL[client]: All defined FAL servers have been attempted.
------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that's sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
------------------------------------------------------------

查看日志应用情况：
SQL> select sequence#,name, applied from v$archived_log;

 SEQUENCE# NAME                                   APPLIED
---------- ---------------------------------------------------------------------- ---------
    95 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_95.258.930049923      YES
       105 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_105.257.930049923      YES
    99 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_99.260.930050783      NO
    98 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_98.259.930050783      NO
       100 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_100.264.930050817      NO
       110 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_110.265.930050819      NO
       109 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_109.269.930050833      NO
       111 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_111.271.930050843      NO
       108 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_108.268.930050833      NO
       112 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_112.267.930050833      NO
       101 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_101.273.930051237      NO
       113 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_113.274.930051239      NO
       115 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_115.280.930098075      NO
       103 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_103.281.930098081      NO
       114 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_114.279.930098067      NO
       102 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_102.282.930098099      NO
       105 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_105.283.930169109      NO
       117 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_117.284.930169291      NO
       118 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_118.286.930169401      NO
       119 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_119.285.930169401      NO
       106 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_106.287.930169407      NO
       120 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_120.289.930184277      NO
       107 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_107.288.930184273      NO
       108 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_108.290.930184305      NO
       121 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_121.291.930184307      NO
       109 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_109.292.930215245      NO
       110 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_110.293.930215255      NO
       111 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_111.294.930215259      NO
       122 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_122.295.930215259      NO
       123 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_123.296.930215941      NO
       112 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_112.297.930216155      NO
       113 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_113.298.930216161      NO
       114 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_114.299.930216927      NO
       125 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_125.300.930216961      NO

34 rows selected.

SQL> select * from v$archive_gap;

   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
     1         106        107
     2          96         97

发现standby库接收日志不全，到主库中查看发现上面的4个归档日志也已经删除（standby库无法通过fal_server参数自动从主库拉缺少的日志），查看主库归档日志备份，
发现备份中存在上面的4个日志，可以再主库中恢复这4个归档然后手动传给standby库。

主库任一节点RMAN下执行下面的脚本：
run
{
  allocate channel c1 type disk;
  set archivelog destination to '/tmp/';
  restore archivelog from logseq 106 until logseq 107;
  release channel c1;
}

run
{
  allocate channel c1 type disk;
  set archivelog destination to '/tmp/';
  restore archivelog from logseq 96 until logseq 97 thread 2;
  release channel c1;
}

手动传输恢复的归档日志到standby数据库：
[oracle@node2 tmp]$ scp *.dbf 192.168.200.35:/tmp/


--register gap archivelog to standby

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '/tmp/1_106_926682304.dbf';

Database altered.

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '/tmp/1_107_926682304.dbf';

Database altered.

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '/tmp/2_96_926682304.dbf';
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/tmp/2_96_926682304.dbf'
*
ERROR at line 1:
ORA-16089: archive log has already been registered


SQL> select sequence#,name, applied from v$archived_log;

 SEQUENCE# NAME                                   APPLIED
---------- ---------------------------------------------------------------------- ---------
    95 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_95.258.930049923      YES
       105 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_105.257.930049923      YES
    99 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_99.260.930050783      NO
    98 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_98.259.930050783      NO
       100 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_100.264.930050817      NO
       110 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_110.265.930050819      NO
       109 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_109.269.930050833      NO
       111 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_111.271.930050843      NO
       108 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_108.268.930050833      NO
       112 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_112.267.930050833      NO
       101 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_101.273.930051237      NO
       113 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_113.274.930051239      NO
       115 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_115.280.930098075      NO
       103 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_103.281.930098081      NO
       114 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_114.279.930098067      NO
       102 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_102.282.930098099      NO
       105 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_105.283.930169109      NO
       117 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_117.284.930169291      NO
       118 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_118.286.930169401      NO
       119 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_119.285.930169401      NO
       106 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_106.287.930169407      NO
       120 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_120.289.930184277      NO
       107 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_107.288.930184273      NO
       108 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_108.290.930184305      NO
       121 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_121.291.930184307      NO
       109 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_109.292.930215245      NO
       110 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_110.293.930215255      NO
       111 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_111.294.930215259      NO
       122 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_122.295.930215259      NO
       123 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_123.296.930215941      NO
       112 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_112.297.930216155      NO
       113 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_113.298.930216161      NO
       114 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_114.299.930216927      NO
       125 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_125.300.930216961      NO
    97 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_97.302.930220527      NO
    96 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_96.301.930220527      NO
       104 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_104.303.930220539      NO
       106 /tmp/1_106_926682304.dbf                          NO
       107 /tmp/1_107_926682304.dbf                          NO
       116 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_116.304.930221649      NO

40 rows selected.

SQL> select * from v$archive_gap;

no rows selected

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

Database altered.


查看standby库日志，开始应用....
Sat Dec 10 11:00:35 2016
Warning: VKTM detected a time drift.
Time drifts can result in an unexpected behavior such as time-outs. Please check trace file for more details.
Sat Dec 10 11:02:26 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_97.302.930220527
Media Recovery Log /tmp/1_107_926682304.dbf
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_2_seq_98.259.930050783
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_1_seq_108.268.930050833
Sat Dec 10 11:03:26 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_2_seq_99.260.930050783
Sat Dec 10 11:03:53 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_1_seq_109.269.930050833
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_1_seq_110.265.930050819
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_1_seq_111.271.930050843
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_2_seq_100.264.930050817
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_2_seq_101.273.930051237
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_1_seq_112.267.930050833
Sat Dec 10 11:04:06 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_08/thread_1_seq_113.274.930051239
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_1_seq_114.279.930098067
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_2_seq_102.282.930098099
Sat Dec 10 11:05:52 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_2_seq_103.281.930098081
Sat Dec 10 11:06:30 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_1_seq_115.280.930098075
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_1_seq_116.304.930221649
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_104.303.930220539
Sat Dec 10 11:08:18 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_1_seq_117.284.930169291
Sat Dec 10 11:08:51 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_2_seq_105.283.930169109
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_2_seq_106.287.930169407
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_1_seq_118.286.930169401
Sat Dec 10 11:09:02 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_09/thread_1_seq_119.285.930169401
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_1_seq_120.289.930184277
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_107.288.930184273
Sat Dec 10 11:09:37 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_108.290.930184305
Sat Dec 10 11:10:19 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_1_seq_121.291.930184307
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_109.292.930215245
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_1_seq_122.295.930215259
Sat Dec 10 11:11:19 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_110.293.930215255
Sat Dec 10 11:11:57 2016
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_111.294.930215259
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_112.297.930216155
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_1_seq_123.296.930215941
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_1_seq_124.305.930221703
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_113.298.930216161
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_2_seq_114.299.930216927
Media Recovery Waiting for thread 2 sequence 115 (in transit)
Recovery of Online Redo Log: Thread 2 Group 14 Seq 115 Reading mem 0
  Mem# 0: +FRA/phydb/stbredo14.log
Media Recovery Log +FRA/phydb/archivelog/2016_12_10/thread_1_seq_125.300.930216961
Sat Dec 10 11:12:07 2016
Media Recovery Waiting for thread 1 sequence 126 (in transit)
Recovery of Online Redo Log: Thread 1 Group 10 Seq 126 Reading mem 0
  Mem# 0: +FRA/phydb/stbredo10.log


SQL> select sequence#,name, applied from v$archived_log;

 SEQUENCE# NAME                                   APPLIED
---------- ---------------------------------------------------------------------- ---------
    95 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_95.258.930049923      YES
       105 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_105.257.930049923      YES
    99 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_99.260.930050783      YES
    98 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_98.259.930050783      YES
       100 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_100.264.930050817      YES
       110 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_110.265.930050819      YES
       109 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_109.269.930050833      YES
       111 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_111.271.930050843      YES
       108 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_108.268.930050833      YES
       112 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_112.267.930050833      YES
       101 +FRA/phydb/archivelog/2016_12_08/thread_2_seq_101.273.930051237      YES
       113 +FRA/phydb/archivelog/2016_12_08/thread_1_seq_113.274.930051239      YES
       115 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_115.280.930098075      YES
       103 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_103.281.930098081      YES
       114 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_114.279.930098067      YES
       102 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_102.282.930098099      YES
       105 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_105.283.930169109      YES
       117 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_117.284.930169291      YES
       118 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_118.286.930169401      YES
       119 +FRA/phydb/archivelog/2016_12_09/thread_1_seq_119.285.930169401      YES
       106 +FRA/phydb/archivelog/2016_12_09/thread_2_seq_106.287.930169407      YES
       120 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_120.289.930184277      YES
       107 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_107.288.930184273      YES
       108 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_108.290.930184305      YES
       121 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_121.291.930184307      YES
       109 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_109.292.930215245      YES
       110 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_110.293.930215255      YES
       111 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_111.294.930215259      YES
       122 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_122.295.930215259      YES
       123 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_123.296.930215941      YES
       112 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_112.297.930216155      YES
       113 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_113.298.930216161      YES
       114 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_114.299.930216927      YES
       125 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_125.300.930216961      IN-MEMORY
    97 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_97.302.930220527      YES
    96 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_96.301.930220527      YES
       104 +FRA/phydb/archivelog/2016_12_10/thread_2_seq_104.303.930220539      YES
       106 /tmp/1_106_926682304.dbf                          YES
       107 /tmp/1_107_926682304.dbf                          YES
       116 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_116.304.930221649      YES
       124 +FRA/phydb/archivelog/2016_12_10/thread_1_seq_124.305.930221703      YES


SQL> alter database recover managed standby database cancel;                                       

Database altered.

SQL> alter database open read only;

Database altered.

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

Database altered.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30373263/viewspace-2130204/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30373263/viewspace-2130204/

csknt26844
关注
实战篇：Oracle DataGuard 出现 GAP 修复完整步骤
LuciferLiu_DBA
07-09 1万+
Oracle DataGuard 出现 GAP 如何修复？
Oracle dataguard 出现较大gap后的处理记录
清风弄影
08-30 897
因为归档机器上的历史归档日志没有做定期清除，导致dataguard因为磁盘空间问题导致很多日志没有应用，但是主机上面的归档日志已经删除，所以没法再磁盘清理后继续。 1.备份机器 sql>alter database recover managed standby database cancel; sql>select THREAD#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# from v$archived_log THREAD# SEQUENCE# FIR...
dataguard中的gap及修复方式(增量备份方式/手工传送注册方式)
My Technology Workstation
07-04 1470
一.概述: Gap定义及产生原理:Gap英文单词的意思就是缝隙的意思，dataguard中出现gap的原理是:源端传递一个archivelog到目标端之后会在目标数据库进行注册，当中间某个archivelog归档到目标端失败或者没有成功注册且后续的archivelog成功归档的话目标端在恢复过程中就会将中间的sequence定义为gap。举例: 1).在single to single
Dataguard-备机产生gap的解决方法
cuanfanli6122的博客
05-29 204
有时候因为网络或备份故障等原因，主机所产生的归档日志无法传到备机上，这个时候备机就产生了gap。对于这种情况，应该如何解决？需要注意的是，一旦产生gap，即使gap之后的archive log能正常传到standby库中，sta...
处理Dataguard日志传输gap一例
姚远OracleACE的博客
01-21 393
文章目录制造gap从主库进行增量SCN的备份在备库上恢复后续检查 制造gap 在主库上停止向备库传输日志 SQL> alter system set log_archive_dest_state_2=defer scope=memory; System altered. 在主库进行几次日志切换，并将切换的日志删除，在错误备库的错误日志中可以看到： Archived Log entry ...
dataguard 主备库出现gap
cuiyinyao6929的博客
05-21 277
问题描述： dataguard 主备库出现gap 15:03时刻，正在主库rman上删除已经被备库applied的归档，此时备库出现WAIT_FOR_GAP：select * from v$archive_gap;THR...
Dataguard GAP修复
zongzizz的博客
12-28 855
Dataguard GAP修复
ORACLE DATAGUARD中手工处理日志v$archive_GAP的方法
09-10
在9i版本之后，DataGuard引入了Fast Application Notification (FAL)特性，该特性大大简化了日志传输和应用的过程，通常情况下，FAL会自动处理丢失的日志，确保备用数据库与主数据库保持同步。 然而，在某些特殊...
Oracle11G数据库DataGuard灾备切换方案.pdf
10-02
GAP 是 DataGuard 中的一种情况，表示主库和备库之间的redo日志差异。可以使用以下 SQL 语句来检查主库当前的 REDO SEQUENCE： SELECT THREAD#, SEQUENCE# FROM V$THREAD; 然后，在备库上执行以下查询，确定查询...
adg搭建备库，归档缺失（GAP）
最新发布
qq_45420945的博客
07-18 929
Oracle DG (GAP)
DataGuard 中处理archive_gap的两种方法
08-01 1325
DataGuard 中处理archive gap的方法 2014年02月08日 14:49:52 阅读数：2373 DG 中处理archive gap的方法 ==================== 当Primary Database的某些日志没有成功发送到Standby Database， 这时候Standby DB上就会出现归档裂缝（Archive Gap）。   Oracle主...
DataGuard出现GAP的两种处理方法
weixin_40913898的博客
08-10 1248
DataGuard出现GAP的两种处理方法 DG GAP顾名思义就是：DG不同步，当备库不能接受到一个或多个主库的归档日志文件时候，就发生了GAP。 DG GAP主要分为两类情况： 主库归档日志存在，可以通过配置 Fetch Archive Log(FAL) 参数，自动解决归档GAP。 主库归档日志丢失，需要 人工干预 来修复： 第一种方式： 11G处理步骤： a.在主库上创建一个备库的控制文件 b.以备库的当前SCN号为起点，在主库上做一个增量备份 c.将增量备份拷贝到备库上 d.使用新的控制文件将备库启
Dataguard gap修复,增量恢复
sqlora的专栏
07-02 1223
Dataguard gap修复 https://blog.csdn.net/kiral07/article/details/87191787 https://www.2cto.com/database/201605/507685.html 1.首先来模拟Gap的产生 1.1.备库关闭： SYS@dgtest_s>shutdown immediate; 1.2.主库切...
手工消除dataguard的gap
迎寒的专栏
07-16 615
1.在备库查询有哪些日志丢失，没应用到备库  SQL> select * from V$ARCHIVE_GAP;    THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- --------------          1          9873        9876 我们可以看到9873到9876这四个归档日
10g物理standby：如何应用断档日志
cobraqing7177的博客
03-20 1168
主从库日志出现断档。问题的解决思路。[@more@]SQL> select * from v$archive_gap; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#---------- --...
dataguard ORA-16037: user requested cancel of managed recovery operation
cuanshao4773的博客
09-14 1122
今天用脚本检测到主库跟备库未同步，收到邮件如下，立刻登录到备库去查看，发现备库有大量的归档未应用 查询备库日志 tlog Errors in file /u01/app/oracle/...
dataguard备库出现GAP修复
weixin_33850890的博客
09-04 332
dataguard备库出现GAP修复 1. 产生原因 巡检发现备库的日志应用有滞后的情况 DGMGRL> show database sxcmpdg 'RecvQEntries'STANDBY_RECEIVE_QUEUE STATUS RESETLOGS_ID THREAD ...
oracle19c双机运维,Oracle 19C Data Guard基础运维-05Failovers (GAP)
weixin_39692830的博客
04-12 298
Oracle 19C Data Guard基础运维-05Failovers (GAP)原主库原备库Failovers新主库独立库192.168.31.90192.168.31.100192.168.31.100192.168.31.90cjcdbchendbchendbcjcdbFailover：Figure 9-4 Failover to a Standby DatabasePerforming...
Oracle 11g RAC到单机Dataguard主备切换详细步骤
"Oracle 11g DataGuard主备切换步骤详细指南" Oracle 11g DataGuard是一种高可用性和灾难恢复解决方案，它允许在主数据库和备用数据库之间实现快速且安全的切换，以确保业务连续性。以下是主备正确切换的详细步骤：...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值