DATABASE ADMINISTRATION Pertemuan ke-9

Database Backup dan Recovery source : Database Administration the complete guide to practices and procedures chapter 15 by. Craig S. Mullins

pengantar Reaksi terhadap failure dan disrupsi service adalah salah satu kunci utama dari tugas seorang DBA DBA harus siap terhadap situasi ketika efek dari kerusakan pada availaibilty, integrity dan usability terjadi pada database

Preaparing for Problems Gangguan Database yang membutuhkan recovery dapat dibedakan menjadi 3 kategori Instance failures : hasil dari internal exception pada DBMS, OS, atau software terkait DBMS. Pada beberapa kasus terjadi karena data korup, tapi tidak merusak data, DBMS hanya butuh direstart untuk mengembalikan fungsi normalnya

Application (or transaction) failures terjadi karena program atau script berjalan pada waktu yang salah, salah input, atau salah perintah. Biasanya menyebabkan kesalahan data, butuh database restore atau recovery. semakin cepat diatasi maka kesalahan akan semakin sedikit Media failure : menyebabkan data rusak. Termasuk dalam kategori ini adalah kerusakandisk storeage, kerusakan file system, tape yang rusak, atau file yang terdelete Kerusakan pada Media ini sudah dapat dihindari dengan menggunakan sistem disk modern RAID

KONDISI satu organisasi bisa menggunakan satu terabyte data atau lebih pada satu database server. Lebih banyak data yang perlu ditransaksikan dan ketersediaan data sangat tinggi dibutuhkan, proses yang cepat semakin dibutuhkan. Backup dan reovery plan dapat menjadi jaminan keamanan dan ketersediaan data bisnis perusahaan

Image Copy Backups Backup database meliputi pembuatan copy data yang konsisten. DBMS memiliki sarana backup dengan berbagai nama contoh : BACKUP, COPY, DUMP, and EXPORT Durasi recovery ditentukan oleh beberapa faktor berikut : Jumlah log record yang diproses recovery Apakah log tercompress atau compact Waktu yang dibutuhkan operator untuk mount dan dismount disc yang dibutuhkan Waktu yang dibutuhkan untuk mendapatkan log yang dibutuhkan Waktu yang dibutuhkan untuk reproses mengganti pages Arsitektur DBMS Umumnya, semakin sering perusahaan membuat sebuah image copy semakin minimal waktu yang dibutuhkan untuk recovery.

Beberapa panduan untuk membuat copy backup yang menjamin ketersediaan recoverable pada database kita Buat dua local copy untuk setiap image copy backup kita, untuk menghindari unrecoverable state pada kasus media error. Koordinasikan local backup stragegi dengan disaster backup recovery srategi, banyak utilitas yang dapat melakukan local dan offsite backup secara simultan Pastikan ada 2 generasi image copy backup untuk setiap database objek. Sehingga jika satu data salah, database bisa di fall back ke data yang lebih baru. Buat image copy backup ke disk dan migrasikan ke disk storage

Ketika image copy di migrasi ke disk storage, kompress file backup untuk mengurangi ukuran file backup Pastikan memasukkan sistem katalog database objek pada backup dan recovery plan. Sistem katalog harus dibackup minimal per pekan. Bahkan lebih untuk dinamic sistem Pastikan backup proses restartable, contoh jika proses backup gagal setelah 2 jam maka setelah restart akan butuh waktu 1 jam sampai selesai backup, jika backup unrestartable, makan proses akan diulang sejak awal Setelah backup komplit, gunakan fasilitas DBMS untuk memferifikasi validitas backup contoh the DB2 db2ckbkp operation or the Sybase BCP utility. Data yang tidak disimpan pada databaes, tapi digunakan oleh database aplikasi, harus dibackup pada waktu yang sama dengan database

- Full vs. Incremental Backups full image copy backup : sebuah copy yang komplit seluruh data pada database objek yang dibackup incremental image copy backup : backup yang mengandung hanya data yang berubah sejak last full atau incremental image copy dibuat Beberapa DBMS memiliki kemampuan untuk menganalisa apakah databse objek membutuhkan full atau incremental backup yang dibutuhkan Untuk database yang ‘small’selalu gunakan full image copy backup

Figure 15-1. Image copy backups

DBA harus memiliki pengetahunan tentang kemampuan backup dari setiap DBMS pada organisasi Beberapa DBMS dapat memiliki kemampuan untuk hot backup dan cold backup A cold backup : adalah backup yang harus diakhiri dengan shutting down database instance A hot backup adalah backup yang dapat dilakukan meski database sedang online

- Using Database Exports to Create Logical Backups Terkadang prosess backup hanya data tidak seluruh file fisik, ini disebut logical backup, beberapa hal yang dapat menjadi alasan logical backup daripada phisical backup Objek atau row recovery : semisal karena salah menghapus row data, maka phisical data akan berat dilakukan DBMS release upgrade : karena migrasi db ke DBMS versi baru tidak memerlukan perubahan fisik, dalam hal ini logical backup lebih dibutuhkan Heterogeneous database migration : karena struktur DB yang berbeda tiap DBMS, dalam kasus migrasi antar DBMS penggunaan logical backup lebih utam Data movement :contoh pada perusahaan yang memiliki mobilitas tinggi , sehingga pembukaan cabang banyak dan model DBMS yang digunakan juga bervariasi

Hal penting terkait backup Log Archiving and Backup Determining Backup Schedule DBMS Instance Backup Designing the DBMS Environment for Recovery Using Storage Management Software to Make Backup Copies Document Backup Strategy Database Object Definition Backups

Recovery General Steps for Database Object Recovery Identify the failure. The detection of an outage is usually simple: either the database is not responding to the application or the DBMS has displayed some type of error message. Some problems are more insidious, though, such as a corrupt control file. This type of problem take more skill to identify. Analyze the situation. The DBA must analyze the error to determine the cause, type, and scope of the failure. Based on the results of this analysis, the DBA will choose a recovery method. This is usually the most time consuming recovery task. Determine what needs to be recovered. The DBA must determine which database objects (and perhaps other components such as logs) are failing and prepare a recovery script that is appropriate for each component. This task can also consume a significant amount of time, especially for larger systems.

Identify dependencies between the database objects to be recovered Identify dependencies between the database objects to be recovered. The failure of one database object can impact other database objects (e.g., indexes and referentially related tables). Loss of data or recovery to a prior point in time will most likely affect related database objects. Locate the required image copy backup(s). The closer the image copy backup is to the recovery point in time, the shorter amount of time it will take to recover. Keep in mind other factors such as the time it takes to find tapes in the library and the possibility of the tape being located at an off-site location. Restore the image copy backup(s). Restoration is accomplished using the database recovery utility or file system recovery command of choice. Roll forward through the database log(s). To recover to current or to a point in time after the image copy backup was taken, the database logs will need to be processed.

Types of Recovery recover to current. point-in-time (PIT) recovery : untuk permasalahan aplikasi(partial recovery) Transaction recovery

Figure 15-3. Recover to current

Figure 15-4. Point-in-time recovery process.

Alternatives to Backup and Recovery Standby Databases Replication Disk Mirroring

Standby Database Diperkenalkan pertama kali oleh Oracle pada versi 7 A standby database adalah identical copy dari online produksi yang mendekati updtudate database utama standby database belum tentu uptodate 100%. Ketika kerusakan terjadi, control akan memindah proses ke standby database sehingga normal aktifitas akan kembali berjalan standby database dibuat dengan restoring a cold backup Kemudian seluruh achive log dari db produksi di copy dan dijalankan pada standby database standby database adalah yang paling mudah dan wajar diimplementasikan

Replication Beberapa DBMS memiliki fitur replikasi Ada dua teknologi dasar dari replikasi data pada database: Snapshot replication : menghasilkan copy database table pada target system berdasarkan query db sumber Symmetric replication : implementasi yang sempurna dari replikasi, karena akan menjaga database replikasi selalu uptodate

Disk Mirroring Mirroring disk devices dapat menambah ekstra level dari proteksi database Disk mirroring dapat dilakukan dengan cara mengalokasikan secondary device yang mengandung copy promary device storage disk Disk mirroring berbeda dengan replikasi, karena disk mirroring terjadi pada system mirroring, sedangkan replikasi pada database mirroring Disk mirroring dapat mengurangi recover akibat media failure

summary Sebuah rencana backup dan recovery yang matang untuk setiap database objek adalah bagian integral dari database implementasi Ini adalah tugas dari DBA untuk memastikan setiap kritikal data pada database terproteksi dan dapa direcover jika ada masalah muncul DBA harus dapat meminimalkan waktu downtime dengan menggunakan stategi backup dan recovery yang tepat Semakin lama database down, semakin banyak kerugian finansial yang dialami oleh perusahaan

Terima kasih