8 BAB 2 LANDASAN TEORI 2.1 Landasan Teori Umum 2.1.1

BAB 2
LANDASAN TEORI
2.1 Landasan Teori Umum
2.1.1 Pengertian Data dan Informasi
Menurut Whitten, Bentley dan Dittman (2004, p27), data adalah fakta mentah
tentang orang, tempat, kejadian, dan barang yang sangat penting dalam organisasi.
Setiap fakta secara relatif mempunyai arti. Sedangkan informasi adalah data yang
telah diproses atau diorganisasikan kembali ke dalam bentuk yang lebih berarti untuk
seseorang. Informasi dibentuk dari kombinasi data yang diharapkan mempunyai arti
bagi penerimanya.
Menurut Williams dan Sawyer (2005, p12), data mengandung fakta mentah dan
bentuk yang diproses kedalam informasi – contohnya, pemugutan suara untuk
kandidat yang berbeda dalam pemilihan senat. Informasi adalah data yang telah
dirangkum atau setidaknya di manipulasi yang digunakan untuk pengambilan
keputusan – contohnya, total hasil pemungutan suara untuk seluruh kandidat yang
digunakan untuk menentukan siapa pemenangnya.
2.1.2 Pengertian Hardware
Menurut Techtarget (www.midmarket.techtarget.com) hardware adalah aspek
fisik dari komputer, telekomunikasi, dan piranti lainnya. Istilah timbul sebagai cara
untuk membedakan "kotak" dan sirkuit listrik yang halus dan komponen komputer
dari program anda menaruh di dalamnya agar melakukan sesuatu.
8
9
2.1.3
Pengertian Basis Data
Menurut Connolly dan Begg (2005, p15), database adalah kumpulan data
yang saling berhubungan secara logika dan dirancang untuk memenuhi kebutuhan
informasi organisasi. Menurut O’Brein (2003, p696) basis data adalah kumpulan
terpadu dari elemen data logis yang saling berhubungan.
2.1.3.1 Pengertian DBMS ( Database Management System )
Menurut Connolly dan Begg (2005, p16), DBMS adalah sistem perangkat
lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara,
dan mengontrol akses ke database. DBMS adalah perangkat lunak yang
berinteraksi dengan program aplikasi pengguna dan database. Sebuah DBMS harus
menyediakan fasilitas sebagai berikut.
•
Mampu mendefinisikan database, biasanya melalui Data Definition
Language (DDL). DDL memungkinkan pengguna untuk menentukan tipe
data, struktur, dan batasan terhadap data yang akan disimpan ke database.
•
Memungkinkan pengguna untuk memasukkan (insert), merubah (update),
menghapus (delete), dan mengambil (retrieve) data dari database,
biasanya
melalui
Data
Manipulation
Language
(DML).
DML
memungkinkan pengguna untuk melakukan query.
•
Menyediakan kendali akses ke database. Sebagai contoh DBMS dapat
menyediakan :
o Sistem keamanan yang memungkinkan untuk mencegah pengguna
yang tidak berkepentingan untuk mengakses database.
10
o Sistem integrasi yang menjaga konsistensi data yang tersimpan.
o Sistem kendali yang memungkinkan database untuk diakses secara
bersamaan.
o Sistem pemulihan yang memungkinkan untuk mengembalikan
keadaan database ke kondisi konsisten yang sebelumnya jika
terjadi kesalahan, termasuk kesalahan perangkat keras dan
perangkat lunak.
o Sebuah katalog yang bisa diakses oleh pengguna yang di dalamnya
terdapat deskripsi atau penjelasan dari data yang terdapat di dalam
database.
2.1.4
Pengertian Backup Basis Data
Menurut Alapati (2005, p631) sebagai seorang Administrator basis data
Oracle, salah satu tugas dasar kita adalah melakukan proses backup pada basis data
secara rutin. Backup berarti membuat salinan dari basis data kita untuk membuat
kembali basis data yang sama jika diperlukan.
2.1.4.1 Whole dan Partial Database Backups
Menurut Alapati (2005, p632) kita dapat melakukan backup pada seluruh
atau sebagian isi basis data. Yang dimaksud dengan sebagian adalah datafile atau
tablespace. Kita tidak dapat melakukan backup pada sebagian basis data jika basis
data berjalan dalam mode noarchivelog, kecuali semua tablespace dan file pada
11
partial backup bersifat read-only. Kita dapat membuat backup pada seluruh basis
data pada mode archivelog ataupun noarchivelog.
2.1.4.2 Archivelog dan Noarchivelog
Menurut Alapati (2005, p633) pada mode archivelog, Oracle menyimpan
redo logs yang sudah berisi. Dengan demikian, tidak peduli berapa lama usia dari
backup bais data yang ada, jika kita berada pada mode archivelog, kita dapat
mengembalikan basis data kapan pun juga. Sedangkan pada mode nonarchivelog,
redo log yang sudah berisi tidak ditimpa dan tidak disimpan. Akibatnya, kita hanya
dapat mengembalikan basis data pada kondisi terakhir backup dan kehilangan
perubahan yang kita buat setelah backup terakhir.
Sistem produksi biasanya berjalan pada mode archivelog, dengan beberapa
alasan berikut:
• Kita dapat recover secara menyeluruh dari sebuah kegagalan instance
ataupun juga kegagalan media.
• Kita dapat melakukan recovery data secara menyeluruh jika mengalami
kerusakan drive disk
• Kita dapat mencapai high availibility karena sebuah basis data yang
berjalan pada mode archivelog tidak perlu di shut down untuk dilakukan
proses back up. Kita dapat melakukan proses online backup.
• Kita hanya dapat melakukan open backup yang adalah backup yang
dilakukan ketika basis data sedang berjalan.
12
• Kita harus berada pada mode archivelog agar bisa melakukan recovery
tablespace secara in time.
2.1.5
Pengertian Recovery Basis Data
Menurut Cyran (2003, p15-2), recovery adalah suatu proses untuk melakukan
restore dari sebuah backup dari datafile atau control file dengan cara merekonstruksi
kembali dan membuatnya kembali tersedia pada server basis data Oracle. Redo logs
dan online logs juga diperlukan untuk mengembalikan perubahan yang terjadi pada
basis data sejak backup terakhir.
Menurut Optimum Recovery. Inc, (www.optimumrecovery.com), recovery
adalah proses untuk mengembalikan data yang hilang atau rusak. Data dapat hilang
karena kerusakan media atau file yang tidak sengaja terhapus.
2.2 Landasan Teori Khusus
2.2.1 Pengertian Analisis
Menurut Whitten, Bentley dan Dittman (2004, p186), sistem analisis adalah
sebuah teknik pemecahan masalah yang memecah-mecah sebuah sistem ke dalam
komponen-kompenan kecil dengan tujuan untuk mempelajari bagaimana kinerja dan
interaksi dari masing-masing komponen untuk mencapai tujuan mereka.
2.2.1.1 Pengertian Six Sigma
Menurut
Manggala
(2005,
p6),
Six
Sigma
merupakan
sebuah
metodologi terstruktur untuk memperbaiki proses yang difokuskan pada usaha
13
mengurangi variasi proses (process variances) sekaligus mengurangi cacat
(produk/jasa yang diluar spesifikasi) dengan menggunakan statistik dan problem
solving tools secara intensif.
Menurut Pande, dalam bukunya The Six Sigma Way: Team
Fieldbook, ada enam komponen utama konsep Six Sigma sebagai strategi bisnis:
1. Benar-benar mengutamakan pelanggan: seperti kita sadari bersama,
pelanggan bukan hanya berarti pembeli, tapi bisa juga berarti rekan kerja
kita, team yang menerima hasil kerja kita, pemerintah, masyarakat umum
pengguna jasa.
2. Manajemen yang berdasarkan data dan fakta: bukan berdasarkan opini,
atau pendapat tanpa dasar.
3. Fokus pada proses, manajemen dan perbaikan: Six Sigma sangat tergantung
kemampuan kita mengerti proses yang dipadu dengan manajemen yang
bagus untuk melakukan perbaikan.
4. Manajemen yang proaktif: peran pemimpin dan manajer sangat penting
dalam mengarahkan keberhasilan dalam melakukan perubahan.
5. Kolaborasi tanpa batas: kerja sama antar tim yang harus mulus.
6. Selalu mengejar kesempurnaan.
2.2.1.2 Tahapan Six Sigma
Menurut Manggala, Mengenal Six Sigma secara Sederhana (2005, p68),
setiap tahap dalam metode Six Sigma mempunyai bagian-bagian yang mesti
14
dilaksanakan ataupun mempunyai jenis-jenis konsep statistik yang bisa dipakai,
walaupun sebenarnya untuk penggunaan statistik bisa cukup fleksibel.
o Define
Pada tahap ini tim pelaksana mengidentifikasikan permasalahan,
mendefiniskan
spesifikasi
pelanggan,
dan
menentukan
tujuan
(pengurangan cacat/biaya dan target waktu).
o Measure
Tahap untuk memvalidasi permasalahan, mengukur/menganalisis
permasalahan dari data yang ada.
o Analyze
Menentukan faktor-faktor yang paling mempengaruhi proses; artinya
mencari satu atau dua faktor yang kalau itu diperbaiki akan
memperbaiki proses kita secara dramatis.
o Improve
Di tahap ini kita mendiskusikan ide-ide untuk memperbaiki sistem kita
berdasarkan hasil analisis terdahulu, melakukan percobaan untuk
melihat hasilnya, jika bagus lalu dibuatkan prosedur bakunya
(standard operating procedure-SOP).
o Control
Di tahap ini kita harus membuat rencana dan desain pengukuran agar
hasil yang sudah bagus dari perbaikan tim kita bisa berkesinambungan.
Dalam tahap ini kita membuat semacam metrics untuk selalu
15
dimonitor dan dikoreksi bila sudah mulai menurun ataupun untuk
melakukan perbaikan lagi.
2.2.2 Perancangan
Menurut Whitten, Bentley, dan Dittman (2004, p186), desain sistem
adalah sebuah teknik pemecahan masalah pelengkap dari analisis sistem yang
membangun kembali komponen-komponen sistem yang baru untuk peningkatan
sistem, hal ini melibatkan penambahan, penghapusan pengubahan potongan kedalam
sistem asli.
2.2.3
Arsitektur Basis Data Oracle
Menurut Alapati (2003, ch.5), basis data Oracle terdiri dari 2 struktur yaitu:
1. Logical Structure
a) Data Blocks
Data Blocks adalah komponen logical paling kecil dari basis data
Oracle. Seorang Administrator basis data (DBA) menentukan besar data
blocks sesuai dengan keperluan pada basis data tersebut, dengan cara
melakukan konfigurasi pada db_block_size parameter. Sebagai contoh,
sebuah blocks berukuran kecil akan sangat berguna ketika user sedang
bekerja dengan jumlah baris yang kecil, di mana user sedang melakukan
banyak pencarian index. Blocks berukuran besar dapat sangat berguna
dalam aplikasi laporan ketika user melakukan pencarian pada tabel yang
berukuran besar.
16
Ketika seorang user melakukan select pada data dari sebuah tabel,
maka sintaks select akan “membaca”, atau mengambil, data dari file basis
data dalam unit dari blocks Oracle. Oracle blocks selalu terdiri dari
berbagai macam ukuran blocks dari sistem operasi. Seluruh data block
dapat dibagi ke dalam 2 bagian utama yaitu : row data portion dan free
space portion . Row data portion terdiri dari dari serangkaian data block
yang menyusun tabel atau index. Free space portion adalah sisa ruang
kosong dalam Oracle blocks untuk melakukan pemasukan data baru atau
sambungan dari baris yang telah diletakkan di dalam blocks.
Oracle 9i mengijinkan untuk mengatur ruang kosong yang tersedia di
dalam data block secara manual atau otomatis.
Tidak seperti versi sebelumnya, Oracle 9i mengijinkan user untuk
menentukan hingga 4 jenis ukuran blocks yang tidak umum, yang disebut
dengan multiple data blocks. Jika user melakukan konfigurasi multiple
data blocks, maka user harus melakukan konfigurasi pula pada subcaches
di System Global Area (SGA) .
Fungsi dari multiple data blocks ini adalah user dapat membuat data
blocks yang berbeda di dalam basis data. Ketika user membuat tablespace,
maka user dapat menentukan ukuran dari blocks dalam basis data. Pada
saat sebuah tablespaces dibuat, maka akan selalu memiliki ukuran data
blocks yang umum.
17
b) Extents
Extents
adalah
kombinasi
dari
berbagai
data
blocks
yang
berdampingan dalam jumlah yang cukup. Pilihan user atas tablespaces
akan menentukan bagaimana basis data Oracle mengalokasikan extents.
Seluruh objek pada basis data disediakan sebagai sebuah jumlah
penanda dari ruang, disebut dengan initial extent, ketika mereka dibuat.
Ketika sebuah objek dibuat, user menentukan ukuran dari extent yang
subsequent dan selanjutnya sejumlah angka maksimal dari extents untuk
objek tersebut, di dalam sintaks pembuatan objek.
Ketika sebuah tabel atau index dialokasikan, maka extents akan
mengingatkan untuk dialokasikan pada objek saat itu, hingga user
melakukan drop pada objek dari basis data, ketika space akan
mengembalikan ke dalam tempat dari free space yang dialokasikan dalam
basis data.
c) Segments
Sekumpulan extent akan membentuk segments. Setiap objek pada basis
data mempunyai segment-nya sendiri. Ketika sebuah index dibuat, maka
index tersebut akan mempunyai segment yang diberi nama setelah nama
index.User dapat memiliki beberapa tipe segment, dengan data segment
dan index segment yang paling umum.
d) Tablespaces
Sebuah tablespace didefinisikan sebagai sebuah kombinasi dari
serangkaian segments yang saling berkaitan. Tablespace adalah logic
18
structure secara murni, dan merupakan main logic structure dari sebuah
basis data Oracle. Semua tablespace tidak selalu mempunyai ukuran yang
sama dengan dengan sebuah basis data Oracle.
Karena Oracle 9i mempunyai fitur multiple data blocks dan tablespace
pun terdiri dari data blocks, maka sebuah tablespace dapat terdiri dari
blocks dengan besar yang berbeda dalam setiap tablespace. Hal ini
menguntungkan karena memberi kesempatan untuk mengambil ukuran
blocks yang tepat untuk sebuah tablespace, tergantung pada struktur data
dari sebuah tabel di dalam tablespace. Beberapa keuntungan dari
konfigurasi ukuran blocks untuk tablespace, yaitu : meningkatkan disk I/O
,meningkatkan cache data, memudahkan transport tablespaces
Dalam setiap basis data Oracle dibutuhkan sedikitnya 2 tablespace,
yaitu : system tablespace dan temporary tablespace. System tablespace
tidak dapat dilakukan drop, yang mengandung Oracle data dictionary.
2. Physical Structure
a) Data Files
Data files adalah physical file yang sebenarnya disimpan oleh data
yang telah dimasukkan ke dalam setiap tabel di basis data. Data files
merupakan cara Oracle untuk mengalokasikan space pada tablespace,
serta memetakan logical tablespaces ke dalam physical disks. Setiap
tablespaces terdiri dari satu atau lebih data files.
b) Control Files
19
Control files adalah key file dari Oracle DBMS yang mengatur keadaan
basis data. Control files mirip seperti basis data di dalam basis data yang
menyimpan data, seperti nama dan lokasi dari data files serta seluruh
System Change Number (SCN), di mana menandakan versi terakhir dari
perubahan pada basis data saat itu. Control files adalah key untuk seluruh
fungsi di dalam basis data, dan pemulihan akan sulit tanpa mengakses
control files yang terbaru. Oracle membuat control files selama proses
pembuatan basis data awal.
Data yang terdapat dalam control files yaitu :
-
Data tentang kemajuan checkpoint
-
Data tentang redo
-
Data tentang tablespaces
-
Data tentang sejarah log files
-
Data tentang archieved logs
-
Data tentang backup set dan data file copy
Control files menjadi sangat penting selama Oracle instances
beroperasi dan selama pemulihan basis data Oracle.
c) Redo Log Files
Redo Log Files sangat penting selama recovery process basis data.
Redo log files merekam semua semua perubahan yang terjadi di dalam
basis data. Oracle redo log files terdiri dari informasi berikut ini (terkait
dengan perubahan pada basis data akibat transaksi) :
-
Indikator yang memberikan tanda ketika sebuah transaksi dimulai
20
-
Nama transaksi
-
Nama dari objek data yang telah di update
-
“Before image” dan “After image” dari transaksi
-
Memastikan (commit) indikator yang memberikan informasi jika dan
kapan transaksi tersebut selesai.
d) Initialization Parameter (init.ora dan SPFILE)
Initialization Parameter untuk Oracle instance yang ditentukan ketika
sebuah basis data baru dibuat, disebut init ora file atau server parameter
file (SPFILE). Oracle mengijinkan untuk mengubah sejumlah initialization
parameters setelah user memulai instance, hal ini disebut dynamic
initialization parameters. Setiap kali melakukan perubahan pada dynamic
initialization parameters, maka user harus melakukan restart pada basis
data.
e) Password Files
Password Files adalah file pilihan yang digunakan untuk menyimpan
nama dari para pengguna yang telah diberikan hak akses (grant
privilleges) oleh SYSDBA dan SYSOPER .
f) Archived Log Files
Archived Log Files adalah penduplikasian isi dari redo log online
yang terakhir, digunakan untuk proses recovery.
21
g) Alert Log Files
Alert Log Files adalah file yang mendaftarkan perubahan besar,
events, errors yang terjadi selama menjalankan Oracle instance. Alert Log
Files juga merekam events yang mencakup log switches, Oracle erros
yang berkaitan, warning, dan messages lainnya.
2.2.4 Pengertian Partitioning
Menurut Situmorang (2004, p309), mempartisi berarti mengelola tabel dan
indeks berukuran besar menjadi bagian kecil.
Menurut Morales (2007, p2-1), partitioning memungkinkan sebuah tabel,
index atau tabel berindeks dibagi menjadi potongan-potongan kecil dan
memungkinkan objek basis data untuk diakses pada tingkat yang lebih kecil. Setiap
partisi memiliki namanya sendiri dan mungkin mempunyai pilihan karakteristik dari
media penyimpanannya. Dari sudut pandang seorang administrator basis data (DBA),
sebuah objek yang dipartisi mempunyai berbagai macam potongan yang juga dapat di
atur secara kolektif ataupun individual. Hal ini akan memberikan pertimbangan yang
fleksibel untuk DBA dalam mengatur objek yang dipartisi.
Bagaimanapun dari sudut pandang aplikasi, sebuah tabel yang dipartisi identik
dengan sebuah tabel yang tidak dipartisi; tanpa modifikasi yang diperlukan ketika
melakukan akses pada tabel yang dipartisi dengan menggunakan perintah SQL DML.
Tabel dipartisi dengan menggunakan partitioning key, yaitu sekumpulan
kolom yang menentukan partisi untuk tiap baris.
22
2.2.4.1 Teknik Partitioning
Menurut Lumpkin (2003, p3), Oracle menyediakan 5 teknik untuk
mempartisi tabel, yaitu :
1. Range Partitioning
Setiap partisi dispesifikasi oleh serangkaian nilai dari partitioning key
2. List Partitioning
Setiap partisi dispesifikasikan oleh sebuah list nilai dari key
partitioning.
3. Hash Partitioning
Sebuah algoritma hash diterapkan pada partitioning key untuk
membatasi partisi pada baris yang diberikan.
4. Composite Range-Hash Partitioning
Sebuah kombinasi dari teknik Range dan Hash partitioning. Pertama
kali, tabel akan dipartisi dengan teknik range partitioning. Kemudian
setiap individu hasil range partitioning tersebut akan dipartisi kembali
dengan menggunakan hash partitioning .
5. Composite Range-—List Partitioning
Sebuah kombinasi antara teknik Range dan List Partitioning. Pertama
kali, tabel akan dipartisi dengan teknik range partitioning. Kemudian
setiap individu hasil range partitioning tersebut akan dipartisi kembali
dengan menggunakan list partitioning. Tidak seperti gabungan RangeHash Partitioning, isi dari setiap subpartisi mewakili sebuah subset
23
logika dari data, dideskripsikan oleh sesuai dengan proses setup pada
range dan list partitioning.
2.2.4.2 Manfaat Partitioning
Menurut Morales(2007, p2-4), Partitoning menyediakan keuntungan pada
berbagai macam variasi aplikasi dengan cara meningkatkan manageability,
performance, dan availability.
• Partitioning for Manageability
Oracle partitioning memungkinkan tabel dan index dipartisi
menjadi unit yang lebih kecil dan mudah diatur, sehingga membantu
seorang DBA untuk melakukan pendekatan management data dengan
teknik “divide and conquer”. Dengan partitioning, operasi maintenance
dapat difokuskan pada bagian tertentu saja dari tabel.
Penggunaan umum partitioning untuk manageability adalah untuk
mendukung proses pemindahan data secara rolling window dalam sebuah
datawarehouse.
• Partitioning for Performance
Dengan membatasi jumlah data yang akan diperiksa atau
dioperasikan, dan dengan menyediakan distribusi data secara paralel,
Oracle partitioning akan memberikan sejumlah keuntungan performance.
Fitur ini termasuk :
24
¾ Partition Pruning
Partitioning Pruning adalah hal yang paling sederhana dan
paling penting untuk meningkatkan performa menggunakan
partitioning. Partition pruning dapat meningkatkan kinerja query
secara signifikan. Menurut Joseph C. Johnson (2003, p.568), yang
dimaksud dengan partition pruning adalah proses yang dilakukan
oleh Cost Based Eliminator untuk menghilangkan partisi tabel
yang tidak berhubungan dengan query yang sedang dilakukan
¾ Partition Wise Join
Partitioning
dapat juga meningkatkan kinerja dari join
beberapa tabel menggunakan teknik partition wise join. Partition
wise join dapat di aplikasikan ketika dua buah tabel akan
digabungkan bersama dan kedua tabel di partisi pada join key atau
ketika sebuah tabel partisi direferensi digabung dengan tabel
parent-nya. Partition wise join memecah sebuah join yang besar
kedalam join yang lebih kecil yang terjadi antar partisi dan
menyelesaikan proses join secara keseluruhan dengan waktu yang
lebih singkat. Hal ini akan menawarkan keuntungan performa yang
signifikan pada eksekusi serial ataupun paralel.
• Partitioning for Availability
Objek basis data yang dipartisi menghasilkan kemandirian partisi.
Sifat kemandirian partisi menjadi suatu hal yang penting untuk mencapai
strategi high availability. Seorang DBA dapat menentukan setiap partisi
25
disimpan dalam tablespace yang terpisah. Skenario yang paling umum
adalah dengan menyimpan tablespace tersebut pada media penyimpanan
yang berbeda. Menyimpan partisi pada tablespace yang berbeda
memungkinkan DBA untuk melakukan proses backup dan recovery secara
terpisah pada masing-masing partisi, sehingga memungkinkan bagian
basis data untuk menjadi lebih cepat availability. Jadi akses pada
sistem
dapat berlanjut ketika data yang tidak aktif sedang dilakukan
restore. Bahkan partitioning dapat mengurangi waktu down dari basis
data.
Menurut Michele Cyran (2003, p18-2), keuntungan yang bisa didapat dengan
melakukan partitioning yaitu:
¾ Partitioning memungkinkan operasi data management seperti data loads,
index creation and rebuilding, dan backup/recovery pada level partisi
daripada pada level keseluruhan tabel. Hal ini dapat mengurangi waktu
untuk melakukan operasi ini secara signifikan.
¾ Partitioning meningkatkan performa query. Dalam banyak kasus, hasil
dari query bisa didapat dari mengakses bagian dari partisi daripada
keseluruhan tabel.
¾ Partitioning dapat secara signifikan mengurangi waktu down yang
diperlukan untuk operasi maintenance.
¾ Partitioning meningkatkan availability dari mission-critical database jika
tabel dan index yang penting dibagi menjadi partisi-partisi untuk
26
mengurangi maintenance windows, recovery times, dan dampak dari
kegagalan.
¾ Partitioning dapat diimplementasikan tanpa memerlukan perubahan pada
aplikasi kita.
2.2.4.3 Kriteria Tabel yang Harus Dipartisi
Menurut Situmorang (2004, p309), Indikasi perlunya penerapan tabel terpartisi
apabila ukuran tabel sudah sangat besar misalnya dalam satuan gigabyte atau tabel berisi
data historis di mana data akan ditambahkan pada partisi baru.
Menurut Filibeto (www.filibeto.com/partition.htm) Berikut ini beberapa saran
untuk melakukan partisi pada tabel:
¾ Tabel lebih besar daripada 2 GB harus selalu dipertimbangkan sebagai
kandidat untuk partitioning
¾ Tabel yang mengandung historical data, di mana data yang baru
ditambahkan ke dalam partisi yang terbaru. Sebuah contoh yang umum
adalah sebuah tabel histori di mana hanya data pada bulan yang sedang
berjalan yang dapat di update dan data 11 bulan yang lainnya hanya dapat
dibaca saja.
¾ Ketika isi dari sebuah tabel butuh untuk di distribusikan dengan tipe media
penyimpanan yang berbeda.
27
2.2.4.4 Metode Konversi Tabel Menjadi Tabel Terpartisi
Menurut DBAZine (www.dbazine.com), beberapa metode yang dapat digunakan
untuk partitioning dalam basis data yang telah berjalan, yaitu :
¾ METODE 1 : DIRECT CREATION
Sebuah tabel baru dibuat sebagai sebuah table yang telah dipartisi sejak
awal, dengan cara melakukan select dari table sasaran. Contoh:
CREATE TABLE MYTAB_NEW
PARTITION BY RANGE (COL1) (
PARTITION P1 VALUES LESS THAN (101) TABLESPACE TS_P1,
PARTITION P2 VALUES LESS THAN (201) TABLESPACE TS_P2,
PARTITION P3 VALUES LESS THAN (301) TABLESPACE TS_P3,
PARTITION PM VALUES LESS THAN (MAXVALUE) TABLESPACE
TS_PM )
NOLOGGING
AS SELECT * FROM MYTAB;
Pada contoh di atas, dibentuk sebuah table baru yaitu MYTAB_NEW
sebagai table yang telah dipartisi dan mengandung data sama persis dari
MYDATA. Penggunanaan NOLOGGING bertujuan memastikan data telah
dibentuk dengan jumlah redo yang paling sedikit. Jika dibutuhkan, Anda dapat
menggunakan klausa PARALEL untuk melakukan hal ini pada tabel paralel.
Setelah tabel dibuat, lakukan drop pada tabel awal dan lakukan rename pada tabel
baru ini sehingga namanya menjadi sama dengan nama tabel awal.
DROP TABLE MYTAB;
RENAME MYTAB_NEW TO MYTAB;
28
Kemudian Anda dapat membuat kembali index dan constraint yang ada
pada tabel ini untuk menyamakan dengan apa yang berlaku sebelumnya.
Keuntungan :
o Operasi yang sangat sederhana
o Penggunaan NOLOGGING memastikan generasi redo yang minimal
o Parallel query dapat digunakan untuk mempercepat pemrosesan
Kelemahan :
o Kebutuhan akan space sangat tinggi. Harus ada space yang cukup untuk
sumber dan tabel sasaran pada berbagai poin yang diberikan. Hal ini dapat
menyebabkan masalah yang serius jika basis data Anda mempunyai space
yang ketat.
o Space dibutuhkan dalam sebuah filesystem ketika file basis data dapat
dibentuk, tidak hanya dalam berbagai filesystem. Untuk instance, Anda
mungkin mempunyai /tmp filesystem, namun hal tersebut tidak dapat
digunakan dalam metode konversi ini. Dalam kasus Oracle Parallel
Server atau Real Application Cluster, space harus tersedia dalam area
media penyimpanan yang di-share, bukan dalam local area.
o Adanya kebutuhan untuk melakukan rollback segments. Ketika melakukan
operasi create table as select dari tabel lainnya, Oracle menggunakan
snapshot dari tabel pada awal query. Dalam system yang aktif, pembuatan
tabel akan memproduksi sebuah ORA-1555 Snapshot Too Old error.
o Constraints, indexes, dan triggers harus dibuat secara terpisah setelah
tabel baru dibentuk. Indexes dan constraints, seperti primary keys yang
29
juga membentuk indexes, mungkin membutuhkan waktu yang panjang
untuk dibentuk. Tambahan ini secara garis besar akan memakan waktu.
Tabel yang baru harus dianalisis setelah dibentuk juga.
o Space yang tinggi, waktu, serta konsumsi sumber daya membuat pilihan
Direct Creation lebih tidak menarik jika Anda berhadapan dengan basis
data berskala menengah ataupun besar. Bagaimanapun, untuk basis data,
kesederhanaan dari pilihan tersebut membuatnya menjadi cukup menarik.
¾ METODE 2 : EXPORT/IMPORT
Metode-metode yang lalu telah efisien
namun membutuhkan space
tambahan di samping basis datanya. Jika space tersedia dalam beberapa filesystem
seperti /tmp, yang tidak dapat ditambahkan ke dalam basis data, export data dari
tabel sumber MYTAB ke dalam dump file pada filesystem menggunakan export
utility. (Menggunakan pilihan DIRECT=Y dan setting RECORDSIZE dan
BUFFER parameters untuk mencocokan nilai akan mempercepat proses).
Kemudian drop tabel MYTAB, bentuk sebuah tabel MYTAB yang dipartisi pada
tempat yang sama, kemudian import kembali data yang ada.
Variasi proses lainnya adalah melakukan export bagian dari tabel yang
melakukan korespondensi dengan data dalam partisi menggunakan sebuah where
clause dalam export utility, kemudian melakukan kompres pada dump file untuk
membuat ruang bagi bagian lain. Ketika importing, sebuah single dump file dapat
tidak dikompres, dilakukan import
dilakukan drop.
ke dalam single partition dan kemudian
30
Keuntungan :
o Keuntungan terbesar dari metode ini adalah pengurangan besar space yang
diperlukan secara signifikan. Secara tipikal menghabiskan space lebih sedikit
daripada tabel sumber. Namun kebutuhan untuk space dalam sebuah regular
filesystem seperti /tmp, dan tidak dalam basis data, membuat proses tersebut
menjadi menarik.
o Jika diperlukan, export dump file dapat dibuat dalam tape, optical drive, NAS,
atau bahkan sistem yang terpisah menggunakan UNIX pipe. Fleksibilitas ini
kemungkinan membuka berbagai tempat space lainnya.
o Jika sebuah tabel mengandung kolom LONG, hal ini adalah satu dari 2 pilihan
yang dimungkinkan.
Kelemahan :
o Imports tidak dapat dilakukan tweak untuk mengecilkan proses log, tidak
seperti pilihan direct loader. Sebelumnya, redo generation dan secara
konsekuen, archived log generation, cukup tinggi.
o Kebutuhan rollback segment juga cukup tinggi. Dalam beberapa hal dapat
dikurangi dengan cara importing partition melalui paritition, dan committing
dengan buffer sizes pada baris parameter perintah import.
o Cara ini membuat tabel tidak tersedia untuk operasi secara keseluruhan.
o Semenjak tabel dilakukan drop dan dibuat kembali, semua operasi lainnya,
seperti pembuatan indexes, harus dilakukan setelahnya, dan ini memakan
waktu.
o Import utility tidak mengambil keuntungan dari parallel query servers.
31
¾ METODE 3 : ONLINE REDEFINITION
Beberapa batasan dalam Online Redefinition :
o Tidak dapat dimiliki oleh SYS atau SYSTEM Schema
o Tabel yang akan diredefinisi secara online tidak boleh merupakan sebuah
clustered table
o Tidak boleh memiliki Materialized View Logs atau Materialized Views
defined
Oracle 9i telah mengenalkan sebuah paket, DBMS_REDEFINITION,
untuk mengorganisasi kembali tabel yang online. Sebuah tabel dapat diubah tanpa
melakukan akses dari user.. Fitur ini dapat ditinjau lebih jauh untuk mengkorvesi
sebuah tabel yang tidak dipartisi menjadi sebuah tabel yang terpartisi. Ada
beberapa batasan dalam bagaimana paket ini dapat digunakan, bagaimana untuk
contohnya, tabel tidak boleh mempunyai sebuah snapshot log atau materialized
view log yang terdefinisi pada tabel tersebut, harus tidak boleh mempunyai kolom
yang mengandung tipe data BFILE, LONG, dan sebagainya.
Akan menjadi lebih mudah untuk mengkoversi sebuah tabel menggunakan
online redefinition ketika tabel tersebut memiliki sebuah primary key. Jika tidak
ada primary key,
beberapa non-default parameters harus dilewati untuk
menyelesaikan proses definisi.
Pertama, periksa apakah tabel tersebut dapat diorganisasikan ulang dengan
menggunakan dbms_redefinition dengan cara berikut ini:
32
Begin
dbms_redefinition.can_redef_table (
'SCOTT',
'MYTAB',
dbms_redefinition.cons_use_rowid);
end;
Jika tabel tersebut mempunyai primary key,gunakan sintaks di bawah ini.
Begin
dbms_redefinition.can_redef_table ('SCOTT','MYTAB');
end;
Catat bahwa fungsi dari nilai tetap dbms_redefinition.cons_use_rowid, di
mana menginstruksikan package untuk hanya menggunakan rowed sebagai cara
untuk melakukan pengujian. Jika sebuah tabel dapat diorganisasikan ulang dengan
package , perintah di atas tidak akan menghasilkan apapun. Namun jika ada
alasan
mengapa
dbms_redefinition
tidak
dapat
digunakan
untuk
mengorganisasikan ulang tabel, maka package akan melemparkan penjelasan
tentang kenapa dapat terjadi error.
Menganggap bahwa redefinition dapat dilakukan, langkah selanjutnya
adalah membuat tabel sasaran dengan cara :
CREATE TABLE MYTAB_NEW
PARTITION BY RANGE (COL1)
(
PARTITION P1 VALUES LESS THAN (101) TABLESPACE
TS_P1,
PARTITION P2 VALUES LESS THAN (201) TABLESPACE
33
TS_P2,
PARTITION P3 VALUES LESS THAN (301) TSBALESPACE
TS_P3,
PARTITION PM VALUES LESS THAN (MAXVALUE) TABLESPACE
TS_PM
)
AS
SELECT * FROM MYTAB
WHERE 1=2;
Ini akan membuat sebuah tabel kosong dalam bentuk yang kita inginkan.
Selanjutnya, waktu untuk memulai proses redefinition. Gunakan cara berikut ini :
begin
dbms_redefinition.start_redef_table ('SCOTT', 'MYTAB',
'MYTAB_NEW', null, dbms_redefinition.cons_use_rowid
);
end;
Ingat bahwa fungsi dari NULL sebagai parameter keempat. Parameter ini
memetakan kolom dari tabel asli ke dalam tabel baru, bila mereka berbeda. Sejak
kita tidak mengubah kolom names. Parameter ini tetap bernilai null.
Parameter terakhir menginstruksikan package yang berada pada tabel yang
tidak memiliki primary key dan rowed seharusnya digunakan untuk redefine. Jika
tidak ada primary key, Anda dapat meninggalkan parameter tersebut sebagai
default value dbms_redefinition.cons_use_pk .
34
Oracle membuat beberapa objek untuk memfasilitasi konversi dari
instance, sebuah materialized view log dibuat pada tabel MYTAB, sebuah trigger
dibuat untuk mendata populasi log, sebuah materialized view digunakan dibuat
menggunakan prebuilt table MYTAB_NEW, dan lain sebagainya (Catatan: Sejak
sebuah materialized view log dibuat pada tabel MYTAB, tabel tersebut harus
tidak boleh mempunyai sebuah view log sebelum proses dimulai ).
Ketika Oracle membuat objek ini, tabel sumber sudah dapat di akses
secara penuh dan perubahannya di rekam dengan menggunakan Materialized
View log. Dari waktu ke waktu, Anda seharusnya dapat menggunakan perintah di
bawah ini untuk melakukan penyesuaian tabel dan materialized view.
begin
dbms_redefinition.sync_interim_table ('SCOTT', 'MYTAB',
'MYTAB_NEW');
end;
Ketika operasi sync-up selesai dan Anda telah mencapai waktu yang relatif
singkat, matikan proses penyesuaian.
begin
dbms_redefinition.finish_redef_table ('SCOTT', 'MYTAB',
'MYTAB_NEW');
end;
Operasi ini adalah final sync-up dari materialized view dengan tabel
utama, drop Materialized View logs, dan lain sebagainya, dan lakukan penamaan
ulang pada tabel utama menjadi tabel sasaran. Ketika melakukan langkah akhir,
hal ini akan mengunci tabel untuk sementara, restricting access. Itulah alasannya
35
mengapa Anda harus melakukannya dalam waktu yang relatif singkat. Sejak
proses selesai dan juga sync-up, langkah tersebut dapat dipersingkat jika sync-up
dilakukan terutama untuk memanggil procedure. Dan itulah alasannya pula
mengapa untuk memanggil sync_interim_table() procedure untuk beberapa kali.
Kemudian dapat dilakukan drop pada tabel MYTAB_NEW.
Keuntungan :
o Cara ini dapat dilakukan secara online. Terpisah dari momen yang ringan
ketika final synchronization telah dilakukan, tabel MYTAB dapat diakses
secara penuh.
Kelemahan :
o Kelemahan yang terbesar adalah kebutuhan akan space. Anda akan
membutuhkan space sebesar dua kali dari besar tabel secara keseluruhan,
ditambah space untuk MV logs, dan sebagainya. Jadi, kebutuhan akan space
untuk online redefinition dalam beberapa kasus mungkin dapat menjadi
constraint.
o Pembatasan lainnya diletakkan pada tabel adalah sebaiknya tabel tersebut
tidak mempunyai MV log. Hal ini dapat membuat banyak tabel menjadi tidak
dapat dibaca untuk online redefinition, secara umum dalam DW dan
replications environments, di mana ada kebutuhan paling baik untuk
mengkonversi sebuah tabel yang dipartisi.
o Jika Anda berhadapan dengan tabel berukuran besar, MV log dapat menjadi
kepentingan besar, mempengaruhi kinerja. Dan sejak hal ini dibuat dalam
36
default tablespace Anda, di mana mungkin juga mengandung parent table,
terkadang mungkin perdebatan pada disk level untuk akses.
o Secara khas, pada snapshots besar, cara efisien untuk mengkonversi adalah
dengan membuat sebuah tabel dahulu dengan menggunakan direct load insert,
kemudian untuk menggunakan tabel untuk membuat snapshot dengan
menggunakan ‘prebuilt table’ clause. Sejak snapshot dibuat otomatis oleh
Oracle dan user tidak mempunyai kendali atas itu, populasi awal tidak dapat
mengambil keuntungan seperti dari memanggil pengurangan features.
Sebelumnya, initial load dapat beberapa kali memaksa sumber seperti
rollback segments, temporary tablespaces, dan lain sebagainya. Dan
penggunaan rollback segment dapat memungkinkan trigger ORA-1555 errors.
Menurut Baylis (2003, p.14), ada 2 metode untuk melakukan online
redefinition, yaitu:
-
Dengan menggunakan primary keys atau pseudo-primary keys. Pseudoprimary keys adalah kolom unik yang tidak boleh kosong. Untuk metode
ini, primary key sebelum dan sesudah redefinisi harus merupakan kolom
yang sama. Metode ini merupakan metode yang umum digunakan dalam
redefinisi.
-
Metode kedua adalah dengan menggunakan rowid. Tetapi metode ini
hanya bisa digunakan pada tabel yang tidak memiliki index. Pada
metode ini, tabel hasil setelah redefinisi memiliki kolom baru
tersembunyi yang bernama M_ROW$$. Kolom ini disarankan untuk
37
dihapus atau dianggap tidak digunakan setelah proses redefinisi selesai
dilakukan.
Menurut Pabba (2007, p.1), kita tidak dapat memindahkan sebuah tabel
dari sebuah schema ke schema lainnya dengan menggunakan Online Redefinition.
1. Periksa untuk memastikan bahwa tabel dapat menggunakan fitur online
redefinition:
SQL> EXEC
DBMS_REDEFINITION.CAN_REDEF_TABLE(’CHANDRA’,'T1′);
2. Buat sebuah tabel yang terpartisi (tambahkan atribut apapun yang
diinginkan pada tabel baru yang terpartisi):
Create table t1_part
( col1 number(10),
col2 varchar2(30),
col3 date default sysdate
)
partition by range (col1)
(Partition p1 values less than (100000),
Partition p2 values less than (200000),
Partition p3 values less than (300000),
Partition p4 values less than (400000),
Partition p5 values less than (500000),
38
Partition p6 values less than (600000),
Partition p7 values less than (maxvalue))
tablespace users;
3. Mulai proses online redefinition:
SQL> EXEC
DBMS_REDEFINITION.START_REDEF_TABLE(’CHANDRA’,'T1′,
’T1_PART’);
4. Fitur dalam Oracle 10g lebih mudah. Dalam Oracle9i, kita butuh untuk
membuat constraints, indexes, grants, dan lainnya pada staging table.
triggers, constraints, indexes, dan grants dapat didefinisikan pada tabel. Hal
ini dapat diduplikat pada staging table dengan menjalankan
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( ).
Jika telah selesai, refential constraints dan triggers dikembangkan dalam
stage table (created disabled) dibuat menjadi enable, seluruh statistik akan
disalin, dan semua objek yang di duplikat akan diberi penamaan ulang pada
nama pre-definition mereka.
SQL> VARIABLE NUM_ERRORS NUMBER;
SQL> EXEC
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(’CHANDRA’,'
T1′,’T1_PART’,1,TRUE,TRUE,TRUE,FALSE,:NUM_ERRORS,FA
LSE);
39
SQL> PRINT NUM_ERRORS
5. Sinkronisasi kembali tabel:
SQL> EXEC
DBMS_REDEFINITION.SYNC_INTERIM_TABLE(’CHANDRA’,'T1′
,’T1_PART’);
6. Selesaikan online redefinition:
SQL> EXEC
DBMS_REDEFINITION.FINISH_REDEF_TABLE(’CHANDRA’,'T1′
,’T1_PART’);
7. Validasi :
SQL> Select partition_name, high_value from
user_tab_partitions where table_name=’T1′;
Hak akses yang diijinkan juga dapat disediakan :
SQL> select privilege, grantee from dba_tab_privs
where table_name=’T1′;
Satu-satunya masalah adalah index sekarang menjadi global dan kita dapat
mempunyai sebuah local prefixed indexed. Untuk tujuan ini kita dapat
melakukan drop pada index yang ada dan membuat sebuah local index;
SQL> alter table t1 disable primary key;
40
SQL> drop index t1_idx;
SQL> create index t1_idx on t1(col1) local
tablespace users;
SQL> alter table t1 enable primary key;
SQL> Select index_name, index_type, partitioned
from user_indexes where table_name=’T1′;
2.2.5 Materialized View
Menurut Situmorang (2004, p236), materialized view (MV) merupakan objek
schema yang berisi hasil query. Tabel-tabel yang digunakan pada query dapat berupa
tabel view atau MV lain yang disebut sebagai tabel master (replikasi) atau tabel detail
(data warehouse) dan informasinya tersedia pada data dictionary ALL_MVIEWS,
DBA_MVIEWS, dan USER_MVIEWS. Materialied view atau snapshot ini
digunakan pada basis data terdistribusi untuk membuat replikasi dengan sinkronisasi
data pada berbagai site maupun untuk data warehouse yang mempersiapkan dan
menyimpan data agregat (summarized), MV meningkatkan kecepatan akses query
melalui prekalkulasi join dan operasi agregat sebelum menjalankan dan menyimpan
hasilnya pada basis data. Ketika query terhadap MV dilakukan, query optimizer akan
mengetahui bilamana MV yang ada dapat digunakan dan segera mengakses MV,
bukan ke tabel detail (query rewrite).