Merhaba arkadaşlar standby veritabanımız da GAP oluştugun da ve elimizde standby’a işleyecek archiveloglar olmadıgı zaman,bunun çözümü olarak production veritabanından incremental bir rman backup alır standby veritabanına işleriz.Bu şekilde iki veritabanını da senkron tutmuş oluruz.Bu senaryoyu örnek üzerinde anlatacak olursak.
1.)Production ve standby veritabanın da archivelog sayısına bakarak archivelog sayısı farklılıklarını görebiliriz.
Production

archive log list;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     48
Next log sequence to archive   53
Current log sequence	       53

Standby

archive log list;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     48
Next log sequence to archive   0
Current log sequence	       50


2.)Production veya standby veritabanında işleme(applied) drurumlarına baktıgımızda da anormallik oldugunu anlayabiliriz.

SELECT sequence#, first_time, next_time, applied
FROM   v$archived_log
ORDER BY sequence#;

SEQUENCE# FIRST_TIM NEXT_TIME APPLIED
———- ——— ——— ———
32 16-JAN-14 16-JAN-14 YES
33 16-JAN-14 16-JAN-14 YES
34 16-JAN-14 16-JAN-14 YES
35 16-JAN-14 16-JAN-14 YES
36 16-JAN-14 16-JAN-14 YES
37 16-JAN-14 16-JAN-14 YES
41 16-JAN-14 16-JAN-14 NO
42 16-JAN-14 16-JAN-14 NO
43 16-JAN-14 16-JAN-14 NO
44 16-JAN-14 16-JAN-14 NO
45 16-JAN-14 16-JAN-14 NO
46 16-JAN-14 16-JAN-14 NO
47 16-JAN-14 16-JAN-14 NO
48 16-JAN-14 16-JAN-14 NO
49 16-JAN-14 16-JAN-14 NO
50 16-JAN-14 16-JAN-14 NO
51 16-JAN-14 16-JAN-14 NO
52 16-JAN-14 16-JAN-14 NO

3.)Production veritabanının SCN numarasına bakarız.

SELECT current_scn FROM v$database;

CURRENT_SCN
———–
1069047

4.)Standby veritabanının SCN numarasına bakarız.

col SCN format 999999999999

SELECT MIN (scn) SCN
FROM (SELECT MIN (current_scn) scn FROM gv$database
UNION
SELECT MIN (checkpoint_change#) scn FROM gv$datafile);

CURRENT_SCN
———–
1066261

5.)Standby veritabanında apply işlemini durdururuz ve data sonra stand by veritabanını kapatırız.

alter database recover managed standby database cancel;
shutdown immediate;

6.)SCN numaralarına baktıktan sonra production veritabanında standby veritabanı’nın SCN numarasına göre incremental yedek alırız.Daha sonra aldıgımız yedegi standby veritabanı sunucusuna göndeririz.

run
{
allocate channel t1 type disk;
allocate channel t2 type disk;
backup incremental from scn 1066261 database FORMAT  '/u01/app/oracle/rman/Backup_%T_%d_%I_%s.rman';
release channel t1;
release channel t2;
}
scp /u01/app/oracle/rman/* oracle@192.168.1.126:/u01/app/oracle/rman/

7.)Yeni bir yedek aldıgımız ve bu yedegi standby veritabanının görmesi için.Production veritabanın da standby veritabanı için control file alır ve bunu da standby veritabanı sunucusuna göndeririz.

alter database create standby controlfile as '/u01/app/oracle/rman/standby_controlfile.ctl';
scp /u01/app/oracle/rman/standby_controlfile.ctl oracle@192.168.1.126:/u01/app/oracle/rman/

8.)Standby veritabanını nomount modda açar daha sonra control file’lerin yerini ögreniriz.

startup nomount;
show parameter control_files

NAME TYPE VALUE
——————– —————- ———–
control_files string /u01/app/oracle/oradata/ORCLSTBY/control01.ctl, /u01/app/oracle/fast_recovery_area/ORCLSTBY/control02.ctl

9.)Production sistemden yeni gönderidigimiz control file’lerin eski control file’leri ezmesi için yeni control file’la eskisini ezeriz.

cp /u01/app/oracle/rman/standby_controlfile.ctl /u01/app/oracle/oradata/ORCLSTBY/control01.ctl
cp /u01/app/oracle/rman/standby_controlfile.ctl /u01/app/oracle/fast_recovery_area/ORCLSTBY/control02.ctl

10.)Standby veritabanını mount modda açarız.

alter database mount standby database;

11.)Standby makinede rman’e baglanır,aldıgımız yedegi tanıması için catalog komutunu çalıştırırız.

rman target /
catalog start with '/u01/app/oracle/rman';

12.)Standby veritabanımızı kurtarmak için recover komutunu çalıştırırız.

run
{
allocate channel t1 type disk;
allocate channel t2 type disk;
recover database noredo;
release channel t1;
release channel t2;
}

Not : Incremental yedek recover işlemi tamamlandığında veritabanı bir sonraki arşiv dosyasını arayacaktır. Ve kurtarma işlemi gerekli arşiv dosyasını bulamadığını belirten ORA-00334 hatası ile sonlanır. ORA-00334  hatası ile belirtilen arşiv primary veritabanında biz incremental yedek aldıktan sonra oluşturulan veya oluşacak olan arşiv dosyasıdır. Artık standby veritabanımızda RMAN den çıkıp apply işlemini başlatabiliriz.

13.)Standby tarafda apply servisini başlatırız.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

İkinci Yöntem

Bazı durumlarda archivelog yedeği alınmış ve silinmiş oluyor.
Bu senaryoda standby da GAP oluşmuşsa incremental yedek ile uğraşmayıp archivelog ları döndermemizde bir yöntemdir. Burada dikkat edilmesi gerekenler döneceğimiz  archivelog ların yedeğimizde bulunması ve sayısıdır.

Eksik olan archivelog ları aşağıdaki gibi bulabiliriz.

 SELECT high.thread#, "LowGap#", "HighGap#"
 FROM (  SELECT thread#, MIN (sequence#) - 1 "HighGap#"
           FROM (SELECT a.thread#, a.sequence#
                   FROM (SELECT * FROM v$archived_log) a,
                        (  SELECT thread#, MAX (next_change#) gap1
                             FROM v$log_history
                         GROUP BY thread#) b
                  WHERE a.thread# = b.thread# AND a.next_change# > gap1)
       GROUP BY thread#) high,
      (  SELECT thread#, MIN (sequence#) "LowGap#"
           FROM (SELECT thread#, sequence#
                   FROM v$log_history, v$datafile
                  WHERE checkpoint_change# <= next_change#
                        AND checkpoint_change# >= first_change#)
       GROUP BY thread#) low
WHERE low.thread# = high.thread#;

   THREAD#    LowGap#   HighGap#
---------- ---------- ----------
         1     118685     118686
         2     122449     122450

Eksik olan archivelog yedeklerimizde var mı kontrol ederiz?

RMAN> LIST ARCHIVELOG FROM SEQUENCE 118685;

List of Archived Log Copies for database with db_unique_name EXAPROD
=====================================================================

Key     Thrd Seq     S Low Time 
------- ---- ------- - ---------
643472  1    118685  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118685.48263.982232201

643475  1    118686  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118686.21772.982232589

643481  1    118687  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118687.34893.982233211

643483  1    118688  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118688.18700.982233485

643491  1    118689  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118689.54553.982233945

643494  1    118690  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118690.45040.982234421

643500  1    118691  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118691.30775.982234905

643503  1    118692  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118692.32647.982235347

643518  1    118693  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118693.16482.982235501

643519  1    118694  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118694.50189.982235507

643548  1    118695  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118695.1504.982236027

643551  1    118696  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118696.30917.982236535

643557  1    118697  A 23-JUL-18
        Name: +RECOC1/exaprod/archivelog/2018_07_23/thread_1_seq_118697.32072.982236983

Yedeğimizden archivelog’u restore ederiz.

RESTORE archivelog from sequence 118685 until sequence 118686;

Yararlı olması Dilegiyle …
Yazar : Mustafa Bektaş Tepe

1,974 total views, 2 views today