Model lisensi Oracle Enterprise Edition (EE) dihitung berdasarkan kapasitas CPU core fisik atau virtual pada level host. Menjalankan banyak dedicated instance pada host atau virtual machine terpisah melipatgandakan kebutuhan lisensi per-core. Arsitektur Oracle Multitenant (Pluggable Database/PDB) memangkas pengeluaran ini dengan mengonsolidasikan beberapa database ke dalam satu Container Database (CDB). Namun, konsolidasi memperkenalkan risiko persaingan resource (noisy neighbor) dan ketergantungan siklus pemeliharaan sistem.

Model Biaya Lisensi: Multitenant vs Dedicated Instance

Oracle menerapkan metrik Processor Core Factor (misalnya faktor 0,5 untuk arsitektur Intel/AMD x86-64 modern). Dalam skenario 4 database independen:

  • Dedicated VM/Host: Jika setiap database diisolasi pada VM 4-core terpisah tanpa hard partitioning tersertifikasi, Oracle mewajibkan lisensi dihitung dari total core fisik cluster. Jika menggunakan bare-metal terpisah (masing-masing 4 core), total lisensi yang dibutuhkan: 4 node x 4 core x 0.5 = 8 Processor Licenses.
  • Konsolidasi Multitenant: Menggabungkan 4 PDB ke dalam 1 CDB pada server 8-core fisik hanya membutuhkan: 8 core x 0.5 = 4 Processor Licenses.

Catatan Lisensi: Sejak Oracle 19c, Oracle mengizinkan penggunaan hingga 3 user PDB per CDB tanpa lisensi opsi Oracle Multitenant tambahan. Jika konsolidasi melampaui 3 PDB per CDB, opsi lisensi Multitenant harus dibeli untuk host tersebut.

Resource Governance: Mengatasi Noisy Neighbor

Tantangan utama konsolidasi adalah satu PDB yang menjalankan kueri analitik berat dapat menguras CPU, IOPS, dan System Global Area (SGA), sehingga merusak latensi transaksi pada PDB lain. Kontrol resource dilakukan melalui dua level: Oracle Resource Manager (CDB Resource Plan) dan parameter instance individual per PDB.

1. Konfigurasi CDB Resource Plan

Gunakan package DBMS_RESOURCE_MANAGER di CDB$ROOT untuk mengalokasikan bobot (shares) dan batas penggunaan CPU maksimum (utilization_limit).

-- Jalankan pada CDB$ROOT sebagai SYSDBA
BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
    plan    => 'cdb_prod_plan',
    comment => 'Plan konsolidasi resource governance untuk PDB'
  );

  -- PDB_CORE: Workload transaksi kritis (prioritas tinggi)
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'cdb_prod_plan',
    pluggable_database    => 'PDB_CORE',
    shares                => 3,
    utilization_limit     => 70
  );

  -- PDB_REPORTING: Workload batch/analitik (dibatasi ketat)
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'cdb_prod_plan',
    pluggable_database    => 'PDB_REPORTING',
    shares                => 1,
    utilization_limit     => 30
  );

  -- Kebijakan default untuk PDB lain
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'cdb_prod_plan',
    pluggable_database    => 'ORA$DEFAULT_PDB_DIRECTIVE',
    shares                => 1,
    utilization_limit     => 40
  );

  DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

-- Terapkan plan pada instance
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'cdb_prod_plan' SCOPE = BOTH;

2. Limitasi I/O dan Memori per PDB

Mulai Oracle 12.2+, batas I/O dan memori dapat dikonfigurasi langsung di dalam konteks PDB tanpa memengaruhi PDB tetangga:

-- Beralih ke konteks PDB tertentu
ALTER SESSION SET CONTAINER = PDB_REPORTING;

-- Batasi I/O agar tidak mendegradasi disk subsystem
ALTER SYSTEM SET MAX_IOPS = 2500 SCOPE = BOTH;
ALTER SYSTEM SET MAX_MBPS = 150 SCOPE = BOTH;

-- Batasi alokasi target SGA untuk PDB ini
ALTER SYSTEM SET SGA_TARGET = 8G SCOPE = BOTH;
ALTER SYSTEM SET CPU_COUNT = 4 SCOPE = BOTH;

Operasional Patching: CDB-Level vs PDB Unplug/Plug

Isolasi operasional menjadi titik lemah terbesar konsolidasi.

CDB-Level Patching (Tradisional)

Menerapkan Release Update (RU) pada CDB memengaruhi seluruh PDB di dalamnya. Eksekusi datapatch memperbarui kamus data untuk CDB$ROOT dan seluruh PDB secara berurutan. Jika terdapat 20 PDB dalam satu CDB, waktu pemeliharaan (downtime window) menjadi panjang dan risiko kegagalan patch berdampak sistemik pada semua aplikasi.

PDB Unplug/Plug (Rolling Migration)

Untuk menghindari all-or-nothing downtime, gunakan arsitektur CDB target:

  1. Siapkan CDB target baru (CDB_NEW) dengan level patch yang sudah diperbarui.
  2. Unplug PDB dari CDB_OLD: ALTER PLUGGABLE DATABASE pdb_core UNPLUG INTO '/opt/oracle/pdb_core.xml';
  3. Tutup dan drop metadata dari CDB_OLD.
  4. Plug ke CDB_NEW: CREATE PLUGGABLE DATABASE pdb_core USING '/opt/oracle/pdb_core.xml' NOCOPY;
  5. Jalankan datapatch -pdbs pdb_core hanya untuk PDB tersebut.

Pendekatan ini memisahkan jadwal rilis antar-aplikasi, namun membutuhkan kapasitas storage dan CPU ekstra untuk menjalankan dua CDB secara paralel selama masa transisi.

Checklist Pengambilan Keputusan Arsitektur

Gunakan panduan berikut untuk menentukan apakah beban kerja harus dikonsolidasikan ke PDB atau tetap menggunakan Dedicated Instance:

  • Pilih Konsolidasi PDB jika:
    • Beban kerja didominasi oleh transaksi OLTP berskala kecil hingga menengah dengan pola pemakaian CPU bergelombang (spiky).
    • Anggaran lisensi software terbatas dan organisasi ingin menekan rasio core-to-database.
    • Tim database engineering memiliki automasi untuk unplug/plug PDB guna mitigasi dependensi patching.
    • Persyaratan SLA downtime antar-aplikasi dapat disinkronkan atau didelegasikan via teknik PDB relocate.
  • Pilih Dedicated Standalone Instance jika:
    • Aplikasi memerlukan modifikasi level instance yang tidak didukung pada level PDB (misalnya parameter non-PDB modifiable atau integrasi third-party agent pada level OS/SGA khusus).
    • Beban kerja berskala ekstrim (misal: Data Warehouse masif) yang membutuhkan saturasi CPU dan memory bus 100% tanpa risiko terganggu thread background lain.
    • Regulasi kepatuhan data (seperti PCI-DSS atau audit industri militer) mewajibkan isolasi total pada layer memori kernel dan storage mount level OS.
    • Jadwal maintenance dan patching antar-aplikasi bertolak belakang secara radikal dan tidak memungkinkan koordinasi CDB.