BAB 3 ANALISIS DAN PERANCANGAN SISTEM

BAB 3 ANALISIS DAN PERANCANGAN SISTEM

3.1

Analisis Sistem 3.1.1

Gambaran Permasalahan Sistem recovery basis data adalah komponen dalam RDBMS yang digunakan untuk mengembalikan basis data ke kondisi yang benar (consistent state) jika terjadi system failure. System failure adalah masalah atau gangguan yang menyebabkan transaksi terputus sebelum selesai. Ini biasanya berupa terputusnya arus listrik atau error pada software yang digunakan. Dalam prosesnya, sistem recovery basis data melibatkan beberapa komponen fisik yang utama, yaitu log file, database buffer, serta basis data itu sendiri. Dari segi teknik, proses recovery terbagi menjadi tiga, yakni teknik deferred update dengan algoritma NO-UNDO/REDO, immediate update dengan algoritma UNDO/NO-REDO, dan immediate update dengan algoritma UNDO/REDO.

3.1.2 Analisis Kebutuhan 3.1.2.1 Kebutuhan Fungsional Berbagai fungsi yang didukung oleh sistem recovery basis data meliputi: •

Sistem dapat membaca file dalam bentuk XML.

•

Sistem dapat melakukan logging (pencatatan informasi transaksi ke log file). 38

39 •

Sistem dapat menjalankan proses insert, update, dan delete.

•

Sistem dapat menerapkan checkpoint.

•

Sistem dapat melakukan penampungan data yang akan dieksekusi di dalam temporary database.

•

Sistem dapat melakukan penulisan dari temporary database ke basis data setiap kali checkpoint.

•

Sistem dapat melakukan proses redo.

•

Sistem dapat melakukan proses undo.

3.1.2.2 Kebutuhan Non-Fungsional Beberapa kebutuhan non-fungsional dari sistem recovery basis data meliputi: •

Sistem dapat berjalan dengan sistem operasi Windows.

•

Data sistem akan disimpan dalam bentuk XML.

3.1.2.3 Batasan Sistem Beberapa batasan dalam sistem recovery basis data ini meliputi: •

Sistem tidak mencakup fitur backup dan restore.

•

Sistem tidak melakukan penulisan ke basis data, penulisan ke basis data dilakukan oleh sistem storage management, sistem hanya mengirimkan data untuk dituliskan ke dalam basis data.

•

Sistem tidak berfokus pada buffer management yang mengatur pengerjaan operasi di temporary database.

40 •

Secara keseluruhan, RDBMS hanya mendukung transaksi yang menggunakan satu basis data.

3.1.3

Log File Log file adalah komponen yang penting dalam basis data. Bila terjadi system failure, log file diperlukan untuk mengembalikan basis data ke consistent state. Isi log file akan ditulis berdasarkan prinsip WAL (write-ahead log) untuk menjamin semua operasi dicatat dalam log terlebih dahulu sebelum dieksekusi. Struktur log file menyerupai relasi yang terdapat dalam konsep basis data relasional. Dengan kata lain, log file merupakan tabel yang terdiri dari sejumlah field (kolom) dan sejumlah record (baris). Field-field dalam log file terdiri dari:

•

LSN (Log Sequence Number), yang berfungsi sebagai tanda pengenal (identifier) tiap log record.

•

TransactionID, yang berfungsi sebagai identifier suatu transaksi. Suatu transaksi terdiri atas satu atau beberapa operasi yang terhubung melalui satu TransactionID yang sama.

•

Time, yang berfungsi sebagai keterangan waktu tiap kali suatu operasi dicatat ke dalam log.

•

Operation, yang menyatakan jenis operasi dari transaksi yang bisa berupa: start, commit, abort, insert, update, atau delete dan record checkpoint berupa permulaan checkpoint <START CKPT (T1,…,Tk)> dan akhir checkpoint <END CKPT>.

41 •

Database, yang menyatakan nama basis data yang akan dimodifikasi.

•

Table, yang menyatakan nama tabel yang akan dimodifikasi.

•

Field, yang menyatakan field apa saja yang akan dimodifikasi dari tabel yang bersangkutan.

•

OldRecordID, yang berisi kode record lama sebelum dimodifikasi. Kode record diperoleh dari sistem storage management yang berperan dalam menyimpan basis data secara fisikal.

•

NewRecordID, yang berisi kode record baru setelah dimodifikasi.

•

BeforeImage, nilai field sebelum operasi dijalankan.

•

AfterImage, nilai field setelah operasi dijalankan.

•

pPtr, pointer yang menunjuk ke log record yang berisi operasi sebelumnya dari transaksi yang sama.

•

nPtr, pointer yang menunjuk ke log record yang berisi operasi berikutnya dari transaksi yang sama. Log file tersusun atas jalinan log record. Setiap log record diidentifikasi oleh satu LSN. Log record yang baru ditulis pada akhir log file dengan LSN yang lebih besar daripada LSN log record sebelumnya. Log record dicatat secara berurutan. Tiap log record mengandung TransactionID dari transaksi yang dikerjakan. Semua log record yang berhubungan dengan suatu transaksi akan dihubungkan dengan pointer untuk mempercepat rollback / undo transaksi. Untuk melakukan recovery terhadap operasi maka akan digunakan before image atau after image:

42 1)

Untuk menjalankan operasi kembali (redo), maka after image akan digunakan.

2)

Untuk mengembalikan operasi (undo), maka before image akan digunakan. Ada beberapa tipe operasi yang dicatat dalam log. Operasi-operasi tersebut meliputi:

1)

Awal dan akhir transaksi (START dan COMMIT atau ABORT)

2)

Modifikasi data (INSERT, UPDATE dan DELETE)

3)

Checkpoint (<START CKPT (T1,…,Tk)> dan <END CKPT>) Jadi dapat disimpulkan bahwa dalam log file tercatat semua operasi dan transaksi yang merubah isi basis data. Catatan tersebut sangat diperlukan untuk mengembalikan basis data ke consistent state bila terjadi system failure melalui proses recovery basis data. Tanpa log file, tidak akan ada catatan mengenai operasi yang merubah isi basis data sehingga bila terjadi system failure, basis data tidak dapat dikembalikan ke consistent state. Proses recovery basis data tidak dapat dilakukan tanpa log file. Dalam penelitian ini, log file akan dibuat untuk tujuan tersebut, yaitu memungkinkan proses recovery basis data berdasarkan catatan tentang operasi-operasi yang telah dijalankan terhadap basis data.

3.1.4

Temporary Database sebagai Database Buffer Database buffer berfungsi untuk meningkatkan kinerja sistem dengan mempercepat proses query. Secara teoritis, database buffer dibuat di main memory (RAM) yang notabene bersifat volatile (data di

43 dalamnya akan hilang jika terjadi system failure), namun sangat baik dalam kecepatan transfer data. Fungsi database buffer di sini direpresentasikan dengan temporary database yang akan disimpan di dalam disk. Temporary database disimpan di dalam disk karena adanya perbandingan terbalik antara kecepatan dan kapasitas. Main memory cepat, namun sangat terbatas dalam hal kapasitas. Sebaliknya disk lebih lambat, namun jauh lebih memadai dalam hal kapasitas. Proses eksekusi operasi membutuhkan kapasitas besar. Oleh karena itu, digunakanlah temporary database yang disimpan di dalam disk untuk mendukung kebutuhan kapasitas yang besar tersebut. Dalam penelitian ini, penggunaan temporary database lebih difokuskan untuk mendukung proses checkpoint, yang menjamin semua operasi yang sudah dikerjakan di temporary database ditulis ke dalam basis data fisikal. 3.1.5

Teknik Deferred Update Teknik

deferred

update

menggunakan

algoritma

NO-

UNDO/REDO. Mekanismenya adalah sebagai berikut: 1)

Ketika transaksi dimulai, sebuah record START dituliskan ke log file.

2)

Setiap operasi transaksi diterima, log record berisi data-data yang relevan akan ditambahkan ke dalam log file.

3)

Temporary database akan meng-copy blok basis data yang mengandung data yang diperlukan bila blok tersebut belum ada.

4)

Jalankan opersasi transaksi terhadap blok basis data dalam temporary database.

44 5)

Ketika transaksi commit, tulis COMMIT TRANSACTION ke log file.

6)

Salin kembali blok basis data yang telah termodifikasi dari temporary database ke basis data. Berikut ini adalah contoh mekanisme deferred update:

1. START 2. INSERT A 3. UPDATE B 4. DELETE A 5. COMMIT Untuk langkah 1, proses yang terjadi adalah: Tulis TRANSACTION START pada log

Log

TempDB

Database

Gambar 3.1 Proses Deferred Update 1 Pada langkah 2, proses yang terjadi adalah: Masukkan log record operasi insert ke dalam log

Bila belum ada di TempDB, salin struktur tabel yang diperlukan ke dalam TempDB

Cek eksistensi tabel di TempDB Log

TempDB

Kerjakan operasi dalam TempDB

Gambar 3.2 Proses Deferred Update 2

Database

45 Pada langkah 3, proses yang terjadi adalah: Masukkan log record operasi update ke dalam log

Bila belum ada di TempDB, salin struktur tabel yang diperlukan ke dalam TempDB

Cek eksistensi tabel di TempDB Log

TempDB

Database

Kerjakan operasi dalam TempDB

Gambar 3.3 Proses Deferred Update 3 Pada langkah 4, proses yang terjadi adalah: Masukkan log record operasi delete ke dalam log

Bila belum ada di TempDB, salin struktur tabel yang diperlukan ke dalam TempDB

Cek eksistensi tabel di TempDB Log

TempDB

Database

Kerjakan operasi dalam TempDB

Gambar 3.4 Proses Deferred Update 4 Pada langkah 5, proses yang terjadi adalah: Tullis Transaction Commit pada log

Salin hasil operasi-operasi yang telah dikerjakan ke dalam Database dan flush TempDB

Log

TempDB

Gambar 3.5 Proses Deferred Update 5

Database

46 3.1.5.1 Kelebihan deferred update Teknik deferred update lebih aman karena operasi tidak langsung mengubah basis data sebelum transaksi di-commit, sehingga bila terjadi system failure atau transaksi abort, basis data tetap dalam consistent state. 3.1.5.2 Kekurangan deferred udpate Teknik deferred update menuntut kapasitas temporary database yang lebih besar karena harus menyimpan semua blok basis data yang dimodifikasi dalam temporary database hingga commit. Untuk operasi select, teknik deferred update harus melakukan penggabungan (union) data antara basis data fisikal dan temporary database untuk mendapatkan data yang reliable. 3.1.6

Immediate Update dengan Algoritma UNDO/NO-REDO Langkah-langkah teknik

immediate update dengan algoritma

UNDO/NO-REDO adalah: 1)

Ketika transaksi mulai, tulis sebuah record START ke log file.

2)

Setiap operasi transaksi diterima, log record berisi data-data yang relevan akan ditambahkan ke dalam log file.

3)

Temporary database akan meng-copy blok basis data yang mengandung data yang diperlukan bila blok tersebut belum ada.

4)

Jalankan operasi transaksi terhadap blok basis data dalam temporary database.

5)

Langsung salin kembali blok basis data yang telah termodifikasi dari temporary database ke basis data.

47 6)

Ketika transaksi commit, semua modifikasi terhadap basis data diselesaikan sebelum COMMIT TRANSACTION ditambahkan ke log file. Berikut ini adalah contoh mekanisme immediate update dengan algoritma UNDO/NO-REDO:

1. START 2. INSERT A 3. UPDATE B 4. DELETE A 5. COMMIT Untuk langkah 1, proses yang terjadi adalah: Tulis TRANSACTION START pada log

Log

TempDB

Database

Gambar 3.6 Proses Immediate Update UNDO/NO-REDO 1 Pada langkah 2, proses yang terjadi adalah: Masukkan log record operasi insert ke dalam log

Bila belum ada di TempDB, salin struktur tabel yang diperlukan ke dalam TempDB

Cek eksistensi tabel di TempDB Log

TempDB

Database

Kerjakan operasi dalam TempDB dan salin hasil operasi ke dalam Database

Gambar 3.7 Proses Immediate Update UNDO/NO-REDO 2

48 Pada langkah 3, proses yang terjadi adalah: Masukkan log record operasi update ke dalam log

Bila belum ada di TempDB, salin struktur tabel yang diperlukan ke dalam TempDB

Cek eksistensi tabel di TempDB Log

TempDB

Database

Kerjakan operasi dalam TempDB dan salin hasil operasi ke dalam Database

Gambar 3.8 Proses Immediate Update UNDO/NO-REDO 3 Pada langkah 4, proses yang terjadi adalah: Masukkan log record operasi delete ke dalam log

Bila belum ada di TempDB, salin struktur tabel yang diperlukan ke dalam TempDB

Cek eksistensi tabel di TempDB Log

TempDB

Database

Kerjakan operasi dalam TempDB dan salin hasil operasi ke dalam Database

Gambar 3.9 Proses Immediate Update UNDO/NO-REDO 4 Pada langkah 5, proses yang terjadi adalah: Tullis Transaction Commit pada log

Log

TempDB

Database

Gambar 3.10 Proses Immediate Update UNDO/NO-REDO 5

49 3.1.6.1 Kelebihan immediate update dengan algoritma UNDO/NOREDO Efek dari operasi langsung tercatat pada basis data. 3.1.6.2 Kekurangan immediate update dengan algoritma UNDO/NOREDO Penggunaan teknik immediate update dengan algoritma UNDO/NO-REDO dapat mengundang masalah yang potensial. Ini terjadi karena transaksi tidak dapat mencapai commit tanpa menyelesaikan semua perubahan yang dilakukannya terhadap basis data terlebih dahulu. Bila seorang pengguna telah mengcommit suatu transaksi tapi ternyata terjadi kegagalan saat pemrosesan, maka seluruh transaksi dianggap gagal karena record commit belum tercatat di log. Pengguna akan mengira basis data sudah berhasil diubah, padahal kenyataannya transaksi yang baru saja dilakukan gagal. Selain itu perpindahan blok basis data dari dan ke temporary database akan lebih dinamis (cepat berubah). Akibatnya penggunaan disk I/O akan lebih boros. Hal ini akan menurunkan kinerja sistem. 3.1.6.3 Kekurangan deferred update dan immediate update dengan algoritma UNDO/NO-REDO Baik teknik deferred update maupun immediate update dengan algoritma UNDO/NO-REDO dapat mengalami kontradiksi dalam penggunaan page dalam temporary database yang

50 digunakan untuk menampung blok basis data yang akan dimodifikasi. Jika blok basis data dalam page tersebut dimodifikasi oleh suatu transaksi yang sudah commit, sedangkan blok tersebut juga dimodifikasi oleh transaksi lain yang belum commit, maka akan terjadi kontradiksi untuk menyalin blok tersebut ke basis data atau tidak. 3.1.7

Teknik Immediate Update dengan algoritma UNDO/REDO Solusi yang dapat dipakai untuk mengatasi kekurangankekurangan ini adalah teknik immediate update UNDO/REDO. Teknik ini merupakan gabungan dari kedua teknik di atas. Teknik ini sangat fleksibel dalam menentukan kapan setiap operasi transaksi dapat dijalankan. Fleksibilitas ini dapat digunakan untuk mengatasi kekurangan dan menggabungkan kelebihan dari teknik deferred update dan immediate update dengan algoritma UNDO/NO-REDO. Kelebihankelebihan teknik immediate update UNDO/REDO antara lain:

1)

Tidak perlu menunggu transaksi commit untuk menulis ke basis data (mengatasi kekurangan dari teknik deferred update).

2)

Tidak perlu menunggu semua operasi selesai dijalankan untuk mengcommit suatu transaksi (mengatasi kekurangan dari teknik immediate update dengan algoritma UNDO/NO-REDO). Kekurangan teknik immediate update UNDO/REDO adalah kinerja saat recovery yang lebih lambat karena harus melakukan redo dan undo sekaligus.

51 3.1.8

Checkpoint Teknik checkpoint digunakan agar pada saat melakukan recovery, keseluruhan log file tidak perlu ditelusuri kembali. Ada dua teknik checkpoint yang dapat digunakan, yaitu checkpoint quiescent dan checkpoint nonquiescent. Setiap checkpoint terjadi pada interval waktu tertentu. Pada

saat

checkpoint,

teknik

checkpoint

quiescent

akan

menghentikan penerimaan transaksi baru sebagai langkah inisialisasi. Kemudian menunggu sampai semua transaksi yang sedang aktif pada saat checkpoint mencapai commit atau abort. Setelah itu log record akan ditambahkan ke dalam log file, dan penerimaan transaksi baru dapat dilanjutkan. Teknik checkpoint quiescent sangat sederhana, namun tidak efektif dari segi kinerja. Karena harus menunggu sampai semua transaksi yang sedang aktif pada saat checkpoint mencapai commit atau abort, sistem akan menjadi lebih lambat. Untuk mengatasi kelemahan ini, dapat digunakan teknik checkpoint nonquiescent. 3.1.9

Checkpoint pada Undo/Redo Logging Nonquiescent checkpoint dapat digunakan pada teknik undo/redo logging dengan langkah-langkah sebagai berikut:

1)

Tuliskan record <START CKPT (T1,…,Tk)> pada log file, dimana T1,…,Tk adalah semua transaksi yang sedang aktif pada saat checkpoint.

52 2)

Salin semua blok basis data yang sudah dimodifikasi (dirty) oleh operasi transaksi sebelum terjadi checkpoint dari temporary database ke basis data. Tidak seperti redo logging, semua blok yang sudah dimodifikasi harus di-flush, tidak hanya blok yang dimodifikasi oleh transaksitransaksi yang sudah commit.

3)

Tuliskan record <END CKPT> pada log file.

3.1.10 Recovery dengan Undo/Redo Logging dan Checkpoint Teknik undo/redo logging menggunakan log record yang berisi old value maupun new value. Jika terjadi system failure, langkah-langkah recovery yang akan dikerjakan adalah dengan mengerjakan redo pada semua transaksi yang telah commit secara berurutan mulai dari log record <START CKPT (T1,…,Tk)> dan mengerjakan undo pada semua transaksi yang belum commit secara berurutan dari log record akhir sampai awal dari transaksi yang sedang di-undo. Alasan memulai redo dari record <START CKPT (T1,…,Tk)> adalah karena semua blok basis data yang sudah dimodifikasi sudah diflush ke basis data pada saat checkpoint dimulai, tanpa terkecuali. Contoh kasus: <START T1> <START T2> <START CKPT(T2)>

53 <START T3> <END CKPT> Gambar di atas adalah contoh log record yang berurutan dari atas ke bawah. Record <START T1> menunjukkan dimulainya transaksi T1. Record berarti operasi transaksi T1 yang memodifikasi blok basis data A yang memiliki nilai before image 4 menjadi nilai after image 5. Sedangkan <START CKPT (T2)> menunjukkan dimulainya checkpoint dengan transaksi T2 sebagai transaksi yang sedang aktif. <END CKPT> menunjukkan akhir dari proses checkpoint, yang berarti semua blok basis data yang telah termodifikasi saat dimulainya checkpoint telah di-flush ke basis data. menunjukkan transaksi T1 telah mencapai commit. Jika terjadi system failure setelah penulisan log record terakhir, maka akan dilakukan penelusuran dari log record terakhir sambil mengidentifikasi transaksi yang tidak memiliki record sampai pada log record <START CKPT (T1,…,TK)>. Dengan demikian, kita dapat menentukan bahwa transaksi yang belum commit adalah T3. Setelah sampai pada record <START CKPT (T2)>, kita mengetahui bahwa T2 adalah transaksi yang belum selesai. Penelusuran akan dihentikan sementara di sini karena semua blok basis data yang sudah dimodifikasi oleh transaksi sebelum checkpoint tersebut telah di-flush ke

54 basis data. Penelusuran akan dimulai kembali dari record <START CKPT (T2)>, namun dengan arah yang berbalik, menuju kembali ke log record terakhir. Redo akan mulai dilakukan di sini. Dari penelusuran ini dapat diketahui bahwa record akan di-redo. Artinya karena tidak dapat diketahui bahwa blok basis data C yang telah diubah nilainya telah di-flush ke basis data atau belum, maka operasi ini harus di-redo. Record yang ditemukan selanjutnya tidak di-redo karena sebelumnya kita telah mengetahui bahwa T3 belum mencapai commit. Setelah penelusuran mencapai log record terakhir, maka akan diteruskan dengan penelusuran untuk melakukan undo dari bawah ke atas. Dari penelusuran ini operasi untuk record akan di-undo karena belum commit. Penelusuran akan dilanjutkan sampai menemukan record <START T3>, karena semua operasi dari transaksi T3 harus di-undo. Jika telah mencapai <START CKPT (T2)> dan semua operasi dari transaksi (dalam hal ini, T3) yang belum di-commit telah di-undo, maka penelusuran berakhir. Dalam teknik recovery menggunakan teknik immediate update dengan algoritma UNDO/REDO, sering kali terjadi ambigu apakah redo atau undo yang harus dilakukan terlebih dahulu. Masalah yang dikhawatirkan akan terjadi adalah bila suatu transaksi di-undo atau diredo, basis data menjadi tidak konsisten. Misalnya: Transaksi T yang sudah commit di-redo harus membaca nilai X yang ditulis oleh transaksi U yang belum commit dan harus di-undo.

55 Masalahnya bukan apakah harus dilakukan redo dulu dan membiarkan X berisi nilai sebelum transaksi U dikerjakan, atau melakukan undo dulu dan membiarkan X berisi nilai yang ditulis oleh transaksi T. Situasi tersebut tidak akan terjadi dengan adanya mekanisme concurrency. Mekanisme concurrency menjamin nilai yang sedang ditulis oleh suatu transaksi tidak akan terbaca oleh transaksi lain. Jadi tidak masalah baik redo maupun undo yang dilakukan terlebih dahulu. Dalam penelitian ini, proses redo dilakukan terlebih dahulu kemudian baru undo sama seperti mekanisme dalam SQL Server 2005. 3.1.11 Perbandingan Teknik-Teknik Recovery Basis Data Tabel 3.1 Perbandingan teknik-teknik Recovery Aspek-aspek yang

Deferred Update

Immediate Update

Immediate

Diperhatikan

dengan algoritma

dengan algoritma

Update dengan

NO-UNDO/REDO

UNDO/NO-REDO

algoritma UNDO/REDO

Kapasitas temporary

Besar

Kecil

Kecil

Tidak

Ya

Ya

database yang diperlukan Menggunakan algoritma Undo

56 Tabel 3.1 Perbandingan teknik-teknik Recovery Aspek-aspek yang

Deferred Update

Immediate Update

Immediate

Diperhatikan

dengan algoritma

dengan algoritma

Update dengan

NO-UNDO/REDO

UNDO/NO-REDO

algoritma UNDO/REDO

Proses modifikasi

Lebih lambat karena

Lebih cepat karena

Lebih cepat

data

tidak langsung

langsung

karena langsung

memodifikasi basis

memodifikasi basis

memodifikasi

data (harus

data setelah tiap

basis data setelah

menunggu commit).

operasi dijalankan.

tiap operasi dijalankan.

Recovery

Lebih

cepat Lebih

cepat Lebih

dibandingkan teknik dibandingkan immediate dengan

update teknik

karena

immediate menggunakan dua

algoritma update

UNDO/REDO.

dengan algoritma

algoritma

sekaligus.

UNDO/REDO. Logging

Sama

Sama

lambat

Sama

57 Tabel 3.1 Perbandingan teknik-teknik Recovery Aspek-aspek yang

Deferred Update

Immediate Update

Immediate

Diperhatikan

dengan algoritma

dengan algoritma

Update dengan

NO-UNDO/REDO

UNDO/NO-REDO

algoritma UNDO/REDO

Fleksibilitas

Kurang fleksibel,

Kurang fleksibel,

Lebih fleksibel

karena modifikasi

karena transaksi

daripada kedua

terhadap basis data

hanya boleh

teknik lainnya,

hanya bisa dilakukan commit setelah

karena modifikasi

setelah transaksi di-

semua operasi

terhadap basis

commit

selesai dijalankan

data boleh dilakukan sebelum transaksi dicommit dan transaksi boleh commit sebelum semua operasi selesai dijalankan

Berdasarkan gambaran di atas maka teknik recovery yang dipilih dalam penelitian ini adalah teknik immediate update dengan algoritma UNDO/REDO. Meskipun teknik ini lebih rumit daripada kedua teknik lainnya, teknik ini lebih fleksibel, lebih cepat untuk proses logging, dan dapat diandalkan untuk proses recovery.

58

3.2

Perancangan Sistem 3.2.1 Use Case Diagram Spesifikasi tugas-tugas yang dapat dilakukan aplikasi akan direpresentasikan dengan diagram use case berikut:

Gambar 3.11 Use Case Diagram Secara sekilas dapat dilihat di sini bahwa sistem recovery basis data berhubungan dengan tiga aktor, yaitu concurrency manager, recovery manager, dan waktu. Concurrency manager berperan dalam

59 inisialisasi sistem dengan mengirimkan transaksi. Recovery manager berperan bila terjadi system failure dengan melakukan recovery dengan algoritma undo dan redo. Masing-masing use case dalam sistem memiliki flow of event (alur kejadian) yang dideskripsikan sebagai berikut:

Tabel 3.2 Use Case Specification untuk Terima Transaksi Nama use case

Terima Transaksi

Pra-kondisi

-

Pasca-kondisi

Logging

Langkah-

1. Concurrency Manager mengirimkan query transaksi dalam format

langkah dasar

XML ke dalam sistem. 2. Sistem menerima query yang berisi informasi tentang basis data, tabel, field, dan record yang terlibat, serta operasi yang dijalankan dalam transaksi tersebut.

Tabel 3.3 Use Case Specification untuk Logging Nama use case

Logging

Pra-kondisi

Query transaksi diterima

Pasca-kondisi

Detail operasi transaksi dicatat dalam log file

60 Tabel 3.3 Use Case Specification untuk Logging Langkahlangkah dasar

1. Jika transaksi baru dimulai, sistem menambah record ke dalam log file, berupa informasi dimulainya transaksi yang diterima oleh sistem, yang meliputi ID transaksi, waktu masuknya transaksi, pPtr (nilai pointer yang menunjuk ke log record yang berisi operasi sebelumnya; dalam hal ini berisi nilai 0 karena belum ada operasi yang sudah dikerjakan), nPtr (nilai pointer yang menunjuk ke log record yang berisi operasi sesudahnya dari transaksi tersebut). Field operasi diisi dengan “transaction start”. 2. Sistem menambah record ke dalam log file, berupa informasi dari query transaksi, yang meliputi ID transaksi, waktu masuknya operasi, operasi yang dilakukan, before image (nilai record sebelum operasi delete atau update), after image (nilai record setelah operasi update atau insert), predicate dari query, pPtr (nilai pointer yang menunjuk ke log record yang berisi operasi sebelumnya dari transaksi yang sama), serta basis data, tabel, dan field yang terlibat dalam operasi. Untuk operasi delete dan update, karena nilai before image harus didapatkan dari basis data, maka sebelum diisi, langkah selanjutnya akan dikerjakan terlebih dulu. Field nPtr akan diisi jika operasi selanjutnya untuk ID transaksi yang sama telah diterima. 3. Sistem menjalankan operasi terhadap tabel di dalam temporary database.

61 Tabel 3.3 Use Case Specification untuk Logging Langkah-

4. Sistem menambah record ke dalam log file, berupa informasi

langkah dasar

berakhirnya transaksi, yang meliputi ID transaksi, waktu masuknya transaksi, pPtr (nilai pointer yang menunjuk ke log record yang berisi operasi sebelumnya), nPtr (nilai pointer yang menunjuk ke log record yang berisi operasi sesudahnya dari transaksi tersebut; dalam hal ini berisi nilai 0 karena sudah tidak ada operasi yang akan dikerjakan). Field operasi diisi dengan “transaction commit”.

Langkah-

Langkah 5: Jika transaksi abort, maka dilakukan undo terhadap

langkah

transaksi tersebut.

alternatif Tabel 3.4 Use Case Specification untuk Checkpoint Nama use case Checkpoint Pra-kondisi

-

Pasca-kondisi

Memicu penulisan basis data

Langkah-

1. Waktu dengan interval tertentu memicu terjadinya checkpoint.

langkah dasar

2. Sistem menulis sebuah checkpoint start record <START CKPT (T1,…,Tk)> ke log file. Record ini berisikan ID dari semua transaksi yang aktif pada waktu checkpoint. 3. Sistem mem-flush (menghapus) semua dirty page (blok basis data yang sudah dimodifikasi). 4. Sistem menulis sebuah checkpoint end record <END CKPT> ke log file.

62 Tabel 3.5 Use Case Specification untuk Tulis ke Basis Data Nama use case

Tulis ke basis data

Pra-kondisi

Checkpoint dan Logging

Pasca-kondisi

Basis data berubah

Langkah-

1. Checkpoint dan Logging memicu terjadinya overwrite isi

langkah dasar

temporary database ke basis data. 2. Sistem melakukan overwrite isi temporary database yang sudah dimodifikasi ke basis data.

Tabel 3.6 Use Case Specification untuk Recovery Nama use case

Recovery

Pra-kondisi

Terjadi system failure

Pasca-kondisi

Basis data kembali ke consistent state

Langkah-

1. Recovery Manager memicu terjadinya recovery.

langkah dasar

2. Sistem mencari record checkpoint terakhir. 3. Sistem melakukan redo terhadap transaksi yang memiliki log record berupa transaction start dan transaction commit mulai dari record <START CKPT (T1,…,Tk)>. 4. Sistem melakukan undo terhadap transaksi yang memiliki log record berupa transaction start tapi tidak memiliki transaction commit mulai dari record terakhir yang tercatat dalam log file.

63 Tabel 3.7 Use Case Specification untuk Redo Nama use case

Redo

Pra-kondisi

Recovery

Pasca-kondisi

Basis data kembali ke consistent state

Langkah-

1. Sistem

langkah dasar

mengidentifikasi

transaksi

yang

memiliki

record

“transaction commit” sesudah waktu checkpoint. 2. Sistem mengidentifikasi ID transaksi tersebut. 3. Sistem melacak kembali urutan transaksi dengan menggunakan pPtr dan nPtr. 4. Sistem menjalankan kembali transaksi tersebut mulai dari record <START CKPT (T1,…,Tk)>.

Tabel 3.8 Use Case Specification untuk Undo Nama use case

Undo

Pra-kondisi

Recovery

Pasca-kondisi

Basis data kembali ke consistent state

Langkah-

1. Sistem mengidentifikasi transaksi yang tidak memiliki record

langkah dasar

transaction commit. 2. Sistem mengidentifikasi ID transaksi tersebut. 3. Sistem melacak kembali urutan transaksi dengan menggunakan pPtr dan nPtr. 4. Sistem mengembalikan nilai pada transaksi tersebut yang telah diubah sebelumnya sesuai dengan nilai before image.

64 3.2.2

Class Diagram

Gambar 3.12 Class Diagram Sistem Recovery Basis Data 3.2.3

Rancangan Data Semua data dalam sistem akan disimpan dalam bentuk XML. Data dari proses-proses yang didukung sistem recovery basis data berupa log file dan data dalam temporary database. Setiap basis data memiliki master file dan log file. Log file berisi jalinan log record. Data yang disimpan dalam log file meliputi LSN (Log Sequence Number), KodeTransaksi, Operasi, KodeDatabase, KodeTabel, KodeField,

KodeRecordLama,

KodeRecordBaru,

BeforeImage,

65 AfterImage, WaktuDatang, nPtr, dan pPtr. KodeDatabase, KodeTabel, KodeField, KodeRecordLama, dan KodeRecordBaru merupakan kode spesifik untuk menunjuk ke record tertentu yang akan dimodifikasi dalam basis data fisikal. Kode-kode tersebut dibuat oleh sistem storage management. Berikut ini contoh data yang disimpan dalam log file: 1 1 START TRANSACTION <WaktuDatang>January 20 2007 6:25:20.484 2 2 1 UPDATE 2 1 5 3 6 850000.00 1000000.00 <WaktuDatang>January 20 2007 6:25:41.359 1

66

Data yang terdapat di dalam temporary database bersifat sementara. Setiap operasi akan dikerjakan dalam temporary database, dan bila temporary database sudah penuh, maka data dari operasi lama akan digantikan data dari operasi baru. Setiap kali terjadi checkpoint, semua data yang sudah dimodifikasi dalam temporary database akan disalin ke dalam basis data dan kemudian dihapus. Data operasi yang disimpan dalam temporary database berupa TDSN (Temporary Database Sequence Number) yang berfungsi sebagai identifier dari tiap record, KodeDatabase, KodeTabel, KodeField, KodeRecord, dan Value (nilai). Selain itu, juga terdapat flag “IsDelete”, yang bila bernilai TRUE maka record tersebut harus dihapus dari basis data. Sedangkan bila flag “IsDelete” bernilai FALSE, maka record akan ditambahkan ke dalam basis data. Flag tersebut berfungsi sebagai pembeda apakah suatu operasi merupakan operasi insert, update yang memerlukan record baru dalam basis data atau operasi delete yang menghapus record yang sudah ada dalam basis data. Berikut ini contoh data yang disimpan dalam temporary database: 1 2 1 5



6

67 1000000.00
3.2.4

Rancangan Proses Flowchart akan digunakan untuk menjelaskan tiap-tiap langkah yang terjadi dalam berbagai proses yang didukung sistem recovery basis data. Proses-proses utama dalam sistem ini meliputi proses logging, checkpoint, dan recovery. Proses logging terjadi setiap kali ada operasi baru yang harus dijalankan. Proses ini akan mencatat operasi ke dalam log file.

68

Gambar 3.13 Flowchart Logging Proses checkpoint dipicu oleh waktu, proses ini akan menghapus data yang sudah dimodifikasi dalam temporary database, menjamin data tersebut sudah masuk ke dalam basis data. Dalam penelitian ini, interval waktu untuk proses checkpoint ditetapkan setiap 15 menit. Interval waktu

69 tersebut ditentukan dengan dasar supaya proses recovery hanya perlu melakukan pemeriksaan terhadap operasi-operasi yang tercatat dalam waktu 15 menit terakhir, sehingga proses recovery tidak akan memakan waktu lama. Start

Tulis record "checkpoint start" dan transaksi sedang berjalan ke log file

Force write isi Temporary Database yang sudah dimodifikasi ke Database

Flush isi Temporary Database yang sudah dimodifikasi

Tulis record "checkpoint end" ke log file

Finish

Gambar 3.14 Flowchart Checkpoint Proses recovery akan dilakukan pada saat sistem dimulai atau bila terjadi system failure. Proses ini menjamin basis data tetap berada dalam consistent state setelah terjadi system failure.

70

Start

Hapus isi Temporary Database

Lakukan backtracking mulai dari transaksi terakhir dalam log file hingga record "checkpoint start"

Lakukan redo terhadap semua transaksi yang memiliki record "transaction commit" mulai dari record "checkpoint start" hingga akhir log file secara berurutan

Lakukan undo terhadap semua transaksi yang tidak memiliki record "transaction commit" mulai dari akhir log file

Finish

Gambar 3.15 Flowchart Recovery Selain proses-proses di atas, sistem recovery basis data juga mendukung proses truncate log, yaitu proses menghapus transaksitransaksi yang sudah tidak aktif lagi di dalam log file. Transaksi-transaksi yang tidak aktif adalah transaksi yang sudah selesai dan hasilnya sudah tercatat dalam basis data. Catatan mengenai transaksi-transaksi tersebut dalam log file tidak diperlukan lagi untuk proses recovery. Oleh karena itu, catatan tersebut dapat dibuang. Transaksi aktif adalah transaksi yang

71 belum selesai atau belum mencapai commit dan hasilnya mungkin belum tercatat dalam basis data. Proses truncate tidak boleh menghapus catatan mengenai transaksi yang masih aktif dalam log file, karena catatan tersebut masih diperlukan untuk proses recovery. Proses truncate log hanya terjadi bila diminta oleh pengguna. Dalam kasus-kasus tertentu, log file sebuah basis data sama sekali tidak dihapus untuk keperluan backup dan restore. Tetapi dengan demikian, ukuran log file akan sangat besar bahkan bisa melebihi ukuran basis data. Bila pengguna ingin membuang bagian log file yang tidak aktif lagi, fitur truncate log dapat digunakan.

3.2.5

Rancangan Interface dan Input/Output (I/O) Sistem recovery basis data berinteraksi langsung dengan dua sistem lain dalam DBMS yang dibuat dalam penelitian ini, yaitu sistem concurrency dan sistem storage management. Sistem concurrency melakukan penjadwalan operasi transaksi mana yang dilakukan terlebih dahulu. Interface antara sistem recovery basis data dengan sistem concurrency berupa class Transaksi. Bila ada operasi transaksi baru yang harus dikerjakan, sistem concurrency akan memanggil

method

addInsertOperation()

untuk

operasi

insert,

addUpdateOperation() untuk operasi update, addDeleteOperation() untuk operasi delete, dan mengirimkan data operasi ke sistem recovery basis data. Bila suatu transaksi sudah selesai dikerjakan, dalam arti suatu transaksi sudah di-commit dan seluruh operasi dalam suatu transaksi

72 sudah dikerjakan ke dalam basis data, maka sistem recovery basis data akan melakukan konfirmasi kepada sistem concurrency. Sistem lain yang berinteraksi dengan sistem recovery basis data adalah sistem storage management yang mengatur isi basis data dan melakukan perubahan atau penulisan ke basis data. Interface dengan sistem storage management dilakukan melalui pemanggilan method writeToDB() milik sistem storage management. Method writeToDB() berfungsi untuk menuliskan data yang dikirimkan oleh sistem recovery basis data ke dalam basis data. Bila penulisan terhadap basis data telah selesai dilakukan, maka sistem storage management akan mengirimkan sinyal sebagai konfirmasi. Selain itu, sistem recovery basis data juga berinteraksi dengan sistem storage management pada saat proses recovery berlangsung, yaitu saat sistem dimulai baik karena terjadi system failure ataupun baru dinyalakan setelah di-shut down. Dalam proses recovery, method yang menghubungkan sistem recovery basis data dengan sistem storage management adalah method getDBList() untuk memperoleh semua nama basis data yang tersimpan. Kemudian proses recovery akan dilakukan berdasarkan log file dari masing-masing basis data.