RAC, Data Guard, dan Stream adalah tiga alat dalam sistem high availability Oracle. Setiap alat dapat digunakan secara mandiri atau kombinasi. Mereka memiliki fokus berbeda dan berlaku dalam skenario yang berbeda.
RAC unggul dalam mengatasi single point of failure dan load balancing. Oleh karena itu, RAC umumnya digunakan dalam sistem kritis 24/7. Namun, pada solusi RAC, data hanya tersedia dalam satu salinan. Meskipun kegagalan penyimpanan dapat dihindari melalui mekanisme seperti RAID, data itu sendiri tidak memiliki redundansi, sehingga rentan terhadap single point failures.
Data Guard menyediakan perlindungan data melalui pengadaan data yang redundan. Dengan memanfaatkan mekanisme sinkronisasi log, Data Guard memastikan sinkronisasi antara data redundan dan data utama. Sinkronisasi ini dapat dicapai dalam berbagai bentuk seperti real-time, tertunda, sinkron, atau asinkron. Data Guard umum digunakan dalam solusi pemulihan bencana jarak jauh dan ketersediaan tinggi untuk perusahaan kecil. Meskipun memungkinkan kueri hanya-baca pada mesin cadangan untuk mengurangi tekanan kinerja pada basis data utama, Data Guard tidak dimaksudkan terutama sebagai solusi kinerja.
Streams, yang dibangun di atas Oracle Advanced Queue, memungkinkan sinkronisasi data dan menawarkan konfigurasi yang fleksibel pada berbagai tingkatan. Karena Oracle menyediakan dukungan pengembangan yang luas, termasuk API yang kaya, Streams lebih cocok digunakan untuk berbagi data pada tingkat aplikasi.
Apa Itu Data Guard?
Dalam lingkungan Data Guard, terdapat setidaknya dua basis data: satu dalam keadaan terbuka yang memberikan layanan ke eksternal, dikenal sebagai Primary Database, dan yang lainnya dalam keadaan pemulihan, dikenal sebagai Standby Database. Selama masa operasi, Primary Database melayani klien, dan operasi yang dilakukan pengguna dicatat dalam log online dan log arsip, yang selanjutnya dikirimkan ke Standby Database melalui jaringan. Log tersebut kemudian dijalankan kembali pada Standby Database untuk mencapai sinkronisasi data antara keduanya.
Data Guard Oracle lebih lanjut mengoptimalkan proses ini, mengotomatisasi dan menyederhanakan tugas transmisi dan pemulihan log, sekaligus menyediakan berbagai parameter dan perintah untuk mempermudah pekerjaan administrator basis data (DBA).
Jika ada faktor yang diperkirakan memerlukan penutupan Database Utama, seperti peningkatan perangkat lunak atau perangkat keras, Database Siaga dapat beralih peran menjadi Database Utama dan terus melayani klien. Hal ini meminimalkan waktu tidak beroperasi dan memastikan integritas data. Dalam kasus terjadi masalah tak terduga yang menyebabkan Database Utama tidak tersedia, Database Siaga dapat dipaksa untuk beralih peran menjadi Database Utama dan melanjutkan pelayanan kepada klien. Tingkat kehilangan data dalam kasus seperti ini tergantung pada tingkat perlindungan data yang telah dikonfigurasikan. Oleh karena itu, Database Utama dan Database Siaga merupakan peran konseptual yang tidak tetap pada database tertentu.
Arsitektur Data Guard
Arsitektur Data Guard dapat dibagi menjadi tiga bagian fungsional:
1) Pengiriman Redo:
Selama Primary Database berjalan, log redo terus menerus dihasilkan dan perlu dikirimkan ke Standby Database. Aksi pengiriman ini dapat dilakukan oleh proses LGWR atau ARCH dari Primary Database. Tujuan arsip yang berbeda dapat menggunakan metode yang berbeda, tetapi untuk tujuan tertentu, hanya satu metode yang dapat dipilih. Pemilihan proses ini memiliki pengaruh signifikan terhadap kemampuan perlindungan data dan ketersediaan sistem.
2) Redo Receive:
Proses RFS (Remote File Server) pada Standby Database menerima log dan menuliskannya ke dalam file Standby Redo Log atau Archived Log, tergantung pada metode transport log Primary Database dan lokasi Standby Database. Jika log ditulis ke file Standby Redo Log, maka saat terjadi pergantian log di Primary Database, akan memicu pergantian log di Standby Redo Log pada Standby Database dan melakukan pengarsipan pada Standby Redo Log tersebut. Jika log ditulis ke dalam Archived Logs, maka operasi ini dapat dianggap sebagai proses pengarsipan itu sendiri.
3) Penerapan Ulang:
Layanan penerapan ulang bertanggung jawab untuk memainkan ulang log Database Primer pada Database Cadangan, sehingga mencapai sinkronisasi data antara kedua database tersebut.
Terdapat dua jenis Standby Database tergantung bagaimana database tersebut memainkan log, yaitu: Physical Standby dan Logical Standby.
Berdasarkan kapan Redo Apply terjadi, ada juga dua jenis:
a) Penerapan Real-Time: Metode ini memerlukan penggunaan Standby Redo Log. Setiap kali log ditulis ke Standby Redo Log, hal ini akan memicu proses pemulihan. Keuntungan metode ini adalah mengurangi waktu yang dibutuhkan untuk pergantian basis data karena log yang tersisa telah dipulihkan secara real-time.
b) Terapkan di Arsip: Metode ini menerapkan log ketika terjadi pergantian log pada Database Primer dan memicu pengarsipan di Database Sekunder. Pemulihan dimulai setelah proses pengarsipan selesai. Ini juga merupakan mode pemulihan bawaan.
Physical Standby vs. Logical Standby
Ada dua jenis Basis Data Cadangan: Physical Standby dan Logical Standby.
1. Physical Standby:
Database Physical Standby sama dengan database Primary. Data Guard memelihara database Physical Standby melalui penerapan REDO. Secara umum, ketika Physical Standby tidak menerapkan REDO, database dapat dibuka dalam mode READ ONLY. Jika area Flashback ditentukan dalam database, database bahkan dapat sementara diubah ke mode READ WRITE untuk melakukan operasi tertentu. Setelah menyelesaikan operasi yang diperlukan, database dapat dipulihkan kembali ke keadaannya sebelum mode READ WRITE menggunakan fitur Flashback Database, sehingga memungkinkan penerapan data REDO dari database Primary untuk dilanjutkan.
Catatan: Fungsi aplikasi dari Physical Standby telah ditingkatkan dalam Oracle 11g. Pada versi ini, Physical Standby dapat terus menerapkan data REDO meskipun berada dalam mode OPEN READ ONLY. Hal ini meningkatkan secara signifikan kelayagunaan basis data Physical Standby.
Fungsi Physical Standby:
1) Pemulihan bencana dan ketersediaan tinggi: Standby Fisik menyediakan solusi yang kuat dan efisien untuk pemulihan bencana dan ketersediaan tinggi. Solusi ini mempermudah pengelolaan switchover/failover dan mengurangi waktu henti yang direncanakan maupun tidak direncanakan.
2) Perlindungan data: Dengan basis data Physical Standby, Data Guard memastikan kehilangan data diminimalkan, bahkan menghadapi bencana yang tidak terduga sekalipun.
3) Kurangi beban kerja basis data utama: Dengan memindahkan sebagian tugas, seperti cadangan data dan kueri hanya-baca, ke basis data Standby Fisik, sumber daya CPU dan I/O pada basis data utama dapat dihemat.
4) Kinerja ditingkatkan: Mekanisme penerapan REDO yang digunakan dalam database Physical Standby beroperasi pada tingkat pemulihan terendah, melewati eksekusi kode SQL. Hal ini menghasilkan efisiensi dan kinerja tertinggi.
2. Logical Standby:
Database Logical Standby juga dibuat berdasarkan database utama (atau cadangan atau replikanya, seperti Physical Standby). Oleh karena itu, pada awalnya, Logical Standby mirip dengan database Physical Standby. Namun, karena Logical Standby menerapkan data REDO melalui eksekusi SQL, struktur file fisik dan bahkan struktur logis datanya bisa berbeda dari database utama.
Berbeda dengan Physical Standby, Logical Standby umumnya dibuka dalam mode BACA TULIS, memungkinkan pengguna mengaksesnya kapan saja. Dengan kata lain, eksekusi SQL berlangsung saat Logical Standby berada dalam keadaan TERBUKA. Hal ini memiliki kelebihan dan kekurangan. Karena sifat eksekusi SQL tersebut, terdapat batasan operasional pada tipe data tertentu dan beberapa pernyataan DDL/DML di dalam Logical Standby. Anda dapat memeriksa tipe data yang tidak didukung melalui tampilan DBA_LOGSTDBY_UNSUPPORTED. Jika tipe data tersebut digunakan, tidak dapat dijamin konsistensi penuh dalam basis data.
Mode BACA TULIS terbuka dari Logical Standby membuatnya cocok digunakan sebagai sistem pelaporan, mengurangi beban kerja sistem tersebut.
Fungsi Logical Standby:
Selain karakteristik yang disebutkan sebelumnya untuk Physical Standby, seperti pemulihan bencana, ketersediaan tinggi, dan perlindungan data, Logical Standby memiliki fitur-fitur berikut:
1) Pemanfaatan efisien sumber daya perangkat keras pada server siaga: Basis data Logical Standby dapat digunakan untuk membuat indeks tambahan, materialized view, serta memenuhi kebutuhan bisnis tertentu. Basis data ini juga dapat membuat skema baru (yang tidak ada di basis data Primer) serta menjalankan operasi DDL atau DML yang tidak sesuai dijalankan di basis data Primer.
2) Kurangi beban kerja database utama: Dengan menjaga database Standby Logis tetap terbuka sambil tetap tersinkron dengan database utama, database ini dapat berfungsi baik untuk perlindungan data maupun operasi pelaporan. Hal ini meringankan beban database utama dari tugas pelaporan dan kueri, sehingga menghemat sumber daya CPU dan I/O yang berharga.
3) Peningkatan yang lancar: Logical Standby dapat digunakan untuk operasi seperti peningkatan antar versi dan pembaruan patch basis data.
Mode Perlindungan Data
Data Guard memungkinkan tiga mode perlindungan data: Maksimum Perlindungan, Ketersediaan Maksimum, dan Kinerja Maksimum.
1. Perlindungan Maksimum:
Mode ini memastikan tidak ada kehilangan data. Untuk mencapai hal ini, semua transaksi tidak hanya harus ditulis ke Online Redo Logs lokal sebelum commit, tetapi juga secara bersamaan ditulis ke Standby Redo Logs di basis data Standby. Data REDO harus dapat diakses di setidaknya satu basis data Standby (jika ada lebih dari satu) sebelum transaksi dapat dikomitmankan di basis data Primary. Jika basis data Standby menjadi tidak tersedia akibat gangguan (misalnya, gangguan jaringan), maka basis data Primary akan dimatikan untuk mencegah kehilangan data.
Mengaktifkan mode ini memerlukan Konfigurasi Standby Database dengan Standby Redo Logs, dan Primary Database harus menggunakan mode LGWR, SYNC, AFFIRM untuk proses pengarsipan ke Standby Database.
2. Ketersediaan Maksimum:
Mode ini menyediakan strategi perlindungan data tingkat tertinggi tanpa mempengaruhi ketersediaan database Primer. Mode ini mengikuti implementasi yang sama seperti Perlindungan Maksimum, di mana transaksi lokal harus ditulis ke setidaknya satu Standby Redo Logs dari database Siaga sebelum commit. Namun, perbedaannya adalah jika terjadi kegagalan yang membuat database Siaga tidak dapat diakses, database Primer akan secara otomatis beralih ke mode Kinerja Maksimum alih-alih mematikan sistem. Setelah database Siaga pulih, database Primer akan secara otomatis kembali ke mode Ketersediaan Maksimum.
Meskipun mode ini bertujuan untuk meminimalkan kehilangan data, mode ini tidak dapat menjamin konsistensi data secara mutlak. Seperti Mode Perlindungan Maksimum, mode ini juga memerlukan Database Siaga dikonfigurasi dengan Standby Redo Logs, dan Database Primer harus menggunakan mode LGWR, SYNC, AFFIRM untuk mengarsipkan ke Database Siaga.
3. Kinerja Maksimum:
Mode ini menyediakan tingkat strategi perlindungan data tertinggi tanpa mempengaruhi kinerja database Primer. Transaksi dapat dikomitmankan kapan saja, dan data REDO dari database Primer saat ini perlu ditulis ke setidaknya satu database Standby, meskipun hal ini dapat dilakukan secara asinkron. Dalam kondisi jaringan yang ideal, mode ini dapat memberikan perlindungan data yang serupa dengan Ketersediaan Maksimum sambil hanya memberikan dampak yang kecil pada kinerja database Primer. Mode ini adalah mode perlindungan default ketika membuat database Standby. Mode ini dapat dicapai menggunakan proses LGWR ASYNC maupun ARCH, dan Standby Redo Logs tidak diperlukan untuk database Standby.
Langkah-langkah untuk Mengubah Mode Perlindungan Data:
1. Matikan database dan mulai ulang dalam keadaan Mount. Jika merupakan konfigurasi RAC, matikan semua instance dan hanya mulai satu instance dalam keadaan Mount.
2. Ubah mode menggunakan sintaks berikut:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
Contoh: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. Buka database: ALTER DATABASE OPEN;
4. Konfirmasikan mode perlindungan data yang dimodifikasi:
SQL>select protection_mode,protection_level dari v$database;
Layanan Penerapan Log
Data Guard memastikan konsistensi antara basis data Primer dan basis data Siaga dengan menerapkan REDO. Di balik layar, mendukung proses ini secara diam-diam, adalah Layanan Penerapan Log yang terkenal. Terdapat dua jenis Layanan Penerapan Log:
1. REDO Apply: Fitur yang khusus untuk basis data Standby fisik, menjaga sinkronisasi dengan basis data Primer melalui pemulihan media.
2. SQL Apply: Khusus untuk basis data Standby logis, fungsinya utamanya adalah menganalisis pernyataan SQL melalui LogMiner dan mengeksekusinya di sisi Standby.
Oleh karena itu, saat menerapkan data REDO, basis data Standby fisik harus berada dalam keadaan MOUNT, sedangkan basis data Standby logis dibuka dalam mode READ WRITE untuk penerapan data REDO. Namun, objek yang dipertahankan secara default diatur ke read-only dan tidak dapat dimodifikasi secara langsung di sisi Standby logis.
Lindungi basis data Oracle dengan solusi profesional
Oracle Data Guard adalah solusi yang tangguh untuk ketersediaan tinggi, perlindungan data, dan pemulihan bencana. Ini merupakan alat penting bagi bisnis yang tidak dapat mentolerir waktu henti atau kehilangan data yang signifikan. Namun demikian, untuk memberikan perlindungan lebih lanjut terhadap lingkungan basis data Anda, disarankan untuk mencadangkan basis data Oracle dengan solusi pencadangan dan pemulihan bencana yang profesional.
Vinchin Backup & Recovery menyediakan fungsi yang kuat untuk melindungi basis data Anda baik di mesin virtual maupun server fisik, dengan cara yang cukup otomatis, fleksibel, dan efisien. Vinchin menyediakan perlindungan berbagai jenis basis data seperti Oracle DB, MySQL, SQL Server, Postgres Pro, dan MariaDB, mendukung kompresi basis data, pengelolaan tugas terpusat, strategi pencadangan cerdas, pencadangan basis data aktif (hot database), serta dukungan lanjutan untuk SQL Server/Oracle. Selain itu, Vinchin juga mendukung fitur perlindungan ransomware yang kuat dan migrasi V2V lintas 10+ platform virtual.
Vinchin Backup & Recovery telah dipilih oleh ribuan perusahaan dan Anda juga dapat mulai menggunakan sistem yang andal ini dengan uji coba selama 60 hari dengan fitur lengkap! Selain itu, hubungi kami dan tinggalkan kebutuhan Anda, lalu Anda akan menerima solusi yang sesuai dengan lingkungan TI Anda.
Kesimpulan
Oracle Data Guard adalah komponen kritis untuk setiap penerapan basis data Oracle tingkat perusahaan, menyediakan solusi komprehensif untuk pemulihan bencana, ketersediaan tinggi, perlindungan data, dan penyeimbangan beban kerja. Arsitekturnya yang fleksibel dan berbagai mode operasi membuatnya dapat disesuaikan dengan berbagai kebutuhan bisnis dan persyaratan operasional.
Anda dapat memilih Vinchin Backup & Recovery untuk dengan mudah mencadangkan dan memulihkan basis data Oracle Anda. Jangan lewatkan uji coba gratisnya!
