Oracle AWR (Automatic Workload Repository) raporundaki Instance Efficiency Percentages (Örnek Verimlilik Yüzdeleri)

Oracle AWR (Automatic Workload Repository) raporlarında “Instance Efficiency Percentages” bölümü, veritabanı örneğinin ne kadar verimli çalıştığını gösteren kritik ölçümleri içerir. Bu yüzdeler, Oracle veritabanının çeşitli önbellek mekanizmalarını ne kadar etkili kullandığını değerlendirmenizi sağlar. Bu bölümdeki metrikler ve bu metrik değerlerinin ne ifade ettiklerini açıklamaya çalıştım.

Buffer Nowait % :

Oracle AWR (Automatic Workload Repository) raporlarında “Buffer Nowait %” metriği, veritabanının buffer cache erişimlerinde ne kadarının bekleme olmadan (nowait) gerçekleştiğini gösteren bir performans göstergesidir.

Detaylı Açıklama

• Buffer Nowait %, Oracle’ın SGA (System Global Area) içindeki buffer cache‘e erişirken:
  • “Nowait” (anında erişim) durumunun ne sıklıkla gerçekleştiğini ölçer.
  • “Wait” (bekleme gerektiren durumlar) olup olmadığını analiz eder.
• Yüksek değerler, buffer cache’in verimli kullanıldığını ve çoğu bloğa direkt erişilebildiğini gösterir.
• Düşük değerler, disk I/O çekişmesi (contention) veya latch bekleme sorunları olduğuna işaret edebilir.

Hesaplama Formülü

Buffer Nowait % = (1 – (physical reads cache + db block gets from cache requiring waits) /

                  (db block gets from cache + consistent gets from cache)) * 100

• db block gets: Current mode’da okunan blok sayısı (DML işlemleri için)
• consistent gets: Read-consistent mode’da okunan blok sayısı (SELECT işlemleri için)
• physical reads cache: Diskten okunan blok sayısı (cache miss)
• gets requiring waits: Buffer cache erişiminde latch/contention nedeniyle beklenen işlemler

İdeal Değerler

• %99 ve üzeri: Çok iyi, buffer cache verimli kullanılıyor.
• %95-%99: Normal, küçük bekleme sorunları olabilir.
• <%95: Potansiyel performans sorunu, latch contention veya I/O bottleneck olabilir.

Düşük “Buffer Nowait %” Nedenleri

1. Yetersiz Buffer Cache: DB_CACHE_SIZE küçükse, disk okumaları artar.
2. Latch Contention: Özellikle “cache buffers chains” latch bekleme sorunları.
3. Yüksek Disk I/O: Yavaş depolama veya yetersiz RAM nedeniyle sık disk okuması.
4. Aşırı Sıcak Bloklar (Hot Blocks): Sık erişilen bloklar latch çakışmasına neden olabilir.

Çözüm Önerileri

• Buffer Cache Büyütme:

ALTER SYSTEM SET DB_CACHE_SIZE=4G SCOPE=BOTH;

• “cache buffers chains” Latch Sorunlarını Azaltma:
  • SQL Optimizasyonu: Fazla full table scan sorguları düzelt.
  • Partitioning: Büyük tabloları parçalayarak erişimi dağıt.
  • Reverse Key Index: Sequence-based PK’larda latch çakışmasını azalt.
• Disk I/O Optimizasyonu:
  • ASM/SSD kullanımı
  • I/O ayarlarını kontrol et (DB_WRITER_PROCESSES, DISK_ASYNCH_IO)

İlişkili Diğer AWR Metrikleri

• Buffer Hit Ratio: Cache verimliliğini gösterir.
• Latch Free Waits: Latch bekleme sorunlarını analiz eder.
• DB CPU vs. DB Time: CPU kullanım verimliliğini ölçer.

Buffer Nowait %, Oracle veritabanının bellek erişim verimliliğini anlamak için kritik bir göstergedir. Düşükse, latch contention veya I/O bottleneck araştırılmalıdır.

Buffer Hit % :

“Buffer Hit %” (Buffer Cache Hit Ratio), Oracle veritabanının buffer cache‘den ne kadar verimli bir şekilde veri okuduğunu gösteren önemli bir performans metriğidir. Bu metrik, disk I/O yerine bellekten (SGA) okunan blokların oranını ölçer.

Detaylı Açıklama

• Buffer Cache, Oracle’ın SGA (System Global Area) içinde sık kullanılan veri bloklarını tutan bir bellek alanıdır.
• Buffer Hit %, bir SQL sorgusu çalıştığında verinin disk yerine doğrudan bellekten (cache) okunma yüzdesini ifade eder.
• Yüksek değerler, Oracle’ın disk erişimini azaltarak performansı optimize ettiğini gösterir.
• Düşük değerler, sık disk okuması (I/O) nedeniyle performans sorunlarına işaret edebilir.

Hesaplama Formülü

Buffer Hit % = (1 – (physical reads / (db block gets + consistent gets))) * 100

• physical reads: Diskten okunan blok sayısı (cache miss)
• db block gets: DML işlemleri (INSERT/UPDATE/DELETE) sırasında okunan bloklar
• consistent gets: SELECT sorguları sırasında okunan tutarlı (read-consistent) bloklar

İdeal Değerler

Düşük “Buffer Hit %” Nedenleri

1. Yetersiz Buffer Cache Boyutu
   • DB_CACHE_SIZE küçükse, Oracle sık sık diske gitmek zorunda kalır.
2. Büyük Full Table Scan Sorguları
   • Büyük tabloları tarayan sorgular cache’i doldurup diğer sorguları diske zorlar.
3. Fazla Sıralama (Sort) ve Hash İşlemleri
   • PGA_AGGREGATE_TARGET yetersizse, disk temp alanı (TEMP_TABLESPACE) kullanılır.
4. Yanlış Index Kullanımı
   • Index’ler olmadığında Oracle tüm tabloyu okur (FTS → Full Table Scan).
5. Aşırı Parse veya Hard Parse
   • Library Cache’i tüketerek buffer cache’i de etkileyebilir.

Çözüm Önerileri

1. Buffer Cache Büyütme

ALTER SYSTEM SET DB_CACHE_SIZE=8G SCOPE=BOTH;  — Örnek: 8GB cache

• DB_CACHE_ADVICE ile ideal boyutu belirle:

SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor

FROM v$db_cache_advice;

2. SQL Optimizasyonu

• Full Table Scan Yapan Sorguları Bul:

SELECT sql_id, executions, disk_reads, buffer_gets

FROM v$sqlarea

ORDER BY disk_reads DESC;

• Eksik Index’leri Ekle:

CREATE INDEX idx_emp_dept ON employees(department_id);

3. CURSOR_SHARING ve Literal SQL Sorunları

ALTER SYSTEM SET CURSOR_SHARING=FORCE;  — Literal SQL’leri bind değişkenine çevir

4. Automatic Shared Memory Management (ASMM) Kullanımı

ALTER SYSTEM RESET memory_max_target;

ALTER SYSTEM RESET memory_target;

ALTER SYSTEM SET PGA_AGGREGATE_TARGET=5G SCOPE=SPFILE SID=’*’;

ALTER SYSTEM SET SGA_TARGET=15G SCOPE=SPFILE SID=’*’;

ALTER SYSTEM SET SGA_MAX_SIZE=15G SCOPE=SPFILE SID=’*’;

İlişkili Diğer AWR Metrikleri

Sonuç

• Buffer Hit % > %98 → Veritabanı bellekten verimli şekilde okuyor.
• Buffer Hit % < %90 → Disk I/O fazla, optimizasyon gerekli.
• En iyi çözüm, cache boyutunu artırmak + SQL optimizasyonu yapmaktır.

Bu metrik, Oracle performans iyileştirme sürecinde en kritik göstergelerden biridir. Düşükse, SQL planlarını ve bellek ayarlarını gözden geçirin.

Library Hit % :

“Library Hit %” (Library Cache Hit Ratio), Oracle veritabanının SQL ve PL/SQL kodlarını ne kadar verimli bir şekilde cache’lediğini gösteren kritik bir performans metriğidir. Bu oran, yeni bir SQL çalıştırıldığında Oracle’ın bu ifadeyi yeniden parse etmek yerine cache’den bulma başarısını ölçer.

Detaylı Açıklama

• Library Cache, SGA’nın bir parçasıdır ve SQL parçalarını, execution planları ve PL/SQL kodlarını saklar.
• Yüksek Library Hit %, Oracle’ın aynı sorguları tekrar tekrar parse etmek yerine cache’den hızlıca aldığını gösterir.
• Düşük değerler, sık hard parsing (pahalı bir işlem) ve library cache contention sorunlarına işaret eder.

Hesaplama Formülü

Library Hit % = (1 – (reloads / (pins))) * 100

• pins: Bir SQL/PLSQL ifadesinin cache’den çağrılma sayısı.
• reloads: Cache’de bulunamayıp diskten yeniden yüklenme sayısı (cache miss).

İdeal Değerler

Düşük “Library Hit %” Nedenleri

1. Literal SQL Kullanımı (Bind Değişken Eksikliği)

SELECT * FROM users WHERE id = 100;  — Literal (cache’lenmez)

SELECT * FROM users WHERE id = :v_id;  — Bind değişken (cache’lenir)

1. Yetersiz Shared Pool Boyutu

SHOW PARAMETER shared_pool_size;

1. Sık Sık Objelerin Invalid Olması
   (Örn: tabloların sık alter edilmesi, schema değişiklikleri)
2. Çok Fazla Farklı SQL Çalıştırma
   (Dinamik SQL’ler, ORM araçlarının ürettiği benzersiz sorgular)

Çözüm Önerileri

1. Bind Değişken Kullanımını Zorla

ALTER SYSTEM SET CURSOR_SHARING=FORCE;  — Literal’leri otomatik bind yapar

2. Shared Pool’u Büyüt

ALTER SYSTEM SET SHARED_POOL_SIZE=2G SCOPE=BOTH;

3. Aşırı Parse Eden SQL’leri Bul ve Düzelt

SELECT sql_id, executions, parse_calls

FROM v$sqlarea

ORDER BY parse_calls DESC;

4. PL/SQL’de “CURSOR_SHARING=EXACT” Kullan

BEGIN

   EXECUTE IMMEDIATE ‘ALTER SESSION SET CURSOR_SHARING=EXACT’;

   — Dinamik SQL’lerde bind değişken kullan

END;

5. Library Cache’i Temizle (Geçici Çözüm)

ALTER SYSTEM FLUSH SHARED_POOL;  — Production’da dikkatli kullanın!

İlişkili Diğer AWR Metrikleri

Sonuç

• Library Hit % > %95 → SQL’ler verimli cache’leniyor.
• Library Hit % < %90 → Hard parse sorunları var, optimizasyon şart.
• En iyi çözüm, bind değişken kullanımı + shared pool ayarı yapmaktır.

Bu metrik, Oracle’ın SQL işleme verimliliğini doğrudan etkiler. Düşükse, uygulama tarafında SQL yazım şekli ve Oracle bellek ayarları gözden geçirilmelidir.

Execute to Parse % :

“Execute to Parse %”, Oracle veritabanında çalıştırılan (execute) SQL ifadelerinin ne kadarının yeniden parse edilmeden kullanıldığını gösteren kritik bir performans metriğidir. Bu oran, veritabanının SQL paylaşım verimliliğini ölçer.

Detaylı Açıklama

• Yüksek değerler, aynı SQL’lerin tekrar tekrar kullanıldığını (soft parse) gösterir → İyi performans
• Düşük değerler, sürekli yeni SQL parse edildiğini (hard parse) gösterir → Performans sorunu
• Parse işlemi CPU yoğun bir işlemdir, mümkün olduğunca azaltılmalıdır.

Hesaplama Formülü

Execute to Parse % = (1 – (parses / executes)) * 100

• parses: SQL ifadelerinin parse edilme sayısı
• executes: SQL ifadelerinin çalıştırılma sayısı

İdeal Değerler

Düşük “Execute to Parse %” Nedenleri

1. Literal SQL Kullanımı

SELECT * FROM orders WHERE order_id = 100;  — Her seferinde yeni parse

1. Bağlantı Havuzu Kullanılmaması
   • Her yeni bağlantı yeni bir parse gerektirir
2. Dinamik SQL’lerin Aşırı Kullanımı

EXECUTE IMMEDIATE ‘SELECT * FROM ‘ || table_name;  — Her seferinde yeni parse

1. Shared Pool’un Yetersiz Olması
   • SQL’ler cache’den atılıyor, yeniden parse gerekiyor
2. Uygulamanın Cursor’ları Kapatmaması
   • Aynı SQL tekrar parse ediliyor

Çözüm Önerileri

1. Bind Değişken Kullanımını Zorunlu Hale Getir

ALTER SYSTEM SET CURSOR_SHARING=FORCE;  — Literal’leri otomatik bind değişkene çevir

2. Uygulama Tarafında Bind Değişken Kullan

// Kötü: literal SQL

String sql = “SELECT * FROM users WHERE id = ” + userId;

// İyi: bind değişken

String sql = “SELECT * FROM users WHERE id = ?”;

PreparedStatement stmt = conn.prepareStatement(sql);

stmt.setInt(1, userId);

3. Bağlantı Havuzu Kullan

• Oracle Connection Pool veya UCP kullanarak bağlantıları yeniden kullan

4. Shared Pool’u Optimize Et

— Shared Pool boyutunu artır

ALTER SYSTEM SET SHARED_POOL_SIZE=2G SCOPE=BOTH;

— Büyük PL/SQL’ler için bölge ayır

ALTER SYSTEM SET SHARED_POOL_RESERVED_SIZE=500M SCOPE=BOTH;

5. Aşırı Parse Eden SQL’leri Bul

SELECT sql_id, executions, parse_calls,

       (parse_calls/executions)*100 as parse_ratio

FROM v$sqlarea

WHERE executions > 0

ORDER BY parse_ratio DESC;

İlişkili Diğer AWR Metrikleri

Sonuç

• Execute to Parse % > %80 → Veritabanı SQL’leri verimli kullanıyor
• Execute to Parse % <%60 → Ciddi parse sorunları var, optimizasyon şart
• En iyi çözüm: Bind değişkenler + bağlantı havuzu + shared pool tuning

Bu metrik, uygulama geliştirme kalitesinin bir göstergesidir. Düşük değerler genellikle uygulama kodundaki sorunlardan kaynaklanır.

Parse CPU to Parse Elapsd % :

“Parse CPU to Parse Elapsd %”, Oracle veritabanının parse işlemlerinde ne kadar verimli çalıştığını gösteren kritik bir performans metriğidir. Bu metrik, parse işlemlerinde harcanan CPU zamanının toplam parse süresine oranını ölçer.

Detaylı Açıklama

• Parse CPU Time: Parse işlemleri için harcanan gerçek CPU zamanı
• Parse Elapsed Time: Parse işlemlerinin toplam süresi (CPU + bekleme süreleri)
• Yüksek oran: Parse işlemlerinin çoğunlukla CPU’da gerçekleştiğini (verimli) gösterir
• Düşük oran: Parse sırasında kayda değer bekleme süreleri olduğunu gösterir (sorun)

Hesaplama Formülü

Parse CPU to Parse Elapsd % = (parse time cpu / parse time elapsed) * 100

İdeal Değerler

Düşük Oranın Nedenleri

1. Shared Pool Çekişmesi
   • Çok fazla eşzamanlı parse işlemi
   • Yetersiz shared pool boyutu
2. Library Cache Latch Çekişmesi
   • “library cache latch” ve “shared pool latch” bekleme süreleri
3. Hard Parse Fazlalığı
   • Yeni SQL’lerin sürekli parse edilmesi
4. Yetersiz CPU Kaynakları
   • CPU kuyruğunda bekleme süreleri

Çözüm Önerileri

1. Shared Pool Optimizasyonu

ALTER SYSTEM SET SHARED_POOL_SIZE=4G SCOPE=BOTH;

ALTER SYSTEM SET SHARED_POOL_RESERVED_SIZE=1G SCOPE=BOTH;

2. Bind Değişken Kullanımı

ALTER SYSTEM SET CURSOR_SHARING=FORCE;

3. Aşırı Parse Eden SQL’leri Bul

SELECT sql_id, parse_calls, executions

FROM v$sqlarea

ORDER BY parse_calls DESC;

4. Latch Çekişmesini Azaltma

— “library cache latch” bekleme sorunlarını izle

SELECT * FROM v$latch WHERE name LIKE ‘library cache%’;

5. CPU Kaynaklarını Artırma

• CPU sayısını artırma
• CPU önceliklendirme ayarları

İlişkili Diğer Metrikler

Sonuç

• > %90: Parse işlemleri verimli çalışıyor
• <%70: Parse sırasında ciddi bekleme sorunları var
• Ana çözümler: Shared pool büyütme, bind değişken kullanımı, latch çekişmesini azaltma

Bu metrik, Oracle’ın parse işlemlerindeki verimliliğini anlamak için kritik öneme sahiptir. Düşük değerler, parse işlemleri sırasında kaynak çekişmesi olduğunu gösterir ve mutlaka optimize edilmelidir.

Redo NoWait % :

“Redo NoWait %”, Oracle veritabanının redo log buffer’a erişimde ne kadar bekleme olmadan (nowait) işlem yapabildiğini gösteren önemli bir performans metriğidir. Bu metrik, redo mekanizmasının verimliliğini ölçer.

Detaylı Açıklama

• Redo NoWait %: Redo log buffer’a erişim denemelerinde bekleme olmadan gerçekleşen işlemlerin yüzdesi
• Yüksek değerler: Redo log buffer’ın verimli kullanıldığını gösterir
• Düşük değerler: Redo log buffer’da çekişme (contention) olduğuna işaret eder

Hesaplama Formülü

Redo NoWait % = (redo log space requests / redo entries) * 100

İdeal Değerler

Düşük Oranın Nedenleri

1. Yetersiz Redo Log Buffer Boyutu

SHOW PARAMETER log_buffer

1. LGWR (Log Writer) Sürecinin Yavaş Yazması
   • Yavaş disk I/O
   • Redo log dosyalarının yanlış konfigürasyonu
2. Aşırı DML İşlemi
   • Çok fazla INSERT/UPDATE/DELETE işlemi
3. Büyük Toplu İşlemler
   • Batch job’ların redo buffer’ı tüketmesi

Çözüm Önerileri

1. Redo Log Buffer Boyutunu Artırma

ALTER SYSTEM SET log_buffer=64M SCOPE=SPFILE;

2. Redo Log Dosyalarını Optimize Etme

• Grup sayısını artırma (en az 3 grup)
• Boyutları büyütme (100M-200M arası)
• Hızlı disklerde tutma

3. LGWR Performansını İyileştirme

• Redo log’ları yüksek performanslı disklerde tutma
• ASM kullanımı

4. Büyük İşlemleri Parçalama

— Kötü

INSERT INTO big_table SELECT * FROM huge_source;

— İyi (COMMIT’leri bölerek)

BEGIN

  FOR i IN 1..1000 LOOP

    INSERT INTO big_table SELECT * FROM huge_source WHERE rownum <= 1000;

    COMMIT;

  END LOOP;

END;

İlişkili Diğer Metrikler

Sonuç

• > %99: Redo mekanizması sağlıklı çalışıyor
• <%95: Redo buffer’da ciddi çekişme var
• Ana çözümler: log_buffer büyütme, redo log gruplarını optimize etme, LGWR performansını iyileştirme

Bu metrik, veritabanı yazma performansının önemli bir göstergesidir. Düşük değerler transaction’ların yavaş commit olmasına ve genel performans düşüşüne neden olabilir.

In-memory Sort % :

“In-memory Sort %”, Oracle veritabanının sıralama (sort) işlemlerini ne kadarını bellek içinde (PGA) tamamlayabildiğini gösteren kritik bir performans metriğidir. Bu metrik, disk kullanımı gerektiren pahalı temp alanı işlemlerinden kaçınılıp kaçınılmadığını ölçer.

Detaylı Açıklama

• İdeal Senaryo: Tüm sıralamaların bellek içinde (PGA) tamamlanması (%100)
• Sorunlu Senaryo: Disk temp alanı kullanımı gerektiren sıralamalar (düşük yüzde)
• Disk Sıralaması: temp tablespace kullanımı, performansı ciddi şekilde düşürür

Hesaplama Formülü

In-memory Sort % = (sorts in memory / (sorts in memory + sorts on disk)) * 100

İdeal Değerler

Düşük Oranın Temel Nedenleri

1. Yetersiz PGA Belleği

SHOW PARAMETER pga_aggregate_target

1. Büyük Sıralama İşlemleri
   • Büyük tablolarda ORDER BY, GROUP BY, DISTINCT işlemleri
   • JOIN’lerde hash area boyutunun yetersizliği
2. Optimize Edilmemiş SQL Sorguları
   • Gereksiz sıralama yapan sorgular
   • Uygun indekslerin eksikliği
3. WORKAREA_SIZE_POLICY Yanlış Ayarları

SHOW PARAMETER workarea_size_policy

Optimizasyon Çözümleri

1. PGA Boyutunu Artırma

— Otomatik PGA yönetimi için

ALTER SYSTEM SET pga_aggregate_target=8G SCOPE=BOTH;

— Veya manuel ayar için

ALTER SYSTEM SET workarea_size_policy=MANUAL;

ALTER SYSTEM SET sort_area_size=256M SCOPE=SPFILE;

2. SQL Optimizasyonu

— Sıralama yapan pahalı sorguları bulma

SELECT sql_id, executions, disk_sorts, memory_sorts

FROM v$sqlarea

WHERE disk_sorts > 0

ORDER BY disk_sorts DESC;

3. İndeks Stratejisi Geliştirme

— Sık sıralanan kolonlar için indeks

CREATE INDEX idx_orders_date ON orders(order_date);

4. TEMP Tablespace Optimizasyonu

— Temp alanını büyütme

ALTER TABLESPACE temp ADD TEMPFILE ‘+DATA’ SIZE 10G;

İlişkili Diğer Metrikler

Sonuç ve Öneriler

• <%70 Değerler: Acil müdahale gerektiren ciddi performans sorunu
• Optimizasyon Adımları:
  1. PGA boyutunu kademeli olarak artır
  2. Sıralama yapan sorguları optimize et
  3. Gerekli indeksleri ekle
  4. TEMP alanını SSD’ye taşı

Bu metrik, veritabanı performansının en hassas göstergelerinden biridir. Düşük değerler, uygulama yanıt sürelerinde ciddi artışlara neden olabilir. Özellikle OLAP sistemlerinde %90+ değerler hedeflenmelidir.

Soft Parse % :

“Soft Parse %”, Oracle veritabanının SQL işleme verimliliğini ölçen en kritik metriklerden biridir. Bu oran, parse işlemlerinin ne kadarının “soft parse” (yeniden kullanım) yoluyla gerçekleştiğini gösterir.

Detaylı Açıklama

• Soft Parse: Daha önce parse edilmiş ve shared pool’da bulunan bir SQL’in yeniden kullanılması (düşük maliyetli)
• Hard Parse: Yeni bir SQL’in tamamen parse edilmesi (yüksek CPU maliyetli)
• Yüksek Soft Parse %: Veritabanının SQL’leri verimli şekilde yeniden kullandığını gösterir
• Düşük Soft Parse %: Performans sorunlarına işaret eder

Hesaplama Formülü

Soft Parse % = (soft parses / (soft parses + hard parses)) * 100

İdeal Değerler

Düşük Soft Parse % Nedenleri

1. Literal SQL Kullanımı

SELECT * FROM orders WHERE order_id = 100; — Her seferinde hard parse

1. Bağlantı Havuzu Eksikliği
   • Her yeni bağlantı yeni parse demektir
2. Shared Pool’un Yetersiz Olması

SHOW PARAMETER shared_pool_size

1. Dinamik SQL Kötü Kullanımı

EXECUTE IMMEDIATE ‘SELECT * FROM ‘ || table_name;

1. Cursor Paylaşım Problemi
   • CURSOR_SHARING parametresinin uygun olmaması

Optimizasyon Çözümleri

1. Bind Değişken Kullanımı

— Sistem genelinde zorlama

ALTER SYSTEM SET CURSOR_SHARING=FORCE;

2. Shared Pool Optimizasyonu

ALTER SYSTEM SET SHARED_POOL_SIZE=4G SCOPE=BOTH;

ALTER SYSTEM SET SHARED_POOL_RESERVED_SIZE=1G SCOPE=BOTH;

3. Uygulama Tarafında Optimizasyon

// Kötü örnek (literal)

String sql = “SELECT * FROM users WHERE id = ” + userId;

// İyi örnek (bind değişken)

String sql = “SELECT * FROM users WHERE id = ?”;

PreparedStatement stmt = conn.prepareStatement(sql);

stmt.setInt(1, userId);

4. Aşırı Parse Eden SQL’leri Bulma

SELECT sql_id, executions, parse_calls,

       (parse_calls/executions) as parse_ratio

FROM v$sqlarea

WHERE executions > 0

ORDER BY parse_ratio DESC;

5. Bağlantı Havuzu Kullanımı

• Oracle Connection Pool (UCP) veya üçüncü parti havuzlar kullanın

İlişkili Diğer Metrikler

Sonuç ve Öneriler

• Soft Parse % > %95 olmalıdır
• <%85 değerler ciddi performans kaybı demektir
• Ana çözümler:
  • Bind değişken kullanımı
  • Shared pool büyütme
  • Bağlantı havuzu kullanımı
  • SQL’lerin standartlaştırılması

Not: Soft parse oranını artırmak, Oracle veritabanı performansını doğrudan iyileştiren en etkili yöntemlerden biridir. Bu optimizasyon CPU kullanımını ciddi oranda düşürür.

Latch Hit % :

“Latch Hit %”, Oracle veritabanının dahili bellek yapılarına (SGA) erişimdeki verimliliğini ölçen kritik bir performans göstergesidir. Bu metrik, latch isteklerinin ne kadarının bekleme olmadan (miss olmadan) gerçekleştiğini gösterir.

Detaylı Açıklama

• Latch: Oracle’ın bellek yapılarını korumak için kullandığı hafif kilitleme mekanizması
• Latch Hit: Latch’in ilk denemede elde edilmesi (başarılı)
• Latch Miss: Latch için bekleme gerektiren durum (başarısız)
• Yüksek Latch Hit %: Veritabanının sağlıklı çalıştığını gösterir
• Düşük Latch Hit %: Bellek erişiminde çekişme (contention) olduğunu gösterir

Hesaplama Formülü

Latch Hit % = (1 – (latch misses / latch gets)) * 100

İdeal Değerler

Düşük Latch Hit % Nedenleri

1. Yüksek Eşzamanlılık
   • Çok sayıda kullanıcının aynı bellek alanına erişmeye çalışması
2. “cache buffers chains” Latch Çekişmesi

SELECT * FROM v$latch WHERE name = ‘cache buffers chains’;

1. Yetersiz Shared Pool
   • Library cache latch çekişmesine neden olur
2. Sıcak Bloklar (Hot Blocks)
   • Aynı veri bloğuna çok fazla erişim
3. Yanlış Uygulama Tasarımı
   • Sequence kullanımında sorunlar

Optimizasyon Çözümleri

1. Latch Çekişmesini Analiz Etme

SELECT name, gets, misses, immediate_gets, immediate_misses,

       (misses/(gets+immediate_gets))*100 miss_ratio

FROM v$latch

ORDER BY miss_ratio DESC;

2. “cache buffers chains” Latch Sorunları

— Sıcak blokları bulma

SELECT file#, dbablk, tch FROM x$bh ORDER BY tch DESC;

3. Shared Pool Optimizasyonu

ALTER SYSTEM SET SHARED_POOL_SIZE=4G SCOPE=BOTH;

4. Sequence Optimizasyonu

— NOORDER yerine ORDER kullanımı

CREATE SEQUENCE seq_orders CACHE 100;

5. Uygulama Tasarımı İyileştirme

• Sıcak tabloları parçalama (partitioning)
• Reverse key index kullanımı

Önemli Latch Türleri

Sonuç ve Öneriler

• Latch Hit % > %99 olmalıdır
• <%98 değerler performans sorununa işaret eder
• Ana çözümler:
  • Sıcak blokların tespiti ve ortadan kaldırılması
  • Shared pool optimizasyonu
  • Uygulama tasarımının gözden geçirilmesi
  • Sequence ayarlarının iyileştirilmesi

Not: Latch çekişmeleri, Oracle veritabanında en zor teşhis edilen ve çözülen performans sorunlarından biridir. Düşük Latch Hit % değerleri, ölçeklenebilirliği ciddi şekilde etkiler.

% Non-Parse CPU :

“% Non-Parse CPU”, Oracle veritabanının CPU kaynaklarının ne kadarının SQL parse işlemleri DIŞINDAKİ gerçek iş yükü için kullanıldığını gösteren kritik bir performans metriğidir.

Detaylı Açıklama

• Non-Parse CPU: Parse dışındaki tüm veritabanı işlemleri için harcanan CPU zamanı (sorgu yürütme, transaction işleme, PL/SQL çalıştırma vb.)
• Parse CPU: SQL ifadelerinin ayrıştırılması (parsing) için harcanan CPU zamanı
• Yüksek % Non-Parse CPU: CPU’nun çoğunun veri işleme için kullanıldığını gösterir (İYİ)
• Düşük % Non-Parse CPU: CPU’nun çoğunun parse işlemlerine harcandığını gösterir (KÖTÜ)

Hesaplama Formülü

% Non-Parse CPU = (CPU used by this session – parse time cpu) / CPU used by this session * 100

İdeal Değerler

Düşük % Non-Parse CPU Nedenleri

1. Literal SQL Kullanımı

SELECT * FROM orders WHERE order_id = 100; — Her seferinde parse gerektirir

1. Bağlantı Havuzu Eksikliği
   • Her yeni bağlantı yeni parse demektir
2. Shared Pool Sorunları

SHOW PARAMETER shared_pool_size

1. Sık Sık Hard Parse
   • Yeni SQL’lerin sürekli parse edilmesi
2. Cursor Paylaşım Problemi
   • CURSOR_SHARING parametresinin uygun olmaması

Optimizasyon Çözümleri

1. Bind Değişken Kullanımı

— Sistem genelinde zorlama

ALTER SYSTEM SET CURSOR_SHARING=FORCE;

2. Shared Pool Optimizasyonu

ALTER SYSTEM SET SHARED_POOL_SIZE=4G SCOPE=BOTH;

3. Uygulama Tarafında Optimizasyon

// Kötü örnek (literal)

String sql = “SELECT * FROM users WHERE id = ” + userId;

// İyi örnek (bind değişken)

String sql = “SELECT * FROM users WHERE id = ?”;

PreparedStatement stmt = conn.prepareStatement(sql);

stmt.setInt(1, userId);

4. Parse Eden SQL’leri Analiz Etme

SELECT sql_id, parse_calls, executions,

       (parse_calls/executions) as parse_ratio

FROM v$sqlarea

WHERE executions > 0

ORDER BY parse_ratio DESC;

5. Bağlantı Havuzu Kullanımı

• Oracle Connection Pool (UCP) veya üçüncü parti havuzlar kullanın

İlişkili Diğer Metrikler

Sonuç ve Öneriler

• % Non-Parse CPU > %95 olmalıdır
• <%90 değerler ciddi parse sorunlarına işaret eder
• Ana çözümler:
  • Bind değişken kullanımı
  • Shared pool optimizasyonu
  • Bağlantı havuzu kullanımı
  • SQL’lerin standartlaştırılması

Önemli Not: % Non-Parse CPU değerini artırmak, Oracle veritabanının gerçek iş yükü için daha fazla CPU kaynağı ayırmasını sağlar ve genel performansı önemli ölçüde iyileştirir.

Flash Cache Hit % :

Oracle AWR (Automatic Workload Repository) raporlarında görülen Flash Cache Hit % metriği, Oracle Database’in Flash Cache (önceden “Smart Flash Cache” olarak bilinir) kullanımının ne kadar etkili olduğunu gösteren bir performans ölçütüdür.

Detaylı Açıklama

Flash Cache Hit %, veritabanının disk yerine flash önbellekten okuma yapma başarısını yüzde olarak ifade eder. Bu metrik, flash önbelleğin veritabanı performansına ne kadar katkı sağladığını gösterir.

• Yüksek değerler (%90 üzeri): Flash önbelleğin etkili şekilde kullanıldığını, disk I/O’sunun azaldığını gösterir.
• Düşük değerler: Flash önbelleğin yeterince kullanılmadığını veya boyutunun yetersiz olduğunu gösterir.

Hesaplama Formülü

Flash Cache Hit % = (Flash Cache Hits / (Flash Cache Hits + Disk Reads)) * 100

Önemli Noktalar

1. Bu metrik yalnızca Oracle Database’in Flash Cache özelliği etkinleştirilmişse ve kullanılıyorsa anlamlıdır.
2. Flash Cache genellikle Exadata sistemlerinde veya Oracle’ın önerdiği belirli flash depolama çözümlerinde kullanılır.
3. Bu metrik, buffer cache hit ratio’dan farklıdır; buffer cache RAM’de, flash cache ise flash depolamada bulunur.

Flash Cache Hit % değerini iyileştirmek için flash önbellek boyutunu artırmayı veya sorgu desenlerini optimize etmeyi düşünebilirsiniz.