내맘대로긍정

오라클 19c 병렬 itas를 이용한 clustering factor 개선 테스트

내맘대로긍정 — Wed, 17 Jun 2026 20:05:52 +0900

OS 환경 : Oracle Linux 8.7 (64bit)

DB 환경 : Oracle Database 19.27.0.0

방법 : 오라클 19c 병렬 itas를 이용한 clustering factor 개선 테스트

오라클에서 인덱스의 clustering factor를 향상 시키기 위해 테이블을 재생성 한뒤
order by를 포함한 itas를 수행해 데이터를 다시 넣는 경우가 있음(insert into 테이블신규 select * from 테이블원본 방식)
본문에서는 이때 속도를 빠르게 하기 위해 parallel 병렬 기능을 사용하여 clustering factor에 영향이 있는지를 확인해봄
구체적으로 itas중 select 구문에만 parallel을 넣어보기도 하고 insert 구문과 select 구문에 모두 parallel을 넣어보면서 확인해봄

참고로 parallel 작업을 수행하게되면 parallel 할당수 만큼 병렬 프로세스가 생김
그리고 order by등 정렬 작업을 사용한 경우에는 parallel 할당수 * 2만큼의 병렬 프로세스가 생김
이때 데이터가 정렬되어야 하는 경우에는 실행계획에 PX SEND QC (ORDER)와 같이 order이 표시됨

이점을 참고해서 테스트를 확인하면됨

테스트
0. 환경설정
1. No-Parallel ITAS 삽입
2. Parallel ITAS 삽입(읽기, 쓰기 모두 병렬)
3. Parallel ITAS 삽입2(읽기만 병렬, 쓰기는 직렬)
4. 전체 결과 비교 및 분석

테스트
0. 환경설정
샘플 테이블 제거

1
2
3
4
5

SQL>
drop table table_noparallel purge;
drop table table_parallel purge;
drop table table_parallel2 purge;
drop table sample_base purge;

플랜확인을 위해 statistics_level 파라미터 all로 설정

1
2
3

SQL> alter session set statistics_level=all;
 
Session altered.

샘플 테이블 생성

1
2
3
4
5
6
7
8

SQL>
create table sample_base (
    c1 number,
    c2 number,
    c3 number,
    pad varchar2(100)
)
pctfree 60;

샘플 데이터 100만건 삽입

1
2
3
4
5
6
7
8
9
10
11

SQL>
insert /*+ append */ into sample_base
select 
    dbms_random.value(1, 100000) as c1,
    dbms_random.value(1, 100000) as c2,
    dbms_random.value(1, 100000) as c3,
    rpad('x', 100, 'x')
from dual
connect by level <= 1000000;
 
commit;

1. No-Parallel ITAS 삽입
order by를 통해 데이터를 물리적으로 정렬하며 입력해봄
테이블 생성 및 데이터 입력(no parallel)

1
2
3
4
5
6
7
8
9
10
11

SQL>
create table table_noparallel pctfree 60 as 
select * from sample_base where 1=0;
 
insert /*+ append no_parallel */ into table_noparallel
select * from sample_base order by c1, c2;
 
select prev_sql_id from v$session
where sid = (select sid from v$mystat where rownum = 1);
 
commit;

prev_sql_id 쿼리 결과는 적지 않았지만 이 insert 구문의 sql_id는 65yb86db9cg1j임

인덱스 생성

1
2
3

SQL> 
create index idx_nopar_c12 on table_noparallel(c1, c2);
create index idx_nopar_c3 on table_noparallel(c3);

통계정보 수집

1
2
3

SQL> exec dbms_stats.gather_table_stats(user, 'table_noparallel', cascade => true);
 
PL/SQL procedure successfully completed.

2. Parallel ITAS 삽입(읽기, 쓰기 모두 병렬)
세션레벨 병렬 dml 활성화

1
2
3

SQL> alter session enable parallel dml;
 
Session altered.

테이블 생성 및 병렬 데이터 입력(parallel)

1
2
3
4
5
6
7
8
9
10
11

SQL> 
create table table_parallel pctfree 60 as 
select * from sample_base where 1=0;
 
insert /*+ append parallel(t 4) */ into table_parallel t
select /*+ parallel(x 4) */ * from sample_base x order by c1, c2;
 
select prev_sql_id from v$session
where sid = (select sid from v$mystat where rownum = 1);
 
commit;

prev_sql_id 쿼리 결과는 적지 않았지만 이 insert 구문의 sql_id는 49pyu0wdc5z5h임

인덱스 생성

1
2
3

SQL> 
create index idx_par_c12 on table_parallel(c1, c2);
create index idx_par_c3 on table_parallel(c3);

통계정보 수집

1
2
3

SQL> exec dbms_stats.gather_table_stats(user, 'table_parallel', cascade => true);
 
PL/SQL procedure successfully completed.

3. Parallel ITAS 삽입2(읽기만 병렬, 쓰기는 직렬)
세션레벨 병렬 dml 활성화

1
2
3

SQL> alter session enable parallel dml;
 
Session altered.

테이블 생성 및 데이터 입력(select만 parallel)

1
2
3
4
5
6
7
8
9
10
11

SQL> 
create table table_parallel2 pctfree 60 as 
select * from sample_base where 1=0;
 
insert /*+ append */ into table_parallel2
select /*+ parallel(x 4) */ * from sample_base x order by c1, c2;
 
select prev_sql_id from v$session
where sid = (select sid from v$mystat where rownum = 1);
 
commit;

prev_sql_id 쿼리 결과는 적지 않았지만 이 insert 구문의 sql_id는 75va8ajmxkzgv임

인덱스 생성

1
2
3

SQL> 
create index idx_par2_c12 on table_parallel2(c1, c2);
create index idx_par2_c3 on table_parallel2(c3);

통계정보 수집

1
2
3

SQL> exec dbms_stats.gather_table_stats(user, 'table_parallel2', cascade => true);
 
PL/SQL procedure successfully completed.

4. 전체 결과 비교 및 분석
인덱스 통계 비교

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SQL> 
set lines 200 pages 1000
col table_name for a20
col index_name for a20
select dt.table_name, index_name, clustering_factor, di.num_rows, dt.blocks
from dba_indexes di, dba_tables dt
where di.table_name = dt.table_name
and di.table_name in ('TABLE_NOPARALLEL', 'TABLE_PARALLEL', 'TABLE_PARALLEL2')
order by di.table_name;
 
TABLE_NAME           INDEX_NAME           CLUSTERING_FACTOR   NUM_ROWS     BLOCKS
-------------------- -------------------- ----------------- ---------- ----------
TABLE_NOPARALLEL     IDX_NOPAR_C12                    55556    1000000      55879 <<-- No-Parallel ITAS 삽입
TABLE_NOPARALLEL     IDX_NOPAR_C3                    999986    1000000      55879
TABLE_PARALLEL       IDX_PAR_C12                      55557    1000000      55872 <<-- Parallel ITAS 삽입(읽기, 쓰기 모두 병렬)
TABLE_PARALLEL       IDX_PAR_C3                      999983    1000000      55872
TABLE_PARALLEL2      IDX_PAR2_C12                     55556    1000000      55879 <<-- Parallel ITAS 삽입2(읽기만 병렬, 쓰기는 직렬)
TABLE_PARALLEL2      IDX_PAR2_C3                     999986    1000000      55879 
 
6 rows selected.

일단 세가지 경우 모두 Clustering Factor에 큰 차이가 없음
insert, select 시 모두 parallel을 사용한 경우만 Clustering Factor가 1 높음

세가지 케이스 실행계획 확인
No-Parallel ITAS 삽입시 실행계획

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

SQL> select * from table(dbms_xplan.display_cursor('65yb86db9cg1j', null, 'advanced allstats last -Projection -qbregistry -rows -bytes' ));
 
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  65yb86db9cg1j, child number 0
-------------------------------------
insert /*+ append no_parallel */ into table_noparallel select * from
sample_base order by c1, c2
 
Plan hash value: 3162832671
 
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name             | Starts | Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  | Writes |  OMem |  1Mem | Used-Mem | Used-Tmp|
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                 |                  |      1 | 51842 (100)|          |      0 |00:00:05.20 |     115K|  77296 |  77296 |       |       |          |         |
|   1 |  LOAD AS SELECT                  | TABLE_NOPARALLEL |      1 |            |          |      0 |00:00:05.20 |     115K|  77296 |  77296 |  2070K|  2070K| 2070K (0)|         |
|   2 |   OPTIMIZER STATISTICS GATHERING |                  |      1 | 51842   (1)| 00:00:03 |   1000K|00:00:02.47 |   55676 |  77296 |  21740 |   256K|   256K|          |         |
|   3 |    SORT ORDER BY                 |                  |      1 | 51842   (1)| 00:00:03 |   1000K|00:00:01.91 |   55564 |  77296 |  21740 |   191M|  4637K|  102M (1)|     170M|
|   4 |     TABLE ACCESS FULL            | SAMPLE_BASE      |      1 | 15161   (1)| 00:00:01 |   1000K|00:00:00.35 |   55561 |  55556 |      0 |       |       |          |         |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
 
   1 - SEL$1
   4 - SEL$1 / SAMPLE_BASE@SEL$1
 
Outline Data
-------------
 
  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('19.1.0')
      DB_VERSION('19.1.0')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$1")
      OUTLINE_LEAF(@"INS$1")
      FULL(@"INS$1" "TABLE_NOPARALLEL"@"INS$1")
      FULL(@"SEL$1" "SAMPLE_BASE"@"SEL$1")
      END_OUTLINE_DATA
  */
 
Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: 1 (U - Unused (1))
---------------------------------------------------------------------------
 
   0 -  STATEMENT
         U -  no_parallel
 
Note
-----
   - Degree of Parallelism is 1 because of hint
 
 
50 rows selected.

실행계획에서 별다른 특이사항 없음, 모든 작업이 직렬로 실행됨

Parallel ITAS 삽입시 실행계획(읽기, 쓰기 모두 병렬)

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
61
62
63
64
65
66
67
68
69

SQL> select * from table(dbms_xplan.display_cursor('49pyu0wdc5z5h', null, 'advanced allstats last -Projection -qbregistry -rows -bytes' ));
 
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  49pyu0wdc5z5h, child number 0
-------------------------------------
insert /*+ append parallel(t 4) */ into table_parallel t select /*+
parallel(x 4) */ * from sample_base x order by c1, c2
 
Plan hash value: 3569992811
 
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name           | Starts | Cost (%CPU)| E-Time   |    TQ  |IN-OUT| PQ Distrib | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                   |                |      1 | 14397 (100)|          |        |      |            |      8 |00:00:05.74 |     119 |      5 |       |       |          |
|   1 |  PX COORDINATOR                    |                |      1 |            |          |        |      |            |      8 |00:00:05.74 |     119 |      5 |   214K|   214K|  190K (0)|
|   2 |   PX SEND QC (RANDOM)              | :TQ10001       |      0 | 14397   (1)| 00:00:01 |  Q1,01 | P->S | QC (RAND)  |      0 |00:00:00.01 |       0 |      0 |       |       |          |
|   3 |    LOAD AS SELECT (HYBRID TSM/HWMB)| TABLE_PARALLEL |      0 |            |          |  Q1,01 | PCWP |            |      0 |00:00:00.01 |       0 |      0 |    10M|    10M| 2070K (0)|
|   4 |     OPTIMIZER STATISTICS GATHERING |                |      0 | 14397   (1)| 00:00:01 |  Q1,01 | PCWP |            |      0 |00:00:00.01 |       0 |      0 |   256K|   256K|  512K (0)|
|   5 |      SORT ORDER BY                 |                |      0 | 14397   (1)| 00:00:01 |  Q1,01 | PCWP |            |      0 |00:00:00.01 |       0 |      0 |   398M|  6600K|   88M (0)|
|   6 |       PX RECEIVE                   |                |      0 |  4207   (1)| 00:00:01 |  Q1,01 | PCWP |            |      0 |00:00:00.01 |       0 |      0 |       |       |          |
|   7 |        PX SEND RANGE               | :TQ10000       |      0 |  4207   (1)| 00:00:01 |  Q1,00 | P->P | RANGE      |      0 |00:00:00.01 |       0 |      0 |       |       |          |
|   8 |         PX BLOCK ITERATOR          |                |      0 |  4207   (1)| 00:00:01 |  Q1,00 | PCWC |            |      0 |00:00:00.01 |       0 |      0 |       |       |          |
|*  9 |          TABLE ACCESS FULL         | SAMPLE_BASE    |      0 |  4207   (1)| 00:00:01 |  Q1,00 | PCWP |            |      0 |00:00:00.01 |       0 |      0 |       |       |          |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
 
   1 - SEL$1
   9 - SEL$1 / X@SEL$1
 
Outline Data
-------------
 
  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('19.1.0')
      DB_VERSION('19.1.0')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$1")
      OUTLINE_LEAF(@"INS$1")
      FULL(@"INS$1" "T"@"INS$1")
      FULL(@"SEL$1" "X"@"SEL$1")
      END_OUTLINE_DATA
  */
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   9 - access(:Z>=:Z AND :Z<=:Z)
 
Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: 2
---------------------------------------------------------------------------
 
   0 -  INS$1 / T@INS$1
           -  parallel(t 4)
 
   9 -  SEL$1 / X@SEL$1
           -  parallel(x 4)
 
Note
-----
   - Degree of Parallelism is 4 because of table property
 
 
63 rows selected.

실행계획에서 PX SEND QC (RANDOM), LOAD AS SELECT (HYBRID TSM/HWMB) 플랜이 보임

Parallel ITAS 삽입시 실행계획(읽기만 병렬, 쓰기는 직렬)

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
61
62
63
64
65
66
67

SQL> select * from table(dbms_xplan.display_cursor('75va8ajmxkzgv', null, 'advanced allstats last -Projection -qbregistry -rows -bytes' ));
 
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  75va8ajmxkzgv, child number 0
-------------------------------------
insert /*+ append */ into table_parallel2 select /*+ parallel(x 4) */ *
from sample_base x order by c1, c2
 
Plan hash value: 745855944
 
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name            | Starts | Cost (%CPU)| E-Time   |    TQ  |IN-OUT| PQ Distrib | A-Rows |   A-Time   | Buffers | Reads  | Writes |  OMem |  1Mem | Used-Mem |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                 |                 |      1 | 14397 (100)|          |        |      |            |      0 |00:00:04.63 |   60034 |      4 |  55556 |       |       |          |
|   1 |  LOAD AS SELECT                  | TABLE_PARALLEL2 |      1 |            |          |        |      |            |      0 |00:00:04.63 |   60034 |      4 |  55556 |  2070K|  2070K| 2070K (0)|
|   2 |   OPTIMIZER STATISTICS GATHERING |                 |      1 | 14397   (1)| 00:00:01 |        |      |            |   1000K|00:00:01.68 |     112 |      4 |      0 |   256K|   256K|          |
|   3 |    PX COORDINATOR                |                 |      1 |            |          |        |      |            |   1000K|00:00:01.14 |       5 |      1 |      0 |   214K|   214K|  190K (0)|
|   4 |     PX SEND QC (ORDER)           | :TQ10001        |      0 | 14397   (1)| 00:00:01 |  Q1,01 | P->S | QC (ORDER) |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |          |
|   5 |      SORT ORDER BY               |                 |      0 | 14397   (1)| 00:00:01 |  Q1,01 | PCWP |            |      0 |00:00:00.01 |       0 |      0 |      0 |   209M|  4848K|   46M (0)|
|   6 |       PX RECEIVE                 |                 |      0 |  4207   (1)| 00:00:01 |  Q1,01 | PCWP |            |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |          |
|   7 |        PX SEND RANGE             | :TQ10000        |      0 |  4207   (1)| 00:00:01 |  Q1,00 | P->P | RANGE      |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |          |
|   8 |         PX BLOCK ITERATOR        |                 |      0 |  4207   (1)| 00:00:01 |  Q1,00 | PCWC |            |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |          |
|*  9 |          TABLE ACCESS FULL       | SAMPLE_BASE     |      0 |  4207   (1)| 00:00:01 |  Q1,00 | PCWP |            |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |          |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
 
   1 - SEL$1
   9 - SEL$1 / X@SEL$1
 
Outline Data
-------------
 
  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('19.1.0')
      DB_VERSION('19.1.0')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$1")
      OUTLINE_LEAF(@"INS$1")
      FULL(@"INS$1" "TABLE_PARALLEL2"@"INS$1")
      FULL(@"SEL$1" "X"@"SEL$1")
      END_OUTLINE_DATA
  */
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   9 - access(:Z>=:Z AND :Z<=:Z)
 
Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: 1
---------------------------------------------------------------------------
 
   9 -  SEL$1 / X@SEL$1
           -  parallel(x 4)
 
Note
-----
   - Degree of Parallelism is 4 because of table property
   - PDML disabled because object is not decorated with parallel clause
 
 
61 rows selected.

실행계획에서 PX SEND QC (ORDER) 플랜이 보임

rowid 순으로 정렬하여 c1 값 확인

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

SQL>
set lines 200 pages 1000
select
dbms_rowid.rowid_relative_fno(rowid) rel_fno,
dbms_rowid.rowid_block_number(rowid) blockno,
rowid, 
c1
from table_noparallel
order by rowid;
 
   REL_FNO    BLOCKNO ROWID                      C1
---------- ---------- ------------------ ----------
...
         4     114877 AAAMReAAEAAAcC9AAM 11850.2128
         4     114877 AAAMReAAEAAAcC9AAN 11850.2761
         4     114877 AAAMReAAEAAAcC9AAO 11850.2793
         4     114877 AAAMReAAEAAAcC9AAP 11850.4207
         4     114877 AAAMReAAEAAAcC9AAQ 11850.4823
         4     114877 AAAMReAAEAAAcC9AAR 11850.5259  <<-- 정렬 유지
         4     114878 AAAMReAAEAAAcC+AAA 11850.5493  <<-- 정렬 유지
         4     114878 AAAMReAAEAAAcC+AAB 11850.5659
         4     114878 AAAMReAAEAAAcC+AAC 11850.5674
         4     114878 AAAMReAAEAAAcC+AAD 11850.5973
         4     114878 AAAMReAAEAAAcC+AAE 11850.6317
...
 
SQL>
set lines 200 pages 1000
select
dbms_rowid.rowid_relative_fno(rowid) rel_fno,
dbms_rowid.rowid_block_number(rowid) blockno,
rowid, 
c1
from table_parallel2
order by rowid;
 
   REL_FNO    BLOCKNO ROWID                      C1
---------- ---------- ------------------ ----------
...
         4     248617 AAAMRkAAEAAA8spAAN 3233.87902
         4     248617 AAAMRkAAEAAA8spAAO 3233.99063
         4     248617 AAAMRkAAEAAA8spAAP 3234.05061
         4     248617 AAAMRkAAEAAA8spAAQ 3234.06362
         4     248617 AAAMRkAAEAAA8spAAR 3234.21536  <<-- 정렬 유지
         4     248618 AAAMRkAAEAAA8sqAAA 3234.24367  <<-- 정렬 유지
         4     248618 AAAMRkAAEAAA8sqAAB 3234.32654
         4     248618 AAAMRkAAEAAA8sqAAC 3234.32802
         4     248618 AAAMRkAAEAAA8sqAAD 3234.36388
         4     248618 AAAMRkAAEAAA8sqAAE 3234.42606
...

rowid 순으로 확인했을 때 parallel을 사용하지 않은 경우(1번 케이스 table_noparallel)와
select 시에만 parallel을 사용한 경우(3번 케이스 table_parallel2)는 c1 값이 순서대로 정렬되어 있었음

rowid 순으로 정렬하여 c1 값 확인(select와 insert시 모두 parallel을 사용한 경우)

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

SQL>
set lines 200 pages 1000
select
dbms_rowid.rowid_relative_fno(rowid) rel_fno,
dbms_rowid.rowid_block_number(rowid) blockno,
rowid, 
c1
from table_parallel
order by rowid;
 
   REL_FNO    BLOCKNO ROWID                      C1
---------- ---------- ------------------ ----------
...
         4     178403 AAALbSAAGAAArjjAAJ 22564.3538
         4     178403 AAALbSAAGAAArjjAAK 22564.5958
         4     178403 AAALbSAAGAAArjjAAL 22564.6543
         4     178403 AAALbSAAGAAArjjAAM 22564.8332
         4     178403 AAALbSAAGAAArjjAAN 22564.8456
         4     178403 AAALbSAAGAAArjjAAO   22564.98
         4     178403 AAALbSAAGAAArjjAAP 22565.2553
         4     178403 AAALbSAAGAAArjjAAQ 22565.4675
         4     178403 AAALbSAAGAAArjjAAR 22565.4941  <<-- 정렬 미유지
         4     178404 AAALbSAAGAAArjkAAA 96023.7804  <<-- 정렬 미유지
         4     178404 AAALbSAAGAAArjkAAB 96023.8758
         4     178404 AAALbSAAGAAArjkAAC 96024.1353
         4     178404 AAALbSAAGAAArjkAAD 96024.3547
         4     178404 AAALbSAAGAAArjkAAE 96024.3653
         4     178404 AAALbSAAGAAArjkAAF 96024.3997
...

select와 insert시 모두 parallel을 사용한 경우(2번 케이스)는 위 결과처럼
하나의 블록 단위 내에서는 c1 값이 정렬 되어 있었지만 c1 값이 전체적으로는 정렬되어 있지 않았음
아래와 같이 178403 블록에서는 2만대의 값(22565)이 나오다가 178404 블록에서는 9만대의 값(96023)이 나옴
이것만 봤을때는 아직까진 이 정렬이 블록 단위 정렬인지 익스텐트 단위 정렬이 되는것인지 알수 없음

TABLE_PARALLEL 테이블이 사용중인 익스텐트 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

SQL>
col owner for a10
col segment_name for a20
SELECT 
    owner,
    segment_name,
    extent_id, -- 익스텐트 번호
    block_id,  -- 익스텐트의 시작 블록
    blocks     -- 익스텐트 내 블록 수
FROM dba_extents
WHERE segment_name = 'TABLE_PARALLEL';
 
OWNER      SEGMENT_NAME          EXTENT_ID   BLOCK_ID     BLOCKS
---------- -------------------- ---------- ---------- ----------
...
IMSI       TABLE_PARALLEL              106     176640       1024
IMSI       TABLE_PARALLEL              107     177664       1024  <<-- !!
IMSI       TABLE_PARALLEL              108     178688       1024
..

위에서 확인한 블록(178403, 178404)들은 모두 107 익스텐트에 들어가 있음
177664 블록부터 178687 블록까지 1024개의 블록이 107 익스텐트에 속함
이 말은 익스텐트간 row 정렬이 되어있는것이 아닌 블록내에서만 정렬이 이루어 졌다는것을 의미함

사실 실행계획에서도 그 내용을 확인할 수 있었음
id 8을 보면 PX BLOCK ITERATOR 으로 표시됨
이는 데이터를 여러 개의 조각(블록 단위)으로 나눈 뒤 여러 병렬 서버 프로세스가 각 조각을 반복(Iterator)하며 나누어 처리하는 작업 방식임

3번 케이스 실행계획(Parallel ITAS 삽입2(읽기만 병렬, 쓰기는 직렬))

1
2
3
4
5
6
7
8
9
10
11
12
13
14

------------------------------------------------------------
| Id  | Operation                        | Name            |
------------------------------------------------------------
|   0 | INSERT STATEMENT                 |                 |
|   1 |  LOAD AS SELECT                  | TABLE_PARALLEL2 |
|   2 |   OPTIMIZER STATISTICS GATHERING |                 |
|   3 |    PX COORDINATOR                |                 |
|   4 |     PX SEND QC (ORDER)           | :TQ10001        | <<--!! ORDER
|   5 |      SORT ORDER BY               |                 |
|   6 |       PX RECEIVE                 |                 |
|   7 |        PX SEND RANGE             | :TQ10000        |
|   8 |         PX BLOCK ITERATOR        |                 | <<--!!
|*  9 |          TABLE ACCESS FULL       | SAMPLE_BASE     |
------------------------------------------------------------

2번 케이스 실행계획(Parallel ITAS 삽입(읽기, 쓰기 모두 병렬))

1
2
3
4
5
6
7
8
9
10
11
12
13
14

-------------------------------------------------------------
| Id  | Operation                          | Name           |
-------------------------------------------------------------
|   0 | INSERT STATEMENT                   |                |
|   1 |  PX COORDINATOR                    |                |
|   2 |   PX SEND QC (RANDOM)              | :TQ10001       | <<--!! RANDOM
|   3 |    LOAD AS SELECT (HYBRID TSM/HWMB)| TABLE_PARALLEL |
|   4 |     OPTIMIZER STATISTICS GATHERING |                |
|   5 |      SORT ORDER BY                 |                |
|   6 |       PX RECEIVE                   |                |
|   7 |        PX SEND RANGE               | :TQ10000       |
|   8 |         PX BLOCK ITERATOR          |                | <<--!!
|*  9 |          TABLE ACCESS FULL         | SAMPLE_BASE    |
-------------------------------------------------------------

그리고 일반적으로 병렬입력에서 값이 정렬되어서 들어가는 경우 아래와 같이 PX SEND QC (ORDER)로 표시됨(3번 케이스)
하지만 2번 케이스의 경우 PX SEND QC가 RANDOM으로 표시가 되었음

이는 Parallel Insert 시 각 병렬 슬레이브가 독립적으로 데이터를 Write하기 때문임
PX BLOCK ITERATOR를 통해 분배된 데이터가 각 슬레이브 내에서 SORT ORDER BY를 거쳐 블록 단위의 정렬은 보장하지만
여러 슬레이브가 동시에 Write를 수행하는 병렬 부하의 특성상 테이블 전체의 물리적 Rowid 순서와 정렬 순서가 일치하지 않는 현상이 발생한것

참고1. Parallel Read + Parallel Write 데이터 흐름

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

1 단계: 디스크에서 블록 읽기 & 분배
[ 데이터베이스 디스크 (SAMPLE_BASE 테이블) ]
                | (PX BLOCK ITERATOR 단위 분배)
                v
 +-----------+ +-----------+ +-----------+ +-----------+
 | PX Slave1 | | PX Slave2 | | PX Slave3 | | PX Slave4 |  <-- [Producer Group]
 +-----------+ +-----------+ +-----------+ +-----------+
       |             |             |             |
       +-------------+-------------+-------------+
                     |
                     | 2 단계: Range 분배 및 정렬 (Inter-Operation Parallelism)
                     | (값의 범위에 따라 다른 슬레이브로 셔플링)
                     v
 +-----------+ +-----------+ +-----------+ +-----------+
 | PX Slave5 | | PX Slave6 | | PX Slave7 | | PX Slave8 |  <-- [Consumer Group]
 +-----------+ +-----------+ +-----------+ +-----------+
   (Sort 수행)   (Sort 수행)   (Sort 수행)   (Sort 수행)
       |             |             |             |
       | (독립 Write)| (독립 Write)| (독립 Write)| (독립 Write)
       v             v             v             v
 [ Block A ]  [ Block B ]  [ Block C ]  [ Block D ]  <-- (Direct Path Insert)
       \             \             /             /
        \             \           /             /
         v             v         v             v
       [ TABLE_PARALLEL 테이블 (물리적 정렬 꼬임 발생!) ]
                     |
                     | 3 단계: 작업 완료 보고 (PX SEND QC RANDOM)
                     v
          [ Query Coordinator (QC) ]  <-- (세션 프로세스)

참고2. Parallel Read + Serial Write 데이터 흐름

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

1 단계: 디스크에서 블록 읽기 & 분배
[ 데이터베이스 디스크 (SAMPLE_BASE 테이블) ]
                | (PX BLOCK ITERATOR 단위 분배)
                v
 +-----------+ +-----------+ +-----------+ +-----------+
 | PX Slave1 | | PX Slave2 | | PX Slave3 | | PX Slave4 |  <-- [Producer Group]
 +-----------+ +-----------+ +-----------+ +-----------+
       |             |             |             |
       +-------------+-------------+-------------+
                     |
                     | 2 단계: Range 분배 및 정렬 (Inter-Operation Parallelism)
                     | (값의 범위에 따라 다른 슬레이브로 셔플링)
                     v
 +-----------+ +-----------+ +-----------+ +-----------+
 | PX Slave5 | | PX Slave6 | | PX Slave7 | | PX Slave8 |  <-- [Consumer Group]
 +-----------+ +-----------+ +-----------+ +-----------+
   (Sort 수행)   (Sort 수행)   (Sort 수행)   (Sort 수행)
       |             |             |             |
       +-------------+-------------+-------------+
                     |
                     | 3 단계: 정렬된 순서대로 QC에게 전송 (PX SEND QC ORDER)
                     v
          [ Query Coordinator (QC) ]  <-- (세션 프로세스)
                     |
                     | 4 단계: 단일 프로세스가 순차적으로 Write (직렬 삽입)
                     v
          [ Block A -> Block B -> Block C -> Block D ... ]
                     |
                     v
       [ TABLE_PARALLEL2 테이블 (물리적 정렬 보장) ]

결론 :
Clustering Factor 개선을 위한 ITAS 작업 시 속도를 위해 Parallel Insert를 사용해보았음
이때 parallel을 미사용한 경우, select시에만 parallel을 사용한 경우, insert, select 모두에 parallel을 사용한 세가지 경우 모두 Clustering Factor는 비슷했음
parallel을 미사용한 경우, select시에만 parallel을 사용한 경우에는 테이블 전체의 물리적 순서 정렬이 되어있지만,
insert, select 모두에 parallel을 사용한 경우에는 테이블 전체의 물리적 순서 정렬이 되어있지 않음
이는 Parallel Insert 시 각 병렬 슬레이브가 독립적으로 데이터를 Write하기 때문임
PX BLOCK ITERATOR를 통해 분배된 데이터가 각 슬레이브 내에서 SORT ORDER BY를 거쳐 블록 단위의 정렬은 보장하지만
여러 슬레이브가 동시에 Write를 수행하는 병렬 부하의 특성상 테이블 전체의 물리적 Rowid 순서와 정렬 순서가 일치하지 않는 현상이 발생한것임
결과는 이렇지만 CF만 본다면 CF 개선을 위해 굳이 select에는 parallel을 사용하고 insert에는 serial로 하는 방식은 사용하지 않아도 될듯함
select, insert 모두에 parallel을 사용하면 될듯함

참조 :

오라클 19c 인덱스 생성시 nosort 옵션(assm 환경) ( https://positivemh.tistory.com/1015 )
오라클 19c 인덱스 생성시 nosort 옵션(mssm 환경) ( https://positivemh.tistory.com/1016 )
오라클 19c 인덱스 생성시 nosort 옵션 대기 이벤트 확인 ( https://positivemh.tistory.com/1023 )

오라클 19c Active Data Guard(ADG)와 Data Guard(DG) 차이점 및 DML Redirection 기능

내맘대로긍정 — Tue, 16 Jun 2026 22:45:26 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle Database 19.28.0.0

방법 : 오라클 19c Active Data Guard(ADG)와 Data Guard(DG) 차이점 및 DML Redirection 기능

Oracle Data Guard(DG)는 Primary DB에서 발생하는 Redo 데이터를 Standby DB로 전송 및 적용(Apply)하여 데이터 동기화를 유지하는 재해 복구(DR) 솔루션임
기본적으로 일반 DG 환경에서 Standby DB는 MOUNT 상태로 유지되고 Redo를 지속적으로 적용함(mount 상태이기 때문에 평상시에는 DB에 접근해서 데이터를 조회할 수 없음)
Active Data Guard(ADG)는 Redo Apply(동기화)를 진행하면서 동시에 Standby DB를 READ ONLY 상태로 Open 할 수 있는 기능임
ADG를 사용하면 무거운 통계 쿼리, 일 단위 결산 배치(Read-only), BI 리포팅 툴의 DB 연결을 Standby로 수행해 Primary DB의 CPU 및 I/O 부하를 분산시킬 수 있음
또한 RMAN 백업을 Primary DB가 아닌 Standby DB에서 수행하여 운영 장비의 백업 부하를 제거하는 용도로도 사용 가능함(참고로 Datapump는 내부적으로 임시테이블을 만드는 작업이 있기때문에 Standby에서 수행 불가함)
라이센스는 기본 DG는 Enterprise Edition(EE)에 기본 포함되지만 ADG는 EE에 추가적인 Option 라이센스 구매가 필요함

그리고 오라클 19c부터는 ADG 환경에서 DML Redirection이라는 신기능이 추가됨
원래 ADG의 Standby DB는 Read Only 상태라 DML(INSERT, UPDATE, DELETE)이 불가능함
하지만 이 기능을 사용하면 Standby DB에서 DML을 실행할 경우 이를 Primary로 리다이렉션해서 처리한 뒤 다시 Redo를 통해 Standby DB로 동기화시킴
가끔 데이터 수정이 필요한 Reporting Application도 이제 소스 수정 없이 ADG를 바라보게 할 수 있음

본문에서는 ADG 환경을 확인하고 19c 신기능인 DML Redirection을 활성화하여 Standby DB에서 직접 DML을 수행해보는 테스트를 진행함
ADG 구축은 아래 게시글 참고
참고 : 오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드 ( https://positivemh.tistory.com/1391 )

테스트
Standby DB의 현재 오픈 모드 및 ADG 상태 확인

1
2
3
4
5

SQL> select name, open_mode, database_role from v$database;
 
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
ORACLE19  READ ONLY WITH APPLY PHYSICAL STANDBY

READ ONLY WITH APPLY 상태로 ADG가 정상적으로 동작 중임

DML Redirection 활성화 전 Primary DB에서 샘플 테이블 생성

1
2
3
4

$ sqlplus system/oracle
SQL> create table adg_test (col1 number);
 
Table created.

DML Redirection 활성화 전 Standby DB에서 dml 테스트

1
2
3
4
5

SQL> insert into adg_test values (1);
insert into adg_test values (1)
            *
ERROR at line 1:
ORA-16000: database or pluggable database open for read-only access

읽기 전용이어서 DML이 실패함

세션 레벨에서 DML Redirection 기능 활성화

1
2
3

SQL> alter session enable adg_redirect_dml;
 
Session altered.

참고로 시스템 전체 레벨로 적용하려면 adg_redirect_dml 파라미터를 true로 변경하면 됨

DML Redirection 활성화 후 Standby DB에서 dml 테스트

1
2
3
4
5
6
7
8

$ sqlplus system/oracle
SQL> insert into adg_test values (1);
 
1 row created.
 
SQL> commit;
 
Commit complete.

조금 느리지만 insert 됨 ORA-16000 에러 없이 정상적으로 INSERT 및 COMMIT이 수행됨
백그라운드에서 Primary DB로 쿼리가 전달되어 실행된 후 Redo를 통해 다시 Standby로 적용된 것임

참고로 sysdba(OS 인증 등)로 접속하면 redirection 할때 필요한 세션 정보가 없기 때문에 dml이 실패함

1
2
3
4
5
6

$ sqlplus / as sysdba
SQL> insert into adg_test values (1);
insert into adg_test values (1)
            *
ERROR at line 1:
ORA-16397: statement redirection from Oracle Active Data Guard standby database to primary database failed

각 DB에서 데이터 반영 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#Primary DB에서 확인
SQL>
conn system/oracle
set lines 200
col name for a20
select * from adg_test;
 
      COL1
----------
         1
 
#Standby DB에서 확인
SQL>
conn system/oracle
set lines 200
col name for a20
select * from adg_test;
 
      COL1
----------
         1

양쪽 db에서 동기화된 데이터가 정상적으로 조회됨

참고로 Primary와 Standby 간의 복제 지연(Lag) 상태나 전송 에러는 v$dataguard_stats 뷰에 정보가 남음

1
2
3
4
5
6
7
8

SQL> select name, value from v$dataguard_stats;
 
NAME                           VALUE
------------------------------ ----------------------
transport lag                  +00 00:00:00
apply lag                      +00 00:00:00
apply finish time              +00 00:00:00.000
estimated startup time         16

Lag이 00:00:00 이면 실시간으로 지연 없이 잘 동기화되고 있다는 의미임

결론 :
Oracle ADG 기능을 이용하면 DR 구성과 동시에 읽기 부하를 Standby 서버로 분산할 수 있음
19c의 DML Redirection을 이용해 Read-Only DB의 제약을 일부 해소할 수도 있음
하지만 리다이렉션 과정에서 네트워크 오버헤드가 발생할수 있기 떄문에 대량의 DML 트랜잭션보다는 간헐적인 DML이 발생하는 환경에 적합함
그리고 Snapshot Standby Database 기능을 이용하면 DG 환경에서도 임시로 Read Write 가능한 db로 변경이 가능함
참고 : 오라클 19c ADG Snapshot Standby Database ( https://positivemh.tistory.com/1397 )

참조 :

오라클 19c ADG Snapshot Standby Database

내맘대로긍정 — Sun, 14 Jun 2026 11:29:30 +0900

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 서버에서만 작업함

Active Data Guard(ADG) 란?

참고 : 오라클 19c Active Data Guard(ADG)와 Data Guard(DG) ( https://positivemh.tistory.com/1398 )

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

SQL> alter database recover managed standby database cancel;
 
Database altered.

Snapshot Standby Database로 변환(Convert)

1
2
3

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

오라클 19c ADG 구성 중 db_file_name_convert, log_file_name_convert 파라미터 테스트

내맘대로긍정 — Fri, 12 Jun 2026 23:05:15 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle Database 19.28.0.0

방법 : 오라클 19c ADG 구성 중 db_file_name_convert, log_file_name_convert 파라미터 테스트

본문에서는 adg duplicate 명령 수행시 db_file_name_convert, log_file_name_convert 파라미터 설정에 따라 어떻게 동작하는지를 확인해봄
참고로 환경은 Restart(ASM) to Restart(ASM) 환경임

테스트
케이스1. db_file_name_convert에 ASM to FS 복제할때처럼 ASM 전체 경로 모두 삽입('+DATA/ORACLE19/DATAFILE','+DATA/ORACLE19STB/DATAFILE')
pfile 수정

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

$ vi initoracle19stb.ora
*.audit_file_dest='/app/oracle/admin/oracle19stb/adump'
*.audit_trail='none'
*.compatible='19.0.0'
*.control_files='+DATA/control01.ctl'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_file_name_convert='+DATA/ORACLE19/DATAFILE','+DATA/ORACLE19STB/DATAFILE','+DATA/ORACLE19/TEMPFILE','+DATA/ORACLE19STB/TEMPFILE'
*.log_file_name_convert='+DATA/ORACLE19/DATAFILE','+DATA/ORACLE19STB/DATAFILE'
*.db_unique_name='oracle19stb'
*.db_name='oracle19'
*.diagnostic_dest='/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=oracle19stbXDB)'
*.fal_client='ORACLE19STB'
*.fal_server='ORACLE19'
*.log_archive_config='DG_CONFIG=(oracle19,oracle19stb)'
*.log_archive_dest_1='location=/app/oracle/arch valid_for=(all_logfiles,all_roles) db_unique_name=oracle19stb'
*.log_archive_dest_2='service=oracle19 lgwr async noaffirm valid_for=(online_logfiles,primary_role) db_unique_name=oracle19'
*.log_archive_format='%t_%s_%r.arc'
*.log_archive_max_processes=4
*.nls_language='AMERICAN'
*.nls_territory='AMERICA'
*.open_cursors=300
*.pga_aggregate_target=522m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=1564m
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'

nomount 기동 후 rman duplicate 수행

1
2
3
4

SQL> startup force nomount
$ rman target sys/oracle@oracle19 auxiliary sys/oracle@oracle19stb
RMAN> duplicate target database for standby from active database dorecover;
(진행됨)

하지만 alert log 확인시 아래 에러 발생함

1
2
3
4
5
6
7
8
9
10
11
12
13

$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
*****************************************
WARNING: The converted filename '+DATA/ORACLE19STB/DATAFILE/users.265.1220456367'
         is an ASM fully qualified filename.
         Changing the filename to '+DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295'.
         Please rename it accordingly.
*****************************************
2026-06-08T21:20:38.810028+09:00
Errors in file /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/oracle19stb_mz00_19898.trc:
ORA-01110: data file 4: '+DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295'
ORA-01565: error in identifying file '+DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295'
ORA-17503: ksfdopn:2 Failed to open file +DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295
ORA-15012: ASM file '+DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295' does not exist

케이스2. db_file_name_convert에 ASM 디스크그룹 이름만 삽입('+DATA/ORACLE19/DATAFILE','+DATA')
pfile 수정

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

$ vi initoracle19stb.ora
*.audit_file_dest='/app/oracle/admin/oracle19stb/adump'
*.audit_trail='none'
*.compatible='19.0.0'
*.control_files='+DATA/control01.ctl'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_file_name_convert='+DATA/ORACLE19/DATAFILE','+DATA','+DATA/ORACLE19/TEMPFILE','+DATA'
*.log_file_name_convert='+DATA/ORACLE19/DATAFILE','+DATA'
*.db_unique_name='oracle19stb'
*.db_name='oracle19'
*.diagnostic_dest='/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=oracle19stbXDB)'
*.fal_client='ORACLE19STB'
*.fal_server='ORACLE19'
*.log_archive_config='DG_CONFIG=(oracle19,oracle19stb)'
*.log_archive_dest_1='location=/app/oracle/arch valid_for=(all_logfiles,all_roles) db_unique_name=oracle19stb'
*.log_archive_dest_2='service=oracle19 lgwr async noaffirm valid_for=(online_logfiles,primary_role) db_unique_name=oracle19'
*.log_archive_format='%t_%s_%r.arc'
*.log_archive_max_processes=4
*.nls_language='AMERICAN'
*.nls_territory='AMERICA'
*.open_cursors=300
*.pga_aggregate_target=522m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=1564m
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'

nomount 기동 후 rman duplicate 수행

1
2
3
4

SQL> startup force nomount
$ rman target sys/oracle@oracle19 auxiliary sys/oracle@oracle19stb
RMAN> duplicate target database for standby from active database dorecover;
(진행됨)

하지만 alert log 확인시 케이스1과 동일한 에러 발생함

1
2
3
4
5
6
7
8
9
10
11
12
13

$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
*****************************************
WARNING: The converted filename '+DATA/users.265.1220456367'
         is an ASM fully qualified filename.
         Changing the filename to '+DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295'.
         Please rename it accordingly.
*****************************************
2026-06-08T21:22:51.264733+09:00
Errors in file /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/oracle19stb_mz00_21186.trc:
ORA-01110: data file 4: '+DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295'
ORA-01565: error in identifying file '+DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295'
ORA-17503: ksfdopn:2 Failed to open file +DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295
ORA-15012: ASM file '+DATA/MUST_RENAME_THIS_DATAFILE_4.4294967295.4294967295' does not exist

케이스3. db_file_name_convert, log_file_name_convert 파라미터 주석처리 후 db_create_file_dest만 '+DATA'로 지정
pfile 수정

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

$ vi initoracle19stb.ora
*.audit_file_dest='/app/oracle/admin/oracle19stb/adump'
*.audit_trail='none'
*.compatible='19.0.0'
*.control_files='+DATA/control01.ctl'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
#*.db_file_name_convert='+DATA/ORACLE19/DATAFILE','+DATA','+DATA/ORACLE19/TEMPFILE','+DATA'
#*.log_file_name_convert='+DATA/ORACLE19/DATAFILE','+DATA'
*.db_unique_name='oracle19stb'
*.db_name='oracle19'
*.diagnostic_dest='/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=oracle19stbXDB)'
*.fal_client='ORACLE19STB'
*.fal_server='ORACLE19'
*.log_archive_config='DG_CONFIG=(oracle19,oracle19stb)'
*.log_archive_dest_1='location=/app/oracle/arch valid_for=(all_logfiles,all_roles) db_unique_name=oracle19stb'
*.log_archive_dest_2='service=oracle19 lgwr async noaffirm valid_for=(online_logfiles,primary_role) db_unique_name=oracle19'
*.log_archive_format='%t_%s_%r.arc'
*.log_archive_max_processes=4
*.nls_language='AMERICAN'
*.nls_territory='AMERICA'
*.open_cursors=300
*.pga_aggregate_target=522m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=1564m
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'

nomount 기동 후 rman duplicate 수행

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188

SQL> startup force nomount
$ rman target sys/oracle@oracle19 auxiliary sys/oracle@oracle19stb
RMAN> duplicate target database for standby from active database dorecover;
 
Recovery Manager: Release 19.0.0.0.0 - Production on Mon Jun 8 21:25:00 2026
Version 19.28.0.0.0
 
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
 
connected to target database: ORACLE19 (DBID=3400652514)
connected to auxiliary database: ORACLE19 (not mounted)
 
RMAN> duplicate target database for standby from active database dorecover;
duplicate target database for standby from active database dorecover;
Starting Duplicate Db at 2026-06-08 21:25:03
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=24 device type=DISK
current log archived
 
contents of Memory Script:
{
   backup as copy reuse
   passwordfile auxiliary format  '/app/oracle/product/19c/dbs/orapworacle19stb'   ;
}
executing Memory Script
 
Starting backup at 2026-06-08 21:25:06
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=273 device type=DISK
Finished backup at 2026-06-08 21:25:08
duplicating Online logs to Oracle Managed File (OMF) location
duplicating Datafiles to Oracle Managed File (OMF) location
 
contents of Memory Script:
{
   restore clone from service  'oracle19' standby controlfile;
}
executing Memory Script
 
Starting restore at 2026-06-08 21:25:08
using channel ORA_AUX_DISK_1
 
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=+DATA/control01.ctl
Finished restore at 2026-06-08 21:25:12
 
contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script
 
sql statement: alter database mount standby database
 
contents of Memory Script:
{
   set newname for clone tempfile  1 to new;
   switch clone tempfile all;
   set newname for clone datafile  1 to new;
   set newname for clone datafile  2 to new;
   set newname for clone datafile  3 to new;
   set newname for clone datafile  4 to new;
   restore
   from  nonsparse   from service
 'oracle19'   clone database
   ;
   sql 'alter system archive log current';
}
executing Memory Script
 
executing command: SET NEWNAME
 
renamed tempfile 1 to +DATA in control file
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
Starting restore at 2026-06-08 21:25:17
using channel ORA_AUX_DISK_1
 
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to +DATA
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:35
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00002 to +DATA
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:08
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00003 to +DATA
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00004 to +DATA
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2026-06-08 21:26:04
 
sql statement: alter system archive log current
current log archived
 
contents of Memory Script:
{
   restore clone force from service  'oracle19'
           archivelog from scn  1539416;
   switch clone datafile all;
}
executing Memory Script
 
Starting restore at 2026-06-08 21:26:05
using channel ORA_AUX_DISK_1
 
channel ORA_AUX_DISK_1: starting archived log restore to default destination
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: restoring archived log
archived log thread=1 sequence=143
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_AUX_DISK_1: starting archived log restore to default destination
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: restoring archived log
archived log thread=1 sequence=144
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2026-06-08 21:26:07
 
datafile 1 switched to datafile copy
input datafile copy RECID=5 STAMP=1235424367 file name=+DATA/ORACLE19STB/DATAFILE/system.258.1235424319
datafile 2 switched to datafile copy
input datafile copy RECID=6 STAMP=1235424367 file name=+DATA/ORACLE19STB/DATAFILE/sysaux.259.1235424353
datafile 3 switched to datafile copy
input datafile copy RECID=7 STAMP=1235424367 file name=+DATA/ORACLE19STB/DATAFILE/undotbs1.260.1235424361
datafile 4 switched to datafile copy
input datafile copy RECID=8 STAMP=1235424367 file name=+DATA/ORACLE19STB/DATAFILE/users.261.1235424363
 
contents of Memory Script:
{
   set until scn  1539600;
   recover
   standby
   clone database
    delete archivelog
   ;
}
executing Memory Script
 
executing command: SET until clause
 
Starting recover at 2026-06-08 21:26:08
using channel ORA_AUX_DISK_1
 
starting media recovery
 
archived log for thread 1 with sequence 143 is already on disk as file /app/oracle/arch1_143_1220456354.arc
archived log for thread 1 with sequence 144 is already on disk as file /app/oracle/arch1_144_1220456354.arc
archived log file name=/app/oracle/arch1_143_1220456354.arc thread=1 sequence=143
archived log file name=/app/oracle/arch1_144_1220456354.arc thread=1 sequence=144
media recovery complete, elapsed time: 00:00:00
Finished recover at 2026-06-08 21:26:09
 
contents of Memory Script:
{
   delete clone force archivelog all;
}
executing Memory Script
 
released channel: ORA_DISK_1
released channel: ORA_AUX_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=273 device type=DISK
deleted archived log
archived log file name=/app/oracle/arch1_143_1220456354.arc RECID=1 STAMP=1235424365
deleted archived log
archived log file name=/app/oracle/arch1_144_1220456354.arc RECID=2 STAMP=1235424366
Deleted 2 objects
 
Finished Duplicate Db at 2026-06-08 21:26:14

문제없이 잘 수행됨

결론 : 결론 ASM to FS 인 경우는 fs의 경로를 다 적어줘야하고,
ASM to ASM인 경우는 db_file_name_convert, log_file_name_convert 파라미터는 지우거나 주석처리 후
OMF 방식인 db_create_file_dest='+DATA' 파라미터만 남겨둬야함

참조 :

오라클 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 )

http://erman-arslan-s-oracle-forum.124.s1.nabble.com/WARNING-The-converted-filename-is-an-ASM-fully-qualified-filename-td12462.html

2026 오라클 ACE Pro

내맘대로긍정 — Thu, 11 Jun 2026 22:33:07 +0900

방법 : 2026 오라클 ACE Pro

안녕하세요, 제가 작년에 이어 올해도 Oracle ACE Pro로 선정되었습니다.

Oracle ACE Program으로부터 이러한 인정을 받게 되어 매우 영광이며, 앞으로도 Oracle 커뮤니티에 더 깊이 기여할 수 있는 새로운 기회를 얻게 되어 기쁩니다.
이 여정에서 저를 응원해 주신 모든 분들께 진심으로 감사드리며, 특히 Oana-Aurelia Bonu 님, Jennifer Nicholson 님, Charles Kim 님의 격려와 도움에 깊이 감사드립니다.
이러한 뜻깊은 인정과 기회를 주신 Oracle과 ACE Program에도 진심으로 감사드립니다.
앞으로도 기술 블로그를 통해 실무 기반의 Oracle 정보를 나누며, 전 세계 ACE 커뮤니티와 함께 배우고 성장해 나가겠습니다.

감사합니다.

올해 받은 ACE 증명서입니다.

오라클 ACE Directory에 등록된 제 프로필입니다.

참고 : https://ace.oracle.com/ords/ace/profile/nmmmg

오라클 ACE란?

오라클 ACE 프로그램(Oracle ACE Program)은 오라클 기술 및 클라우드 서비스에 대한 뛰어난 전문 지식을 바탕으로, 커뮤니티에서 지식을 공유하고 기여한 외부 전문가들을 발굴해 포상하고 지원하는 오라클 공식 커뮤니티 인정 프로그램임

1. 주요 목적 및 역할
오라클 클라우드 및 기술을 널리 알리고 타인을 돕는 기술 전문가 및 커뮤니티 리더를 발굴함
블로그 작성, 콘퍼런스 발표, 유튜브/팟캐스트 운영, 오라클 포럼 참여 등을 통해 지식을 적극적으로 공유하는 이들을 전 세계에 홍보하고 지원함

2. ACE 프로그램의 4가지 등급
ACE Apprentice (에이스 어프렌티스) : 오라클 기술을 잘 알고 있으나 커뮤니티 활동 및 지식 공유 경험이 적은 입문자를 위한 단계임. 발표나 블로깅 등 역량을 키워 상위 단계로 나아갈 수 있도록 가이드와 마일스톤을 제공함
ACE Associate (에이스 어소시에이트) : 커뮤니티에 기술 콘텐츠를 게시하고 기여하기 시작하여 공식 인정을 받은 초기 전문가 단계
ACE Pro (에이스 프로) : 최소 매달 심도 있는 기술 콘텐츠를 공유하거나, 지역 커뮤니티 행사를 직접 조직하는 등 한층 높은 빈도와 깊이로 기여하는 베테랑 전문가 단계
ACE Director (에이스 디렉터) : 프로그램의 최상위 등급임. 오랜 기간 막대한 커뮤니티 기여를 해왔을 뿐만 아니라, 오라클 제품 관리팀(Product Management)과 직접 소통하며 제품 피드백을 주고받는 핵심 오피니언 리더

3. 주요 혜택
오라클 공식 홈페이지 내 'Oracle ACE 디렉토리'에 개인 프로필 등록 및 소셜 미디어 채널을 통한 활동 홍보 기회를 얻음
오라클 제품 전문가들이 진행하는 독점 제품 브리핑 세션에 초대받음
전용 슬랙(Slack) 채널을 통해 오라클 제품 관리팀 및 전 세계의 ACE 전문가들과 직접 네트워킹할 수 있음
등급에 따른 오라클 공식 디지털 배지, 교육 및 전용 굿즈(Swag) 등을 지급받음

4. 선정 및 유지 기준
만 18세 이상이어야 하며, 정부 기관이나 공공 부문, 특정 헬스케어 및 생명과학 조직의 직원은 참여가 제한됨
추천 및 심사 과정을 거쳐 선발되며, 어워드는 1년 주기로 갱신됨. 매년 커뮤니티 기여 실적을 검토하여 활동 수준에 따라 등급이 조정되거나 Alum(이전 회원)으로 전환될 수 있음

5. 상세 혜택
오라클 ACE 어프렌티스(Apprentice) 혜택
오라클 ACE 프로그램 디렉토리에 온라인 프로필 등록
오라클 유니버시티(Oracle University) 자격증 및 배지 제공
오라클 제품 관리팀과 소통할 수 있는 ACE 어프렌티스 전용 슬랙(Slack) 채널 접속 권한
독점적인 기술 제품 개요 세션 제공
발표, 블로그 작성, 소셜 미디어 프로필 생성 및 극대화 방안 등에 관한 커리어 및 전문 역량 교육 세션 제공
소셜 채널에 공유할 수 있는 멋진 디지털 자산 제공
멘토링 기회 제공

오라클 ACE 어소시에이트(Associate) 혜택
오라클 공식 웹사이트(Oracle.com)에 ACE 회원으로 등재 및 홍보
오라클 ACE 프로그램 디렉토리에 온라인 프로필 등록
X, 링크드인, 페이스북을 포함한 오라클 ACE 소셜 미디어 계정 및 'ACEs in Action' 블로그를 통한 활동 홍보
오라클 자격증 시험 크레딧 제공
디지털 오라클 ACE 어소시에이트 회원 인증서 제공
글로벌 및 가상 오라클 ACE 프로그램 제품 개요 세션과 네트워킹 행사 초대

오라클 ACE 프로(Pro) 혜택

오라클 ACE 어소시에이트(Associate)의 모든 혜택

오라클 ACE 회원 전용 굿즈(Swag) 제공
오라클 AI 월드(Oracle AI World) 컨퍼런스 패스 지급
오라클 클라우드(Oracle Cloud) 계정 제공

오라클 ACE 디렉터(Director) 혜택

오라클 ACE 프로(Pro)의 모든 혜택

오라클 임원진 및 제품 관리 리더들과 함께하는 오라클 ACE 디렉터 전용 제품 브리핑 세션 참여
독점적인 테스트 참여 자격 부여
기술 콘퍼런스 발표 시 여행 경비(출장비) 지원 자격 부여

6. 오라클 ACE가 되는 방법
자기 추천 또는 타인 추천 : 본인이 직접 신청하거나, 기존 ACE 멤버 또는 오라클 직원의 추천을 통해 후보자가 될 수 있음 (공식 홈페이지의 'Become an ACE' 메뉴를 통해 신청 가능함)
활동 증빙 제출 : 지난 12개월 동안 수행한 커뮤니티 기여 활동(블로그 포스팅, 세미나 발표, 오픈소스 기여, 책 집필, 커뮤니티 답변 등)을 정량적/정성적으로 모두 제출해야 함
오라클 위원회 심사 : 제출된 활동 내역을 바탕으로 오라클 ACE 위원회에서 심사를 거쳐 최종 선발함(심사에서 탈락 시 6개월 뒤 재심사 신청 가능함)

참조 :

https://ace.oracle.com/

https://ace.oracle.com/ords/r/ace/oracle-aces/oracle-ace-program-faq

오라클 19c ADG Gap 발생시 rman 증분백업이용 복구 시나리오

내맘대로긍정 — Thu, 11 Jun 2026 21:44:24 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle Database 19.28.0.0

방법 : 오라클 19c ADG Gap 발생시 rman 증분백업이용 복구 시나리오

현재 오라클 19c Restart(ASM) to 싱글(FS) ADG가 구축되어 있는 상태임
참고 : 오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드 ( https://positivemh.tistory.com/1391 )
현재 상태에서 상태에서 네트워크 장애를 발생시키고 강제로 아카이브를 유실시켜 gap을 만들고
이 장애를 해결하기 위해 rman 증분백업을 이용해 복구하는 시나리오를 테스트해봄

테스트
테스트 전 레벨 0 백업 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

$ rman target /
RMAN> backup incremental level 0 database format '/app/oracle/rman/level0_%T_%U';
backup incremental level 0 database format '/app/oracle/rman/level0_%T_%U';
Starting backup at 2026-06-07 21:28:50
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=274 device type=DISK
channel ORA_DISK_1: starting incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=+DATA/ORACLE19/DATAFILE/system.261.1220456359
input datafile file number=00002 name=+DATA/ORACLE19/DATAFILE/sysaux.262.1220456361
input datafile file number=00003 name=+DATA/ORACLE19/DATAFILE/undotbs1.263.1220456361
input datafile file number=00004 name=+DATA/ORACLE19/DATAFILE/users.265.1220456367
channel ORA_DISK_1: starting piece 1 at 2026-06-07 21:28:52
channel ORA_DISK_1: finished piece 1 at 2026-06-07 21:28:59
piece handle=/app/oracle/rman/level0_20260607_0t4q3gsk_29_1_1 tag=TAG20260607T212852 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 2026-06-07 21:28:59
 
Starting Control File and SPFILE Autobackup at 2026-06-07 21:28:59
piece handle=/app/oracle/product/19c/dbs/c-3400652514-20260607-03 comment=NONE
Finished Control File and SPFILE Autobackup at 2026-06-07 21:29:00

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

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

#Primary
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 oracle19                       VALID     OPEN            IDLE                               oracle19
         2 oracle19stb                    VALID     OPEN_READ-ONLY  MANAGED REAL TIME APPLY WITH QUERY oracle19stb                    NO GAP
 
#Standby
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

현재 adg는 정상적인 상태임

Standby db의 네트워크를 잠시 내려놓음(장애 발생 상황 가정)

1
2
3
4
5
6
7
8
9
10

# ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.137.60  netmask 255.255.255.0  broadcast 192.168.137.255
        ether 00:50:56:a8:f1:2c  txqueuelen 1000  (Ethernet)
        RX packets 474857  bytes 8816967143 (8.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 162866  bytes 37564406 (35.8 MiB)
        TX errors 0  dropped 801 overruns 0  carrier 0  collisions 0
 
# nmcli connection down ens160

Primary에서 로그 스위치 수행

1
2
3
4
5
6
7
8
9
10
11

SQL> alter system switch logfile;
 
System altered.
 
SQL> /
 
System altered.
 
SQL> /
 
System altered.

3회 수행함

Primary 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

$ tail -300f /app/oracle/diag/rdbms/oracle19/oracle19/trace/alert_oracle19.log
2026-06-07T21:29:38.684175+09:00
Thread 1 advanced to log sequence 82 (LGWR switch),  current SCN: 1340496
  Current log# 1 seq# 82 mem# 0: +DATA/ORACLE19/ONLINELOG/group_1.258.1235315217
2026-06-07T21:29:38.707115+09:00
ARC3 (PID:121247): Archived Log entry 124 added for B-1220456354.T-1.S-81 LOS:0x000000000014744d NXS:0x0000000000147450 NAB:2 ID 0xcb94dc22 LAD:1
..
2026-06-07T21:30:47.322247+09:00
ARC2 (PID:121245): Error 12543 received logging on to the standby
2026-06-07T21:30:47.366516+09:00
Errors in file /app/oracle/diag/rdbms/oracle19/oracle19/trace/oracle19_arc2_121245.trc:
ORA-12543: TNS:destination host unreachable
ARC2 (PID:121245): FAL: Error 12543 creating remote archived redo log file 'oracle19stb'
ARC2 (PID:121245): FAL archive failed with error 12543 (see trace for details)
ARC2 (PID:121245): FAL archive failed, archiver continuing
2026-06-07T21:30:47.380851+09:00
ORACLE Instance oracle19, archival error, archiver continuing
2026-06-07T21:30:47.380925+09:00
ORA-16055: FAL request rejected
2026-06-07T21:30:47.381109+09:00
Errors in file /app/oracle/diag/rdbms/oracle19/oracle19/trace/oracle19_arc2_121245.trc:
ORA-16055: FAL request rejected
..
2026-06-07T21:33:50.892878+09:00
TMON (PID:121142): Process (PID:121237) hung on an I/O to LAD:2 after 260 seconds with threshold of 240 at [krsu.c:10195]
TMON (PID:121142): WARN: Terminating process hung on an operation (PID:121237)
2026-06-07T21:33:52.974584+09:00
TMON (PID:121142): Process (PID:121243) hung on an I/O to LAD:2 after 254 seconds with threshold of 240 at [krsu.c:10195]
TMON (PID:121142): WARN: Terminating process hung on an operation (PID:121243)
2026-06-07T21:33:57.087569+09:00
TMON (PID:121142): Killing 1 processes (PIDS:121237) (Process by index) in order to remove hung processes. Requested by OS process 121142
2026-06-07T21:33:57.088623+09:00
Process termination requested for pid 121237 [source = rdbms], [info = 2] [request issued by pid: 121142, uid: 54321]
2026-06-07T21:34:01.113679+09:00
TMON (PID:121142): Killing 1 processes (PIDS:121243) (Process by index) in order to remove hung processes. Requested by OS process 121142
2026-06-07T21:34:01.124937+09:00
Process termination requested for pid 121243 [source = rdbms], [info = 2] [request issued by pid: 121142, uid: 54321]
..
2026-06-07T21:34:03.142751+09:00
TMON (PID:121142): Detected ARCH process failure
TMON (PID:121142): STARTING ARCH PROCESSES
Starting background process ARC1
2026-06-07T21:34:03.162404+09:00
ARC1 started with pid=43, OS id=125682
TMON (PID:121142): ARC1: Archival started
TMON (PID:121142): STARTING ARCH PROCESSES COMPLETE
2026-06-07T21:34:03.180846+09:00
ARC1 (PID:125682): FAIL: Reclaiming FAL entry from dead process (PID:121243)
ARC1 (PID:125682): FAL archive failed with error 12609 (see trace for details)
ARC1 (PID:125682): FAL archive failed, archiver continuing
2026-06-07T21:34:03.236481+09:00
ORACLE Instance oracle19, archival error, archiver continuing
2026-06-07T21:34:03.236596+09:00
ORA-16055: FAL request rejected
2026-06-07T21:34:03.236825+09:00
Errors in file /app/oracle/diag/rdbms/oracle19/oracle19/trace/oracle19_arc1_125682.trc:
ORA-16055: FAL request rejected
2026-06-07T21:34:21.194499+09:00
TT00 (PID:125789): Gap Manager starting

시퀀스 82까지 생성되었지만 네트워크 문제로 전송실패함
그리고 arch 프로세스도 행걸려서 자동으로 종료되었다가 다시 시작됨

Standby로 넘어가지 못한 아카이브 로그 제거 시도

1
2
3
4
5
6
7
8
9
10
11
12
13

RMAN> delete noprompt archivelog all;
delete noprompt archivelog all;
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=51 device type=DISK
RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_79.307.1235338177 thread=1 sequence=79
RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_80.303.1235338179 thread=1 sequence=80
RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_81.308.1235338179 thread=1 sequence=81
RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_82.300.1235338343 thread=1 sequence=82

rman에서 제거하려니 실패함(오라클이 실수를 막아줌)

asmcmd에서 확인해도 아카이브로그가 안지워졌음

1
2
3
4
5
6
7
8
9

$ . oraenv
ORACLE_SID = [oracle19] ? +ASM
The Oracle base remains unchanged with value /app/oracle
 
ASMCMD [+data/oracle19/archivelog/2026_06_07] > ls
thread_1_seq_79.307.1235338177  <<-- !! 제거 예정
thread_1_seq_80.303.1235338179  <<-- !! 제거 예정
thread_1_seq_81.308.1235338179
thread_1_seq_82.300.1235338343

테스트를 위해 시퀀스 66 아카이브 로그 수동으로 삭제

1
2
3
4
5

ASMCMD [+data/oracle19/archivelog/2026_06_07] > rm thread_1_seq_79.307.1235338177
ASMCMD [+data/oracle19/archivelog/2026_06_07] > rm thread_1_seq_80.303.1235338179
ASMCMD [+data/oracle19/archivelog/2026_06_07] > ls
thread_1_seq_81.308.1235338179
thread_1_seq_82.300.1235338343

시퀀스 79,80을 지움

현재 상황
Primary에서 아카이브로그 시퀀스 79부터 82까지가 생성되었고
여기서 시퀀스 79,80을 지워버린 상태
Standby 네트워크를 정상화 시켜도 아카이브로그는 순차적으로 적용해야하기 때문에
시퀀스 79,80이 없어서 시퀀스 81,82를 Standby에 적용할수가 없음

Standby 네트워크 정상화

1
2
3
4
5
6
7
8
9
10

# ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.137.60  netmask 255.255.255.0  broadcast 192.168.137.255
        ether 00:50:56:a8:f1:2c  txqueuelen 1000  (Ethernet)
        RX packets 474857  bytes 8816967143 (8.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 162866  bytes 37564406 (35.8 MiB)
        TX errors 0  dropped 801 overruns 0  carrier 0  collisions 0
 
# nmcli connection up ens160

Standby mrp 프로세스 재시작

1
2
3
4
5
6
7

SQL> alter database recover managed standby database cancel;
 
Database altered.
 
SQL> alter database recover managed standby database disconnect from session;
 
Database altered.

아카이브 갭 확인

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

#Primary
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 oracle19                       VALID     OPEN            IDLE                               oracle19
         2 oracle19stb                    ERROR     OPEN_READ-ONLY  MANAGED REAL TIME APPLY WITH QUERY oracle19stb                    RESOLVABLE GAP  <<--!!
 
#Standby
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

Primary에서 Standby db 상태를 보면 처음에 ERROR임 잠시 뒤 VALID로 변경됨
하지만 GAP_STATUS는 UNRESOLVABLE GAP임

Standby에서 아카이브 갭 시퀀스 확인

1
2
3
4
5

SQL> select * from v$archive_gap;
 
   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#     CON_ID
---------- ------------- -------------- ----------
         1            79             80          1

시퀀스 79(low),80(high)이 필요한 상태임

Standby에서 마지막으로 적용한 아카이브로그 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SQL>
select thread#, sequence#, first_change#, next_change#, applied 
from v$archived_log 
where applied = 'YES' 
order by sequence# desc;
 
   THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APPLIED
---------- ---------- ------------- ------------ ---------
         1         78       1339005      1340309 YES
         1         77       1337012      1339005 YES
         1         76       1336774      1337012 YES
         1         75       1336765      1336774 YES
         1         74       1336762      1336765 YES
         1         73       1336480      1336762 YES
         1         72       1336475      1336480 YES
         1         71       1336465      1336475 YES
         1         70       1336439      1336465 YES
         1         69       1334609      1336439 YES
 
10 rows selected.

78번까지 적용되어 있음

Primary alert log에 아래와 같이 에러가 남음

1
2
3
4
5
6

$ tail -300f /app/oracle/diag/rdbms/oracle19/oracle19/trace/alert_oracle19.log
2026-06-07T21:40:23.169886+09:00
Errors in file /app/oracle/diag/rdbms/oracle19/oracle19/trace/oracle19_tt00_125789.trc:
ORA-00308: cannot open archived log '+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_79.307.1235338177'
ORA-17503: ksfdopn:2 Failed to open file +DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_79.307.1235338177
ORA-15012: ASM file '+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_79.307.1235338177' does not exist

해결
아카이브로그 백업이 있다면 해당 아카이브를 적용하면 아래 명령으로 적용하면되지만

1

SQL> alter database register logfile '/tmp/arch_stb/아카이브로그파일명.arc';

현재는 아카이브로그 백업이 없기 때문에 rman 증분백업으로 복구를 수행해봄
이전 게시글에선 rman duplicate로 새로 adg를 구축했었음
참고 : 오라클 19c ADG Gap 발생시 rman duplicate 재수행 시나리오 ( https://positivemh.tistory.com/1392 )

Standby 서버에서 현재 SCN 확인

1
2
3
4
5

SQL> select current_scn from v$database;
 
CURRENT_SCN
-----------
    1340462

Primary 서버에서 해당 SCN 이후의 변경분 백업 생성

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

$ rman target /
RMAN> backup incremental from scn 1340462 database format '/app/oracle/rman/stb_inc_%u' tag 'for_stb_gap';
backup incremental from scn 1340462 database format '/app/oracle/rman/stb_inc_%u' tag 'for_stb_gap';
Starting backup at 2026-06-07 21:41:38
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=280 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=+DATA/ORACLE19/DATAFILE/system.261.1220456359
input datafile file number=00002 name=+DATA/ORACLE19/DATAFILE/sysaux.262.1220456361
input datafile file number=00003 name=+DATA/ORACLE19/DATAFILE/undotbs1.263.1220456361
input datafile file number=00004 name=+DATA/ORACLE19/DATAFILE/users.265.1220456367
channel ORA_DISK_1: starting piece 1 at 2026-06-07 21:41:39
channel ORA_DISK_1: finished piece 1 at 2026-06-07 21:41:42
piece handle=/app/oracle/rman/stb_inc_0v4q3hkj tag=FOR_STB_GAP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 2026-06-07 21:41:43
channel ORA_DISK_1: finished piece 1 at 2026-06-07 21:41:44
piece handle=/app/oracle/rman/stb_inc_104q3hkm tag=FOR_STB_GAP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2026-06-07 21:41:44

백업이 완료됨

스탠바이용 컨트롤파일도 백업

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

RMAN> backup current controlfile for standby format '/app/oracle/rman/stb_ctl.bck';
backup current controlfile for standby format '/app/oracle/rman/stb_ctl.bck';
Starting backup at 2026-06-07 21:42:04
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including standby control file in backup set
channel ORA_DISK_1: starting piece 1 at 2026-06-07 21:42:05
channel ORA_DISK_1: finished piece 1 at 2026-06-07 21:42:06
piece handle=/app/oracle/rman/stb_ctl.bck tag=TAG20260607T214204 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2026-06-07 21:42:06
 
Starting Control File and SPFILE Autobackup at 2026-06-07 21:42:06
piece handle=/app/oracle/product/19c/dbs/c-3400652514-20260607-04 comment=NONE
Finished Control File and SPFILE Autobackup at 2026-06-07 21:42:07

백업이 완료됨

생성된 증분백업 파일들과 컨트롤파일 백업파일을 Standby 서버로 전송

1
2
3
4
5
6

$ cd /app/oracle/rman
$ scp stb_* 192.168.137.60:/app/oracle/rman2/
oracle@192.168.137.60's password:
stb_ctl.bck                                    100%   10MB 250.7MB/s   00:00
stb_inc_0v4q3hkj                               100%  896KB 243.5MB/s   00:00
stb_inc_104q3hkm                               100%   10MB 288.5MB/s   00:00

Standby 서버에서 MRP 중지

1
2
3

SQL> alter database recover managed standby database cancel;
 
Database altered.

Standby DB 중지 후 nomount 기동

1
2

SQL> shutdown immediate
SQL> startup nomount

Standby 서버에서 컨트롤파일 먼저 복구

1
2
3
4
5
6
7
8
9
10
11

RMAN> restore standby controlfile from '/app/oracle/rman2/stb_ctl.bck';
restore standby controlfile from '/app/oracle/rman2/stb_ctl.bck';
Starting restore at 2026-06-07 21:17:02
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
 
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/app/oracle/oradata/oracle19stb/control01.ctl
Finished restore at 2026-06-07 21:17:04

mount로 변경

1

RMAN> alter database mount;

Standby 서버에서 백업파일 카탈로깅(등록)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

RMAN> catalog start with '/app/oracle/rman2';
catalog start with '/app/oracle/rman2';
using target database control file instead of recovery catalog
searching for all files that match the pattern /app/oracle/rman2
 
List of Files Unknown to the Database
=====================================
File Name: /app/oracle/rman2/stb_ctl.bck
File Name: /app/oracle/rman2/stb_inc_0v4q3hkj
File Name: /app/oracle/rman2/stb_inc_104q3hkm
 
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
 
List of Cataloged Files
=======================
File Name: /app/oracle/rman2/stb_ctl.bck
File Name: /app/oracle/rman2/stb_inc_0v4q3hkj
File Name: /app/oracle/rman2/stb_inc_104q3hkm

Standby 서버에서 증분 백업 적용

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

RMAN> recover database noredo;
recover database noredo;
Starting recover at 2026-06-07 21:18:47
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /app/oracle/oradata/oracle19stb/system.261.1220456359
destination for restore of datafile 00002: /app/oracle/oradata/oracle19stb/sysaux.262.1220456361
destination for restore of datafile 00003: /app/oracle/oradata/oracle19stb/undotbs1.263.1220456361
destination for restore of datafile 00004: /app/oracle/oradata/oracle19stb/users.265.1220456367
channel ORA_DISK_1: reading from backup piece /app/oracle/rman/stb_inc_0v4q3hkj
channel ORA_DISK_1: errors found reading piece handle=/app/oracle/rman/stb_inc_0v4q3hkj
channel ORA_DISK_1: failover to piece handle=/app/oracle/rman2/stb_inc_0v4q3hkj tag=FOR_STB_GAP
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
 
Finished recover at 2026-06-07 21:18:49

정상적으로 복구됨

alter log 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
2026-06-07T21:18:48.559761+09:00
Restore from backup piece /app/oracle/rman/stb_inc_0v4q3hkj
Restore from backup piece /app/oracle/rman2/stb_inc_0v4q3hkj
Cannot read block 1 from /app/oracle/rman/stb_inc_0v4q3hkj - restore failover to read from /app/oracle/rman2/stb_inc_0v4q3hkj
ORA-19505: failed to identify file "/app/oracle/rman/stb_inc_0v4q3hkj"
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 7
 
Incremental restore complete of datafile 4 /app/oracle/oradata/oracle19stb/users.265.1220456367
  checkpoint is 1341720
  last deallocation scn is 3
Incremental restore complete of datafile 3 /app/oracle/oradata/oracle19stb/undotbs1.263.1220456361
  checkpoint is 1341720
  last deallocation scn is 1316171
Incremental restore complete of datafile 2 /app/oracle/oradata/oracle19stb/sysaux.262.1220456361
  checkpoint is 1341720
  last deallocation scn is 868405
Incremental restore complete of datafile 1 /app/oracle/oradata/oracle19stb/system.261.1220456359
  checkpoint is 1341720
  last deallocation scn is 1340053

정상적으로 checkpoint 1341720 까지 복구됨(참고로 증분백업 적용전 scn은 1340462 였음)

db open 상태로 변경

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.

mrp 기동됨

아카이브 갭 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#Primary
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 oracle19                       VALID     OPEN            IDLE                               oracle19
         2 oracle19stb                    VALID     OPEN_READ-ONLY  MANAGED REAL TIME APPLY WITH QUERY oracle19stb                    NO GAP  <<--!!
 
#Standby
SQL> 
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

GAP_STATUS가 UNRESOLVABLE GAP에서 NO GAP로 변경됨

Standby에서 아카이브 갭 시퀀스 확인

1
2
3

SQL> select * from v$archive_gap;
 
no rows selected

no rows로 표시됨

Standby에서 마지막으로 적용한 아카이브로그 확인

1
2
3
4
5
6
7
8
9

SQL>
select thread#, sequence#, first_change#, next_change#, applied 
from v$archived_log 
where applied = 'YES' 
order by sequence# desc;
 
   THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APPLIED
---------- ---------- ------------- ------------ ---------
         1         86       1343778      1343783 YES

정상적으로 86번 시퀀스까지 아카이브를 적용함

87번 시퀀스는 현재 Standby에서 ACTIVE redo임

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SQL> 
set lines 200
set pages 1000
col member for a60
select thread#, l.group#, member, archived, l.status, (bytes/1024/1024) MB, sequence#
from v$standby_log l, v$logfile f
where f.group# = l.group#
order by 1, 2;
 
   THREAD#     GROUP# MEMBER                                                       ARC STATUS             MB  SEQUENCE#
---------- ---------- ------------------------------------------------------------ --- ---------- ---------- ----------
         0          5 /app/oracle/oradata/oracle19stb/group_5.285.1235315381       YES UNASSIGNED        200          0
         1          4 /app/oracle/oradata/oracle19stb/group_4.284.1235315377       YES ACTIVE            200         87
         1          6 /app/oracle/oradata/oracle19stb/group_6.286.1235315381       NO  UNASSIGNED        200          0

추가
Standby alert을 보니 아래 에러가 발생했음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
2026-06-07T21:50:19.632484+09:00
 rfs (PID:70868): SRL LNO:5 needs clearing because log has not been created
2026-06-07T21:50:19.632605+09:00
Errors in file /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/oracle19stb_rfs_70868.trc:
ORA-00367: checksum error in log file header
ORA-00315: log 5 of thread 0, wrong thread # 1 in header
ORA-00312: online log 5 thread 0: '/app/oracle/oradata/oracle19stb/group_5.285.1235315381'
2026-06-07T21:50:19.640985+09:00
ARC1 (PID:67420): Archived Log entry 4 added for B-1220456354.T-1.S-87 LOS:0x0000000000148127 NXS:0x0000000000149199 NAB:10648 ID 0xcb94dc22 LAD:1
2026-06-07T21:50:19.641153+09:00
 rfs (PID:70868): Selected LNO:6 for T-1.S-88 dbid 3400652514 branch 1220456354
2026-06-07T21:50:19.697485+09:00
PR00 (PID:71329): Media Recovery Waiting for T-1.S-88 (in transit)
2026-06-07T21:50:19.698260+09:00
Recovery of Online Redo Log: Thread 1 Group 6 Seq 88 Reading mem 0
  Mem# 0: /app/oracle/oradata/oracle19stb/group_6.286.1235315381

그룹 5번 redo 헤더에 문제가 있는듯함

추후 참고용 trc 파일

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

$ cat /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/oracle19stb_rfs_70868.trc
Trace file /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/oracle19stb_rfs_70868.trc
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.28.0.0.0
Build label:    RDBMS_19.28.0.0.0DBRU_LINUX.X64_250704
ORACLE_HOME:    /app/oracle/product/19c
System name:    Linux
Node name:      ora19stb
Release:        6.12.0-1.23.3.2.el9uek.x86_64
Version:        #1 SMP PREEMPT_DYNAMIC Tue May 13 17:24:00 PDT 2025
Machine:        x86_64
CLID:   P
Instance name: oracle19stb
Instance number: 1
Database name: oracle19
Database unique name: oracle19stb
Database id: 3400652514
Database role: PHYSICAL STANDBY
Redo thread mounted by this instance: 1
Oracle process number: 46
Unix process pid: 70868, image: oracle@ora19stb
 
 
*** 2026-06-07T21:25:46.590398+09:00
*** SESSION ID:(26.40508) 2026-06-07T21:25:46.590416+09:00
*** CLIENT ID:() 2026-06-07T21:25:46.590421+09:00
*** SERVICE NAME:(oracle19stb) 2026-06-07T21:25:46.590424+09:00
*** MODULE NAME:(oracle@ora19 (TNS V1-V3)) 2026-06-07T21:25:46.590428+09:00
*** ACTION NAME:() 2026-06-07T21:25:46.590431+09:00
*** CLIENT DRIVER:() 2026-06-07T21:25:46.590446+09:00
 
*** 2026-06-07 21:25:46.590061 [krsh.c:6437]
krsr_rfs_atc: Identified database type as 'PHYSICAL': Client is ASYNC (PID:121251)
*** 2026-06-07 21:25:46.598325 [krsr.c:17303]
krsr_dump_alert_msg: Header received for LNO:4 T-1.S-85 dbid 3400652514 branch 1220456354
 
*** 2026-06-07T21:25:47.007061+09:00
*** 2026-06-07 21:25:47.007050 [krsr.c:17315]
krsr_dump_alert_msg: Archival completed for LNO:4 T-1.S-85 dbid 3400652514 branch 1220456354
DDE rules only execution for: ORA 312
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
Executing SYNC actions
----- START DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) -----
Successfully dispatched
----- END DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (SUCCESS, 0 csec) -----
Executing ASYNC actions
----- END DDE Actions Dump (total 0 csec) -----
krsk_rlf_need_clearing: SRL LNO:5 needs clearing because log has not been created
<error barrier> at 0x7ffc85c73090 placed krsk.c@11442
ORA-00367: checksum error in log file header
ORA-00315: log 5 of thread 0, wrong thread # 1 in header
ORA-00312: online log 5 thread 0: '/app/oracle/oradata/oracle19stb/group_5.285.1235315381'
*** 2026-06-07 21:25:47.025225 [krsr.c:17303]
krsr_dump_alert_msg: Header received for LNO:6 T-1.S-86 dbid 3400652514 branch 1220456354
 
*** 2026-06-07T21:25:48.761255+09:00
*** 2026-06-07 21:25:48.761236 [krsr.c:17315]
krsr_dump_alert_msg: Archival completed for LNO:6 T-1.S-86 dbid 3400652514 branch 1220456354
*** 2026-06-07 21:25:48.777459 [krsr.c:17303]
krsr_dump_alert_msg: Header received for LNO:4 T-1.S-87 dbid 3400652514 branch 1220456354
 
*** 2026-06-07T21:50:19.622578+09:00
*** 2026-06-07 21:50:19.622558 [krsr.c:17315]
krsr_dump_alert_msg: Archival completed for LNO:4 T-1.S-87 dbid 3400652514 branch 1220456354
DDE rules only execution for: ORA 312
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
Executing SYNC actions
----- START DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) -----
Successfully dispatched
----- END DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (SUCCESS, 0 csec) -----
Executing ASYNC actions
----- END DDE Actions Dump (total 0 csec) -----
krsk_rlf_need_clearing: SRL LNO:5 needs clearing because log has not been created
<error barrier> at 0x7ffc85c73090 placed krsk.c@11442
ORA-00367: checksum error in log file header
ORA-00315: log 5 of thread 0, wrong thread # 1 in header
ORA-00312: online log 5 thread 0: '/app/oracle/oradata/oracle19stb/group_5.285.1235315381'
*** 2026-06-07 21:50:19.645413 [krsr.c:17303]
krsr_dump_alert_msg: Header received for LNO:6 T-1.S-88 dbid 3400652514 branch 1220456354

Standby쪽 redo이기 때문에 지금 clear 해주어도됨
MRP 중지

1
2
3
4

XGUBUNX
SQL> alter database recover managed standby database cancel;
 
Database altered.

그룹 5번 redo 로그 clear 수행

1
2
3

SQL> alter database clear logfile group 5;
 
Database altered.

alert log 확인

1
2
3
4
5
6
7
8
9
10
11
12

$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
2026-06-07T21:53:51.445616+09:00
Errors in file /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/oracle19stb_ora_69849.trc:
ORA-00367: checksum error in log file header
ORA-00315: log 5 of thread 0, wrong thread # 1 in header
ORA-00312: online log 5 thread 0: '/app/oracle/oradata/oracle19stb/group_5.285.1235315381'
Completed: alter database clear logfile group 5
2026-06-07T21:54:09.065466+09:00
alter database clear logfile group 5
2026-06-07T21:54:09.065747+09:00
Clearing online log 5 of thread 0 sequence number 0
Completed: alter database clear logfile group 5

한번 수행했을때 alert에 에러가 나는것 같아서 한번더 수행해봤음, clear가 잘 된듯함

MRP 시작

1
2
3

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

Primary에서 데이터 생성 및 로그 스위치시 정상적으로 Standby alert에 5번 그룹 리두를 사용하는게 확인됨

1
2
3
4
5
6
7
8
9
10

$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
2026-06-07T21:58:20.234438+09:00
 rfs (PID:70868): Selected LNO:5 for T-1.S-93 dbid 3400652514 branch 1220456354
2026-06-07T21:58:20.266740+09:00
PR00 (PID:81814): Media Recovery Waiting for T-1.S-93 (in transit)
2026-06-07T21:58:20.267881+09:00
Recovery of Online Redo Log: Thread 1 Group 5 Seq 93 Reading mem 0  <<--!!
  Mem# 0: /app/oracle/oradata/oracle19stb/group_5.285.1235315381  <<--!!
2026-06-07T21:58:20.808471+09:00
ARC0 (PID:67414): Archived Log entry 9 added for B-1220456354.T-1.S-92 LOS:0x000000000014947d NXS:0x00000000001496ec NAB:389116 ID 0xcb94dc22 LAD:1

결론 :
adg 환경에서 gap이 너무 많이 생기거나 아카이브로그가 유실된 경우 본문과 같은 방식으로
증분백업을 이용하여 정상화시킬 수 있음

참조 :

오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드 ( https://positivemh.tistory.com/1391 )

오라클 19c ADG Gap 발생시 rman duplicate 재수행 복구 시나리오 ( https://positivemh.tistory.com/1392 )

Oracle Linux 8.4에 Oracle 19c ADG 설치 가이드_Part 1 ( https://positivemh.tistory.com/819 )
Oracle Linux 8.4에 Oracle 19c RAC to RAC ADG 설치 가이드_Part 1 ( https://positivemh.tistory.com/824 )
https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-role-transitions.html#GUID-AAD70601-D248-4309-B8DD-F461EE31A5FF
https://docs.oracle.com/en/database/oracle/oracle-database/19/spmss/switchover-to-a-physical-db.html#GUID-AAD70601-D248-4309-B8DD-F461EE31A5FF

Oracle Linux 8 grep 또는 find 명령 특정 단어 들어간 파일 찾기

내맘대로긍정 — Thu, 11 Jun 2026 21:37:43 +0900

OS 환경 : Oracle Linux 8.7 (64bit)

방법 : Oracle Linux 8 grep 또는 find 명령 특정 단어 들어간 파일 찾기

테스트를 하면서 10053 트레이스가 많이 생김
이중에서 특정 단어를 포함하는 파일을 찾기위해 사용한 명령어임
Costing group-by pushdown 이라는 문장이 들어간 파일을 ls -ltr로 조회

1
2

$ grep -rl --include="*10053*.trc" 'Costing group-by pushdown:' . | xargs ls -ltr
-rw-r----- 1 oracle oinstall 135820 May 28 16:28 ./ORA19DBFS_ora_3070952_10053_1.trc

그외 다양한 검색 명령어

매칭된 단어의 라인넘버 확인

1
2

$ grep -rn --include="*10053*.trc" 'Costing group-by pushdown:' .
./ORA19DBFS_ora_3070952_10053_1.trc:1170:Costing group-by pushdown:

매칭된 단어의 앞뒤 흐름 확인

1
2
3
4
5
6
7
8
9

$ grep -rn -A 5 -B 2 --include="*10053*.trc" 'Costing group-by pushdown:' .
./ORA19DBFS_ora_3070952_10053_1.trc-1168-GROUP BY/Correlated Subquery Filter adjustment factor: 1.000000
./ORA19DBFS_ora_3070952_10053_1.trc-1169-GROUP BY cardinality:  100.000000, TABLE cardinality:  100.000000
./ORA19DBFS_ora_3070952_10053_1.trc:1170:Costing group-by pushdown:
./ORA19DBFS_ora_3070952_10053_1.trc-1171-Vector group by not costed because no SYS_OP_XLATE_USE in group by.
./ORA19DBFS_ora_3070952_10053_1.trc-1172-    SORT ressource         Sort statistics
./ORA19DBFS_ora_3070952_10053_1.trc-1173-      Sort width:         598 Area size:      831488 Max Area size:   104857600
./ORA19DBFS_ora_3070952_10053_1.trc-1174-      Degree:               1
./ORA19DBFS_ora_3070952_10053_1.trc-1175-      Blocks to Sort: 1 Row size:     14 Total Rows:             25

옵션 설명
-B 2 (Before) : 매칭된 라인 앞으로 2줄 더 출력
-A 5 (After) : 매칭된 라인 뒤로 5줄 더 출력
-C 3 (Context) : 앞뒤로 똑같이 3줄씩 더 출력할 때 사용

검색어 주변 내용 실시간으로 넘겨가며 보기

1

$ grep -rl --include="*10053*.trc" 'Costing group-by pushdown:' . | xargs less +/'Costing group-by pushdown:'

대소문자 구분 없이 검색

1
2

$ grep -rn -i --include="*10053*.trc" 'costing group-by pushdown' .
./ORA19DBFS_ora_3070952_10053_1.trc:1170:Costing group-by pushdown:

매칭된 단어가 '몇 번'이나 나왔는지 카운트

1
2

$ grep -c 'Costing group-by pushdown:' ./ORA19DBFS_ora_3070952_10053_1.trc
1

alert log 같은 특정 파일에서 ORA-로 시작하는 라인 검색(앞에 공백이 있는 ORA는 제외)(앞 3줄까지 같이 나오게)

1

$ grep -B 3 '^ORA-' alert_ORA19DBFS.log

특정 파일명 검색

1

$ find . -type f -name '*alert*.log'

참조 :

오라클 19c ADG Gap 발생시 rman duplicate 재수행 복구 시나리오

내맘대로긍정 — Mon, 8 Jun 2026 06:46:33 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle Database 19.28.0.0

방법 : 오라클 19c ADG Gap 발생시 rman duplicate 재수행 복구 시나리오

현재 오라클 19c Restart(ASM) to 싱글(FS) ADG가 구축되어 있는 상태임
참고 : 오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드 ( https://positivemh.tistory.com/1391 )
현재 상태에서 네트워크 장애를 발생시키고 강제로 아카이브를 유실시켜 gap을 만들고
이 장애를 해결하기 위해 rman duplicate를 재수행하는 시나리오를 테스트해봄

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

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

#Primary
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 oracle19                       VALID     OPEN            IDLE                               oracle19
         2 oracle19stb                    VALID     OPEN_READ-ONLY  MANAGED REAL TIME APPLY WITH QUERY oracle19stb                    NO GAP
 
#Standby
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

현재 adg는 정상적인 상태임

Standby db의 네트워크를 잠시 내려놓음(장애 발생 상황 가정)

1
2
3
4
5
6
7
8
9
10

# ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.137.60  netmask 255.255.255.0  broadcast 192.168.137.255
        ether 00:50:56:a8:f1:2c  txqueuelen 1000  (Ethernet)
        RX packets 474857  bytes 8816967143 (8.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 162866  bytes 37564406 (35.8 MiB)
        TX errors 0  dropped 801 overruns 0  carrier 0  collisions 0
 
# nmcli connection down ens160

Primary에서 로그 스위치 수행

1
2
3
4
5
6
7
8
9
10
11

SQL> alter system switch logfile;
 
System altered.
 
SQL> /
 
System altered.
 
SQL> /
 
System altered.

3회 수행함

Primary alert log에 아래와 같이 에러가 남음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$ tail -300f /app/oracle/diag/rdbms/oracle19/oracle19/trace/alert_oracle19.log
2026-06-07T20:04:23.853966+09:00
Errors in file /app/oracle/diag/rdbms/oracle19/oracle19/trace/oracle19_tt02_85677.trc:
ORA-16038: log 3 sequence# 60 cannot be archived
2026-06-07T20:04:23.854554+09:00
Errors in file /app/oracle/diag/rdbms/oracle19/oracle19/trace/oracle19_tt02_85677.trc:
ORA-16038: log 3 sequence# 60 cannot be archived <<--!!
2026-06-07T20:06:26.472711+09:00
TMON (PID:44675): Process (PID:44782) hung on an I/O to LAD:2 after 270 seconds with threshold of 240 at [krsu.c:10195]
TMON (PID:44675): WARN: Terminating process hung on an operation (PID:44782)
2026-06-07T20:06:30.669332+09:00
TMON (PID:44675): Killing 1 processes (PIDS:44782) (Process by index) in order to remove hung processes. Requested by OS process 44675
2026-06-07T20:06:30.670125+09:00
Process termination requested for pid 44782 [source = rdbms], [info = 2] [request issued by pid: 44675, uid: 54321]
2026-06-07T20:06:32.710569+09:00
TT00 (PID:98288): Gap Manager starting

시퀀스 60을 아카이브하지 못했다고 나옴(Standby로 전송하지 못했다는 말로 보임)

Standby로 넘어가지 못한 아카이브 로그 제거 시도

1
2
3
4
5
6
7
8
9
10
11

RMAN> delete noprompt archivelog all;
delete noprompt archivelog all;
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=52 device type=DISK
RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_60.308.1235333037 thread=1 sequence=60
RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_61.307.1235333037 thread=1 sequence=61
RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_62.303.1235333043 thread=1 sequence=62

rman에서 제거하려니 실패함(오라클이 실수를 막아줌)

asmcmd에서 확인해도 아카이브로그가 안지워졌음

1
2
3
4
5
6
7
8

$ . oraenv
ORACLE_SID = [oracle19] ? +ASM
The Oracle base remains unchanged with value /app/oracle
 
ASMCMD [+data/oracle19/archivelog/2026_06_07] > ls
thread_1_seq_60.308.1235333037  <<-- !! 제거 예정
thread_1_seq_61.307.1235333037
thread_1_seq_62.303.1235333043

테스트를 위해 시퀀스 60 아카이브 로그 수동으로 삭제

1
2
3
4

ASMCMD [+data/oracle19/archivelog/2026_06_07] > rm thread_1_seq_60.308.1235333037
ASMCMD [+data/oracle19/archivelog/2026_06_07] > ls
thread_1_seq_61.307.1235333037
thread_1_seq_62.303.1235333043

시퀀스 60을 지움

현재 상황
Primary에서 아카이브로그 시퀀스 60부터 62까지가 생성되었고
여기서 시퀀스 60을 지워버린 상태
Standby 네트워크를 정상화 시켜도 아카이브로그는 순차적으로 적용해야하기 때문에
시퀀스 60이 없어서 시퀀스 61, 62를 Standby에 적용할수가 없음

Standby 네트워크 정상화

1
2
3
4
5
6
7
8
9
10

# ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.137.60  netmask 255.255.255.0  broadcast 192.168.137.255
        ether 00:50:56:a8:f1:2c  txqueuelen 1000  (Ethernet)
        RX packets 474857  bytes 8816967143 (8.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 162866  bytes 37564406 (35.8 MiB)
        TX errors 0  dropped 801 overruns 0  carrier 0  collisions 0
 
# nmcli connection up ens160

Standby mrp 프로세스 재시작

1
2
3
4
5
6
7

SQL> alter database recover managed standby database cancel;
 
Database altered.
 
SQL> alter database recover managed standby database disconnect from session;
 
Database altered.

아카이브 갭 확인

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

#Primary
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 oracle19                       VALID     OPEN            IDLE                               oracle19
         2 oracle19stb                    VALID     OPEN_READ-ONLY  MANAGED REAL TIME APPLY WITH QUERY oracle19stb                    UNRESOLVABLE GAP  <<--!!
 
#Standby
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

Primary에서 Standby db 상태(STATUS)를 보면 처음에 ERROR 였다가 지금은 VALID로 변경되었음
하지만 여전히 GAP_STATUS는 UNRESOLVABLE GAP임

Standby에서 아카이브 갭 시퀀스 확인

1
2
3
4
5

SQL> select * from v$archive_gap;
 
   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#     CON_ID
---------- ------------- -------------- ----------
         1            60             60          1

시퀀스 60번이 필요한 상태임

Standby에서 마지막으로 적용한 아카이브로그 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

SQL>
select thread#, sequence#, first_change#, next_change#, applied 
from v$archived_log 
where applied = 'YES' 
order by sequence# desc;
 
   THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APPLIED
---------- ---------- ------------- ------------ ---------
         1         59       1327468      1327670 YES
         1         58       1327243      1327468 YES
         1         57       1327023      1327243 YES
         1         56       1326807      1327023 YES
         1         55       1326591      1326807 YES
         1         54       1326375      1326591 YES
         1         53       1326157      1326375 YES
         1         52       1325916      1326157 YES
         1         51       1325706      1325916 YES
         1         50       1325486      1325706 YES
         1         49       1325253      1325486 YES
         1         48       1325039      1325253 YES
         1         47       1324821      1325039 YES
..

59번까지 적용되어 있음

Primary alert log에 아래와 같이 에러가 남음

1
2
3
4
5
6
7
8
9
10
11

$ tail -300f /app/oracle/diag/rdbms/oracle19/oracle19/trace/alert_oracle19.log
2026-06-07T20:18:42.206843+09:00
Thread 1 advanced to log sequence 64 (LGWR switch),  current SCN: 1331051
  Current log# 1 seq# 64 mem# 0: +DATA/ORACLE19/ONLINELOG/group_1.258.1235315217
2026-06-07T20:18:42.889785+09:00
ARC0 (PID:44780): Archived Log entry 90 added for B-1220456354.T-1.S-63 LOS:0x0000000000144a38 NXS:0x0000000000144f6b NAB:104278 ID 0xcb94dc22 LAD:1
2026-06-07T20:19:39.651320+09:00
Errors in file /app/oracle/diag/rdbms/oracle19/oracle19/trace/oracle19_tt00_98288.trc:
ORA-00308: cannot open archived log '+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_60.308.1235333037'
ORA-17503: ksfdopn:2 Failed to open file +DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_60.308.1235333037
ORA-15012: ASM file '+DATA/ORACLE19/ARCHIVELOG/2026_06_07/thread_1_seq_60.308.1235333037' does not exist

해결
아카이브로그 백업이 있다면 해당 아카이브를 적용하면 아래 명령으로 적용하면되지만

1

SQL> alter database register logfile '/tmp/arch_stb/아카이브로그파일명.arc';

현재는 아카이브로그 백업이 없기 때문에 rman duplicate를 재수행해봄

Standby DB 종료 및 nomount 기동

1
2

SQL> shutdown immediate
SQL> startup nomount

Primary 서버에서 rman 접속

1
2
3
4
5
6
7
8
9
10
11

$ rman target sys/oracle@oracle19 auxiliary sys/oracle@oracle19stb
 
Recovery Manager: Release 19.0.0.0.0 - Production on Sun Jun 7 16:20:36 2026
Version 19.28.0.0.0
 
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
 
connected to target database: ORACLE19 (DBID=3400652514)
connected to auxiliary database: ORACLE19 (not mounted)
 
RMAN>

접속됨

duplicate 명령으로 복제

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

RMAN> duplicate target database for standby from active database dorecover;
duplicate target database for standby from active database;
Starting Duplicate Db at 2026-06-07 20:31:21
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=21 device type=DISK
 
contents of Memory Script:
{
   backup as copy reuse
   passwordfile auxiliary format  '/app/oracle/product/19c/dbs/orapworacle19stb'   ;
}
executing Memory Script
 
Starting backup at 2026-06-07 20:31:22
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=50 device type=DISK
Finished backup at 2026-06-07 20:31:26
 
contents of Memory Script:
{
   restore clone from service  'oracle19' standby controlfile;
}
executing Memory Script
 
Starting restore at 2026-06-07 20:31:26
using channel ORA_AUX_DISK_1
 
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/app/oracle/oradata/oracle19stb/control01.ctl
Finished restore at 2026-06-07 20:31:30
 
contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script
 
sql statement: alter database mount standby database
 
contents of Memory Script:
{
   set newname for tempfile  1 to
 "/app/oracle/oradata/oracle19stb/temp.264.1220456361";
   switch clone tempfile all;
   set newname for datafile  1 to
 "/app/oracle/oradata/oracle19stb/system.261.1220456359";
   set newname for datafile  2 to
 "/app/oracle/oradata/oracle19stb/sysaux.262.1220456361";
   set newname for datafile  3 to
 "/app/oracle/oradata/oracle19stb/undotbs1.263.1220456361";
   set newname for datafile  4 to
 "/app/oracle/oradata/oracle19stb/users.265.1220456367";
   restore
   from  nonsparse   from service
 'oracle19'   clone database
   ;
   sql 'alter system archive log current';
}
executing Memory Script
 
executing command: SET NEWNAME
 
renamed tempfile 1 to /app/oracle/oradata/oracle19stb/temp.264.1220456361 in control file
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
Starting restore at 2026-06-07 20:31:35
using channel ORA_AUX_DISK_1
 
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /app/oracle/oradata/oracle19stb/system.261.1220456359
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:01:55
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00002 to /app/oracle/oradata/oracle19stb/sysaux.262.1220456361
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00003 to /app/oracle/oradata/oracle19stb/undotbs1.263.1220456361
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00004 to /app/oracle/oradata/oracle19stb/users.265.1220456367
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 2026-06-07 20:33:50
 
sql statement: alter system archive log current
 
contents of Memory Script:
{
   switch clone datafile all;
}
executing Memory Script
 
datafile 1 switched to datafile copy
input datafile copy RECID=1 STAMP=1235332888 file name=/app/oracle/oradata/oracle19stb/system.261.1220456359
datafile 2 switched to datafile copy
input datafile copy RECID=2 STAMP=1235332888 file name=/app/oracle/oradata/oracle19stb/sysaux.262.1220456361
datafile 3 switched to datafile copy
input datafile copy RECID=3 STAMP=1235332888 file name=/app/oracle/oradata/oracle19stb/undotbs1.263.1220456361
datafile 4 switched to datafile copy
input datafile copy RECID=4 STAMP=1235332888 file name=/app/oracle/oradata/oracle19stb/users.265.1220456367
Finished Duplicate Db at 2026-06-07 20:33:56

커맨드에 dorecover를 붙여주면 duplicate가 오래 걸려도 그사이 생긴 아카이브로그도 Standby에 적용해줌

참고로 병렬 채널 할당도 가능함

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

RMAN>
RUN {
    # 1. Target(Primary) 채널 4개 할당 (ASM 디스크 Read 담당)
    ALLOCATE CHANNEL p1 DEVICE TYPE DISK;
    ALLOCATE CHANNEL p2 DEVICE TYPE DISK;
    ALLOCATE CHANNEL p3 DEVICE TYPE DISK;
    ALLOCATE CHANNEL p4 DEVICE TYPE DISK;
 
    # 2. Auxiliary(Standby) 채널 4개 할당 (FS 디스크 Write 담당)
    ALLOCATE AUXILIARY CHANNEL s1 DEVICE TYPE DISK;
    ALLOCATE AUXILIARY CHANNEL s2 DEVICE TYPE DISK;
    ALLOCATE AUXILIARY CHANNEL s3 DEVICE TYPE DISK;
    ALLOCATE AUXILIARY CHANNEL s4 DEVICE TYPE DISK;
 
    # 3. Duplicate 명령 수행 (DORECOVER 포함)
    DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
    DORECOVER;
}

db role 및 상태 확인

1
2
3
4
5
6
7
8
9
10
11
12
13

#Primary
SQL> select database_role, open_mode, (select status from v$instance) status from v$database;
 
DATABASE_ROLE    OPEN_MODE            STATUS
---------------- -------------------- ------------
PRIMARY          READ WRITE           OPEN
 
#Standby
SQL> select database_role, open_mode (select status from v$instance) status from v$database;
 
DATABASE_ROLE    OPEN_MODE            STATUS
---------------- -------------------- ------------
PHYSICAL STANDBY MOUNTED              MOUNTED

Standby가 mount로 기동됨

Standby db read only로 기동

1
2
3

SQL> alter database open read only;
 
Database altered.

Standby에서 MRP 프로세스(Managed Recovery Process)를 기동

1
2
3

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

Primary에서 로그 스위치 수행

1
2
3

SQL> alter system switch logfile;
 
System altered.

alert log 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#Primary
$ tail -300f /app/oracle/diag/rdbms/oracle19/oracle19/trace/alert_oracle19.log
2026-06-07T20:36:16.487709+09:00
Thread 1 advanced to log sequence 66 (LGWR switch),  current SCN: 1332365
  Current log# 3 seq# 66 mem# 0: +DATA/ORACLE19/ONLINELOG/group_3.260.1235315267
2026-06-07T20:36:16.592451+09:00
ARC3 (PID:44792): Archived Log entry 96 added for B-1220456354.T-1.S-65 LOS:0x00000000001453c1 NXS:0x000000000014548d NAB:16659 ID 0xcb94dc22 LAD:1
 
#Standby
$ tail -300f /app/oracle/diag/rdbms/oracle19stb/oracle19stb/trace/alert_oracle19stb.log
2026-06-07T20:03:54.232185+09:00
 rfs (PID:53142): krsr_rfs_atc: Identified database type as 'PHYSICAL': Client is ASYNC (PID:85677)
2026-06-07T20:03:54.238631+09:00
 rfs (PID:53142): Selected LNO:4 for T-1.S-66 dbid 3400652514 branch 1220456354
2026-06-07T20:03:54.965536+09:00
PR00 (PID:52942): Media Recovery Log /app/oracle/arch/1_65_1220456354.arc
PR00 (PID:52942): Media Recovery Waiting for T-1.S-66 (in transit)
2026-06-07T20:03:55.047052+09:00
Recovery of Online Redo Log: Thread 1 Group 4 Seq 66 Reading mem 0
  Mem# 0: /app/oracle/oradata/oracle19stb/group_4.284.1235315377

정상적으로 아카이브가 Standby에도 적용됨

아카이브 갭 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#Primary
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 oracle19                       VALID     OPEN            IDLE                               oracle19
         2 oracle19stb                    VALID     OPEN_READ-ONLY  MANAGED REAL TIME APPLY WITH QUERY oracle19stb                    NO GAP  <<--!!
 
#Standby
SQL> 
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

GAP_STATUS가 UNRESOLVABLE GAP에서 NO GAP로 변경됨

Standby에서 아카이브 갭 시퀀스 확인

1
2
3

SQL> select * from v$archive_gap;
 
no rows selected

no rows로 표시됨

Standby에서 마지막으로 적용한 아카이브로그 확인

1
2
3
4
5
6
7
8
9
10

SQL>
select thread#, sequence#, first_change#, next_change#, applied 
from v$archived_log 
where applied = 'YES' 
order by sequence# desc;
 
   THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APPLIED
---------- ---------- ------------- ------------ ---------
         1         65       1332161      1332365 YES
         1         64       1331051      1332161 YES

정상적으로 65번 시퀀스까지 아카이브를 적용함

66번 시퀀스는 현재 Standby에서 ACTIVE redo임

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SQL> 
set lines 200
set pages 1000
col member for a60
select thread#, l.group#, member, archived, l.status, (bytes/1024/1024) MB, sequence#
from v$standby_log l, v$logfile f
where f.group# = l.group#
order by 1, 2;
 
   THREAD#     GROUP# MEMBER                                                       ARC STATUS             MB  SEQUENCE#
---------- ---------- ------------------------------------------------------------ --- ---------- ---------- ----------
         0          5 /app/oracle/oradata/oracle19stb/group_5.285.1235315381       YES UNASSIGNED        200          0
         0          6 /app/oracle/oradata/oracle19stb/group_6.286.1235315381       YES UNASSIGNED        200          0
         1          4 /app/oracle/oradata/oracle19stb/group_4.284.1235315377       YES ACTIVE            200         66  <<-- !!

결론 :
adg 환경에서 gap이 너무 많이 생기거나 아카이브로그가 유실된 경우 본문과 같은 방식으로
rman duplicate를 재수행 해주어서 정상화시킬 수 있음

참조 :

오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드 ( https://positivemh.tistory.com/1391 )

https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-role-transitions.html#GUID-AAD70601-D248-4309-B8DD-F461EE31A5FF
https://docs.oracle.com/en/database/oracle/oracle-database/19/spmss/switchover-to-a-physical-db.html#GUID-AAD70601-D248-4309-B8DD-F461EE31A5FF

오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드

내맘대로긍정 — Mon, 8 Jun 2026 00:12:08 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle Database 19.28.0.0

방법 : 오라클 19c Restart(ASM) to 싱글(FS) ADG 구성 가이드

본문에서는 이미 Restart(ASM)로 구성된 서버와 19c 엔진만 설치된 Filesystem 서버를 준비해두고, 이 환경에서 ADG를 구성해봄
동일 환경으로 ADG 구성하는것과의 차이점은 db_file_name_convert, log_file_name_convert에 ASM 경로 -> FS 경로를 넣어주는 부분만 다름
싱글(FS) to 싱글(FS) ADG 구성 가이드는 아래 게시물을 참고하면됨
참고 : Oracle Linux 8.4에 Oracle 19c ADG 설치 가이드_Part 1 ( https://positivemh.tistory.com/819 )
RAC(ASM) to RAC(ASM) ADG 구성 가이드는 아래 게시물을 참고하면됨
참고 : Oracle Linux 8.4에 Oracle 19c RAC to RAC ADG 설치 가이드_Part 1 ( https://positivemh.tistory.com/824 )

Active Data Guard(ADG) 란?

참고 : 오라클 19c Active Data Guard(ADG)와 Data Guard(DG) ( https://positivemh.tistory.com/1398 )

Primary(Active) hostname : ora19, db_name : oracle19, db_unique_name : oracle19
Standby(Standby) hostname : ora19stb, db_name : oracle19, db_unique_name : oracle19stb

테스트

1
2
3
4
5
6

# cat /etc/hosts
#Dataguard Primary
192.168.137.50 ora19
 
#Dataguard Standby
192.168.137.60 ora19stb

Primary 리스너 정보(정적리스너 설정 필요)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$ cat /app/grid/product/19c/network/admin/listener.ora
#Backup file is  /app/oracle/crsdata/ora19/output/listener.ora.bak.ora19.oracle line added by Agent
# listener.ora Network Configuration File: /app/grid/product/19c/network/admin/listener.ora
# Generated by Oracle configuration tools.
 
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ora19)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )
 
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = oracle19)
      (ORACLE_HOME = /app/oracle/product/19c)
      (SID_NAME = oracle19)
    )
  )
 
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON              # line added by Agent
VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON            # line added by Agent

Standby 리스너 정보(정적리스너 설정 필요)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$ cat /app/oracle/product/19c/network/admin/listener.ora
# listener.ora Network Configuration File: /app/oracle/product/19c/network/admin/listener.ora
# Generated by Oracle configuration tools.
 
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ora19stb)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )
 
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = oracle19stb)
      (ORACLE_HOME = /app/oracle/product/19c)
      (SID_NAME = oracle19stb)
    )
  )

Primary tns 정보

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ cat /app/oracle/product/19c/network/admin/tnsnames.ora
ORACLE19 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ora19)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = oracle19)
    )
  )
 
ORACLE19STB =
(DESCRIPTION =
  (ADDRESS = (PROTOCOL = TCP)(HOST = ora19stb)(PORT = 1521))
  (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = oracle19stb)
  )
)

Standby tns 정보

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ cat /app/oracle/product/19c/network/admin/tnsnames.ora
ORACLE19 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ora19)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = oracle19)
    )
  )
 
ORACLE19STB =
(DESCRIPTION =
  (ADDRESS = (PROTOCOL = TCP)(HOST = ora19stb)(PORT = 1521))
  (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = oracle19stb)
  )
)

Primary, Standby 양쪽 모두 리스너 기동

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

$ lsnrctl start
 
#Primary 리스너
$ lsnrctl status
 
LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 07-JUN-2026 16:11:50
 
Copyright (c) 1991, 2025, Oracle.  All rights reserved.
 
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                07-JUN-2026 16:11:43
Uptime                    0 days 0 hr. 0 min. 6 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /app/grid/product/19c/network/admin/listener.ora
Listener Log File         /app/oracle/diag/tnslsnr/ora19/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ora19)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "oracle19" has 1 instance(s).
  Instance "oracle19", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
 
#Standby 리스너
$ lsnrctl status
 
LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 07-JUN-2026 15:40:52
 
Copyright (c) 1991, 2025, Oracle.  All rights reserved.
 
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ora19stb)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                07-JUN-2026 15:33:55
Uptime                    0 days 0 hr. 6 min. 57 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /app/oracle/product/19c/network/admin/listener.ora
Listener Log File         /app/oracle/diag/tnslsnr/ora19stb/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ora19stb)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "oracle19stb" has 2 instance(s).
  Instance "oracle19stb", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

현재 db는 아카이브로그 모드 상태임

1
2
3
4
5
6
7

SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            +DATA
Oldest online log sequence     5
Next log sequence to archive   7
Current log sequence           7

Force Logging 설정

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

SQL> 
set lines 200 pages 1000
select name, force_logging from v$database;
 
NAME      FORCE_LOGGING
--------- ---------------------------------------
ORACLE19  NO
 
SQL> alter database force logging;
 
Database altered.
 
SQL> select name, force_logging from v$database;
 
NAME      FORCE_LOGGING
--------- ---------------------------------------
ORACLE19  YES

현재 데이터파일, 템프파일 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

SQL> 
set lines 200 pages 1000
col tablespace_name for a20
col file_name for a70
select tablespace_name, file_id, file_name, round(bytes/1024/1024/1024, 2) gb,
round(maxbytes/1024/1024/1024, 2) max_gb, autoextensible, status, online_status from dba_data_files
union all
select tablespace_name, file_id, file_name, round(bytes/1024/1024/1024, 2) gb,
round(maxbytes/1024/1024/1024, 2) max_gb, autoextensible, status, null from dba_temp_files order by 2;
 
TABLESPACE_NAME         FILE_ID FILE_NAME                                                                      GB     MAX_GB AUT STATUS    ONLINE_
-------------------- ---------- ---------------------------------------------------------------------- ---------- ---------- --- --------- -------
SYSTEM                        1 +DATA/ORACLE19/DATAFILE/system.261.1220456359                                 .98         32 YES AVAILABLE SYSTEM
TEMP                          1 +DATA/ORACLE19/TEMPFILE/temp.264.1220456361                                   .49         32 YES ONLINE
SYSAUX                        2 +DATA/ORACLE19/DATAFILE/sysaux.262.1220456361                                 .98         32 YES AVAILABLE ONLINE
UNDOTBS1                      3 +DATA/ORACLE19/DATAFILE/undotbs1.263.1220456361                               .62         32 YES AVAILABLE ONLINE
USERS                         4 +DATA/ORACLE19/DATAFILE/users.265.1220456367                                    0         32 YES AVAILABLE ONLINE

+DATA/ORACLE19/DATAFILE, +DATA/ORACLE19/TEMPFILE에 존재함

ADG 관련 파라미터 설정

1
2
3
4
5
6
7
8
9
10

SQL>
alter system set log_archive_config='DG_CONFIG=(oracle19,oracle19stb)' scope=both;
alter system set log_archive_dest_1='location=+data valid_for=(all_logfiles,all_roles) db_unique_name=oracle19' scope=both;
alter system set log_archive_dest_2='service=oracle19stb lgwr async noaffirm valid_for=(online_logfiles,primary_role) db_unique_name=oracle19stb' scope=both;
alter system set log_archive_max_processes=4 scope=both;
alter system set fal_client=oracle19 scope=both;
alter system set fal_server=oracle19stb scope=both;
alter system set db_file_name_convert='+DATA/ORACLE19/DATAFILE','/app/oracle/oradata/oracle19stb','+DATA/ORACLE19/TEMPFILE','/app/oracle/oradata/oracle19stb' scope=spfile;
alter system set log_file_name_convert='+DATA/ORACLE19/ONLINELOG','/app/oracle/oradata/oracle19stb' scope=spfile;
alter system set standby_file_management=auto scope=both;

db 재기동

1
2
3

SQL> 
shutdown immediate
startup

적용된 파라미터 확인

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

SQL> 
set lines 200 pages 1000
col value for a120
col name for a50
select name, value
from v$parameter
where name in ('db_name','db_unique_name','log_archive_config', 'log_archive_dest_1','log_archive_dest_2',
'log_archive_dest_state_1','log_archive_dest_state_2', 'remote_login_passwordfile',
'log_archive_format','log_archive_max_processes','fal_client','fal_server','db_file_name_convert',
'log_file_name_convert', 'standby_file_management', 'dg_broker_start');
 
NAME                                               VALUE
-------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------
db_file_name_convert                               +DATA/ORACLE19/DATAFILE, /app/oracle/oradata/oracle19stb, +DATA/ORACLE19/TEMPFILE, /app/oracle/oradata/oracle19stb
log_file_name_convert                              +DATA/ORACLE19/ONLINELOG, /app/oracle/oradata/oracle19stb
log_archive_dest_1                                 location=+data valid_for=(all_logfiles,all_roles) db_unique_name=oracle19
log_archive_dest_2                                 service=oracle19stb lgwr async noaffirm valid_for=(online_logfiles,primary_role) db_unique_name=oracle19stb
log_archive_dest_state_1                           enable
log_archive_dest_state_2                           enable
fal_client                                         ORACLE19
fal_server                                         ORACLE19STB
log_archive_config                                 DG_CONFIG=(oracle19,oracle19stb)
log_archive_format                                 %t_%s_%r.arc
log_archive_max_processes                          4
standby_file_management                            AUTO
remote_login_passwordfile                          EXCLUSIVE
db_name                                            oracle19
db_unique_name                                     oracle19
dg_broker_start                                    FALSE
 
16 rows selected.

파라미터가 잘 적용됨

현재 redo 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SQL> 
set lines 200
set pages 1000
col member for a60
select thread#, l.group#, member, archived, l.status, (bytes/1024/1024) MB, sequence#
from v$log l, v$logfile f
where f.group# = l.group#
order by 1, 2;
 
   THREAD#     GROUP# MEMBER                                                       ARC STATUS                   MB  SEQUENCE#
---------- ---------- ------------------------------------------------------------ --- ---------------- ---------- ----------
         1          1 +DATA/ORACLE19/ONLINELOG/group_1.258.1235315217              YES INACTIVE                200         22
         1          2 +DATA/ORACLE19/ONLINELOG/group_2.275.1235315197              NO  CURRENT                 200         23
         1          3 +DATA/ORACLE19/ONLINELOG/group_3.260.1235315267              YES INACTIVE                200         21

3개 존재함

Standby용 redo 생성

1
2
3
4

SQL>
alter database add standby logfile '+DATA' size 200M;
alter database add standby logfile '+DATA' size 200M;
alter database add standby logfile '+DATA' size 200M;

현재 redo 재확인

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

SQL> select group#, type, member from v$logfile order by 1;
 
    GROUP# TYPE    MEMBER
---------- ------- ------------------------------------------------------------
         1 ONLINE  +DATA/ORACLE19/ONLINELOG/group_1.258.1235315217
         2 ONLINE  +DATA/ORACLE19/ONLINELOG/group_2.275.1235315197
         3 ONLINE  +DATA/ORACLE19/ONLINELOG/group_3.260.1235315267
         4 STANDBY +DATA/ORACLE19/ONLINELOG/group_4.284.1235315377
         5 STANDBY +DATA/ORACLE19/ONLINELOG/group_5.285.1235315381
         6 STANDBY +DATA/ORACLE19/ONLINELOG/group_6.286.1235315381
 
SQL>
set lines 200
set pages 1000
col member for a60
select l.thread#, l.group#, type, member, l.archived, l.status, (l.bytes/1024/1024) MB, l.sequence#
from v$standby_log l, v$logfile f
where 1=1
and f.group# = l.group#
order by 1, 2;
 
   THREAD#     GROUP# TYPE    MEMBER                                                       ARC STATUS             MB  SEQUENCE#
---------- ---------- ------- ------------------------------------------------------------ --- ---------- ---------- ----------
         0          4 STANDBY +DATA/ORACLE19/ONLINELOG/group_4.284.1235315377              YES UNASSIGNED        200          0
         0          5 STANDBY +DATA/ORACLE19/ONLINELOG/group_5.285.1235315381              YES UNASSIGNED        200          0
         0          6 STANDBY +DATA/ORACLE19/ONLINELOG/group_6.286.1235315381              YES UNASSIGNED        200          0

standby redo log가 추가됨

Standby용 pfile 생성 및 Standby로 전송

1
2
3
4
5
6
7
8

SQL> create pfile from spfile;
 
File created.
 
$ cd /app/oracle/product/19c/dbs
$ scp initoracle19.ora ora19stb:/app/oracle/product/19c/dbs/initoracle19stb
oracle@ora19stb's password:
initoracle19stb.ora                                   100% 1632     3.6MB/s   00:00

패스워드 파일 확인

1
2

$ srvctl config database -d oracle19 | grep -i "Password file"
Password file: +DATA/ORACLE19/PASSWORD/pwdoracle19.287.1235316209

ASM에 존재함

pwcopy 명령으로 os로 복제

1

$ asmcmd pwcopy '+DATA/ORACLE19/PASSWORD/pwdoracle19.287.1235316209' '/home/oracle/orapworacle19' //orapw[SID]

패스워드 파일 Standby로 전송

1
2
3

$ scp /home/oracle/orapworacle19 ora19stb:/app/oracle/product/19c/dbs/orapworacle19stb
oracle@ora19stb's password:
orapworacle19                                      100% 2048     2.6MB/s   00:00

Standby 서버에서 pfile 수정(굵게 표시한 부분 수정)

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

$ cd /app/oracle/product/19c/dbs
$ vi initoracle19stb.ora
*.audit_file_dest='/app/oracle/admin/oracle19stb/adump'  <<-- !!
*.audit_trail='none'
*.compatible='19.0.0'
*.control_files='/app/oracle/oradata/oracle19stb/control01.ctl'  <<-- !!
*.db_block_size=8192
*.db_create_file_dest='/app/oracle/oradata/oracle19stb'  <<-- !!
*.db_file_name_convert='+DATA/ORACLE19/DATAFILE','/app/oracle/oradata/oracle19stb','+DATA/ORACLE19/TEMPFILE','/app/oracle/oradata/oracle19stb'
*.db_unique_name='oracle19stb'  <<-- !!
*.db_name='oracle19'
*.diagnostic_dest='/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=oracle19stbXDB)'  <<-- !!
*.fal_client='ORACLE19STB'  <<-- !!
*.fal_server='ORACLE19'  <<-- !!
*.log_archive_config='DG_CONFIG=(oracle19,oracle19stb)'
*.log_archive_dest_1='location=/app/oracle/arch valid_for=(all_logfiles,all_roles) db_unique_name=oracle19stb'  <<-- !!
*.log_archive_dest_2='service=oracle19 lgwr async noaffirm valid_for=(online_logfiles,primary_role) db_unique_name=oracle19'  <<-- !!
*.log_archive_format='%t_%s_%r.arc'
*.log_archive_max_processes=4
*.log_file_name_convert='+DATA/ORACLE19/ONLINELOG','/app/oracle/oradata/oracle19stb'
*.nls_language='AMERICAN'
*.nls_territory='AMERICA'
*.open_cursors=300
*.pga_aggregate_target=522m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=1564m
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'

Standby 서버에서 adump 경로 생성

1

$ mkdir -p /app/oracle/admin/oracle19stb/adump

Standby 서버의 .bash_profile 파일 수정(ORACLE_SID, DB_UNIQUE_NAME 수정)

1
2
3
4
5
6
7
8

$ cat /home/oracle/.bash_profile
export ORACLE_BASE=/app/oracle;
export ORACLE_HOME=$ORACLE_BASE/product/19c;
export ORACLE_SID=oracle19stb;
export DB_UNIQUE_NAME=oracle19stb;
export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib;
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib;

Standby DB nomount 기동

1
2
3
4
5
6
7
8

SQL> startup nomount
ORACLE instance started.
 
Total System Global Area 1644165832 bytes
Fixed Size                  8940232 bytes
Variable Size             402653184 bytes
Database Buffers         1224736768 bytes
Redo Buffers                7835648 bytes

양방향 sqlplus 접속 테스트

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

#Primary에서 테스트
$ sqlplus sys/oracle@oracle19 as sysdba
SQL> select instance_name, status from v$instance;
 
INSTANCE_NAME    STATUS
---------------- ------------
oracle19         OPEN
 
$ sqlplus sys/oracle@oracle19stb as sysdba
 
SQL> select instance_name, status from v$instance;
 
INSTANCE_NAME    STATUS
---------------- ------------
oracle19stb      STARTED
 
#Standby에서 테스트
SQL> select instance_name, status from v$instance;
 
INSTANCE_NAME    STATUS
---------------- ------------
oracle19         OPEN
 
$ sqlplus sys/oracle@oracle19stb as sysdba
 
SQL> select instance_name, status from v$instance;
 
INSTANCE_NAME    STATUS
---------------- ------------
oracle19stb      STARTED

양방향 잘 접속됨(접속이 안된다면 정적리스너 설정 다시 확인 필요함)

Primary 서버에서 rman 접속

1
2
3
4
5
6
7
8
9
10
11

$ rman target sys/oracle@oracle19 auxiliary sys/oracle@oracle19stb
 
Recovery Manager: Release 19.0.0.0.0 - Production on Sun Jun 7 16:20:36 2026
Version 19.28.0.0.0
 
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
 
connected to target database: ORACLE19 (DBID=3400652514)
connected to auxiliary database: ORACLE19 (not mounted)
 
RMAN>

접속됨

duplicate 명령으로 복제

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

RMAN> duplicate target database for standby from active database dorecover;
duplicate target database for standby from active database;
Starting Duplicate Db at 2026-06-07 16:47:16
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=19 device type=DISK
 
contents of Memory Script:
{
   backup as copy reuse
   passwordfile auxiliary format  '/app/oracle/product/19c/dbs/orapworacle19stb'   ;
}
executing Memory Script
 
Starting backup at 2026-06-07 16:47:18
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=281 device type=DISK
Finished backup at 2026-06-07 16:47:21
 
contents of Memory Script:
{
   restore clone from service  'oracle19' standby controlfile;
}
executing Memory Script
 
Starting restore at 2026-06-07 16:47:22
using channel ORA_AUX_DISK_1
 
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/app/oracle/oradata/oracle19stb/control01.ctl
Finished restore at 2026-06-07 16:47:26
 
contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script
 
sql statement: alter database mount standby database
 
contents of Memory Script:
{
   set newname for tempfile  1 to
 "/app/oracle/oradata/oracle19stb/temp.264.1220456361";
   switch clone tempfile all;
   set newname for datafile  1 to
 "/app/oracle/oradata/oracle19stb/system.261.1220456359";
   set newname for datafile  2 to
 "/app/oracle/oradata/oracle19stb/sysaux.262.1220456361";
   set newname for datafile  3 to
 "/app/oracle/oradata/oracle19stb/undotbs1.263.1220456361";
   set newname for datafile  4 to
 "/app/oracle/oradata/oracle19stb/users.265.1220456367";
   restore
   from  nonsparse   from service
 'oracle19'   clone database
   ;
   sql 'alter system archive log current';
}
executing Memory Script
 
executing command: SET NEWNAME
 
renamed tempfile 1 to /app/oracle/oradata/oracle19stb/temp.264.1220456361 in control file
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
executing command: SET NEWNAME
 
Starting restore at 2026-06-07 16:47:31
using channel ORA_AUX_DISK_1
 
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /app/oracle/oradata/oracle19stb/system.261.1220456359
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00002 to /app/oracle/oradata/oracle19stb/sysaux.262.1220456361
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00003 to /app/oracle/oradata/oracle19stb/undotbs1.263.1220456361
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service oracle19
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00004 to /app/oracle/oradata/oracle19stb/users.265.1220456367
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2026-06-07 16:47:40
 
sql statement: alter system archive log current
 
contents of Memory Script:
{
   switch clone datafile all;
}
executing Memory Script
 
datafile 1 switched to datafile copy
input datafile copy RECID=1 STAMP=1235319319 file name=/app/oracle/oradata/oracle19stb/system.261.1220456359
datafile 2 switched to datafile copy
input datafile copy RECID=2 STAMP=1235319319 file name=/app/oracle/oradata/oracle19stb/sysaux.262.1220456361
datafile 3 switched to datafile copy
input datafile copy RECID=3 STAMP=1235319319 file name=/app/oracle/oradata/oracle19stb/undotbs1.263.1220456361
datafile 4 switched to datafile copy
input datafile copy RECID=4 STAMP=1235319319 file name=/app/oracle/oradata/oracle19stb/users.265.1220456367
Finished Duplicate Db at 2026-06-07 16:47:42

복제됨

커맨드에 dorecover를 붙여주면 duplicate가 오래 걸려도 그사이 생긴 아카이브로그도 Standby에 적용해줌

참고로 병렬 채널 할당도 가능함

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

RMAN>
RUN {
    # 1. Target(Primary) 채널 4개 할당 (ASM 디스크 Read 담당)
    ALLOCATE CHANNEL p1 DEVICE TYPE DISK;
    ALLOCATE CHANNEL p2 DEVICE TYPE DISK;
    ALLOCATE CHANNEL p3 DEVICE TYPE DISK;
    ALLOCATE CHANNEL p4 DEVICE TYPE DISK;
 
    # 2. Auxiliary(Standby) 채널 4개 할당 (FS 디스크 Write 담당)
    ALLOCATE AUXILIARY CHANNEL s1 DEVICE TYPE DISK;
    ALLOCATE AUXILIARY CHANNEL s2 DEVICE TYPE DISK;
    ALLOCATE AUXILIARY CHANNEL s3 DEVICE TYPE DISK;
    ALLOCATE AUXILIARY CHANNEL s4 DEVICE TYPE DISK;
 
    # 3. Duplicate 명령 수행 (DORECOVER 포함)
    DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
    DORECOVER;
}

duplicate 이후에는 Standby DB가 mount 상태가 됨

1
2
3
4
5

SQL> select instance_name, status from v$instance;
 
INSTANCE_NAME    STATUS
---------------- ------------
oracle19stb      MOUNTED

db role 확인

1
2
3
4
5
6
7
8
9
10
11
12
13

#Primary
SQL> select database_role, open_mode from v$database;
 
DATABASE_ROLE    OPEN_MODE
---------------- --------------------
PRIMARY          READ WRITE
 
#Standby
SQL> select database_role, open_mode from v$database;
 
DATABASE_ROLE    OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY MOUNTED

Standby DB spfile 생성 및 mount 모드로 재기동

1
2
3
4
5
6
7
8
9
10
11

SQL> create spfile from pfile;
 
File created.
SQL> shutdown immediate
SQL> startup mount
SQL> show parameter spfile
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      /app/oracle/product/19c/dbs/sp
                                                 fileoracle19stb.ora

spfile 사용중임

Standby db read only로 기동

1
2
3

SQL> alter database open read only;
 
Database altered.

Standby에서 MRP 프로세스(Managed Recovery Process)를 기동

1
2
3

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

기동됨

참고로 아래 구문은 deprecated 된 예전 명령임

1

alter database recover managed standby database using current logfile disconnect;

프로세스 확인

1
2
3

$ ps -ef|grep mrp
oracle     28785       1  0 16:21 ?        00:00:00 ora_mrp0_oracle19stb
oracle     28993    7353  0 16:21 pts/0    00:00:00 grep --color=auto mrp

mrp 기동됨

db 상태 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#Primary
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
------------------------------ -------------------- ---------------- -------------------- --------
oracle19                       READ WRITE           PRIMARY          TO STANDBY           DISABLED
 
#Standby
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 WITH APPLY PHYSICAL STANDBY NOT ALLOWED          DISABLED

정상적으로 엑티브 데이터 가드(ADG)가 구성됨

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

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

#Primary
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 oracle19                       VALID     OPEN            IDLE                               oracle19
         2 oracle19stb                    VALID     OPEN_READ-ONLY  MANAGED REAL TIME APPLY WITH QUERY oracle19stb                    NO GAP
 
#Standby
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

정상임

Primary에서 테이블, 데이터 생성 및 Standby에서 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#Primary
SQL>
create table test as select * from dba_objects;
select count(*) from test;
 
  COUNT(*)
----------
     64234
 
#Standby
SQL> select count(*) from test;
 
  COUNT(*)
----------
     64234

잘 보임

Switch Over 테스트
Primary에서 verify 명령 먼저 수행

1
2
3

SQL> alter database switchover to oracle19stb verify;
 
Database altered.

verify 명령 수행시 문제가 없으면 Database altered.가 표시되고 switchover에 문제가 있다면 에러가 발생함
에러 조치 후 switchover 가능함

Primary에서 switchover 수행

1
2
3

SQL> alter database switchover to oracle19stb;
 
Database altered.

참고로 아래 구문은 예전에(11g 이전) 사용하던 구문임

1

alter database commit to switchover to standby;

전환 후 db role 확인

1
2
3
4
5
6
7
8

#Primary(구 Standby)
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                    MOUNTED              PRIMARY          NOT ALLOWED          DISABLED

switchover후 구 Standby가 Primary가 되면서 mount 상태가 됨

db open 후 재확인

1
2
3
4
5
6
7
8
9
10
11

SQL> alter database open;
 
Database altered.
 
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           PRIMARY          FAILED DESTINATION   DISABLED

read write, primary가 됨

Standby DB(구 Primary)는 db가 종료되었기 때문에 다시 기동 후 확인

1
2
3
4
5
6
7
8
9

#Standby(구 Primary)
SQL> startup
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
------------------------------ -------------------- ---------------- -------------------- --------
oracle19                       READ ONLY            PHYSICAL STANDBY RECOVERY NEEDED      DISABLED

startup 시 자동으로 read only로 기동됨

Standby(구 Primary)에서 MRP 프로세스(Managed Recovery Process)를 기동

1
2
3

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

기동됨

프로세스 확인

1
2
3

$ ps -ef|grep mrp
oracle     46223       1  0 17:22 ?        00:00:00 ora_mrp0_oracle19
oracle     46559   32185  0 17:22 pts/2    00:00:00 grep --color=auto mrp

mrp 기동됨

Primary(구 Standby)에서 테이블, 데이터 생성 및 Standby(구 Primary)에서 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#Primary(구 Standby)
SQL>
create table test2 as select * from dba_objects;
select count(*) from test2;
 
  COUNT(*)
----------
     64235
 
#Standby(구 Primary)
SQL> select count(*) from test2;
 
  COUNT(*)
----------
     64235

잘 보임

다음 테스트를 위해 Switch Over 재수행해서 원복

1
2
3
4
5
6
7
8

#Primary에서 switchover 수행
SQL> alter database switchover to oracle19;
#Primary open
SQL> alter database open;
#Standby 기동
SQL> startup
#Standby MRP 기동
SQL> alter database recover managed standby database disconnect from session;

failover는 본 게시글에서 테스트하지 않음
공식가이드 참고
참고 : https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-role-transitions.html#GUID-1496944D-3089-4A56-A518-5F9FBF82D2C6

참고1. mrp 프로세스 중지 및 시작 명령

1
2
3
4
5
6
7
8
9

#중지
SQL> alter database recover managed standby database cancel;
 
Database altered.
 
#시작
SQL> alter database recover managed standby database disconnect from session;
 
Database altered.

참고2. gap 확인

1
2
3

SQL> select * from v$archive_gap;
 
no rows selected

참고3. 데이터가드 상태 확인

1
2
3
4
5
6
7
8

SQL> select name, value from v$dataguard_stats;
 
NAME                             VALUE
-------------------------------- ----------------------------------------------------------------
transport lag                    +00 00:00:00
apply lag                        +00 00:00:00
apply finish time
estimated startup time           16

결론 :
Restart 환경(ASM) 싱글(Filesystem) 환경으로 ADG를 구성해보았음
요약하면 정적 리스너를 양쪽 db서버에 등록한뒤
adg 파라미터를 설정한 뒤 rman duplicate 명령을 이용해 간편하게 db를 복제하고
standby db에서 mrp를 기동하는 절차로 진행하였음
문제가 발생해서 gap(적용할 아카이브가 많이 생기는것을 gap이라 부름)이 너무 많이 발생하게 되는 경우
standby에 redo를 적용하는 시간과 duplicate를 다시 하는 시간을 계산하여
빠른 방식으로 재구성하면됨

참조 :

오라클 19c RAC 환경 opatchauto 이용 19.31 RU 패치 가이드

내맘대로긍정 — Sun, 7 Jun 2026 15:39:13 +0900

OS 환경 : Oracle Linux 8.7 (64bit)

DB 환경 : Oracle Database 19.27.0.0

방법 : 오라클 19c RAC 환경 opatchauto 이용 19.31 RU 패치

본문에서는 19.28이 설치된 RAC 환경에 19.31 패치를 적용하는 방법을 설명함
이때 opatch apply를 개별적으로 수행하지 않고 opatchauto를 이용해 커맨드 한줄로 수행하는 방법을 설명함
요즘 오라클 패치 파일 readme에서도 이 방식을 권장하고 있음
패치파일은 39062956를 사용함(참고로 19.31 패치는 한번 문제가 발생했었어서 rollback 되었다가 재릴리즈 되었음)
Patch 39062956 - Combo of OJVM Component Release Update 19.31.0.0.260421 + Grid Infrastructure Apr 2026 Release Update 19.31.0.0.260421 (REL-APR2026)

패치파일 구조

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

39062956  
|
|- README.txt 
| 
|- README.html 
|
|- 39036936/ <<-- GRID 및 DB 패치 파일
|      --README.html
|      -- 39034528  <<-- Database Release Update 19.31.0.0.260421
|      -- 39039430  <<-- OCW Release Update 19.31.0.0.260421
|      -- 39055473  <<-- ACFS Release Update 19.31.0.0.260421
|      -- 39107855  <<-- Tomcat Release Update 19.0.0.0.0 (Beginning 19.31 TOMCAT version will be deleted.)
|      -- 39107825  <<-- DBWLM Release Update 19.0.0.0.0 (Beginning from 19.31 Apr2026, QOS / WLM directory has been removed.)
|
|- 38906621/ <<-- OJVM 패치 파일
|      --README.html
|      -- <other files and directories>

39036936 폴더 안에 있는 파일 설명
39034528 : Database Release Update 19.31.0.0.260421
설치 대상 : Oracle RAC 환경이 아닌 경우 Oracle 홈에만 적용, Oracle RAC 환경인 경우에는 Oracle 홈과 Grid 홈 모두 적용

39039430 : OCW Release Update 19.31.0.0.260421
설치 대상 : Oracle 홈과 Grid 홈 모두 적용

39055473 : ACFS Release Update 19.31.0.0.260421
설치 대상 : Grid 홈에만 적용

39107855 : Tomcat Release Update 19.0.0.0.0 (Beginning 19.31 TOMCAT version will be deleted.)
설치 대상 : Grid 홈에만 적용

39107825 : DBWLM Release Update 19.0.0.0.0 (Beginning from 19.31 Apr2026, QOS / WLM directory has been removed.)
설치 대상 : Grid 홈에만 적용

테스트
양쪽 노드 모두 패치파일 unzip

1
2

$ cd /app/media
$ unzip -q p39062956_190000_Linux-x86-64.zip

양쪽 노드 모두 opatch 파일 업데이트(db)

1
2
3

$ cd $ORACLE_HOME
$ mv OPatch OPatchold
$ unzip -q /app/media/p6880880_190000_Linux-x86-64.zip

양쪽 노드 모두 opatch 파일 업데이트(grid)

1
2
3
4

# cd $GRID_HOME
# mv OPatch OPatchold
# unzip -q /app/media/p6880880_190000_Linux-x86-64.zip
# chown -R oracle:dba OPatch

패치 전 충돌 검사 수행
참고로 현재 경로는 /app/media/39062956임

1
2
3
4
5
6
7
8
9
10
11
12

# grid 유저로 수행
$ $GRID_HOME/OPatch/opatch prereq CheckMinimumOPatchVersion-phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39034528 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39034528 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39039430 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39055473 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39107855 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39107825 -oh $GRID_HOME
 
# oracle 유저로 수행
$ $ORACLE_HOME/OPatch/opatch prereq CheckMinimumOPatchVersion-phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39034528 -oh $ORACLE_HOME
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39034528 -oh $ORACLE_HOME
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39039430 -oh $ORACLE_HOME

패치 전 여유 공간 검사 수행

1
2
3
4
5
6
7
8
9
10

# grid 유저로 수행
$ $GRID_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39034528 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39039430 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39055473 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39107855 -oh $GRID_HOME
$ $GRID_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39107825 -oh $GRID_HOME
 
# oracle 유저로 수행
$ $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39034528 -oh $ORACLE_HOME
$ $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir <UNZIPPED_PATCH_LOCATION>/39036936/39039430 -oh $ORACLE_HOME

1번 노드 먼저 패치를 수행하는데 db나 grid를 수동으로 내리지 않고 바로 아래 명령을 수행함

1번 노드 root에서 패치 수행

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136

# cd /app/media/39062956
# export ORACLE_HOME=$GRID_HOME
# $GRID_HOME/OPatch/opatchauto apply 39036936
 
OPatchauto session is initiated at Fri Jun  5 23:29:25 2026
 
System initialization log file is /app/grid/product/19c/cfgtoollogs/opatchautodb/systemconfig2026-06-05_11-29-33PM.log.
 
Session log file is /app/grid/product/19c/cfgtoollogs/opatchauto/opatchauto2026-06-05_11-30-06PM.log
The id for this session is 1569
 
Executing OPatch prereq operations to verify patch applicability on home /app/grid/product/19c
Patch applicability verified successfully on home /app/grid/product/19c
 
 
Executing OPatch prereq operations to verify patch applicability on home /app/oracle/product/19c
Patch applicability verified successfully on home /app/oracle/product/19c
 
 
Executing patch validation checks on home /app/grid/product/19c
Patch validation checks successfully completed on home /app/grid/product/19c
 
 
Executing patch validation checks on home /app/oracle/product/19c
Patch validation checks successfully completed on home /app/oracle/product/19c
 
 
Verifying SQL patch applicability on home /app/oracle/product/19c
SQL patch applicability verified successfully on home /app/oracle/product/19c
 
 
Preparing to bring down database service on home /app/oracle/product/19c
Successfully prepared home /app/oracle/product/19c to bring down database service
 
 
Performing prepatch operations on CRS - bringing down CRS service on home /app/grid/product/19c
Prepatch operation log file location: /app/oracle/crsdata/oel19db1/crsconfig/crs_prepatch_apply_inplace_oel19db1_2026-06-05_11-38-06PM.log
CRS service brought down successfully on home /app/grid/product/19c
 
 
Performing prepatch operation on home /app/oracle/product/19c
Prepatch operation completed successfully on home /app/oracle/product/19c
 
 
Start applying binary patch on home /app/oracle/product/19c
Binary patch applied successfully on home /app/oracle/product/19c
 
 
Running rootadd_rdbms.sh on home /app/oracle/product/19c
Successfully executed rootadd_rdbms.sh on home /app/oracle/product/19c
 
 
Performing postpatch operation on home /app/oracle/product/19c
Postpatch operation completed successfully on home /app/oracle/product/19c
 
 
Start applying binary patch on home /app/grid/product/19c
Binary patch applied successfully on home /app/grid/product/19c
 
 
Running rootadd_rdbms.sh on home /app/grid/product/19c
Successfully executed rootadd_rdbms.sh on home /app/grid/product/19c
 
 
 
 
Performing postpatch operations on CRS - starting CRS service on home /app/grid/product/19c
Postpatch operation log file location: /app/oracle/crsdata/oel19db1/crsconfig/crs_postpatch_apply_inplace_oel19db1_2026-06-06_00-12-57AM.log
CRS service started successfully on home /app/grid/product/19c
 
 
Preparing home /app/oracle/product/19c after database service restarted
No step execution required.........
 
 
Trying to apply SQL patch on home /app/oracle/product/19c
No SQL patch operations are required on local node for this home
 
OPatchAuto successful.
 
--------------------------------Summary--------------------------------
 
Patching is completed successfully. Please find the summary as follows:
 
Host:oel19db1
RAC Home:/app/oracle/product/19c
Version:19.0.0.0.0
Summary:
 
==Following patches were SKIPPED:
 
Patch: /app/media/39062956/39036936/39055473
Reason: This patch is not applicable to this specified target type - "rac_database"
 
Patch: /app/media/39062956/39036936/39107825
Reason: This patch is not applicable to this specified target type - "rac_database"
 
Patch: /app/media/39062956/39036936/39107855
Reason: This patch is not applicable to this specified target type - "rac_database"
 
 
==Following patches were SUCCESSFULLY applied:
 
Patch: /app/media/39062956/39036936/39034528
Log: /app/oracle/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-05_23-39-47PM_1.log
 
Patch: /app/media/39062956/39036936/39039430
Log: /app/oracle/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-05_23-39-47PM_1.log
 
 
Host:oel19db1
CRS Home:/app/grid/product/19c
Version:19.0.0.0.0
Summary:
 
==Following patches were SUCCESSFULLY applied:
 
Patch: /app/media/39062956/39036936/39034528
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-05_23-54-27PM_1.log
 
Patch: /app/media/39062956/39036936/39039430
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-05_23-54-27PM_1.log
 
Patch: /app/media/39062956/39036936/39055473
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-05_23-54-27PM_1.log
 
Patch: /app/media/39062956/39036936/39107825
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-05_23-54-27PM_1.log
 
Patch: /app/media/39062956/39036936/39107855
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-05_23-54-27PM_1.log
 
 
 
OPatchauto session completed at Sat Jun  6 00:19:12 2026
Time taken to complete the session 49 minutes, 40 seconds

1번 노드 grid, db 패치가 완료됨, 49분 소요됨

2번 노드 root에서 패치 수행

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135

# export ORACLE_HOME=$GRID_HOME
# $GRID_HOME/OPatch/opatchauto apply 39036936
 
OPatchauto session is initiated at Sat Jun  6 00:20:29 2026
 
System initialization log file is /app/grid/product/19c/cfgtoollogs/opatchautodb/systemconfig2026-06-06_12-20-40AM.log.
 
Session log file is /app/grid/product/19c/cfgtoollogs/opatchauto/opatchauto2026-06-06_12-21-19AM.log
The id for this session is 8YMN
 
Executing OPatch prereq operations to verify patch applicability on home /app/grid/product/19c
Patch applicability verified successfully on home /app/grid/product/19c
 
 
Executing OPatch prereq operations to verify patch applicability on home /app/oracle/product/19c
Patch applicability verified successfully on home /app/oracle/product/19c
 
 
Executing patch validation checks on home /app/grid/product/19c
Patch validation checks successfully completed on home /app/grid/product/19c
 
 
Executing patch validation checks on home /app/oracle/product/19c
Patch validation checks successfully completed on home /app/oracle/product/19c
 
 
Verifying SQL patch applicability on home /app/oracle/product/19c
SQL patch applicability verified successfully on home /app/oracle/product/19c
 
 
Preparing to bring down database service on home /app/oracle/product/19c
Successfully prepared home /app/oracle/product/19c to bring down database service
 
 
Performing prepatch operations on CRS - bringing down CRS service on home /app/grid/product/19c
Prepatch operation log file location: /app/oracle/crsdata/oel19db2/crsconfig/crs_prepatch_apply_inplace_oel19db2_2026-06-06_00-29-28AM.log
CRS service brought down successfully on home /app/grid/product/19c
 
 
Performing prepatch operation on home /app/oracle/product/19c
Prepatch operation completed successfully on home /app/oracle/product/19c
 
 
Start applying binary patch on home /app/oracle/product/19c
Binary patch applied successfully on home /app/oracle/product/19c
 
 
Running rootadd_rdbms.sh on home /app/oracle/product/19c
Successfully executed rootadd_rdbms.sh on home /app/oracle/product/19c
 
 
Performing postpatch operation on home /app/oracle/product/19c
Postpatch operation completed successfully on home /app/oracle/product/19c
 
 
Start applying binary patch on home /app/grid/product/19c
Binary patch applied successfully on home /app/grid/product/19c
 
 
Running rootadd_rdbms.sh on home /app/grid/product/19c
Successfully executed rootadd_rdbms.sh on home /app/grid/product/19c
 
 
 
 
Performing postpatch operations on CRS - starting CRS service on home /app/grid/product/19c
Postpatch operation log file location: /app/oracle/crsdata/oel19db2/crsconfig/crs_postpatch_apply_inplace_oel19db2_2026-06-06_01-01-13AM.log
CRS service started successfully on home /app/grid/product/19c
 
 
Preparing home /app/oracle/product/19c after database service restarted
No step execution required.........
 
 
Trying to apply SQL patch on home /app/oracle/product/19c
SQL patch applied successfully on home /app/oracle/product/19c
 
OPatchAuto successful.
 
--------------------------------Summary--------------------------------
 
Patching is completed successfully. Please find the summary as follows:
 
Host:oel19db2
RAC Home:/app/oracle/product/19c
Version:19.0.0.0.0
Summary:
 
==Following patches were SKIPPED:
 
Patch: /app/media/39062956/39036936/39055473
Reason: This patch is not applicable to this specified target type - "rac_database"
 
Patch: /app/media/39062956/39036936/39107825
Reason: This patch is not applicable to this specified target type - "rac_database"
 
Patch: /app/media/39062956/39036936/39107855
Reason: This patch is not applicable to this specified target type - "rac_database"
 
 
==Following patches were SUCCESSFULLY applied:
 
Patch: /app/media/39062956/39036936/39034528
Log: /app/oracle/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-06_00-31-02AM_1.log
 
Patch: /app/media/39062956/39036936/39039430
Log: /app/oracle/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-06_00-31-02AM_1.log
 
 
Host:oel19db2
CRS Home:/app/grid/product/19c
Version:19.0.0.0.0
Summary:
 
==Following patches were SUCCESSFULLY applied:
 
Patch: /app/media/39062956/39036936/39034528
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-06_00-44-03AM_1.log
 
Patch: /app/media/39062956/39036936/39039430
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-06_00-44-03AM_1.log
 
Patch: /app/media/39062956/39036936/39055473
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-06_00-44-03AM_1.log
 
Patch: /app/media/39062956/39036936/39107825
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-06_00-44-03AM_1.log
 
Patch: /app/media/39062956/39036936/39107855
Log: /app/grid/product/19c/cfgtoollogs/opatchauto/core/opatch/opatch2026-06-06_00-44-03AM_1.log
 
 
 
OPatchauto session completed at Sat Jun  6 01:12:02 2026
Time taken to complete the session 51 minutes, 23 seconds

2번 노드 grid, db 패치가 완료됨, 51분 소요됨

패치 확인(모든 노드)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# su - oracle
$ opatch lspatches -oh $GRID_HOME
39107855;TOMCAT RELEASE UPDATE 19.0.0.0.0 (39107855)
39107825;DBWLM RELEASE UPDATE 19.0.0.0.0 (39107825)
39055473;ACFS RELEASE UPDATE 19.31.0.0.0 (39055473)
39039430;OCW RELEASE UPDATE 19.31.0.0.0 (39039430)
39034528;Database Release Update : 19.31.0.0.260421 (REL-APR2026) (39034528)
 
OPatch succeeded.
 
$ opatch lspatches -oh $ORACLE_HOME
39039430;OCW RELEASE UPDATE 19.31.0.0.0 (39039430)
39034528;Database Release Update : 19.31.0.0.260421 (REL-APR2026) (39034528)
37847857;OJVM RELEASE UPDATE: 19.28.0.0.250715 (37847857)
 
OPatch succeeded.

grid, db 모두 19.31로 패치됨(ojvm은 함께 패치되지 않음)

패치 내역 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

SQL>
set lines 200 pages 1000
col action_time for a20
col action for a10
col status for a10
col description for a70
col version for a10
select to_char(action_time, 'yyyy/mm/dd hh24:mi:ss') as action_time,
       action, status, description, patch_id
from dba_registry_sqlpatch
order by action_time;
 
ACTION_TIME          ACTION     STATUS     DESCRIPTION                                                              PATCH_ID
-------------------- ---------- ---------- ---------------------------------------------------------------------- ----------
2025/12/24 10:53:33  APPLY      SUCCESS    OJVM RELEASE UPDATE: 19.28.0.0.250715 (37847857)                         37847857
2025/12/24 10:56:39  APPLY      SUCCESS    Database Release Update : 19.28.0.0.250715 (37960098)                    37960098
2026/06/06 01:11:18  APPLY      SUCCESS    Database Release Update : 19.31.0.0.260421 (REL-APR2026) (39034528)      39034528

datapatch도 잘 적용됨(ojvm은 함께 패치되지 않음)

필요시 db 중지 후 ojvm은 함께 패치 수행(모든 노드)

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

SQL> shutdown immediate
$ cd /app/media/39062956/38906621/
$ opatch apply
Oracle Interim Patch Installer version 12.2.0.1.51
Copyright (c) 2026, Oracle Corporation.  All rights reserved.
 
 
Oracle Home       : /app/oracle/product/19c
Central Inventory : /app/oraInventory
   from           : /app/oracle/product/19c/oraInst.loc
OPatch version    : 12.2.0.1.51
OUI version       : 12.2.0.7.0
Log file location : /app/oracle/product/19c/cfgtoollogs/opatch/opatch2026-06-06_07-17-34AM_1.log
 
Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   38906621
 
Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
 
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/app/oracle/product/19c')
 
 
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '38906621' to OH '/app/oracle/product/19c'
 
Patching component oracle.javavm.server, 19.0.0.0.0...
 
Patching component oracle.javavm.server.core, 19.0.0.0.0...
 
Patching component oracle.rdbms.dbscripts, 19.0.0.0.0...
 
Patching component oracle.rdbms, 19.0.0.0.0...
 
Patching component oracle.javavm.client, 19.0.0.0.0...
Patch 38906621 successfully applied.
Sub-set patch [37847857] has become inactive due to the application of a super-set patch [38906621].
Please refer to Doc ID 2161861.1 for any possible further required actions.
Log file location: /app/oracle/product/19c/cfgtoollogs/opatch/opatch2026-06-06_07-17-34AM_1.log
 
OPatch succeeded.

완료됨

패치 재확인(모든 노드)

1
2
3
4
5
6

$ opatch lspatches -oh $ORACLE_HOME
38906621;OJVM RELEASE UPDATE: 19.31.0.0.260421 (38906621)
39039430;OCW RELEASE UPDATE 19.31.0.0.0 (39039430)
39034528;Database Release Update : 19.31.0.0.260421 (REL-APR2026) (39034528)
 
OPatch succeeded.

ojvm이 19.31로 패치됨

db 기동(모든 노드) 후 datapatch 수행(한쪽 노드)

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

SQL> startup
$ cd $ORACLE_HOME/OPatch
$ ./datapatch -verbose
SQL Patching tool version 19.31.0.0.0 Production on Sat Jun  6 07:25:19 2026
Copyright (c) 2012, 2026, Oracle.  All rights reserved.
 
Log file for this invocation: /app/oracle/cfgtoollogs/sqlpatch/sqlpatch_453631_2026_06_06_07_25_19/sqlpatch_invocation.log
 
Connecting to database...OK
Gathering database info...done
Bootstrapping registry and package to current versions...done
Determining current state...done
 
Current state of interim SQL patches:
Interim patch 37847857 (OJVM RELEASE UPDATE: 19.28.0.0.250715 (37847857)):
  Binary registry: Not installed
  SQL registry: Applied successfully on 24-DEC-25 10.53.33.506597 AM
Interim patch 38906621 (OJVM RELEASE UPDATE: 19.31.0.0.260421 (38906621)):
  Binary registry: Installed
  SQL registry: Not installed
 
Current state of release update SQL patches:
  Binary registry:
    19.31.0.0.0 Release_Update 260514003012: Installed
  SQL registry:
    Applied 19.31.0.0.0 Release_Update 260514003012 successfully on 06-JUN-26 01.11.18.913247 AM
 
Adding patches to installation queue and performing prereq checks...done
Installation queue:
  The following interim patches will be rolled back:
    37847857 (OJVM RELEASE UPDATE: 19.28.0.0.250715 (37847857))
  No release update patches need to be installed
  The following interim patches will be applied:
    38906621 (OJVM RELEASE UPDATE: 19.31.0.0.260421 (38906621))
 
Installing patches...
Patch installation complete.  Total patches installed: 2
 
Validating logfiles...done
Patch 37847857 rollback: SUCCESS
  logfile: /app/oracle/cfgtoollogs/sqlpatch/37847857/27534561/37847857_rollback_ORADB_2026Jun06_07_27_07.log (no errors)
Patch 38906621 apply: SUCCESS
  logfile: /app/oracle/cfgtoollogs/sqlpatch/38906621/28588735/38906621_apply_ORADB_2026Jun06_07_27_46.log (no errors)
SQL Patching tool complete on Sat Jun  6 07:28:29 2026

패치 내역 재확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

SQL>
set lines 200 pages 1000
col action_time for a20
col action for a10
col status for a10
col description for a70
col version for a10
select to_char(action_time, 'yyyy/mm/dd hh24:mi:ss') as action_time,
       action, status, description, patch_id
from dba_registry_sqlpatch
order by action_time;
 
ACTION_TIME          ACTION     STATUS     DESCRIPTION                                                              PATCH_ID
-------------------- ---------- ---------- ---------------------------------------------------------------------- ----------
2025/12/24 10:53:33  APPLY      SUCCESS    OJVM RELEASE UPDATE: 19.28.0.0.250715 (37847857)                         37847857
2025/12/24 10:56:39  APPLY      SUCCESS    Database Release Update : 19.28.0.0.250715 (37960098)                    37960098
2026/06/06 01:11:18  APPLY      SUCCESS    Database Release Update : 19.31.0.0.260421 (REL-APR2026) (39034528)      39034528
2026/06/06 07:27:46  ROLLBACK   SUCCESS    OJVM RELEASE UPDATE: 19.28.0.0.250715 (37847857)                         37847857
2026/06/06 07:28:29  APPLY      SUCCESS    OJVM RELEASE UPDATE: 19.31.0.0.260421 (38906621)                         38906621

ojvm까지 datapatch도 잘 적용됨

참고1. ORACLE_HOME을 $GRID_HOME으로 설정해주어야함 그렇지 않은 경우 아래와 같은 에러가 발생함

1
2
3
4
5
6
7

# echo $ORACLE_HOME
/app/oracle/product/19c
# $GRID_HOME/OPatch/opatchauto apply 39036936
 
opatchauto must run from one of the homes specified
opathauto runs from the /app/grid/product/19c, while Oracle Home specified is /app/oracle/product/19c
opatchauto returns with error code = 2

참고2. opatchauto 파일 경로를 지정해주지 않으면 아래와 같은 에러가 발생함

1
2
3
4

# opatchauto apply 39036936
 
opatchauto must run from Grid Home with current arguments. Please retry it inside Grid Home
opatchauto returns with error code = 2

결론 :
opatchauto를 이용해 패치를 간편하게 수행할 수 있음

참조 :

19.31 combo patch readme 문서