Oracle ASM Cluster Dosya Sistemi (ACFS)

ASM Cluster Dosya Sistemi ilk olarak Oracle 11.2.0.1 sürümü ile Linux sistemler üzerinde desteklenecek şekilde hizmete girmiş, Oracle 11.2.0.2 sürümü ile Solaris, AIX,HP-UX ve Windows platformlarınada bu destek hizmete girmektedir. Oracle 11.2.0.2 sürümü ile ACFS yapısına replikasyon, etiketleme, şifreleme ve realm tabanlı güvenlik özellikleride ilave edilmiştir.

ACFS sadece ASM volumleri desteklemektedir, ancak ASMLib sürücüleri ile kullanılamaz ve fdisk gibi formatlama araçları ile bu ACFS volumleri formatlanmamalıdır. ACFS, Oracle external binary veri dosyaları (LOB dosyalar ve BFile gibi), external dizinler, Oracle veritabanı home dizin dosyaları, izleme dosyaları gibi çeşitli paylaşılabilir dosyalara senkronize erişimi desteklemektedir. ACFS üzerinde Oracle’nın desteklemediği dosyalar, ASM diskgrupları bünyesinde tutulan kontrol dosyaları, SPFILE dosyaları, redo log dosyaları, arşiv log dosyaları,clusterware dosyaları(OCR ve voting dosyaları) ve veri dosyalarıdır.

Standby üzerinde backup retention ilkesinin değiştirilmesi

Standby veritabanı oluşturulduğu anda yedek alıkoyma(retention) ilkesini değiştirmek mümkün olmamaktadır. Standby sunucu üzerindeki disk alanı yetersiz duruma geldiğinde veya diğer başka kısıtlamalar sebebiyle, primart veritabanından yedek alıkoyma ilkesinin değiştirilme ihtiyacı duyulabilmektedir. Bu değişiklik işlemi  esnasında ise aşağıdaki hata mesajı ile karşılaşılmaktadır.

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 days;

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of configure command at 08/18/2011 14:42:35

RMAN-05021: this configuration cannot be changed for a BACKUP or STANDBY control file

Yedekleme alıkoyma ilkesinin –eğer mümkünse- değiştirmenin en kolay yolu; bir switchover işlemi(standby veritabanını primary yapmak), ardından alıkoyma ilkesini değiştirmek ve sonrada orjinal primary veritabanına bir switchover işlemi yapmaktır. Ancak, bu her sefer mümkün olmamaktadır, özellikle dataguard yapılandırması asimetrik ise ve standby sistem daha çok bir felaketten geri kurtarma senaryosu için “veri koruma” modunda kullanılmaktaysa...

RMAN raporlaması

Her firma için en değerli nokta verilerdir ve en iddialı iş ise bir felaket anında bu verilerin en kısa sürede herhangi bir kayıp yaşanmadan sisteme geri yüklenmesidir. Pek çok durumda veritabanı yöneticileri hangi veri dosyalarının yedeğinin alınmasının gerektiğini bilmeden ve hangi veri dosyalarının yedeklendiğini bilmeden eksik geri kurtarma işlemi yapmaktadırlar. Veritabanının etkili olarak yedeklendiğinin ve gerektiği zamanda da başarılı şekilde geri yükleme yapılacağından emin olunması gerekmektedir. RMAN raporlaması, başarılı geri yükleme için veritabanı yedeklerini belirlemede en etkili ve en kolay yolu sağlamaktadır.

Genellikle, bir katalog görünümü(view) tüm veritabanlarının metadatasını içermektedir ve kullanışlı yedek bilgisini alabilmek için komplike bir sorgu yazılması gerekmektedir. Ancak, RMAN raporlaması ile LIST ve REPORT komutlarını kullanarak aynı bilgiler daha kolay yoldan elde edilebilmektedir.  RMAN raporlaması, Oracle sürümleri arttıkça gelişme göstermekte ve artık hangi veri dosyalarının yedeğinin alınmadığını veya başarılı bir geri yükleme için hangi yedekler gerekecektir gibi pek çok sorunun cevabını belirlemede oldukça yararlı olmaktadır. 

RMAN raporlamasını verimli kullanarak, nelerin yedeklendiği ile ilgili tereddütlü durumların üstesinden gelinmekte ve eksik geri kurtarma gibi can sıkıcı durumlardan kurtulunabilmektedir. Yedekleme ve geri kurtarma stratejesinin bir parçası olarak, bu raporlar aşağıdaki durumları tespit etmek amacıyla belirli periyotlarla çalıştırılmalıdır.

1) Neyin yedeğinin alındığını gözlemlemek.
2) Hangi veri dosyalarının yedeğinin alınması gerekmekte veya güncel olarak hangi veri dosyasının yedeği alınmamış.
3) Bir problem meydana geldiğinde RMAN hangi yedeği kullanarak geri kurtarma yapabilecek.
4) RMAN görevlerinin geçmiş bilgisinin gözlemlenmesi

Oracle 11.2 Grid mimarisinde RAC düğümlere ilave SCAN listener ekleme

Geçenlerde test ortamda yapılandırdığım Oracle11gR2 grid yapılandırması aşağıdaki loglarda görüldüğü gibi sadece tek bir SCAN listener ile tamamlandı. Oracle 11.2 RAC yapılandırması iki düğümden(rac01 ve rac02) oluşan bir test platformunda yapıldı. Bu yazıda Oracle 11.2 Grid ortamında RAC düğümlere nasıl ilave iki SCAN listener daha eklenecek, onu inceleyeceğiz.

[grid@rac01 grid]$ srvctl config scan
SCAN name: rac-scan, Network: 1/192.168.38.0/255.255.255.0/eth2
SCAN VIP name: scan1, IP: /rac-scan.bugra.com/192.168.67.192

[grid@rac01 grid]$ srvctl config scan_listener
SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521

[grid@rac01 grid]$ ping rac-scan.bugra.com
PING rac-scan.bugra.com(192.168.67.193) 56(84) bytes of data.
From rac01.test.ant(192.168.38.50) icmp_seq=2 Destination Host Unreachable
From rac01.test.ant(192.168.38.50) icmp_seq=3 Destination Host Unreachable
From rac01.test.ant(192.168.38.50) icmp_seq=4 Destination Host Unreachable

— rac-scan.bugra.com ping istatistikleri —

6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5000ms
, pipe 3

Dataguard ortamında RMAN silme(deletion) ilkesinin yapılandırılması

Dataguard ortamında RMAN arşivlog silme(deletion) ilkesini tek bir merkez noktadan kontrol etmek için aşağıdaki adımlar izleyenebilir.

“Archivelog deletion” ilkesinin yapılandırılması

APPLIED ON STANDBY – Zorunlu standby olarak belirlenen standby sunucusu üzerinde uygulanan arşivlenmiş logları silmek üzere flash recovery alanını etkinleştirir.

NONE – Üçüncü derece cihazlara yedeklenen ve yapılandırılmış backup retention ilkesina bağlı olarak geçerliliğini yitirmiş arşivlenmiş logları silmek üzere flash recovery alanını etkinleştirir. Bu varsayılan ayardır.

CLEAR – Silme ilkesini temizler ve konfigürasyonu varsayılan değere döndürür.