Kenapa Query Cepat Tapi Procedure PL/SQL Terasa Lambat?

 Pernah ngalamin ini?

• Query dijalankan langsung → cepat

• Query yang sama dimasukin ke procedure → kok lama?

Awalnya saya juga mikir:

“Ah, mungkin database lagi sibuk.”

Ternyata… sering kali bukan itu masalahnya.

---

Kasus Nyata yang Sering Terjadi

Query ini kalau dijalankan langsung:

SELECT *
FROM orders
WHERE order_date >= SYSDATE - 7;

Hasilnya cepat.
Tapi begitu dimasukkan ke procedure:

CREATE OR REPLACE PROCEDURE get_orders IS
  CURSOR c_orders IS
    SELECT *
    FROM orders
    WHERE order_date >= SYSDATE - 7;

  v_rec c_orders%ROWTYPE;
BEGIN
  OPEN c_orders;
  LOOP
    FETCH c_orders INTO v_rec;
    EXIT WHEN c_orders%NOTFOUND;
    -- proses data
  END LOOP;
  CLOSE c_orders;
END;

Dipanggil… dan terasa lambat.

---

Penyebab #1: Loop Baris per Baris (Row by Row)

Ini jebakan klasik PL/SQL.

Query SQL:

• Diproses set-based

• Dioptimasi oleh Oracle

Loop PL/SQL:

• Diproses baris per baris

• Jauh lebih berat kalau datanya banyak

Di dunia PL/SQL, ini sering disebut:

“Slow by Slow”

---

Penyebab #2: Terlalu Banyak Logic di Dalam Loop

Kadang tanpa sadar, di dalam loop kita taruh:

• SELECT tambahan

• IF bertingkat

• UPDATE per baris

Contoh jebakan:

LOOP
  FETCH c_orders INTO v_rec;
  EXIT WHEN c_orders%NOTFOUND;

  SELECT status
  INTO v_status
  FROM customers
  WHERE customer_id = v_rec.customer_id;

END LOOP;

Kalau cursor berisi 10.000 baris, berarti:
👉 10.000 SELECT tambahan

---

Penyebab #3: Cursor Padahal Bisa SQL Murni

Banyak logic yang sebenarnya bisa ditarik ke SQL langsung.

Daripada:

• Cursor

• Loop

• Logic manual

Sering kali cukup:

INSERT INTO report_table
SELECT ...
FROM orders o
JOIN customers c ON ...
WHERE ...

Lebih singkat.
Lebih cepat.
Lebih ramah performa.

---

Catatan Pengalaman Kerja

Di satu project lama, ada procedure yang:

• Jalan 20 menit

• Server kelihatan “sibuk”

Setelah dicek:

• Ada loop

• Di dalamnya ada SELECT

• Di dalam SELECT ada function PL/SQL lain

Setelah diubah ke SQL murni:
👉 Waktu turun jadi kurang dari 1 menit

Dan lucunya, logic-nya jadi lebih pendek.

---

Prinsip yang Selalu Saya Pegang

Kalau kerja pakai PL/SQL, saya selalu tanya ke diri sendiri:

1. Ini bisa pakai SQL saja nggak?

2. Ini perlu loop atau cuma kebiasaan lama?

3. Ada SELECT di dalam loop?

Kalau jawabannya “iya”, biasanya di situ sumber lambatnya.

---

Penutup

PL/SQL itu kuat, tapi bukan berarti semua masalah harus diselesaikan dengan loop.

Kadang:

• Kurang kode

• Lebih SQL
  justru hasilnya lebih baik.

Catatan berikutnya kemungkinan bahas:

• BULK COLLECT & FORALL (versi santai, bukan textbook)

• Atau debugging procedure yang “diam tapi makan resource”

Sampai catatan Rabu berikutnya 👋