BASIS DATA RELASIONAL

BACK UP DAN
RECOVERY

Amalia Nurani Basyarah

Ilmu Komputer, 2018
 Latar Belakang
Sistem komputer berpotensi mengalami kerusakan/kegagalan
operasi. Beberapa sebab kegagalan operasi, adalah:

Aliran Listrik Putus, yang dapat mengakibatkan hilangnya

informasi yang ada di memori utama dan register
 Kesalahan operasi (human error), dimana operator
melakukan kesalahan operasi yang tidak disengaja.
 Kesalahan perangkat lunak, yang dapat mengakibatkan
hasil pengolahan (akhir/antara) tidak benar, informasi yang
disajikan ke user salah, atau basis data menjadi tidak konsisten.
 Disk rusak, yang dapat mengakibatkan hilangnya informasi
atau rusaknya basis data yang ada di dalam disk.
SBD harus menyiapkan/menerapkan sejumlah aksi untuk
menjamin agar data dan sistem dapat terpelihara
dengan baik.
 Jenis Kerusakan dalam SBD
1. Kegagalan Transaksi (Transaction Failure)
Beberapa kesalahan yang dapat menyebabkab sebuah
transaksi menjadi gagal:
a. Kesalahan Logika (Logical Error)
Program/sistem tidak dapat menjalankan eksekusi
normalnya karena adanya kondisi internal tertentu seperti
masukan data yang salah, data tidak tersedia, nilai data di
luar batas domain yang diperbolehkan (overflow), logika
yang tidak tepat (bugs) atau batas sumber daya sistem
(seperti memori) habis.
b. Kesalahan Sistem (System Error)
Program/sistem telah memasuki kondisi yang tidak
diharapkan (seperti deadlock), sebagai hasil dari tidak
tereksekusinya program/sistem secara normal.
Deadlock  Kondisi dimana 2 proses atau lebih saling
menunggu proses yg lain untuk menggunakan resource ttn.
 Jenis Kerusakan dalam SBD
2. Kerusakan Sistem (System Crash)
Hardware macet (hang), menyebabkan isi media
penyimpanan sementara (volatile storage) hilang.
3. Kegagalan/kerusakan Disk (Disk Failure)
Adanya/terjadinya bad sector atau disk macet
pada saat berlangsungnya operasi I/O ke disk.
 Transaksi
 Transaksi merupakan unit logika dari proses
database yang mencakup satu atau lebih operasi
pengaksesan database – meliputi insert, delete,
modifikasi atau operasi retrieve.
Secara sederhana, transaksi dapat diartikan
sebagai sekelompok tugas/operasi berurutan
yang harus dikerjakan oleh database.
 Operasi database ini dapat disisipkan dalam
suatu program aplikasi atau dapat langsung
dibuat interaktif dengan bahasa query level tinggi
misal SQL.
 Transaksi
 Sebuah transaksi akan mengelompokkan
beberapa operasi, sehingga kumpulan operasi
tersebut dapat dilaksanakan secara keseluruhan
(commit) atau dibatalkan secara keseluruhan (roll
back).
 Properti dari Transaksi
Transaksi memiliki 4 properti yang disingkat menjadi ACID,
yaitu:

1) Atomicity  Sebuah transaksi dianggap sebagai satu

kesatuan tunggal. Sehingga pada prosesnya, semua
operasi dalam transaksi harus dikerjakan secara utuh atau
kesemuanya tidak dikerjakan sama sekali.

2) Consistency  Database tetap harus konsisten meski telah

melakukan satu transaksi. Kesalahan pada suatu proses
tidak boleh mengubah konsistensi data pada database.
 Properti dari Transaksi
Transaksi memiliki 4 properti yang disingkat menjadi ACID,
yaitu:

3) Isolation  Efek dari suatu transaksi (misal A) tidak akan

terlihat oleh transaksi lain sampai transaski (A) tersebut selesai.
Contoh: Jika suatu user mengupdate data hr.employee, user
tsb tidak dapat melihat perubahan yang belum
selesai/sedang berlangsung (uncomitted) pada table
employee yang sedang bersamaan dilakukan oleh user lain.

4) Durability  Perubahan yang dibuat oleh suatu transaksi

memiliki sifat permanen. Ketika suatu transaksi telah commit,
maka database harus memastikan bahwa pada saat recovery
terjadi, perubahan hasil transaksi tersebut tidak akan hilang.
 Transaksi
Suatu cara untuk menspesifikasikan batasan transaksi
adalah dengan membuat statemen begin transaction
dan end transaction dalam program aplikasi;
Pada kasus ini semua operasi yang mengakses
database di antara statemen begin-end dianggap
sebagai sebuah transaksi

Begin transaction

Operation A
Sebuah Transaksi
Operation B

End transaction
 Transaksi
Sebuah program aplikasi dapat berisi lebih dari
satu transaksi.
Jika operasi database dalam suatu transaksi
tidak meng-update database tetapi hanya
mengambil (retrieve) data, transaksinya disebut
dengan read-only transaction.
 Status Transaksi dan Operasi
Tambahan
Suatu transaksi adalah unit terkecil dari kerja yang
dapat diselesaikan atau tidak dapat diselesaikan.
Beberapa operasinya dengan diagram transisinya :

 BEGIN_TRANSACTION : memulai transaksi

 READ or WRITE : operasi baca atau tulis dari item
database yang dieksekusi sebagai bagian dari
transaksi
 END_TRANSACTION : operasi transaksi READ atau
WRITE selesai dilakukan
 Status Transaksi dan Operasi
Tambahan
 COMMIT_TRANSACTION : transaksi berakhir sukses
sehingga semua perubahan (update) yang dilakukan
melalui transaksi dapat dimasukkan ke database dan
akan diselesaikan
 ROLLBACK (or ABORT) : transaksi berakhir dengan
tidak sukses sehingga semua perubahan atau efek
transaksi yang diaplikasikan ke database tidak dapat
diselesaikan.
Status Transaksi dan Operasi
Tambahan
 Contoh Transaksi

Misalkan sebuah transaksi pada database bank.

 Operasi Pencegahan/Penanganan
Kerusakan SBD
Ada dua jenis operasi terhadap basis data
dengan yang saling bergantung satu sama
lain, yaitu:
a. Recovery
b. Backup
 Konsep Recovery

 Recovery basis data merupakan suatu proses

penyimpanan kembali basis data pada keadaan yang
benar sebelum terjadi kegagalan(failure).

 Recovery dari suatu kegagalan transaksi biasanya

berarti database direstore ke status yang konsisten
(waktu sebelum terjadi kegagalan).
 Konsep Recovery

Untuk mengcover kesalahan atau kegagalan dari

transaksi, sistem memaintain sebuah LOG untuk
menjaga jalannya semua operasi yang mempengaruhi
nilai dari item database. Informasi ini mungkin akan
dibutuhkan untuk mengcover adanya kegagalan.

LOG disimpan di storage, dan secara berkala

diback-up ke storage lainnya untuk menjaga dari
kerusakan yang fatal.
 Fasilitas Recovery pada DBMS
 Mekanisme backup
Melakukan backup secara periodik terhadap basis
data yg ada
 Fasilitas Logging
Mencatat transaksi-transaksi dan perubahan-
perubahan yang terjadi terhadap basis data. DBMS
memelihara file khusus yang disebut Log (Journal)
yang menyediakan informasi mengenai seluruh
perubahan yang terjadi pada basis data.
 Fasilitas Checkpoint
Mengizinkan update terhadap basis data yang
akan menjadi basis data yang permanen
 Manager recovery
Mengizinkan sistem untuk menyimpan kembali basis
data ke keadaan sebelum terjadi kegagalan
 Teknik Recovery

Prosedur recovery yang digunakan tergantung dari

kegagalan yang terjadi pada basis data. Terdapat 2
kasus kerusakkan :
1. Jika basis data rusak secara fisik seperti : disk head
crash dan menghancurkan basis data, maka
yang terpenting adalah melakukan
penyimpanan kembali backup basis data yang
terakhir dan mengaplikasikan kembali operasi-
operasi update transaksi yang telah commit
dengan menggunakan log file. Dengan asumsi
bahwa log file-nya tidak rusak.
 Teknik Recovery

2. Jika basis data tidak rusak secara fisik tetapi

menjadi tidak konsisten, sebagai contoh : sistem
crash sementara transaksi dieksekusi, maka yang
perlu dilakukan adalah membatalkan
perubahan-perubahan yang menyebabkan basis
data tidak konsisten. Mengulang beberapa
transaksi sangat diperlukan juga untuk meyakinkan
bahwa perubahan2 yang dilakukan telah
disimpan di dalam secondary storage.

Di sini tidak perlu menggunakan salinan backup basis

data, tetapi dapat me-restore basis data ke dalam
keadaan yang konsisten dengan menggunakan before
dan after-image yang ditangani oleh log file.
 Skema Mekanisme Recovery
Asumsi: Disk yang dialokasikan untuk BD tidak
mengalami kerusakan, maka ada 3 pilihan skema
untuk menjalankan recovery begitu kerusakan atau
kegagalan terjadi, yaitu:
1. File Log dengan penundaan Pengubahan
(Incremental Log with Deffered Updates)

2. File Log dengan Pengubahan langsung

(Incremental Log with Immediate Updates)

3. Page Bayangan (Shadow Paging)

 File Log dengan Penundaan
Pengubahan (Deferred Update)
• Menunda update yang sesungguhnya ke basis
data sampai transaksi menyelesaikan
eksekusinya dengan sukses dan mencapai titik
commit.
• Selama eksekusi masih berlangsung update
hanya dicatat pada system log dan transaction
workspace.
• Setelah transaksi commit dan log sudah dituliskan
ke disk, maka update dituliskan ke basis data.
 File Log dengan Penundaan
Pengubahan
• Ide dari protocol update yang tertunda :
1. Sebuah transaksi tidak dapat merubah database
pada disk hingga mencapai titik point
2. Sebuah transaksi tidak dapat mencapai titik point
hingga semua operasi update disimpan dalam log
dan ditulis ke disk
 File Log dengan Penundaan
Pengubahan
• Karena database tidak pernah ter-update
pada disk hingga transaksi mencapai commit,
operasi UNDO tidak diperlukan.
• Operasi ini dikenal dengan algoritma recovery
NO UNDO/ REDO.
• REDO dibutuhkan saat sistem gagal setelah
transaksi mencapai commit tetapi sebelum
perubahan disimpan pada database di disk.
 Recovery Deferred Update pada
Single-user
• Mulai dari entry terakhir pada log, baca mundur
sampai ke awal dari log
• Buat list dari transaksi yang sudah commit dan
yang belum commit
• Lakukan operasi REDO dari semua operasi
write_item dari transaksi yg sudah commit, dengan
urutan seperti tertulis pada log
• Abaikan semua operasi dari transaksi yang belum
commit  implicit rollback
• Transaksi yg belum commit akan diresubmit
kembali ke sistem
 File Log dengan Pengubahan
Langsung
• Update dilakukan langsung pada basis data
tanpa menunggu transaksi mencapai titik
commit
• Operasi tetap harus dituliskan ke log (pada disk)
sebelum update dilakukan pada basis data 
Write-Ahead Logging protocol
 File Log dengan Pengubahan
Langsung untuk Single User
• Buat list semua transaksi yang sudah commit
dan list transaksi yang belum commit
• UNDO semua operasi write_item dari transaksi
yang belum commit
• REDO semua operasi write_item dari transaksi
yang sudah commit sesuai dengan urutan
yang tertulis pada log
• Dapat ditambahkan checkpoint
 Recovery dengan Shadow Paging

• Basis data terdiri dari sejumlah fixed-size disk

• Buat page table di memory dengan jumlah
entry yang sama dengan jumlah disk page
• Shadow page table adalah copy dari
current page table yang disimpan di disk
• Selama transaksi berlangsung current page
table diupdate, sedangkan shadow page
table tidak dimodifikasi
 Recovery dengan Shadow Paging

• Bila operasi write_item dilaksanakan, maka copy

dari basis data yang akan dimodifikasi dibuat
• Current page table dimodifikasi untuk menunjuk
pada disk page yang baru, sedangkan shadow
page lama tetap menunjuk pada disk blok yang
lama
• Bila proses commit sukses, maka shadow page
table akan dihapus
• Bila proses commit gagal, maka status basis data
sebelum transaksi bisa diperoleh dari shadow page
table
 Recovery dengan Shadow Paging
• AFIM tidak menimpa BFIMnya tetapi disimpan
pada tempat lain di disk. Sehingga, setiap saat
sebuah item data memiliki AFIM dan BFIM
(Shadow copy dari item data) pada dua
tempat yang berbeda di disk.

X Y
X' Y'

Database

X dan Y: Shadow copies dari item data

X` dan Y`: Current copies dari item data
 Recovery dengan Shadow Paging
Untuk mengatur akses item data dengan konkuren dua
direktori transaksi (current dan shadow) yang digunakan.
Susunan direktori digambarkan di bawah ini. Halaman
berikut merupakan item data.

Current Directory Shadow Directory

(after updating pages 2, 5) (not updated)
Page 5 (old)
1 Page 1 1
2 Page 4 2
3 Page 2 (old) 3
4 Page 3 4
5 Page 6 5
6 Page 2 (new) 6
Page 5 (new)
 Operasi Backup

Berdasarkan waktu pelaksanaan atau strateginya,

ada dua jenis operasi backup, yaitu:
1) Backup Statis
Backup dilakukan dengan lebih dulu menonaktifkan
basis data secara keseluruhan.

2) Backup Dinamis
Backup dilakukan tanpa penonaktifan basis data
(Sehingga user tetap bisa bekerja)
 Backup Statis
Backup statis dilakukan dengan melakukan
penyalinan objek basis data secara keseluruhan,
sehingga hasil operasi backup ini akan sama
dengan basis data yang ada.
Backup statis dapat dilakukan melalui program
utilitas yang disediakan sistem operasi (OS) atau
dengan menjalankan program utilitas modul) khusus
yang disediakan DBMS.
Operasi back up statis hanya bisa dilakukan
selama basis data tidak aktif (offline backup).
 Backup Dinamis
Backup dinamis dilakukan selama basis data
masih aktif (online backup).
Operasi ini hanya akan dilakukan secara hati-hati,
karena dapat mengganggu jalannya operasi-
operasi utama terhadap basis data.
Kehati-hatian itu dapat diterapkan dalam dua
bentuk, yaitu pemilihan waktu backup dan
penentuan objek-objek yang dikenai operasi
backup.
Terima
Kasih