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
Ağustos 8th, 2014 on 15:11
Merhabalar Mustafa,
catalog’a almış olduğumuz incremental backup’ı recover etmek için RECOVER DATABASE komutunu kullanmışsın. Bir çok anlatılan dökümanda bu işlem RECOVER DATABASE NOREDO şeklinde tamamlanmış farkı nedir. Bu işlemden sonra standby redolog file’ı yeniden create etmemiz gerekir mi ? NOREDO’yu kullanmassak RECOVER DATABASE sonrası oracle bu işlemleri otomatik yaparmı. clear logfile ve add standby logfile.
Teşekkürler.
Eylül 1st, 2014 on 20:10
Merhabalar,
Noredo online redo log dosyalarının yedeği alınmadıysa ya da kaybolduysa RECOVER DATABASE komudu ile birlikte kullanabiliriz. Eğer NOREDO komutunu kullanmazsa RMAN incremental backupları kullanarak restore işlemi yaptıktan sonra online redo log dosyalarını arayacaktır. Online Redo log dosyalarını bulamadğı zaman ise RMAN hata verecektir.
Yani yukarıda ki gibi standby da bir gap oluşmuşsa norede kullanmamıza çok da gerek yok incremental backup alıp işledikten sonra online redo log dosyasını recover etmeye gerek yok kendisi zaten düzelecektir.Tek farkı recocer database dedigimiz zaman en sonda bi hata vermesi.