Oracle network konfigürasyonun optimizasyonu

Oracle veritabanları büyük ölçekli firmalarda genellikle coğrafik olarak farklı bölgelere dağıtılmıştır, böylece Oracle veritabanları uzmanları için veritabanının network bağlantılarından nasıl etkilendiğinin anlaşılması önemli bir görev olmaktadır. Oracle tarafından sağlanan Transparent Network Substrate(TNS), veritabanları arasında dağıtık bağlantılara izin vermektedir.

 
Dağıtık işlemlerin performansı bu yazıda yer alan bazı değişiklikler ile arttırılabilecektir. Bu değişiklikler sqlnet.ora, tnsnames.ora ve protocol.ora dosyaları içindeki parametreler olacaktır. Bu parametreler, konfigürasyonu ve TCP paketlerinin boyutunu değiştirmek için kullanılır. Bu parametrelerin ayarlanmasının, tüm Oracle işlemlerinin çıktısını geliştirmek için, temel network taşıma katmanı üzerinde çok yoğun bir etkisi vardır.  

Oracle Net, veritabanı uzmanlarına temel network ayarlarını iyileştirebilecek yeterliliğe izin vermez ve network trafiğinin çoğunluğu Oracle yapısı içerisindende iyileştirilmez. Çünkü Oracle Net, OSI modeli içinde network spesifik protocol yığını üstünde bulunur.

Network paketlerinin sıklığı ve büyüklüğü Oracle DBA tarafından kontrol edilir. Oracle, paket sıklığı ve büyüklüğünü değiştirmek için zengin araçlara sahiptir. Network üzerinden paket taşımasının sıklığı ve büyüklüğü, aşağıdaki parameter dosyaları içinde yer alan ayarları kullanılarak etkilenir:

• protocol.ora dosyası - tcp.nodelay parametresi
• sqlnet.ora server dosyası - automatic_ipc parametresi
• tnsnames.ora ve listener.ora dosyaları - SDU ve TDU parametreleri

protocol.ora dosyası içindeki tcp.nodelay parametresi
Oracle Net, varsayılan olarak verinin iletilmesinden önce tampon dolana kadar bekler. Bu yüzden, talepler hedeflerine her zaman anında gönderilmemektedir. Bu olay, çoğu zaman büyük miktarda verilerin bir sondan bir diğerine akıp gittiği zamanda yaygın bir olaydır ve Oracle Net tampon dolana kadar paketleri işlemez. protocol.ora dosyası eklemek ve tampon taşıma gecikmelerini durdurmak için tcp.nodelay değerinin belirtilesi bu sorunun üstesinden gelebilir.

protocol.ora dosyası tüm TCP/IP yapılandırmaları için veri tamponlamasının olmamasını göstermek için belirtilir. Bu parameter, hem istemci hemde sunucu üzerinde kullanılabilir.  protocol.ora içinde bu  parametrenin kullanımı:

         tcp.nodelay = yes

Bu paramerenin tanımlanması TCP tamponlamanın es geçilmesine sebep olur, böylece tüm talepler hemen ve anında gönderilir. Ancak unutmamak gerekirki, network trafiği daha küçük ama sık paket işlemesi sebebiyle artar, bu da networkte ağırlaşmaya sebep olur. tcp.nodelay parametresi, sadece TCP zaman aşımı ile karşılaşıldığı zamanlarda kullanılmalıdır. tcp.nodelay parametresinin ayarlanması, veritabanı sunucuları arasında yüksek hacimde trafik olduğunda performansı aşırı oranda geliştirmeye sebep olabilir.

Sqlnet.ora dosyasındaki “automatic_ipc” parametresi

automatic_ipc parametresi network katmanını atlar, böylece veritabanına local bağlantıları hızlandırır. automatic_ipc değeri ON olarak ayalandığında, Oracle Net local veritabanının aynı alias ile belirtilip belirtilmediğini kontrol eder. Eğer aynı alias ile belirtilmişse, bağlantı direkt olarak local IPC bağlantılarına çevrildiğinden network katmanları atlanır. Bu veritabanı sunucuları için kullanışlıdır, ancak Oracle Net istemcileri için kesinlikle gereksizdir.

“Oradebug hanganalyze” komutunun incelemesi

Oradebug özelliği yeterli döküman kaynağı olmadığından dolayı “gizli” kategoride yer almaktadır. Oysaki Oracle 8.1 sürümünden beri SQL*Plus üzerinden çalıştırılmaktadır. Bu özellik kullanıcı oturumlarını izleyebildiği gibi global olarakta veritabanı izleme işlevlerini sağlamaktadır.

Oradebug komutu çalıştırılmak için SYSDBA hakkına gerek duymaktadır. Bu komut ile yapılacak pek çok faydalı işlemlere gelirsek;

• Başka kullanıcının oturumu için SQL izlemesinin etkinleştirilmesi veya devredışı bırakılması
• Yoğun prosesleri askıya almak
• Paylaşımlı bellek ve semaforlar hakkında bilgileri bulmak
• İzleme dosyasını kapatmak suretiyl yenisinin oluşturulmasını sağlamak
• Dahili yapılar ile oynamak ve yığınlar oluşturmak
• Prosesleri uyandırmak

HANGANALYZE özelliğinin kullanımı

HANGANALYZE özelliği oradebug komutu ile veritabanının askıya alındığı zamanlarda oldukça güçlü ve kullanışlıdır.

HANGANALYZE çıktısı yığın şeklinde değildir. “user dump destination” dizininde bir çıktı oluşturur, kullanıcıların okuyabileceği formattadır. Genel sentaks aşağıdaki gibidir;

Standby veritabanında “ORA-02290: check constraint (RMAN.AL_C_STATUS) violated” hata mesajı

Bu hata mesajı ile birkaç hafta önce uzun bir tatil dönüşü sonunda bir yedekleme sorunu üzerinde çalışırken karşılaştım. Yedek, standby veritabanında alınmakta ve recovery katalog kullanılmaktaydı. Oracle sürümü ise Oracle 10.2.0.4

Stanby veritabanında RMAN operasyonu ile katalog veritabanı bağlantı denemeleri aşağıdaki hata mesajı ile sonlandırılmaktaydı:

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of list command at 06/27/2011 09:01:57

RMAN-03014: implicit resync of recovery catalog failed

RMAN-03009: failure of partial resync command on default channel at 06/27/2011 09:01:57

ORA-02290: check constraint (RMAN.AL_C_STATUS) violated

Görünüşe göre hiçbir yedek yok! Halbuki primary veritabanında aynı işlemi yaptığımda bir hata ile karşılaşmıyorum, ancak primary üzerinde ise yedek almak için yeterli boş alan yok.

Büyük partition tablolarda istatistiklerin toplanması

Genellikle büyük partition tablolarda optimizer istatistiklerinin toplanması ve sürdürülmesi ile ilgili pek çok yeni DBA’nin kafasında soru işaretleri vardır. Bu soruları aslında iki konu etrafında toplayabiliriz:

1. Sorgular, eskimiş veya varolmayan partition seviyesi istatistiklerine erişirken menzil dışı değerler sebebiyle bir alt optimal planı alabilir.
2. Global istatistik toplaması zaman ve sistem kaynakları açısından aşırı derecede pahalıdır.

Bu yazıda bu iki sorunu tanımlayıp Oracle 10g ve Oracle 11g sürümlerinde bu iki sorunun temelini inceleyeceğiz.

Menzil dışı (out of range) değerler
Büyük tablolar sıklıkla, sorgu performansını artırmak ve veri yönetimini kolaylaştırmak için “partition” olarak adlandırılan daha küçük bölümlere ayrıştırılır. Oracle sorgusu, SQL sorgusu için iyi bir çalıştırma planı seçmek için hem bütün tablonun istatistiklerini(global istatistikler), hemde bireysel partitionların istatistiklerini(partition istatistikleri) değerlendirmeye almaktadır. Eğer sorgu sadece tekil bir partitiona erişmek ihtiyacı duyarsa, optimizer sadece bu erişilen partition’un istatistiklerini kullanmaktadır. Eğer sorgu birden fazla partitiona erişirse, global ve partition istatistiklerinin kombinasyonunu kullanılmaktadır. Partition kolonların minimum ve maksimum değerlerini şu şekilde düzeltir; İlk partition kolonun maksimum değeri olarak yüksek sınır bölümlendirmesini kullanır ve “range partitioned” tablolar için ilk bölümlendirilmiş kolonun minimum değeri olarak bir önceki partitionun yüksek sınır bölümlendirme değerini kullanır. İsteğe bağlı olarak, hedefin blok sayısı, satır sayısı gibi diğer bazı istatistikleride devredışı bırakır.

Farzedinki STOK adlı tablonun STOK_GIRIS kolonundan dörtte bir oranında “range partition” şeklinde bölümlendirilmiş bir tablo mevcut. Her günün sonunda veri en son partition içine yüklenmekte, ancak istatistikler sadece partitionun tamamen dolduğu yılın dörtte birlerinde toplanmakta. Global ve partition seviyeli istatistiklerin(sadece tamamen dolu partitionlar için) güncel olduğunu varsayarak, alt-optimal planının “menzil dışı” olmasını önlemek için aşağıdaki adımlar izlenebilir.

LOG_ARCHIVE_MAX_PROCESSES değerinin ayarlanması

Oracle LOG_ARCHIVE_MAX_PROCESSES parametresi Oracle tarafından başlangıçta çağrılan aktif ARCH proseslerinin(ARC0-ARCn) sayısını belirtir. LOG_ARCHIVE_MAX_PROCESSES parametresinin değeri,Oracle 10g itibariyle LOG_ARCHIVE_START başlangıç parametresinin geçersiz olmasına rağmen TRUE olarak ayarlandığında değerlendirmeye alınır. Oracle’da yüksek uygunluğa erişmek, Oracle’ı enterprise veritabanı olarak kullanan herkesin hayalidir ve bu hedefe ulaşmak için öncelikle LOG_ARCHIVE_MAX_PROCESSES parametresinin değerinin yükseltilmesi sıklıkla tavsiye edilmektedir. Bu yazıda, LOG_ARCHIVE_MAX_PROCESSES parametresinin değerinin yükseltilmesinin her zaman veritabanı sisteminde en iyi çözüm olmadığını ve LOG_ARCHIVE_MAX_PROCESSES  değerini ayarlarken neden dikkatli olunmasını inceleyeceğiz.

TEMP tablespace büyüme sorunu

TEMP tablespace büyüme sorunu pek çok DBA tarafından karşılaşılan ve sıkıntı yaratan bir sorundur. Temporary(geçici) tablespace aşırı büyüdüğünde veritabanında geçici tablespace alanı tükenebilmektedir. Bu yazıda, bu gibi durumlarda geçici tablespace alanını arzu edilen boyuta kavuşturulacağı ile ilgili bir takım ipuçları yer alacaktır.

Geçici tablespace hakkında bilgi almak:

Aşağıdaki komutu kullanarak geçici tablespace hakkında bilgi alınabilir.

SELECT TABLESPACE_NAME, FILE_NAME FROM DBA_TEMP_FILES;

TABLESPACE_NAME   FILE_NAME

---------------   -----------
TEMP              /u01/oracle/oradata/arda/TEMP01.DBF

Tempfile dosyasının yeniden boyutlandırılması:

Pek çok durumda ALTER DATABASE TEMPFILE komutu ile geçici tablespace’in alanını artırmak metodu seçilebilmektedir.

Ancak, geçici tablespace dosyalarının(tempfile) yeniden boyutlandırılması sıklıkla ORA-03297 hata mesajının alınması ile sonuçlanmaktadır. Bu gibi durumda TEMP veri dosyasının oto genişleyebilir(auto-extensible) olması gerekmekte ve maxbytes/maxblocks değerinin çok düşük olmadığından emin olunması gerekmektedir. Benzer olarak TEMP tablespace’in büyük yığınlarını tahsis etmekten sorumlu olan SQL sorgularının belirlenmesi ve iyileştirilmeside gerekmektedir.

ALTER DATABASE TEMPFILE ‘/u01/oracle/oradata/arda/TEMP01.DBF' RESIZE RESIZE 250M
*
ERROR AT LINE 1:
ORA-03297: FILE CONTAINS USED DATA BEYOND REQUESTED RESIZE VALUE

Eğer ALTER DATABASE TEMPFILE komutu sonunda ORA-032297 hata mesajı ile karşılaşılırsa aşağıdaki adımları izleyerek temp dosyasının boyutu sorunsuzca arzu edilen boyuta kavuşturulur.

Sıcak blok kavramı üzerine bir inceleme

Ön bellek içinde muhtemel “sıcak bloklar” CACHE BUFFERS CHAINS mandalında yüksek veya hızla artış gösteren bekleme sayılarından belirlenebilmektedir.

Bu mandal, tampon bellek içerisinde önbelleklenmiş data bloklarını araştırırken elde edilir. Tampon bellek, blok zincirlerinin toplamı olarak uygulandığından itibaren, her bir zincirin taranması gerektiğinde alt bir mandal tarafından korunmaktadır. Bu mandal içindeki içerik, tekil bir bloğa çok yüksek sayıda erişimden kaynaklanmaktadır. Bu durum, uygulamanın yeniden gözden geçirilmesini gerektirebilir.

 
Bu mandal üzerindeki beklemeler incelenerek, aşağıdaki sorgularda kullanılarak ilgili segment ve spesifik blok hakkında bilgiler elde edilebilir.

Önce, bu mandal için uyku sayısı incelemesiyle hangi mandal ID(ADDR) lerinin etkilendiği belirlenmelidir. Yüksek uyku sayısı, daha etkili mandal IDsi(ADDR)ni işaret etmektedir:

select CHILD#  "cCHILD", ADDR    "sADDR",     
       GETS    "sGETS" , MISSES  "sMISSES",
       SLEEPS  "sSLEEPS"
from v$latch_children
where name = 'cache buffers chains'
order by 4, 1, 2, 3;

En fazla sürekli uyku sayısına sahip mandal IDsi(ADDR) oluşturmak için yukarıdaki sorgu sıklıkla çalıştırılabilir. En yüksek uyku sayısına sahip ID bulunduğunda, sonrasında bu mandal tarafından korunan tampon bellek içindeki mevcut bloklar hakkında daha fazla detay almak için bu mandal adresi kullanılabilir.

 
En yüksek uyku sayısına sahip ID yi belirledikten sonra aşağıdaki sorgu çalıştırılmalıdır.

     select /*+ RULE */
       e.owner ||'.'|| e.segment_name  segment_name,
       e.extent_id  extent#,
       x.dbablk - e.block_id + 1  block#,
       x.tch,
       l.child#
     from
       sys.v$latch_children  l,
       sys.x$bh  x,
       sys.dba_extents  e
     where
       x.hladdr  = 'ADDR' and
       e.file_id = x.file# and
       x.hladdr = l.addr and
       x.dbablk between e.block_id and e.block_id + e.blocks -1
     order by x.tch desc ;

SEGMENT_NAME  EXTENT#  BLOCK#   TCH    CHILD#
------------  -------- -------- ------ ---------
SCOTT.EMP_PK  5        474      17      7,668
SCOTT.EMP     1        449       2      7,668

TCH kolonuna bağlı olarak bir “sıcak blok” belirlenebilir. TCH kolonun değerinin yüksekliği neticesinde, SQL cümlelerince erişilen en sık blok anlaşılır. “Sıcak blokları” bulmak için aşağıdaki sorgu çalıştırılabilir.