STRUKTUR RECOVERY DBMS ORACLE

Struktur Database Oracle
Secara garis besar, database oracle memiliki tiga buah struktur utama yaitu memory structure, process structure, dan strorage structure. Oracle Instance menggunakan memory dan process structure untuk dapat berjalan sedangkan oracle database menggunakan storage structure untuk dapat menyimpan data file maupun control file di dalam database tersebut. Tentu ketiga struktur utama ini sangat penting karena tanpa adanya salah satu komponen saja, maka oracle instance tidak dapat mengakses oracle database atau sebaliknya oracle database tidak dapat diakses oleh oracle instance.
Oracle Database dibangun menggunakan tiga struktur komponen, yaitu :
•         Struktur Memori
•         Struktur Porses
•         Struktur File(storage/penyimpanan)
• Memory Stucture
Di dalam memory structure terdapat dua buah komponen yaitu :
A. System Global Area (SGA)
SGA merupakan shared memory yang dapat digunakan oleh seluruh server process dan background process. Di dalamnya tersimpan informasi-informasi yang berupa data file dan control file dari instance.
Di dalam SGA terdapat struktur data sebagai berikut :
-          Database Buffer Cache : berisi cache blok data yang berisi hasil pengembalian dari proses query database.
-          Redo log buffer : menyimpan redo information yang digunakan untuk instance recovery. Informasi tersebut akan disimpan hingga ditulis ke dalam physical redo log file di dalam storage disk.
-          Shared Pool : menyimpan berbagai macam konstruksi / informasi yang dapat dishare di antara user database.
-          Large Pool : merupakan area optional yang dibutuhkan jika ada proses-proses yang memakan memory cukup besar seperti backup and recovery dan proses server I/O.
-          Java Pool : digunakan oleh java code atau data yang menggunakan Java Virtual Machine (JVM).
-          Stream Pool : Digunakan oleh Oracle Stream untuk proses streaming.

            B. Process Global Area (PGA)
Berbeda dengan SGA, PGA lebih spesifik hanya digunakan secara khusus oleh masing-masing server dan background process. Minimal ada satu PGA yang dimiliki oleh tiap server process. Setiap PGA menyimpan data dan control information dari masing-masing proses yang menyediakan layanan dari tiap request oracle client.
-          stack-space: memori yang melakukan variabel session, arrays, dsb.
-          session-information: instance menyimpan informasi session di PGA. (Kecuali multithreaded server, informasi session disimpan di SGA.)
-          private SQL-area: area PGA yang menyimpan informasi seperti bind-variables dan runtime-buffers.
-          sorting area: area PGA yang menyimpan informasi mengenai sort, hash-joins, dsb.
• Struktur Penyimpanan (Storage Structures)
Terdapat 2 tipe struktur penyimpanan pada oracle database, yaitu :
- Logical Storage
- Physical Storage
a. Logical Structure
Struktur Logical Storage ini memungkinkan Oracle Database untuk memiliki kontrolfine-grained terhadap penggunaan disk space. Struktur Logical Storage dapat dilihat pada gambar di bawah ini.
Logical Storage terbagi menjadi beberapa bagian, yaitu tablespace, segment, extent dandata
block.
-          Data Blocks
Pada tingkat terbaik dari granularity, data dari Oracle Database disimpan dalam data blocks. Satu data blocks berukuran sesuai dengan database fisik yang terdapat padaharddisk. Standar ukuran data block ditentukan oleh parameter inisialisasi DB_BLOCK_SIZE. Selain itu Anda dapat menentukan hingga empat ukuran blocklainnya. Database menggunakan dan mengalokasikan ruang bebas database di data blocks milik Oracle Database.
-          Extent
Tingkat berikutnya dari logical database space adalah extent. Extent adalah sejumlah tertentu dari data block yang berhubungan, diperoleh alokasi tunggal, yang digunakan untuk menyimpan jenis informasi khusus
-          Segment
Di atas extent, level selanjutnya dari logical database storage adalah segment. Segmentadalah gabungan dari extent yang dialokasikan untuk tabel, index, rollback segment, atau untuk
sementara digunakan oleh session, transaction, atau SQL parser. Dalam kaitannya dengan physical structure, semua extent milik salah satu segment berada di tablespaceyang sama, tetapi mungkin berada dalam file data yang berbeda. Ketika extent dari sebuah segment terisi penuh, Oracle Database secara dinamis mengalokasikan extent lain untuk segment tersebut. Karena extent dialokasikan sesuai kebutuhan, extent dari sebuahsegment mungkin berhubungan atau tidak dalam harddisk.
-          Tablespace
Sebuah database dibagi menjadi unit penyimpanan logis yang disebut tablespace, merupakan gabungan dari data block, extent, dan segment yang berhubungan. Misalnya,tablespace umumnya dikelompokkan bersama semua objek aplikasi untuk menyederhanakn beberapa operasi administrasi. Setiap database secara logis dibagi menjadi dua(2) atau lebih
tablespace. Satu atau banyak datafile secara eksplisit dibuat untuk setiap tablespace untuk menyimpan data dari semua logical structure dalam tablespace secara fisik. Gabungan ukuran dari datafile di tablespace adalah kapasitas penyimpanan total daritablespace tersebut. Setiap database Oracle berisi tablespace SYSTEM dan tablespaceSYSAUX. Oracle Database membuat dua(2) tablespace tersebut secara otomatis ketika database dibuat. Standar sistem di Oracle adalah untuk menciptakan sebuah tablespaceyang bersifat smallfile, yang merupakan tipe tradisional dari Oracle tablespace.Tablespace SYSTEM dan SYSAUX dibuat sebagai tablespace yang bersifat smallfile.
b. Physical Structure
Bagian berikut ini menjelaskan Physical Database Structure dari Oracle Database, termasuk di dalamnya terdapat datafile, control file, redo log file, archived redo log file, parameter file, alert dan trace log file, dan backup file.

Berikut ini pembahasan tentang bagian-bagian dari Physical Database Structure:
-          Datafile
Setiap Oracle Database memiliki satu atau lebih datafile fisik, yang berisi semua data database. Data dari Logical Database Structure, seperti tabel dan index, secara fisik tersimpan dalam datafile yang dialokasikan untuk database.
Datafile memiliki karakteristik sebagai berikut:
-          Satu atau lebih datafile membentuk logical unit dari database
-          yang disebut tablespace.
-          Datafile hanya dapat dengan satu tablespace saja.
-          Datafile dapat didefinisikan untuk memperluas secara otomatis ketika datafile tersebut sudah penuh.
-          Control File
Setiap Oracle database memiliki control file. Sebuah control file berisi tentang informasi struktur fisik dari database, termasuk informasi berikut:
-          Nama database
-          Nama dan lokasi dari datafile dan redo log file
-          Catatan waktu dari pembuatan database
Oracle database dapat memperbanyak control file, yaitu, secara bersamaan membuat beberapa salinan control file yang sama persis, ini dilakukan untuk melindungi database dari kegagalan
sistem yang melibatkan control file.
-  Online Redo Log File
Setiap database Oracle memiliki dua atau lebih online redo log file. Online Redo Log File, bersama dengan archived redo log file, secara kolektif dikenal sebagai redo log untuk database. Sebuah redo log terdiri dari beberapa masukkan(juga disebut redo record),
yang merekam semua perubahan yang terjadi pada data. Jika kegagalan mencegah data yang telah dimodifikasi ditulis secara permanen ke dalam datafile, maka perubahan dapat dimasukkan ke dalam redo log, sehingga pekerjaan tidak pernah hilang. Untuk melindungi terhadap kegagalan yang melibatkan redo log itu sendiri, database Oracle memungkinkan Anda memperbanyak redo log sehingga dua atau lebih salinan dari redo log dapat ditempatkan
pada disk yang berbeda.
-          Archived Redo Log File
Archived Redo Log File adalah file yang dihasilkan dari salinan offline redo log file. Database Oracle secara otomatis mengarsip redo log file ketika database dalam mode ARCHIVELOG. Oracle merekomendasikan agar Anda mengaktifkan pengarsipan otomatis untuk Redo Log File.
-          Parameter File
Parameter file berisi daftar parameter konfigurasi untuk instance dan database. Kedua parameter file(pfile) dan server parameter file(spfile) memungkinkan Anda menyimpan dan mengelola
parameter inisialisasi Anda terus-menerus dalam file server-side disk. Sebuah server parameter file memiliki keuntungan tambahan,
yaitu:
_ File ini diperbarui secara bersamaan ketika beberapa nilai parameter dirubah ketika instance aktif
_ File ini dapat diakses secara terpusat oleh semua instance di dalam Real Application Service Database.
-          Alert and Trace Log File
Setiap proses server dan proses background dapat menuliskan ke dalam trace file yang berhubungan. Ketika kegagalan internal terdeteksi oleh proses, informasi dump process tentang kegagalan tersebut akan masuk ke dalam trace file. Beberapa informasi yang dimasukkan ke dalam trace file ditujukan untuk database administrator, sedangkan informasi yang lain digunakan untuk Oracle Support Service. Informasi dalam trace file juga digunakan untuk menyesuaikan aplikasi dan instance. Alert file atau alert log adalah sebuah trace file khusus. Alert log dari database adalah log yang berisi kronologis kejadian pesan dan kegagalan.
-          Backup File
Untuk mengembalikan file dengan menggantinya dengan backup file. Biasanya, Anda me-restore file ketika ada kegagalan media atau kesalahan dari user yang mengakibatkan kerusakan atau
kehilangan file asli. Backup dan restore yang dikelola user mengharuskan Anda untuk
benar-benar me-restore backup file sebelum Anda dapat melakukan percobaan recovery dari backup. Backup dan restore yang dikelola oleh server dapat mengelola proses backup, seperti penjadwalan backup, serta proses restore, seperti menerapkan backup file yang benar ketika recovery dibutuhkan.
• Struktur Proses
Terdapat 3 Struktur Proses pada Oracle :
a.       UserProcess
User Process adalah proses ketika user melakukan suatu aktivitas pada instance. Contohnya ketika user ingin melakukan login atau membuka suatu program. Satu user process dapat memiliki 2 server process yaitu ketika user login sebagai sys dan login kembali sebagai hr pada terminal yang lain
b.      ServerProcess
Server Process Terjadi ketika pengguna berhasil melakukan login (Connect Database / Connect SQL Plus). Server process dihapus ketika user berhasil logout
c.       BackgroundProcess
Background Process adalah proses yang tidak terlihat oleh user
•         archiver processes (ARCn) : Berfungsi untuk mengcopy data dari redo log file ke archive log file.
•         checkpoint process (CKPT) : berfungsi untuk mengupdate control file dan data file
•         coordinator-of-job-queues process (CJQn): secara dinamis menimbulkan slave processes terhadap job-queues.
•         database writer processes (DBWn)
•         dispatcher processes (Dnnn): multiplex server-processes users
•         memory-manager process (MMAN): digunakan untuk internal database seperti Automatic Shared Memory Management
•         log-writer process (LGWR) : Berfungsi untuk menulis data yang berubah ke redo log files.
•         log-write network-server (LNSn): mengirim redo log dalam penggunaan Data Guard
•         logical standby coordinator process (LSP0): kontrol aplikasi log Data Guard
•         media-recovery process (MRP): detached recovery-server process
•         memory-monitor process (MMON)
•         memory-monitor light process (MMNL): memperoleh dan menyimpan data Automatic Workload Repository (AWR).
•         process-monitor process (PMON).
•         process-spawner (PSP0): spawns Oracle processes
•         queue-monitor processes (QMNn).
•         recoverer process (RECO).
•         remote file-server process (RFS).
•         shared server processes (Snnn): melayani client-requests.
system monitor process (SMON).

RECOVERY DATABASE

Recovery : merupakan upaya untuk mengembalikan basis data ke keadaaan yang dianggap benar setelah terjadinya suatu kegagalan.
1.  Pemulihan terhadap kegagalan transaksi
2.  Pemulihan terhadap kegagalan system
3.  Pemulihan terhadap kegagalan media
Jenis – jenis kegagalan :
1.      Kegagalan system
Kegagalan yang mempengaruhi semua transaksi yang sedang berjalan tetapi tidak merusak database secara fisik.
Contoh : system error, software error
2.      Kegagalan media
Kegagalan yang merusak database dan semua transaksi yang sedang berjalan pada saat itu.
Contoh : head crash
Berbagai kemungkinan yang harus diantisipasi :
•         Gangguan Listrik
•         Kerusakan Disk
•         Kesalahan Perangkat Lunak
•         Pengaksesan oleh orang yang tidak berhak
•         Dua Pengguna/ lebih mengubah data yang sama
3.   Fasilitas recovery
Fasilitas recovery didalam DBMS :
•         Back up mechanism
Membuat back up database dan log file secara periodik
•         Looging facility
Mencatat semua transaksi yang sedang berjalan
•         Checkpoint facility
Synchronization point antara database dengan transaksi log file
•         Recovery manager
Mengijinkan system untuk merestore database kekondisi yang tepat
Sejumlah control yang disediakan oleh DMBS :
•         Pemulihan (recovery)
•         Pengamanan (security)
•         Integritas (integrity)
•         Konkurensi (concurency)
Teknik Pemulihan :                                       
1.      defered upate / perubahan yang ditunda :
Perubahan pada basis data 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 Upadte / perubahan langsung :
Perubahan pada basis data 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.
Pemulihan Transaksi
Sebuah transaksi adalah suatu kesatuan prosedur di dalam program yang mungkin memperbaharui data pada sejumlah tabel. Sebuah transaksi dikatakan telah disetujui (committed) kalau seluruh rangkaian proses dalam transaksi tersebut berhasil dilaksanakan. Dalam prakteknya, bisa saja sesuatu proses di dalam sebuah transaksi gagal dilaksanakan.
Keterangan :
a. mulai   : menyatakan keadaan awal
b. disetujui sebagian : keadaan setelah suatu pernyataan berhasil dilaksanakan
c. gagal : menyatakan keadaan setelah suatu pernyataan gagal melaksanakan tugas
d. batal : keadaan setelah transaksi dibatalkan. Setelah dibatalkan, keadaan dipulihkan  seperti keadaan awal transaksi.
e. disetujui  : keadaan setelah transaksi berhasil dijalankan
f. berakhir  : terjadi setelah transaksi disetujui atau dibatalkan
System mempunyai catatan yang disebut log atau jurnal pada disk, yang dijadikan pedoman untuk membatalkan suatu pengubahan basisdata prosedur konsep pencatatan pada log:
Baca (X, xi) menyatakan prosedur untuk membaca item X dan nilainya berupa xi.
Tulis (Y, yi) menyatakan prosedur untuk menulis item Y dan nilainya berupa yi.
Contoh catatan log :
mulai>  : ditulis ke dalam log sebelum Ti  dimulai
: pengubahan item X dengan nilai baru xi
: ditulis ke dalam log saat transaksi disetujui
Log Basis Data
Pernyataan pada SQL :
COMMIT  : menyetujui pengubahan data secara permanen dan membawa ke
keadaan  akhir
ROLLBACK  : membatalkan pengubahan data dan membawa ke keadaan akhir
Terdapat dua metode dasar, yaitu :
1.      pendekatan update-in-place.
2.   pendekatan deferred-update
Transaksi pada dasarnya melibatkan empat aksi, yaitu :
1. update – membaca dan memodifikasi sistem.
2. read – hanya membaca sistem.
3. commit – membuat permanent seluruh modifikasi terhadap sistem.
4. abort – membatalkan aksi-aksi yang telah dilakukan.
1.      Pendekatan update – in – place
Pendekatan ini melibatkan pembaharuan sistem sebagaimana transaksi berjalan dan meniadakan pembaruan-pembaruan jika transaksi dibatalkan. Implementasi aksi-aksi transaksi pada pendekatan ini adalah :
1.   Update – merekam  undo terhadap record (contoh nilai lama objek yang  diperbarui) di file log undo dan memperbarui sistem.
2.   Read – membaca nilai objek disistem.
3.   Commit – mengabaikan file log undo.
4.  Abort – menggunkan record-rekord undo di file log undo untuk mengembalikan   system ke kondisi semula sebelum transaksi dengan membalik operasi-operasi yang telah dilakukan.
2.     Pendekatan deferred – update
Melibatkan penyimpanan pembaruan-pembaruan transaksi saat dijalankan dan menggunakan pembaruan-pembaruan yang disimpan untuk memperbarui system saat transaksi di – commit. Implementasi aksi-aksi transaksi pada pendekatan ini adalah :
1. Update – merekam rekor redo ( contoh nilai baru dari objek yang sedang diperbarui) di file log redo (juga disebut intention list).
2.    Read – menggabungkan file log redo dan system untuk menentukan nilai objek.
3.  Commit – memperbarui system dengan menerapkan file log redo secara berurut (dimulai dengan opersi pertama yang dilakukan transaksi).
4.      Abort – mengabaikan file log redo dan transaksi.
   Shadow paging
•         Untuk pemeliharaan suatu transaksi digunakan 2 buah table page yaitu table page baru (current page) dan table page bayangan (shadow page)
•         Pada saat start kedua table page mempunyai isi yang sama
•         Table page bayangan tidak berubah selama waktu transaksi
•         Semua pengupdatean transaksi dituliskan ke table page baru
•         Pada saat hamper commit, isi table page bayangan di hapus dan isi table page baru dimasukkan ke dalam table page bayangan
•         Bila transaksi gagal maka table page harus dihapus
•         Dibandingkan menggunakan log file, menggunakan shadow paging lebih cepat karena tidak perlu redo atau undo, tetapi memerlukan data fragmentation dan garbage collection.
Pemulihan Sistem 
Karena gangguan sistem, hang, listrik terputus alirannya. Kegagalan pada system menyebabkan data yang berada dalam RAM hilang.
Implikasi :
Transaksi tidak selesai  : dibatalkan pada saat system aktif (prosesnya bisa disebut Undo).
Transaksi yang telah berakhir  (disetujui)  :ditulis ke basis data (prosesnya biasa disebut Redo).
Pemulihan Media
Pemulihan karena kegagalan media dengan cara mengambil atau memuat kembali salinan basis data (backup) atau Pemulihan dengan cara restore dari backup Bagian tak terpisah dari sistem basisdata adalah skema pemulihan (recovery). Pemulihhan bertanggung-jawab terhadap pendeteksian kegagalan dan mengembalikan basis data ke keadaan konsisten sebelum terjadinyya kegagalan. Kegagalan media (misalnya disk rusak) dan proses pemulihannya Kegagalan disebabkan penyimpanan permanent adalah jarang terjadi. Meskipun demikian perlu dipersiapkan untuk mengatasi kejadian kegagalan ini. Teknik utama untuk mengatasi ini adalah backup atau dump.
Kegagalan pada media disebabkan data di disk hhilang karena terkorupsi sewaktu sistem crash atau penulisan acak atau karena rusaknya head dari disk. Kalau kejadian ini berlangsung , kita dapat memperoleh data dari penyimpanan stabil (yang berpeluang kecil gagal karena dilakukan secara mirrored disks, atau mempunyai banyak kopian dibanyak lokasi jaringan).Data yang disimpan dipenyimpanan stabil adalah data itu sendiri dan file log. Kapan arsip yang konnsisten sulit dilakukan karena berarti harus menghentikan semua transaksi untuk perekaman kopian arsip. Pendekatan yang lebih baik adalah teknik “fuzzy dump” yaitu perekaman dilakukan secara asinkron selagi aktivitas transaksi berlangsung dilakukan secara konkuren sebagai aktivitas background. Skema dasar untuk mengatasai adalah backup seluruh isi basisdata ke penyimpan stabil (stabile storage) secara periodic. Penyimpan stabil adalah penyimpan yang tak pernah kehilangan isinya. Transfer blok antara memori dan penyimpan disk dapat menghasilkan beberapa kemungkinan hasil berikut :
Ø  sukses seluruhnya
Ø  informasi yang ditransfer tiba dengan selamat ditujuan
Ø  terjadi kegagalan persial
kegagalan. terjadi ditengah-tengah transfer dan blok tujuan memuat informasi yang salah.
Ø  terjadi kegagalan total
kegagalan terjadi diawal transfer sehingga blok tujuan tidak berubah. Sistem harus dapat mendeteksi terjadinya kegagalan transfer data dan melakukan prosedur pemulihan untuk mengembalikan blok ke keadaan konsisten . untuk melakukan hal ini, system harus mengelola dua blok fisik untuk tiap blok basisdata logik. Operasi penulisan sebagai berikut :
1.    Tulis informasi ke blok fisik pertama.
2.  Saat penulisan pertama sukses secara lengkap, tulis informasi yang sama ke blok fisik kedua.
3.  Penlisan dinyatakan sukses secara hanya setelah penulisan kedua sukses secara lengkap.
Prosedur pemulihan
Selama pemulihan , masing-masing pasangan blok fisik diperiksa. Jika keduanya sama dan tidak terdeteksi kesalahan , maka tak ada aksi yang dilakukan. Jika salah satu blok terdeteksi kesalahan, maka gantikan isisnya dengan blok yang tak terdeteksi kesalahan. Jika kedua blok tak terdeteksi kesalahan tapi berada maka gantikan blok pertama dengan nilai blok kedua.
Pemulihan berbasis log
Bentuk yang palingn sering digunakan untuk merekam mamodifikasi yang dilakukan terhadap basisdata adalah log. Rekaman log mendeskripsikan satu penulisan ke basisdata dan memiliki field-field berikut :
1. nama transaksi
nama transaksi untuk yang melakukan operasi penulisan.
2. nama item data
nama item data unik yang ditulis.
3. nilai nama
nilai ite data sebelum penulisan.
4. nilai baru
nilai item data yang seharusnya terjadi setelah penulisan.
Prosedur pemulihan
Setelah kegagalan maka basisdata dikembalikan ke keadaan terakhir yang di backup. Kemudian barisan transaksi stelah backup terakhir yang tercatat dilog dieksekusi ulang.
Pemulihan dengan checkpoint
Saat terjadi kegagalan system, maka diperlukan mengkonsultasi log untuk menetukan transaksi-transaksi yang perlu dijalankan kembali dan transaksi-trsansaksi yang perlu dijalankan kembali dan transaksi-transaksi yang tak perlu dijalankan ulang. Seluruh log perlu ditelusuri untuk menetukan hal ini. Terdapat dua kesulitan dengan pendekatan ini :
•  Proses pencairan memerlukan banyak waktu.
•  Kebanyakan transaksi yang perlu dilakukan telah dituliskan ke basisdata.
Meskipun menjalankan ulang transaksi-transaksi itu tidak merusak, tapi pemulihan menjadi lebih lama. Meruduksi overhead ini diperlukan checkpoint. System mengelolah log menggunakan salah satu teknik-teknik diatas. Sistem secara periodik membuat checkpoint sebagai berikut :
•  Tulis semua rekaman log yang saat itu berada dimemori utama kepenyimpan
stabil.
•  Tulis semua blok buffer yang telah dimodifikasi ke disk.
•  Tulis record log ke penyimpan stabil.

Cara Melakukan Recovery Database

1. Automatic Recovery

Automatic Recovery yaitu proses recovery yang dilakukan secara otomatis. Hal ini
adalah pilihan termudah untuk melakukan recovery database, karena hampir tidak
membutuhkan campur tangan pemakainya. Anda bisa melakukan hal ini dengan
mengikuti langkah-langkah berikut ini :
• Buka Recovery Manager. Kotak dialog Recovery Manager
• Dari kotakdialog tersebut, klik pushbutton Automatic Recovery.
• Jika database tidak aktif dan Anda ingin menampilkan dan memodifikasi nama file struktur database, maka Anda bisa memilih tombol File, sehingga kotak dialog Database Files muncul di layar.
• Jika databae Anda tidak aktif dan Anda ingin menampilkan dan mengubah parameter-parameter database yang akan berefek mulai dari database dibuka sampai proses recovery.
• Pilih tombol Recovery.


2. Memulihkan Database dengan Full Backup

Jika hal ini yang memang Anda lakukan, maka Oracle akan melakukan proses
recovery database dengan menggunakan file-file hasil full backup. Untuk melakukan
hal ini, Anda bisa mengikuti langkah-langkah berikut ini :
• Buka Recovery Manager, sehingga kotak dialog Recovery Manager tampak dilayar.
• Dari kotak dialog tersebut, pilih pushbutton Restore From Full Database Backup.
• Jika database tidak aktif dan Anda ingin menampilkan dan memodifikasi nama file struktur database, maka Anda bisa memilih tombol File sehingga kotak dialog Database Files muncul di layar.
• Jika database Anda tidak aktif dan Anda ingin menampilkan serta merubah parameter-parameter database yang akan berefek jika database dimulai sampai proses recovery, pilih tombol Parameters sehingga di layar Anda tampak kotak dialog Edit Database Parameter. Lakukan pengeditan terhadap parameter-parameter tersebut jika memang Anda menghendakinya. Jika sudah, klik tombol OK.
• Pilih Tombol Recovery sehingga di layar akan tampak kotak dialog
• Dari kotak dialog tersebut, pilih push button Restore From tape, atau Restore From Disk.
• Jika Anda merestore dari tape, pilih device dari daftar drop downnya. Jika Anda merestore dari disk, pilih direktori yang akan Anda gunakan untuk merestore database, dengan menggunakan tombol Browse atau mengetikkan direktori pathnya di dalam bagian Direktory.
• Pilih file backup dari daftar file Backup. Pilih klausa "<latest backup>" untuk menggunakan hasil backup yang terakhir atau menurut tanggal tertentu. Jika database tidak dijalankan, Anda akan diminta untuk memasukkan password database.
• Masukkan password Anda, dan jika sudah, klik tombol OK.
• Jika semua sudah selesai, pilih OK.

YANG PERLU DIPERHATIKAN SAAT MELAKUKAN BACKUP DATABASE

Faktor  yang perlu diperhatikan saat akan melakukan Backup database

• Penyimpanan
Anda harus menghitung terlebih dahulu berapa kapasitas penyimpanan yang diperlukan. Katakanlah minimum dan maksimum sekian GB. Banyak provider cloud backup yang mulai menerapkan harga per 1 GB. Dengan mengetahui kebutuhan ruang penyimpanan, anda dapat memilih cloud backup yang lebih sesuai dengan kebutuhan.

• Skalabilitas
Memang tidak semua pelaku bisnis mudah dalam menghitung kebutuhan penyimpanan. Oleh karena itu anda dapat memilih cloud backup yang dapat memberikan fleksibilitas secara cepat sesuai dengan kebutuhan ruang penyimpanan anda, baik itu semakin membesar atau mengecil.

• Pemulihan Bencana
Vendor dapat membuat semua jaminan uptime yang mereka inginkan, namun kenyataannya adalah kejadian tak terduga, seperti serangan cyber yang dapat mematikan server dan membuat data Anda tidak dapat diakses. Salah satu contohnya adalah serangan penolakan layanan terdistribusi (DDoS) yang melanda 26 situs web bank di A.S. selama musim liburan 2012-2013. contoh lainnya adalah ketika server Amazon di Virginia Utara mendadak offline karena badai petir yang parah. Kejadian tersebut membuat layanan utama seperti Netflix, Instagram dan Pinterest menjadi terhenti. Jika institusi besar bisa terkena, maka usaha kecil bisa terkena juga. Sementara downtime tidak selalu dapat dicegah, yang penting adalah memastikan layanan cloud backup yang Anda pilih dapat memberikan rencana pemulihan bencana yang efektif dan efisien untuk dapat kembali pulih dan online. Ini bisa berarti apa saja dari backup multilokasi hingga mitigasi cyberattack.

• Frekuensi Backup
Anda akan mengerjakan file dan memperbarui informasi sepanjang hari. Anda memerlukan ketenangan pikiran bahwa versi terbaru selalu dicadangkan. Jadi, sangat penting untuk mengetahui frekuensi pencadangan data ke layanan cloud dan bagaimana hal itu dilakukan. Praktik penyedia layanan cloud backup sangat bervariasi, jadi ada yang lebih cocok untuk jenis bisnis Anda daripada yang lain. Misalnya, beberapa layanan mencadangkan file saat Anda membuat perubahan, jadi ini bisa berarti apa saja dari membackup keseluruhan file lagi atau hanya menyinkronkan file sehingga hanya memback-up perubahan yang Anda buat. Beberapa layanan juga menawarkan frekuensi backup per jam, harian, bulanan atau lainnya. Sementara yang lain membiarkan Anda mengatur jadwal pencadangan sendiri. Ini akan lebih pada fitur yang perlu diperhatikan dalam memilih cloud backup.

• Keamanan
Beberapa hal yang harus dicari mencakup setidaknya enkripsi 256-bit saat istirahat dan selama transit (dalam penyimpanan dan saat dikirim ke dan dari server), Secure Socket Layer (SSL), dan penyimpanan data lokal dan off-site. selain pada teknologi cloud, anda juga harus perhatikan data center yang digunakan apakah memiliki sertifikasi ISO 27001 atau tidak.

PERLUNYA MELAKUKAN BACKUP DATABASE

Mengapa Database Perlu Dilakukan Backup ?


1. Definisi Backup Database
Backup data merupakan salah satu kegiatan yang harus dilakukan oleh pengelola database untuk melakukan penyalinan sistem, data dan aplikasi. Backup data harus dilakukan untuk menjaga jangan sampai terjadi kerusakan sistem dari luar ataupun dari dalam sistem, yang disengaja atau pun tidak disengaja.
Proses backup data dilakukan secara rutin sesuai dengan jadwal yang telah ditentukan, jika dimisalkan pada sebuah perusahaan memiliki 1 database yang melayani 100 transaksi perhari bisa kita bayangkan berapa banyak data yang terkumpul dalam 1 bulan, dan jika terjadi kerusakan system maka data yang begitu banyak akan hilang atau akan menjadi pekerjaan input data baru yang membuang buang waktu, dengan adanya proses backup data kejadian tersebut bisa dihindari, misalnya secara rutin administrator database melakukan penyimpanan data setiap minggu sehingga jika pada minggu ketiga hari kedua terjadi crash system atau kerusakan system yang terjadi akibat gangguan system atau factor gangguan cuaca seperti gempa, banjir dan tanah longsor yang merusak data secara fisik. Maka data yang hilang hanya 2 hari, sehingga total data yang hilang adalah 200 transaksi, dari ilustrasi diatas kita bisa mengetahui betapa pentingnya proses backup data untuk daur hidup suatu system database.


2. Alasan Pentingnya Dilakukan Backup Database

• Waktu sangatlah berharga
Berbicara mengenai data, berarti berbicara mengenai waktu. Sebuah data, walaupun terkadang berukuran 100kb saja, nilainya bisa setara dengan puluhan bahkan ratusan jam kerja.

• Kerja keras sangatlah berharga
Hampir sama dengan waktu, kerja keras juga sangatlah berharga. Biasanya, data penting dihasilkan dengan upaya yang tidak sedikit. Berpikir, merangkum, mengetik, dsb. Semuanya butuh upaya dan pemikiran yang besar. Kehilangan data tersebut bisa berarti kehilangan upaya dan kerja keras kamu selama ini.

• Uang sangatlah berharga
Berbicara dari segi bisnis, data identik dengan pendapatan, biaya, dan semuanya itu adalah uang. Kehilangan data penting bisa berarti kehilangan peluang bisnis, data rekan bisnis, prospek usaha, bahkan kehilangan kepercayaan dari atasan.

• Virus ada dimana-mana
Tidak jarang virus yang bekerja dengan menghapus atau merusak berbagai data dengan ekstensi tertentu, misalnya saja virus Blackmal yang mampu menghapus sekitar 11 ekstensi file di hardisk. Karena banyaknya pengguna, Windows menjadi sasaran utama dari para pembuat virus. Oleh karena itu, membackup data merupakan langkah yang penting untuk mengamankan data dari serangan virus penghapus file semacam ini.

• Hardisk bisa rusak kapan saja
Memang, dengan teknologi secanggih sekarang, komponen komputer termasuk hardisk bisa bertahan dalam jangka waktu yang lama. Tetapi hal itu tidak menjamin bahwa hardisk baru tidak akan memiliki masalah. Berbagai hal seperti kesalahan produksi, kondisi cuaca, goncangan, kestabilan listrik, dll. bisa membuat hardisk kamu rusak sebelum waktunya. Bisa jadi tahun depan, bulan depan, minggu depan, atau besok.

• Bencana bisa datang kapan saja
Walaupun kita selalu berharap tidak ada bencana apapun yang menimpa kita, namun berbagai bencana seperi kebakaran, banjir, gempa bumi, dsb. tidak bisa kita prediksi kedatangannya. Banjir yang sering hadir di Jakarta misalnya, bisa jadi merusak komputer dan berbagai komponen di dalamnya, termasuk hardisk. Jika sampai komputer rusak karena bencana, dan kita sama sekali belum melakukan backup, maka kehilangan data penting akan menambah besarnya kerugian kita.

• Pencurian bisa terjadi kepada siapa saja
Walaupun kita tidak pernah menginginkannya, resiko pencurian bisa menyerang kepada siapa saja. Tidak menutup kemungkinan laptop atau komputer kita akan hilang dicuri oleh orang yang tidak bertanggung jawab. Jika hal itu terjadi, paling tidak data penting kita tidak ikut hilang karena kita telah rajin melakukan backup sebelumnya.