Standby Database Nasıl Gerçek bir Test Ortamına Dönüştürülür

Hemen hemen her prod ortamın aslında bir test ortamı bulunuyor ancak kimi zaman test ortamlarındaki data büyüklüğü veya test ortamının bulunduğu sunucunun özelliklerinden dolayı test ortamında yapılan bir test PROD ortama implemente edildiğinde test ortamındaki ile benzer sonuçları veremeyebiliryor. Bu yüzden kimi zaman (DG’ ında bulunduğu sunucunun donanım özellikleri prod ile çoğu zaman aynı olamayabiliyor ancak en azından aynı data üzerinde işlem yapabilme şansını sağlıyor) gerçeğe daha yakın sonuçlar alabilmek adına DG ortamlarını test ortamı gibi kullanabilmemiz gerekebiliyor. Bu tarz durumlarda karşılaştığımız da DG’ ı nasıl test ortamına dönüştürebileceğimizden ve sonrasında tekrar nasıl DG yapabileceğimizden bahsetmek istiyorum;

— Öncelike standby database’ imizde flash_recovery_file_dest ve file_dest_size parametrelerimizin tanımlı olduğundan emin olmamız gerekiyor. BU parametreler database’ i flashback moda alabilmemiz için gerekiyor. Daha önce bu parametreler set edilmemişse aşağıdaki gibi set edebiliriz;

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=10G;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST=’c:\oracle\flash_recovery_area\disprod\’;

— standby database’ inde apply işlemi durdurulur;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

— database zaten mount modda olduğundan dolayı database flashback moda alınır;

alter database flashback on;

— bulunduğumuz noktayı belirlemek için restore point create ediyoruz (testimiz bittiğinde bu noktaya dönüyor olacağız) ;

CREATE RESTORE POINT before_study GUARANTEE FLASHBACK DATABASE;

— Oluşturduğumuz restore point noktasını aşağıdaki select ile görüyor olmamız gerekiyor.

SELECT * FROM V$RESTORE_POINT;

— Primary sistemde (standby de apply’ ı durdurduğumuz için) log transferini durduruyoruz ;

ALTER SYSTEM ARCHIVE LOG CURRENT;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

— Standby database’ imizi artık prod database’ miş gibi activate edebiliriz;

ALTER DATABASE ACTIVATE STANDBY DATABASE;
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
ALTER DATABASE OPEN;

— DG activate edildikden son kontrol etmemiz gereken nokta temp tablespace’ inin olup olmadığıdır. Temp tablespace’ i eğer yoksa bir tane oluşturulabilir.

CREATE TEMPORARY TABLESPACE TEMP1 TEMPFILE ‘c:\oracle\oradata\PROD\ temp01.dbf’ SIZE 2048M ;

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP1;
DROP TABLESPACE TEMP INCLUDING CONTENTS AND DATAFILES;

— Yukarıda yaptığımız işlemler sonrasında artık DG’ ın, normal bir production dan bir farkı kalmamış bulunuyor. Dolayısıyla test yapacak kullanıcılar tns’ lerinde gerekli düzenlemeyi yaptıkdan sonra bağlanıp tüm testlerini yapabileceklerdir. Ancak yapılan testler sonrasında tekrar DG kurmak, ayağa kaldırmak gerektiğinde problem yaşanmaması için dikkat edilmemesi gereken bazı iş kuralları bulunmaktadır. Bunlar ;

• Yapılacak olan test boyunca hiçbir archive log DG tarafına taşınmayacağından dolayı, PROD’ daki archive’ ların ezilmemesine dikkat edilmelidir. (Çoğu zaman proddan alınan rman backuplar sonrasında archive loglar silindiğinden dolayı buna dikkat edilmelidir)
• Yapılacak test işlemi sırasında, geriye dönebilmek için oracle DB_RECOVERY_FILE_DEST altına bazı file’ ler create etmeye başlayacaktır. Bu alanın size’ ına dikkat edilmelidir. Tabi bu alanının size’ ına dikkat ederken sunucunun diskinde de yeteri kadar yer olması gerektiğini hatırlatmama gerek yok diye düşünüyorum.

DG üzerindeki testlarimiz bitti ve artık tekrar DG’ ımıza kavuşmak istiyoruz. Yani yaptığımız tüm işlemleri geri alıp, mount modda DG’ ın aktif çalışmasını sağlamak istiyoruz. Bunu nasıl yapıyoruz;

— Standby database’ imizi aşağıdaki şekilde mount moda almakla başlıyoruz;

STARTUP MOUNT FORCE;

— İşlem öncesinde create ettiğimiz restore point noktamıza geri dönüyoruz;

FLASHBACK DATABASE TO RESTORE POINT before_study ;

— Database’ imizi physical database olacak şekilde convert ediyoruz;

ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

STARTUP MOUNT FORCE;

— Apply işlemini başlatıyoruz;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

DG tarafında yapacaklarımız sadece bu kadar, artık DG’ ımız hazır yapmamız gereken sadece bir adımımız kaldı, primary database’ de DEFER etmiş olduğumuz log_archive_dest_state_2 parametremizi tekrar enable yapmak;

— on Primary

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE scope=both;

Evet, hepsi bu kadar aslında, tüm bu işlemler sonrasında DG tarafında restore point noktasını drop etmeyi ve flashback modu off yapmayı unutmamanızı öneririm. Flashback operasyonları disk üzerinde ciddi alan kaplayan işlemlerdir.

— on standby

drop restore point before_STUDY;
alter database flashback off;

Be Sociable, Share!

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir


5 × = on