BAB 4 IMPLEMENTASI DAN EVALUASI
4.1
Implementasi 4.1.1 Arsitektur RDBMS Sistem recovery basis data yang dibuat dalam penelitian ini merupakan bagian dari RDBMS (Relational Database Management System). RDBMS terdiri dari beberapa komponen yang meliputi security control, SQL Parser, sistem concurrency, transaction recovery manager yang akan disebut sistem recovery basis data, sistem backup and restore, dan sistem storage management. SQL Parser berfungsi sebagai compiler statement SQL yang dimasukkan oleh pengguna. Sistem concurrency berfungsi sebagai pengatur jadwal pengerjaan operasi transaksi. Sistem recovery transaksi berfungsi menjalankan operasi yang diinginkan pengguna untuk merubah basis data. Sistem backup and restore berfungsi melakukan backup dan restore terhadap basis data. Sedangkan sistem storage management berfungsi melakukan penulisan terhadap basis data, membuat basis data fisikal, membuat indeks dan sebagainya, serta melakukan pencarian dan retrieve data sebagai respon dari operasi select.
73
74
Gambar 4.1 Arsitektur RDBMS Pengguna RDMBS akan memasukkan query dan di-compile oleh SQL Parser. Kemudian operasi tiap transaksi akan diurutkan oleh sistem concurrency untuk dikerjakan. Pengerjaan operasi tidak boleh saling menimpa data dalam basis data sehingga dalam sistem concurrency terdapat mekanisme locking. Operasi transaksi dan data relevan yang dikirimkan sistem concurrency akan diterima oleh sistem recovery basis data yang kemudian akan menuliskan operasi yang diterima ke dalam log file, dan mengerjakan operasi tersebut di temporary database. Bila operasi sudah dikerjakan, maka hasilnya akan disalin ke dalam basis data oleh sistem storage management. Dalam interval waktu tertentu, misalnya satu minggu atau satu bulan, pengguna mungkin ingin membuat backup dari basis data yang didukung oleh sistem backup and restore. Sistem backup and restore juga dapat melakukan restore terhadap basis data berdasarkan backup yang sebelumnya telah dibuat. Penelitian ini difokuskan pada sistem recovery basis data yang mendukung proses logging, checkpoint, dan recovery. 4.1.2
Sistem Recovery Basis Data
75
Secara umum, sistem recovery basis data yang dibuat dalam penelitian ini adalah sistem yang mampu melakukan logging atau menulis ke log bila ada transaksi yang masuk ke RDBMS dan sistem dapat melakukan recovery atau mengembalikan basis data ke consistent state bila terjadi system failure. Setiap kali server mulai dijalankan, sistem akan melakukan proses recovery. Setelah itu, bila ada transaksi yang harus dikerjakan, sistem akan melakukan proses logging berdasarkan data yang dikirimkan oleh sistem concurrency. Pada interval waktu tertentu, sistem akan melakukan proses checkpoint yang menjamin semua operasi transaksi yang telah dikerjakan di temporary database masuk ke dalam basis data. Dan bila terjadi system failure, sistem recovery basis data akan melakukan proses recovery. Pada saat transaksi masuk, sistem concurrency akan membuat satu objek dari class Transaksi untuk tiap transaksi. Objek Transaksi akan membuat objek lagi dari class Log dan hasil pembuatan objek dimasukkan ke dalam atribut LogObject. Selain itu, objek Transaksi juga akan membuat objek dari class TempDB dan hasilnya dimasukkan ke dalam atribut TempDBObject. Bila ada operasi update, sistem concurrency akan memanggil method addUpdateOperation(), yang kemudian akan memanggil method writeUpdateOperation() dengan informasi yang dikirimkan berupa KodeTransaksi, JenisOperasi, KodeDatabase, KodeTabel, KodeField, KodeRecordLama, KodeRecordBaru, BeforeImage, AfterImage milik
76
LogObject untuk mencatat operasi tersebut ke dalam log file. Sedangkan WaktuDatang, pPtr, dan nPtr akan di-generate oleh sistem recovery basis data. Bila ada operasi insert, sistem concurrency akan memanggil method addInsertOperation(), yang kemudian akan memanggil method writeInsertOperation() dengan informasi yang dikirimkan berupa KodeTransaksi, JenisOperasi, KodeDatabase, KodeTabel, KodeField, KodeRecordBaru, AfterImage milik LogObject untuk mencatat operasi tersebut ke dalam log file. WaktuDatang, pPtr, dan nPtr akan di-generate oleh sistem recovery basis data Bila ada operasi delete, sistem concurrency akan memanggil method addDeleteOperation(), yang kemudian akan memanggil method writeDeleteOperation() dengan informasi yang dikirimkan berupa KodeTransaksi, JenisOperasi, KodeDatabase, KodeTabel, KodeField, KodeRecordLama, BeforeImage milik LogObject untuk mencatat operasi tersebut ke dalam log file. WaktuDatang, pPtr, dan nPtr akan di-generate oleh sistem recovery basis data Kemudian sistem akan memanggil method writeToTempDBFile() milik TempDBObject untuk menjalankan operasi ke temporary database. Informasi
yang
dikirimkan
meliputi
KodeDatabase,
KodeTabel,
KodeField, KodeRecord dan Value. Setelah itu, sistem akan memanggil method writeToDB(). Untuk operasi insert dan update, informasi yang akan dikirimkan meliputi KodeDatabase,
KodeTabel,
KodeField,
KodeRecordBaru,
dan
77
AfterImage dari logfile. Kemudian juga dikirim flag IsDelete dengan nilai FALSE. Untuk operasi delete, informasi yang dikirimkan meliputi KodeDatabase, KodeTabel, KodeField, KodeRecordBaru, dan flag IsDelete dengan nilai TRUE. Bila penulisan sudah selesai, sistem storage management akan mengirimkan sinyal sebagai konfirmasi. Pada saat transaksi di-commit, sistem akan memanggil method Commit() dari Transaksi. Di dalam method ini akan dipanggil method writeCommit() dari LogObject. Setelah semua operasi dalam transaksi berhasil dikerjakan ke dalam basis data, sistem recovery basis data akan mengirimkan sinyal konfirmasi ke sistem concurrency untuk melepaskan lock yang ada. Sebaliknya bila transaksi di-abort, akan dipanggil method Abort() dari Transaksi. Di dalam method ini akan dipanggil method writeAbort() dari LogObject dan kemudian dilakukan proses undo terhadap transaksi tersebut. Dalam interval waktu tertentu, proses checkpoint akan terjadi. Pada saat checkpoint, sistem akan memanggil method getDBList() dari sistem storage management untuk memperoleh semua nama basis data yang
ada.
Setelah
itu,
sistem
akan
menulis
record
START
CHECKPOINT dan transaksi yang masih aktif ke dalam semua log file menggunakan method writeStartCheckpoint(). Kemudian semua record dalam temporary database akan disalin ke dalam basis data menggunakan method writeToDB(). Setelah penulisan ke basis data selesai, maka akan dipanggil method
78
writeEndCheckpoint() untuk menulis record END CHECKPOINT ke semua log file. Pada saat proses recovery dijalankan, sistem akan memanggil method getDBList yang dibuat oleh sistem storage management untuk memperoleh semua nama basis data yang terdapat dalam basis data fisikal. Dengan nama basis data yang ada akan dibuat masing-masing satu objek dari class Recovery(NamaDatabase). Folder untuk log file telah dibuat oleh sistem storage management tiap kali membuat sebuah basis data. Setelah mendapatkan log file dari tiap basis data, sistem akan melakukan tracking dari bawah ke atas untuk mengidentifikasi status transaksi pada log file. Log file diperiksa dari record terakhir, flag IsCheckpointEnded diinisialisasi dengan nilai FALSE, flag tersebut digunakan sebagai batas akhir pemeriksaan log file. Pada saat pemeriksaan
log
file,
bila
bertemu
dengan
record
COMMIT
TRANSACTION, maka transaksi tersebut akan dimasukkan ke dalam atribut CommittedTransaction dalam class Recovery. Bila bertemu dengan record ABORT TRANSACTION, maka transaksi tersebut dimasukkan ke dalam atribut AbortedTransaction. Bila bertemu dengan record operasi UPDATE, INSERT atau DELETE pada saat tracking dilakukan, maka sistem akan mengecek apakah operasi tersebut termasuk dalam transaksi yang sudah masuk dalam CommitedTransaction, AbortedTransaction, atau bukan keduanya.
79
Bila tidak termasuk keduanya, maka transaksi tersebut akan dimasukkan ke dalam atribut UnfinishedTransaction. Bila bertemu dengan record END CHECKPOINT, maka flag IsCheckpointEnded akan diubah menjadi TRUE. Dan bila bertemu dengan record START CHECKPOINT dan flag IsCheckpointEnded bernilai TRUE, maka tracking atau pemeriksaan log file dihentikan. Dari record START CHECKPOINT akan diperoleh transaksitransaksi yang aktif pada saat checkpoint dilakukan. Jika transaksi tersebut sudah termasuk dalam UnfinishedTransaction, maka transaksi tersebut juga dimasukkan ke dalam atribut ActiveUnfinishedTransaction. Berdasarkan transaksi-transaksi yang tercatat dalam atribut CommittedTransaction,
UnfinishedTransaction,
dan
ActiveUnfinishedTransaction, maka akan dilakukan proses redo atau undo terhadap transaksi-transaksi tersebut. Proses redo dilakukan dari atas ke bawah log file mulai dari record START CHECKPOINT. Bila bertemu dengan record operasi update, insert, atau delete dan transaksi dari operasi tersebut termasuk dalam CommittedTransaction, maka operasi tersebut di-redo atau dikerjakan kembali dengan cara menuliskan operasi tersebut ke basis data fisikal lagi. Record yang harus ditulis kembali ke basis data kemungkinan besar sudah terdapat dalam basis data fisikal. Oleh karena itu, record tersebut akan ditimpa. Hal ini tidak perlu dikhawatirkan karena proses recovery basis data bersifat idempotent, yaitu berapa kali pun suatu transaksi dikerjakan, hasilnya akan tetap sama.
80
Dalam proses redo bila bertemu dengan operasi update atau insert yang harus dituliskan kembali ke basis data, maka akan dipanggil method writeToDB() milik sistem storage management. Informasi yang dikirimkan
meliputi
KodeDatabase,
KodeTabel,
KodeField,
KodeRecordBaru, dan AfterImage dari logfile, kemudian juga dikirim flag IsDelete dengan nilai FALSE. Sedangkan untuk operasi delete, juga akan dipanggil method writeToDB() dengan informasi yang dikirimkan meliputi KodeDatabase, KodeTabel, KodeField, KodeRecordBaru, dan flag IsDelete bernilai TRUE. Flag IsDelete adalah flag yang terdapat dalam tiap record temporary database. Bila flag IsDelete bernilai TRUE, maka record tersebut akan dihapus dari basis data, tetapi bila bernilai FALSE, maka record tersebut akan ditambahkan ke dalam basis data. Proses redo akan dilakukan hingga record log file terakhir. Setelah mencapai record terakhir maka proses redo selesai, dilanjutkan proses undo. Proses undo dilakukan dari bawah ke atas mulai dari record terakhir. Bila bertemu dengan record operasi update, insert, atau delete dan
jika
transaksi
dari
operasi
tersebut
termasuk
dalam
UnfinishedTransaction, maka operasi tersebut harus di-undo. Untuk operasi insert, maka record yang masuk ke dalam basis data harus dihapus. Sebaliknya untuk operasi delete, maka record yang telah dihapus dalam basis data harus diaktifkan kembali. Untuk operasi update,
81
maka record baru akan ditimpa dengan nilai sebelumnya (BeforeImage) yang tercatat di log file. Bila bertemu dengan operasi update, maka sistem akan memanggil method writeToDB() milik sistem storage management dan mengirimkan informasi berupa KodeDatabase, KodeTabel, KodeField, KodeRecordBaru dan BeforeImage dengan flag IsDelete bernilai FALSE. Untuk operasi insert, informasi yang dikirimkan meliputi KodeDatabase, KodeTabel, KodeField, dan KodeRecordBaru dengan flag IsDelete bernilai TRUE. Untuk operasi delete, informasi yang dikirimkan meliputi KodeDatabase, KodeTabel, dan KodeRecordLama dengan flag IsDelete bernilai FALSE. Setelah mencapai record START CHECKPOINT, sistem akan mengecek apakah ada transaksi dalam ActiveUnfinishedTransaction. Jika ada transaksi, maka berarti ada transaksi yang belum selesai di-undo. Proses tracking dan undo dilanjutkan hingga mencapai record TRANSACTION START dari tiap transaksi tersebut. Untuk semua transaksi yang di-undo akan ditulis record ABORT TRANSACTION ke log file. Setelah proses undo selesai dikerjakan maka keseluruhan proses recovery pun selesai. 4.1.3
Kebutuhan Hardware dan Software Untuk menjalankan RDBMS yang dibuat dibutuhkan hardware dan software yang mendukung. Hardware yang dibutuhkan meliputi:
•
Processor minimal 600 MHz Pentium III-class processor.
•
Memory minimal 160 MB untuk sistem operasi Windows XP Profesional.
82
•
Harddisk 40 GB, yang meliputi 900 Mega untuk system drive, 3.3 GB untuk installation drive, 1.9 GB untuk dokumentasi MSDN Library, dan sisanya untuk penyimpanan data. Sedangkan untuk software dibedakan menjadi dua jenis yaitu software untuk produksi (production software) dan software untuk pengembangan (development software). Production software yang diperlukan adalah sistem operasi minimal Windows 98 dan .NET Framework. Development software yang diperlukan adalah Visual Basic .NET 2003.
4.2
Evaluasi 4.2.1
Validitas Data Untuk menguji validitas data dalam sistem recovery basis data, akan dilakukan pemeriksaan data dalam tiap proses yang terjadi yaitu pada proses logging, checkpoint, dan recovery. Pada proses logging, akan diperiksa apakah operasi yang dikirimkan sistem concurrency sudah dicatat dalam log file. Pada proses checkpoint, akan diperiksa apakah temporary database benar-benar telah di-flush. Sementara untuk proses recovery, akan diperiksa apakah transaksi
yang
telah
di-undo
akan
ditulis
record
ABORT
TRANSACTION pada log file setelah proses recovery selesai. Dan pada semua proses, akan diperiksa apakah data yang terdapat dalam basis data sudah benar.
83
4.2.1.1 Proses Logging Test Case: Terdapat dua pengguna yang mengerjakan dua transaksi terhadap basis data yang sama dengan memasukkan query-query berikut: Tabel 4.1 Contoh Transaksi Time t1
Transaksi 1
Transaksi 2
SELECT * FROM MsBarang
SELECT
*
FROM
MsKaryawan t2
BEGIN
t3
UPDATE
MsBarang
HargaSatuan=1000000
SET BEGIN WHERE
NamaBarang = 'Televisi';
t4
INSERT
INTO
(KodeBarang,
MsBarang NamaBarang,
TanggalBeli, Stok, Hargasatuan) VALUES
('BR006',
'Sepeda',
'12/11/2006', 5, 500000); t5
INSERT INTO MsKaryawan (KodeKaryawan, NamaKaryawan, VALUES ‘Manajer’);
('K006',
Jabatan) 'Andy',
84
Tabel 4.1 Contoh Transaksi Time t6
Transaksi 1 DELETE
FROM
Transaksi 2 MsBarang
WHERE KodeBarang='BR003';
t7
UPDATE
MsKaryawan
Jabatan=’Supervisor’
SET
WHERE
NamaKaryawan = 'Dina';
t8
COMMIT
t9 t10
ABORT SELECT * FROM MsBarang
SELECT * FROM MsKaryawan
System failure disimulasikan dengan mematikan komputer. Pada tahap tertentu saat mengerjakan transaksi, komputer akan direset. Kemudian pemeriksaan akan dilakukan dengan mengecek log file dan temporary database saat komputer kembali dinyalakan. Berikut ini informasi-informasi yang dikirimkan oleh sistem concurrency dalam tiap operasi.
85
Tabel 4.2 Informasi yang Dikirim Sistem Concurrency Time
Kode
Kode
Kode
Kode
Kode
Kode
Before
After
transaksi
database
tabel
field
record
record
Image
Image
lama
baru
850000.
1000000.
3
6 00
00
t1 t2
1
t3
1
2
1
5
2 t4
1
2
1
1
1
BR006
1
2
1
2
7
Sepeda
1
2
1
3
7
12/11/20 06 1
2
1
4
7
1
2
1
5
7
5 500000.0 0
t5
t6
2
2
5
1
4
K006
2
2
5
2
4
Andy
2
2
5
3
4
Manajer
1
2
1
1
3
BR003
1
2
1
2
3
Baterai
1
2
1
3
3
10/07/20 06
86
Tabel 4.2 Informasi yang Dikirim Sistem Concurrency Time
Kode
Kode
Kode
Kode
Kode
Kode
Before
After
transaksi
database
tabel
field
record
record
Image
Image
lama
baru
1
2
1
4
3
1
2
1
5
3
15 7500.0 0
t7
2
t8
1
t9
2
2
5
3
1
9
Staff
Supervisor
t10
Untuk menguji validitas data dalam proses logging, maka setiap kali sistem concurrency mengirimkan informasi operasi transaksi dan data yang relevan, akan dilakukan pemeriksaan terhadap hasil penulisan di log file. Tabel 4.3 Skenario Logging Pengujian
Skenario
Hasil
1
Hasil query sebelum kedua transaksi dimulai
Benar
2
Hasil penulisan di log file setelah time t2
Benar
3
Hasil penulisan di log file setelah time t3
Benar
87
Tabel 4.3 Skenario Logging Pengujian
Skenario
Hasil
4
Hasil penulisan di log file setelah time t4
Benar
5
Hasil penulisan di log file setelah time t5
Benar
6
Hasil penulisan di log file setelah time t6
Benar
7
Hasil penulisan di log file setelah time t7
Benar
8
Hasil penulisan di log file setelah time t8
Benar
9
Hasil penulisan di log file setelah time t9
Benar
10
Hasil query sesudah kedua transaksi dimulai
Benar
Hasil pengujian proses logging dapat dilihat di bagian lampiran L1. 4.2.1.2 Proses Checkpoint Test Case: Berdasarkan operasi transaksi pada Tabel 4.1, akan dilakukan pengujian terhadap proses checkpoint. Setiap kali checkpoint terjadi, yaitu bila record START CHECKPOINT tertulis ke log file, akan diperiksa apakah file TempDB kosong dan transaksi yang sedang aktif juga tercatat dalam record log file. Interval waktu checkpoint ditentukan 15 menit. Pengujian dilakukan sebanyak 4 kali.
88
Tabel 4.4 Skenario Checkpoint Pengujian
Skenario
Hasil
1
Checkpoint pertama terjadi setelah time t3
Benar
2
Checkpoint kedua terjadi setelah time t5
Benar
3
Checkpoint ketiga terjadi setelah time t8
Benar
4
Checkpoint keempat terjadi setelah time t9
Benar
Hasil pengujian proses checkpoint dapat dilihat di bagian lampiran L24. 4.2.1.3 Proses Recovery Test Case: Bila terjadi system failure, maka akan dilakukan proses recovery. Berdasarkan operasi transaksi pada Tabel 4.1, akan dilakukan pengujian terhadap validitas data setelah proses recovery terjadi. Di sini diasumsikan bahwa transaksi 2 tidak abort pada time t9, melainkan commit. Tabel 4.5 Skenario Recovery Pengujian 1
Skenario
Hasil
Bila system failure terjadi setelah time t6, Benar maka
proses
recovery
seharusnya
melakukan undo terhadap kedua transaksi. Hasil operasi SELECT terhadap kedua tabel seharusnya masih berupa data lama. Record ABORT TRANSACTION untuk kedua transaksi akan tertulis di log file.
89
Tabel 4.5 Skenario Recovery Pengujian 3
Skenario
Hasil
Bila system failure terjadi setelah time t9, Benar maka proses recovery akan melakukan proses redo terhadap kedua transaksi. Hasil operasi SELECT terhadap kedua tabel seharusnya berupa data yang telah dimodifikasi.
Tidak
terdapat
record
ABORT TRANSACTION dalam log file. Hasil pengujian proses recovery dapat dilihat di bagian lampiran L39. 4.2.2
Hasil Evaluasi Setelah melakukan pengujian terhadap proses-proses yang didukung oleh sistem recovery basis data, maka dapat dirangkum bahwa sistem mampu:
•
Melakukan proses logging.
•
Melakukan proses checkpoint.
•
Melakukan proses recovery.
