Oracle 11g [ DDL Wait Option ]

Contoh kasus, semisal tabel SALES akan ditambah kolom, TAX_CODE, dengan menggunakan pernyataan SQL sebagai berikut

SQL> alter table sales add (tax_code varchar2(10));

tapi ternyata tidak berhasil membuat table altered, keluar output sbg berikut

alter table sales add (tax_code varchar2(10))
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

Pesan kesalahan tsb menjelaskan bahwa tabel sedang digunakan sekarang, kemungkinan sedang terjadi transaksi, jadi tabel dikunci secara exclusive
Tentu saja row tidak akan di lock selamanya, saat sesi menjalankan commit, maka lock dirow tsb akan dilepas. Tapi sebelum periode unlock tsb terlalu lama
sesi lain mungkin update row lain dalam tabel tsb sehingga sedikit waktu untuk mendapat exclusive lock akan hilang. Dikebanyakan lingkungan bisnis,
waktu untuk lock tabel secara exclusive tidak terbuka secara periodic, dan DBA tidak bisa menjalankan perintah alter tepat diwaktu tsb.
Tentu saja dengan keadaan seperti itu , kita hanya bisa mengetik perintah yang sama berulang-ulang sampai mendapat exclusive lock.
Dalam Oracle 11g, Kita punya pilihan lebih baik, DDL Wait Option

SQL> alter session set ddl_lock_timeout = 10;

Session altered.

Sekarang saat pernyataan DDL dalam sebuah sesi tidak mendapat lock exclusive, ini tidak akan keluar error. Ini akan menunggu selama 10 detik.
Dalam waktu tsb , ini akan berulang-ulang menjalankan operasi DDL sampai sukses atau waktu habis. Saat kita jalankan perintah

SQL> alter table sales add (tax_code varchar2(10));

Pernyataan tersebut hang dan tidak keluar error sama sekali. Tapi pernyataan tsb tetap berjalan seperti sebuah program telepon yang mencoba
terus retry kenomer yang sibuk yang akan dihubungi. Fitur ini sangat membantu , kita jg bisa menjadikan ini sebagai default sehinggan kita tidak perlu
menjalankan ALTER SESSION tiap kali, jika kita menjalankan ALTER SYSTEM SET DDL_LOCK_TIMEOUT = 10 maka secara automatis sesi akan menunggu
selama periode yang kita tentukan selama proses DDL.

Oracle Basic [ Table Compression ]

Oracle Basic [ Table Compression ]

Sistem yang kita develop sekarang hampir kebanyakan membutuhkan jumlah data yang sangat banyak dan pasti memerlukan beberapa tabel yang sangat besar. Ini tentu saja akan membutuhkan banyak space di disk kita. Untuk memanage kapasitas disk fitur tabel compression yang ada sejak Oracle 9i release 2 dapat menekan jumlah pemakaian disk space oleh tabel2 didatabase secara signifikan dan meningkatkan performance query di beberapa kasus.

Mekanisme kerja fitur ini adalah dengan mengeliminasi value untuk data yang terduplikasi yang ditemukan di tabel. Kompresi data bekerja di level database block. Saat tabel didefinisikan sebagai “compressed”, maka database akan memesan space dalam tiap database block untuk menyimpan single copy dari tiap data yang juga muncul di beberapa tempat selain block tersebut. Reserved space ini disebut dengan symbol table. Data yang di beri label untuk kompresi disimpan hanya di symbol table dan bukan di row databasenya sendiri. Bila data yang diberi label untuk kompresi muncul dirow database, maka row akan menyimpan sebuah pointer yang menuju ke data yang relevan di symbol table. Dan space yang akan dihemat datang dari proses eliminasi data yang sama yang ada ditabel. Efek dari kompresi tabel transparan kepada user atau developer aplikasi karena developer dapat mengakses tabel dengan cara yang sama terhadap tabel yang kita kompresi maupun tidak kita kompress. Jadi query SQL tidak perlu dirubah setelah kita putuskan untuk melakukan kompresi tabel. Kompresi tabel ini biasanya dimanage oleh DBA, dengan sedikit keterlibatan developer atau user.

Untuk membuat tabel kompresi, gunakan keyword COMPRESS di statement CREATE TABLE. berikut contohnya :

CREATE TABLE EMP (
ID NUMBER NOT NULL,
NAME VARCHAR2(50) NOT NULL,
SAL NUMBER NOT NULL,
JOIN_DATE DATE NOT NULL,
ADDRESS VARCHAR2(100)
) COMPRESS;

Sebagai alternatif kita bisa gunakan ALTER TABLE untuk merubah atribut kompresi dari tabel yang sudah ada.

ALTER TABLE EMP COMPRESS;

Untuk menentukan apakah sebuah tabel telah dibuat menggunakan COMPRESS, kita lihat diview data dictionary

USER_TABLES dan lihat dikolom COMPRESSION.

SELECT TABLE_NAME, COMPRESSION FROM USER_TABLES WHERE TABLE_NAME=’EMP’;

TABLE_NAME COMPRESSION
—————— ———–
EMP ENABLED

Atribut COMPRESS juga dapat kita definisikan pada level TABLESPACE, bisa saat kita CREATE TABLESPACE atau ALTER TABLESPACE bila kita lakukan pada tablespace yang sudah ada. Untuk menentukan apakah sebuah tablespace didefinisikan dengan COMPRESS, cek pada DBA_TABLESPACES pada kolom DEF_TAB_COMPRESSION.

SELECT TABLESPACE_NAME,DEF_TAB_COMPRESSION FROM DBA_TABLESPACES;

TABLESPACE_NAME DEF_TAB_COMPRESSION
————— ——————-
DATA_TS_01 DISABLED
INDEX_TS_01 DISABLED

Sebagai catatan bahwa saat kita menggunakan COMPRESS seperti diatas, kita tidak sebenarnya melakukan kompress data. Command diatas hanya memodifikasi seting dari data dictionary. Data tidak sebenarnya dikompres sampai kita load atau insert data ke dalam tabel. Selanjutnya untuk memastikan bahwa data sebenarnya telah dikompres, kita perlu menggunakan metode yang tepat untuk melakukan load atau insert kedalam tabel. Kompresi data hanya berperan selama proses load atau insert dengan menggunakan salah satu dari metode berikut :

1. SQL*Loader scr direct
2. INSERT dengan APPEND
3. Paralel INSERT
4. CREATE TABLE … AS SELECT

Dan jika kita tidak menggunakan metode load data atau INSERT yang tepat, maka data dalam tabel akan tetap tidak dikompres, meskipun tabel telah didefiniskan dengan atribut COMPRESS. Sebagai contoh jika kita menggunakan perintah INSERT biasa maka data tidak akan dikompress.

Pertanyaannya adalah, kapan kita gunakan Table Compression?
Seperti disebutkan diatas, data didalam tabel didefinisikan menggunakan COMPRESS hanya akan dikompres hanya jika data kita load menggunakan mode direct atau INSERT menggunakan append atau paralel mode. Data kita insert menggunakan pernyataan insert biasa akan tetap tidak dikompres. Dalam Online Transaction Processing (OLTP), data biasanya diinsert dengan insert biasa. Hasilnya, tabel ini tidak akan mendapat banyak keuntungan dengan menggunakan kompresi tabel. Table compression dapat bekerja maksimal dalam read-only table yang diload sekali tapi dibaca berkali-kali. Selain itu, update data dalam tabel yang terkompresi akan membutuhkan beberapa baris data untuk di uncompress terlebih dulu, yang mana akan menghilangkan tujuan dari kompresi.Sehingga tabel yang membutuhkan operasi update dengan frekuensi tinggi tidak cocok untuk dilakukan table compression.

Dan selanjutnya adalah mempertimbangkan efek dari delete pada baris data dalam penggunaan kompresi tabel. Saat kita melakukan delete sebuah data dalam suatu tabel yang dikompresi, database akan melepaskan space yang ditempati oleh baris data tsb diblok database. free space ini dapat digunakan kembali oleh operasi insert yang akan dilakukan kemudian.

Melakukan kompresi pada tabel yang sudah ada dan belum dikompres sebelumnya kita gunakan command berikut

ALTER TABLE EMP MOVE COMPRESS;

Kita bisa menggunakan pernyataan ALTER TABLE … MOVE untuk melakukan uncompress tabel.

ALTER TABLE EMP MOVE NOCOMPRESS;

Perhatikan bahwa operasi ALTER TABLE … MOVE mendapat lock EXCLUSIVE didalam tabel, yang mana akan mencegah semua operasi DML terhadap tabel tsb saat pernyataan dieksekusi.

Melakukan Kompresi pada tabel yang dipartisi

ALTER TABLE EMP MOVE PARTITION EMP3_03 COMPRESS;

Alasan sesungguhnya untuk menggunakan kompresi tabel adalah untuk menghemat space pada storage kita. Sebuah tabel dalam mode kompresi akan memakan lebih sedikit ruang di storage kita saat dibandingkan dengan tabel yang tidak terkompresi. Query terhadap tabel yang dikompres akan membutuhkan waktu yang lebih cepat, karena akan lebih sedikit membaca database block dalam prosesnya.