Oracle 11.2.0.2 Data Guard performansını genel olarak değerlendirmek

Oracle 11.2.0.2 Data Guard standby veritabanlarını yapıya ilave ettikten sonra birincil veritabanı performansını doğru şekilde değerlendirmek için,  aynı uygulama profili ve yüklemesiyle Dataguard yapılandırmasının öncesinin ve  sonrasının V$SYSMETRIC_SUMMARY  görünümünden ve AWR snapshotlarından alınacak istatistik geçmişleriyla kıyaslanması gerekmektedir.

Data Guard standby uygulaması öncesinde ve sonrasında uygulama profilini değerlendirmek için aşağıdaki istatistikler kıyaslanabilir:

·         İşlem başına fiziksel okuma

·         İşlem başına fiziksel yazma

·         İşlem başına CPU kullanımı

·         İşlem başına redo üretimi

Uygulama performansını değerlendirmek için aşağıdaki istatistikler kıyaslanabilir:

·         Saniye başı redo üretimi veya redo oranı

·         Saniye başı kullanıcı commit işlemi veya saniye başı işlem

·         Saniye başı veritabanı zamanı

·         İşlem başına yanıt süresi

·         SQL servisi yanıt süresi

Eğer her iki senaryo arasında uygulama profili değişmişse bu adil bir karşılaştırma olmayacaktır. Bu durumda testin yeniden yapılması gerekmekte ve buna göre iyileştirme işlemlerine başlanmalıdır.

Eğer uygulama profili benzerse ve birincil veritabanında çıktıdaki bir düşüş veya yanıt süresinde bir artış sebebiyle uygulama performansında değişmeler gözlemleniyorsa, o zaman aşağıdaki genel problem alanlarının değerlendirmeye alınması gerekecektir:

·         CPU kullanımı

Eğer yüksek yükleme(%90 üzerinde aşırı CPU kullanımı, paging veya swapping) yaşanıyorsa, Data Guard  ile devam etmeden önce sistemin iyileştirilmesi gerekmektedir. Bu amaçla, işletim sisteminden sistem kullanım istatistiklerini izlemek için V$OSSTAT görünümü veya $SYSMETRIC_HISTORY görünümü kullanılabilir.

·         Çok yüksek I/O bekleme olayları

Eğer , log yazıcı veya veritabanı yazıcı proseslerinden kaynaklanan çok yüksek I/O bekleme olayları yaşanıyorsa, o halde bu durum çıktı ve yanıt süresine olumsuz etki edecektir. I/O etkisini gözlemlemek için aşağıdaki bekleme olaylarının geçmiş verilerine bakmak gerekecektir:

– Log dosyası paralel yazmalar

– Log dosyası sıralı okumalar (sequential reads)

– Log dosyası paralel okumalar

– Veri dosyası paralel yazmalar

– Veri dosyası sıralı okumalar paralel yazmalar

SYNC taşımasıyla, “commit” işlemleri daha uzun zaman almaktadır, çünkü ilgili prosesler “commit” işleminin tamamlandığıyla ilgili LGWR prosesinden bir geri bildirim almadan önce, redo verisinin standby veritabanında geçerli durumda olmasını garantileme ihtiyacı duymaktadır.  Bir LGWR proses işlemi  aşağıdaki bekleme olaylarını içermektedir.

·         Log dosyası paralel yazma ( LGWR prosesi için lokal yazma)

·         SENDREQ’da LGWR beklemesi

Bu bekleme olayı şunları içermektedir:

– Paketi ağa koymak için gereken zaman

– Paketi standby veritabanına göndermek için gereken zaman

– RFS yazması veya RFS I/O bekleme olayı içeren standby redo log dosyasına standby yazması

– Birincil veritabanına alındı bilgisini geri iletmek için gereken süre (mesela tek bir yolculuğun gecikme süresi)

LGWR prosesi için daha uzun “commit “ süreleri daha uzun yanıt sürelerine ve daha düşük çıktılara sebebiyet verecektir, özellikle küçük süre hassasiyetindeki işlemlerde... Ancak, log yazıcı lokal yazmasını(Log Dosyası Paralel Yazma bekleme olayı) veya SENDREQ bekleme olayındaki LGWR beklemesini kapsayan çeşitli bileşenleri iyileştirerek yeterli bir gelişime ulaşılabilir.

Disk yazma I/O performansını iyileştirmek için (Log Dosyası Paralel Yazması veya RFS I/O), I/O bant genişliği arttırılmalıdır.  

Ağ zamanını azaltmak için:

·         Oracle Net gönderme ve alma tampon boyutları iyileştirilmelidir.

·         SDU boyutu 65535 olarak ayarlanmalıdır.

·         Eğer ağ bant genişliğinde doyma varsa bant genişliği arttırılmalıdır.

·         Ağ gecikmesini azaltmak için mümkünse yakın bir site bulunmalıdır.

ASYNC taşımasıyla,  LGWR prosesi mevcut log dosyasına “commit” kayıtının yazılmasından önce ağ sunucu prosesleri için hiç bir zaman beklemez. Ancak,  eğer ağ sunucu prosesleri geriye düşmüşse ve taşınması gereken redo verisi log tamponundan silinmişse, o zaman ağ sunucu prosesi online redo dosyasından okuma yapar. Bu da, daha fazla I/O içeriği ve muhtemelen  log yazıcı proses yazmaları(Log Yazma Paralel Yazma beklemesi) için daha uzun bekleme süresi anlamına gelmektedir. Eğer yeterli I/O bant genişliği tahsis edilmemişse, log dosyası paralel yazmaları ve log dosyası sıralı okumaları artacaktır ve böylece çıktı ve yanıt süresi performansı olumsuz etkilecektir.