Zaman zaman dataguardlarda production ortamlarda yaşanan archive kayıplarından dolayı senkronizasyonun durması problemiyle kaşılaşırız. Alında bu durumun birden fazla nedeni olabilmektedir. Production ortamda disk doluluğu gibi bir durumla karşılaşıldığında henüz apply olmamış bir logun silinmesi veya DG tarafı düzgün bir periyod ile kontrol edilmediğinde gap’ de kalmış olabileceği ve productiondaki archive’ ların ezilmesi gibi durumlarda DG’ ımız artık ilerleyemeyeceği için işlevselliğini bir ölçüde kaybetmiş oluyor. Bu problemi aşmanın yolu Dg ‘ nın kalmış olduğu noktayı tespit edip, o noktadan itibaren PROD ortamdan (incremantal) backup alıp DG ortamına recover etmekdir. Bahsettiğimiz işlemi adım adım nasıl yapabileceğimizden bahsedelim ;
Öncelikle Standby tarafında apply işlemini durdurup kalınan sequence noktasını tespit ediyoruz.
Bu noktayı tespit ederken aşağıdaki 3 sql’ den faydalanıyoruz. Bu 3 sql ‘den gelen değerlerden en düşük olan hangisi ise o noktayı dikkate alıyoruz.
— standby database
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> column CURRENT_SCN format 9999999999999999999
SQL> SELECT CURRENT_SCN FROM V$DATABASE; (1. Sql’ imiz)
CURRENT_SCN
———————
xxxxxxxxxxxxxx
SQL> select min(fhscn) current_scn from x$kcvfh; (2. Sql’ imiz)
CURRENT_SCN
———————
xxxxxxxxxxxxxx
SQL> select min (checkpoint_change#) CURRENT_SCN (3. Sql’ imiz)
from v$datafile_header where status in
(select status from v$tablespace where status <> ‘READ ONLY’) order by 1;
CURRENT_SCN
———————
xxxxxxxxxxxxxx
Bu 3 değerden hangisi küçük ise o nokta bizim backup almaya başlayacağımız noktayı ifade etmektedir. Bu noktayı yanlış belirler iseniz yani örneğin 10 nolu sequence’ den itibaren backup almaya gerekirken 11’ den itibaren backup alıp DG tarafında recover etmeye çalışırsanız sistem size hiçbir hata vermeyecek ve recover işlemi birkaç saniye içerisinde hatasız olarak tamamlanacaktır. Ancak yapılan işlem hatalı olduğundan doğru sequence noktasından başlamadığınız için DG tarafında değişen bir durum olmayacaktır. Dolayısıyla kalınan sequence değeri son derece önemlidir.
— Primary database’ de tespit ettiğimiz sequence değerinden itibaren backupımızı aşağıdaki gibi alıyoruz.
rman > BACKUP INCREMENTAL FROM SCN xxxxxxxxx DATABASE FORMAT ‘/u01/BACKUP/ForStandby_%U’ tag ‘FORSTANDBY’;
— Almış olduğumuz bu backupı scp veya ftp aracılığı ile DG tarafına taşıyoruz;
scp /u01/BACKUP/ForStandby * 10.10.10.10:/u02/BACKUP/.
— Standby tarafında, taşımış olduğumuz bu backupları rman aracılığı ile catalogluyoruz. (Rman’ e backupları tanıtıyoruz.)
RMAN> CATALOG START WITH ‘/u02/BACKUP/ForStandby………’;
RMAN> CATALOG START WITH ‘/u02/BACKUP/ForStandby………’;
— Standby databasede backupları DG tarafına catalogladıkdan sonra recover işlemini başlatıyoruz ;
RMAN> RECOVER DATABASE NOREDO;
Bu kısımda backupların cataloglanması sonrasında bir takım problemler yaşanabilir, burada cataloglama sonrasında;
crosscheck backup;
delete expired backup;
komutları ile expired olmuş olan backuplar silinebilir.
— Almış olduğumuz incremental backupımızı döndükden sonra DG’ımız için standby formatta yeni bir controlfile create edip bunuda DG tarafına taşıyoruz. (bu aşamada DG tarafındaki control file’ larımızı yeni almış olduğumuz standby formattaki yeni control file’ lerimiz ile ezeceğimizden dolayı DG ‘ i shutdown etmeyi unutmamalıyız.)
SQL> alter database create standby controlfile as ‘/home/oracle/stby_control.ctl’
$ scp /home/oracle/stby_control.ctl 10.10.10.10:/u02/oradata/PROD/control01.ctl
$ scp /home/oracle/stby_control.ctl 10.10.10.10:/u02/oradata/PROD/control02.ctl
$ scp /home/oracle/stby_control.ctl 10.10.10.10:/u02/oradata/PROD/control03.ctl
— Standby database’ de
RMAN> STARTUP MOUNT;
— Apply başlatmak için;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Bu işlemi parallel yapmak isterseniz (parallelik verirken cpu adedinizi dikkate almayı unutmayın)
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT PARALLEL 10;
— DG tarafında RFS ve MRP processlerinin çalışıp çalışmadığını kontrol etmek için;
SQL> select pid, process, status, sequence# from v$managed_standby ;
Bu şekilde DG’ ı kalmış olduğu noktadan bugüne kadar eşitlemiş oluyoruz ki, DG’ da apply başlattığımız da da backupın alındığı andan sonra çıkmış olan archivelogları istemeye başlayacaktır.
DG operasyonların da archive kayıpları disk size’ ı sıkıntılı olan kimi sistemlerde çok sık olarak yaşanmaktadır. Umarım faydalı olmuştur.
