Dataguard mimarisinde redo log taşıma hizmetlerinin iyileştirilmesi

Redo taşıması için ne kadar bant genişliği yeterlidir?

Dataguard 3 çeşit redo taşıma metodu sunmaktadır: ARCH, LGWR ASYNC ve 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 ürettiği redo verisini saniye başı byte miktarı olarak belirlemektir. Örneğin, yoğun zamanlarda kullandığınız uygulama 3MB/saniyelik 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 yoğunluktaki trafiği işleyebilmelidir. Network bant genişliği Megabits/second(Mbps) olarak tanımlanmakta ve 3 MB/sec network formulasyonuna 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 ise sınırları içerisinde kalmaktadır. Bunun yanında networkteki gecikmeler, latency, 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 alttadı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üde kullanıcı sorgularının ne kadar sürede yanıtlandığı noktasında faydalı bilgiler vermektedir. Bu görünümden elde edilecek bazı değerler 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 durumlarında 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. Oracle 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. Maksimum 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 dosyaları hem primary hemde standby veritabanına yazılmadan o redonun içindeki transactionlara COMMIT izni verilmez. Alternatif olarak COMMIT NOWAIT ile commitler henüz veritabanı katmanında commit olmamasına rağmen programa sanki COMMIT olmuş gibi 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. Redo gruplarında ek standby redo log üyeleri varsa fazla yazma oluşmaması için bu ek redo üyelerini redo gruplarından kaldırın.
• Depolama alanlarında single I/O isteklerinde en az 1Mb I/O rezerve edin. Bu noktada server donanım uzmanlarından destek alınabilir.

Network hizmetlerinin iyileştirilmesi

• 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)
• 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 network link 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 şu şekilde hesaplanır;

BDP = 1000Mbps X 0.25sec

BDP = 25000000Mbps / 8 = 3.125.000 bytes

Soket tampon büyüklüğü = 3.125.000 X 3 = 9.375.000

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

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

RECV_BUF_SIZE=9375000

SEND_BUF_SIZE=9375000

Data guard aktif değilse STANDBY sistemin listener.ora dosyasına 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 TXQUEUELEN 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 TXQUEUELEN değeri en az 10000 olmalıdır. İdeal değerler için Linux üreticilerinin tavsiyeleri alınabilir.

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ükleri artacaktır. Alttaki tablo MAA test laboratuvarında TCP soket tampon büyüklükleri ve network cihazındaki kuyruk büyüklüklerinde yapılan gelişimler sonrasında network iyileşmelerini göstermektedir.

Test Evresi	Test süresi (saniye)	Transfer olan veri miktarı	Ulaşılan network çıktısı (Megabits/saniye)	Yüzdesel değişim
İyileştirme öncesi	60	77.2 MB	10.8 Mbps
Network soket tampon büyüklüğünü 16K varsayılan değerinden 3XBDP değerine yükseltikten sonra	60	5.11 GB	731.0 Mbps	665% (İyileştirme öncesine gore performanstaki artış)
Üsteki ayarlama sonrasında ve donanım kuyruk uzunluklarını  100'den 1.000‘e yükseltikten sonra	60	6.55 GB	937.0 Mbps	28% iyileşme (önceki değere göre)