오라클 Hot backup시 변경이 발생한다면?

OS환경 : Oracle Linux6.8(64bit)

DB 환경 : Oracle Database 10.2.0.4, 11.2.0.4

질문 : 

안녕하세요 11g를 공부하고있는 학생입니다. hot backup 에서 data file을 alter .... begin backup 을 실행중일때, 

backup중인 파일을 update 하면 update된 block 들이 redo log 파일에 저장되는건가요?? 만약 그렇다면 backup이 끝나고 나면 

redo log 파일에 저장된 block들이 data file에 저절로 합쳐지는건가요?? 

답변 :

이거 누가 이렇게 가르쳐 주는 건가요?

일단 BEGIN백업을 한다고 해도 DBWn이 작동하면 더티 블록이 데이터파일에 저장 되는 건 동일합니다.

단, 체크포인트 SCN이 변경 되지 않죠.

BEGIN BACKUP은 OS블록 사이즈 등에 대한 내용으로 리두에 쓰는 내용이 변경 DML단위 =>변경 블록 단위로 변하는 것 이나, 백업을 위해 복사 중 발생되는 비일관적인 상황에 대해 리커버리 포인트를 잡는 다는 것이지, 데이터파일 프리징을 하고 변경 내용을 리두에 저장하고 END BACKUP을 찍을 시 변경 내용을 다시 데이터 파일에 기록하는 게 아닙니다. (이렇게 하면 END BACKUP은 시스템에 엄청난 부하를 주겠네요...)

(MOS계정 있으신 분들은 What Happens When A Tablespace/Database Is Kept In Begin Backup Mode (문서 ID 469950.1) 참고하시길... )

일단 테스트로 아래 내용 한번 해보시길 바랍니다

1. BEGIN 백업 후 alter system archive log current; 수차례 수행 후 발생 된 아카이브 로그 삭제 후 END BACKUP

- 만약 redo와 archive에만 데이터가 기록 된다면 END BACKUP을 못 찍을 것

2. autoextent on인 데이터 파일 BEGIN BACKUP 후 대용량 DML로 파일 자동 증가 되는 지 확인

- 만약 데이터파일에 변경 내용이 저장 안되면 파일 사이즈가 증가하지 않을 것.

BEGIN BACKUP찍는다고 데이터파일이 변경되지 않는 다는 내용은 어떤 공식 문서에도 없는데, 왜 이렇게 알고 계신 분들이 많은 지 궁금하네요...

테스트 시나리오

*테스트1 (11g)

BEGIN 백업 후 alter system archive log current; 수차례 수행 후 발생 된 아카이브 로그 삭제 후 END BACKUP

- 만약 redo와 archive에만 데이터가 기록 된다면 END BACKUP을 못 찍을 것

@세션1

테이블 스페이스 확인

SQL> select tablespace_name, bytes/1024 KB, autoextensible from dba_data_files
where file_id = 5;
 
TABLESPACE_NAME          KB AUT
------------------------------ ---------- ---
BEGINTS        10240 YES
 
1 row selected.

begin backup 실행

SQL> alter tablespace begints begin backup;
 
Tablespace altered.

begin 백업 상태 확인

SQL> select * from v$backup where file#=5;  
 
     FILE# STATUS   CHANGE# TIME        CON_ID
---------- ------------------ ---------- --------- ----------
  5 ACTIVE   2558824 23-AUG-18     0
 
1 row selected.

아카이브로 내리기

SQL> alter system archive log current;
 
System altered.
 
위 쿼리 4번 반복 
SQL> /
 
System altered.
 
SQL> /
 
System altered.
 
SQL> /
 
System altered.
 
SQL> /
 
System altered.

@세션2

아카이브 로그 확인(5개 발생)

[oracle@oracle18 2018_08_23]$ ls -al
total 5260
drwxr-x---. 2 oracle dba    4096 Aug 23 10:22 .
drwxr-x---. 6 oracle dba      74 Aug 23 10:16 ..
-rw-r-----. 1 oracle dba 5360128 Aug 23 10:21 o1_mf_1_978_fqw31co8_.arc
-rw-r-----. 1 oracle dba    6656 Aug 23 10:22 o1_mf_1_979_fqw32k5o_.arc
-rw-r-----. 1 oracle dba    4096 Aug 23 10:22 o1_mf_1_980_fqw32llg_.arc
-rw-r-----. 1 oracle dba    1024 Aug 23 10:22 o1_mf_1_981_fqw32mmj_.arc
-rw-r-----. 1 oracle dba    1024 Aug 23 10:22 o1_mf_1_982_fqw32os1_.arc

아카이브 로그 모두 삭제

[oracle@oracle18 2018_08_23]$ rm -rf ./o1_mf_1_978_fqw31co8_.arc
[oracle@oracle18 2018_08_23]$ rm -rf ./o1_mf_1_978_fqw31co8_.arc
[oracle@oracle18 2018_08_23]$ rm -rf ./o1_mf_1_979_fqw32k5o_.arc
[oracle@oracle18 2018_08_23]$ rm -rf ./o1_mf_1_980_fqw32llg_.arc
[oracle@oracle18 2018_08_23]$ rm -rf ./o1_mf_1_981_fqw32mmj_.arc
[oracle@oracle18 2018_08_23]$ rm -rf ./o1_mf_1_982_fqw32os1_.arc

아카이브 로그 확인(5개 삭제됨)

[oracle@oracle18 2018_08_23]$ ls -al
total 0
drwxr-x---. 2 oracle dba  6 Aug 23 10:23 .
drwxr-x---. 6 oracle dba 74 Aug 23 10:16 ..

@세션1

#end backup 실행(정상적으로 수행됨)

SQL> alter tablespace begints end backup;
 
Tablespace altered.

테스트1 결론

- begin backup 이후 archive가 지워져도 END BACKUP을 찍을 수 있다.

*테스트2(11g)

autoextent on인 데이터 파일 BEGIN BACKUP 후 대용량 DML로 파일 자동 증가 되는 지 확인

- 만약 데이터파일에 변경 내용이 저장 안되면 파일 사이즈가 증가하지 않을 것.

테이블 스페이스 확인

SQL> select tablespace_name, bytes, autoextensible from dba_data_files
where file_id = 5;
 
TABLESPACE_NAME       BYTES AUT
------------------------------ ---------- ---
BEGINTS     10485760 YES
 
1 row selected.

begin backup 실행

SQL> alter tablespace begints begin backup;
 
Tablespace altered.

begints에 테스트용 테이블 생성

SQL> create table beuser.betest as select * from dba_objects;
 
Table created.

데이터 추가 삽입

SQL> insert into beuser.betest select * from beuser.betest;
 
22972 rows created.
 
SQL> /
 
45944 rows created.
 
SQL> /
 
91888 rows created.
 
SQL> /
 
183776 rows created.
 
SQL> commit;
 
Commit complete.

테이블 스페이스 확인(용량이 증가함)

SQL> select tablespace_name, bytes, autoextensible from dba_data_files
where file_id = 5;
 
TABLESPACE_NAME       BYTES AUT
------------------------------ ---------- ---
BEGINTS     52887552 YES

테스트2 결론

- begin backup 이후 데이터파일에 변경 내용이 저장 되어 파일 사이즈가 증가한다.

--191012 추가--

*테스트3(11g 머신이 없어 10g로 테스트)

autoextent on인 데이터 파일 BEGIN BACKUP 후 대용량 DML 및 log switch로 파일 자동 증가 되는 지 확인

- 만약 데이터파일에 변경 내용이 저장 안되면 파일 사이즈가 증가하지 않을 것.

아카이브 모드 확인

SQL> archive log list
Database log mode           Archive Mode
Automatic archival           Enabled
Archive destination           /oracle/app/oracle/product/10.2.0/db_1/dbs/arch
Oldest online log sequence     154
Next log sequence to archive   156
Current log sequence           156

ts 생성

SQL> create tablespace begints datafile '/oracle/app/oracle/oradata/ORCL/begints01.dbf' size 10m autoextend on;
 
Tablespace created.

유저 생성 및 default tablespace 지정

SQL> create user beuser identified by beuser account unlock default tablespace begints;
 
User created.

dba 권한부여

SQL> grant dba to beuser;
 
Grant succeeded.

유저접속

SQL> conn beuser/beuser
Connected.

데이터 파일 크기 조회(초기 10M)

SQL> select tablespace_name, bytes/1024 KB, autoextensible from dba_data_files
where file_id = 6;
 
TABLESPACE_NAME                KB AUT
------------------------------ ---------- ---
BEGINTS                 10240 YES

비긴백업 수행

SQL> alter tablespace begints begin backup;
 
Tablespace altered.

SCN 조회

SQL> select * from v$backup where file#=6;
 
     FILE# STATUS         CHANGE# TIME
---------- ------------------ ---------- ---------
     6 ACTIVE         5014788 11-OCT-19

테이블 생성

SQL> create table beuser.betest as select * from dba_objects;
 
Table created.

커밋

SQL> commit;
 
Commit complete.

SCN조회(동일)

SQL> select * from v$backup where file#=6;
 
     FILE# STATUS         CHANGE# TIME
---------- ------------------ ---------- ---------
     6 ACTIVE         5014788 11-OCT-19

로그스위치 수행

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

SCN조회(동일)

SQL> select * from v$backup where file#=6;
 
     FILE# STATUS         CHANGE# TIME
---------- ------------------ ---------- ---------
     6 ACTIVE         5014788 11-OCT-19

데이터 추가 삽입

SQL> insert into beuser.betest select * from beuser.betest;
 
50297 rows created.
 
SQL> /
 
100594 rows created.
 
SQL> /
 
201188 rows created.
 
SQL> /
 
402376 rows created.
 
SQL> /
 
804752 rows created.

커밋

SQL> commit;
 
Commit complete.

SCN조회(동일)

SQL> select * from v$backup where file#=6;
 
     FILE# STATUS         CHANGE# TIME
---------- ------------------ ---------- ---------
     6 ACTIVE         5014788 11-OCT-19

로그스위치 수행

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

SCN조회(동일)

SQL> select * from v$backup where file#=6;
 
     FILE# STATUS         CHANGE# TIME
---------- ------------------ ---------- ---------
     6 ACTIVE         5014788 11-OCT-19

테이블스페이스 용량조회(17M로 증가됨)

SQL> select tablespace_name, bytes/1024 KB, autoextensible from dba_data_files
where file_id = 6;
 
TABLESPACE_NAME                KB AUT
------------------------------ ---------- ---
BEGINTS                181248 YES

데이터파일 용량 조회(17M로 증가됨)

SQL> !ls -al /oracle/app/oracle/oradata/ORCL/begints01.dbf
total 1366484
drwxr-xr-x  2 oracle dba      4096 Oct 11 23:54 .
drwxr-xr-x  4 oracle dba      4096 Apr 19 08:54 ..
-rw-r-----  1 oracle dba 185606144 Oct 12 00:00 begints01.dbf

엔드백업 수행

SQL> alter tablespace begints end backup;
 
Tablespace altered.

테이블스페이스 용량조회(변동없음)

SQL> select tablespace_name, bytes/1024 KB, autoextensible from dba_data_files
where file_id = 6;
 
TABLESPACE_NAME                KB AUT
------------------------------ ---------- ---
BEGINTS                181248 YES

데이터파일 용량 조회(변동없음)

SQL> !ls -al /oracle/app/oracle/oradata/ORCL/begints01.dbf
total 1366484
drwxr-xr-x  2 oracle dba      4096 Oct 11 23:54 .
drwxr-xr-x  4 oracle dba      4096 Apr 19 08:54 ..
-rw-r-----  1 oracle dba 185606144 Oct 12 00:00 begints01.dbf

scn 조회

SQL> select * from v$backup where file#=6;
 
     FILE# STATUS         CHANGE# TIME
---------- ------------------ ---------- ---------
     6 NOT ACTIVE         5014788  11-OCT-19

테스트3 결론

- begin backup 이후 데이터 삽입, 로그스위치를 해도 SCN은 증가하지 않고

데이터파일에 변경 내용이 저장 되어 파일 사이즈가 증가한다.

--191012 추가--

추가 자료

MOS문서에 나온 내용 공유드립니다.

영어가 부족해서 대략 적인 내용만 설명해 볼께요...

(영잘알 분이나, 더 고수분들이 계시면 추가 설명해주시면 감사드리겠습니다. (__ 

참고 자료 : MOS 문서 What Happens When A Tablespace/Database Is Kept In Begin Backup Mode (문서 ID 469950.1)

Therefore oracle internally manages the consistency as below : 

1.  The first time a block is changed in a datafile that is in hot backup mode, the entire block is written to the redo log files, not just the changed bytes. Normally only the changed bytes (a redo vector) is written.

첫째로, 핫 백업 모드로 변경 된 데이터파일에서 블록이 변경 시, 리두에 기록되는 건 변경된 bytes가 아니라 변경 된 블록이 기록됨. 일반적으로는 오직 변경 된 바이트만 저장 됨.

 In hot backup mode, the entire block is logged the first time. This is because you can get into a situation where the process copying the datafile and DBWR are working on the same block simultaneously.

Lets say they are and the OS blocking read factor is 512bytes (the OS reads 512 bytes from disk at a time). The backup program goes to read an 8k Oracle block. The OS gives it 4k. Meanwhile -- DBWR has asked to rewrite this block. the OS schedules the DBWR write to occur right now. The entire 8k block is rewritten. The backup program starts running again (multi-tasking OS here) and reads the last 4k of the block. The backup program has now gotten an fractured block -- the head and tail are from two points in time.

We cannot deal with that during recovery. Hence, we log the entire block image so that during recovery, this block is totally rewritten from redo and is consistent with itself atleast. We can recover it from there.

핫 백업 모드에서 복사 중 copy 프로세스와 DBWR의 작업이 동시에 발생할 때 이상 상태에 대한 설명입니다.

일반적으로 오라클은 8k 블록을 많이 사용하고, OS는 4k블록을 많이 사용하죠. (물론 설정에 따라 다를 수 있음)

오라클에서의 블록의 기록 단위는 8k인데, copy는 4k단위로 수행 되겠죠?

이때 DBWn가 작업 중인 블록을 copy하려고 한다면 4k는 DBWn가 기록 전인 블록으로, 4k는 기록 후인 블록으로 복사되는 시나리오도 충분히 나올 수 있습니다.

이러한 copy중 발생되는 이상현상에 대비해서 redo log에 change bytes가 아닌 change block으로 저장하는 것 때문에 아카이브로그 사이즈가 커지는 데, 이걸 가지고 변경 데이터를 아카이브에 저장한다고 오해하시는 분들이 많더라구요...

2. The datafile headers which contain the SCN of the last completed checkpoint are not updated while a file is in hot backup mode. This lets the recovery process understand what archive redo log files might be needed to fully recover this file. 

핫백업 모드에서는 데이터피일 해더의 checkpoint scn을 더 이상 업데이트 하지 않습니다.

위 1번의 이유로 BEGIN 백업 이후 카피 되는 데이터파일은 일관성을 보장할 수 없습니다. 따라서 BEGIN 백업 이후 복사된 파일을 이용하기 위해서는 해당 시점부터 전체 복구를 하는 게 안정적이라 할 수 있겠죠?

따라서 BEGIN 백업을 수행하면 더 이상 데이터파일 해더의 SCN을 업데이트 하지 않습니다.

이 파일은 이 때부터는 복구 되어야 한다는 것을 명시하는 것이죠.

To limit the effect of this additional logging, you should ensure you only place one tablepspace at a time in backup mode and bring the tablespace out of backup mode as soon as you have backed it up. This will reduce the number of blocks that may have to be logged to the minimum possible. 

 추가적인 로깅을 제한 하려면 가급적 테이블스페이스 단위로 백업 모드를 하는 게 낫다는 내용

---------------

Try to take the hot/online backups when there is less / no load on the database, so that less redo will be generated.

hot/online backup을 한다고 추가적인 부하가 발생 되진 않음. 다만 redo가 더 생성 될 뿐...

---------------

공식 문서상으로는 BEGIN BACKUP 한다고 데이터파일이 변경 되지 않는다고 나오는 게 아니라, BEGIN 백업 후 데이터파일이 변경되는 동안 OS에서 Copy 작업에 대한 이상현상을 방지하기 위한 메카니즘이 나온다고 이해하시면 될 듯 합니다.

오라클 하시면 가급적 민간요법(?)은 믿는 게 아닙니다.

참조 : https://cafe.naver.com/prodba/50037

(문서 ID 469950.1)

https://cafe.naver.com/dbian/1199

https://m.blog.naver.com/bkbspark0725/222034237601