프린트 하기 URL 복사

OS 환경 : Oracle Linux 9.6 (64bit)

 

DB 환경 : Oracle Database 19.28.0.0

 

방법 : 오라클 19c ADG Snapshot Standby Database

본문에서는 oracle data guard 기능 중 하나인 Snapshot Standby Database에 대해 설명하고
Physical Standby Database를 Snapshot Standby Database로 변경해보는 테스트를 진행함
참고로 본문 테스트는 Primary에는 접속하지 않고 Standby 서버에서만 작업함

 

 

Snapshot Standby Database란?
읽기와 쓰기가 모두 가능한(Fully updatable) 스탠바이 데이터베이스임
물리적 스탠바이 데이터베이스(Physical Standby Database)와 유사한 수준의 재해 복구(DR) 및 데이터 보호 이점을 제공함

 

데이터 동기화 및 동작 방식
Primary DB로부터 Redo 데이터를 수신하여 아카이브(저장)하지만, 즉시 반영(Apply)은 하지 않음
Redo 데이터 미적용 및 로컬 업데이트 발생으로 인해 시간이 지날수록 Primary DB와 데이터 불일치(Divergence)가 발생함
다시 물리적 스탠바이 데이터베이스로 변환 시, 스냅샷 상태에서 발생한 모든 로컬 업데이트 내역은 폐기됨
변환 직후 그동안 보관해둔 Redo 데이터가 일괄 적용되며 다시 Primary DB와 동기화됨

 

주요 특징
Redo 데이터는 지속적으로 수신 및 보관하므로 Primary DB의 데이터는 안전하게 보호됨
스냅샷 상태에서는 직접적인 Switchover 또는 Failover가 불가능함
역할(Role) 전환을 수행하려면 반드시 먼저 물리적 스탠바이 데이터베이스로 변환해야 함
Maximum Protection(최대 보호) Data Guard 구성에서는 유일한 스탠바이 데이터베이스로 사용할 수 없음

 

주의 사항
FRA(Fast Recovery Area) 사전 설정
Snapshot Standby Database로 전환하는 시점에 보장된 복구 지점(Guaranteed Restore Point, GRP)을 자동으로 생성함
그리고 Snapshot Standby Database에서 발생하는 모든 Read-Write 변경 사항(DML/DDL)이 Flashback Log(FRA)에 저장됨
그렇기 때문에 테스트 중 변경량이 많거나 운영 기간이 길어지면 FRA 용량 부족(Full)이 날수 있고 이로인해 DB가 행이 걸릴수 있음
FRA 설정을 위해선 db_recovery_file_dest와 db_recovery_file_dest_size 파라미터를 설정 해주어야함
본문에선 +DATA에 20gb를 설정해놓음

 

 

테스트
현재 db는 adg로 구축되어 있는 상태임
참고 : 오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드 ( https://positivemh.tistory.com/1391 )

 

 

FRA(Fast Recovery Area) 설정 확인

1
2
3
4
5
6
SQL> show parameter db_recovery_file_dest
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      +DATA
db_recovery_file_dest_size           big integer 20G

20gb 설정되어 있음

 

 

현재 db role 확인

1
2
3
4
5
6
7
SQL>
set lines 200 pages 1000
select db_unique_name, open_mode, database_role, switchover_status, dataguard_broker broker from v$database;
 
DB_UNIQUE_NAME                 OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS    BROKER
------------------------------ -------------------- ---------------- -------------------- --------
oracle19stb                    READ ONLY            PHYSICAL STANDBY TO PRIMARY           DISABLED

현재 physical standby임

 

 

mrp 중지

1
2
3
4
5
6
7
SQL> alter database recover managed standby database cancel;
 
Database altered.
 
SQL> alter database convert to snapshot standby;
 
Database altered.

 

 

Snapshot Standby Database로 convert시 alert log 분석

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
2026-06-13T22:50:18.576264+09:00
alter database convert to snapshot standby
2026-06-13T22:50:18.632200+09:00
DBWPreopen slv 0 open list size=1 successful=0
DBWPreopen slv 1 open list size=1 successful=0
DBWPreopen slv 2 open list size=1 successful=0
DBWPreopen slv 3 open list size=1 successful=0
DBWPreopen total open count=5 shared=0 BG-shared=0 at t=0s
Starting background process RVWR
2026-06-13T22:50:18.657930+09:00
RVWR started with pid=52, OS id=47292
2026-06-13T22:50:19.627478+09:00
Already allocated 8384512 bytes in shared pool for flashback generation buffer.
2026-06-13T22:50:19.718617+09:00
DBWPreopen slv 0 open list size=1 successful=0
DBWPreopen slv 1 open list size=1 successful=0
DBWPreopen slv 2 open list size=1 successful=0
DBWPreopen slv 3 open list size=1 successful=0
DBWPreopen total open count=5 shared=0 BG-shared=0 at t=0s
2026-06-13T22:50:19.751725+09:00
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_06/13/2026 22:50:18
.... (PID:46879): Killing 2 processes (PIDS:47055,47057) (all RFS) in order to disallow current and future RFS connections. Requested by OS process 46879
2026-06-13T22:50:19.752628+09:00
Process termination requested for pid 47055 [source = rdbms], [info = 2] [request issued by pid: 46879, uid: 54321]
2026-06-13T22:50:19.752663+09:00
Process termination requested for pid 47057 [source = rdbms], [info = 2] [request issued by pid: 46879, uid: 54321]
2026-06-13T22:50:19.775749+09:00
.... (PID:46879): DBROLE: Converted    to a SNAPSHOT   at [kcvs.c:3410]
.... (PID:46879): Begin: SRL archival
.... (PID:46879): End: SRL archival
2026-06-13T22:50:19.792615+09:00
DBWPreopen slv 0 open list size=1 successful=0
DBWPreopen slv 1 open list size=1 successful=0
DBWPreopen slv 2 open list size=1 successful=0
DBWPreopen slv 3 open list size=1 successful=0
DBWPreopen total open count=5 shared=0 BG-shared=0 at t=0s
2026-06-13T22:50:19.801697+09:00
RESETLOGS after complete recovery through change 2041743
2026-06-13T22:50:19.804326+09:00
.... (PID:46879): Waiting for all non-current ORLs to be archived
2026-06-13T22:50:19.804422+09:00
.... (PID:46879): All non-current ORLs have been archived
.... (PID:46879): Clearing online redo logfile 1 +DATA/ORACLE19STB/ONLINELOG/group_1.262.1235424371
Clearing online log 1 of thread 1 sequence number 1
2026-06-13T22:50:22.487804+09:00
.... (PID:46879): Clearing online redo logfile 1 complete
Online log +DATA/ORACLE19STB/ONLINELOG/group_1.262.1235424371: Thread 1 Group 1 was previously cleared
Online log +DATA/ORACLE19STB/ONLINELOG/group_2.263.1235424371: Thread 1 Group 2 was previously cleared
Online log +DATA/ORACLE19STB/ONLINELOG/group_3.264.1235424371: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 2041741
2026-06-13T22:50:23.030034+09:00
Setting recovery target incarnation to 4
2026-06-13T22:50:23.043306+09:00
.... (PID:46879): RT_PMODE: SNAPSHOT           mounting with mode MAXIMUM PERFORMANCE  level NO PROTECTION
.... (PID:46879): Redo network throttle feature is disabled at mount time
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: alter database convert to snapshot standby

로그 설명 :
alter database convert to snapshot standby : 스냅샷 스탠바이로의 변환 명령어가 실행됨
DBWPreopen slv ... : Database Writer(DBW) 슬레이브 프로세스들이 데이터 파일을 사전에 열기(Preopen) 위해 실행됨
Starting background process RVWR : Recovery Writer(RVWR) 백그라운드 프로세스가 시작됨 (추후 물리적 스탠바이로 되돌릴 때 Flashback Database 기능을 사용해야 하므로, 변경 사항을 FRA의 Flashback Log에 기록하기 위함)
Already allocated ... in shared pool for flashback generation buffer. : Shared Pool 메모리 영역에 Flashback 데이터를 생성하고 버퍼링하기 위한 공간이 할당됨
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_... : 나중에 물리적 스탠바이 데이터베이스로 다시 돌아오기 위해, 현재 시점의 보장된 복원 지점(Guaranteed Restore Point)을 자동으로 생성함
Killing 2 processes (all RFS) in order to disallow current and future RFS connections : Primary DB로부터 수신한 Redo 데이터를 더 이상 직접 반영(Apply)하지 않도록, RFS(Remote File Server) 프로세스를 강제로 종료하고 향후 접속을 차단함
DBROLE: Converted to a SNAPSHOT : 데이터베이스의 역할(Role)이 스냅샷 스탠바이로 변경됨
Begin: SRL archival / End: SRL archival : 기존에 수신 중이던 Standby Redo Log(SRL)의 아카이빙 작업을 마무리함
RESETLOGS after complete recovery ... : 데이터베이스를 읽기/쓰기가 가능한 상태로 열기 위해, 이전까지의 복구를 마치고 resetlogs를 수행하여 새로운 Incarnation을 시작함
Clearing online redo logfile ... : 새롭게 쓰기 작업을 처리하기 위해 내부 Online Redo Log 파일들을 초기화(Clear)함
Standby became primary SCN: 2041741 : 데이터베이스가 내부적으로는 읽고 쓸 수 있는 Primary 역할을 수행하기 시작함
Setting recovery target incarnation to 4 : 데이터베이스의 Incarnation이 새로운 번호(4)로 설정됨
RT_PMODE: SNAPSHOT mounting with mode MAXIMUM PERFORMANCE level NO PROTECTION : Primary DB와의 데이터 동기화(Apply)가 중단된 상태이므로, 데이터베이스 보호 모드가 일시적으로 가장 낮은 단계인 Maximum Performance (No Protection)로 전환됨
CONVERT TO SNAPSHOT STANDBY: Complete : 스냅샷 스탠바이 데이터베이스로의 변환 및 마운트 작업이 완료됨

 

 

db open 상태로 변경

1
2
3
SQL> alter database open read write;
 
Database altered.

정상적으로 기동됨

 

 

전환 후 db role 확인

1
2
3
4
5
6
7
SQL>
set lines 200 pages 1000
select db_unique_name, open_mode, database_role, switchover_status, dataguard_broker broker from v$database;
 
DB_UNIQUE_NAME                 OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS    BROKER
------------------------------ -------------------- ---------------- -------------------- --------
oracle19stb                    READ WRITE           SNAPSHOT STANDBY NOT ALLOWED          DISABLED

정상적으로 snapshot database로 변환됨

 

 

incarnation 및 resetlogs_change# 확인

1
2
3
4
5
6
7
8
9
10
SQL> 
alter session set nls_date_format = 'yyyy/mm/dd hh24:mi:ss';
select * from v$database_incarnation;
 
INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME      PRIOR_RESETLOGS_CHANGE# PRIOR_RESETLOGS_TIM STATUS  RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED     CON_ID
------------ ----------------- ------------------- ----------------------- ------------------- ------- ------------ ------------------ -------------------------- ----------
           1                 1 2025/12/21 15:39:14                       0                     PARENT    1220456354                  0 YES                             0
           2           1539601 2026/06/08 21:28:54                       1 2025/12/21 15:39:14 ORPHAN    1235424534                  1 NO                              0
           3           2041744 2026/06/13 22:48:21                       1 2025/12/21 15:39:14 ORPHAN    1235861301                  1 YES                             0
           4           2041744 2026/06/13 22:50:19                       1 2025/12/21 15:39:14 CURRENT   1235861419                  1 YES                             0

이전에 테스트 했을때 남은 기록이 incarnation 2, 3 이고
지금 snapshot database로 전환한 이후 남은 기록이 incarnation 4임
resetlogs로 open 되었기 때문에 새로운 incarnation을 할당 받고 새로운 resetlogs_change#를 할당 받음

 

 

아카이브 갭 등 정상여부 확인

1
2
3
4
5
6
7
8
9
10
11
SQL>
set lines 200 pages 1000
select dest_id, db_unique_name, status, database_mode, recovery_mode, db_unique_name, gap_status 
from v$archive_dest_status 
where dest_id <=2 
order by 1,2;
 
   DEST_ID DB_UNIQUE_NAME                 STATUS    DATABASE_MODE   RECOVERY_MODE                      DB_UNIQUE_NAME                 GAP_STATUS
---------- ------------------------------ --------- --------------- ---------------------------------- ------------------------------ ------------------------
         1 oracle19stb                    VALID     OPEN            IDLE                               oracle19stb
         2 oracle19                       VALID     UNKNOWN         IDLE                               oracle19                       NO GAP

Snapshot Database이기 떄문에 RECOVERY_MODE가 IDLE로 표시됨

 

 

변환후에는 dml 및 로그스위치 등을 자유롭게 사용할 수 있음

1
2
3
4
5
6
7
8
9
10
11
12
13
SQL> create table test as select * from dba_objects;
 
Table created.
 
SQL> select count(*) from test;
 
  COUNT(*)
----------
     64502
 
SQL> alter system switch logfile;
 
System altered.

잘됨

 

 

alert log에도 log switch 기록이 남음

1
2
3
4
5
6
$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
2026-06-13T23:03:18.231584+09:00
Thread 1 advanced to log sequence 2 (LGWR switch),  current SCN: 2043707
  Current log# 2 seq# 2 mem# 0: +DATA/ORACLE19STB/ONLINELOG/group_2.263.1235424371
2026-06-13T23:03:18.662602+09:00
ARC1 (PID:46885): Archived Log entry 6 added for B-1235861419.T-1.S-1 LOS:0x00000000001f2790 NXS:0x00000000001f2f3b NAB:97224 ID 0xcb9d07ca LAD:1

 

 

다시 Physical Standby Database로 변환

 

 

먼저 shutdown 후 mount 모드로 기동

1
2
SQL> shutdown immediate
SQL> startup mount

 

 

Physical Standby Database로 변환

1
2
3
SQL> alter database convert to physical standby;
 
Database altered.

 

 

Physical Standby Database로 convert시 alert log 분석

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
2026-06-13T23:11:46.787164+09:00
alter database convert to physical standby
2026-06-13T23:11:46.787430+09:00
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (oracle19stb)
2026-06-13T23:11:46.796433+09:00
.... (PID:59761): Killing 2 processes (PIDS:59793,59795) (all RFS) in order to disallow current and future RFS connections. Requested by OS process 59761
2026-06-13T23:11:46.796960+09:00
Process termination requested for pid 59795 [source = rdbms], [info = 2] [request issued by pid: 59761, uid: 54321]
2026-06-13T23:11:46.797050+09:00
Process termination requested for pid 59793 [source = rdbms], [info = 2] [request issued by pid: 59761, uid: 54321]
2026-06-13T23:11:48.799286+09:00
 downstream capture: turning off downstream_real_time_mine
2026-06-13T23:11:48.955287+09:00
DBWPreopen slv 0 open list size=1 successful=0
DBWPreopen slv 1 open list size=1 successful=0
DBWPreopen slv 2 open list size=1 successful=0
DBWPreopen slv 3 open list size=1 successful=0
DBWPreopen total open count=5 shared=0 BG-shared=0 at t=0s
2026-06-13T23:11:49.087244+09:00
Flashback Restore Start
2026-06-13T23:11:50.462488+09:00
Flashback Restore Complete
2026-06-13T23:11:50.514653+09:00
DBWPreopen slv 0 open list size=1 successful=0
DBWPreopen slv 1 open list size=1 successful=0
DBWPreopen slv 2 open list size=1 successful=0
DBWPreopen slv 3 open list size=1 successful=0
DBWPreopen total open count=4 shared=0 BG-shared=0 at t=0s
2026-06-13T23:11:50.535078+09:00
Drop guaranteed restore point
Stopping background process RVWR
Deleted Oracle managed file +DATA/ORACLE19STB/FLASHBACK/log_1.269.1235861419
2026-06-13T23:11:51.645132+09:00
Deleted Oracle managed file +DATA/ORACLE19STB/FLASHBACK/log_2.270.1235861423
Guaranteed restore point  dropped
Clearing standby activation ID 3416065994 (0xcb9d07ca)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 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 209715200;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 209715200;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 209715200;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 209715200;
2026-06-13T23:11:51.653919+09:00
.... (PID:59761): DBROLE: Converted    to a PHYSICAL   at [kcvs.c:9257]
.... (PID:59761): RT_PMODE: PHYSICAL           mounting with mode MAXIMUM PERFORMANCE  level NO PROTECTION
.... (PID:59761): RT: Role transition work is not done
.... (PID:59761): Redo network throttle feature is disabled at mount time
Physical Standby Database mounted.
2026-06-13T23:11:51.679491+09:00
In-memory operation on ADG is currently only supported on Engineered systems and PaaS.
inmemory_adg_enabled is turned off automatically.
Please contact our support team for EXADATA solutions
CONVERT TO PHYSICAL STANDBY: Complete - Database mounted as physical standby
Completed: alter database convert to physical standby
2026-06-13T23:11:52.041694+09:00
 rfs (PID:60033): krsr_rfs_atc: Identified database type as 'PHYSICAL': Client is Foreground (PID:2677)

로그 설명 :
alter database convert to physical standby : 물리적 스탠바이 데이터베이스(Physical Standby Database)로의 변환 명령어가 실행됨
Killing 2 processes (all RFS) in order to disallow current and future RFS connections : 변환 작업을 안전하게 수행하기 위해, 기존에 연결되어 있던 RFS(Remote File Server) 프로세스를 강제 종료하고 새로운 접속을 일시적으로 차단함
downstream capture: turning off downstream_real_time_mine : 데이터베이스 내부의 마이닝 및 캡처 관련 프로세스를 일시 중지함
DBWPreopen slv ... : Database Writer(DBW) 슬레이브 프로세스들이 데이터 파일을 사전에 열기(Preopen) 위해 실행됨
Flashback Restore Start : 스냅샷 스탠바이로 전환할 때 생성해두었던 보장된 복원 지점(Guaranteed Restore Point)으로 되돌리기 위한 Flashback Database 작업이 시작됨 (이 과정에서 스냅샷 상태일 때 발생한 모든 로컬 변경 사항이 폐기됨)
Flashback Restore Complete : Flashback 복원 작업이 완료되어, 데이터베이스가 원래의 물리적 스탠바이 시점으로 되돌아감
Drop guaranteed restore point : 복원이 완료되었으므로, 더 이상 필요 없는 보장된 복원 지점을 삭제함
Stopping background process RVWR : Flashback 데이터 기록을 담당하던 Recovery Writer(RVWR) 백그라운드 프로세스를 종료함
Deleted Oracle managed file .../FLASHBACK/... : 복원 지점이 삭제됨에 따라 해당 시점을 유지하기 위해 사용되었던 FRA 내의 Flashback Log 파일들이 삭제됨
Clearing standby activation ID ... : 스냅샷 스탠바이 상태에서 사용하던 독립적인 데이터베이스 활성화 ID(Activation ID)를 초기화함
The primary database controlfile was created using the... (안내 메시지) : Primary DB와 구성(Standby Redo Log 등)을 맞추기 위해 필요한 권장 SQL 명령어를 정보성으로 안내해 줌
DBROLE: Converted to a PHYSICAL : 데이터베이스의 역할(Role)이 다시 물리적 스탠바이(Physical Standby)로 변경됨
RT_PMODE: PHYSICAL mounting with mode MAXIMUM PERFORMANCE level NO PROTECTION : 물리적 스탠바이 역할로서 데이터베이스 보호 모드를 설정하며 마운트 단계를 진행함
Physical Standby Database mounted. : 물리적 스탠바이 상태로 데이터베이스가 마운트됨
CONVERT TO PHYSICAL STANDBY: Complete : 물리적 스탠바이 데이터베이스로의 변환 작업이 모두 성공적으로 완료됨
rfs (PID:...): krsr_rfs_atc: Identified database type as 'PHYSICAL' : RFS 프로세스가 새롭게 시작되어 현재 데이터베이스가 물리적 스탠바이임을 정상적으로 인식하고, Primary DB로부터 다시 Redo 데이터를 수신할 준비를 함

 

 

db 기동

1
2
3
SQL> alter database open;
 
Database altered.

정상적으로 기동됨

 

 

mrp 기동

1
2
3
SQL> alter database recover managed standby database disconnect from session;
 
Database altered.

 

 

전환 후 db role 확인

1
2
3
4
5
6
7
SQL>
set lines 200 pages 1000
select db_unique_name, open_mode, database_role, switchover_status, dataguard_broker broker from v$database;
 
DB_UNIQUE_NAME                 OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS    BROKER
------------------------------ -------------------- ---------------- -------------------- --------
oracle19stb                    READ ONLY            PHYSICAL STANDBY TO PRIMARY           DISABLED

정상적으로 physical standby로 변환됨

 

 

incarnation 및 resetlogs_change# 확인

1
2
3
4
5
6
7
8
9
10
SQL> 
alter session set nls_date_format = 'yyyy/mm/dd hh24:mi:ss';
select * from v$database_incarnation;
 
INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME      PRIOR_RESETLOGS_CHANGE# PRIOR_RESETLOGS_TIM STATUS  RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED     CON_ID
------------ ----------------- ------------------- ----------------------- ------------------- ------- ------------ ------------------ -------------------------- ----------
           1                 1 2025/12/21 15:39:14                       0                     CURRENT   1220456354                  0 NO                              0
           2           1539601 2026/06/08 21:28:54                       1 2025/12/21 15:39:14 ORPHAN    1235424534                  1 NO                              0
           3           2041744 2026/06/13 22:48:21                       1 2025/12/21 15:39:14 ORPHAN    1235861301                  1 NO                              0
           4           2041744 2026/06/13 22:50:19                       1 2025/12/21 15:39:14 ORPHAN    1235861419                  1 NO                              0

incarnation 4도 ORPHAN(고아) 상태가됨
incarnation 1이 CURRENT가 됨

 

 

아카이브 갭 등 정상여부 확인

1
2
3
4
5
6
7
8
9
10
11
SQL>
set lines 200 pages 1000
select dest_id, db_unique_name, status, database_mode, recovery_mode, db_unique_name, gap_status 
from v$archive_dest_status 
where dest_id <=2 
order by 1,2;
 
   DEST_ID DB_UNIQUE_NAME                 STATUS    DATABASE_MODE   RECOVERY_MODE                      DB_UNIQUE_NAME                 GAP_STATUS
---------- ------------------------------ --------- --------------- ---------------------------------- ------------------------------ ------------------------
         1 oracle19stb                    VALID     OPEN_READ-ONLY  MANAGED REAL TIME APPLY            oracle19stb
         2 oracle19                       VALID     UNKNOWN         IDLE                               oracle19

다시 RECOVERY_MODE가 MANAGED REAL TIME APPLY로 변경됨

 

 

결론 :
오라클 Data Guard의 Snapshot Standby Database 기능을 이용해 Standby db에도 dml을 수행할 수 있음
read write가 허용된 상태에서 운영환경과 동일한 데이터로 개발자들이 테스트를 한다거나 배치 수행 및 분석등을 해볼 수 있음
참고로 Snapshot Standby Database 기능의 라이센스는 SE에선 불가하고 EE 환경은 무료로 사용 가능함
Table 1-4 High Availability 섹션의 Oracle Data Guard—Snapshot Standby 부분 참고
참고 : https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-F796455D-C7EF-4836-9F69-2BCCDA49B7BD

 

 

참조 : 

오라클 19c rman incarnation 설명 및 복구 시나리오 ( https://positivemh.tistory.com/697 )
오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드 ( https://positivemh.tistory.com/1391 )
오라클 19c ADG Gap 발생시 rman duplicate 재수행 복구 시나리오 ( https://positivemh.tistory.com/1392 )
오라클 19c ADG Gap 발생시 rman 증분백업이용 복구 시나리오 ( https://positivemh.tistory.com/1394 )
오라클 19c ADG 구성 중 db_file_name_convert, log_file_name_convert 파라미터 테스트 ( https://positivemh.tistory.com/1396 )
https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-physical-standby-databases.html
https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-physical-standby-databases.html#GUID-0682EE24-B495-48E8-9E1F-52AC0E6FE486
https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-physical-standby-databases.html#GUID-63245504-B67C-4DF2-B8E5-752C0A67FEE7
https://docs.oracle.com/en/database/oracle/oracle-database/26/dbiad/db_RVWR.html
https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/background-processes.html
https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-F796455D-C7EF-4836-9F69-2BCCDA49B7BD

저작자표시 (새창열림)

'ORACLE > Admin' 카테고리의 다른 글

오라클 19c ADG 구성 중 db_file_name_convert, log_file_name_convert 파라미터 테스트  (0) 2026.06.12
오라클 19c ADG Gap 발생시 rman 증분백업이용 복구 시나리오  (0) 2026.06.11
오라클 19c ADG Gap 발생시 rman duplicate 재수행 복구 시나리오  (0) 2026.06.08
오라클 19c ACFS 경로 변경 테스트  (0) 2026.06.06
오라클 19c ACFS 구성 테스트  (0) 2026.06.06

티스토리툴바