Opsi pemulihan dari bencana untuk workload database Oracle

Panduan ini menjelaskan opsi pemulihan dari bencana yang tersedia bagi pengguna menjalankan workload database Oracle yang sangat penting dalam Solusi Bare Metal lingkungan fleksibel App Engine.

Panduan ini mengasumsikan bahwa Anda menjalankan Oracle Enterprise Edition. Beberapa fitur yang dijelaskan dalam panduan ini dilisensikan secara terpisah di luar Lisensi Edisi Perusahaan. Beberapa fitur ini mencakup, tetapi tidak terbatas menjadi:

• Cluster Aplikasi Nyata Oracle
• Oracle Active Data Guard
• Kompresi Lanjutan Oracle
• GoldenGate Oracle

Baca perjanjian lisensi Oracle Anda untuk menentukan fitur mana yang Anda digunakan saat merencanakan pemulihan dari bencana dan ketersediaan tinggi.

RTO dan RPO Aplikasi

Pemulihan dari bencana untuk teknologi database Oracle harus ditentukan berdasarkan batas waktu pemulihan (RTO) dan batas titik pemulihan aplikasi (RPO). Secara umum, RTO menjelaskan jumlah waktu henti yang dapat diterima untuk suatu sistem, dan RPO menjelaskan jumlah kehilangan data yang dapat diterima. Biaya dan kompleksitas sistem meningkat karena masing-masing nilai ini menurun. Untuk selengkapnya informasi tentang RTO dan RPO, lihat Dasar-dasar perencanaan DR.

Arsitektur yang diberi label "RPO = 0" atau "nol kehilangan data" memerlukan data harus ditulis di beberapa lokasi sebelum dianggap "dikomitmenkan" dapat {i>database<i}. Latensi menjadi masalah saat RPO bergerak mendekati nol.

Kecuali diperhitungkan dengan benar selama fase desain, menerapkan nol data arsitektur kerugian dapat berdampak buruk pada performa aplikasi secara keseluruhan.

Ketersediaan tinggi versus pemulihan dari bencana

Ketersediaan tinggi dan pemulihan bencana adalah konsep pelengkap ketika merancang arsitektur {i>database <i} yang dapat diandalkan. Dalam konteks panduan ini, ketersediaan tinggi mengacu pada kemampuan sistem untuk memulihkan secara otomatis dari kegagalan satu per satu atau beruntun pada sistem. Di sisi lain, bencana pemulihan adalah bagian dari rencana kelangsungan bisnis secara keseluruhan dan berlaku untuk kegagalan yang dapat membuat seluruh grup sistem menjadi tidak tersedia. Rencana pemulihan bencana mencakup ruang lingkup yang lebih besar karena jumlah komponen terintegrasi yang harus dapat digunakan kembali jika terjadi bencana.

Ketersediaan tinggi harus dianggap sebagai "garis pertahanan pertama" saat mendesain sistem yang andal. Arsitektur {i>database<i} yang sangat tersedia harus dapat mempertahankan kegagalan individual dan terus berjalan tanpa menyebabkan periode nonaktif untuk aplikasi. Komponen ketersediaan tinggi dari suatu sistem harus disertakan, tetapi tidak terbatas pada hal berikut:

• Daya yang redundan ke hardware server, jaringan, atau penyimpanan
• Beberapa antarmuka jaringan, {i>switch<i}, dan kabel
• Kain penyimpanan redundan, pengontrol, dan perangkat disk
• Partner Interconnect yang fault-tolerant antara Google Cloud dan Ekstensi region Solusi Bare Metal
• Oracle RAC untuk mencegah kegagalan server menonaktifkan database

Desain pemulihan bencana harus mencakup proses pemulihan dari berbagai kegagalan beruntun yang merender komponen. Rencana pemulihan bencana perencanaan harus mempertimbangkan hal-hal berikut:

• Gangguan regional
• Bencana alam
• Insiden yang mengakibatkan pemadaman seluruh satu atau lebih komponen komputer aplikasi

Alat pemulihan dari bencana Oracle dan ketersediaan tinggi

Berikut adalah beberapa alat pemulihan dari bencana (disaster recovery) dan ketersediaan tinggi Oracle:

• Cluster Aplikasi Nyata Oracle
• Pengelola Pemulihan Oracle
• Oracle Data Guard
• Database flashback
• Oracle GoldenGate

Cluster Aplikasi Nyata Oracle

Oracle Real Application Clusters (RAC) digunakan untuk menskalakan database secara horizontal workload yang akan dilayani oleh beberapa server database. Database yang menggunakan RAC memungkinkan konfigurasi aktif/aktif antarserver dalam satu region .

RAC biasanya digunakan untuk memberikan ketersediaan tinggi bagi sistem yang melindungi dari kegagalan server tunggal. Karena "berbagi semuanya" pendekatan (penyimpanan bersama dan jaringan bersama) untuk pengelompokan, cluster RAC yang berjalan di lingkungan Solusi Bare Metal harus ada di dalam pod Solusi Bare Metal tunggal. Hal ini membuat RAC menjadi solusi untuk ketersediaan tinggi kekhawatiran, tetapi tidak memenuhi persyaratan pemulihan dari bencana.

Untuk mempelajari cara menyiapkan RAC untuk Solusi Bare Metal, lihat Menginstal Oracle RAC di Solusi Bare Metal.

Pengelola Pemulihan Oracle

Oracle Recovery Manager (RMAN) adalah alat utama untuk pencadangan dan pemulihan {i>Database<i} Oracle karena kemampuannya untuk membaca {i>datafile<i} milik Oracle format font. Alat ini dapat digunakan untuk melakukan clone database, pemulihan point-in-time, atau bahkan pemulihan satu tabel dalam {i>database<i} Oracle.

RMAN adalah satu-satunya alat yang dapat digunakan untuk mengambil cadangan saat {i>database<i} terbuka. Alat ini juga digunakan untuk mengelola katalog file cadangan yang tersedia untuk pemulihan.

Data Guard Oracle

Oracle Data Guard melakukan replikasi {i>database<i} ke klaster RAC jarak jauh atau penginstalan database. Data Guard mendukung database standby baik di konfigurasi fisik atau logis.

{i>Database<i} standby secara fisik adalah salinan {i> block-for-block<i} yang memungkinkan satu salinan {i>database<i} menjadi terbuka untuk menulis; yang lainnya sudah dipasang (tetapi tidak terbuka) untuk menerapkan perubahan atau membuka hanya-baca untuk mendukung pelaporan menggunakan berbagai aplikasi obrolan.

Untuk mempelajari cara menyiapkan Data Guard di Solusi Bare Metal, lihat Men-deploy Oracle Data Guard pada Solusi Bare Metal.

FLASHBACK DATABASE

Fitur FLASHBACK DATABASE dari Oracle Enterprise Edition memungkinkan administrator memundurkan {i>database<i} dengan cepat ke waktu tertentu tanpa perlu dan melakukan pemulihan {i>database<i} yang memakan waktu.

Dalam konteks pemulihan dari bencana, FLASHBACK DATABASE biasanya digunakan di bersama dengan Data Guard selama operasi failover untuk mendapatkan database yang lebih cepat pengaktifan kembali. Database yang gagal di-flash kembali ke titik waktu tertentu yang konsisten dengan log di {i>primary <i}baru, dan {i>redo<i} dikirim sehingga dapat disinkronkan ulang sepenuhnya.

GoldenGate Oracle

Oracle GoldenGate adalah alat replikasi logis yang umum digunakan untuk memungkinkan deployment multi-situs aktif/aktif atau pemindahan data di seluruh hardware di seluruh platform Google. Saat menggunakan GoldenGate, sebuah proses extract di database sumber menangkap perubahan di log {i>redo<i} {i>online<i} dan menulisnya pada perubahan pada jalur yang dikirim ke database target. Proses replicat di database target mengonversi transaksi dari file tail ke SQL, dan menjalankan SQL pada database target.

Arsitektur ini menjadikan GoldenGate sebagai alat yang ampuh untuk memindahkan data platform {i>database<i} atau mengubah data seperti yang direplikasi. Tidak seperti Data Guard, GoldenGate membutuhkan perangkat lunak terpisah untuk diinstal dan dikelola di sumber dan sistem target. GoldenGate tidak dapat digunakan untuk replikasi sinkron karena transaksi diterjemahkan dan diterapkan sebagai SQL pada target database Anda. Meskipun GoldenGate dapat memberikan kelonggaran minimal untuk replikasi, GoldenGate saja tidak dapat menjamin RPO nol.

Model deployment pemulihan dari bencana (Khusus database)

Oracle telah menciptakan framework {i> Maximum Availability Architecture <i}(MAA) untuk memberi Anda model pemulihan dari bencana yang direkomendasikan untuk men-deploy aplikasi dan database.

Masing-masing model berikut menyediakan target RTO dan RPO tertentu:

• Model tembaga
• Model perunggu
• Model perak
• Model emas
• Model platinum

Model dipetakan ke pola deployment tertentu yang memenuhi RPO dan RTO pada saat pemadaman layanan yang direncanakan dan tidak terencana. Setiap beban kerja database harus dievaluasi untuk persyaratan ketersediaannya dan dirancang dengan model transformer. Umumnya database pengembangan menggunakan model dengan perlindungan yang lebih rendah dibandingkan produksi dan uji mutu (QA) mereka.

Model Perunggu ditujukan untuk {i>database<i} yang tidak memerlukan RTO yang diukur menit. Model Silver dan dengan level yang lebih tinggi mencakup database standby yang berjalan di situs jarak jauh. Setiap model menggabungkan fungsi tingkat rendah jaringan. Misalnya, model Bronze menggunakan konsep pencadangan dan pemulihan yang harus tetap diikuti meskipun database standby di-deploy.

Model tembaga

Model tembaga menyediakan deployment minimal untuk mencadangkan database ke penyimpanan lokal ke penyimpanan yang berada di luar ekstensi wilayah. Ini memerlukan pendekatan dua tahap, tetapi juga dapat menggunakan skrip Google Cloud SDK untuk mengotomatiskan transmisi cadangan.

Menggunakan deployment ini juga meningkatkan RTO karena pemulihan dua tahap yang tidak diperlukan. RMAN tidak dapat mengakses cadangan secara langsung, sehingga harus dipindahkan ke yang tersedia untuk RMAN sebelum pemulihan dapat dimulai.

Penonaktifan, layanan nonaktif	Jenis pemadaman	RPO	RTO
Tidak terencana	Kegagalan node atau instance yang dapat dipulihkan	0	Waktu yang diperlukan untuk memulai ulang instance
	Bencana: korupsi	{i>archivelog<i} terakhir, tambahan, atau cadangan penuh yang terakhir yang ditransfer keluar dari RE	Jam, bergantung pada ukuran database dan bandwidth yang ditetapkan ke Partner Interconnect
	Bencana: kegagalan perluasan wilayah	Cadangan log arsip terakhir, cadangan inkremental, atau cadangan penuh yang ditransfer keluar dari RE	Hari / minggu, bergantung pada waktu yang diperlukan untuk menghubungkan kembali perluasan wilayah ke internet
Direncanakan	Patch database, update OS / FW	0	Waktu yang diperlukan untuk mengupdate dan memulai ulang instance
	Upgrade database utama	0	1-2 jam

Model perunggu

Model Bronze menawarkan dua opsi deployment. Keduanya menggunakan Penyimpanan berbasis Google Cloud untuk menyimpan cadangan database.

Deployment Bronze 1: Pencadangan pada regional storage

Dalam deployment ini, cadangan langsung ditulis ke media di luar lokasi. Dalam sebagian besar kasus, tujuan pencadangan yang dipilih adalah Cloud Storage dengan Cloud Storage FUSE, yang menampilkan bucket Cloud Storage sebagai sistem file.

Rekomendasi untuk menggunakan Cloud Storage FUSE dapat ditemukan di Oracle Backups dengan NFS dan Cloud Storage. Google Cloud Filestore, yang menunjukkan pembagian NFS ke instance Solusi Bare Metal, juga dapat digunakan.

Diagram berikut menunjukkan contoh deployment.

Penonaktifan, layanan nonaktif	Jenis pemadaman	RPO	RTO
Tidak terencana	Kegagalan node atau instance yang dapat dipulihkan	0	Waktu yang diperlukan untuk memulai ulang instance
	Bencana: korupsi	Cadangan log arsip terakhir, cadangan inkremental, atau cadangan penuh	Jam, bergantung pada ukuran database dan bandwidth yang ditetapkan ke Partner Interconnect
	Bencana: kegagalan perluasan wilayah	Cadangan log arsip terakhir, cadangan inkremental, atau cadangan penuh	Hari / minggu, bergantung pada waktu yang diperlukan untuk menghubungkan kembali perluasan wilayah ke internet
Direncanakan	Patch database, update OS/FW	0	Waktu yang diperlukan untuk mengupdate dan memulai ulang instance
	Upgrade database utama	0	1-2 jam

Deployment Bronze 2: Pencadangan menggunakan Pencadangan dan DR

Dalam deployment ini, Pencadangan dan DR Service digunakan untuk menyimpan cadangan di Google Cloud. Pencadangan dan DR menawarkan biaya pencadangan, yang disimpan di media kinerja tinggi yang didukung oleh Cloud Storage untuk retensi jangka panjang.

Pencadangan dan DR juga menawarkan RTO yang lebih cepat daripada menyimpan cadangan di Filestore atau Cloud Storage, karena dapat langsung membuat gambar file database yang tersedia untuk instance Oracle. Pemasangan dan migrasi membawa database online dengan cepat sembari menyalin kembali ke jalur produksi media penyimpanan, secara drastis mengurangi RTO.

Diagram berikut menunjukkan contoh deployment.

Penonaktifan, layanan nonaktif	Jenis pemadaman	RPO	RTO
Tidak terencana	Kegagalan node atau instance yang dapat dipulihkan	0	Waktu yang diperlukan untuk memulai ulang instance Detik jika menggunakan RAC
	Bencana: korupsi	Cadangan log arsip terakhir, cadangan inkremental, atau cadangan penuh	Dari menit hingga jam, bergantung pada persyaratan performa, ukuran database, dan bandwidth yang ditetapkan untuk Partner Interconnect
	Bencana: kegagalan perluasan wilayah	Cadangan log arsip terakhir, cadangan inkremental, atau cadangan penuh	Hari / minggu, bergantung pada waktu yang diperlukan untuk mengembalikan ekstensi wilayah menjadi online atau kemampuan pelanggan untuk pindah ke ekstensi wilayah lain.
Direncanakan	Patch database, update OS / FW	0	Waktu yang diperlukan untuk mengupdate dan memulai ulang instance
	Upgrade database utama	0	1-2 jam

Silver

Model Silver memperkenalkan replikasi database menggunakan Oracle Data Guard. Data Guard menyediakan replikasi database real-time dengan satu atau beberapa database bertindak sebagai database standby. Karena Data Guard bergantung pada pengangkutan dan menerapkan perubahan {i>database<i} saat mereka terjadi, RPO bisa mendekati nol. Perak mengandalkan replikasi asinkron; menggunakan replikasi sinkron memastikan kehilangan data nol, tetapi waktu yang dibutuhkan untuk mengirim data antar region biasanya mendorong waktu respons aplikasi melampaui batas yang dapat diterima.

Fitur failover mulai cepat Data Guard memiliki kemampuan untuk melakukan operasi failover jika database utama tidak tersedia untuk periode waktu yang ditentukan pengguna. Konfigurasi tersebut dipantau oleh Data Guard proses pengamat, yang dapat berjalan.

Model Silver memiliki manfaat untuk memastikan bahwa database tersedia di terjadi kegagalan total regional, tetapi operasi failover dan peralihan mungkin memengaruhi performa aplikasi sebagai latensi jaringan di antara aplikasi server dan {i>database<i} meningkat. Jarang sekali disarankan untuk menjalankan aplikasi dan mendukung {i>database<i} di berbagai region. Meskipun RTO untuk {i>database<i} mungkin kurang dari 1 menit, kasus failover aplikasi mungkin memerlukan waktu beberapa menit hingga jam sebelumnya berfungsi sepenuhnya. Pada umumnya, mengeksekusi bencana lintas regional rencana failover pemulihan biasanya melibatkan proses manual karena jumlah komponen yang dipindahkan.

Pada model Silver, Anda mungkin masih melakukan periode nonaktif atau masa pemeliharaan selama aktivitas patching tiga bulanan. Memperkenalkan Oracle RAC dapat mengurangi periode nonaktif untuk patching atau kegagalan server.

Diagram berikut menunjukkan contoh konfigurasi.

Contoh konfigurasi dalam diagram menunjukkan {i>database<i} RAC yang berjalan di us-west2 dan us-east4 region. Replikasi dikonfigurasi menggunakan asinkron {i>Data Guard<i}. Semua traffic antara Solusi Bare Metal dan Google Cloud transit di Partner Interconnect dan perjalanan traffic lintas region melalui backbone jaringan Google. Server aplikasi dikonfigurasi di masing-masing tetapi biasanya dihentikan di daerah pemulihan dari bencana hingga peristiwa failover dideklarasikan.

Penonaktifan, layanan nonaktif	Jenis pemadaman	RPO	RTO
Tidak terencana	Kegagalan node atau instance yang dapat dipulihkan	0	Waktu yang diperlukan untuk memulai ulang instance Detik jika menggunakan RAC
	Bencana: korupsi	< 60 dtk	Menit hingga jam, bergantung pada failover aplikasi.
	Bencana: kegagalan perluasan wilayah	< 60 dtk	Menit hingga jam, bergantung pada failover aplikasi.
Direncanakan	Patch database, update OS / FW	0	Waktu yang diperlukan untuk mengupdate dan memulai ulang instance. Detik jika menggunakan RAC
	Upgrade database utama	0	1-2 jam Menit jika menggunakan DBMS_ROLLING untuk melakukan upgrade.

Model emas

Jika Anda khawatir tentang kehilangan data dalam model Silver, Anda dapat pilih model Gold yang menggunakan instance sinkronisasi jauh untuk menyediakan replikasi sinkron ke instance yang berjalan di Google Cloud Compute Engine.

Instance sinkronisasi jauh mencakup file kontrol database dan serangkaian pengulangan standby log yang berjalan secara geografis di dekat {i>database<i} utama. Instance ini dikonfigurasi untuk menerima pengulangan secara sinkron dengan latensi rendah yang mengizinkan semua perubahan yang akan dicatat di luar ekstensi region {i>database<i} utama. Jauh yang sama, lalu meneruskan redo ke database standby di remote region untuk diterapkan secara asinkron.

Instance sinkronisasi jauh bukan salinan lengkap dari database, sehingga tidak dapat melayani traffic aplikasi. Instance sinkronisasi jauh digunakan untuk memberikan model fault-tolerant lokasi perubahan database yang akan ditulis secara sinkron, yang memungkinkan sebuah solusi nol data hilang. Saat melakukan replikasi sinkron ke sinkronisasi jauh transaksi tidak dilakukan pada {i>database<i} utama hingga perubahan yang telah diterima dan di-commit pada instance jauh sinkronisasi.

Instance Compute Engine biasanya dipilih sebagai kandidat untuk hosting instance sinkronisasi jauh. Menempatkan instance sinkronisasi jauh di zona Compute Engine kedekatan dengan database utama menambahkan latensi minimal (biasanya di bawah 1,5 md) dan melindungi dari kegagalan dalam ekstensi region.

Diagram berikut menunjukkan contoh deployment.

Contoh konfigurasi dalam diagram menunjukkan {i>database<i} RAC utama yang berjalan di us-west2 dengan aplikasi yang berjalan di Compute Engine. Compute Engine instance dalam us-west2 menjalankan instance sinkronisasi jauh, yang menerima ulangi. Instance sinkronisasi jauh dikonfigurasi untuk mengirim pengulangan secara asinkron ke RAC database yang berjalan di region us-east4. Instance aplikasi dikonfigurasi di region us-east4 pada Compute Engine untuk menangani traffic aplikasi di terjadinya bencana.

Penonaktifan, layanan nonaktif	Jenis pemadaman	RPO	RTO
Tidak terencana	Kegagalan node atau instance yang dapat dipulihkan	0	Waktu yang diperlukan untuk memulai ulang instance Detik jika menggunakan RAC
	Bencana: korupsi	0	Menit hingga jam, bergantung pada failover regional aplikasi.
	Bencana: kegagalan perluasan wilayah	0	Menit hingga jam, bergantung pada failover regional aplikasi.
Direncanakan	Patch database, update OS / FW	0	Waktu yang diperlukan untuk mengupdate dan memulai ulang instance. Detik jika menggunakan RAC
	Upgrade database utama	0	1-2 jam Menit jika menggunakan DBMS_ROLLING untuk melakukan upgrade.

Model platinum

Model Platinum menawarkan dua opsi deployment. Setiap opsi deployment menyediakan perlindungan menggunakan teknologi yang berbeda, dan membawa RTO dan RPO yang berbeda karakteristik.

Deployment Platinum 1: Data Guard dengan failover mulai cepat

Deployment Platinum 1 dibangun berdasarkan deployment model Gold dengan menambahkan database standby Data Guard kedua di region lokal yang berjalan pada Compute Engine. Konfigurasi ini menggunakan replikasi sinkron antara database utama dan standby yang berjalan di Compute Engine, yang memberikan jaminan nol kehilangan data dalam region utama.

Dengan membuat database standby di region, Anda dapat melakukan failover dan peralihan database operasi tanpa mempengaruhi aplikasi. Selama peran database aplikasi yang dikonfigurasi sesuai dengan Pertimbangan klien Oracle secara otomatis terhubung kembali ke database utama baru tanpa yang memerlukan intervensi manual. Aplikasi yang dikonfigurasi dengan benar mengalami lebih sedikit periode nonaktif lebih dari 2 menit selama peristiwa failover.

Meskipun database standby di Compute Engine tidak menjalankan RAC, database tersebut harus berukuran untuk mendukung traffic aplikasi normal saat aplikasi berjalan sebagai di skrip untuk menyiapkan database. {i>Instance <i}ini bisa berjalan dengan bentuk yang lebih kecil sambil beroperasi sebagai standby dan meningkatkan skala selama peristiwa failover, atau berjalan dengan kapasitas penuh kali. Mengubah ukuran instance selama peristiwa failover akan berdampak negatif pada RTO, karena instance harus dimulai ulang selama operasi ubah ukuran.

Failover mulai cepat dikonfigurasi pada instance Compute Engine yang menjalankan Broker Data Guard dengan pengamat. Pengamat menjalankan klien Oracle dasar dengan koneksi ke semua database utama dan standby. Jika pengamat mendeteksi terjadi kegagalan di database utama, maka akan memulai failover ke salah satu instance {i>database<i}. Database standby yang berjalan di Compute Engine harus dan dikonfigurasi sebagai target failover pilihan saat menggunakan deployment tingkat Gold.

Oracle merekomendasikan agar observer ditempatkan di region yang terpisah dari dari database utama dan standby. Hal ini memberikan perlindungan terbaik terhadap kegagalan regional dan peristiwa partisi jaringan. Jika region ketiga tidak memungkinkan, observer harus diinstal di region utama, zona yang berbeda dari standby di dekat lokasi.

Diagram berikut menunjukkan contoh deployment.

Contoh deployment yang ditampilkan dalam diagram terdiri dari hal berikut:

• Database utama yang menjalankan RAC di server Solusi Bare Metal di us-west2 teritorial Anda.
• Database standby dekat lokasi yang berjalan di instance Compute Engine di Region us-west2.
• Database standby jarak jauh yang berjalan di server Solusi Bare Metal di us-east4 teritorial Anda.
• Observer Data Guard yang berjalan pada instance Compute Engine di us-central1 teritorial Anda.

Replikasi sinkron dikonfigurasi untuk database standby di region yang berjalan di instance Compute Engine, dan replikasi asinkron dikonfigurasi untuk daerah terpencil itu. Dalam setiap kasus, redo dikirim dari {i>database<i} utama ke standby; {i>redo<i} tidak diteruskan dari satu {i>database<i} standby ke yang lain. Tujuan observer dikonfigurasi di region ketiga dan menjaga konektivitas ke semua database dalam konfigurasi. Instance aplikasi dikonfigurasi di region utama dan terhubung ke database utama di server Solusi Bare Metal (atau database di instance Compute Engine selama failover dan peralihan operasi). Instance aplikasi dikonfigurasi di region us-east4 di Compute Engine untuk menangani traffic aplikasi jika terjadi bencana.

Penonaktifan, layanan nonaktif	Jenis pemadaman	RPO	RTO
Tidak terencana	Kegagalan node atau instance yang dapat dipulihkan	0	Waktu yang diperlukan untuk memulai ulang instance Detik jika menggunakan RAC
	Bencana: korupsi	0	< 60 dtk
	Bencana: kegagalan perluasan wilayah	0	< 60 dtk
Direncanakan	Patch database, update OS / FW	0	Waktu yang diperlukan untuk mengupdate dan memulai ulang instance. Detik jika menggunakan RAC
	Upgrade database utama	0	1-2 jam Menit jika menggunakan DBMS_ROLLING untuk melakukan upgrade.

Deployment Platinum 2: GoldenGate untuk replikasi

Deployment Platinum 2 mengandalkan penggunaan Oracle GoldenGate untuk replikasi. Sejak GoldenGate tidak bereplikasi di level blok. Ini memungkinkan setiap {i>database<i} untuk membaca dan menulis sesi aplikasi secara independen. Model ini mereplikasi berubah secara dua arah, sehingga memungkinkan terjadinya konfigurasi {i>database<i} aktif/aktif.

Permohonan harus divalidasi secara menyeluruh sebelum berkomitmen untuk deployment, dan Anda harus memperhitungkan deteksi dan resolusi konflik.

Tidak seperti Data Guard, GoldenGate memerlukan instalasi dan pemeliharaan perangkat lunak tambahan pada server {i>database<i} Oracle. Deployment aktif/aktif biasanya membutuhkan skema dan desain aplikasi yang canggih untuk memanfaatkan dari deployment database multi-situs. Banyak aplikasi pra-paket yang tidak mendukung arsitektur jenis ini.

Deployment yang bergantung pada GoldenGate untuk semua replikasi tidak dapat mendukung nilai nol RPO kehilangan data karena sifat asinkron replikasi logika. Lokal Database standby yang berjalan di Compute Engine menggunakan Data Guard dapat di-deploy untuk menyediakan RPO nol dengan replikasi sinkron.

Diagram berikut menunjukkan contoh deployment.

Penonaktifan, layanan nonaktif	Jenis pemadaman	RPO	RTO
Tidak terencana	Kegagalan node atau instance yang dapat dipulihkan	0	Waktu yang diperlukan untuk memulai ulang instance
	Bencana: korupsi	Detik ke Menit 0 jika menggunakan Data Guard di setiap lokasi	0
	Bencana: kegagalan perluasan wilayah	Detik ke Menit 0 jika menggunakan Data Guard di setiap lokasi	0
Direncanakan	Patch database, update OS / FW	0	Waktu yang diperlukan untuk mengupdate dan memulai ulang instance. Detik jika menggunakan RAC
	Upgrade database utama	0	0