Arsitektur Skala Oracle: Trade-off RAC vs Active Data Guard

Menentukan strategi skalabilitas dan ketersediaan tinggi (High Availability) pada Oracle Database sering kali bermuara pada perbandingan dua solusi utama: Oracle Real Application Clusters (RAC) dan Oracle Active Data Guard (ADG). Keduanya memiliki filosofi desain yang sangat bertolak belakang. RAC mengusung pendekatan shared-everything untuk penskalaan komputasi horizontal dalam satu lokasi fisik, sedangkan Active Data Guard menggunakan arsitektur shared-nothing dengan replikasi fisik asinkron atau sinkron antar-mesin independen.

Kesalahan umum dalam perancangan sistem adalah memperlakukan RAC sebagai solusi penskalaan tulis (write scaling) universal atau menganggap ADG hanya sebagai cadangan pasif untuk pemulihan bencana (Disaster Recovery). Keputusan arsitektur yang keliru berisiko membebani latensi jaringan privat, memunculkan ancaman split-brain, hingga melipatgandakan biaya lisensi tanpa peningkatan throughput yang sepadan.

Mekanisme Fundamental: Cache Fusion vs Redo Transport

Perbedaan performa antara RAC dan ADG berakar pada unit data yang ditransmisikan melintasi jaringan infrastruktur.

Oracle RAC: Cache Fusion dan Beban Jaringan Interconnect

Oracle RAC mengizinkan multi-instance mengakses satu set file database yang sama secara simultan. Konsistensi blok data antar-instance dikelola oleh subsistem Cache Fusion melalui Global Cache Service (GCS) dan Global Enqueue Service (GES). Ketika Instance A membutuhkan blok data yang sedang dimodifikasi oleh Instance B di buffer cache-nya, blok tersebut langsung ditransfer melalui jaringan privat (interconnect) tanpa melalui disk I/O.

Mekanisme ini menuntut latensi jaringan sub-milidetik. Jika beberapa instance melakukan pembaruan konkuren pada tabel atau indeks yang sama (fenomena buffer busy wait atau block bouncing), latensi interconnect akan mendominasi waktu eksekusi kueri. Diagnostik performa RAC sering berpusat pada event penantian gc (Global Cache), seperti gc cr block receive time atau gc current block busy.

-- Memeriksa degradasi latensi Interconnect pada RAC
SELECT inst_id, event, total_waits, time_waited_micro / total_waits AS avg_wait_us
FROM gv$system_event
WHERE event LIKE 'gc%'
ORDER BY avg_wait_us DESC;

Active Data Guard: Asynchronous/Synchronous Redo Transport

Active Data Guard menduplikasi transaksi dengan mereplikasi catatan log biner (redo stream) dari database primer ke database siaga (standby) fisik. Proses Log Network Server (LNS/NSS) mengirimkan redo vector melalui jaringan TCP standar ke Remote File Server (RFS) pada target standby. Database standby dibuka dalam status Read-Only with Apply, memproses Redo Apply (Media Recovery) secara terus-menerus sambil tetap melayani kueri pembacaan data konsisten.

Berbeda dari RAC yang sensitif terhadap konkurensi tingkat blok data, performa sistem primer pada ADG terisolasi jika menggunakan mode transport ASYNC. Dalam mode SYNC (Maximum Protection atau Maximum Availability), komit transaksi primer tertahan sampai redo berhasil ditulis ke standby redo log target. Beban utama pada ADG bukan latensi per-blok, melainkan apply lag dan transport lag.

-- Memeriksa lag replikasi pada Active Data Guard Standby
SELECT name, value, unit
FROM v$dataguard_stats
WHERE name IN ('transport lag', 'apply lag');

Trade-off Teknis: Kompleksitas Shared Storage vs Isolasi Hardware

Penyimpanan Bersama (ASM) dan Risiko Split-Brain pada RAC

RAC bergantung secara mutlak pada lapisan penyimpanan bersama (biasanya dikelola melalui Oracle Automatic Storage Management atau ASM) yang diakses oleh seluruh node. Konsekuensinya:

• Titik Kegagalan Tunggal (Single Point of Failure): Kerusakan pada SAN array, fiber channel switch, atau korupsi metadata ASM tingkat diskgroup dapat menghentikan seluruh node cluster sekaligus.
• Fencing dan Split-Brain: Cluster Synchronization Services (CSS) memantau detak jantung (heartbeat) node melalui interconnect dan voting disk. Apabila terjadi partisi jaringan (network partition), CSS harus memutus (fence) salah satu node secara paksa (node evict/reboot) untuk mencegah terjadinya korupsi blok data bersama.

Isolasi Total pada Active Data Guard

ADG beroperasi di atas prinsip isolasi penuh. Server standby memiliki CPU, memori, operating system kernel, dan array storage yang benar-benar terpisah. Kegagalan I/O storage primer tidak memengaruhi standby. Demikian juga kesalahan operasional manusia (seperti DROP TABLE yang tidak disengaja) dapat ditanggulangi dengan Flashback Database pada standby tanpa mematikan layanan primer secara langsung.

Siklus Pemeliharaan: Rolling Patch vs Switchover

Rolling Maintenance pada RAC

Secara teori, Oracle RAC memungkinkan rolling patch menggunakan OPatchAuto. Satu node dinonaktifkan, di-patch, dan diaktifkan kembali tanpa downtime aplikasi global. Namun penerapannya memiliki batasan teknis:

• Patch yang memodifikasi struktur kamus data internal (data dictionary) atau metadata clusterware sering kali tetap membutuhkan penghentian kluster penuh (non-rolling patch).
• Selama eksekusi rolling patch, kapasitas komputasi kluster tereduksi, berisiko menyebabkan beban berlebih pada node yang tersisa jika sizing kapasitas berada pada batas atas.

Standby-First Patching dan Switchover pada ADG

Dengan Active Data Guard, pembaruan versi (khususnya Patch Set Update/Release Update) dapat diterapkan menggunakan metode Standby-First Patching. Patch diaplikasikan terlebih dahulu pada database standby. Setelah stabilitasnya tervalidasi via kueri read-only, eksekusi graceful switchover dijalankan. Operasi ini menukar peran standby menjadi primer, dengan interupsi koneksi yang umumnya berada di bawah rentang 30–60 detik, meminimalkan jendela risiko sistem produksi.

Pola Beban Kerja: Write-Intensive OLTP vs Read Offloading

Write-Intensive OLTP: Kapan Memilih RAC?

RAC tidak meningkatkan batas throughput tulis (write scalability) dari sebuah tabel tunggal yang sangat aktif. Jika arsitektur aplikasi menjalankan ribuan transaksi konkuren yang memodifikasi baris pada data block dan leaf block indeks yang sama, pemindahan blok melalui Cache Fusion akan menjadi bottleneck kritis. RAC ideal untuk:

• High Availability lokal: Failover koneksi transparan menggunakan Fast Application Notification (FAN) dan Application Continuity (AC).
• Beban transaksi dengan partisi logis: Transaksi yang mengakses segmen partisi berbeda pada masing-masing instance dapat membagi beban CPU/memori tanpa menimbulkan contention transfer blok.

Read-Intensive dan Reporting: Efektivitas Active Data Guard

Menempatkan kueri reporting analitik yang berat (full table scans, multi-way joins, aggregasi) ke dalam RAC dapat merusak buffer cache node transaksi OLTP karena terjadinya pertukaran blok data besar-besaran. ADG menjadi arsitektur definitif untuk skenario ini:

• Query Offloading: Beban reporting, dashboard operasional, ekspor ETL, dan backup RMAN dialihkan 100% ke standby database yang dibuka READ ONLY.
• Redirection DML: Sejak Oracle 19c, Active Data Guard mendukung fitur DML Redirection. Operasi sisip/perbarui kecil pada node standby diteruskan ke primer secara transparan, sementara hasil kueri dievaluasi langsung di standby, menyederhanakan konfigurasi koneksi pool aplikasi.

Evaluasi Biaya Operasional dan Lisensi Per-Core

Model lisensi Oracle menuntut perhitungan cermat berbasis prosesor (Processor License Factor, umumnya 0.5 untuk prosesor multi-core modern seperti Intel/AMD x86_64).

• Oracle RAC: Mengharuskan pembelian lisensi Oracle Database Enterprise Edition (EE) ditambah Oracle Real Application Clusters Option untuk setiap core pada semua node di dalam cluster. Biaya lisensi melonjak proporsional dengan jumlah server komputasi aktif.
• Active Data Guard: Mengharuskan lisensi Oracle Database Enterprise Edition pada server primer dan standby, ditambah opsi Oracle Active Data Guard pada kedua sistem. Database standby tradisional (tanpa ADG, hanya Redo Apply pasif) tidak membutuhkan opsi tambahan ADG, tetapi status read-only konkuren saat apply otomatis mewajibkan opsi ini.

Dari segi TCO, jika tujuan arsitektur adalah mengamankan sistem dari kegagalan server sekaligus mengisolasi beban analitik, ADG memberikan rasio efisiensi biaya yang jauh lebih tinggi dibanding RAC multi-node yang terkendala interconnect.

Matriks Keputusan Arsitektur

Gunakan matriks objektif berikut untuk memvalidasi pilihan arsitektur database:

Kesimpulan dan Panduan Penerapan

Pilihlah Oracle RAC jika aplikasi memerlukan ketersediaan komputasi yang tidak boleh putus sama sekali saat server mengalami kegagalan hardware, pola beban kerja terdistribusi dengan interaksi data yang terpisah secara partisi, dan infrastruktur memiliki shared storage berperforma tinggi dengan jaringan interconnect berkecepatan tinggi.

Sebaliknya, terapkan Active Data Guard jika prioritas utama adalah ketahanan bencana sejati (DRP), isolasi beban kueri analitik dan pencadangan dari sistem transaksi operasional, serta kebutuhan untuk menerapkan maintenance patching dengan risiko gangguan minimum terhadap beban kerja produksi.