Home / MAKALELER / Veri Tabanı / Standby Database’in Incremantal Backup ile Tekrardan Senkronize Edilmesi

Standby Database’in Incremantal Backup ile Tekrardan Senkronize Edilmesi

aman 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.

 

About Kamil Turkyilmaz

1979 Tokat/Zile doğumluyum. Yıldız Teknik Üniversitesi 1997 - 2001 mezunuyum ancak 1998 yılından itibaren IT sektöründe, 2000 yılından bu yanada Oracle üzerine çalışmaktayım. 2005 yılına kadar oracle database'i üzerine yazılmış olan kimi uygulamalara software support hizmeti, sonrasında ise oracle veritabanı yöneticiliği olmak üzere yaklaşık 12 yıldır sektör içerisindeyim. Oracle' ın hemen hemen tüm ürünlerinin kurulumu, konfigurasyonu, yönetimi konusundaki çalışmalarıma özel bir bankada oracle dba olarak devam etmekteyim. Aynı zamanda kimi bilişim sitelerinde yazarlık yapıyorum, bunun yanısıra bu alandaki deneyim ve tecrübelerimi daha fazla kullanıcıyla paylaşabilmek adına bir de oracle blog yazarıyım.

İlginizi Çekebilir

SQL Server ile Veri Şifreleme

Bilgi teknolojilerinde verinin güvenliği çok kritik bir öneme sahiptir. Önemli verileri korumak için ekstra bir …

Bir Cevap Yazın