Cursor vs SELECT Langsung: Saya Dulu Sering Salah Pilih

 Kalau sudah lama ngoding PL/SQL, cursor itu terasa “alami”.

Rapi, terstruktur, dan kelihatan profesional.

Masalahnya… tidak selalu perlu.

---

Contoh Pola yang Dulu Sering Saya Pakai

FOR rec IN (
  SELECT employee_id, salary
  FROM employees
) LOOP
  DBMS_OUTPUT.PUT_LINE(rec.employee_id || ' - ' || rec.salary);
END LOOP;

Tidak salah.
Tapi sering kali overkill.

---

Kasus Nyata

Di satu proses report:

• Datanya ribuan

• Hasilnya cuma dipindahkan ke tabel lain

Tetap pakai cursor + loop.

Hasilnya:

• Jalan

• Tidak error

• Tapi lambat

---

Alternatif yang Lebih Sederhana

Kalau tujuannya cuma memindahkan atau memproses data massal:

INSERT INTO report_table (employee_id, salary)
SELECT employee_id, salary
FROM employees;

Tanpa loop.
Tanpa cursor.
Lebih ramah performa.

---

Kapan Cursor Masih Masuk Akal?

Cursor masih penting kalau:

• Ada logic kompleks per baris

• Banyak IF / kondisi khusus

• Proses per record memang beda-beda

Tapi kalau:

• Logic sama

• Datanya banyak

• Bisa diselesaikan SQL

Cursor biasanya bukan pilihan terbaik.

---

Kesalahan yang Dulu Sering Saya Lakukan

Saya dulu sering mikir:

“Kalau pakai cursor, berarti lebih aman.”

Padahal:

• Aman ≠ efisien

• Rapi ≠ cepat

Setelah beberapa kali kena masalah performa,
saya mulai biasakan:

SQL dulu, cursor belakangan.

---

Prinsip Sederhana yang Sekarang Saya Pakai

Sebelum pakai cursor, saya selalu tanya:

1. Bisa pakai satu SQL?

2. Perlu loop?

3. Datanya besar atau kecil?

Kalau jawabannya:

• Bisa SQL

• Tidak perlu loop

• Data besar

👉 cursor saya coret.

---

Penutup

Cursor bukan musuh.
Tapi juga bukan solusi untuk semua hal.

PL/SQL itu soal memilih alat yang pas,
bukan sekadar yang paling familiar.

Sampai catatan Rabu berikutnya 👋

Read More

COMMIT di Dalam Loop: Jalan, Tapi Diam-Diam Berbahaya

 Ini salah satu kebiasaan lama yang sering “lolos review”.

Procedure:

• Jalan normal

• Tidak error

• Bahkan terasa aman

Padahal… dampaknya bisa panjang.

---

Contoh yang Sering Saya Temui

FOR rec IN (
  SELECT order_id
  FROM orders
  WHERE status = 'NEW'
) LOOP

  UPDATE orders
  SET status = 'PROCESS'
  WHERE order_id = rec.order_id;

  COMMIT;
END LOOP;

Secara logika:

• Setiap data langsung disimpan

• Kalau gagal, yang lain sudah aman

Secara sistem:
👉 ini mimpi buruk performa

---

Kenapa COMMIT di Loop Itu Bermasalah?

Setiap COMMIT:

• Menulis redo log

• Melepas undo

• Sinkron ke disk

Kalau loop:

• 1.000 baris → 1.000 COMMIT

• 10.000 baris → 10.000 COMMIT

Tidak heran kalau:

• I/O naik

• Session lain melambat

• Database terasa “berat”

Dan tidak ada error sama sekali.

---

“Tapi Saya Takut Datanya Setengah Jalan…”

Ini alasan paling sering.

Dan memang valid dalam kasus tertentu.

Tapi sebelum taruh COMMIT di loop, tanyakan dulu:

1. Apakah datanya benar-benar besar?

2. Apakah bisa di-rollback bersama?

3. Apakah failure-nya sering?

Sering kali jawabannya: tidak.

---

Pola yang Lebih Aman

Kalau memungkinkan:

FOR rec IN (
  SELECT order_id
  FROM orders
  WHERE status = 'NEW'
) LOOP
  UPDATE orders
  SET status = 'PROCESS'
  WHERE order_id = rec.order_id;
END LOOP;

COMMIT;

Atau lebih baik lagi:

UPDATE orders
SET status = 'PROCESS'
WHERE status = 'NEW';

COMMIT;

Satu commit.
Lebih bersih.
Lebih ringan.

---

Kapan COMMIT di Loop Masih Masuk Akal?

Ada, tapi jarang.

Biasanya kalau:

• Proses sangat panjang (jam-an)

• Data independen per baris

• Failure sebagian masih bisa diterima

Dan itupun:

• Commit per batch (misalnya tiap 1.000 baris)

• Bukan setiap baris

---

Catatan Pengalaman Kerja

Saya pernah menemukan job malam yang:

• Tidak pernah error

• Tapi membuat backup melambat

Setelah dicek:

• Ada COMMIT di loop

• Data puluhan ribu

Setelah diubah:

• Commit per batch

• Waktu eksekusi turun drastis

• Beban server lebih stabil

---

Prinsip yang Saya Pegang Sekarang

Kalau lihat:

• COMMIT di loop
  dan

• Data bukan kecil

Saya langsung curiga.

Bukan salah,
tapi sering tidak perlu.

---

Penutup

COMMIT itu penting,
tapi tempatnya juga penting.

PL/SQL bukan cuma soal “jalan atau tidak”,
tapi soal bagaimana dampaknya ke sistem.

Sampai catatan Rabu berikutnya 👋

Read More

Procedure Tidak Error, Tapi Server Terasa Berat — Ternyata Ini Penyebabnya

 Ini tipe masalah yang paling bikin curiga.

• Tidak ada error

• Tidak ada rollback

• Log kelihatan normal

Tapi:

• Server terasa berat

• Session banyak yang aktif

• User mulai komplain “kok lambat?”

Dan parahnya, procedure-nya kelihatan biasa saja.

---

Awalnya Saya Juga Mengira “Mungkin Server Lagi Sibuk”

Procedure ini jalan otomatis (job):

BEGIN
  process_daily_data;
END;

Tidak error.
Tidak warning.
Tapi setiap jam tertentu, performa database turun.

---

Setelah Dicek Lebih Dalam…

Ternyata di dalam procedure ada loop seperti ini:

FOR rec IN (
  SELECT order_id
  FROM orders
  WHERE status = 'NEW'
) LOOP

  UPDATE orders
  SET status = 'PROCESS'
  WHERE order_id = rec.order_id;

END LOOP;

Sekilas:

• Aman

• Jelas

• Mudah dibaca

Tapi ada masalah besar.

---

Masalah Utamanya: UPDATE di Dalam Loop

Kalau data:

• 10 baris → aman

• 100 baris → masih oke

• 10.000 baris → mulai terasa

• 100.000 baris → server bisa “ngap”

Kenapa?

• Setiap loop = 1 context switch

• Oracle harus bolak-balik SQL ↔ PL/SQL

Dan ini tidak kelihatan dari sisi error.

---

Versi yang Lebih Sehat

Kalau logic-nya sederhana seperti ini, loop tidak dibutuhkan.

Cukup:

UPDATE orders
SET status = 'PROCESS'
WHERE status = 'NEW';

Satu statement.
Lebih cepat.
Lebih ringan.

---

“Tapi Logic Saya Lebih Rumit…”

Nah, ini biasanya alasan kenapa loop dipertahankan.

Kalau memang perlu proses massal, pertimbangkan:

• BULK COLLECT

• FORALL

Contoh singkat:

SELECT order_id
BULK COLLECT INTO v_ids
FROM orders
WHERE status = 'NEW';

FORALL i IN v_ids.FIRST .. v_ids.LAST
  UPDATE orders
  SET status = 'PROCESS'
  WHERE order_id = v_ids(i);

Bukan paling cantik,
tapi jauh lebih ramah performa.

---

Catatan Pengalaman Kerja

Saya pernah nemu job harian yang:

• Jalan 40 menit

• Tidak pernah error

• Dianggap “wajar”

Setelah diubah:

• Loop dikurangi

• UPDATE massal diprioritaskan

Waktu turun jadi kurang dari 5 menit.

Dan tidak ada perubahan logic bisnis sama sekali.

---

Prinsip Pribadi Saya Sekarang

Setiap lihat PL/SQL, saya selalu cek:

1. Ada UPDATE / INSERT di dalam loop?

2. Bisa dijadikan satu statement SQL?

3. Perlu loop, atau cuma kebiasaan lama?

Kalau ketemu poin 1 + data besar,
biasanya di situlah biang masalahnya.

---

Penutup

Procedure yang “diam” bukan berarti aman.
Kadang justru dia:

• Pelan-pelan

• Konsisten

• Tapi menggerogoti resource

PL/SQL itu bukan cuma soal benar atau salah,
tapi soal dampaknya ke database.

Sampai catatan Rabu berikutnya 👋

Read More

Jangan Terlalu Percaya Function di Dalam Query PL/SQL

 ni catatan yang muncul setelah beberapa kali “kecolongan”.

Query kelihatan rapi.
Logic kelihatan bersih.
Tapi performanya… pelan pelan banget.

Dan penyebabnya hampir selalu sama:
function PL/SQL dipanggil di dalam query.

---

Contoh yang Kelihatannya Aman

SELECT employee_id,
       get_salary_grade(salary)
FROM employees;

Function get_salary_grade kelihatan sederhana.
Dan waktu dites pakai 1–2 data, tidak ada masalah.

Masalahnya baru terasa saat:

• Datanya ribuan

• Query dipanggil berkali-kali

• Atau dipakai di report

---

Apa yang Sebenarnya Terjadi?

Oracle akan:

• Mengambil set data

• Lalu memanggil function untuk setiap baris

Artinya:

• 1.000 baris → 1.000 kali function dipanggil

• 10.000 baris → 10.000 kali function dipanggil

Kalau di dalam function ada:

• SELECT lain

• IF bertingkat

• Logic tambahan

Ya jelas terasa lambat.

---

Contoh Function yang Jadi Masalah

FUNCTION get_salary_grade(p_salary NUMBER)
RETURN VARCHAR2 IS
  v_grade VARCHAR2(10);
BEGIN
  SELECT grade
  INTO v_grade
  FROM salary_grade
  WHERE p_salary BETWEEN min_salary AND max_salary;

  RETURN v_grade;
END;

Secara logika: benar.
Secara performa: berbahaya kalau dipanggil massal.

---

Alternatif yang Lebih Aman

Daripada function di query, sering kali lebih baik:

• Pindahkan logic ke SQL langsung

• Pakai JOIN

Contoh:

SELECT e.employee_id,
       g.grade
FROM employees e
JOIN salary_grade g
  ON e.salary BETWEEN g.min_salary AND g.max_salary;

Lebih panjang sedikit,
tapi:

• Lebih jelas

• Lebih cepat

• Lebih mudah dianalisis optimizer

---

Catatan Pengalaman Kerja

Saya pernah nemu report yang:

• Jalan hampir 15 menit

• Server kelihatan sibuk

• Tidak ada error

Setelah dicek:

• Query utamanya simpel

• Tapi ada 2 function PL/SQL di SELECT

Begitu logic-nya dipindah ke JOIN:
👉 waktu turun jadi di bawah 1 menit

Dan lucunya, kodenya malah jadi lebih “jujur”.

---

Kapan Function Masih Boleh Dipakai?

Bukan berarti function itu haram 😄

Masih aman kalau:

• Dipanggil untuk 1 record

• Dipakai di logic procedure, bukan query massal

• Atau benar-benar deterministic & sederhana

Yang bahaya:
👉 function + query + data besar

---

Penutup

Function PL/SQL itu enak dibaca.
Tapi SQL optimizer tidak peduli kode kita cantik atau tidak.

Kalau performa mulai aneh:

• Cek dulu

• Ada function di SELECT atau WHERE nggak?

Sering kali jawabannya: ada.

Sampai catatan Rabu berikutnya 👋

Read More

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 👋

Read More