Oracle 11g aktif standby veritabanında otomatik blok bozulması tamiri işlemi

Oracle 11g Active Data Guard özelliğinde gerçek zamanlı sorgu yeteneğinin yanında, Otomatik Blok Medya Düzeltme(Automatic Block Media Repair) özelliği ile daha yüksek erişilebilirlik yeteneği olduğu gözükmektedir. Primary veritabanındaki veri blok bozulmalarını standby siteden bu bozulan blokları elde etmek suretiyle ABMR arkaplan prosesi tarafından tamir edilebilmektedir.

Aynı fonksiyon, aktif standby sitedeki blok bozulmalarını primary siteden aynı şekilde bozulmamış blokların elde edilmesiyle tamir edilmesi yoluylada  kullanılabilmektedir. Aşağıdaki senaryoda bu durumu test edeceğiz.

Bu test senaryosunda kullanılmak üzere bir tablo oluşturup USERS tablespace içine atayacağız.

SQL> create table testtbl
tablespace users
as select * from hr.emp;

Table created.

DBMS_ROWID fonksiyonunu kullanarak bu tablonun kullandığı blokları belirliyoruz.

SQL> select * from
(select distinct dbms_rowid.rowid_block_number(rowid)
from testtbl)
where rownum < 6;

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------
12
13
14
15
16

Ardından bu bloklardan herhangi birisini bozuyoruz (senaryomda 13 numaralı bloğu bozuyorum, bu testi kesinlikle gerçek üretim veritabanınızda yapmayın!)

Eşzamanlı redo taşıma cevap süresinin izlenmesi

V$REDO_DEST_RESP_HISTOGRAM görünümü her bir redo taşıma hedefi için taşıma esnasındaki cevap süresi bilgilerini kaydeder. Bu cevap süresi verisi, eşzamanlı redo taşıma yöntemiyle gönderilen redo taşıma mesajlarında iyileştirme yapmak amacıyla kullanılmaktadır. Bilhassa birden fazla standby veritabanı olan ve primary veritabanı ile WAN bağlantısı yoluyla veri iletişimi yapan standby sunucularda bu değerin ölçümü proaktif iyileştirme için önem kazanmaktadır.

Her istikametteki veri, her bir cevap süresi bir satırdan olmak üzere dizi dizi satır serilerinden meydana gelir. Kayıt tutmayı kolaylaştırmak için 300 saniyeden düşük cevap süreleri en yakın tam sayıya yuvarlanır. 300 saniyeden büyük cevap süreleri ise 600,1200,2400 veya 9600 saniyeye yuvarlanır.

Sistem aktivite raporu(SAR) ile CPU kullanımını izleme

UNIX ve Linux sunucularda sar komutunu –u parametresi ile kullanarak CPU kullanımını izleyebiliriz. sar komutu ne kadar CPU kaynağının çıkmaza girdiğini veya kullanıldığını ile ilgili hızlı bir snapshot çeker. Sisteminiz yavaşladığı zaman bu komutu çalıştırarak pekçok darboğazın kaynağını gözlemleyebilirsiniz.

sar –u <nümerik_değer1> <nümerik_değer2>

nümerik_değer1: sar okumaları arasındaki saniye değeri

nümerik_değer2: sar komutunun kaç sefer çalıştırılacağını belirten değer

$ sar -u 10 5
Linux 2.4.21-37.0.0.1.4.ELhugemem (ap6188rt)    01/06/2011

10:48:24 PM      CPU    %user     %nice   %system   %iowait   %idle
10:48:34 PM       all       22.07      0.00     14.36         0.03         63.54
10:48:44 PM       all       16.70      0.00     13.93         0.17         69.20
10:48:54 PM       all        8.80       0.00       8.15         0.25         82.80
10:49:04 PM       all        2.52       0.00       3.55         0.00         93.92
10:49:14 PM       all        2.05       0.00       4.00         0.00         93.95
Average:             all       10.43      0.00       8.80         0.09         80.69

Shared server yapısında başlangıç dispatcher sayısını ayarlama

Instance başladığında işleme girecek dispatcher sayısının kontrolü DISPATCHER sıfatı ile kontrol edilir. Başlangıç dispatcher sayısını hesaplamak için alttaki formül kullanılabilir.

 dispatcher sayısı  =  maksimum eşzamanlı oturum sayısı / her bir dispatcher için bağlantı sayısı

• Örneğin, TCP/IP üzerinden 3,000 eşzamanlı bağlantı ve her bir proses için 1,000 bağlantının destekleneceği shared server mimarisinde en az 4 dispatcher ayarlanmalı ve spfile içerisinde alttaki gibi eklenmelidir. Performansa bağlı olarak dispatcher sayısı arttırılabilir.