Anasayfa » Oracle 11g RAC Performansı İzleme ve İyileştirme Teknikleri

Makaleyi Paylaş

Oracle

Oracle 11g RAC Performansı İzleme ve İyileştirme Teknikleri

 

Oracle 11g RAC veritabanı sisteminde iki önemli servis vardır. Bunlar  Global Cache Service (GCS) ve Global Enqueue Service (GES) dir. Bu ikisi temelde arkaplan proseslerinin koleksiyonudur. Her iki proses birlikte toplam “cache fusion” prosesini, kaynak transferlerini ve instancelar üzerinden kaynak tırmanmasını kapsar ve yönetir. Aşağıdaki şekilde yer alan “shared cache” kısmı, aslında tüm düğümlerde paylaşılan ortak ön bellektir ve kısaca “cache fusion” diye adlandırılır.

 

 

image001

 

Global Kaynak Dizini (Global Resource Directory)

 

GES ve GCS prosesleri beraberce, kaynak ve kuyruğa ekleme bilgilerini kaydetmek için Global Kaynak Dizinini(GRD) oluştururlar. GRD, bellek içinde yer alır ve tüm instanceler üzerinde saklanır. Her instance dizinin bir parçasını yönetir.Bu dağıtık sadelik, RAC’ın fault tolerance yapısı için anahtar noktayı oluşturmaktadır.

 

 

Global Kaynak Dizini (GRD), veri bloklarının mevcut durumunu kaydeden ve saklayan dahili bir veritabanıdır. Bir blok, bulunduğu instance içindeki lokal bellekten diğer instance’ların belleğine transfer olur olmaz GRD güncellenir. GRD içinde aşağıdaki kaynak bilgileri yer almaktadır.

Sponsor

 

 

* Veri blok tanımlıyıcıları (DBI)

* En güncel versiyon bilgisinin lokasyonu

* Veri blok modları (N)Null, (S)Shared, (X)Exclusive

* Her bir instance tarafından tutulan veri bloklarının rolleri(lokal veya global)

* Küme içindeki çoklu düğümler üzerindeki ön bellekler

 

 

Global Cache Service (LMSx)

 

 

GCS veri bloklarının lokasyonunu, mod ve rol durumları ile birlikte tüm instance’ların erişim haklarını izler. Veri bloğunun mevcut versiyonu bir instance’ın ön belleğinde yer alırken ve bu esnada diğer bir instance o bloğu değiştirmek için talepte bulunursa, Oracle,GCS prosesini bellek uyumluluğu için kullanmaktadır. GCS aynı zamanda blokları diğer instance’dan okumak içinde kullanılır.

 

Ayrıcalıklı kaynakların ilk okumasını takiben tekil RAC instance içinde çalışan çoklu işlemler, bloğu uzunca süre lokal bellek dışına transfer yapmadan GCS ilişkisi olmaksızın veri blok setlerine erişimi paylaşabilmektedir. Bu yapı, RAC olmayan Oracle veritabanı ile benzerlik gösterir. Eğer bloğun lokal belleğin dışına transfer olması gerekirse GCS paylaşımlı havuz içinde Global Kaynak Dizinini günceller.

 

 

GCS ve Cache Coherency( Bellek Uyumluluğu)

 

 

GCS tüm veri blok tiplerini yönetir. Bellek uyumluluğu, veritabanı bloğunu değiştirmeden veya okumadan önce, instanceların cluster boyunca kaynak kazanma(blok üstündeki kilit veya kuyruğa alma) gereksinimi sebebiyle GCS üzerinden sürdürülür. GCS, sadece bir instance’ın  herhangi bir tekil zaman anında bloğu değiştirmesine izin vererek global bellek erişimi senkronizasyonu için kullanılmaktadır. Global Kaynak Dizini boyunca GCS, cluster içinde herhangi bir modda belleğe alınan veri bloklarının durumunun global olarak görünür ve sürdürülür olmasını temin eder.

Oracle RAC birçok versiyon mimarisinden oluşmaktadır. Yani bu birçok versiyon mimarisi, mevcut veri blokları ile bloğun bir veya daha fazla kalıcı okuma(CR) versiyonunu ayırt etmeye yaramaktadır. Mevcut veri bloğu, commit edilmiş ve daha henüz commit edilmemiş işlemler ile ilgili değişiklikleri içermektedir. Bloğun kalıcı okuma(CR) versiyonu, verinin geçmişte herhangi bir zaman anında alınan kalıcı snapshot görüntüsünü ifade etmektedir. Bir veri bloğu, paylaşımlı kaynakların himayesi altında pek çok ön bellek içinde bulunabilmektedir.

 

 

Oracle RAC’da rollback segment bilgisinin mevcut bloklara uygulanması, bloklarda kalıcı okuma versiyonlarının oluşmasına sebep olur. Hem mevcut okuma blokları, hemde kalıcı okuma blokları GCS tarafından yönetilir.

 

Veri bloklarını veritabanı bellekleri arasında transfer etmek için bu tamponlar, yüksek hızda IPC interconnect ortalamasıyla taşınmaktadırlar. Disk yazmaları sadece bellek değiştirmesi için gereklidir. Bloğun eski görüntüsü(PI), eğer kirli(değiştirilmiş) blok ise, gönderilmeden önce bellek içinde saklanır. Herhangi bir başarısızlık durumunda Oracle bu blokların eski görüntüsünü kullanarak bloğun mevcut versiyonunu yeniden inşa eder

 

 

GCS Kaynak Modları ve Roller

 

 

GCS global kaynak dizini, RAC sistemin başından sonuna kadar aktarılan kaynak bloklarını izlemektedir. Aynı blok, birçok bellek içinde sonuçta blok transferleri olarak yer alır. Blok, instance’nın kaynak veriyi güncellemek içinmi yoksa yalnızca okuma içinmi niyetlendiğine bağlı olarak farklı modlarda tutulur.

 

RAC kaynağı iki faktör tarafından belirlenmektedir:

 

Mod – null, shared veya exclusive.

Rol – Lokal veya global

 

Kaynak için talebin bir parçası olarak kaynak modları tutucu tarafından genellikle ayarlanmaktadır. Kaynak modu, taşıyıcının bloğu değiştirip değiştiremeyeceğini belirler. RAC kaynaklarının  modları aşağıda açıklanmaktadır.

 

Null – N ile tanımlanır. Bu seviyede kaynak tutmak hiç bir erişim hakkının olmadığını ifade eder.

Shared – S ile tanımlanır. Korumalı okuma anlamına gelir. Kaynak bu seviyede tutulursa, proses onu değiştiremez ve birçok proses aynı kaynağı okuyabilir.

Exclusive – X ile tanımlanır. Prosesin ayrıcalıklı erişimi tutmasını onaylar. Diğer prosesler kaynağa yazamaz, ancak eski blokların sürekli okumaları PI prosesi üzerinden hala müsaittir. 

 

Kaynak rolleri erişim tipine göre ayarlanmaktadır. Eğer kaynak exclusive(ayrıcalıklı) modda ise lokal, null veya shared mod da ise kaynak globaldir.

 

Cache Coherency(Bellek uyumluluğu) ile kullanılan performans izleme yolları

 

Bazı AWR raporlarını çalıştırmaktan çok daha fazla şekilde, HSI(High Speed Interconnects) network arayüzlerinin sağlığını ölçmeye ihtiyacımız vardır. Bunun yanında düğümler üzerindeki trafik hacmini ve cevap sürelerinide izlememiz gerekmektedir. Tipik bir OLTP sistemi bizi bu noktada fazlasıyla meşgul edecektir. Bu trafiği ölçmek için iki kategoriye odaklanılması gerekmektedir.

 

 

GCS (Global Cache Services)

GES (Global Enqueue Services)

 

 

Global Kuyruğa Alma Servisi (Global Enqueue Service)

 

Global olarak paylaşılan kuyruğa alma işlemlerini koordine eden servistir. RAC mimarisinde bloklar çoğunlukla işleri kendi başlarına halledebilmektedir, ancak GES devreye girdiğinde can alıcı bir nokta ortaya çıkar. RAC işlemi için düğümler arasında kusursuz bir koordinasyonun sağlanması şarttır. İşte bu noktada, GES önceliği ele alarak dictionary ve library bellekleri içinde uyumluluğun sağlanmasından sorumlu olur.Dictionary bellek, her bir düğümün kendi SGA’sı içinde öncelikli olarak hızlı bakış ve erişim için data dictionary master bilgisinden oluşmaktadır. Bir düğümde commit edilen herhangi bir DML işlemi, RAC yapısındaki tüm düğümlerde data dictionaryler üzerinden senkronize edilmeli ve yazılmalıdır. GES, değişikliklerin düğümler üzerinden sürekli kılındığını ve böylece uyuşmazlık olmadığını garanti altına alır.GES aynı objeye erişimde düğümler arasında deadlock olmamasını da garanti etmelidir. LMON, LCK ve LMD prosesleri birlikte bir koordinasyon içinde çalışarak, GES’in çalışmasını yumuşak ve kusursuz şekilde ayarlar.

 

Oracle RAC GCS performansını izlemek için Grid Enterprise konsoldan “Cluster Cache Coherency” performans izleme sayfasına girince aşağıdaki ekran çıkmaktadır.

 

 

image002

 

GC CR Blocks Received: Bu metrik mevcut cluster üzerinden okuma kalıcılık uygulamasını yansıtmaktadır.  Diğer bir şekilde cluster içindeki herhangi bir düğümde SELECT işlemi çalışır durumdayken başka bir oturum başka bir düğümde bu SELECT sorgusu çalışmaya başladığı andan itibaren satırları değiştirdiyse, oturum sorgu başladığı andaki veriyi içeren veri bloklarını talep edecektir. Eğer kalıcı okuma talebi lokal ön bellekten sağlanamazsa, bu durumda cluster içindeki başka bir instance içindeki veri bloklarını taşıma yoluyla sağlayabilmektedir. İşte bu taşıma işlemleri bu metrik içinde kayıt edilmektedir.

 

 

GC Current Blocks Received: Bu metrik mevcut durumdaki veri bloklarının instance’lar arası transferini göstermektedir. Bir veri bloğu INSERT, UPDATE veya DELETE işlemi sonucunda değiştirilmiş veya oluşturulmuşsa “mevcut durum” modundadır ve bu hareketi sağlayan en son güncel veri instance içindeki ön bellekte yer almaktadır. Eğer bu mevcut veri, cluster içindeki başka bir instance tarafından talep edilmiş ve başarılı bir şekilde transfer edilmişse bu metrik içinde yer alır.

 

 

GV$ görünümleri

 

Awr raporları yanında SQL*Plus üzerinden GV$ görünümleride performas izleme ve proaktif işlemler açısından önemlidir.

 

Örneğin, aşağıdaki sorgu düğümler üzerinde gönderilen GCS mesajları ile ilgili sonuç verecektir. Eğer düğümler arasında çok farklılıklar varsa bir sorun var demektir.

 

SQL> select * from gv$sysstat where name like ‘%gcs %’;

 

Bunun yanında aşağıdaki sql cümlesi, “nunhem” şemasındaki segmentlere ait global bellek aktivitesini gösterecektir. Eğer sonuçta blok başına yüksek satır sonuçları mevcutsa, bu objelerin PCTFREE değerlerinin artırılmasında fayda vardır.

 

SQL> SELECT

> table_name AS “Table Name”,

> gc_buffer_busy AS “Buffer Busy”,

> gc_cr_blocks_received AS “CR Blocks Received”,

> gc_current_blocks_received AS “Current Blocks Received”

> FROM

> (

> SELECT table_name FROM dba_tables

> WHERE owner = ‘NUNHEM’

> ) t,

> (

> SELECT object_name,value AS gc_buffer_busy

> FROM v$segment_statistics

> WHERE owner = ‘NUNHEM’

> AND object_type = ‘TABLE’

> AND statistic_name = ‘gc buffer busy’

> ) ss1,

> (

> SELECT object_name,value AS gc_cr_blocks_received

> FROM v$segment_statistics

> WHERE owner = ‘NUNHEM’

> AND object_type = ‘TABLE’

> AND statistic_name = ‘gc cr blocks received’

> ) ss2,

> (

> SELECT object_name,value AS gc_current_blocks_received

> FROM v$segment_statistics

> WHERE owner = ‘NUNHEM’

> AND object_type = ‘TABLE’

> AND statistic_name = ‘gc current blocks received’

> ) ss3

> WHERE t.table_name = ss1.object_name

> AND t.table_name = ss2.object_name

> AND t.table_name = ss3.object_name;

 

 

Table Name Buffer Busy CR Blocks Received Current Blocks Received

——————— ————— ———————- ———————–

CSTTBL                  0                              54                           434

RGNTBL                                0                              62                           370

JOBTBL                                 0                              6                              19

ITMTBL                                 0                              0                              637

ORDTBL                                1                              250                         574

STCTBL                  0                              1193                       531

WRHTBL                               0                              206                         192

 

 

Global Cache Services(GCS) kalıcı okumalarının izlenmesi

 

 

Kalıcı  okumaların performansını izlemek için alttaki formül kullanılır.

 

 (gc cr block receive time × 10) / (gc cr blocks received)

 

Yukardaki formulün sonucunda instance için milisaniye değerinde kalıcı blok okuması taleplerinin ortalama zamanı dönmektedir ve Enterprise Manager RAC performans görünümlerinde gözlemlediğimiz global bellek blok transfer oranı (Global Cache Block Transfer Rate) metrikidir. Bu değer interconnect performansını belirlemek için kullanılan en önemli değerdir.

 

Veri blokları için global kaynak talepleri, talep eden instance’ın ön belleği içinde meydana gelir. Talep, GCS talep kuyruğuna girmeden önce Oracle, SGA içinde talebin durumunu izleyecek ve bu kaynak yapıları üzerinde istatistik toplayacak veri yapılarını tahsis eder.

 

SQL> SELECT

> gc_cr_block_receive_time AS “Receive Time”,

> gc_cr_blocks_received AS “Blocks Received”,

> (gc_cr_block_receive_time * 10) /

> gc_cr_blocks_received AS “Average Latency (MS)”

> FROM

> (

> SELECT value AS gc_cr_block_receive_time FROM v$sysstat

> WHERE name = ‘gc cr block receive time’

> ),

> (

> SELECT value AS gc_cr_blocks_received FROM v$sysstat

> WHERE name = ‘gc cr blocks received’

> );

 

Alttaki sonuç yukardaki raporun çalışması sonucu alınan bir örnek sonuçtur:

 

Receive Time      Blocks Received                 Average Latency (MS)

————–         ——————–              ——————–

5405                         3869                                     23.9681803

 

 

Kalıcı blok talep gecikmesi, orijinal talep ile lokal instancetaki kalıcı blok imaj alındısı arasında geçen zamandır.Gigabit Ethernet bağlatısı ile, be değer normalde 5ms altında olmalı ve 15ms üzerine çıkmamalı, bununla beraber bu değer sistem konfigürasyonu ve hacimdende etkilenebilmektedir. Yukardaki örnekte gecikme süresi 24ms dir. Linux içerisinden “netstat” komutunu kullanarak network paket alımı ve gönderimi gibi bir network yapılandırma sorunu olup olmadığı anlaşılabilir. Bunun yanında, “top” ve “sar” komutları ile düğümler üzerindeki yükü ölçmelisiniz.  Eğer “interconnect” düzgün bir şekilde yapılandırıldıysa ve hala yüksek ortalama gecikme süreleri varsa, bu durumda

 

DB_FILE_MULTIBLOCK_READ_COUNT parametresinin değerini düşürün. Bu değer tekli operasyonda beher proses için ne kadar bloğun belirler. Proses tüm blokların dönmesini bekleyeceğinden dolayı muhtemelen yüksek bekleme oranlarına sebebiyet verebilir. Bu parametreyi düzenlemeden önce, tüm işyükündeki etkisini gözden geçirin.

 

 

Yüksek ortalama gecikme süreleri, yüksek sayıdaki gelen çağrılar veya birçok proses çağrıları LMS prosesine dağıtması yüzünden meydana gelebilir. Ortalama LMS servis süresi aşağıdaki formul ile hesaplanabilir.

 

average LMS service time = average latency – average time to build consistent read block – average time to wait for log flush – average time to send completed block

 

Kalıcı okuma bloğu inşa etmek için gereken ortalama zaman hesaplaması:

gc cr block build time / gc cr blocks served

 

Redo log flush işlemi için ortalama bekleme süresi hesaplaması:

gc cr block flush time / gc cr blocks served

 

Tamamlanmış bloğun ortalama gönderim süresi hesaplaması:

 

gc cr block send time / gc cr blocks served

 

Alttaki sorgu, kalıcı blok okuması için gereken ortalama LMS servis süresini hesaplamaktadır.

 

SQL> SELECT

> average_latency AS “Average Latency”,

> average_build_time AS “Average Build Time”,

> average_flush_time AS “Average Flush Time”,

> average_send_time AS “Average Send Time”,

> average_latency – average_build_time – average_flush_time – average_send_time

> AS “Average LMS Service Time”

> FROM

> (

> SELECT

> (gc_cr_block_receive_time * 10) / gc_cr_blocks_received AS average_latency,

> (gc_cr_block_build_time * 10) / gc_cr_blocks_served AS average_build_time,

> (gc_cr_block_flush_time * 10) / gc_cr_blocks_served AS average_flush_time,

> (gc_cr_block_send_time * 10) / gc_cr_blocks_served AS average_send_time

> FROM

> (

> SELECT value AS gc_cr_block_receive_time FROM v$sysstat

> WHERE name = ‘gc cr block receive time’

> ),

> (

> SELECT value AS gc_cr_blocks_received FROM v$sysstat

> WHERE name = ‘gc cr blocks received’

> ),

> (

> SELECT value AS gc_cr_block_build_time FROM v$sysstat

> WHERE name = ‘gc cr block build time’

> ),

> (

> SELECT value AS gc_cr_block_flush_time FROM v$sysstat

> WHERE name = ‘gc cr block flush time’

> ),

> (

> SELECT value AS gc_cr_block_send_time FROM v$sysstat

> WHERE name = ‘gc cr block send time’

> ),

> (

> SELECT value AS gc_cr_blocks_served FROM v$sysstat

> WHERE name = ‘gc cr blocks served’

> ) );

 

 

Oratalama gecikme süresi ve ortalama inşa, boşaltma ve gönderme zamanı arasındaki farklılık, LMS servisi içindeki harcanan zamanı ve “interconnect” üzerinden mesaj işlerken geçen süreyi temsil eder. Aşağıdaki sorgu sonucu buna bir örnek teşkil etmektedir.

 

 

Average               Average               Average               Average               Average

Latency                Build Time           Flush Time           Send Time           LMS Service Time

———–              ———–              ———–              ————            —————-

41.8455403          0.039572616       0.696264345       0.03661535          40.957365

 

 

Yukardaki örnekte görüldüğü üzere doğrusu LMS servis zamanında baya yüksek bir bekleme oranı mevcuttur. netstat- l ile TCP/UDP paketleri incelenmelidir. 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ğlanması gerekmektedir. Bu sayede network çıktısında büyük artışlar sağlanacaktır.
<!–[if !supportLineBreakNewLine]–>
<!–[endif]–>

 


Bunun yanında Linux 2.16 versiyon üzerinde maksimum UDP tampon büyüklüğü 4MB’dır ve alım tarafında otomatik iyileştirm etkindir.  udp_max_buffer parametresini 8MB ‘ye artırarak maksimum UDP tampon büyüklüğünün genişletilmesi gerekmektedir. Bunun neticesinde de udp_xmit_hiwat ve udp_recv_hiwat değerlerini 256KB’ya yükselterek, yetersiz UDP alım/işleme tampon büyüklüğü yüzünden düşen paket sayısını önemli oranda azaltmak mümkün olacaktır. Bunun yanında eğer networkunuz jumbo frame destekliyorsa, jumbo frameleri kullanın. Tipik olarak MTU büyüklüğü 1500 bytes büyüklüğündedir, bu değeri yaklaşık 9000 bytes sınırına çıkarın.

 

 

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. Düğümlerdeki sqlnet.ora dosyalarına aşağıdaki eklemeler yapılabilir.

 

 

RECV_BUF_SIZE=<soket tampon büyüklüğü>

SEND_BUF_SIZE=<soket tampon büyüklüğü>

 

 

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

 

 

GCS Mevcut Bloklarda performansın izlenmesi

 

 

SQL*Plus kullanarak EM RAC performans görünümlerindeki Global Cache Block Transfer Rate oranı ile mevcut blok aktivitesini izleyebiliriz. Mevcut bloklar için işlem gören çağrılar içinde baştan sona ortalama gecikme süresi aşağıdaki formül ile bulunabilir.

 

 

SQL> SELECT

> gc_current_block_receive_time AS “Receive Time”,

> gc_current_blocks_received AS “Blocks Received”,

> (gc_current_block_receive_time * 10) / gc_current_blocks_received

> AS “Average (MS)”

> FROM

> (

> SELECT value AS gc_current_block_receive_time

> FROM v$sysstat

> WHERE name = ‘gc current block receive time’

> ),

> (

> SELECT value AS gc_current_blocks_received

> FROM v$sysstat

> WHERE name = ‘gc current blocks received’

> );

 

Aşağıdaki çıktı örnek bir sonuç olabilmektedir.

 

 

Receive Time                      Blocks Received                 Average (MS)

————                            —————                       —————-

12279                                    14222                                    8.63380678

 

 

LMS işlemine dayandırılan baştan sona gecikme süresi aşağıdaki formül ile hesaplanabilir.

 

average LMS service time = average latency – average time to pin current blocks – average time to wait for log flush – average time to send completed block

 

Mevcut blok okumaları için ortalama LMS servis zamanı hesaplamasında aşağıdaki sorgu kullanılabilir:

 

 

SQL> SELECT

> average_latency AS “Average Latency”,

> average_pin_time AS “Average Pin Time”,

> average_flush_time AS “Average Flush Time”,

> average_send_time AS “Average Send Time”,

> average_latency – average_pin_time – average_flush_time – average_send_time

> AS “Average LMS Service Time”

> FROM

> (

> SELECT

> (gc_current_block_receive_time * 10) / gc_current_blocks_received

> AS average_latency,

> (gc_current_block_pin_time * 10) / gc_current_blocks_served

> AS average_pin_time,

> (gc_current_block_flush_time * 10) / gc_current_blocks_served

> AS average_flush_time,

> (gc_current_block_send_time * 10) / gc_current_blocks_served

> AS average_send_time

> FROM

> (

> SELECT value AS gc_current_block_receive_time FROM v$sysstat

> WHERE name = ‘gc current block receive time’

> ),

> (

> SELECT value AS gc_current_blocks_received FROM v$sysstat

> WHERE name = ‘gc current blocks received’

> ),

> (

> SELECT value AS gc_current_block_pin_time FROM v$sysstat

> WHERE name = ‘gc current block pin time’

> ),

> (

> SELECT value AS gc_current_block_flush_time FROM v$sysstat

> WHERE name = ‘gc current block flush time’

> ),

> (

> SELECT value AS gc_current_block_send_time FROM v$sysstat

> WHERE name = ‘gc current block send time’

> ),

> (

> SELECT value AS gc_current_blocks_served FROM v$sysstat

> WHERE name = ‘gc current blocks served’

> ));

 

Aşağıda bu sorgu sonucu hazırlanan örnek bir sorgu sonucu yer almaktadır.

 

 

Average               Average               Average               Average               Average

Latency                Build Time           Pin Time               Send Time           LMS Service Time

———–              ———–              ————            ————            —————-

8.67584376          0.041137669       0.022696645       0.04397475          8.56803469

 

 

Yüksek değerler interconnect veya sunucu bazlı sorunlar olduğunu işaret eder.Bununla beraber yüksek “average pin time” değerleri olduğunda, LGWR prosesinin işlem önceliğini artırın. Redo log dosyaları üzerinde yazma performansının artması tüm RAC ortamında blok işlemlerinde performans artışı sağlayacaktır. Örneğin, Solaris host için aşağıdaki gibi LGWR prosesine öncelik verebilirsiniz.

 

 

priocntl -e -c class -m userlimit -p priority

priocntl -e -c RT -p 59 `pgrep -f ora_lgwr_${ORACLE_SID}`

priocntl -e -c FX -m 60 -p 60 `pgrep -f ora_lms[0-9]*_${ORACLE_SID}`

 

Bunun yanında yüksek bekleme olaylarıyla ilişkili veritabanı objelerini bulmak için aşağıdaki sorgu çalıştırılabilir.

 

 

SELECT INST_ID “Instance”, name, kind, sum(forced_reads) “Forced Reads”, sum(forced_writes) “Forced Writes” 

FROM gv$cache_transfer

WHERE owner# != 0

GROUP BY inst_id, name, kind

ORDER BY 1,4 desc,2;

 

Instance NAME                                                 KIND                      Forced Reads     Forced Writes

——— —————————- ———-               —————-     ————-

        1 MOD_TEST_IND                                    INDEX                   308                          0

        1 TEST2                                         TABLE            64                    0

        1 AQ$_QUEUE_TABLES         TABLE             5                     0

        2 TEST2                                         TABLE             473                 0

        2 MOD_TEST_IND                                     INDEX            221                0     

 

 

Bunun yanında Cache Fusion Hit Ratio oranını bulmak için ise;

 

 

SELECT A.inst_id “Instance”,

A.VALUE/B.VALUE “Cache Fusion Writes Ratio”

FROM GV$SYSSTAT A, GV$SYSSTAT B

WHERE A.name=’DBWR fusion writes’

AND B.name=’physical writes’

AND B.inst_id=a.inst_id

ORDER

BY A.INST_ID;

 

Instance               Cache Fusion Writes Ratio

———                 ————————-

        1                .227487558

        2                .141465042

 

 

Yüksek orandaki Cache Fusion Write Ratio değeri, yetersiz büyüklükte bellek olmasından veya çok fazla checkpoint meydana gelmesinden veya bellek replacement(yeniden yerleştirme) -yada -checkpoint yüzünden çok büyük tamponların yazılmasından kaynaklanmaktadır. Bu durumda checkpoint sıklığını azaltmak bir çözüm olabilecektir. Bunun yanında geniş sort ve full tablo taramalarını azaltmakta çok büyük tamponların DBWR prosesi ile yazılma büyüklüğünü azaltacaktır. Aslında SGA alanında ön bellek miktarını bir miktar artırmakta bir çözüm olabilecektir. Ancak en optimal Cache Fusion yazma değerini yakalamak için Veri dosyalarını diskler veya disk kontroller üzerine serpiştirin ve sıcak noktaların oluşmasının önüne geçin.

 

 

Global Kuyruğa Alma Servisinin izlenmesi

 

 

SQL> SELECT

> global_enqueue_get_time AS “Get Time”,

> global_enqueue_gets_sync AS “Synchronous Gets”,

> global_enqueue_gets_async AS “Asynchronous Gets”,

> (global_enqueue_get_time * 10) /

> (global_enqueue_gets_sync + global_enqueue_gets_async)

> AS “Average (MS)”

> FROM

> (

> SELECT value AS global_enqueue_get_time

> FROM v$sysstat

> WHERE name = ‘global enqueue get time’

> ),

> (

> SELECT value AS global_enqueue_gets_sync

> FROM v$sysstat

> WHERE name = ‘global enqueue gets sync’

> ),

> (

> SELECT value AS global_enqueue_gets_async

> FROM v$sysstat

> WHERE name = ‘global enqueue gets async’

> );

 

Get Time              Synchronous Gets           Asynchronous Gets         Average (MS)

———-               —————-                     —————–                    ————

159674 98861                                    10555                                    15.3954835

 

 

“Synchronous gets”  değerleri genellikle kilitleme olaylarını işaret ederken yüksek orandaki “asynchronous gets” ise instanceler arası engelleyici olmayan prosesler yüzünden meydana gelir.

 

 

Yukardaki örnekte ortalama global kuyruğa alma zamanı yaklaşık olarak 15.4 ms, ki bu değer kabul edilebilir sınırlar içindedir. Eğer bu oran 20ms üzerinde olursa, çalıştırdığınız uygulamada sorunların ve beklemelerin olduğu anlamına gelmektedir. Bu noktada index kullanımını gözden geçirmeniz ve bu beklemelerde bloklayan SID yi bulmanız gerekecektir. Eşzamanlı kilitleyebilmede önkuyruk sayısını maksimum sayıda kontrol etmek için  ENQUEUE_RESOURCES parametresi kullanılmaktadır. Bu değeri artırmayı deneyin.

Makaleyi Paylaş

Cevap bırakın