برطرف کردن گپ استندبای از اوراکل 10g با کمک incremental backup قابل انجام است البته به صورت کاملا دستی! انجام این کار نیازمند تعیین شماره scn، تهیه بکاپ از بانک اصلی(بصورت incremental)، ارسال فایل به سرور استندبای و …. بود از اوراکل 12cR1، بهبودهایی در این زمینه صورت پذیرفت و قسمتی از این عملیات به صورت خودکار قابل انجام است ولی کماکان نیاز بود با طی چند مرحله این کار انجام شود:

SQL>startup force mount

RMAN> RECOVER DATABASE FROM SERVICE prim NOREDO ;

RMAN> RESTORE STANDBY CONTROLFILE FROM SERVICE prim;

SQL>startup force;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

در اوراکل 18c، مجددا بهبودی در این زمینه رخ داد که تنها با اجرای دستور recover standby database from service tns، همه این عملیات به صورت خودکار انجام خواهد شد. در ادامه به شبیه سازی این مسئله خواهیم پرداخت.

در ابتدا وضیعت فعلی استندبای را نسبت به بانک اصلی بررسی می کنیم:

–in prim:

SQL> select max(sequence#),thread# from v$archived_log group by thread#;

MAX(SEQUENCE#)    THREAD#

————– ———-

           128          1

–in stb:

SQL> select max(sequence#),thread#,applied from gv$archived_log group by thread#,applied order by thread#;

MAX(SEQUENCE#)    THREAD# APPLIED

————– ———- ———

           128          1 YES

 

همانطور که قابل مشاهده است، استندبای هم شماره با بانک اصلی می باشد در ادامه برای شبیه سازی حالت gap، استندبای را از مدار خارج می کنیم:

 

SQL> shutdown abort

ORACLE instance shut down.

 

ارشیولاگی را در بانک اصلی ایجاد کرده و بلافاصله آن را حذف می کنیم:

–in prim:
alter system switch logfile;
alter system switch logfile;

[oracle@hkm6 ~]$ rm -rf /18c/arch/1_129_972120046.dbf

 

با استارت مجدد استندبای، خواهیم دید که استندبای منتظر ارشیو شماره 129 می باشد که در بانک اصلی حذف شده است:

in stb:

SQL> startup

Database opened.

SQL> alter database recover managed standby database;

PR00 (PID:23943): Media Recovery Waiting for T-1.S-129

PR00 (PID:23943): Fetching gap from T-1.S-129 to T-1.S-129

 

تا این مرحله، صرفا استندبای را برای پیش بردن سناریو، در حالت gap قرار دادیم. در ادامه تنها با اجرای سه دستور، این gap را برطرف خواهیم کرد:

1.خارج کردن استندبای از حالت ریکاور:

in stb:

SQL>  alter database recover managed standby database cancel;

Database altered.

2.دستور زیر، از اوراکل 18c ارائه شد که اجرای ان در محیط Rman، سبب رفع گپ ایجاد شده خواهد شد:

RMAN> recover standby database from service prim;

Starting recover at 26-APR-18

using target database control file instead of recovery catalog

Oracle instance started

Total System Global Area    4982831184 bytes

Fixed Size                     8906832 bytes

Variable Size               1174405120 bytes

Database Buffers            3791650816 bytes

Redo Buffers                   7868416 bytes

contents of Memory Script:

{

   restore standby controlfile from service  ‘prim’;

   alter database mount standby database;

}

executing Memory Script

Starting restore at 26-APR-18

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=743 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: using network backup set from service prim

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

output file name=/18c/base/oradata/USEFDB18/controlfile/control01.ctl

Finished restore at 26-APR-18

released channel: ORA_DISK_1

Statement processed

contents of Memory Script:

{

  recover database from service  ‘prim’;

}

executing Memory Script

Starting recover at 26-APR-18

Starting implicit crosscheck backup at 26-APR-18

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=743 device type=DISK

Crosschecked 12 objects

Finished implicit crosscheck backup at 26-APR-18

Starting implicit crosscheck copy at 26-APR-18

using channel ORA_DISK_1

Crosschecked 2 objects

Finished implicit crosscheck copy at 26-APR-18

searching for all files in the recovery area

cataloging files…

no files cataloged

using channel ORA_DISK_1

skipping datafile 5; already restored to SCN 1506388

skipping datafile 6; already restored to SCN 1506388

skipping datafile 8; already restored to SCN 1506388

skipping datafile 57; already restored to SCN 6799373

skipping datafile 58; already restored to SCN 6799373

skipping datafile 59; already restored to SCN 6799373

channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: using network backup set from service prim

destination for restore of datafile 00001: /18c/base/oradata/USEFDB18/datafile/o1_mf_system_fcvjfc9s_.dbf

channel ORA_DISK_1: restore complete, elapsed time: 00:00:15

channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: using network backup set from service prim

destination for restore of datafile 00003: /18c/base/oradata/USEFDB18/datafile/o1_mf_sysaux_fcvjh2k2_.dbf

channel ORA_DISK_1: restore complete, elapsed time: 00:00:16

channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: using network backup set from service prim

destination for restore of datafile 00004: /18c/base/oradata/USEFDB18/datafile/o1_mf_undotbs1_fcvjhvp9_.dbf

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: using network backup set from service prim

destination for restore of datafile 00007: /18c/base/oradata/USEFDB18/datafile/o1_mf_users_fcvjhwty_.dbf

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

starting media recovery

media recovery complete, elapsed time: 00:00:00

Finished recover at 26-APR-18

Finished recover at 26-APR-18

RMAN>

3.در نهایت، مجددا بانک را در حالت ریکاور قرار می دهیم:

 

SQL>  alter database recover managed standby database;

PR00 (PID:25374): Media Recovery Waiting for T-1.S-131 (in transit)

 

با مشاهده وضیعت استندبای، خواهیم دید که استندبای ارشیو 130 را هم اعمال کرده است:

 

SQL> select max(sequence#),thread#,applied from gv$archived_log where RESETLOGS_ID=972120046 group by thread#,applied order by thread#;

MAX(SEQUENCE#)    THREAD# APPLIED

————– ———- ———

           130          1 YES