73 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
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.
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
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
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
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.
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 transaksi-transaksi yang aktif pada saat checkpoint dilakukan. Jika transaksi-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.
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,
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.
• 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.
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 Transaksi 1 Transaksi 2
t1 SELECT * FROM MsBarang SELECT * FROM
MsKaryawan t2 BEGIN
t3 UPDATE MsBarang SET HargaSatuan=1000000 WHERE NamaBarang = 'Televisi';
BEGIN
t4 INSERT INTO MsBarang (KodeBarang, NamaBarang, TanggalBeli, Stok, Hargasatuan) VALUES ('BR006', 'Sepeda', '12/11/2006', 5, 500000);
t5 INSERT INTO MsKaryawan
(KodeKaryawan,
NamaKaryawan, Jabatan) VALUES ('K006', 'Andy', ‘Manajer’);
Tabel 4.1 Contoh Transaksi
Time Transaksi 1 Transaksi 2
t6 DELETE FROM MsBarang
WHERE KodeBarang='BR003';
t7 UPDATE MsKaryawan SET
Jabatan=’Supervisor’ WHERE NamaKaryawan = 'Dina';
t8 COMMIT
t9 ABORT
t10 SELECT * FROM MsBarang SELECT * FROM MsKaryawan
System failure disimulasikan dengan mematikan komputer.
Pada tahap tertentu saat mengerjakan transaksi, komputer akan
di-reset. 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.
Tabel 4.2 Informasi yang Dikirim Sistem Concurrency Time Kode transaksi Kode database Kode tabel Kode field Kode record lama Kode record baru Before Image After Image t1 t2 1 t3 1 2 1 5 3 6 850000. 00 1000000. 00 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 5 1 2 1 5 7 500000.0 0 t5 2 2 5 1 4 K006 2 2 5 2 4 Andy 2 2 5 3 4 Manajer t6 1 2 1 1 3 BR003 1 2 1 2 3 Baterai 1 2 1 3 3 10/07/20 06
Tabel 4.2 Informasi yang Dikirim Sistem Concurrency Time Kode transaksi Kode database Kode tabel Kode field Kode record lama Kode record baru Before Image After Image 1 2 1 4 3 15 1 2 1 5 3 7500.0 0 t7 2 2 5 3 1 9 Staff Supervisor t8 1 t9 2 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
Tabel 4.3 Skenario Logging
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.
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
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 Skenario Hasil 1 Bila system failure terjadi setelah time t6,
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.
Tabel 4.5 Skenario Recovery
Pengujian Skenario Hasil 3 Bila system failure terjadi setelah time t9,
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.
Benar
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.
