DBA BAB 4 - Recovery Data

Riza Muhammad Nurman Thursday, March 1, 2018
Click to edit Master title style
BAB 4
DBA
FACULTY
Riza Muhammad Nurman
DATABASE ADMINISTRATION
Recovery Data
Twitter : https://twitter.com/rhyzone
SlideShare : https://slideshare.net/rizaman

Click to edit Master title styleCONTENT
• Pengenalan Recovery
• Backup Database
• Restore Database
• Sistem Log
• Checkpoint
• Teknik-Teknik Recovery

Click to edit Master title stylePENGENALAN RECOVERY
• DATABASE RECOVERY
 mekanisme untuk memulihkan database dengan cepat dan akurat
setelah mengalami kerusakan
Hardware Failure
User Error
Application Failure
Software Failure
Terlalu Banyak Privilege
Bencana Alam

Hardware Failure
User Error
Application Failure
Software Failure
Bencana Alam
Kerusakan
perangkat keras
baik itu CPU,
memory, bus,
network card,
disk drives,
ataupun
controllers

Hardware Failure
User Error
Application Failure
Software Failure
Bencana Alam
Kerusakan
terjadi
kesalahan yang
dilakukan
pengguna
database

Hardware Failure
User Error
Application Failure
Software Failure
Bencana Alam
Setiap aplikasi
dimungkinkan
terdapat bug
yang bisa saja
memodifikasi
data yang tidak
diinginkan

Hardware Failure
User Error
Application Failure
Software Failure
Bencana Alam
Kerusakan Sistem
Operasi atau
driver perangkat,
dsb

Hardware Failure
User Error
Application Failure
Software Failure
Bencana Alam
SQL Server Login
yang memiliki
banyak Privilege
lebih dari yang
dibutuhkan

Hardware Failure
User Error
Application Failure
Software Failure
Bencana Alam
Sebuah bencana
yang tak terduga
dapat
menghancurkan
suatu daerah di
mana pusat data
dapat menjadi
tidak bisa
beroperasi atau
hancur

Click to edit Master title styleBACKUP DATABASE
Full Backup
• Sebuah backup yang lengkap termasuk file database dan lokasi, serta log
transaksi
1.Differential Backup
• Proses backup untuk merekam semua perubahan yang terjadi pada
database sejak full backup terakhir dilakukan
1.Transaction Log Backup
• Membackup file log dari database yang dimiliki
1.Tail-Log Backup
• Backup ini dilakukan sebelum operasi restore
1.File/Filegroup backup
• Digunakan untuk backup file database yang telah ditentukan dan
membolehkan backup file-file database secara spesifik daripada
keseluruhan database

Click to edit Master title styleRESTORE DATABASE
Jika telah dilakukan backup rutin dari database,
maka apabila terjadi kerusakan, data dapat
dikembalikan ke titik dimana data backup
terbaru berada

Click to edit Master title styleSISTEM LOG
• Fasilitas penjurnalan atau Log Shipping menjaga audit trail terhadap transaksi dan
perubahan database.
• Pada saat kegagalan pada sistem terjadi, keadaan database yang konsisten dapat
dikembalikan lagi dengan menggunakan informasi jurnal atau log dan data backup.
• Transaction log berisi:
– Identitas transaksi
– Data transaksi
– Tipe transaksi (misalnya: Insert)
– Waktu transaksi
– Identitas terminal atau pemakai
- Nilai data yang dimasukkan
- Tabel dan record yang diakses
- Record-record yang terubah
- Nilai lama dan nilai baru

Click to edit Master title styleSISTEM LOG - II
• Log shipping
 proses pemindahan/peng-copy-an transaction log files secara otomatis.
 Log Shipping memerlukan server primer dan server sekunder yang harus
ditetapkan.
• Keuntungan menggunakan Log Shipping :
– Log Shipping menyediakan kapabilitas untuk proses copy dan restore log files secara
otomatis berdasarkan durasi tertentu dan secara terus menerus.
– Dengan Log Shipping ini perbedaan data diantara server primer dan sekunder bisa
dikurangi.
• Log Shipping boleh dikatakan sebagai metode Recovery Plan yang terbaik,
karena resiko kehilangan data sangat sedikit dan sedikit pula waktu untuk
downtime.

Click to edit Master title styleLog Shipping Configuration
• Siapkan 2 server yang spesifikasinya hampir sama
dengan server primer termasuk softwarenya. 1 server
digunakan sebagai server sekunder dan 1 server lagi
digunakan sebagai server untuk monitoring Log
Shipping
• Pastikan account yang dipakai sebagai startup
SQL/SQLAgent Services di semua server adalah
merupakan account domain atau Built-in accoung
menggunakan Network Services.
• Siapkan satu folder pada server primer dan share folder
tersebut dengan memberikan full akses pada
account/user yang akan dipakai sebagai startup
SQL/SQLAgent Services.
• Boleh gunakan Group everyone, tetapi tidak di
rekomendasikan, karena secara default semua user
dalam domain termasuk kedalam group everyone.
• Pastikan metode recovery model pada database sudah
pada posisi Full/Bulk-Load.

Click to edit Master title styleLog Shipping Configuration - 2
• Klik kanan pada database yang akan dibuat Log Shipping-nya, kemudian pilih Task -
> Ship Transaction Log
• Klik “Enable this as a primary database in a log
shipping configuration”
• Klik tombol “Backup Setting” untuk membuat
konfigurasi dari backup yang akan dijalankan pada
server primer.
• Isi kolom “Network path to backup folder”
dengan nama sharing dari folder yang telah
dibuat.

• Kemudian klik tombol Add dalam
database properties untuk membuat
konfigurasi dari server tujuan (server
sekunder).
– Secondary Server Instance : Isi dengan
meng-klik tombol connect untuk
memilih server tujuan (server sekunder).
– Secondary Database : Diisi dengan nama
database yang dipakai sebagai tempat
untuk me-restore database primer yang
ada pada datasase sekunder (server
sekunder).
– Klik Connect untuk mendapatkan server

• Pada Tab Initialize
Secondary Database, klik
“Yes, generate a full
backup …” apabila akan
membuat full backup
terlebih dahulu sebelum
Log Shipping ini dijalankan
dan klik tombol restore
option, apabila akan
menempatkan file
database di directory yang
lain pada server sekunder

• Pada Tab Copy Files, isi
destination folder dengan
nama folder pada server
sekunder yang dipakai sebagai
tempat menyimpan file
transaction log yang di
generate oleh SQL.
– Delete copied files after : Diisi
dengan lamanya waktu yang
diperboleh untuk menghapus
file-file log yang sudah lama.
– Job name : Diisi dengan nama
Job.
Bisa diisikan juga IP Address komputer
sekunder, seperti 192.168.1.10foldershare

• Pada Tab Restore Transaction Log, pilih option Standby Mode.
– Delay restoring backup at least: Diisi dengan waktu yang diperbolehkan untuk SQL
agar menunda proses restore.
– Alert if no restore occurs: Diisi dengan lamanya waktu yang diperbolehkan SQL untuk
menunda proses backup, sebelum timbul notifikasi.
• Klik tombol schedule apabila ingin
merubah schedule dari job yang dibuat.

• Klik option Use a Monitor server Instance dalam
database properties. Klik tombol Setting untuk
menambahkan server yang berfungsi untuk
memonitor jalannya Log Shipping ini.
• Klik tombol connect untuk menambahkan nama
server yang berfungsi memonitor jalannya Log
Shipping.
• Klik option “By impersonating the proxy account”
sebagai cara untuk konek ke server tersebut.
– Delete history after : Diisi dengan lamanya waktu yang
diperbolehkan SQL sebelum history dari job ini di hapus.
– Job Name : Diisi dengan nama Job.
• Setelah semua step tersebut diatur, klik tombol OK.
SQL akan memberikan status dari Log Shipping
Configuration yang dibuat tadi.

• Proses akhir Transaction Log Shipping
 pada server sekunder akan
terbentuk satu database dengan status
standby/read only.

Click to edit Master title styleCHECKPOINT
• Fasilitas checkpoint bekerja untuk membantu aplikasi atau sistem untuk
dapat menyimpan eksekutif state dan mentolerir kesalahan dengan
membolehkan kesalahan tersebut memulihkan keadaan ke keadaan aman
sebelumnya.

Click to edit Master title styleMEKANISME CHECKPOINT
• Mekanisme Checkpoint melakukan
duplikasi state dari Proses A kedalam
sebuah media penyimpanan Non-
Volatile.
• Terjadi kesalahan sistem.
• Mengembalikan hasil checkpoint state
terakhir yang telah diduplikasi dari
Proses A, kedalam memory dan
kembali terproses.

Click to edit Master title styleTEKNIK-TEKNIK RECOVERY
1. Jika database rusak secara fisik
– Seperti : disk head crash Restore Backup Database yang terakhir dan mengaplikasikan kembali
operasi-operasi update transaksi yang telah commit dengan menggunakan log file.
– Dengan asusmsi bahwa log filenya tidak rusak.
2. Jika database tidak rusak secara fisik tetapi menjadi tidak konsisten,
– Sebagai contoh karena adanya kesalahan (system crash, system error, local error,
concurrency control), solusinya adalah membatalkan perubahan-perubahan yang
menyebabkan database tidak konsisten
– Disini tidak perlu menggunakan salinan backup database, tetapi dapat me-restore database ke
dalam keadaan yang konsisten dengan menggunakan before- dan after-image yang ditangani oleh
log file.
• Before-image: salinan sebuah record sebelum dimodifikasi.
• After-image: salinan sebuah record sesudah dimodifikasi.

Click to edit Master title styleTEKNIK-TEKNIK RECOVERY - 2
• Teknik recover berikut ini dilakukan terhadap situasi dimana database tidak rusak tetapi database dalam
keadaan yang tidak konsisten :
1. Differed Update / perubahan yang ditunda
– Perubahan pada DB tidak akan berlangsung sampai transaksi ada pada poin disetujui (COMMIT)
– Jika terjadi kegagalan maka tidak akan terjadi perubahan, tetapi diperlukan operasi redo untuk mencegah akibat dari
kegagalan tersebut.
2. Immediate Update / perubahan langsung
– Perubahan pada DB akan segera tanpa harus menunggu sebuah transaksi tersebut disetujui.
– Jika terjadi kegagalan diperlukan operasi UNDO untuk melihat apakah ada transaksi yang telah disetujui sebelum terjadi
kegagalan.
3. Shadow Paging
– Menggunakan page bayangan dimana pada prosesnya terdiri dari 2 tabel yang sama, yang satu menjadi tabel transaksi
dan yang lain digunakan sebagai cadangan.
– Ketika transaksi mulai berlangsung kedua tabel ini sama dan selama berlangsung tabel transaksi yang menyimpan
semua perubahan ke database, tabel bayangan akan digunakan jika terjadi kesalahan.
– Keuntungannya adalah tidak membutuhkan REDO atau UNDO, kelemahannya membuat terjadinya fragmentasi.

Click to edit Master title style

DBA BAB 4 - Recovery Data

More Related Content

What's hot

More from Riza Nurman

Recently uploaded

DBA BAB 4 - Recovery Data