Database Performance
Kinerja database berfokus pada tuning
dan mengoptimalkan desain, parameter, dan konstruksi fisik objek database,
khususnya tabel dan indeks, dan di mana file-file data disimpan. Komposisi
aktual dan struktur objek database harus dipantau terus menerus dan berubah
jika database menjadi tidak efisien. Tidak ada jumlah SQL tweaking yang dapat
mengoptimalkan kinerja query saat dijalankan terhadap database yang dirancang
buruk.
Techniques for
Optimizing Databases [ Teknik untuk Mengoptimalkan Database ]
DBA harus paham fitur dari DBMS untuk
menerapkan teknik yang tepat untuk mengoptimalkan struktur kinerja basis data.
Sebagian besar DBMS mendukung teknik-teknik berikut, meskipun dengan nama yang
berbeda. Masing-masing teknik berikut dapat digunakan untuk menyempurnakan
kinerja database dan akan dibahas dalam bagian ini:
•
Partitioning/Partisi - Satu tabel
database menjadi bagian - bagian
yang disimpan dalam beberapa file.
•
Raw partitions versus file systems/Partisi
mentah dibandingkan sistem file - memilih apakah akan menyimpan data
database dalam file OS yang dikendalikan atau tidak.
• Indexing/Pengindeksan - memilih indeks yang tepat dan pilihan untuk
mengaktifkan query yang efisien.
• Denormalization - bervariasi dari desain logis untuk mencapai
kinerja query yang lebih baik.
• Clustering - menegakkan urutan fisik data pada disk.
•
Interleaving data - menggabungkan
data dari beberapa tabel menjadi satu, file yang diurutkan.
• Free space/ruang - meninggalkan
ruang kosong untuk pertumbuhan data.
• Compression/Kompresi - algoritmik mengurangi persyaratan penyimpanan.
• File placement and
allocation/Penempatan file dan alokasi -
menempatkan file yang tepat di tempat yang tepat.
• Page size/ Ukuran - menggunakan ukuran halaman yang tepat untuk
penyimpanan data yang efisien dan I / O.
•
Reorganization/Reorganisasi - menghapus
inefisiensi dari database dengan menyelaraskan dan restrukturisasi objek
database.
Ø Partitioning
Tabel database adalah manifestasi
logis dari sekumpulan data yang secara fisik berada pada penyimpanan
komputerisasi. Salah satu keputusan DBA harus membuat untuk setiap tabel penyimpanan
data. Setiap DBMS menyediakan mekanisme yang berbeda untuk mencapai hal yang
sama-pemetaan file fisik untuk tabel database. DBA harus memutuskan antara
pilihan berikut pemetaan untuk setiap tabel:
• Single table to a single file / Tabel Tunggal untuk satu file.
• Single table to multiple files / Tabel Tunggal untuk beberapa file.
• Multiple
tables to a single file / Beberapa meja
untuk satu file.
Sebenarnya inti dari partisi itu
adalah membagi ruang untuk data-data tertentu. Jika dikaitkan dengan
DBMS,Partisi tabel adalah membagi data suatu tabel menjadi beberapa
bagian/kriteria. Misal tabel mahasiswa, dipartisi/dibagi berdasarkan NIM.
Sehingga dapat diketahui angkatan mahasiswa berdasarkan NIMnya. Dan konsep
partisi ini dapat dikembangkan sebagai DSS (Decision Support System) untuk pengambilan
keputusan tertentu.
Sedangkan index digunakan untuk
mempercepat perncarian data didalam tabel database relasional. Sehingga dengan
adanya index partition, memungkinkan untuk meningkatkan performa pencarian
data. Berikut adalah konsep umum partisi tabel:
Dari
suatu data yang besar, dipecah-pecah lagi per-bagian berdasarkan
kriteria-kriteria tertentu. Pada gambar di atas, dari suatu data dibagi
berdasarkan bulan.
Manfaat
lain dari partitioning adalah tiap-tiap segment (partisi atau subpartisi) bisa
ditaruh di tablespace yang berbeda, sehingga kita mendapat manfaat dari spreading (menyebar)
tablespace, yaitu penyebaran I/O dan mengurangi resiko loss data karena
tablespace corrupt.
Ada 3 metode utama partisi:
- Range partition
Range partition adalah pembagian
suatu tabel ke dalam beberapa bagian berdasarkan range (rentang) nilai
tertentu. Range partition ini cocok digunakan pada kolom yang memiliki
distribusi nilai yang merata.
- List partition
Konsep pada list partition adalah
data dikelompokkan berdasarkan nilai datanya. Cocok untuk kolom yang variasi
nilainya tidak banyak. Misal data kota berdasarkan wilayah provinsi. List:
Jember, Malang, Surabaya pada partisi Jawa Timur; Bandung, Cirebon pada partisi
Jawa Barat. Jadi list partition ini berdasarkan list dari suatu segmen,
sehingga data-datanya di list terlebih dahulu.
- Hash partition
Penggunaan hash partition ini jika tidak cocok
dengan RANGE ataupun LIST Partition. Penentuan “nilai mana di taruh di partisi
mana” itu diatur secara internal oleh Oracle (berdasarkan hash value). Kenapa
harus memaksakan memakai partisi sementara tidak cocok dengan RANGE ataupun
LIST? Jika ingin mendapat manfaat dari filosofi PARTITIONING yang sebenarnya di
mana data disebar ke segment-segment yang berbeda.
Dan 2 metode composite (gabungan):
- Composite range-list partition
Konsep composite range-list partition
ini menggabungkan partisi range dan list. Jika pada tabel mahasiswa, NIM
dipartisi secara range, sedangkan untuk mendapatkan NIM sekian yang tinggal di
wilayah provinsi Jawa Timur itu apa saja, maka menggunakan list. Jadi dipartisi
kemudian di list berdasarkan kriteria tertentu.
- Composite range-hash partition
Composite range-hash partition
merupakan konsep menggabungkan range partition dan hash partition. Sehingga
partisi-partisi yang telah dibuat berdasarkan range/rentang akan dipartisi lagi
ke dalam beberapa bagian berdasarkan hash.
Ø Raw Partition vs. File System
Untuk lingkungan DBMS berbasis UNIX, DBA harus
memilih antara partisi mentah dan menggunakan sistem berkas UNIX untuk
menyimpan data dalam database. Sebuah partisi mentah adalah pilihan jenis
perangkat fisik untuk penyimpanan database karena menulis cache oleh sistem
operasi ketika sebuah sistem file yang digunakan. Ketika menulis disangga oleh
sistem operasi, DBMS tidak tahu apakah data telah fisik disalin ke disk atau
tidak. Ketika cache manajer DBMS mencoba untuk menulis data ke disk, sistem
operasi dapat menunda menulis sampai nanti karena data mungkin masih di cache
sistem file. Jika terjadi kegagalan, data dalam database menggunakan sistem
file untuk penyimpanan mungkin tidak 100% dapat dipulihkan. Hal ini harus
dihindari.
Jika partisi baku digunakan sebagai pengganti, data
ditulis langsung dari database cache ke disk tanpa sistem file menengah atau
caching sistem operasi, seperti yang ditunjukkan pada Gambar 11-1. Ketika cache
manajer DBMS menulis data ke disk, secara fisik akan ditulis ke disk tanpa
intervensi. Selain itu, ketika menggunakan partisi mentah, DBMS akan memastikan
bahwa cukup ruang yang tersedia dan menulis halaman alokasi. Bila menggunakan
sistem file, sistem operasi tidak akan preallocate ruang untuk penggunaan
database.
Dari perspektif kinerja, tidak ada
keuntungan untuk memiliki lapisan sekunder caching pada sistem file atau operasi
tingkat sistem, cache DBMS cukup. Sebenarnya, pekerjaan tambahan yang
diperlukan untuk cache data untuk kedua kalinya mengkonsumsi sumber daya,
sehingga berdampak negatif pada kinerja keseluruhan operasi database.
Ø Indexing
Indexing merupakan sebuah proses
untuk melakukan pengindeksan terhadap kumpulan dokumen yang akan disediakan
sebagai informasi kepada pemakai. Menciptakan indeks yang benar pada tabel
dalam database mungkin adalah teknik tuning
kinerja yang DBA dapat dilakukan. Indeks digunakan untuk meningkatkan kinerja. Indeks
sangat berguna untuk :
• Mencari baris dengan nilai (s) pada kolom (s)
• Membuat bergabung lebih efisien (ketika indeks
didefinisikan pada kolom join)
• Korelasi data di tabel
• Agregasi Data
• Mengurutkan data untuk memenuhi permintaan
Tanpa
indeks, semua akses ke data dalam database harus dilakukan dengan memindai
semua baris yang tersedia. Scan sangat tidak efisien untuk tabel yang sangat
besar.
Tujuan umum analisis indeks adalah
dengan menggunakan lebih sedikit I / O ke database untuk memenuhi permintaan
yang dilakukan terhadap meja. Tentu saja, indeks dapat membantu beberapa
pertanyaan dan menghalangi orang lain. Oleh karena itu, DBA harus menilai
dampak dari penambahan indeks untuk semua aplikasi dan tidak hanya menyempurnakan
permintaan tunggal dalam ruang hampa. Ini bisa menjadi tugas yang berat tapi bermanfaat.
Proses pengindeksan bisa secara manual
ataupun secara otomatis. Dewasa ini, sistem pengindeksan secara manual mulai
digantikan oleh sistem pengindeksan otomatis. Adapun tahapan dari pengindeksan
adalah sebagai berikut:
1. Tokenozation Dokumen
yaitu proses pengambilan kata-kata dari kumpulan dokumen.
2. Penghapusan Stoplist yaitu
proses pembuangan kata buang seperti: a, an, is, then, with, dan sebagainya.
3. Stemming yaitu
proses penghilangan/ pemotongan dari suatu kata menjadi bentuk dasar. Kata
“diadaptasikan” atau “beradaptasi” mejadi kata “adaptasi” sebagai istilah.
4. Term Weigthing yaitu
proses pembobotan term dengan melihat frekuensi kemunculan kata pada setiap
dokumen. Untuk lebih detailnya, pembobotan dijelaskan pada sub bab berikutnya.
-
Index Overloading
Kinerja query dapat ditingkatkan
dalam situasi tertentu dengan melakukan overloading indeks dengan kolom
tambahan. Indeks biasanya didasarkan pada klausa WHERE SQL SELECT pernyataan.
Sebagai contoh, perhatikan pernyataan SQL berikut.
select emp_no, last_name, salary
from employee
where salary > 15000.00
;
DBA harus mempertimbangkan
overloading indeks untuk mendorong indeks-satunya akses saat beberapa query
bisa mendapatkan keuntungan dari indeks atau saat permintaan individu sangat
penting.
Ø Denormalization
Cara lain untuk mengoptimalkan
kinerja akses database untuk denormalize tabel. Denormalization telah dibahas
secara rinci dalam Bab 4, jadi kami tidak akan membahas topik secara mendalam
di sini. Cukuplah untuk mengatakan, denormalization, kebalikan dari normalisasi,
adalah proses menempatkan satu fakta di banyak tempat. Ini mempercepat
pengambilan data dengan mengorbankan modifikasi data. Denormalizing tabel bisa
menjadi keputusan yang baik ketika desain yang benar-benar normal tidak tampil
maksimal.
Satu-satunya alasan untuk pernah
denormalize desain database relasional adalah untuk meningkatkan kinerja.
Sebagaimana dibahas dalam Bab 4, Anda harus mempertimbangkan pilihan berikut:
•
Prejoined tabel-ketika biaya bergabung adalah mahal.
•
Laporan table-saat kritis laporan khusus terlalu mahal untuk menghasilkan.
•
Cermin tabel-tabel ketika diperlukan secara bersamaan oleh dua jenis
lingkungan.
•
tabel-saat Berpisah kelompok yang berbeda menggunakan bagian yang berbeda dari
meja.
•
Gabungan tabel-untuk mengkonsolidasikan satu-ke-satu atau satu-ke-banyak
hubungan ke tabel tunggal.
•
Tabel-to Kecepatan mendukung hirarki seperti tagihan-of-bahan atau struktur
pelaporan.
•
denormalization-to Fisik mengambil keuntungan dari karakteristik DBMS tertentu.
Anda mungkin juga mempertimbangkan
•
Menyimpan data yang berlebihan dalam tabel untuk mengurangi jumlah meja
bergabung diperlukan.
•
Menyimpan kelompok berulang dalam satu baris untuk mengurangi I / O dan mungkin
ruang disk.
•
Menyimpan data diturunkan untuk menghilangkan perhitungan dan algoritma mahal.
Denormalization Field Map
Dari Tabel Order
Details
Beralih ke bagian Bidang Peta Denormalization, dan
masukkan peta bidang berikut:
dbo.Orders
=> dbo.Employees
FirstName
HomePhone
Tekan
Finish untuk menyimpan perubahan.
Ø Clustering
Sebuah meja berkerumun akan menyimpan
baris yang secara fisik pada disk dalam rangka kolom khusus. Clustering
biasanya ditegakkan oleh DBMS dengan indeks clustering. Pengelompokan Indeks
pasukan baris tabel untuk disimpan dalam urutan menaik oleh kolom diindeks.
Urutan kiri ke kanan dari kolom sebagaimana didefinisikan dalam indeks,
mendefinisikan urutan menyusun untuk clustered index. Hanya ada satu urutan
pengelompokan per tabel (karena secara fisik data dapat disimpan dalam satu
urutan).
Gambar
11-2 menunjukkan perbedaan antara berkerumun dan unclustered data dan indeks,
indeks berkerumun berada di atas, indeks unclustered adalah di bagian bawah.
Seperti yang Anda lihat, entri pada halaman daun indeks atas dalam urutan
sekuensial-dengan kata lain, mereka berkerumun. Clustering meningkatkan kinerja
query yang mengakses data secara berurutan karena lebih sedikit I / Os perlu
dikeluarkan untuk mengambil data yang sama.
Figure 11-2.
Clustered and unclustered indexes
Tergantung pada DBMS, data mungkin tidak
selalu secara fisik dipertahankan dalam urutan pengelompokan yang tepat. Ketika
urutan pengelompokan telah didefinisikan untuk tabel, DBMS akan bertindak dalam
satu dari dua cara untuk menegakkan pengelompokan:
1.
Ketika baris baru dimasukkan, DBMS fisik akan manuver baris data dan halaman
agar sesuai dengan baris baru ke urutan pengelompokan didefinisikan; atau
2.
Ketika baris baru dimasukkan, DBMS akan mencoba untuk menempatkan data ke
urutan pengelompokan didefinisikan, tetapi jika ruang tidak tersedia pada
halaman yang dibutuhkan data dapat ditempatkan di tempat lain.
DBA
harus belajar bagaimana DBMS mempertahankan clustering. Jika DBMS beroperasi
seperti dalam skenario kedua, data dapat menjadi unclustered dari waktu ke
waktu dan memerlukan reorganisasi. Sebuah diskusi rinci reorganisasi database
yang muncul kemudian dalam bab ini. Untuk saat ini, meskipun, kembali ke
diskusi kita tentang clustering.
Tabel
Clustering yang diakses secara berurutan adalah praktik yang baik. Dengan kata
lain, indeks berkerumun baik untuk mendukung akses jangkauan, sedangkan indeks
unclustered lebih baik untuk mendukung random mengakses. Pastikan untuk memilih
kolom pengelompokan bijaksana. Gunakan indeks berkerumun untuk situasi berikut:
•
Gabung kolom, untuk mengoptimalkan SQL bergabung di mana beberapa baris sesuai
untuk satu atau kedua tabel berpartisipasi dalam bergabung
•
kolom kunci asing karena mereka sering terlibat dalam bergabung dan DBMS
mengakses nilai-nilai kunci asing selama integritas referensial deklaratif
memeriksa
•
Predikat dalam WHERE clause
•
kolom Rentang
•
Kolom yang tidak berubah sering (mengurangi fisik reclustering)
•
Kolom yang sering dikelompokkan atau diurutkan dalam pernyataan SQL
Clustering
umumnya tidak dianjurkan untuk kolom primary key karena kunci utama adalah,
menurut definisi, unik. Namun, jika rentang baris sering dipilih dan
diperintahkan oleh nilai kunci primer, indeks pengelompokan mungkin bermanfaat.
Ø Interleaving
Data
Bila
data dari dua tabel sering bergabung, dapat masuk akal untuk fisik Interleave
data ke dalam struktur penyimpanan fisik yang sama. Hal ini dapat dilihat
sebagai bentuk khusus clustering (dan, pada kenyataannya, Oracle menggunakan
cluster istilah untuk mendefinisikan data interleaved). Interleaving Data
tercakup dalam Bab 4 dan disebutkan di sini sebagai teknik tuning kinerja untuk
mempertimbangkan.
Gambar. Interval Data
Ø Free Space
Ruang
bebas, kadang-kadang disebut faktor pengisian, bisa digunakan untuk
meninggalkan sebagian dari tablespace atau indeks kosong dan tersedia untuk
menyimpan data yang baru ditambahkan. Spesifikasi ruang bebas dalam tablespace
atau indeks dapat mengurangi frekuensi reorganisasi, mengurangi pertentangan,
dan meningkatkan efisiensi penyisipan. Setiap DBMS menyediakan metode
menentukan ruang bebas untuk objek database CREATE dan ALTER pernyataan. Sebuah
parameter khas adalah PCTFREE, di mana DBA menentukan persentase setiap halaman
data yang harus tetap tersedia untuk menyisipkan masa depan. Parameter lain
yang mungkin adalah FREEPAGE, di mana DBA menunjukkan jumlah halaman tertentu
setelah halaman benar-benar kosong yang tersedia.
Memastikan
jumlah yang tepat ruang bebas untuk setiap objek database menyediakan manfaat
sebagai berikut :
• Sisipan cepat
bila ruang bebas yang tersedia.
• Sebagai baris
baru dimasukkan, mereka dapat dikelompokkan dengan baik.
•
Variabel-panjang baris dan baris diubah memiliki ruang untuk memperluas,
berpotensi mengurangi jumlah baris
direlokasi.
• sedikit baris pada halaman hasil di
concurrency lebih baik karena kurang data tidak tersedia untuk pengguna lain
ketika halaman terkunci.
Namun, ruang
bebas juga memiliki beberapa kelemahan :
• persyaratan
penyimpanan Disk lebih besar.
• Memindai
memakan waktu lebih lama.
• sedikit baris
pada halaman dapat memerlukan lebih banyak I / O operasi untuk mengakses
informasi yang diminta.
• Karena jumlah
baris per halaman menurun, efisiensi caching data dapat berkurang karena lebih
sedikit baris yang akan diambil per I / O.
DBA
harus memantau ruang bebas dan memastikan bahwa jumlah yang sesuai
didefinisikan untuk setiap objek database. Jumlah yang benar ruang bebas harus
didasarkan pada :
• Frekuensi
sisipan dan modifikasi
• Jumlah akses
sekuensial dibandingkan random
• Dampak
mengakses data unclustered
• Jenis
pengolahan
• Kemungkinan
baris chaining, migrasi baris, dan halaman perpecahan
Pada GUI yang ditampilkan,
Select Installation Method, Pilih Basic
Installation, kemudian isikan :
|
1
2
3
4
5
|
# Oracle Home Location: "/u01/app/oracle/product/10.2.0/db_1"
# Installation Type: "Enterprise Edition 1.3 GB"
# UNIX DBA Group: "dba"
# Checklist pada "Create Starter Database",
isikan Global Database Name ("orcl" — ses
|
Gambar.Proses
Free Space pada Oracle
Ø Compression
Kompresi dapat digunakan untuk
mengecilkan ukuran database. Dengan mengompresi data, database membutuhkan
penyimpanan disk sedikit. Beberapa DBMS memberikan pilihan DDL internal untuk
kompres file database, perangkat lunak pihak ketiga yang tersedia untuk mereka
yang tidak menyediakan fitur tersebut.
Bila kompresi yang ditentukan, data
algoritmik dikompresi pada penyisipan ke dalam database dan didekompresi ketika
dibaca. Membaca dan menulis data terkompresi mengkonsumsi sumber daya CPU lebih
daripada membaca dan menulis data terkompresi: DBMS harus mengeksekusi kode
untuk kompres dan dekompresi data sebagai pengguna insert, update, dan membaca
data.
Namun, kompresi bukan merupakan
pilihan untuk setiap indeks database atau tabel. Untuk jumlah data yang lebih
kecil, adalah mungkin bahwa sebuah file terkompresi akan lebih besar dari file
terkompresi. Hal ini terjadi karena beberapa DBMSs dan algoritma kompresi
memerlukan kamus internal untuk mengelola kompresi. Kamus berisi statistik
tentang komposisi data yang dikompres. Untuk jumlah sepele data, ukuran kamus
mungkin lebih besar daripada jumlah penyimpanan diselamatkan oleh kompresi.
Contoh Gambar.Proses Compression
Ø File Placement
and Allocation
Lokasi dari file berisi data untuk
database dapat memiliki dampak yang signifikan terhadap kinerja. Database adalah
sangat I / O intensif, dan DBA harus melakukan segala upaya untuk meminimalkan
biaya disk fisik membaca dan menulis.
Disiplin
ini memerlukan :
•
Memahami pola akses yang terkait dengan setiap bagian dari data dalam sistem
• Menempatkan data pada perangkat disk
fisik sedemikian rupa untuk mengoptimalkan kinerja
Pertimbangan pertama untuk penempatan
berkas pada disk untuk memisahkan indeks dari data, jika memungkinkan. Query
database sering diperlukan untuk mengakses data dari kedua tabel dan indeks di
atas meja itu. Jika kedua file ini berada pada perangkat disk yang sama,
penurunan kinerja mungkin. Untuk mengambil data dari disk, lengan bergerak di
atas permukaan disk untuk membaca blok fisik data pada disk. Jika satu operasi
akan mengakses data dari file pada perangkat disk yang sama, latency akan
terjadi, membaca dari satu file akan harus menunggu sampai membaca dari file
lain diproses. Tentu saja, jika DBMS menggabungkan indeks dengan data dalam
file yang sama, teknik ini tidak dapat digunakan.
Aturan lain untuk penempatan file
untuk menganalisis pola akses aplikasi Anda dan memisahkan file untuk tabel
yang sering diakses bersama-sama. DBA harus melakukan ini untuk alasan yang
sama ia harus memisahkan file indeks dari file tabel.
Pertimbangan terakhir untuk
menempatkan file pada perangkat disk yang terpisah terjadi ketika sebuah tabel
tunggal disimpan dalam beberapa file (partisi). Adalah bijaksana dalam hal ini
untuk menempatkan setiap file pada perangkat disk yang terpisah untuk mendorong
dan mengoptimalkan operasi database paralel. Jika DBMS dapat pecah query untuk
menjalankannya secara paralel, menempatkan beberapa file untuk tabel dipartisi
pada perangkat disk yang terpisah akan meminimalkan latency disk yang.
Ada beberapa File Placement and Allocation untuk
database,yaitu :
ü Database Log Placement [Database Log Penempatan]
ü Distributed Data Placement [Distributed Penempatan
data]
ü Disk Allocation [Disk Alokasi]
Ø Gambar.
Proses File
Placement and Allocation
Ø Page Size (Block
Size)
Kebanyakan DBMS menyediakan kemampuan
untuk menentukan halaman, atau blok, ukuran. Ukuran halaman yang digunakan
untuk menyimpan baris tabel (atau lebih tepatnya, catatan yang berisi isi baris
ditambah biaya overhead ada) pada disk. Sebagai contoh, perhatikan tabel
membutuhkan baris yang 125 byte panjangnya dengan 6 tambahan byte overhead. Hal
ini membuat setiap record 131 byte panjang. Untuk menyimpan 25 catatan pada
halaman, ukuran halaman akan menjadi setidaknya 3275 byte. Namun, masing-masing
DBMS membutuhkan beberapa jumlah halaman overhead juga, sehingga ukuran praktis
akan lebih besar. Jika halaman overhead 20 byte, maka ukuran halaman akan
menjadi 3295-yaitu, 3275 + 20 byte overhead.
Gambar. Page size/ Ukuran
Ø Database Reorganization
Teknologi relasional dan SQL membuat
modifikasi data yang mudah. Hanya mengeluarkan pernyataan INSERT, UPDATE, atau
DELETE dengan klausa WHERE yang sesuai, dan DBMS mengurus aktual data navigasi
dan modifikasi. Dalam rangka memberikan tingkat abstraksi, DBMS menangani
penempatan fisik dan pergerakan data pada disk. Secara teoritis, hal ini
membuat semua orang senang. Antarmuka programmer disederhanakan, dan RDBMS
mengurus hard paruh memanipulasi penempatan data aktual. Namun, hal ini tidak
sesederhana itu. Cara di mana DBMS mengelola data fisik dapat menyebabkan
masalah kinerja selanjutnya.
Menentukan Kapan Reorganisasi :
Statistik sistem katalog dapat
membantu untuk menentukan kapan untuk menata objek database. Setiap DBMS
menyediakan metode membaca isi database dan pencatatan informasi statistik
tentang setiap objek database. Tergantung pada DBMS, informasi statistik ini
disimpan baik dalam sistem katalog atau halaman khusus dalam objek database itu
sendiri.
Satu statistik yang dapat membantu
DBA menentukan kapan untuk menata adalah rasio klaster. Rasio Cluster adalah
persentase baris dalam tabel yang benar-benar disimpan dalam urutan clustering.
Semakin dekat rasio cluster sampai 100%, yang lebih dekat sebenarnya urutan
baris pada halaman data sesuai urutan clustering. Rasio klaster rendah
menunjukkan pengelompokan buruk, dan reorganisasi mungkin diperlukan. Rasio
klaster rendah, bagaimanapun, tidak mungkin menjadi penghalang kinerja jika
mayoritas akses data query secara acak, bukan secara berurutan.
Statistik lain indeks untuk
menganalisis untuk menentukan apakah reorganisasi diperlukan adalah jarak
antara halaman indeks daun, atau jarak daun. Jarak daun adalah perkiraan
rata-rata jumlah halaman antara halaman daun berturut-turut dalam indeks.
Kesenjangan antara halaman daun dapat berkembang sebagai data akan dihapus dari
indeks atau sebagai akibat dari halaman membelah. Tentu saja, nilai terbaik
untuk jarak daun adalah nol, tapi mencapai jarak daun nol dalam prakteknya
tidak realistis. Secara umum, semakin rendah nilai ini, semakin baik. Meninjau
nilai dari waktu ke waktu untuk menentukan tanda-air yang tinggi untuk jarak
daun yang akan menunjukkan bila indeks harus direorganisasi.
Gambar.
Proses Reorganization/Reorganisasi
KESIMPULAN :
Aplikasi
dan data yang terus berubah. Pengguna memerlukan waktu respon instan dan 24/7
ketersediaan. Struktur database yang mendukung aplikasi ini harus terjaga baik
untuk memastikan kinerja aplikasi yang optimal. Database desain yang tepat,
sesuai pilihan clustering, dan reorganisasi database berdasarkan statistik
membantu untuk memberikan database yang efisien. Selanjutnya, DBA dapat
memastikan kinerja database dengan mengotomatisasi proses ini untuk mengurangi
risiko dan kesalahan yang terkait dengan pemeliharaan database pengguna.
