Akar Masalah: Mekanisme Invalidasi dan Latch Contention

Oracle Server Result Cache menyimpan hasil eksekusi query SQL dan fungsi PL/SQL di SGA (System Global Area). Saat sebuah query menggunakan Result Cache, Oracle membuat pointer dependensi antara entri cache dan segmen objek database yang diakses (tabel atau partisi).

Ketika transaksi melakukan operasi DML (INSERT, UPDATE, DELETE) dan melakukan COMMIT pada tabel terkait, Oracle menandai seluruh entri cache yang bergantung pada tabel tersebut sebagai Invalid. Proses invalidasi dan realokasi blok memori di Result Cache dilindungi oleh latch memori tunggal atau tersentralisir: Result Cache: Latch (atau latch: Result Cache: RC Latch).

Pada sistem OLTP dengan mutasi data berfrekuensi tinggi, invalidasi berulang memicu perebutan latch yang intensif:

  • Proses DML memerlukan latch eksklusif untuk mendepresiasi dan menghapus entri cache.
  • Sesi query yang masuk secara serentak (read concurrency) memerlukan latch untuk memeriksa validitas cache dan mengalokasikan memori baru guna menyimpan hasil query ulang (thundering herd problem).
  • Hasilnya: Antrean worker memanjang, waktu tunggu CPU melonjak drastis, dan throughput database turun signifikan akibat pemblokiran berantai.

Diagnosa Menggunakan Dynamic Performance Views

Identifikasi apakah Result Cache menjadi bottleneck menggunakan view performa bawaan Oracle.

1. Evaluasi Status Statistik Global

Jalankan query berikut pada V$RESULT_CACHE_STATISTICS untuk memeriksa rasio hit, invalidasi, dan konsumsi memori:

SELECT name, value
FROM v$result_cache_statistics
WHERE name IN (
    'Cache Size (bytes)',
    'Block Size (bytes)',
    'Create Count',
    'Find Count',
    'Invalidations',
    'Delete Count'
);

Evaluasi metrik:

  • Jika nilai Invalidations mendekati atau melampaui Find Count, cache bekerja kontra-produktif. Sistem menghabiskan lebih banyak resource untuk menghapus cache daripada menyajikan data dari memori.
  • Jika Delete Count tinggi bersamaan dengan lonjakan invalidasi, terjadi churn memori tinggi yang memicu fragmentasi pada Result Cache pool.

2. Identifikasi Objek Dependensi Pemicu Invalidasi

Gunakan V$RESULT_CACHE_OBJECTS untuk menemukan tabel mana yang paling sering memicu pembersihan cache:

SELECT 
    id,
    type,
    name,
    status,
    invalidations,
    space_overhead,
    space_unused
FROM v$result_cache_objects
WHERE type = 'Dependency'
ORDER BY invalidations DESC
FETCH FIRST 10 ROWS ONLY;

Tabel dengan nilai invalidations tertinggi adalah sumber contention. Objek-objek ini tidak boleh dilibatkan dalam Result Cache.

Langkah Remediasi Operasional

1. Normalisasi Konfigurasi RESULT_CACHE_MODE

Pastikan mode global tidak diatur ke FORCE. Nilai FORCE memaksa Oracle mencoba mencache semua query yang memenuhi syarat, termasuk tabel transaksi cepat.

ALTER SYSTEM SET result_cache_mode = 'MANUAL' SCOPE=BOTH;

Nilai MANUAL memastikan caching hanya terjadi jika query secara eksplisit menggunakan hint /*+ RESULT_CACHE */.

2. Bypass Cache pada Query Tabel Volatil via Hint

Jika ada query yang secara default mewarisi perilaku caching atau dieksekusi di lingkungan batch dengan mutasi tinggi, gunakan hint NO_RESULT_CACHE untuk membebaskan akses dari Result Cache latch:

SELECT /*+ NO_RESULT_CACHE */ 
    order_id, customer_id, total_amount
FROM orders
WHERE status = 'PROCESSING';

Query tersebut akan langsung membaca data dari Buffer Cache tanpa membebani latch Result Cache.

3. Mitigasi Darurat: Nonaktifkan Result Cache

Saat latch contention melumpuhkan database produksi akibat lonjakan DML tak terduga, nonaktifkan Result Cache secara dinamis tanpa restart instance dengan menyetel ukurannya ke 0:

ALTER SYSTEM SET result_cache_max_size = 0 SCOPE=BOTH;

Langkah ini menonaktifkan mekanisme Result Cache seketika. Seluruh sesi worker akan berhenti mengantre pada Result Cache: Latch dan dialihkan kembali ke eksekusi SQL standar melalui Buffer Cache.

4. Isolasi Workload dan Alternatif Arsitektur

Terapkan aturan pemisahan beban kerja:

  • Batasi Penggunaan: Gunakan Result Cache hanya pada tabel statis atau semi-statis (misal: tabel konfigurasi sistem, tabel referensi wilayah) di mana rasio read-to-write minimal 100:1.
  • Gunakan Buffer Cache Standar: Untuk query yang membaca tabel dinamis, optimalkan indeks dan biarkan data dilayani oleh Buffer Cache. Buffer Cache menggunakan algoritma hashing dan latching yang didistribusikan ke ratusan cache buffers chains latches, jauh lebih scalable dibanding struktur Result Cache.
  • Gunakan Materialized View: Jika data agregasi dari tabel volatil tetap perlu diakses cepat, pertimbangkan Materialized View dengan refresh terjadwal (on demand) di luar jam sibuk alih-alih Result Cache real-time.