Oracle Dataguard Mimarisinde Redo Log Taşıma Hizmetlerinin İyileştirilmesi

Merhaba, bu makalemizde sizlere Oracle Dataguard mimarisinde Redo Log taşıma hizmetlerinin iyleştirmesini anlatacağım. 

Primary veritabanında uygun veri koruma modunun ayarlanması

Standby veritabanında redo boşluklarının olmaması için primary veritabanı üzerinde uygun veri koruma modunun seçimi gerekmektedir. Üç çeşit veri koruma modu vardır.

Maksimum uygunluk

Bu koruma modu primary veritabanının erişilebilirliğinde taviz vermeden en yüksek seviyede veri koruma seviyesini belirtir. İşlemler, herhangi bir çökmede geri kurtarmayı sağlayacak verinin online redo log dosyalarına yazılmadan ve bu redo log dosyalarının en azından bir standby veritabanına senkronize olmadan COMMIT işlemine izin vermez. Bu mod sıfır veri kaybı sağlar, ancak birkaç saniyelik düşmeler redo veri setlerinin standby veritabanına taşınmasını engellemez ve bu birkaç saniyelik düşmelerin olduğu zaman zarfında veri kaybı yaşanma ihtimali yüksektir.

Maksimum performans

Bu koruma modu primary veritabanının performansını etkilemden un yüksek seviyede veri koruma seviyesini belirtir. İşlemler, online redo log dosyasına yazılır yazılmaz COMMIT olur. Redo verisi daha sonra eşzamanlı olmadan standby veritabanına yazılır. Böylece bu mod aktifken, primary veritabanı eşzamanlı redo taşıması esnasındaki gecikmelerden kaynaklanan performans sıkıntısını yaşamaz. Bu mod varsayılan koruma modudur ve primary veritabanı performansı üzerinde etkisi sınırlıdır.

Maksimum koruma

Bu koruma modu primary veritabanı çöktüğü zaman sıfır veri kaybını sağlar. İşlem commit olmadan önce aynı maksimum uygunluk modunda olduğu gibi hem primary redo log dosyalarına yazılmalı hemde en az bir standby veritabanına yazılması gerekmektedir. Veri kaybının yaşanmaması eğer redo dosyalarını en az bir standby veritabanına yazamazsa primary veritabanı kendini kapatır, böylece veri kaybı ihtimalini ortadan kaldırır. En az 2 standby veritabanı kullanıldığı Dataguard mimarilerinde bu modun seçimi tavsiye edilir.

Primary veritabanında veri koruma modunu değiştirmek için aşağıdaki adımları izleyebilirsiniz.

1 - Aşağıdaki tablodan uygunluk, performans ve veri koruma isteklerinizi karşılayacak modu seçiniz.

2 - Redo taşıma hizmetinin en azından bir standby veritabanında etkinleştirildiğinden emin olun.

LOG_ARCHIVE_DEST_n başlangıç parametresi değeri yukardaki tablodaki en uygun mod için listelenen redo taşıma

değerlerini almalıdır.

LOG_ARCHIVE_DEST_2='SERVICE=orclprm ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE,

PRIMARY_ROLE) REOPEN=5 COMPRESSION=ENABLE DB_UNIQUE_NAME=orclprm'

Örneğin; yukardaki standby veritabanında parametre değeri redo taşıma hizmetinin eş zamanlı olmayacağını, redo logların arşivlendikten sonra standby veritabanına senkronize edileceğini, NOAFFIRM değeri ile kaynak veritabanında alınan redo dosyasının standby veritabanına yazılana kadar doğruluğunun sağlanmayacağını, böylece read-only standby veritabanlarında yapılan raporlamalarda bu verilerin işleme sokulmayacağını garantiye alır.

VALID_FOR değeri ise standby sunucu primary olarak rol değiştirdiği zaman kendisinin primary olduğunu ve bu durumda sadece online redo dosyası taşıma hizmeti sunacağını işaret eder.

REOPEN değeri ise primary ile arasındaki bağlantı bir şekilde koptuğunda ne kadar dakika sonra yeniden bağlantı denemesinin yapılması gerektiğini belirtir. Eğer compression etkin ise primary üzerinde akan redo verileri sıkıştırılmış olarak gelecek ve buda network bant genişliğinde rahatlama sağlayacaktır.

3 - DB_UNIQUE_NAME başlangıç parametresinin hem primary veritabanında hemde standby veritabanında servis

ismini işaret ettiğinden emin olun.

Primary veritabanında;

SQL> ALTER SYSTEM SET DB_UNIQUE_NAME='orclprm' SCOPE=SPFILE;

Standby veritabanında;

SQL> ALTER SYSTEM SET DB_UNIQUE_NAME='orclstdby' SCOPE=SPFILE;

4.      LOG_ARCHIVE_CONFIG başlangıç parametresinin hem primary hem standby sunucularda ilgili

DB_UNIQUE_NAME değerinin DG_CONFIG listesi içinde eklendiğinden emin olun.

Hem primary hemde standby veritabanlarında;

SQL> ALTER SYSTEM SET

2> LOG_ARCHIVE_CONFIG='DG_CONFIG=(orclprm,orclstdby)';

5.      Primary veritabanını kapatıp MOUNT modda tekrar başlatın.Eğer RAC kullanılırsa tüm instancelerı kapatın ve tek

bir instanceı MOUNT modda başlatın.

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

6.      Uygun veri koruma modunu etkinleştirin.Eğer RAC kullanıyorsanız durdurduğunuz instancelerı tekrar başlatın.

SQL> ALTER DATABASE

     2> SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY |  

          PERFORMANCE | PROTECTION};

7.      Primary veritabanını tekrar başlatın.

SQL> ALTER DATABASE OPEN;

8.      Primary veritabanının yeni modda çalıştığını kontrol ediniz.

SQL> SELECT PROTECTION_MODE FROM V$DATABASE;

Redo taşıması için ne kadar bant genişliği yeterli olacaktır?

Dataguard 3 çeşit redo taşıma metodu sunmaktadır: ARCH, LGWR ASYNC, LGWR SYNC

Dataguard yapılandırmalarının amacı redo verisinin uzak siteye veritabanında bir felaket durumunda en kısa zamanda ve en son güncel durumdan eksiksiz geri kurtarma hizmeti vermektir. Eğer gerekli yoğunluğu ele alabilecek yeterli bant genişliği mevcut değilse hiç bir iyileştirme hizmeti sonuç vermez. Ne kadar bant genişliği kullanılacak sorusuna cevap vermek için ise, önce primary veritabanından ne kadar redo yoğunluğu olduğunun incelenmesi gerekmektedir.

Bu yoğunluğun hesaplanması için en kolay yol,  veritabanının normal ve yoğun kullanıldığı zamanlarda AWR(Automatic Workload Repository) raporlarını toplamak ve primary veritabanının ürettiği redo verisini saniye başı byte miktarı olarak belirlemektir. Örneğin, yoğun zamanlarda kullandığınız uygulama 3MB/saniye lik redo verisi üretiyorsa, primary ve standby veritabanlarınız arasındaki network linki en az 3MB/saniye’lik network bant genişliğine sahip olmalı ve bu trafiği işleyebilmelidir. Network bant genişliği Megabits/second(Mbps) olarak tanımlanmakta ve 3 MB/sec de formulasyona göre 25.2 Mbps lik network çıktısına eşit olmaktadır. Bu miktarda yoğunlukta dolayısıyla 1.544 Mbps genişliğindeki T1/DS1 linkinin kapasitesini aşmakta, 44.7Mbps genişlikteki T3/DS3 linkinin sınırları içerisinde kalmaktadır. Bunun yanında networkteki gecikmeler, ISP kalitesi, paket düşmeleri ve link performansı ile ilgili diğer etkenlerde göz önünde bulundurulmalıdır. Bu noktada, redo log dosyalarını taşımak için günlük ne kadar bant ihtiyacı olacağı ve bununla beraber saat başı ne kadar ortalama,minimum ve maksimum Mbps gerekeceği alttaki sorgu sonucu elde edilebilir.

SELECT DT,
SUM(RB*8/3600000000*1.3) TOTAL_Mbps_REQ_FOR_A_DAY,
MIN(RB*8/3600000000*1.3) MIN_Mbps_REQ_FOR_AN_HOUR,
MAX(RB*8/3600000000*1.3) MAX_Mbps_REQ_FOR_AN_HOUR ,
AVG(RB*8/3600000000*1.3) AVG_Mbps_REQ_FOR_AN_HOUR
FROM
(
SELECT TRUNC (COMPLETION_TIME) DT,
TO_CHAR (COMPLETION_TIME,'HH24') HH,
SUM(BLOCKS*BLOCK_SIZE) RB
FROM
V$ARCHIVED_LOG
WHERE COMPLETION_TIME > SYSDATE-5
AND DEST_ID=1
GROUP BY TRUNC(COMPLETION_TIME),
TO_CHAR (COMPLETION_TIME, 'HH24')
)
GROUP BY DT;

AWR raporlarında yardımcı olacak bileşenler altatdır.

·         Redo volume – Bu rapor süresince oluşturulan redo miktarı

·         Transactions – Rapor için TPS

·         Redo writes – Rapor süresince redo yazma sayısı

Bunun yanında V$SYSMETRIC_HISTORY görünümü kullanıcı sorgularının ne kadar sürede yanıtlandığı noktasında faydalı bilgiler vermektedir. Bu görünümden elde edilecek bazı noktalar ise;

·         Response Time per Txn – Transcationlar için yanıtlama süresi

·         SQL Service Response Time – Kullanıcı çağrı başına yanıt süresi

·         Database Time Per Sec – DB Süresi / Geçen Süre

Network bant genişliği gereksinimi hesaplarken sonraki düşünce ise Data Guard koruma modu ve kullanılan taşıma hizmetidir. Örneğin, LGWR SYNC eşzamanlı taşıma redo verisi oluşturma oranlarını ele alırken yetersiz bant genişliği oluduğu durumlarda primary veritabanında performansta darboğazlara sebebiyet verecektir. LGWR ASYNC ise aksine geçici olarak network çıktısının maksimum sınırları aştığı  durumlarda bile primary veritabanı performansını etkilemeden online redo logları kullanarak tamponda redo oluşturmaya devam eder. ARCH moduda tampon olarak lokal arşiv log dosyalarını kullanarak aynı işlevi sağlar, ancak LGWR ASYNC’e göre daha fazla veri kaybı riski ortaya çıkarabilir. Primary ve standby arasında gerekli bant genişliği hesaplamasından sonra her taşıma modu için alttakileri uygulayabilirsiniz.

ARCH Redo Taşıması

·         ARCn proses sayısını artırmayı göz önünde bulundurun. Veritabanı oluşturulurken bu değer 2’dir.

LOG_ARCHIVE_MAX_PROCESSES başlangıç parametresi maksimum ARCn proses değerini işaret eder. Oracl 9i için

maksimum 10, Oracle 10g Release2 için ise maksimum 30 olabilir. Yüksek ARCn proses değeri network ağı

genişlediğinde veya  standby veritabanı kesintiye uğradığında kolayca arşiv dosyası sorunlarını çözmeye yardımcı

olur. Bunun yanında yüksek ARCn değeri, remote archiving parallism özelliğini desteklemektede yardımcı

olmaktadır.

·         MAX_CONNECTIONS başlangıç parametre değerini 2’ninüzerine çıkarın. Bu sayede arşiv logların transferi

hızlanacaktır. Makimum değeri 5’dir.

LGWR SYNC Redo Taşıması

·         NET_TIMEOUT değerini primary veritabanı performansında network kesintilerine etki etmemesi için düşürün.

Bu değer, primary veritabanındaki LGWR isteklerine cevap vermek için bekleyen Oracle Net Servislerininin LGWR

saniye değerini belirtir. Oracle 10g Release2 için varsayılan değer 180 saniye’dir. Oracle gereksiz yere standby

veritabanından bağlantının kesilmemesi için bu değerin en az 10 saniye olarak ayarlanmasını tavsiye eder. Bu

değerin yeterince kısa olması bant genişliğindeki rahatlama sürelerini azaltacağından potensiyel olarak veri

kayıpları meydana gelebilir.

·         LGWR SYNC kullanılırken redo hem primary hemde standby veritabanına yazılmadan o redonun içindeki

transactionlara COMMIT izin verilmez. Alternatif olarak COMMIT NOWAIT ile commitler henüz veritabanında

commit olmamasına rağmen programa geri döner ve böylece programda gecikmeler meydana gelmez. Bu yüzden

programlarda cevap süresinin optimizasyonunda transactionlarda COMMIT NOWAIT kullanmak performans

açısından önem kazanır.

Tüm Redo Taşımaları için tavsiyeler

·         Standby redo log dosyalarının ayrı fiziksel disklerde tutulduğundan emin olun.

·         Standby redo dosyalarını multiplex yapmayın. İlave standby redo log üyeler varsa ek yazmaları engellemek için bunları veritabanından kaldırın.

·         Depolama alanlarında tekli I/O isteklerinde en az 1Mb I/O rezerve edin. Bu noktada Stora Uzmanlarından destek alın.

Network hizmetlerinin iyileştirilmesi

· Oracle Net hizmetlerinde RECV_BUF_SIZE ve SEND_BUF_SIZE parametrelerinin BDP(Bandwidth Delay Product

değerinin 3 katına eşit olmasını sağlayın. Bu sayede network çıktısında büyük artışlar sağlanacaktır.

BDP değerini hesaplamak için Linkin bant genişliği ve network Round Trip Time(RTT) değerleri gerekmektedir. RTT değeri, primary veritabanından standby veritabanına network iletişiminde kullanılan seyahat süresidir ve ms(milisaniye) olarak hesaplanır.25ms RTT değerinde 1Gigabit network linkinde BDP değeri;

BDP = 1000Mbps X 0.25sec

BDP = 25000000Mbps / 8 = 3125000 bytes

Soket tampon büyüklüğü = 3125000 X 3 = 9375000

Soket tampon büyüklüğü hem işletim sistemi seviyesinde hemde Oracle net servisleri seviyesinde atanabilir. Bazı Linux işletim sistemi vcersitonlarında bu değerler olduğundan fazla olabilir.Bu  Kurumda bu değeri optimal seviyeye indirmeniz gerekmektedir.

Data Guard Broker servisinin kurulu olduğu STANDBY sistemlerde sqlnet.ora dosyasına alttaki ekleme yapılabilir.

RECV_BUF_SIZE=9375000

SEND_BUF_SIZE=9375000

Data guard aktif değilse STANDBY sistemin listener.ora dosyasında alttaki şekilde ekleme yapılabilir.

LISTENER=

(DESCRIPTION=

(ADDRESS=(PROTOCOL=tcp)

(HOST=linux2)(PORT=1521)

(SEND_BUF_SIZE=9375000)

(RECV_BUF_SIZE=9375000) ) )

… 

·         Oracle Net Session Data Unit(SDU)  boyutu olarak 32767 değerini atayın. Bu işlemi Data Guard Broker hizmeti

kullanıyorsanız hem primary hemde standby sistemlerdeki sqlnet.ora dosyasına alttaki gibi ekleyebilirsiniz.

DEFAULT_SDU_SIZE=32767

Eğer Data Guard Broker hizmeti kullanılmıyorsa hem primary hemde standby  sistemlerde listener.ora dosyasında ekleme yapılmalıdır. Altta örneği yer almaktadır.

…

(SID_LIST=

(SID_DESC=

(SDU=32767)

(GLOBAL_DBNAME=orcl.test.com)

(SID_NAME=orcl)

(ORACLE_HOME=/u01/app/oracle) ) )

…

·  Linuxlarda kuyruk büyüklüğünü kernel network alt sistemleri ve ethetnet kartı sürücüsü arasındada

düzenleyebiliriz. Herhangi bir kuyruk tekrardan boyutlandırılabilir, böylece local tampon aşırı yüklemeleri

sebebiyle kayıplar meydana gelmez. Bu yüzden yüksek bant genişliğindeki networklerde etkili iyileştirme yapmak

için kuyruk büyüklüklerinin mevcut network bağlantımıza uygun olduğundan emin olmamız gerekmektedir. Kuyruk

büyüklükleri için Linux’ta 2 kuyruk tipi önemlidir, arayüz iletim kuyruğu ve network alım kuyruğu. ifconfig ile

gönderim tarafında TXQUEUELENGTH arayüzü seçeneğini artırın, alım tarafında ise NET_DEV_MAX_BACKLOG kernel

parametre değerini artırın. 100ms latency ye sahip 1 gigabitlik network için bir örnek altta yer almaktadır.Bu

şartlarda network için TXQUEUELENGTH değeri en az 10000 olmalıdır. İdeal değerler için Linux üreticilerinin

tavsiyeleri alınmalıdır.

echo 20000 > /proc/sys/net/core/netdev_max_backlog

echo 1 > /proc/sys/net/ipv4/route/flush

ifconfig eth0 txqueuelen 10000

Bu sayede ilişkili network arayüzlerinde alım ve gönderim kuyruk büyüklüğü artacaktır. 

Oracle Net servisinde TCP_NODELAY değerinin “yes” olarak ayarlandığından emin olun(bu varsayılan değerdir eğer değiştirilmediyse kurulumda veya sonrasında)

Data Guarda bağlı bekleme olayları

Primary veritabanından standby veritabanına redo gönderirken ayrılan zaman iki ana bölüme ayrılır, networkun bir ucundan diğer ucuna geçerken zaman ve standby sunucu üzerinde diske yazarken geçen zaman. I/O olurken geçen zaman esnasında primary veritabanında sağlanan toplam zamanı ele geçiren bekleme olayları standby üzerinde izlenebilir.

Primary veritabanınından standby veritabanına ARCH veya LGWR prosesleri ile redo gönderirken meydana gelen bekleme olayları altta yer almaktadır. Bu veriler primary veritabanından elde edilir.

Bunun yanında primary veritabanında izlenmesi gereken önemli I/O olayları ise altta yer almaktadır.

Alttaki sorgu fiziksel standby veritabanındaki I/O bekleme olaylarını listeler.

SQL> SELECT EVENT, TOTAL_WAITS,

     ROUND(TIME_WAITED/100) "TIME(S)",

     AVERAGE_WAIT*10 "AVG(MS)",

     TO_CHAR(SYSDATE, 'DD-MON-YYYY HH:MI:SS') TIME

                          FROM V$SYSTEM_EVENT