Category Archives: Administration

by Kamil TURKYILMAZ

RMAN Konfigurasyonu Hakkında Özet Bilgi

Aslında RMAN ile ilgili uzun bir süredir yazmak istiyordum notlarımı ancak toparlayabildim. Bu yazımda Rman’ in genel özelliklerinden, çalışma mantığından,hangi ihtiyaca göre nasıl kongiure edimesi gerektiğinden kısacası temel bir takım genel özelliklerin den bahsedeceğim. Bundan sonraki Rman ile ilgili yazılarımda ise spesifik olarak bazı özel (disaster durumlarında) ne yapmamız gerekeceğinden bahsetmeye çalışacağım. Öncelikle Rman’ in temel konfihurasyonların yer aldığı Show All komutu ile başlamak istedim. Show all’ daki her bir parametrenin ne olduğunu ifade ettikden sonra yine temel olması açısından database’ in backupının farklı şekillerde (full, datafile,sadece archivelog, .. vs) nasıl alabileceğimizden bahsetmek istiyorum. Show All’ ile parametreleri nasıl configure edebildiğimizi anlatırken olabildiğince en az iki örnek vermeye çalışacağım.

SHOW ALL ;
Continue reading →

by Kamil TURKYILMAZ

Physical Standby Database Üzerinde Switchover Operasyonu

Dataguard üzerinde zaman zaman switchover ile Dataguard ve Primary sunucularında rol değişimi yapmamız gerekebilir. Örneğin, Production ortamlarında yaşanacak disaster durumunda Dataguardları Primary olarak açmamız gerekecektir veya Primary olan sunucu üzerinde yapılacak olan (donanımsal bir işlem olabilir) bir çalışma nedeniyle eğer kesinti yapmamıyorsanız DG ‘ ı primary yaparak kullanıcılarının etkilenmeden gerekli işlemi yapıp, sonra tekrar bir switchover ile primary database’ i aktif edebilirsiniz. Bu operasyonu dataguard broker’ ı kullanarak da yapabilirsiniz. DGMGRL ile bu işlemin nasıl yapılacağından daha önce bahsetmiştim. Şimdi bu işlemleri manuel nasıl yapabileceğimizden bahsedelim;

— Öncelikle Primary database’ imizin switchover’ a işlemine hazır olup olmadığı kontrol ediyoruz;

SQL>select switchover_status from v$database ;
Switchover_status
—————–
TO STANDBY
Continue reading →

by Kamil TURKYILMAZ

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;
Continue reading →

by Kamil TURKYILMAZ

ASM Üzerindeki Standby Database’ in Incremantal Backup ile Tekrardan Senkronizasyonun Sağlanması

Bir önceki yazımda çeşitli sebeblerden dolayı DG geride kaldığında ve artık istemiş olduğu archive loga PROD tarafında ulaşamadığımızda, DG’ ı senkron hale getirmek için incremantal backupdan nasıl döneceğimizden bahsetmiştim. Şimdi aynı senaryoyu ASM üzerinde çalışan bir DG’ ımız olduğunda nasıl yapacağımızdan bahsedelim. ASM işin içine girdiğinde işler bir parça değişiyor ama mantık aynı aslında. Sırayla üstünden geçmeye çalışalım ;
Continue reading →

by Kamil TURKYILMAZ

Standby Database’ in Incremantal Backup ile Tekrardan Senkronizasyonun Sağlanması

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.
Continue reading →