Oracle Snapshot Standby, sebuah fitur dari perangkat lunak Data Guard Oracle, memungkinkan konversi sementara database standby fisik menjadi snapshot standby untuk operasi baca-tulis. Sangat ideal untuk pengujian tanpa risiko, fitur ini dapat dikembalikan ke database standby fisik, menghilangkan semua perubahan dan melanjutkan aplikasi data redo.
Updated by Zahiyah on 2025/08/18
Data Guard Oracle 11g membawa kita tidak hanya fitur luar biasa berupa query waktu nyata melalui Active Data Guard tetapi juga keistimewaan tambahan yang dikenal sebagai fungsionalitas database cadangan snapshot (snapshot standby database). Fungsionalitas ini memungkinkan database cadangan ditempatkan dalam mode "baca-tulis", berfungsi sebagai lingkungan untuk keperluan pengujian yang mungkin kurang nyaman dilakukan secara langsung pada database utama produksi, seperti mensimulasikan penyebaran daring dan tugas-tugas lainnya. Setelah tugas selesai dilakukan dalam keadaan baca-tulis, akan sangat mudah untuk mengembalikan peran database cadangan snapshot tersebut ke peran database cadangannya semula, melanjutkan sinkronisasi dengan database utama. Dalam keadaan database cadangan snapshot, database ini tetap dapat menerima log dari database utama, namun perubahan tersebut tidak dapat diterapkan ke database cadangan.
Jika database standby saat ini sedang menjalankan prosedur Redo Apply, maka perlu untuk menghentikannya terlebih dahulu.
sys@ora11gdg> alter database recover managed standby database cancel; Database altered.
sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE PHYSICAL STANDBY MOUNTED
Pada saat ini, standby database berperan sebagai standby fisik dan berjalan dalam mode MOUNTED.
Pengingat: Mengaktifkan fungsi basis data cadangan cuplikan (Snapshot Standby) tidak memerlukan pengaktifan fitur Flashback Database pada kedua basis data utama dan cadangan. Hal ini tidak tergantung apakah fitur flashback database diaktifkan atau tidak.
sys@ora11gdg> show parameter db_recovery_file_dest NAME TYPE VALUE db_recovery_file_dest string /u01/app/oracle/flash_recovery_area db_recovery_file_dest_size big integer 3852M
Pastikan fitur flashback tidak diaktifkan pada database utama.
sys@ora11g> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
Pastikan bahwa fitur flashback tidak diaktifkan pada database cadangan.
Sebuah database baru yang dapat dibaca dan ditulis terbentang di depan kita.
Log alert database utama untuk Oracle 11g:
Mon Mar 19 18:46:28 2012 LNS: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135) LNS: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact Error 3135 for archive log file 2 to 'ora11gdg' Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact LNS: Failed to archive log 2 thread 1 sequence 50 (3135) Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact
Log alert standby database untuk Oracle 11g:
Mon Mar 19 18:46:26 2012 alter database convert to snapshot standby Starting background process RVWR Mon Mar 19 18:46:26 2012 RVWR started with pid=26, OS id=8824 Allocated 3981204 bytes in shared pool for flashback generation buffer Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26 krsv_proc_kill: Killing 3 processes (all RFS) Begin: Standby Redo Logfile archival End: Standby Redo Logfile archival RESETLOGS after complete recovery through change 1472476 Resetting resetlogs activation ID 4174194338 (0xf8cd26a2) Online log /u01/app/oracle/oradata/ora11gdg/redo01.log: Thread 1 Group 1 was previously cleared Online log /u01/app/oracle/oradata/ora11gdg/redo02.log: Thread 1 Group 2 was previously cleared Online log /u01/app/oracle/oradata/ora11gdg/redo03.log: Thread 1 Group 3 was previously cleared Standby became primary SCN: 1472474 Mon Mar 19 18:46:29 2012 Setting recovery target incarnation to 5 CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby Completed: alter database convert to snapshot standby
Baris informasi penting menyatakan, "Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26." Ini menunjukkan saat di mana kita berubah menjadi snapshot, memungkinkan pengembalian ke keadaan sebelumnya.
Bahkan ketika database utama melakukan pergantian log, database standby terus menerima log tersebut, meskipun tidak menerapkannya.
1) Aktifkan log pada basis data primer.
sys@ora11g> alter system switch logfile; System altered.
2) Konten log peringatan yang dicatat oleh basis data utama
Log peringatan basis data utama untuk Oracle 11g:
Mon Mar 19 18:52:00 2012 Thread 1 cannot allocate new log, sequence 52 Private strand flush not complete Current log# 3 seq# 51 mem# 0: /u01/app/oracle/oradata/ora11g/redo03.log Mon Mar 19 18:52:00 2012 ARC3: Standby redo logfile selected for thread 1 sequence 50 for destination LOG_ARCHIVE_DEST_2 Thread 1 advanced to log sequence 52 (LGWR switch) Current log# 1 seq# 52 mem# 0: /u01/app/oracle/oradata/ora11g/redo01.log Mon Mar 19 18:52:03 2012 Archived Log entry 91 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1: Mon Mar 19 18:52:03 2012 LNS: Standby redo logfile selected for thread 1 sequence 51 for destination LOG_ARCHIVE_DEST_2 LNS: Standby redo logfile selected for thread 1 sequence 52 for destination LOG_ARCHIVE_DEST_2
Log alert database cadangan untuk Oracle 11g:
Mon Mar 19 18:52:00 2012 RFS[5]: Assigned to RFS process 9174 RFS[5]: Identified database type as 'snapshot standby': Client is ARCH pid 27296 Mon Mar 19 18:52:00 2012 RFS[6]: Assigned to RFS process 9176 RFS[6]: Identified database type as 'snapshot standby': Client is ARCH pid 27300 RFS[6]: Selected log 4 for thread 1 sequence 50 dbid -120744030 branch 778023141 Mon Mar 19 18:52:00 2012 Archived Log entry 47 added for thread 1 sequence 50 ID 0xf8cd26a2 dest 1: Mon Mar 19 18:52:03 2012 RFS[7]: Assigned to RFS process 9180 RFS[7]: Identified database type as 'snapshot standby': Client is LGWR ASYNC pid 27302 RFS[7]: Selected log 4 for thread 1 sequence 51 dbid -120744030 branch 778023141 Mon Mar 19 18:52:04 2012 Archived Log entry 48 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1: RFS[7]: Selected log 4 for thread 1 sequence 52 dbid -120744030 branch 778023141
3) Memeriksa konten file log di direktori arsip basis data primer dan sekunder
(1) Arsipkan file log dari basis data utama:
ora11g@secdb /home/oracle/arch/ora11g$ ls -ltr total 879M ...omitted... -rw-r----- 1 oracle oinstall 1.1M Mar 19 18:51 1_50_778023141.arc -rw-r----- 1 oracle oinstall 363K Mar 19 18:52 1_51_778023141.arc
(2) Arsipkan file log dari database standby:
ora11g@secdb /home/oracle/arch/ora11gdg$ ls -ltr total 847M ...omitted... -rw-r----- 1 oracle oinstall 1.1M Mar 19 18:52 1_50_778023141.arc -rw-r----- 1 oracle oinstall 363K Mar 19 18:52 1_51_778023141.arc
Sebagaimana terlihat, database standby telah berhasil menerima file log yang dikirim dari database utama.
sys@ora11gdg> create user ocmu identified by ocmu;
User created.
secooler@ora11gdg> grant dba to ocmu;
Grant succeeded.
secooler@ora11gdg> conn ocmu/ocmu
Connected.
ocmu@ora11gdg> create table t (x varchar2(8));
Table created.
ocmu@ora11gdg> insert into t values ('Secooler');
1 row created.
ocmu@ora11gdg> commit;
Commit complete.
ocmu@ora11gdg> select * from t;
X
SecoolerPada saat ini, basis data siaga berada dalam keadaan yang dapat dimodifikasi dan disesuaikan, yang sesuai dengan mode "BACA/TULIS" yang diinginkan.
Perlu dicatat bahwa implementasi fungsi database Snapshot Standby secara mendasar berbasis pada prinsip data flashback. Oleh karena itu, setiap tindakan yang berpotensi menghambat kemampuan untuk melakukan flashback database harus dihindari di sini. Jika tidak, database standby snapshot tidak akan mampu kembali ke status pemulihan standby sebelumnya.
1) Mulai ulang standby database ke keadaan MOUNTED.
ocmu@ora11gdg> conn / as sysdba Connected. sys@ora11gdg> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. sys@ora11gdg> startup mount ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1336232 bytes Variable Size 268438616 bytes Database Buffers 37748736 bytes Redo Buffers 6336512 bytes Database mounted. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE SNAPSHOT STANDBY MOUNTED
2) Jalankan perintah untuk memulihkan identitas asli database standby fisik.
sys@ora11gdg> alter database convert to physical standby; Database altered.
3) Log peringatan dari database cadangan secara cermat mendokumentasikan proses transisi ini.
Mon Mar 19 19:30:24 2012 alter database convert to physical standby ALTER DATABASE CONVERT TO PHYSICAL STANDBY (ora11gdg) Flashback Restore Start Flashback Restore Complete Stopping background process RVWR Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg3n2jc_.flb Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg52yst_.flb Guaranteed restore point dropped Clearing standby activation ID 4174523254 (0xf8d22b76) The primary database controlfile was created using the 'MAXLOGFILES 30' clause. There is space for up to 27 standby redo logfiles Use the following SQL commands on the standby database to create standby redo logfiles that match the primary database: ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800; Completed: alter database convert to physical standby
Dari log peringatan, dapat disimpulkan bahwa metode pemulihan menggunakan fitur Flashback Database. Ini menunjukkan bahwa meskipun database cadangan tidak dijalankan dalam mode flashback database, transisi peran database cadangan tetap dapat dilakukan dengan menggunakan fungsi Flashback Database.
4) Mulai ulang database siaga dalam mode pemulihan log otomatis.
(1) Pada titik ini, basis data berada dalam keadaan NOMOUNTED dan perlu dimulai ulang.
Harap dicatat bahwa hal ini memerlukan restart database alih-alih menggunakan perintah ALTER, jika tidak pesan kesalahan berikut akan muncul:
sys@ora11gdg> alter database mount; alter database mount l ERROR at line 1: ORA-00750: database has been previously mounted and dismounted sys@ora11gdg> shutdown immediate; ORA-01507: database not mounted ORACLE instance shut down. sys@ora11gdg> startup mount; ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1336232 bytes Variable Size 268438616 bytes Database Buffers 37748736 bytes Redo Buffers 6336512 bytes Database mounted. sys@ora11gdg> alter database recover managed standby database disconnect; Database altered.
(2) Dengan memeriksa log peringatan database cadangan, proses pemulihan dapat diamati dengan jelas.
Mon Mar 19 19:43:48 2012 Managed Standby Recovery not using Real Time Apply Parallel Media Recovery started with 4 slaves Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Clearing online redo logfile 1 /u01/app/oracle/oradata/ora11gdg/redo01.log Clearing online log 1 of thread 1 sequence number 1 Completed: alter database recover managed standby database disconnect Clearing online redo logfile 1 complete Clearing online redo logfile 2 /u01/app/oracle/oradata/ora11gdg/redo02.log Clearing online log 2 of thread 1 sequence number 2 Clearing online redo logfile 2 complete Media Recovery Log /home/oracle/arch/ora11gdg/1_49_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_50_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_51_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_52_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_53_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_54_778023141.arc Media Recovery Waiting for thread 1 sequence 55
(3) Pantau status aplikasi log dengan memeriksa tampilan performa dinamis V$ARCHIVED_LOG.
sys@ora11gdg> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#; SEQUENCE# FIRST_TIME NEXT_TIME APPLIED ...omitted... 49 20120319 18:32:32 20120319 18:38:03 YES 50 20120319 18:38:03 20120319 18:51:00 YES 51 20120319 18:51:00 20120319 18:52:03 YES 52 20120319 18:52:03 20120319 19:09:57 YES 53 20120319 19:09:57 20120319 19:10:15 YES 54 20120319 19:10:15 20120319 19:10:25 YES 52 rows selected.
sys@ora11gdg> alter database recover managed standby database cancel; Database altered. sys@ora11gdg> alter database open read only; Database altered. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE PHYSICAL STANDBY READ ONLY sys@ora11gdg> select username from dba_users where username = 'OCMU'; no rows selected
Kesimpulan telah dikonfirmasi bahwa pengguna uji "OCMU" yang sebelumnya dibuat tidak ada.
Oracle Snapshot Standby sangat berguna untuk tujuan pengujian. Namun, untuk lebih melindungi lingkungan basis data Anda, disarankan untuk mencadangkan basis data Oracle Anda dengan solusi pencadangan dan pemulihan bencana profesional.
Vinchin Backup & Recovery menyediakan fungsi yang kuat untuk melindungi basis data Anda baik di mesin virtual maupun server fisik, dengan cara yang sangat otomatis, fleksibel, dan efisien. Vinchin Backup & Recovery menyediakan perlindungan multi-tipe basis data untuk Oracle DB, MySQL, SQL Server, Postgres Pro dan MariaDB, mendukung kompresi basis data, manajemen terpusat pekerjaan, strategi cadangan yang cerdas, pencadangan basis data secara aktif (hot database backup), serta dukungan lanjutan untuk SQL Server/Oracle. Selain itu, Vinchin Backup & Recovery juga mendukung fitur perlindungan yang kuat terhadap ransomware dan migrasi V2V di lebih dari 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 sesuai dengan lingkungan TI Anda.
Fitur luar biasa dari "Snapshot Standby database" memungkinkan database cadangan sementara berubah menjadi database independen yang dapat dibaca dan ditulis. Hal ini secara signifikan memperluas kemungkinan pemanfaatan database cadangan. Dengan memanfaatkan fungsi khusus ini pada database cadangan, Anda dapat secara aman melakukan pengujian serta mereproduksi masalah yang mungkin berisiko untuk disimulasikan dan direproduksi dalam lingkungan produksi. Setelah pengujian selesai, Anda dapat mengembalikan identitasnya sebagai database standby fisik dan melanjutkan dengan pemulihan log.
Bagikan di:
