ÇözümPark'a hoş geldiniz. Oturum Aç | Üye Ol
 
Ana Sayfa Makale Video Forum Resimler Dosyalar Etkinlik Hizmetlerimiz Biz Kimiz

Oracle

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.

 

Maksimum Uygunluk

Maksimum Performans

Maksimum Koruma

AFFIRM

NO AFFIRM

AFFIRM

SYNC

ASYNC

SYNC

DB_UNIQUE_NAME

DB_UNIQUE_NAME

DB_UNIQUE_NAME

 

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. 

  

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 1000 ‘e yükseltikten sonra

60

6.55 GB

937.0 Mbps

28% iyileşme (önceki değere göre)

 

 

 

 

 

 

 

 

 

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.

 

 

 

Olay İsmi

Proses

Tanımı

ARCH wait on ATTACH

ARCH

Bu bekleme olayı tüm arşivci prosesler tarafından yeni RFS bağlantıları meydana getirme süresindeki geçen süreyi izler.

ARCH wait on SENDREQ

ARCH

Bu bekleme olayı tüm arşivci prosesler tarafından arşiv dosyalarını standbya yazmakla birlikte lokal diskede yazma esnasında geçen süreyi izler.

ARCH wait on DETACH

ARCH

Bu bekleme olayı tüm arşivci prosesler tarafından RFS bağlantısını silme esnasında geçen süreyi izler.

LNS wait on ATTACH

LGWR

Bu bekleme olayı tüm LNS prosesleri tarafından  yeni bir RFS bağlantısı meydana getirme süresindeki geçen süreyi izler.

LNS wait on SENDREQ

LGWR

Bu bekleme olayı tüm LNS prosesleri tarafından alınan redoları diske yazmakla birlikte standby arşiv redo dosyalarını açmak ve kapatmak sırasında geçen süreyi izler.

LNS wait on DETACH

LGWR

Bu bekleme olayı tüm LNS prosesleri tarafından RFS bağlantısını silme sürecindeki geçen süreyi izler.

LGWR wait on LNS

LGWR

Bu bekleme olayı LNS prosesinden alınan mesajları beklerken LGWR prosesince geçen süreyi izler.

LNS wait on LGWR

LGWR

Bu bekleme olayı LGWR prosesinden alınan mesajları beklerken LNS prosesince geçen süreyi izler.

LGWR-LNS wait on channel

LGWR

Bu bekleme olayı  LGWR tarafından geçen zamanı veya mesajları almak için bekleyen LNS prosesleri tarafından geçen süreyi izler.

  

 

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

 

 

Olay İsmi

Proses

Tanım

Log File Sync

LGWR

Ön planın bir işlemi commitleme zamanından,  LGWR prosesinin önplana commit işleminin tamamlamasının kabulüne kadar geçen bekleme süresidir. Kullanıcı oturumu commit yaptığında oturumun redo bilgisi redo log dosyasını boşaltma ihtiyacı duyar.  Kullanıcı oturumu LGWR prosesini log belleğini redo log dosyasına yazmakla görevlendirir. LGWR yazmayı bitirdiğinde bunu kullanıcı oturumuna ilan eder.

Log File Parallel Write

LGWR

LGWR I/O ları için commit yazma işlemini tamamlamak için  geçen zamandır. Redo kayıtlarının parallel olarak yazılmasına rağmen diskteki en son I/O işlemine kadar parallel yazma tamamlanmaz.

DB File Sequential Read

Foreground

Veritabanında ardışık okuma olurken oturum bekler. Bu olay aynı zamanda kontrol dosyası ve dumping data dosyası başlıklarını yeniden inşa etmek için kullanılır ve veritabanı dosya başlıklarını elde eder.

 

 

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

 

Tarih : 12 Mart 2011 Cumartesi 22:37 Yayınlayan: Ugur INAL

Yorumlar

 

Ufuk TATLIDİL

Elinize sağlık.

Mart 13, 2011 01:45
Kimliksiz yorumlar seçilemez kılınmış durumdadır.

Yazar: Ugur INAL

http://uguroracle.blogspot.com

Bu Kategori

Hızlı aktarma