대부분의 오라클 데이터베이스 사용자들은 유니버설 인스톨러(Universal Installer)에 의해 오라클 서버를 설치하게 되며 자신들의 데이터를 저장, 관리하는 일에 대부분의 시간과 노력을 투자하게 됩니다.
하지만, 자신들의 데이터를 안전하게 저장, 관리하기 위해서는 먼저, 오라클 서버의 기본구조를 명확히 이해해야 하며, 기본구조에 대한 안전한 구조설계를 해야 만 효과적으로 데이터를 저장, 관리할 수 있게 됩니다.
이번 섹션에서는 오라클 데이터베이스를 설치하고 난 후 반드시 고려해야 하는 구조설계에 대해 소개하고자 합니다.
|
|
2-1 오라클 DB의 논리적/물리적 구조 |
|
오라클 데이터베이스의 안전한 구조설계를 통해 데이터의 효과적인 저장, 관리를 하기 위해서는 먼저, 논리적, 물리적 구조에 대한 이해가 필수적입니다.
다음은 오라클 데이터베이스의 논리적 구조에 대한 설명입니다.
|
|
1) 데이터베이스
오라클 데이터베이스는 크게 논리적 구조와 물리적 구조로 나누어 구성되어 있습니다. 일반적으로 사용자들이 말하는 데이터베이스(Database)는 논리적 개념에서 사용되는 용어이며, 데이터(Data)의 집합이란 의미를 가지고 있습니다. 하지만, 오라클 서버에서 데이터베이스는 하나의 연속적인 공간을 일컫는 말은 아니며, 위 그림을 보시는 것처럼, 여러 개의 테이블스페이스(Tablespace)라는 논리적 구조가 모여서 하나의 데이터베이스를 구성하게 됩니다. |
|
2) 테이블스페이스와 데이터 파일
하나의 데이터베이스를 구성하는 여러 개의 논리적 구조들을 테이블스페이스(Tablespace)라고 합니다. 일반적으로, 테이블스페이스는 유니버셜 인스톨러(Universal Installer)에 의해 기본적으로 3개(SYSTEM , UNDOTBS, TEMP 테이블스페이스)가 생성되며 또한, 사용자에 의해 추가적으로 여러 개의 테이블스페이스가 생성될 수도 있습니다.
(1) SYSTEM 테이블스페이스
데이터베이스는 기본적으로 자료사전(Data Dictionary) 테이블을 제공합니다. 데이터베이스 내에 생성되어 있는 모든 객체들에 대한 정보 뿐만 아니라 데이터베이스의 현재 상태를 보여주며 서버에 의해 생성되며 관리됩니다. 이와 같은, 자료사전 테이블들이 저장되는 논리적 구조를 SYSTEM 테이블스페이스 라고 합니다.
SQL> CONNECT system/manager SQL> SELECT * FROM DBA_USERS; SQL> SELECT * FROM DBA_DATA_FILES;
결론적으로 이 공간에는 데이터베이스의 모든 상태정보가 저장되어 있는 공간입니다. (2) UNDOTBS 테이블스페이스
사용자들이 데이터베이스에 접속한 다음 DML문(Update, Delete, Insert)을 실행한 후 만약, 트랜잭션을 취소해야 한다면 ROLLBACK문을 수행하게 됩니다.
SQL> |
CONNECT scott/tiger |
SQL> |
SELECT empno, ename, sal FROM emp WHERE empno = 7934; |
|
SQL> |
UPDATE emp SET sal = sal * 1.1 WHERE empno = 7934; |
SQL> |
SELECT empno, ename, sal FROM emp WHERE empno = 7934; |
|
SQL> |
ROLLBACK; |
SQL> |
SELECT empno, ename, sal FROM emp WHERE empno = 7934; |
UPDATE문을 실행한 후 SELECT문을 수행하면 해당 사원의 SAL 컬럼 값이 변경되어 있는 것을 확인할 수 있습니다. 하지만, ROLLBACK문을 수행한 후 다시 SELECT문을 실행하면 UPDATE문을 실행하기 이전 상태로 돌아가 있는 것을 확인할 수 있을 것 입니다. 그렇다면, ROLLBACK문을 실행하기 이전에는 변경 후의 값이, 실행하고 난 후에는 변경 전의 값을 확인할 수 있다는 것은 사용자는 알 수 없지만 어딘가에 변경 전의 값이 잠시 저장되어 있다는 것을 미루어 짐작할 수 있을 것 입니다. 바로, 이 공간이 UNDOTBS 테이블스페이스 입니다. 결론적으로 이 공간에는 사용자의 ROLLBACK 데이터가 ROLLBACK 문장이 수행될 때까지 잠시 저장되어 있는 임시 공간입니다.
|
|
|
|
|
(3) TEMPORARY 테이블스페이스
UNDOTBS 테이블스페이스와 함께 사용자들이 자주 사용하는 것이 TEMP 테이블스페이스 입니다.
SQL> |
CONNECT scott/tiger |
|
SQL> |
SELECT empno, ename, sal FROM emp ORDER BY deptno; |
대부분의 사용자들이 데이터베이스에 접속하여 실행하는 문장들은 내부적으로 분류작업(Sorting)이 발생하게 됩니다. (ORDER BY, GROUP BY, DISTINCT, UNION CREATE INDEX~ 등) 왜냐하면, 기본적인 테이블 구조들은 데이터를 입력했을 때 입력하는 순으로 저장되기 때문에 테이블의 정보를 SELECT 해 보면 그 결과를 쉽게 참조할 수 없는 단점을 가지고 있기 때문입니다. 결국, 그 데이터를 분류작업(Sorting) 하기 위해서는 별도의 임시공간이 필요하게 되는데, 바로 이 공간이 TEMP 테이블스페이스 입니다. 결론적으로 이 공간에는 사용자의 SQL문이 분류작업을 요구하는 경우 잠시 사용하는 임시 공간입니다. (4) 데이터 파일
지금까지 소개 드린 SYSTEM, UNDOTBS, TEMP 테이블스페이스는 다음과 같이 CREATE DATABASE ~ ; 문법에 의해 오라클 데이터베이스가 설치될 때 생성됩니다. <xmp style="PADDING-BOTTOM: 5px; PADDING-LEFT: 15px; PADDING-RIGHT: 0px; BACKGROUND: #f4f4f4; PADDING-TOP: 5px"></xmp> CREATE DATABASE ora90 LOGFILE GROUP 1 ('c:\oracle\oradata\ora92\redo01.log') size 10m, GROUP 2 ('c:\oracle\oradata\ora92\redo02.log') size 10m) DATAFILE 'c:\oracle\oradata\ora92\system01.dbf' size 100m UNDO TABLESPACE undo DATAFILE 'c:\oracle\oradata\ora92\undo01.dbf' size 50m DEFAULT TEMPORARY TABLESPACE temp TEMPFILE 'c:\oracle\oradata\ora92\temp01.dbf' size 30m EXTENT MANAGEMENT LOCAL UNIFORM size 1m CHARACTER SET ko16ksc5601 NATIONAL CHARACTER SET al16utf16 SET TIME_ZONE = 'Korea/Seoul';
이 문법에서 SYSTEM01.DBF 데이터 파일은 SYSTEM 테이블스페이스에 대한 물리적 구조를 표현한 것이며, UNDO01.DBF 는 UNDOTBS 테이블스페이스, TEMP01.DBF는 TEMPORARY 테이블스페이스에 대한 물리적 구조를 표현한 것 입니다.
|
|
3) 세그멘트
데이터베이스 내에 생성되는 모든 객체( 테이블, 인덱스, 뷰, 시퀀스, 시노늄 등)들을 세그멘트(Segment) 라고 합니다. 다음 문법을 보시는 것처럼, 하나의 세그멘트는 하나의 테이블스페이스에 저장되는 하나의 구성요소 입니다.
SQL> |
CONNECT system/manager |
SQL> |
CREATE TABLESPACE insa DATAFILE 'C:\ORACLE\ORADATA\ORA92\test01.dbf' size 10M; |
|
SQL> |
CONNECT scott/tiger |
SQL> |
CREATE TABLE test (a NUMBER(2), b CHAR(10)) TABLESPACE insa; |
← TEST 테이블(세그멘트)는 INSA 테이블스페이스에 생성됩니다. |
|
|
4) 익스텐트
하나의 테이블스페이스가 여러 개의 세그멘트로 구성되어 있는 것처럼, 하나의 세그멘트도 여러 개의 익스텐트(Extent)가 모여서 구성됩니다. 하나의 테이블을 생성하면 처음부터 아주 큰 하나의 저장공간이 할당되는 것이 아니라, 처음에는 익스텐트라는 공간이 할당되고, 이 공간이 모두 사용되면 다시 익스텐트를 할당 받아 연속적으로 데이터를 저장하게 되는 것 입니다.
SQL> |
CONNECT scott/tiger |
SQL> |
CREATE TABLE test1 |
|
CREATE TABLE test1 |
|
a NUMBER(2), b VARCHAR2(10)) |
|
TABLESPACE insa |
|
STORAGE ( |
INITIAL |
10K ← 테이블의 최초 크기를 결정합니다. |
|
|
NEXT |
10K ← 최초 크기가 모두 사용된 후 다음 크기를 결정합니다. |
|
|
MINEXTENT |
1 |
|
|
MAXEXTENT |
UNLIMITED |
|
|
PCTINCREASE |
50); |
결론적으로, 하나의 테이블은 하나의 연속적인 공간으로 생성되는 것이 아니라 익스텐트라는 작은 구성요소로 생성되어 있는 것을 확인할 수 있습니다. |
|
5) 블록
오라클 데이터베이스의 가장 작은 저장구조를 블록(Block)이라고 합니다. 앞에서 소개 드린 익스텐트 구조는 사실은 하나의 연속적인 공간이 아니라 블록구조가 여러 개 모여 만들어지는 하나의 공간입니다. 결국, 여러 개의 블록이 모여 하나의 익스텐트를 만들게 됩니다.
그렇다면, 하나의 익스텐트를 왜 여러 개의 작은 구성요소로 만들었을까요 ??
만약, 하나의 익스텐트를 하나의 연속적인 공간으로 만들었다면 테이블의 데이터를 읽을 때 한번에 많은 데이터를 읽어야 하기 때문에 시간이 많이 소요될 뿐만 아니라 한번에 많은 데이터를 저장해야 하기 때문에 효과적인 저장과 관리가 용이하지 않기 때문입니다. 그래서, 연속적인 데이터를 여러 개의 블록구조로 쪼개서 관리함으로써 효율성을 높이게 되는 것 입니다.
오라클 데이터베이스의 논리적, 물리적 저장구조에 대한 보다 자세한 설명은 "오라클 데이터베이스의 관리"에 관련된 참고서적을 참고해 주십시오.
|
|
|
|
|
사례-1 |
|
사용자의 데이터가 저장되어 있는 테이블에 입력, 수정, 삭제작업을 수행하다 보면 자주 발생하는 에러현상이 있습니다. 이 현상은 테이블이 저장되어 있는 테이블스페이스의 공간이 부족한 경우에 주로 발생합니다.
• ORA-01653 에러코드가 발생하는 경우 • 테이블스페이스를 생성 또는 변경하거나 크기를 관리해야 경우
|
|
1) 테스트를 위해 TEST 테이블스페이스를 생성하십시오.
[C:\] sqlplus "/as sysdba" |
SQL> |
startup force |
SQL> |
create tablespace test datafile 'c:\oracle\oradata\ora92\test_01.dbf' size 3M; |
|
SQL> |
select tablespace_name, bytes, file_name from dba_data_files; |
|
|
2) TEST 테이블을 TEST 테이블스페이스에 생성하십시오.
[C:\] sqlplus "/as sysdba" |
SQL> |
create table test(name char(30)) tablespace test storage(initial 2M); |
|
|
3) TEST 테이블이 생성되었으면 연속적으로 행들을 입력하여 익스텐트 확장 시 에러가 발생하도록 하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> declare x number(2); begin for x in 1 .. 10000 loop insert into test values('111111111111111111111111111111'); end loop; end; / SQL> / SQL> / SQL> / ← 익스텐트 에러가 발생할 때 까지 반복적으로 실행하십시오. SQL> / declare * 1행에 오류: ORA-01653: SYS.TEST 테이블을 128(으)로 TEST 테이블스페이스에서 확장할 수 없습니다 ORA-06512: 줄 5에서
|
|
4) 테이블스페이스의 크기가 부족하여 발생하는 에러를 해결하기 위해서는 해당 테이블스페이스에 새로운 데이터 파일을 추가하는 방법입니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> alter tablespace test add datafile 'c:\oracle\oradata\ora92\test_02.dbf' size 3M; SQL> declare x number(2); begin for x in 1 .. 10000 loop insert into test values('111111111111111111111111111111'); end loop; end; / SQL> select tablespace_name, bytes, file_name from dba_data_files; SQL> host dir c:\oracle\oradata\ora92 → "test_02.dbf" 파일의 존재여부와 파일 크기를 확인하십시오. test_01.dbf test_02.dbf |
|
5) 테이블스페이스의 크기를 늘리는 두 번째 방법은 기존의 데이터 파일을 RESIZE절로 늘리는 방법입니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> alter database datafile 'c:\oracle\oradata\ora92\test_02.dbf' resize 5M; SQL> select tablespace_name, bytes, file_name from dba_data_files; SQL> host dir c:\oracle\oradata\ora92 |
|
6) 실습이 끝나면 TEST 테이블스페이스를 삭제하십시오. 해당 테이블스페이스 내에 관련 테이블이나 인덱스가 생성되어 있으면 테이블스페이스를 삭제할 수 없습니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> drop tablespace test; drop tablespace test * 1행에 오류: ORA-01549: 테이블스페이스가 비어있지 않으므로 INCLUDING CONTENTS 옵션 을 사용해 주십시오 SQL> drop tablespace test including contents; SQL> select tablespace_name, bytes, file_name from dba_data_files; SQL> host dir c:\oracle\oradata\ora92 test_01.dbf test_02.dbf |
|
7) 테이블스페이스를 삭제하더라도 관련 데이터 파일은 삭제되지 않습니다. 추가적인 작업을 통해 관련 데이터 파일을 함께 삭제하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> host del c:\oracle\oradata\ora92\test_0* SQL> host dir c:\oracle\oradata\ora92 SQL> exit |
|
|
|
|
사례-2 |
|
사용자들이 실행하는 SQL문장 중에는 SORTING(분류작업)이 유발되는 경우가 매우 많습니다. 동시에 많은 사용자들이 이러한 문장을 실행하게 되면 Temporary 테이블스페이스를 통해 분류작업을 수행하게 되는데 만약 TEMPORARY 테이블스페이스의 데이터 파일이 유실된다면 더 이상 작업이 진행되지 못하여 장애가 발생하게 됩니다. 이런 경우, 어떻게 장애를 복구해야 할까요 ?
|
|
1) 이 실습을 수행하기 위해 오라클 데이터베이스가 정상이라는 것을 확인하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus "/as sysdba" SQL> startup SQL> select tablespace_name, file_name from dba_temp_files; → 현재 오라클 서버환경에서 TEMPORARY 테이블스페이스의 이름과 위치를 분석하십시오. SQL> host dir c:\oracle\oradata\ora92\temp02.dbf |
|
2) 다음과 같은 실습 시나리오를 통해 TEMP 테이블스페이스에 장애가 발생 합니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> shutdown abort → 오라클 서버가 비정상적으로 종료됩니다. 갑자기, 정전이 발생하여 시스템이 종료되는 것과 동일한 시나리오를 연출하기 위함 입니다. SQL> exit [C:\] cd c:\oracle\oradata\ora92 [C:\] move temp02.dbf temp02.org → Temp 테이블스페이스가 디스크의 장애로 인해 읽기, 쓰기 작업이 수행되지 못하는 경우를 연출하기 위해 임의로 이동됩니다. [C:\] sqlplus "/as sysdba" SQL> startup mount SQL> alter database open; → TEMP 테이블스페이스에 장애가 발생하여 더 이상 읽기,쓰기 작업을 수행할 수 없지만 오라클 서버는 정상적으로 오픈 됩니다. 왜냐하면, TEMP 테이블스페이 스는 사용자의 데이터가 저장되는 공간이 아니라 SQL문을 실행할 때 발생하는 SORTING 데이터가 잠시 저장되는 임시 공간이기 때문에 직접적인 복구가 요구 되지 않기 때문에 오라클 서버는 정상적으로 오픈되는 것 입니다. 오라클 서버 가 오픈 된다는 것은 TEMP 테이블스페이스가 사용 가능하다는 것을 의미하는 것은 아니며, 오픈 후 복구작업을 수행해야 합니다. |
|
3) 다음은 TEMP 테이블스페이스를 복구하는 방법과 절차입니다.
TEMP 테이블스페이스에는 사용자의 데이터가 저장되어 있지 않으므로, 데이터에 대한 복구는 요구되지 않으며 다만, TEMP 테이블스페이스의 구조를 재생성 하는 것이 복구작업의 모든 것 입니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> select * from dba_tablespaces; → 자료사전 테이블에는 Temp" Tablespace는 그래도 존재합니다. 왜냐하면 Temp Tablespace의 구성 File 중 하나를 Drop한 것 뿐이기 때문입니다. SQL> drop tablespace temp including contents; → DROP 문장을 실행하면 컨트롤 파일 내에 존재하는 TEMP 테이블스페이스에 대한 정보와 데이터 딕션어리 테이블에 저장되어 있는 정보가 모두 삭제됩니다. SQL> create temporary tablespace temp2 tempfile 'c:\oracle\oradata\ora92\temp02.dbf' size 3m; → CREATE 문장을 실행하면 컨트롤 파일에 TEMP 테이블스페이스에 대한 정보가 저장되며 데이터 딕션어리 테이블에도 관련 정보가 저장됩니다. 컨트롤 파일에 관련 정보를 저장하는 이유는 데이터베이스의 무결성을 보장하기 위해서 입니다. SQL> host dir c:\oracle\oradata\ora92\temp02.dbf → 해당 경로에서 파일과 크기 확인 SQL> shutdown immediate SQL> exit [C:\] del c:\oracle\oradata\ora92\temp02.org → 이전 TEMP 파일은 불필요함으로 삭제 [C:\] cd |
|
|
|
|
2-2. 컨트롤 파일 |
|
2-2-1 다중 컨트롤 파일 시스템 이란?
오라클 데이터베이스를 설치하면 기본적으로 생성되는 파일들이 있습니다. 이 중에 컨트롤 파일은 별도의 문법에 의해 생성되지는 않으며 단지, CREATE DATABASE ~ 문법에 의해서만 자동 생성되고 데이터베이스 생성 시 모든 상태 정보를 저장하게 됩니다. (파일명과 경로, 시스템 변경번호, 로그-시퀀스 번호, 데이터베이스 명, 설치날자, Characterset 등) 또한, 데이터베이스 생성 시 오라클 서버는 init.ora 파라메터 파일에 정의되어 있는 CONTROL_FILES 파라메터 값을 참조하여 정해진 경로에, 정해진 파일이름으로, 정해진 개수 만큼의 컨트롤 파일을 생성하게 됩니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] CD C:\ORACLE\ORA92\DATABASE [C:\] EDIT init.ora CONTROL_FILES = ("C:\ORACLE\ORADATA\ORA92\CONTROL01.CTL", "C:\ORACLE\ORADATA\ORA92\CONTROL02.CTL")
예를 들어, 위 문법과 같이 2개의 컨트롤 파일에 대한 정보를 init.ora 파일에 정의하였다면, 데이터베이스 생성 시 오라클 서버는 컨트롤 파일을 정해진 위치에 정해진 이름으로 2개를 생성해 줍니다. 이때, 첫 번째 컨트롤 파일이 원본이며, 두 번째 파일은 미러링(Mirror) 컨트롤 파일입니다. 만약, init.ora 파일에 3 번째 컨트롤 파일에 대한 정보를 정의하였다면, 생성 후 하나의 원본 컨트롤 파일과 2개의 미러링 컨트롤 파일을 확인할 수 있을 것 입니다. 이러한 구조를 다중 컨트롤 파일 시스템(Multipled Control File System) 이라고 합니다. (기본적으로 오라클 서버는 사용자가 init.ora 파일에 컨트롤 파일에 대한 정보를 정의하지 않으면 1개의 원본 컨트롤 파일만 생성해 줍니다.)
결론적으로, 오라클 서버가 하나의 원본 컨트롤 파일과 여러 개의 미러링 컨트롤 파일을 제공하는 이유는 무엇일까요 ?
그 이유는 , 컨트롤 파일은 데이터베이스를 사용하면서 없어서는 안될 가장 중요한 파일 중에 하나이기 때문에 무엇보다도 잘 관리해야 만 오라클 데이터베이스의 안정성이 보장될 수 있기 때문 입니다. |
|
|
|
|
1) 데이터베이스의 시작단계에서 반드시 필요한 컨트롤 파일
데이터베이스를 시작할 때(STARTUP), NOMOUNT 단계가 끝나고 MOUNT 단계가 되면 컨트롤 파일 정보를 읽어 데이터베이스의 모든 파일 상태를 검증하게 되는데 만약, 컨트롤 파일을 읽을 수 없다면(사용자의 실수로 삭제되거나 디스크의 이상으로 생기는 문제) 데이터베이스는 더 이상 MOUNT 작업을 수행하지 않으며, 사용자들은 데이터베이스를 사용할 수 없게 됩니다. (1편 "오라클 서버의 시작과 종료"를 참조하십시오.) <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] CD C:\ORACLE\ORADATA\ORA92 [C:\] DEL *.CTL ← 모든 컨트롤 파일이 삭제됩니다. [C:\] sqlplus SQL*Plus: Release 9.0.1.0.0 - Production on Tue Mar 2 10:33:39 2004 (c) Copyright 2001 Oracle Corporation. All rights reserved. Enter user-name: /as sysdba Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 26140792 bytes Fixed Size 434296 bytes Variable Size 20971520 bytes Database Buffers 4194304 bytes Redo Buffers 540672 bytes ORA-00205: error in identifying controlfile, check alert log for more info |
|
2) COMMIT문을 실행할 때 SCN을 기록하기 위해 반드시 필요한 컨트롤 파일
1편 "COMMIT문의 처리과정"에서 소개한대로 컨트롤 파일의 용도는 사용자들이 DML문을 실행한 후 COMMIT문을 실행할 때 데이터베이스의 상태정보를 기록해 두는 파일입니다. 만약, 이 파일을 일기, 쓰기 할 수 없다면 더 이상 사용자들은 DML문을 실행할 수 없게 됩니다. (1편 "COMMIT문의 처리과정"을 참조하십시오.) <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] sqlplus SCOTT/TIGER SQL> UPDATE emp SET sal = sal 1.5; SQL> COMMIT; SQL> CONNECT /AS SYSDBA SQL> SHUTDOWN ORA-00210: cannot open the specified controlfile ORA-00202: controlfile: 'C:\ORACLE\ORADATA\ORA92\CONTROL01.CTL' ORA-27041: unable to open file SVR4 Error: 2: No such file or directory Additional information: 3
결론적으로, 컨트롤 파일은 항상 잘 관리해야 하고 문제가 발생했을 때 쉽게 대처할 수 있도록 평소에 백업을 잘 해 두는 것을 습관화 해야 합니다. WINDOWS 환경에서 유니버설 인스톨러에 의해 오라클 데이터베이스를 설치하면 기본적으로 3개의 컨트롤 파일이 생성됩니다. 첫 번째 파일이 원본 컨트롤 파일이며 두 번째, 세 번째 컨트롤 파일은 원본에 대한 미러링(MIRRORING) 파일입니다. 원본 컨트롤 파일에 문제가 발생하면 두 번째, 세 번째 파일로 쉽게 복구할 수 있도록 오라클 서버가 기본적으로 제공하는 것 입니다.(UNIX 환경에서는 기본적으로 하나의 컨트롤 파일이 생성됩니다.) 현재, 데이터베이스에서 사용하고 있는 컨트롤 파일의 위치와 이름을 알고 싶다면 init.ora 파일의 CONTROL_FILES 파라메터를 참조하십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>[C:\] CD C:\ORACLE\ORA92\DATABASE [C:\] EDIT init.ora ########################################### # 파일 구성 ########################################### control_files=( "C:\oracle\oradata\ORA92\CONTROL01.CTL", ← 원본 컨트롤 파일 "C:\oracle\oradata\ORA92\CONTROL02.CTL", ← 미러링 컨트롤 파일 "C:\oracle\oradata\ORA92\CONTROL03.CTL") ← 미러링 컨트롤 파일
또는, 다음과 같이 V$CONTROLFILE 자료사전을 참조해 보십시오. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> CONNECT system/manager SQL> SELECT * FROM V$CONTROLFILE; STATUS NAME --------------------------------------------- C:\oracle\oradata\ORA92\CONTROL01.CTL C:\oracle\oradata\ORA92\CONTROL02.CTL C:\oracle\oradata\ORA92\CONTROL03.CTL |
|
|
|
|
2-3. 리두로그 파일 |
|
2-3-1 다중 리두로그 파일 시스템의 설계와 방법
이번에는 오라클 데이터베이스의 안정적 운영을 위해 요구되는 구조적 설계에서 가장 중요한 다중 리두로그 파일 시스템(Multipled Redo-Log File System)에 대해서 자세히 알아 보도록 하겠습니다. |
|
1) 리두로그 파일 시스템
사용자의 SQL문에 대해 COMMIT문을 실행하면 SQL*PLUS 화면에 "커밋이 성공적이다"라는 메시지를 확인할 수 있습니다. 이 메시지의 의미는 커밋 되었던 모든 행 데이터(변경 전 데이터와 변경 후 데이터)를 리두로그 버퍼 영역에 백업했다는 의미이며, 이어 LGWR 백그라운드 프로세스가 일시적으로 저장되는 리두로그 버퍼 영역의 모든 데이터를 영구히 저장할 수 있는 리두로그 파일로 저장했다는 의미입니다. 결론적으로, 현재 변경한 행 데이터를 리두로그 파일로 백업했다는 의미를 가지게 됩니다. 리두로그 버퍼와 리두로그 파일에 모든 변경정보를 저장하는 이유는 갑작스런 시스템의 다운(DOWN) 또는 갑작스런 데이터베이스의 다운 시 처리하고 있던 모든 작업 내용이 테이블에 미쳐 저장되기 전이라면 데이터의 유실이 발생할 수 있기 때문입니다. 이때 리두로그 파일에 백업해 둔 데이터를 통해 데이터베이스를 복구하기 위해서 입니다.
사용자가 생성한 테이블에 대해 DML문을 실행할 때 모든 데이터가 리두로그 버퍼에 백업될 수 있는 이유는 해당 테이블이 생성될 때 LOGGING 문법 절에 의해 결정됩니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> CONNECT SCOTT/TIGER SQL> CREATE TABLE TEST1 (NO NUMBER, NAME VARCHAR2(15)) LOGGING;
테이블을 생성할 때, LOGGING 절을 부여하지 않으면 오라클 서버는 기본적으로 LOGGING 절을 적용해 줍니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> CREATE TABLE TEST2 (NO NUMBER, NAME VARCHAR2(15)) LOGGING;
만약, 해당 테이블에 대해서는 DML문이 실행될 때 모든 데이터를 백업하지 않아도 된다면 다음과 같이 NOLOGGIN 절을 사용할 수도 있습니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> CREATE TABLE TEST3 (NO NUMBER, NAME VARCHAR2(15)) NOLOGGING;
일반적으로, 다른 데이터베이스 환경에서 다운로드를 통해 재 사용되는 테이블이거나, 언제든지 해당 테이블에 대한 복구가 용이한 경우에는 NOLOGGING절을 사용할 수도 있습니다. 하지만, 이러한 경우가 아닌 경우에는 데이터베이스 차원에서 모든 데이터들에 대한 백업정보를 로그버퍼에 저장해 주는 것이 기본 모드입니다.
자 ~ 그럼 리두로그 파일의 구조에 대해서 조금 더 자세히 알아 보도록 하겠습니다.
기본적으로 CREATE DATABASE 문에 의해 오라클 데이터베이스를 생성하면 최소 2개의 리두로그 파일이 생성되며, 운영체계에 따라 차이는 있지만, 기본적으로 3개의 리두로그 파일이 생성됩니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> CREATE DATABASE ora90 LOGFILE GROUP 1 ('c:\oracle\oradata\ora92\redo01.log') size 100m, GROUP 2 ('c:\oracle\oradata\ora92\redo02.log') size 100m, GROUP 3 ('c:\oracle\oradata\ora92\redo03.log') size 100m) DATAFILE 'c:\oracle\oradata\ora92\system01.dbf' size 100m UNDO TABLESPACE undo DATAFILE 'c:\oracle\oradata\ora92\undo01.dbf' size 50m DEFAULT TEMPORARY TABLESPACE temp TEMPFILE 'c:\oracle\oradata\ora92\temp01.dbf' size 30m EXTENT MANAGEMENT LOCAL UNIFORM size 1m ;
또는, V$LOGFILE 자료사전을 통해서도 확인할 수 있습니다. <xmp style="PADDING-BOTTOM: 10px; PADDING-LEFT: 10px; PADDING-RIGHT: 10px; BACKGROUND: #f4f4f4; PADDING-TOP: 10px"></xmp>SQL> SET LINESIZE 1000 SQL> SELECT * FROM V$LOGFILE; GROUP# STATUS TYPE MEMBER ---------- -------- ------- ------------------------------------ 1 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO01.LOG 2 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO02.LOG 3 ONLINE C:\ORACLE\ORADATA\ORA92\REDO03.LOG |
|
|
|
|
2) 다중 리두로그 파일 시스템
이러한 리두로그 파일은 오라클 데이터베이스에 장애가 발생한 경우 복구작업을 수행하기 위해서는 반드시 필요한 백업 데이터를 저장하고 있기 때문에 철저한 관리가 요구됩니다. 그런데, 리두로그 파일이 저장되어 있는 디스크에 장애가 발생한다면 어떻게 될까요 ? 결론적으로 말하자면, 복구 시 사용해야 할 백업 데이터에 문제가 발생한 경우이므로, 만약, 데이터 파일에 대한 복구가 필요하다면, 복구작업을 수행할 수 없게 됩니다. 즉, 데이터의 유실이 발생하게 됩니다. 그래서, 오라클 사에서는 원본 리두로그 파일에 장애가 발생할 것을 대비하여 미러링(Mirroring) 리두로그 파일을 생성하게 함으로써, 어떤 장애가 발생하더라도 모든 데이터에 대한 복구작업을 수행할 수 있기 해 줍니다. 이러한 데이터베이스 환경을 다중 리두로그 파일 시스템(Multiplex Redo-Log File System)이라고 합니다. 개념적으로, 다중 컨트롤 파일 시스템(Multiplex Control File System)과 같이 원본 파일에 대한 복사본 파일을 항상 유지해 둠으로써 원본에 문제가 발생하면 복사본 파일로 대체하여 오라클 데이터베이스를 사용 가능하게 해 줍니다.
다음은 다중 리두로그 파일 시스템을 구축하는 방법과 절차입니다. |
|
(1) 먼저, 현재 사용중인 데이터베이스 환경에서 리두로그 파일 상태를 확인하십시오. <xmp style="PADDING-LEFT: 25px"></xmp>[C:\] sqlplus "/as sysdba" SQL> SELECT * FROM V$LOG; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS ---------- ---------- ---------- ---------- ---------- --- --------- 1 1 63 5242880 1 NO INACTIVE 2 1 62 5242880 1 NO INACTIVE 3 1 64 1048576 1 NO CURRENT ← MEMBERS 컬럼의 값 1은 다중 리두로그 파일 시스템이 아닌 것을 의미합니다. 만약, 다중 리두로그 파일 시스템이라면 2 이상의 값을 확인할 수 있습니다.(2) 현재, 데이터베이스 환경은 몇 개의 리두로그 그룹을 가지고 있는지 확인하십시오. 그리고, 새로운 그룹을 추가하십시오. <xmp style="PADDING-LEFT: 25px"></xmp>SQL> ALTER DATABASE ADD LOGFILE GROUP 4 'C:\ORACLE\ORADATA\ORA92\REDO04.LOG' size 500k; (3) 새로운 그룹을 추가하였으면, 다중 리두로그 파일 시스템을 구축해 보십시오. 그리고,리두로그룹 4에 대한 미러링 파일을 추가 생성합니다. <xmp style="PADDING-LEFT: 25px"></xmp>SQL> ALTER DATABASE ADD LOGFILE MEMBER 'C:\ORACLE\ORADATA\ORA92\REDO04B.LOG' TO GROUP 4; (4) 이번에는 리두로그 그룹1, 그룹2, 그룹3에 대한 각각의 미러링 파일을 추가하십시오. <xmp style="PADDING-LEFT: 25px"></xmp>SQL> ALTER DATABASE ADD LOGFILE MEMBER ] 'c:\oracle\oradata\ora92\REDO01B.LOG ' TO GROUP 1; SQL> ALTER DATABASE ADD LOGFILE MEMBER 'c:\oracle\oradata\ora92\REDO02B.LOG' TO GROUP 2; SQL> ALTER DATABASE ADD LOGFILE MEMBER 'c:\oracle\oradata\ora92\REDO03B.LOG' TO GROUP 3; SQL> SELECT * FROM v$logfile; GROUP# STATUS TYPE MEMBER ------ ------- ------- ---------------------------------------- 1 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO01.LOG 1 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO01B.LOG 2 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO02.LOG 2 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO02B.LOG 3 ONLINE C:\ORACLE\ORADATA\ORA92\REDO03.LOG 3 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO03B.LOG 3 ONLINE C:\ORACLE\ORADATA\ORA92\REDO04.LOG 3 STALE ONLINE C:\ORACLE\ORADATA\ORA92\REDO04B.LOG SQL> SELECT * FROM V$LOG; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS ---------- ---------- ----------- --------- -------- --- ---------- 1 1 62 5242880 2 NO INACTIVE 2 1 63 5242880 2 NO INACTIVE 3 1 64 1048576 2 NO CURRENT 4 1 61 1048576 2 NO CURRENT |