Oracle sequence (selanjutnya saya sebut sequence saja, untuk mempermudah) merupakan object dalam database yang berfungsi sebagai sequence number generator, nilai yang dihasilkan ini biasanya disimpan dalam kolom yang berfungsi sebagai primary key pada suatu table. Fungsionalitas sequence ini hampir sama seperti kolom autonumber di Microsoft Access hanya saja cara pemakaiannya berbeda, nanti pada pertengahan artikel ini akan saya sertakan bagaimana cara memiliki kolom autonumber di Oracle seperti yang dimiliki Microsoft Access dengan menggunakan sequence.

Developer yang tidak mengetahui adanya sequence atau karena hal lain yang membatasinya untuk tidak menggunakan sequence, menggantikannya dengan membuat sendiri sequence number (selanjutnya saya sebut m-sequence, untuk membedakannya dengan Oracle sequence) layaknya Oracle sequence. Teknik ini direalisasikan dengan menyimpan nilai maksimum dari m-sequence pada sebuah table. Saat aplikasi meminta nilai untuk m-sequence berikutnya, nilai terakhir yang disimpan dalam table tersebut dibaca kemudian ditambah satu (atau bilangan tertentu) dan disimpan kembali dalam table tersebut. Pada mekanisme ini, jika setelah table yang menyimpan nilai terakhir m-sequence ini di-update dan kemudian transaksi tidak segera diakhiri (commit atau rollback) maka aplikasi lain yang juga membutuhkan nilai m-sequence ini harus menunggu sampai transaksi yang memegang row level lock tersebut berakhir. Untuk aplikasi single user mekanisme ini tidak menimbulkan masalah, sedangkan dalam situasi multiuser, aplikasi yang seperti ini dikatakan tidak scalable. Pada m-sequence developer juga harus menangani sendiri mekanisme locking untuk mencegah terjadinya lost update, karena jika mekanisme locking tidak diimplementasikan dengan benar maka terdapat kemungkinan dua session yang me-request m-sequence secara bersamaan memperoleh nilai sama.

Sequence memiliki karakteristik berbeda dengan m-sequence yaitu dapat digunakan oleh aplikasi lain tanpa menunggu transaksi yang meng-update sequence tersebut berakhir, dengan kata lain memperkecil terjadinya window serialization yang pada akhirnya meningkatkan scalability. Selain itu mekanisme locking-nya juga ditangani secara internal oleh Oracle, jadi kita tidak perlu khawatir memperoleh nilai kembar. Berikut saya sertakan contoh membuat sequence lengkap dengan parameternya.

create sequence myblog_seq
  start with 1
  increment by 1
  maxvalue 99999
  minvalue 1
  nocycle
  cache 5
  noorder;

Seperti halnya object lain dalam database dimiliki oleh seorang owner, sequence object ini juga tidak terkecuali, sequence di atas dimiliki oleh current user dimana sequence tersebut saya create. Seorang user harus memiliki privilege create sequence untuk dapat membuat sequence pada schema-nya, untuk membuat sequence pada schema yang dimiliki user lain dibutuhkan privilege create any sequence. Sequence di atas, ascending sequence, akan menghasilkan sequence number mulai dari start with (1) sampai maxvalue (10000), dan selisih dari tiap nilai yang dihasilkan adalah sebesar increment by (1). Jika aplikasi meminta sequence number berikutnya setelah sequence tersebut mencapai maxvalue maka ada dua kemungkinan yang terjadi tergantung parameter sequence tersebut cycle atau nocycle. Jika cycle setelah mencapai maxvalue, sequence tersebut akan kembali menghasilkan nilai mulai minvalue, sebaliknya jika nocycle maka pesan error ORA-08004 yang dihasilkan. Perlu diketahui bahwa parameter increment by juga bisa bernilai negatif artinya sequence yang dihasilkannyapun bersifat desceding sequence.

Persamaan dari m-sequence dan sequence adalah state dan karakteristik masing-masing sequence disimpan dalam sebuah table. Jika pada m-sequence table yang menyimpannya dibuat sendiri oleh developer maka pada sequence disimpan pada table dalam data dictionary yaitu sys.seq$. Untuk setiap perubahan dari sequence, Oracle akan meng-update nilai maksimum sequence tersebut pada table sys.seq$ dan segera meng-commit transaksinya tanpa harus mempengaruhi transaksi yang meminta sequence number tersebut. Mekanisme seperti ini dimungkinkan karena adanya autonomous transaction. Sebagai konsekuensinya jika transaksi yang meminta sequence number tadi me-rollback transaksinya, nilai maksimum sequence tersebut tidak berubah.

Oracle menyediakan mekanisme caching pada sequence dengan tujuan untuk mengurangi intensitas update pada table sys.seq$ yang pada akhirnya meningkatkan performance saat akses sequence tersebut.
Jika kita saat membuat sequence tidak menspesifikasikan parameter cache maka default-nya sequence tersebut akan di-cache dan nilai cache ini adalah 20 yang artinya ada 20 sequence number yang dipre-alokasikan dalam sequence cache, dan jika habis terpakai cache tersebut akan diisi kembali. Kalau kita menggunakan teknologi RAC maka tiap-tiap instance dalam RAC memiliki sequence cache-nya sendiri. Selain meningkatkan performance sequence, cache ini juga menimbulkan efek samping yaitu gap yang cukup signifikan pada sequence number yang dihasilkan. Sekali lagi saya tekankan secara eksplisit, sekalipun sequence tersebut tidak menggunakan cache (nocache) Oracle tidak menjamin tidak adanya gap, yang dijamin Oracle dengan sequence ini ialah tidak ada dua atau lebih user akan memperoleh hasil kembar dari sebuah sequence.

Selanjutnya saya akan membahas mengapa gap yang cukup signifikan ini bisa terjadi. Karena sequence cache disimpan dalam shared pool tepatnya libary cache maka saat instance shutdown, cache tersebut juga akan hilang. Sebab lainnya ialah, object dalam shared pool dimaintain dengan modified LRU algorithm termasuk di dalamnya sequence cache, dan jika sequence cache tersebut tidak sering diakses maka besar kemungkinan akan mengalami aged out. Berikut gambaran akses sequence myblog_seq yang telah saya create di atas dan di dalamnya terdapat aged out dan instance shutdown (Metalink Note:62002.1).

   app.    | number   | sequence |  cache   |
  access   | returned | current  |  current |
---------------------------------------------
1st access |     1    |     5    |     1    |
2nd access |     2    |     5    |     2    |
---------------------------------------------
               cache aged out
---------------------------------------------
3rd access |     6    |    10    |     6    |
4th access |     7    |    10    |     7    |
---------------------------------------------
              instance shutdown
---------------------------------------------
5th access |    11    |    15    |    11    |
6th access |    12    |    15    |    12    |
7th access |    13    |    15    |    13    |

Karena dua efek tersebut sequence number yang dihasilkan (lihat kolom 2) didalamnya terdapat gap tak beraturan. Khusus untuk kasus aged out, Oracle menyediakan solusi dengan menggunakan procedure keep dalam package dbms_shared_pool. Package ini perlu di-create terlebih dulu dengan menjalankan script dbmspool.sql sebagai user SYS, dan di Linux script ini berada di $ORACLE_HOME/rdbms/admin/. Berikut contoh penggunaan procedure ini pada sequence myblog_seq.

begin
  sys.dbms_shared_pool.keep('myblog_seq','q');
end;
/

Setelah eksekusi procedure ini sequence akan tetap di-cache dalam memory tanpa terpengaruh efek LRU. Untuk sequence yang tidak sering diakses, lebih baik tidak menggunakan cache dari pada harus menggunakan procedure keep untuk alokasi memory (sequence cache) yang jarang dipakai. Solusi ini tidak menyelesaikan masalah pada kasus instance shutdown. Kita dapat melihat sequence apa saja yang telah di-keep melalui perintah SQL berikut.

select owner, name
from v$db_object_cache
where type = 'SEQUENCE' and kept = 'YES';

OWNER      NAME
---------- --------------------
RK         MYBLOG_SEQ

Pada RAC, sequence dengan cache ini dapat menghasilkan nilai yang tidak berurutan dengan timing event request-nya. Contoh, user A pada instance rac1 meminta sequence number pada jam 07:00 selanjutnya user B pada instance rac2 juga meminta sequence number pada jam 07:01. Pada RAC, kejadian berikut mungkin terjadi dimana user A memperoleh nilai 11 untuk request-nya dan user B memperoleh nilai 7 untuk request-nya. Untuk menjaga keterurutan sequence ini Oracle menyediakan clausa order sebagai parameter saat developer membuat sequence, dengan demikian user A akan memperoleh nilai 7 and user B akan memperoleh nilai 8.

Apabila setelah di-create kita ingin mengubah nilai dari parameter sequence maka kita dapat menggunakan perintah alter sequence. Untuk meng-alter sequence yang berada di schema user lain dibutuhkan privilege alter any sequence.

Kombinasi parameter cache dan order ini berpengaruh terhadap performance sequence yang di-create. Saya tidak akan menjelaskan alasannya satu-persatu karena artikel ini hanya mengulas tentang basic sequence saja. Kombinasi dari kedua parameter tersebut dari yang terburuk sampai yang terbaik dari segi performance sebagai berikut :
1. nocache dan order
2. nocache dan noorder
3. cache dan order
4. cache dan noorder

Sampai sejauh ini saya belum menunjukkan bagaimana cara menggunakan sequence. Karena penggunaannya sangat mudah saya tidak akan membahasnya tersendiri, seperti yang telah saya singgung di awal artikel ini, saya akan menggunakan sequence untuk memperoleh fungsionalitas autonumber seperti pada Microsoft Access.

Misalkan saya mau menyimpan informasi judul setiap artikel blog ini ke dalam sebuah table dan menggunakan sequence number sebagai primary key-nya.

create table myblog_post
(
  myblog#    number(5),
  title        varchar2(255),
  constraints    myblog_post_pk primary key (myblog#)
);

Selanjutnya dengan menggunakan before insert trigger saya mengisi kolom myblog# dengan sequence number sehingga saat insert record ke table tersebut kita tidak perlu lagi mengisi nilai kolom ini. Kali ini saya menggunakan trigger hanya untuk menunjukkan bahwa Oracle juga bisa mengimplementasikan autonumber seperti pada Microsoft Access meskipun dengan usaha yang lebih banyak dan biasanya teknik ini digunakan oleh aplikasi yang bersifat database independent. Baca artikel saya sebelumnya tentang trigger sebelum menggunakan trigger dalam aplikasi yang anda buat. Script berikut telah saya test di Oracle 10.2.0.1 dan Oracle 11.1.0.6. Conditional compilation yang saya pakai di trigger mulai tersedia pada Oracle release 10.1.0.4.

create or replace trigger myblog_post_bir
before insert on myblog_post
for each row
begin
  $if dbms_db_version.ver_le_10 $then
    select myblog_seq.nextval into :new.myblog#
    from dual;
  $else
    :new.myblog# := myblog_seq.nextval;
  $end
end;
/

insert into myblog_post (title) values ('Intro');
insert into myblog_post (title) values ('Activate Extended SQL Trace');
insert into myblog_post (title) values ('Reading TKPROF Output');
insert into myblog_post (title) values ('Don''t trigger to code Trigger');
commit;

insert into myblog_post (title) values ('Oracle Sequence Basic');
rollback;

insert into myblog_post (title) values ('Oracle Sequence Basic');
commit;

select * from myblog_post;

   MYBLOG# TITLE
---------- ------------------------------
         1 Intro
         2 Activate Extended SQL Trace
         3 Reading TKPROF Output
         4 Don't trigger to code Trigger
         6 Oracle Sequence Basic

select myblog_seq.currval from dual;

   CURRVAL
----------
         6

Atribut nextval di atas digunakan untuk memperoleh sekaligus mengalokasikan nilai sequence selanjutnya. Untuk mengetahui nilai terakhir yang dialokasikan sequence tersebut pada suatu session digunakan atribut currval. Jika eksekusi atribut currval ini tidak pernah didahului dengan eksekusi nextval untuk setiap sequence pada suatu session, maka akan muncul pesan error ORA-08002. Berikut perilaku yang perlu diperhatikan saat menggunakan atribut currval. (Pada tabel berikut, jika ada dua select yang berada sebaris maka select milik session A dieksekusi terlebih dulu)

Session A                            | Session B
-------------------------------------|-------------------------------------
select myblog_seq.nextval from dual; | select myblog_seq.nextval from dual;
                                     |
   NEXTVAL                           |    NEXTVAL
----------                           | ----------
         7                           |          8
-------------------------------------|-------------------------------------
select myblog_seq.nextval from dual; | Idle
                                     |
   NEXTVAL                           |
----------                           |
         9                           |
-------------------------------------|-------------------------------------
select myblog_seq.nextval from dual; | Idle
                                     |
   NEXTVAL                           |
----------                           |
        10                           |
-------------------------------------|-------------------------------------
select myblog_seq.currval from dual; | select myblog_seq.currval from dual;
                                     |
   CURRVAL                           |    CURRVAL
----------                           | ----------
        10                           |          8
-------------------------------------|-------------------------------------
Idle                                 | select myblog_seq.nextval from dual;
                                     |
                                     |    NEXTVAL
                                     | ----------
                                     |         11

Untuk mengetahui nilai yang akan dihasilkan suatu sequence tanpa harus mengeksekusi nextval ternyata tidak semudah yang saya bayangkan, dapat dilihat pada table di atas nilai yang ditampilkan oleh atribut currval ini hanya mengacu pada masing-masing session dimana nilainya tidak konsisten dan tidak dapat digunakan sebagai patokan untuk nilai yang akan dihasilkan oleh suatu sequence. Oracle mengeksternalisasi sys.seg$ menjadi data dictionary view dba_sequences/all_sequences/user_sequences dan melalui kolom last_number kita dapat mengetahui berapa nilai yang akan kita peroleh jika kita mengeksekusi nextval.

select last_number from user_sequences
where sequence_name = 'MYBLOG_SEQ';

LAST_NUMBER
-----------
         16

select myblog_seq.nextval from dual;

   NEXTVAL
----------
        12

Ternyata view ini juga memberikan informasi yang tidak tepat karena saya menspesifikasikan cache 5 saat membuat sequence ini. Namun jika kita tidak menggunakan cache untuk sequence tersebut maka ketiga dictionary view tadi akan memberikan informasi yang tepat untuk nilai sequence selanjutnya. Saat ini cara yang saya ketahui untuk sequence yang di-cache ialah melalui fixed view yang dimiliki oleh user SYS yaitu v$_sequences.

select nextvalue from v$_sequences
where sequence_name = 'MYBLOG_SEQ';

 NEXTVALUE
----------
        13

select myblog_seq.nextval from dual;

   NEXTVAL
----------
        13

Tetapi untunglah kita dapat memakai sequence dalam aplikasi tanpa perlu mengetahui berapa nilai selanjutnya yang akan dihasilkan oleh sequence tersebut selama parameter yang kita isikan saat create sequence tersebut benar. Jadi bahasan terakhir ini hanya untuk memuaskan rasa keingintahuan saya saja tentang Oracle sequence.

Dulu waktu kuliah saya sempat belajar mengenai trigger, apa itu trigger, bagaimana trigger digunakan dan sebagainya. Setelah saya lulus, dan bukan kebetulan saya bekerja menggunakan Oracle database, saya merupakan pengguna trigger yang tanpa tahu efek buruk yang ditimbulkannya, bahkan saya sempat berpikir kalau trigger merupakan salah satu feature yang keren.

Efek pertama, yang terasa bagi saya sendiri setelah cukup banyak mengerjakan program adalah repotnya memaintain program lama jika mengalami perubahan. Kalau saya tidak lupa tentang keberadaan trigger, saya akan menelusuri kembali trigger apa saja yang ada pada module tersebut, karena sifat trigger yang transparent terhadap aplikasi, dan bayangkan saja jika event (insert, update, delete, dst) satu table men-trigger event table lain dan event table lain ini juga men-trigger event table lainnya lagi, sungguh rumit dan butuh ketelitian apakah perubahan tersebut juga harus mengubah source trigger tersebut.

Efek kedua, berhubungan dengan performance. Sekarang ini setiap project yang saya tangani, saya kerjakan dengan menggunakan PL/SQL package, dimana package ini berupa API (Application Programming Interface). Berikut ini saya akan membandingkan eksekusi SQL yang berada dalam trigger dan yang berada dalam stored procedure (PL/SQL) dari segi performance. Test saya kerjakan di Oracle Database 10g Enterprise Edition Release 10.2.0.1.0.

create table t (col varchar2(30));

create or replace procedure sql_in_proc
as
begin
  for i in (select /*+ stored procedure */ * from dual)
  loop
    null;
  end loop;
end;
/

create or replace trigger sql_in_trig
before insert on t
for each row
begin
  for i in (select /*+ trigger */ * from dual)
  loop
    null;
  end loop;

  sql_in_proc;
end;
/

alter session set timed_statistics = true;

alter session set events '10046 trace name context forever, level 1';

insert into t values ('TEST1');

insert into t values ('TEST2');

insert into t
select owner from all_objects
where rownum < 11;

commit;

alter session set events '10046 trace name context off';

Dengan menggunakan TKPROF saya memformat raw trace file yang dihasilkan, dan berikut adalah bagian yang perlu dianalisa lebih lanjut.

SELECT /*+ trigger */ *
FROM
 DUAL

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        3      0.00       0.00          0          0          0           0
Execute     12      0.00       0.00          0          0          0           0
Fetch       12      0.00       0.00          4         36          0          12
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       27      0.00       0.00          4         36          0          12

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 74     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS FULL DUAL (cr=3 pr=2 pw=0 time=175 us)

********************************************************************************

SELECT /*+ stored procedure */ *
FROM
 DUAL

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     12      0.00       0.00          0          0          0           0
Fetch       12      0.00       0.00          0         36          0          12
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       25      0.00       0.00          0         36          0          12

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 74     (recursive depth: 1)

Dari hasil test di atas dapat dilihat bahwa keduanya sama-sama melakukan sekali hard parsing, statistik misses in library cache during parse yang keduanya bernilai satu. Statistik lain yang menunjukkan perbedaan ialah jumlah soft parse, diperoleh dari statistik parse dikurangi jumlah hard parse. Untuk SQL yang berada dalam stored procedure mengalami soft parse yang lebih sedikit (0) jika dibandingkan dengan SQL yang berada pada trigger (2). Dari sini dapat saya simpulkan bahwa SQL pada trigger hanya di-cache selama triggering statement berlangsung. Sedangkan SQL pada PL/SQL (stored procedure/function), mulai Oracle 9i, akan di-cache sebanyak jumlah yang dispesifikasikan dalam parameter session_cached_cursors. Detail dari statement saya yang terakhir akan menjadi topik blog saya yang lain. Jumlah execute call yang tidak didahului parse call disebut juga sebagai no parse.

Jadi dari segi performance, SQL dalam PL/SQL lebih baik jika dibandingkan SQL dalam trigger karena seperti kita ketahui jika parameter session_cached_cursors dikonfigurasi dengan benar akan mengurangi jumlah soft parse yang terjadi.

Mulai Oracle 11g, SQL yang berada pada trigger diperlakukan sama seperti SQL yang berada dalam PL/SQL. Untuk itu saya ulangi lagi test di atas hanya saja saya kerjakan di Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 dan saya peroleh hasil dari TKPROF sebagai berikut.

SQL ID : a8w9mrw70zb7k
SELECT /*+ trigger */ *
FROM
 DUAL

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     12      0.00       0.00          0          0          0           0
Fetch       12      0.00       0.00          0         36          0          12
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       25      0.00       0.00          0         36          0          12

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 95     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS FULL DUAL (cr=3 pr=0 pw=0 time=0 us cost=2 size=2 card=1)

********************************************************************************

SQL ID : 610w27avd3dts
SELECT /*+ stored procedure */ *
FROM
 DUAL

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     12      0.00       0.00          0          0          0           0
Fetch       12      0.00       0.00          0         36          0          12
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       25      0.00       0.00          0         36          0          12

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 95     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS FULL DUAL (cr=3 pr=0 pw=0 time=0 us cost=2 size=2 card=1)

Walaupun sudah diperlakukan sama di Oracle 11g, saya cenderung tidak menggunakan trigger karena alasan yang saya jelaskan pada efek pertama di atas.

Dari topik sebelumnya yaitu Activate Extended SQL Trace, kita telah memperoleh sebuah file yang berisi history tentang apa saja yang dikerjakan oleh Oracle kernel untuk memenuhi permintaan aplikasi terhadap database. Menurut pengalaman saya dalam tracing ini, file yang dihasilkan dari SQL tracing ini berukuran besar, dan tidak mudah untuk langsung dianalisa. Untuk itulah TKPROF dibuat supaya mempermudah kita melakukan analisa.

TKPROF ini akan mem-format trace file yang dihasilkan ke dalam bentuk standard dengan tujuan mudah dimengerti. Saya tidak akan menjelaskan seluruh option yang dimiliki oleh TKPROF karena Oracle telah mendokumentasikannya dengan baik, hanya yang sering saya pakai saja. Untuk lebih dimengerti, penjelasan akan saya sertai dengan contoh. Berikut saya bentuk dulu test case-nya, saya jalankan dengan menggunakan Oracle 11g karena saya memakai v$diag_info untuk mencari nama trace file yang terbentuk.

spool trace;

set serveroutput off;

select value
from v$diag_info
where inst_id = (select instance_number from v$instance) and
      name = 'Default Trace File';

execute dbms_random.seed(0);

create table t
as
select rownum-1 id,
       dbms_random.string('X',50) name,
       trunc((rownum-1)/10) manager,
       to_date('19800101','yyyymmdd')+trunc((rownum-1)/100) hire_date,
       1000000-trunc(rownum/10) salary,
       'LEVEL '||decode(rownum-1,0,0,trunc((rownum-1)/10)+1) job,
       rpad('*',50,'*') description
from dual
connect by level <= 1000000;

alter table t add constraint t_pk primary key (id);

alter table t add constraint t_r01 foreign key (manager) references t(id);

alter table t modify(manager not null);

execute dbms_stats.gather_table_stats(user,'T',cascade => true);

alter session set timed_statistics = true;

alter session set max_dump_file_size = unlimited;

alter session set events '10046 trace name context forever, level 12';

begin
  for i in (select a.*
            from (select emp.*, mgr.name mgr_name
                  from t emp, t mgr
                  where mgr.id = emp.manager
                  order by emp.id) a
            where rownum <= 100000)
  loop
    null;
  end loop;
end;
/

alter session set events '10046 trace name context off';

spool off;

exit;

Selanjutnya pada command line/shell ketikkan perintah berikut.

tkprof rac3_ora_6942.trc tkrpt1.prf sys=no sort=prsela,exeela,fchela

Perintah TKPROF ini akan memproses trace file yang diinputkan yaitu rac3_ora_6942.trc dan kemudian menghasilkan report dengan nama tkrpt1.prf. Option sys=no ini memberi perintah kepada TKPROF supaya SQL statement yang dieksekusi oleh user SYS (recursive SQL) tidak disertakan ke dalam report yang terbentuk. Option sort=prsela,exeela,fchela memberi perintah pada TKPROF untuk mengurutkan SQL statement pada report yang terbentuk berdasarkan penjumlahan waktu (response time) yang dibutuhkan untuk parsing, execute dan fetching secara descending. Selanjutnya akan saya jelaskan bagian-bagian dari report tersebut yang penting untuk troubleshooting.

Bagian header berisi informasi tentang nama trace file dan sort option. Trace file ini saya peroleh dari session yang terkoneksi dengan dedicated server, jadi SQL statement yang terkandung di dalamnya pasti juga berasal dari session yang sama. Memang ada pengecualian, misalnya pada operating system Windows saya pernah menjumpai trace file dari session yang berbeda berada dalam satu file walaupun koneksinya dedicated server. Ada informasi yang tidak muncul pada TKPROF report yang saya hasilkan yaitu informasi mengenai identitas session yang bersangkutan (sid,serial#,timing information), hal ini dipengaruhi oleh parameter aggregate yang default-nya bernilai true. Jika parameter ini bernilai false identitas session ini akan muncul sebagai pemisah SQL statement yang dieksekusi oleh session berbeda (shared server).

TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 18 11:34:45 2008

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Trace file: rac3_ora_6942.trc
Sort options: prsela  exeela  fchela
********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

Setelah bagian header dapat dijumpai satu blok besar yang berisi SQL statement, execution statistic, query environment, execution plan dan wait event. Perlu diingat urutan statement yang muncul dalam TKPROF report ini bukan merupakan urutan kejadian tetapi diurutkan sesuai sort option yang saya spesifikasikan saat membentuk report ini.

SQL statement
Mengandung informasi tentang SQL statement beserta SQL ID yang profile eksekusinya terletak setelahnya.

SQL ID : d026689a03jpc
SELECT A.*
FROM
 (SELECT EMP.*, MGR.NAME MGR_NAME FROM T EMP, T MGR WHERE MGR.ID =
  EMP.MANAGER ORDER BY EMP.ID) A WHERE ROWNUM <= 100000

Execution statistics
Tabular report berikut menampilkan informasi statistik dari tiap-tiap database call. Ada tiga macam database call yang statistiknya dicatat dalam TKPROF report, yaitu:
1. Parse
Dalam fase ini, Oracle melakukan syntax, semantical dan access right checking. Kemudian Oracle mencari shareable cursor pada shared pool dan jika tidak ada maka membuat plan baru (hard parsing).
2. Execute
Merupakan tahap eksekusi statement oleh Oracle. Jika statement tersebut adalah DML maka pada tahap inilah semua perkerjaan diselesaikan. Sedangkan untuk select statement fase ini biasanya bernilai nol, karena load sesungguhnya berada pada fase fetch.
3. Fetch
Fase ini hanya untuk select statement saja dan merupakan fase dominan dari select statement. Jika query mengembalikan record/row maka dalam fase inilah record-record tersebut didapatkan.

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch     1001      2.55       5.46      49517      39884          0      100000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     1003      2.55       5.47      49517      39884          0      100000

Berikut saya jelaskan mengenai arti dari statistik pada tiap-tiap database call.
1. Count
Menyatakan jumlah eksekusi dari tiap-tiap database call.
2. CPU
Jumlah CPU time dalam second yang digunakan pada tiap-tiap database call.
3. Elapsed
Lama waktu dalam second yang dibutuhkan pada tiap-tiap database call. Jika nilai elapsed lebih besar dari cpu maka artinya session tersebut pernah mengalami penantian untuk sesuatu hal yang session tersebut butuhkan (wait event).
4. Disk
Jumlah data block yang dibaca secara langsung dari datafile (OS cache/disk subsystem cache/disk) pada tiap-tiap database call. Pembacaan langsung ke datafile ini juga dikenal dengan istilah physical IO (PIO).
5. Query
Jumlah data block yang dibaca dari buffer cache dengan consistent read artinya block yang kita baca adalah block yang sama saat query dimulai dan tidak akan terpengaruh perubahan yang dilakukan oleh session lain. Block yang semacam ini direkonstruksi dari rollback segment. Jumlah block yang terbaca dari statistik ini merupakan salah satu kontributor dari logical IO (LIO). LIO dengan consistent read ini ditimbulkan oleh select statement.
6. Current
Jumlah data block yang dibaca dari buffer cache dengan current read artinya block yang kita baca adalah isi block saat itu juga. Jumlah ini juga merupakan kontributor bagi LIO. Jadi LIO merupakan jumlah block yang dibaca baik dengan consistent maupun current read. LIO dengan current read ini ditimbulkan oleh DML (insert/update/delete/merge).
7. Rows
Jumlah row/record yang diproses pada tiap-tiap database call. Untuk select statement jumlah ini merupakan jumlah row yang di-fetch, sedangkan untuk DML merupakan jumlah row yang terpengaruh perubahan.

Query environment
Pada bagian ini berisi informasi tentang parsing. Jumlah misses pada bagian berikut menandakan Oracle melakukan satu kali hard parsing dan terjadi saat parse, sedangkan jika bernilai nol artinya Oracle melakukan soft parse. Selain informasi tentang kapan terjadinya hard parsing, dapat ditemukan parameter optimizer mode apa yang digunakan untuk mengoptimasi execution plan dan siapa yang melakukan parsing SQL statement tersebut.

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 109     (recursive depth: 1)

Execution plan
Row source operation atau yang sering disebut execution plan merupakan plan yang digunakan oleh Oracle ketika SQL statement tersebut dijalankan. Bagian ini terdiri dari dua kolom, kolom pertama adalah rows yang merupakan jumlah row/record yang dihasilkan pada operasi yang tertera disebelahnya. Sedangkan pada kolom kedua berisi tetang operasi yang dikerjakan oleh Oracle berikut dengan statistiknya.

Rows     Row Source Operation
-------  ---------------------------------------------------
 100000  COUNT STOPKEY (cr=39884 pr=49517 pw=49517 time=2873 us)
 100000   VIEW  (cr=39884 pr=49517 pw=49517 time=1856 us cost=61101 size=4104000000 card=1000000)
 100000    SORT ORDER BY STOPKEY (cr=39884 pr=49517 pw=49517 time=801 us cost=61101 size=192000000 card=1000000)
1000000     HASH JOIN  (cr=39884 pr=49517 pw=49517 time=18290 us cost=19093 size=192000000 card=1000000)
1000000      TABLE ACCESS FULL T (cr=19942 pr=19938 pw=19938 time=13449 us cost=4424 size=56000000 card=1000000)
1000000      TABLE ACCESS FULL T (cr=19942 pr=19938 pw=19938 time=11271 us cost=4430 size=136000000 card=1000000)

Berikut saya sertakan penjelasan dari statistik yang menyertai row source operation:
- cr (consitent read) merupakan jumlah block yang dibaca dari buffer cache dengan consistent read.
- pr (physical read) merupakan jumlah block yang dibaca dari datafile.
- pw (physical write) merupakan jumlah block yang ditulis ke disk.
- time merupakan jumlah waktu dalam microsecond (us) yang dibutuhkan hingga mencapai langkah tersebut.
- cost merupakan perkiraan cost yang diberikan oleh optimizer sampai dengan operasi tersebut.
- size merupakan perkiraan jumlah data yang dihasilkan sampai dengan operasi tersebut dalam byte.
- card merupakan perkiraan jumlah row yang dihasilkan pada operasi tersebut.

Untuk tiga parameter terakhir hanya ada mulai Oracle 11g. Selain cardinalty (card), nilai di atas sifatnya akumulatif artinya juga mengandung nilai dari child operation-nya. Untuk time, nilainya tidak akurat karena dalam hal ini saya menggunakan parameter statistics_level default yaitu TYPICAL. Ada dua cara untuk memperoleh statistik time yang akurat (1) mengubah parameter statistics_level menjadi ALL atau (2) mengubah hidden parameter “_rowsource_statistics_sampfreq” menjadi 1 (defaultnya 128) dan tentunya kedua cara ini menimbulkan overhead.

Wait event
Bagian ini sangatlah membantu saat tuning, terutama untuk menelusuri penggunaan waktu (elapsed) yang di luar pemakaian CPU. Bagian ini terdiri dari empat kolom yaitu:
- Event waited on, kolom ini menampilkan nama wait event. Wait event dapat berupa penantian resource untuk kembali tersedia, misalnya latch, enqueue; menunggu terselesaikannya suatu pekerjaan, misalnya I/O operation; menunggu pekerjaan selanjutnya, misalnya menunggu SQL statement yang akan di-submit oleh client (idle event).
- Times Waited, menampilkan jumlah terjadinya wait event tersebut.
- Max. Wait, menampilkan lama waktu maksimal dalam second untuk sebuah wait event ini.
- Total Waited, menampilkan total lama waktu dalam second yang dibutuhkan untuk wait event ini.

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  rdbms ipc reply                                77        0.00          0.00
  KJC: Wait for msg sends to complete             2        0.00          0.00
  reliable message                                2        0.00          0.01
  enq: KO - fast object checkpoint                4        0.04          0.04
  ges inquiry response                            2        0.00          0.00
  direct path read                             2682        0.00          0.01
  enq: TT - contention                           32        0.00          0.01
  direct path write temp                        311        0.00          0.00
  direct path read temp                         311        0.00          0.00
********************************************************************************

Idealnya total cpu time (2.55 s) ditambah total wait event time (0.07 s) sama dengan total elapsed time (5.47 s), namun pada contoh ini terdapat selisih sebesar 2.85 second. Selisih waktu ini disebut juga unaccounted for time. Terdapat banyak hal mengapa timbul unaccounted for time, misalnya un-instrumented Oracle kernel code, quantization error, measurement intrusion effect.

Perlu diingat penjelasan ini bukan merupakan penjelasan keseluruhan dari report yang terbentuk, jadi ada beberapa bagian dari report yang tidak saya munculkan di sini, misalnya bagian PL/SQL yang memanggil SQL statement di atas karena memiliki struktur yang sama dengan penjelasan di atas.

Selanjutnya kita jumpai bagian summary dari TKPROF report ini. Pada bagian berikut tampak total statistik yang dipisahkan menjadi dua bagian yaitu total statistik untuk non-recursive statement (dalam hal ini PL/SQL yang kita trace) dan total statistik untuk recursive statement. Bagian ini secara garis besar memiliki struktur yang sama seperti struktur yang saya jelaskan di atas.

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.00       0.00          0          0          0           0
Execute      2      0.04       0.04          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.04       0.04          0          0          0           1

Misses in library cache during parse: 1

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       2        0.00          0.00
  SQL*Net message from client                     2        0.00          0.00
  library cache lock                              1        0.00          0.00
  library cache pin                               1        0.00          0.00
  rdbms ipc reply                                77        0.00          0.00

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch     1001      2.55       5.46      49517      39884          0      100000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     1003      2.55       5.47      49517      39884          0      100000

Misses in library cache during parse: 1

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  KJC: Wait for msg sends to complete             2        0.00          0.00
  reliable message                                2        0.00          0.01
  enq: KO - fast object checkpoint                4        0.04          0.04
  ges inquiry response                            2        0.00          0.00
  direct path read                             2682        0.00          0.01
  enq: TT - contention                           32        0.00          0.01
  direct path write temp                        311        0.00          0.00
  direct path read temp                         311        0.00          0.00

Di akhir summary terdapat informasi mengenai jumlah SQL statement baik yang di-eksekusi oleh user ataupun oleh sys. Setelah itu terdapat informasi mengenai nama trace file beserta lokasinya, kompatibilitas/versi dari trace file, sorting option yang digunakan, total jumlah SQL statement dari beberapa perspektif, berikut total elapsed time dalam second untuk seluruh SQL statement.

    3  user  SQL statements in session.
    0  internal SQL statements in session.
    3  SQL statements in session.
********************************************************************************
Trace file: /u01/app/oracle/diag/rdbms/rac/rac3/trace/rac3_ora_6942.trc
Trace file compatibility: 11.01.00
Sort options: prsela  exeela  fchela
       1  session in tracefile.
       3  user  SQL statements in trace file.
       0  internal SQL statements in trace file.
       3  SQL statements in trace file.
       3  unique SQL statements in trace file.
    4499  lines in trace file.
       5  elapsed seconds in trace file.

Walaupun TKPROF ini merupakan tool untuk troubleshooting yang handal, namun TKPROF ini juga memiliki kelemahan, yaitu kita tidak selalu dapat memperoleh trace file dari session yang bermasalah karena event 10046 tidak otomatis aktif, ditambah lagi jika kemunculan masalah tersebut random. Selain itu tracing event ini juga menambah overhead pada session yang di-trace karena masih harus menuliskan informasi debug pada file.

Kadang saat troubleshooting dibutuhkan tracing session (event 10046) yang mengalami masalah, karena dengan cara ini kita dapat menemukan SQL statement yang tidak efisien. Event-event apa saja yang dapat diaktifkan tersembunyi dalam file $ORACLE_HOME/rdbms/mesg/oraus.msg, yaitu file yang berisi error message dari kernel Oracle. Dapat ditemukan dalam file tersebut, bahwa error codes 10000 .. 10999 bukan merupakan error message tetapi event. Jika aktif, event ini digunakan oleh Oracle developer untuk salah satu dari ketiga hal berikut:
- Meng-enable atau disable suatu feature
- Simulasi crash/corruption
- Mencatat informasi trace atau debug

Debug atau trace event yang sering saya pakai untuk troubleshooting adalah:
- 10046 (enable SQL statement timing)
- 10053 (CBO enable optimizer trace)

Yang akan saya bahas di sini adalah bagaimana cara untuk mengaktifkan tracing pada debug event 10046. Perlu diketahui hasil tracing dari event ini adalah input file untuk TKPROF (Trace Kernel Profiler) yang merupakan salah satu tool yang digunakan untuk performance tuning – akan saya bahas penggunaannya di artikel selanjutnya.

Ada dua cara yang sering saya pakai untuk mengaktifkan debug event tergantung dari program yang akan kita trace,
1. Tracing program yang source code-nya dapat kita edit
2. Tracing program dimana kita tidak memiliki akses ke source code program tersebut

Untuk tipe pertama, langkah-langkahnya sebagai berikut:

1. Pastikan session tersebut memiliki hak untuk alter session.

2. Untuk mengetahui nama trace file yang akan dibentuk jalankan salah satu SQL berikut.

--Oracle 10g dan 11g, untuk 8i, 9i belum saya coba.
select rtrim(a.value,'/')||'/'||b.instance_name||'_ora_'||
       ltrim(to_char(d.spid))||
       decode(d.traceid,null,null,'_'|| d.traceid)||
       '.trc' trace_file_name
from v$parameter a, v$instance b, v$session c, v$process d
where a.name = 'user_dump_dest' and
      c.audsid = sys_context('userenv','sessionid' ) and
      d.addr = c.paddr;

--Oracle 11g
select value
from v$diag_info
where inst_id = (select instance_number from v$instance) and
      name = 'Default Trace File';

Pastikan session ini memiliki hak akses ke v$ view di atas untuk dapat menjalankan query tersebut. Tanpa memiliki hak akses ke v$ view, pencarian trace file yang dihasilkan dapat lebih mudah dengan menjalankan perintah berikut.

alter session set tracefile_identifier = XXX;

Perintah ini akan menambahkan string XXX pada nama trace file.

3. Pada source code yang akan di-trace tambahkan statement berikut.

alter session set timed_statistics = true;
alter session set max_dump_file_size = unlimited;
alter session set events '10046 trace name context forever, level 12';

-- source code yang akan di-trace

alter session set events '10046 trace name context off';

4. Selesai.

Tracing tipe kedua, langkah-langkahnya sebagai berikut:

1. Login dengan user yang memiliki hak untuk mengeksekusi package sys.dbms_system.

2. Pastikan SID session yang akan di-trace sudah diketahui. Jika SID tidak diketahui, maka cari lewat v$session kemudian difilter dengan field yang nilainya sudah diketahui, misalkan osuser, machine, program, module. Cara ini berlaku untuk aplikasi client server yang menggunakan dedicated server.

3. Dari SID yang diperoleh, jalankan query berikut untuk memperoleh serial# dan lokasi file trace.

select serial#, audsid
from v$session where sid = :sid

--Oracle 10g dan 11g, untuk 8i, 9i belum saya coba.
select rtrim(a.value,'/')||'/'||b.instance_name||'_ora_'||
       ltrim(to_char(d.spid))||
       decode(d.traceid,null,null,'_'||d.traceid)||
       '.trc' trace_file_name
from v$parameter a, v$instance b, v$session c, v$process d
where a.name = 'user_dump_dest' and
      c.audsid = :audsid and
      d.addr = c.paddr;

4. Gunakan nilai sid dan serial# yang telah diperoleh dari langkan no 2 dan 3 sebagai input statement berikut.

execute sys.dbms_system.set_bool_param_in_session(:sid,:serial#,'timed_statistics',true);
execute sys.dbms_system.set_ev(:sid,:serial#,10046,12,''); 

-- jalankan action yang akan di-trace (session berbeda) sampai selesai

execute sys.dbms_system.set_ev(:sid,:serial#,10046,0,'');

5. Selesai

Ada empat nilai level yang valid untuk debug event 10046, level 1 = enable sql trace, level 4 = enable sql trace dan capture bind variable value, level 8 = enable sql trace dan capture wait event dan level 12 = enable sql trace, capture bind variable value dan capture wait event.

Kedua cara tersebut bukan merupakan satu-satunya cara untuk mengaktifkan sql trace, hanya yang sering saya pakai saja. Masih ada package-package lain seperti DBMS_MONITOR, DBMS_SESSION, DBMS_SUPPORT ataupun dengan menggunakan fasilitas ORADEBUG. Beragam cara yang ditawarkan ini memiliki kelebihan dan kekurangan masing-masing dan tentunya ada yang di-support dan ada yang tidak di-support oleh Oracle.

BLOG (Behave Like Oracle Geek) akan berisi dokumentasi tetang feature-feature Oracle yang saya peroleh baik dari eksperimen sendiri atau dari sumber lain misalnya Dokumentasi Oracle atau buku-buku Oracle. Tujuan pertama tentunya supaya mempermudah saya mengakses dokumen tersebut jika diperlukan. Kedua, mungkin juga berguna bagi siapa saja yang mengunjungi blog ini.

Script atau artikel yang berkaitan tetang Oracle yang akan saya posting di sini pasti telah saya test dan berhasil. Jika yang terjadi sebaliknya, artinya anda mencoba dan gagal, saya tidak bertanggung jawab atas dampak apapun yang ditimbulkan.

Silahkan beri komentar untuk ralat, kritik dan saran.