[데이터베이스/OCP] 오라클 서버의 구조의 백업/복구 원리

오라클 / OCP 10g 2008. 3. 31. 10:22

오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원 오라클 OCP 오라클자격증 OCP자격증 데이터베이스 DB 데이터베이스관리자 DB관리자 오라클학원 OCP학원

1장 오라클 서버의 구조와 백업/복구원리

주종면 | 플랜정보기술

오라클 데이터베이스를 사용하다 보면 다양한 에러코드와 함께 장애가 발생하는 경우를 한두 번쯤 경험해 보았을 것 입니다. 이런 경우 대부분의 사용자들은 자신이 알고 있는 모든 지식을 기반으로 복구작업을 수행하게 됩니다. 하지만, 막연한 방법과 절차는 복구작업에 도움이 되지 않을 뿐 아니라 오히려 불필요한 시간의 낭비를 초래할 수 있기 때문에 무엇보다도 철저한 계획과 준비가 요구됩니다. 또 한가지 염두에 두어야 할 점은 다양한 장애와 복구방법에 대한 이해를 하기 전에 반드시 오라클 서버 구조에 대한 이해를 하셔야 합니다. 구조에 대한 명확한 이해 없이는 장애에 대한 복구작업을 수행할 수가 없기 때문입니다.

자~ 그럼 오라클 서버의 전체 구조와 복구 원리를 소개하도록 하겠습니다.

1-1 오라클 서버의 구조

먼저, 오라클 서버에 대한 장애와 복구를 체계적으로 습득하기 위해서는 물리적 구조에 대한 이해를 명확히 하셔야 합니다. 예를 들어, 어느날 여러분이 소유하고 계신 자동차가 갑자기 정상적으로 시동이 걸리지 않는다면 어떻게 하시겠습니까?

만약, 여러분이 자동차 구조에 대한 해박한 지식을 가지고 있다면 직접 원인을 찾기 위해 다양한 점검을 하게 되고, 또한 조치를 하게 될 것 입니다. 하지만, 자동차 구조에 대해 전혀 이해를 못한다면 이러한 경우 여러분이 할 수 있는 것은 아무것도 없을 것 입니다.

이와 같은 원리로 오라클 서버환경에서도 장애가 발생했을 때 적절한 조치와 복구작업이 수행되기 위해서는 장애가 발생한 원인을 분석할 수 있어야 합니다. 또한, 그 원인을 분석하기 위해서는 오라클 서버에 대한 철저한 이해가 요구됩니다. 다음은 오라클 서버의 기본구조에 대한 설명입니다. 오라클 서버는 다음과 같이 3가지 영역으로 구성되어 있습니다.

1) 메모리 영역

오라클 서버가 사용 가능한 상태가 되면 모든 사용자들은 데이터베이스에 접속할 수 있으며, 또한 테이블을 통해 데이터를 검색할 수 있게 됩니다. 이때, 읽혀진 테이블 정보들이 잠시 저장되는 공간이 메모리 영역 입니다. 이 공간은 SGA (System Global Area) 영역이라고 부르며 다음과 같이 4가지 영역으로 구성되어 있습니다.

• 공유-풀 영역 (Shared Pool Area)
• 데이터버퍼 캐시 영역 (Data Buffer Cache Area)
• 로그버퍼 영역 (Log Buffer Area)
• 라지-풀 영역 (Large Pool Area)
• 자바-풀 영역 (Java Pool Area)
• 스트림-풀 영역 (Stream Pool Area)

2) 프로세스 영역

사용자가 오라클 서버에 접속하기 위해서는 SQL*PLUS 또는 사용자의 애플리케이션 프로그램을 통해 접속하게 됩니다. 이때, 활성화 되는 영역을 사용자 프로세스(User Process)라고 합니다. 그리고, 사용자가 실행한 SQL문이 실행되기 위해서는 서버 프로세스(Server Process)에 의해 분석되며 테이블로부터 읽기 또는 쓰기 작업을 수행하게 됩니다.

또한, 오라클 서버가 효과적으로 운영되기 위해서 다음과 같은 백그라운드 프로세스(Background Process)가 기본적으로 제공됩니다.

• DBWR (Database Writer Process)
• LGWR (Log Writer Process)
• PMON (Process Monitor Process)
• SMON (System Monitor Process)
• CKPT (Check-Point Process)
• ARCH (Archive Process)
• RVWR
• MMAN (Memory Manager Process)
• RBAL
• ORBn
• RFS (Remote File System Proces)
• MRO

3) 파일 영역

사용자 또는 오라클 서버에 의해 생성되는 모든 테이블 정보가 저장되는 물리적 구조를 파일 영역 또는 데이터베이스(Database) 영역이라고 합니다.

다음은 오라클 서버의 기본 파일구조 입니다.

• 파라메터 파일 (Parameter File)
• 데이터 파일 (Data-File)
• 리두로그 파일 (Redo-Log File)
• 컨트롤 파일 (Control File)
• 플래시-백 데이터베이스 로그 파일 (Flash-Back Database Log File)
• 아카이브 리두로그 파일 (Archive Redo-Log File)

자~ 그럼 보다 구체적으로 오라클 서버의 각 구조를 알아 보도록 하겠습니다.

1-2 SELECT문의 처리과정

이번에는 SELECT문의 처리과정을 통해 오라클 서버의 구조를 보다 구체적으로 알아 보도록 하겠습니다. 사용자들이 실행하는 SELECT문의 결과가 리턴될 때 오라클 서버의 각 구조를 어떻게 사용하는지를 이해해 보십시오.

1) STEP-1 : Parsing

SQL*PLUS 툴을 통해 SCOTT 사용자 계정과 TIGER 암호로 오라클 서버에 접속합니다.

사용자가 실행한 SELECT문은 사용자 프로세스를 거쳐 서버 프로세스로 전송이 됩니다. 서버 프로세스는 사용자가 실행한 SELECT문에 대해 다음과 같이 구문분석(Parsing) 작업을 수행합니다.

<구문분석>
(1)	메모리 영역 중에 공유-풀 영역을 검색하여 사용자가 실행한 문장과 동일한 문장이 존재하는지 확인합니다. 동일한 문장이 발견되면 구문분석 작업을 중단하고, 동일한 문장이 발견되지 않으면 다음 단계의 작업을 계속 수행합니다.

(2)	사용자가 실행한 SELECT문의 문법을 확인합니다.

(3)	SELECT문에 작성된 테이블과 컬럼 들이 사용가능한지 확인합니다.

(4)	해당 사용자가 테이블과 컬럼 들을 검색할 수 있는 권한이 있는지 확인합니다.

(5)	모든 검증작업이 완료되고 나면 구문 분석된 결과를 공유-풀 영역에 저장합니다. 분석결과를 저장하는 이유는 다른 사용자에 의해 동일한 문장이 재 실행되는 경우 구문분석 작업을 재 수행하는 불필요한 작업을 피하게 함으로써 SELECT문의 실행성능을 빠르게 하기 위함 입니다.

2) STEP-2 : Execution

해당 테이블이 저장되어 있는 데이터 파일로부터 데이터를 읽어서 메모리 영역인 데이터-버퍼 캐시 영역(Data-Buffer Cache Area)에 저장해 둡니다. 먼저, 테이블과 데이터 파일과의 관계를 이해하기 위해서는 다음 문장에 대한 이해가 필요합니다.

SQL> CREATE TABLESPACE insa
DATAFILE 'C:\ORACLE\ORADATA\ORA92\INSA01.DBF' SIZE 10M;
→ 인사 업무에 관련된 테이블이 저장될 공간

SQL> CREATE TABLE emp
(EMPNO NUMBER(4),
ENAME VARCHAR2(15))
TABLESPACE insa;
→ EMP 테이블이 저장될 공간은 INSA 테이블스페이스 입니다. 다른 의미로 표현한다면
EMP 테이블이 저장될 공간은 INSA01.DBF 파일입니다.

3) STEP-3 : Fetch

STEP-2 단계에 의해 데이터 버퍼 캐시영역에 저장되어 있는 데이터를 읽어서 사용자의 SQL*PLUS 화면에 출력해 주는 단계를 인출(FETCH)라고 합니다. 이 단계는 SELECT문을 실행하는 경우에만 수행되며 UPDATE, DELETE, INSERT문을 실행할 때는 수행되지 않습니다. 즉, SQL문을 실행한 후 처리된 결과가 화면에 출력되는 것을 인출이라고 합니다.

1-3 DML문의 처리과정

이번에는 DML문 (UPDATE, INSERT, DELETE)의 처리과정에 대해 자세히 알아 보도록 하겠습니다. 사용자가 실행한 DML문에 대해 구문분석을 수행하는 단계까지는 SELECT문과 동일한 방법과 절차에 의해 수행됩니다.

먼저, 처리과정에 대해 알아보기 전에 DML문에서 만 사용되는 오라클 서버의 기본구조에 대해 알아 보겠습니다.

[C:\] sqlplus SCOTT/TIGER
SQL>	UPDATE emp SET sal = sal * 1.1 WHERE empno = 7934;
SQL>	SELECT * FROM emp WHERE empno = 7934; 7934 KING 1100

SQL>	ROLLBACK;
SQL>	SELECT * FROM emp WHERE empno = 7934; 7934 KING 1000

SQL 문장 중에 DML문들은 항상 실행한 후 COMMIT 또는 ROLLBACK문을 실행해야 해당 트랜잭션이 종료됩니다. 위 예제와 같이 UPDATE 문을 실행한 후 ROLLBACK문을 실행하게 되면 변경되었던 모든 행 정보는 취소됩니다. 이러한 과정을 처리하기 위해서는 UPDATE문이 실행될 때 마다 변경 전 데이터 (7934 KING 1000)와 변경 후 데이터(10 KING 1100)를 모두 어딘가에 저장해 두었다가 ROLLBACK문을 만나는 순간 변경 전 데이터로 변경 후 데이터를 복구해야 할 것 입니다. 이때 변경 전 데이터를 잠시 저장해 두는 공간을 롤백-세그멘트(Rollback Segment) 또는 언두 세그멘트(Undo Segment)라고 합니다. 위 그림에서 데이터 파일에 생성되어 있는 RBS01은 언두 세그멘트 입니다. 현재, 위 그림의 공유-풀 영역을 보면 사용자가 실행한 UPDATE문의 구문 분석된 결과가 저장되어 있으므로 UPDATE문이 파싱까지 수행되어 있는 것을 알 수 있습니다.

1) STEP-1/STEP-2

데이터 파일로부터 해당 테이블을 읽어 행 데이터를 데이터 버퍼 캐시영역에 저장합니다.
이때, 메모리에 저장되는 행 데이터에 대한 변경 작업을 수행하기 위해서는 만약 변경 작업 후 ROLLBACK문을 수행할 것을 대비하며 변경 전 데이터를 저장해 둘 수 있는 언두 세그멘트의 공간을 확보해 두어야 합니다. 위 그림에서 RBS01 데이터 파일과 데이터 버퍼 캐시영역에 일정한 공간을 확보합니다.

2) STEP-3

공유-풀 영역을 구성하는 데이터 딕션어리 캐시영역 (Data Dictionary Cache Area)은 사용자가 실행한 DML문의 구문분석을 수행하기 위한 테이블 정보와 락(Lock) 정보를 저장해 주는 메모리 영역입니다.
UPDATE문을 실행했을 때 어떤 행에 락(LOCK)이 발생하였는지를 기록해 두었다가 다른 사용자들이 똑 같은 행 데이터에 대해 변경작업을 수행하려고 하면 더 이상 작업을 수행하지 못하도록 DML문을 대기상태로 만들게 됩니다.

3) STEP-4

마지막 단계는 리두로그 버퍼영역에 변경 전 데이터(1 주종면 100)와 변경 후 데이터(1 주종면 110)를 모두 백업(Backup)하게 됩니다.(이렇게 모든 변경정보를 백업하는 이유는 "백업과 복구 원리"에서 자세히 소개됩니다.)

1-4 COMMIT문의 처리과정

마지막으로 DML문을 수행한 후 트랜잭션(Transaction)을 종료하기 위해 실행하는 COMMIT 문의처리 과정에 대해 자세히 알아보도록 하겠습니다.

1) STEP-1

사용자가 DML문을 실행한 후 COMMIT문을 실행하면 서버 프로세스로 전송됩니다.

2) STEP-2

서버 프로세는 로그버퍼 영역에 백업되어 있는 데이터에 대해 시스템 변경번호(System Change Number)를 부여합니다. 사용자가 COMMIT문을 수행할 때 마다 오라클 서버에 의해 연속적으로 부여되며 해당 트랜잭션이 데이터베이스 생성 후 몇 번째로 COMMIT 된 것인지를 나타냅니다. (SCN의 사용 용도에 대해서는 "백업과 복구 원리"에서 자세히 설명됩니다.)

3) STEP-3

일정한 시점이 되면 LGWR는 로그버퍼 영역에 백업되어 있는 데이터를 리두로그 파일로 저장합니다. 왜냐하면, STEP-2 단계에서 언급한대로 리두로그 버퍼는 사용자들이 실행한 DML문에 의해 발생한 모든 변경된 데이터를 저장하는 공간인데, 만약, 시스템이 갑자기 정전되면 리두로그 버퍼에 저장되어 있던 모든 데이터들이 유실되기 때문입니다. 그래서, 일정시점이 되면 LGWR 프로세는 리두로그 버퍼의 데이터들을 영구히 저장될 수 있는 운영체계 상의 리두로그 파일로 저장하게 되는 것 입니다.

다음은 LGWR가 리두로그 버퍼의 내용을 리두로그 파일로 저장하는 시점의 경우입니다.

• 사용자가 COMMIT문을 실행하는 경우
• 매 3초가 지날 때 마다 오라클 서버에 의해 실행되는 경우
• CHECKPOINT가 발생하는 경우
• 오라클 서버가 정상적으로 SHUTDOWN 되는 경우

4) STEP-4

LGWR 프로세스에 의해 리두로그 파일에 백업 데이터가 저장되고 나면 사용자의 화면에 "Commited"라는 메시지를 출력하게 됩니다.
즉, "커밋 되었습니다"라는 메시지의 의미는 변경 데이터를 테이블에 저장했다는 의미가 아니라 관련 데이터를 백업했다는 의미를 가지고 있습니다.

5) STEP-5

LGWR 프로세스가 리두로그 버퍼의 모든 데이터를 리두로그 파일에 기록하지 못한 경우에는 다음 리두로그 파일로 이동하여 계속적으로 데이터를 기록하게 됩니다.

6) STEP-6

LGWR 프로세스가 하나의 리두로그 파일에 모든 로그버퍼의 데이터를 저장하지 못하면 다음 로그파일로 이동하게 되는데 이때 CKPT 프로세스는 체크포인트(CHECKPOINT)를 발생시켜 현재 시점까지의 모든 변경 상태를 컨트롤 파일(Control File)과 데이터 파일(Data File)에 기록하게 됩니다. (모든 변경상태를 기록해 두는 이유는 "백업과 복구 원리"에서 자세히 설명됩니다.)

7) STEP-7

DBWR 프로세스는 데이터 버퍼 캐시영역에 저장되어 있는 테이블의 변경 후 데이터를 최종적으로 테이블에 기록하게 됩니다.

1-5 오라클 서버의 시작과 종료

지금까지 사용자가 실행하는 SELECT문, DML문, COMMIT문의 처리과정을 통해 오라클 서버의 각 구조가 어떤 역할을 하게 되는지 자세히 알아 보았습니다.

이번에는 오라클 서버의 시작과 종료단계에 대해 보다 구체적인 이해를 해 보도록 하겠습니다. 또한, 기본구조를 설명하면서 소개되지 않았던 다른 구조들과 시작과 종료의 기본 원리에 대해서도 함께 소개될 것 입니다.

오라클 데이터베이스를 사용하면서 발생하는 장애에 대한 원인을 쉽게 파악하고 복구 절차를 이해하기 위해서는 지금부터 소개 드리는 내용이 매우 중요합니다.

1)NOMOUNT 단계

STARTUP 명령어에 의해 오라클 서버를 시작하는 첫 번째 단계를 NOMOUNT 단계라고 합니다. 이 단계를 수행하게 되면 오라클 서버의 기본구조 중에 메모리 영역(SGA 영역)과 백그라운드 프로세스가 사용 가능한 상태로 활성화 됩니다.

결론적으로 메모리 영역이 활성화 되기 위해서는 데이터 버퍼 캐시영역과 로그버퍼 영역 그리고, 공유-풀 영역을 활성화 해야 하며 각 영역에 대한 크기를 결정해야 할 것 입니다.

각 메모리 영역의 크기는 init<SID>ora 파라메터 파일을 참조하면 다음과 같은 파라메터 값을 참조하게 됩니다.

[C:\] EDIT initORCL.ora

SHARED_POOL_SIZE		= 33000000	← 공유-풀 영역의 크기를 결정
LOG_BUGGER		= 8192	← 로그버퍼 영역의 크기를 결정
DB_CACHE_SIZE		= 33000000	← 데이터 버퍼 캐시영역의 크기를 결정

(1)	init<SID>.ora 파라메터 파일을 읽어 관련된 파라메터 값을 참조합니다.
(2)	관련 파라메터 값을 기반으로 SGA 영역을 활성화 합니다.
(3)	관련 파라메터 값을 기반으로 백그라운드 프로세스를 활성화 합니다.
(4)	BACKGROUND_DUMP_DEST 파라메터가 지정하는 경로에 있는 ALERT!_<SID>.LOG 파일에 데이터베이스의 시작과 관련된 모든 로그 정보를 기록해 둡니다.

만약, init<SID>.ora 파라메터 파일을 읽을 수 없다면 어떻게 될까요 ?

[C:\] CD C:\ORACLE\ORA92\DATABASE
[C:\] MOVE initORCL.ora initORCL.bak
[C:\] sqlplus "/as sysdba"
SQL> STARTUP
ORA- ERROR
→ NOMOUNT 단계를 수행하기 위해서 init<SID>.ora 파일을 읽어야 하지만 파라메터 파일은 이미 MOVE 된 상태이기 때문에 읽을 수가 없습니다.

2) MOUNT 단계

오라클 서버의 두 번째 시작 단계를 MOUNT 단계라고 합니다. 이 단계는 현재 데이터베이스의 모든 상태 정보를 읽어오게 됩니다.

(1)	먼저, 오라클 데이터베이스의 모든 상태정보를 저장하고 있는 컨트롤 파일을 읽습니다.

(2)	오라클 데이터베이스의 환경을 결정하는 init.ora 파라메터 파일을 읽습니다.

(3)	컨트롤 파일과 파라메터 파일에 저장되어 있는 여러가지 환경 정보(DB_NAME 명)가 일치하는지를 검증합니다. 만약, 이 단계에서 환경정보가 일치하지 않으면 MOUNT 단계는 실패하게 되고 사용자들은 데이터베이스를 사용할 수 없게 됩니다. 그러므로, init<SID>.ora 파일 내에 환경설정 정보를 임의로 변경해서는 안됩니다.

(4)	기타, 데이터 파일과 리두로그 파일의 이름과 경로, 현재 상태정보도 읽습니다.

만약, control01.ctl 컨트롤 파일을 읽을 수 없다면 어떻게 될까요 ?

[C:\] CD C:\ORACLE\ORADATA\ORA92
[C:\] MOVE control01.ctl control01.bak

[C:\] sqlplus "/as sysdba"
SQL> STARTUP

ORA- ERROR
→ MOUNT 단계를 수행하기 위해서 control01.ctl 파일을 읽어야 하지만 컨트롤 파일은 이미 MOVE 된 상태이기 때문에 읽을 수가 없습니다. NOMOUNT 단계 수행 후 MOUNT 단계를 수행하지 못해 에러가 발생합니다.

3) OPEN 단계

오라클 서버의 마지막 시작 단계를 OPEN 단계라고 합니다. 이 단계는 MOUNT 단계에서 수집한 데이터베이스의 상태정보가 정상적인지 확인하는 작업을 수행하게 됩니다.
예를 들어, 컨트롤 파일 내에는 SYSTEM 테이블스페이스가 c:\oracle\oradata\ora92\users01.dbf 파일로 존재한다는 상태 정보를 가지고 있는데, 실제 운영체계 상의 해당 경로에 해당 파일이 존재하는지를 검증하게 됩니다.
참고로, SQL*PLUS 상에서 테이블스페이스를 생성하게 되면 관련된 모든 정보가 컨트롤 파일에 저장됩니다. 이렇게 저장하는 이유는 데이터베이스의 시작단계에서 사용자가 생성한 테이블스페이스 인지를 검증하기 위해서 입니다. 컨트롤 파일에 정의되어 있는 파일 및 경로가 운영체계 상에 실제 파일 및 경로로 존재하지 않으면 데이터베이스를 더 이상 OPEN 하지 않으며 사용할 수 없게 됩니다.
만약, 모든 상태정보가 일치한다면 사용자들은 오라클 서버에 접속할 수 있게 되고 또한 테이블을 검색 및 조작할 수 있게 됩니다.

만약, system01.dbf 데이터 파일을 읽을 수 없다면 어떻게 될까요 ?

[C:\] CD C:\ORACLE\ORADATA\ORA92
[C:\] MOVE users01.dbf users01.bak
[C:\] sqlplus "/as sysdba"
SQL> STARTUP
ORA- ERROR c:\oracle\oradata\ora92\users01.dbf
→ OPEN 단계를 수행하기 위해서 컨트롤 파일에 정의되어 있는 데이터 파일의 상태정보와 실제 운영체계 상의 파일의 상태정보가 일치 하는지를 확인하게 됩니다. SYSTEM01.DBF 데이터 파일은 이미 MOVE 된 상태이기 때문에 읽을 수가 없습니다.

1-6 백업과 복구 원리

데이터베이스를 운영하다 보면 예상하지 못한 시스템 에러나 사용자의 실수 또는 갑작스런 정전 등과 같은 주변환경의 문제로 인해 더 이상 데이터베이스를 운영할 수 없는 상황에 부딪히게 됩니다. 이런 경우가 발생하더라도 데이터베이스 관리자는 사용자의 데이터를 안전하게 복구할 수 있는 준비를 평소에 해야 하는데 오라클 데이터베이스에서는 여러 가지 백업과 복구방법을 제공하고 있습니다. 자신이 운용하는 데이터베이스가 어떤 성격의 데이터를 가지고 있으며, 얼마나 많은 데이터를 가지고 있는지, 장애가 발생한 경우 데이터의 복구시간이 더 중요한지 아니면 데이터의 복구율이 더 중요한지를 잘 이해하고 분석하여 적절한 백업 방법을 준비해야 합니다.

다음은 오라클 서버구조에서 사용자들이 실행하는 DML문에 의해 변경되는 데이터들에 대한 백업과 복구 원리에 대해서 알아 보도록 하겠습니다.
오라클 데이터베이스의 구조에서 로그버퍼 영역에는 사용자가 DML문을 통해 변경한 모든 데이터가 백업되며 로그기록기(LGWR)에 의해 로그파일에 저장됩니다. 로그버퍼와 로그파일에 변경 전 데이터와 변경 후 데이터 모두를 저장하는 이유는 갑작스런 시스템 에러나 사용자 실수, 정전 등으로부터 데이터베이스가 다운되거나 시스템이 다운될 때 변경된 데이터가 미처 테이블에 저장되지 못 했을 경우를 위해 백업작업을 수행하는 것입니다. 이런 경우, 모든 변경 데이터는 리두로그 파일에 저장되어 있다가 데이터베이스가 다시 정상적으로 시작될 때(STARTUP) 리두로그 파일에 저장되어 있던 데이터를 통해서 데이터를 복구하게 됩니다.

예를 들어, 대부분의 사용자들은 한두 가지의 워드 프로세스 툴을 사용하고 계실 것 입니다. 만약, 여러분이 자신이 수행하고 있는 업무에 대해 담당 관리자에게 보고서를 제출하기 위해 열심히 워드 프로세스 작업을 수행하고 있다고 가정해 보십시오.
약 10장 정도의 보고서를 작성하고 있는데 갑자기 정전이 되었다고 생각해 보십시오. 불행하게도 지금까지 작성한 보고서를 미처 저장도 하기 전에 정전이 되었다면 그때까지 입력한 모든 문서들은 삭제가 되고 말 것입니다. 바로 이런 문제를 해결하기 위해서는 워드 프로세스 툴의 환경설정에서 사용자가 직접 문서에 대해 저장하지 않더라도 툴에서 자동 저장해 주는 기능을 설정해 둘 수 있을 것 입니다.

오라클 데이터베이스 환경은 워드 프로세스와 같이 한명의 사용자가 데이터를 저장하는 구조가 아닙니다. 무수히 많은 사용자들이 데이터를 입력, 수정, 삭제, 조회하는 아주 복잡하고 까다로운 구조를 가지고 있는 시스템 소프트웨어 입니다.
이런 환경에서 어떤 사용자는 입력을 수행하고, 또 다른 사용자는 수정과 삭제를 수행하다가 갑자기 시스템이 정전에 의해 다운된다면 그때까지 처리되고 있던 모든 데이터들은 어떻게 될까요 ?
기본적으로 정전이 되던 시점까지 사용자가 COMMIT문을 수행하였다면 그 모든 데이터들은 리두로그 파일에 백업이 되어 있으며, 만약, COMMIT문을 수행하지 못했다면 모든 데이터들은 자동 롤백(Rollback)이 되게 됩니다.
그리고, COMMIT문을 처리하는 단계에서 보았던 것처럼, 리두로그 파일에는 백업되었지만 테이블에는 저장되지 못한 데이터들은 다시 데이터베이스가 재 시작하게 될 때 SMON 백그라운드 프로세스에 의해 리두로그 파일의 백업 데이터들이 읽혀져서 복구작업이 수행되게 됩니다.

1-7 시스템 변경 번호

이번에는 오라클 데이터베이스의 파일구조와 SCN 에 대해서 좀 더 자세히 알아보겠습니다.
먼저, 모든 데이터베이스 파일에는 사용자들이 COMMIT문을 실행할 때마다 발행되는 SCN(SYSTEM CHANGE NUMBER)이 CKPT 프로세스에 의해 모든 데이터 파일과 컨트롤 파일에 저장됩니다. (앞에서 소개 드린 "COMMIT문의 처리과정"을 참조하십시오.) SCN을 파일의 헤드 영역들에 저장하는 이유는 데이터베이스에서 COMMIT된 현재 시점을 구분하기 위해서 입니다. 만약, 향후에 데이터베이스에 문제가 발생하여 복구 작업을 수행해야 할 경우 특정시간, 특정 SCN을 기준으로 복구작업을 수행해야 할 때 경우도 있습니다.

SCN은 데이터베이스가 시작될 때(STARTUP) OPEN 단계에서 데이터 파일의 무결성을 검증할 때 사용되기도 합니다. ("오라클 서버의 시작과 종료"를 참조하십시오.)
예를 들어, 위 그림에서 2001년 6월 30일 백업 당시에 SCN은 100 이었다고 합니다. 그리고, 2001년 7월 31일 백업 당시에 SCN은 101 이었다고 합니다. 2001년 8월 10일 현재 시점에 컨트롤 파일에 장애가 발생하여 마지막에 백업되었던 컨트롤 파일(2001년 7월31일)을 현재 컨트롤 파일 위치로 복사 하였다고 합니다. 이런 경우, 데이터베이스를 다시 재 시작하면 어떻게 될까요 ?
결론적으로 데이터베이스는 정상적으로 시작되지 않습니다.

왜 그럼 정상적으로 사용할 수 없는 걸까요 ? 데이터베이스의 시작단계 중 OPEN 단계는 오라클 서버의 모든 데이터 파일과 컨트롤 파일들이 같은 시점의 데이터들 인지를 검증하기 위해 시스템 변경번호(System Change Number)를 검증하게 되는데, 컨트롤 파일에는 현재 SCN이 101이라고 되어 있고, 다른 데이터 파일들은 102 라고 되어 있기 때문에 이 파일들은 같은 시점의 데이터가 아니라고 판단하여 정상적으로 시작하지 않는 것 입니다.
시스템 변경번호는 COMMIT문을 실행할 때 마다 오라클 서버에 의해 발행되며 데이터베이스의 시작과 종료단계에서 데이터의 무결성을 보장하기 위해 사용되는 중요한 상태 값 중에 하나입니다. SCN은 컨트롤 파일과 데이터 파일의 헤드영역에 항상 기록되어 있습니다.

1-8 오라클 데이터베이스의 파일 구조

자~ 이번에는 오라클 서버의 구조 중에 파일(Files)에 대해 자세히 알아 봅시다.
오라클 데이터베이스를 자동으로 설치해 주는 유니버셜 인스톨러(Universal Installer)에 의해 오라클 서버를 설치하면 위 그림과 같이 CREATE DATABASE~문에 의해 기본적인 파일 구조들이 생성됩니다.

1) 파라메터 파일	CREATE DATABASE ~ ; 문법이 실행되기 전에 생성하며, 오라클 서버의 환경설정과 관련된 정보를 저장해 두는 파일입니다. 사용자가 직접 내용을 편집할 수 있는 텍스트 파일구조 입니다.

2) 리두로그 파일	CREATE DATABASE ~ LOGFILE ~ ; 문법에 의해 생성되며 사용자들이 실행하는 DML문에 의해 발생하는 모든 변경 데이터를 백업해 줍니다.

3) 컨트롤 파일	CREATE DATABASE ~ ; 문법에 의해 생성되며 이 문법에 정의되어 있는 모든 파일들에 대한 이름과 경로,크기,상태에 대한 정보를 저장합니다.

4) 데이터 파일	CREATE DATABASE ~ ; 문법에 의해 기본적으로 SYSTEM.DBF, UNDO.DBF, TEMP.DBF 파일을 생성해 주면 사용자에 의해 추가적으로 데이터 파일이 생성 됩니다.