[Oracle] Chapter 5. 오라클의 기동과 정지

5.1 기동과 정지를 왜 배워야 하는가?

 

OS와 마찬가지로 기동과 정지를 배우는 것은 오라클의 내부 구조를 이해하는 데 큰 도움이 된다. 기동할 떄 어떤 파일을 어떻게 사용하는지, 의존 관계가 어떻게 되어 있는지를 안다면 내부 동작을 더 쉽게 이해할 수 있다. 더욱이 각종 파일이 손상된 장애에 대응해야 할 떄도 내부 동작에 관한 지식을 알고 있다면 도움이 된다.

또한, 이번 장에서 설명하는 내용 일부는 윈도우(Windows)에서 동작하는 오라클에는 해당하지 않을 수도 있다. 단, 내부 구조는 대부분 같으며, 유닉스 쪽이 프로세스들을 살펴보기에 좀 더 쉬우므로 유닉스상의 오라클을 이해하는 것이 윈도우상의 오라클을 이해하는 지름길이다.

 

5.2 오라클의 기동/정지 개요

 

오라클의 기동은 '창고 회사의 업무 시작'이고, 오라클의 정지는 '창고 회사의 업무가 종료'하는 것에 해당한다. 업무 시작과 종료는 큰 흐름으로 보면 다음과 같다.

- 창고 회사 오라클의 업무 시작 흐름

1. 사원(영업 제외)이 출근함

2. 창고에 관한 정보(관리 대장)를 조사함

3. 창고를 대충 훑어본 뒤, 문제가 없다면 창고를 열어 업무를 시작함

 

- 창고 회사 오라클의 업무 종료 흐름

1. 업무(SQL이나 트랜잭션 등)가 끝나는 것을 기다린다. 단, 급할 떄는 업무 중이더라도 업무 처리를 중지함(종료하는 명령어의 옵션에서 '업무 중이더라도 업무 처리를 중지한다' 지정할 수 있다.)

2. 작업장의 물건(캐시상의 데이터)을 창고(파일)에 정리한다. 단, 급할 때는 작업장의 물건들을 정리하지 않음(종료하는 명령어의 옵션에서 '데이터를 정리하지 않는다' 지정할 수 있다.) 

 

상태명	비유	상태	수행하는 작업
OPEN	업무 중인 상태	데이터 처리를 할 수 있는 상태. SQL을 처리할 수 있는 상태	MOUNT -> OPEN 데이터 파일에 대한 점검 등을 수행함
MOUNT	관리 대장을 읽은 상태	데이터 파일 등에 접근할 수 있는 상태(컨트롤 파일을 읽은 상태)	NOMOUNT -> MOUNT 컨트롤 파일을 읽어옴
NOMOUNT	사원이 출근한 상태	백그라운드 프로세스와 공유 메모리가 존재하는 상태	SHUTDOWN -> NOMOUNT 파라미터를 읽어 와서 백그라운드 프로세스를 기동시키고 공유 메모리를 할당함
SHUTDOWN	퇴근한 상태	정지 상태

5.3 업무의 시작에 해당하는 오라클의 기동

 

사원이 출근하지 않으면 어떤 업무도 시작할 수 없다. 따라서 업무를 시작하기 위해서는 사원이 먼저 출근해서 업무를 시작하기 위한 작업들을 해야 한다. 창고 회사 오라클에서는 관리 대장에 어떤 물건이 창고 어디에 있는지를 기록하고 있다. 이 관리 대장을 토대로 창고를 대충 훑어봤을 떄 문제가 없다면 업무를 시작한다. 그 후에 고객에게 요청이 오기 시작하면 영업 사원이 출근하여 고객의 요청에 대응한다. 창고 회사 오라클의 업무 흐름은 현실의 창고 회사와는 조금 다르게 흘러간다.

그러면 창고 회사의 업무 시작 흐름과 실제 오라클의 기동을 비교해보자. 예를 들었던 이야기에서 '사원의 출근'은 백그라운드 프로세스의 생성과 공유 메모리의 확보에 해당하며, '창고에 관한 정보(관리 대장)를 본다'는 컨트롤 파일을 보는 것을 의미한다. 컨트롤 파일이란, 데이터베이스의 구성 정보가 적혀 있는 파일로서 데이터베이스의 파일 경로 등을 알 수 있다. 그리고 '창고를 열어서 업무를 시작'하는 것이 SQL을 처리할 수 있는 상태로 만드는 작업이다. 데이터 파일이나 REDO 로그 파일을 열어서 오라클이 내부적으로 사용하는 정보와 비교하여 문제가 있는지를 확인한다. 데이터 파일은 이름대로 데이터가 보관된 파일을 의미하며, REDO 로그 파일은 데이터의 변경 이력을 보관하는 파일을 의미한다.

 

5.4 인스턴스, 데이터베이스, 그리고 주요 파일의 구성

 

오라클을 관리하기 위한 단위로 인스턴스(instance)라는 용어를 사용하고 있다. 인스턴스라고 하면 객체지향 언어를 경험해보신 분들은 '엔터티(entity)'를 떠올리시겠지만, 오라클에서의 인스턴스는 백그라운드 프로세스 + 공유 메모리를 의미한다. 'NO MOUNT' 상태는 인스턴스가 기동한 상태이다. 인스턴스는 '데이터베이스를 관리하는 것(프로세스 + 메모리)'이며, 데이터베이스와는 다르다.(데이터베이스는 스토리지 이다.)

 

일반적으로 인스턴스와 데이터베이스는 일대일로 대응하므로 인스턴스를 데이터베이스라고 불러도 그렇게 큰 문제는 없다. 인스턴스가 기동되고 데이터베이스가 오픈된 상태를 '데이터베이스가 기동했다'라고 말한다. 단 RAC(Real Application Clusters 오라클 데이터베이스의 클러스트링 기능)를 사용하는 경우에는 인스턴스와 데이터베이스가 일대일로 대응하지 않기 떄문에 인스턴스와 데이터베이스의 차이를 명확히 이해할 필요가 있다.

 

다음으로 파일의 구체적인 구성을 살표보도록 하자. 특히 의존 관계에 주목하자. 일반적으로 환경 변수 ORACLE_HOME과 ORACLE_SID를 알고 있을 경우, 나머지는 파일에 기록된 정보를 보고 파일을 찾아보면 대부분 어디에 있는지 알 수 있다. 

 

ORACLE_HOME 환경 변수에 지정한 경로 -> 오라클이 설치된 경로

1. -> bin 경로 : 오라클의 프로그램. oralce이라는 이름을 가진 파일. SQL*Plus도 이 경로에 들어있음

2. -> dbs 경로 : 초기화 파라미터 파일 : 인스턴스의 파라미터나 컨트롤 파일의 위치가 기록되어 있음(초기화 파라미터의 파일 이름에는 ORACLE_SID 환경 변수에 지정한 이름이 포함되어 있음)

 

컨트롤 파일 : 데이터 파일이나 REDO 로그 파일의 위치가 기록되어 있음

 

데이터 파일 : 실제 데이터가 들어 있음

 

REDO 로그 파일 : 데이터 변경 로그가 들어 있음

 

그 외의 파일 : 아카이브 로그나 각종 에러 로그 파일 등이 위치하며, 초기화 파라미터에서 지정한 경우가 많음

 

구성에 따라서는 각종 파일이 같은 경로에 들어 있지 않은 떄도 있다. 또한, 초기화 파라미터 파일은 dbs가 아닌 경로에 위치하는 경우도 있다.

 

5.5 기동 처리의 흐름과 내부 동작

 

5.5.1 기동 정지 상태에서 NOMOUNT로 전환

 

먼저, 환경 변수를 설정하고 SQL*Plus라고 하는 도구를 기동하자. 이후 이 도구를 사용해서 오라클에 명령어를 입력한다. 일반적으로는 SQL*Plus에서 데이터베이스를 기동할 수 있는 관리자 계정으로 전환하고 'startup'이라는 기동 명령어를 입력한다. 하지만 이번에는 기동 처리에 관한 내용을 확인하기 위해 'startup nomount'를 입력하자(리스트 5.1) startup nomount를 수행하면 정지 상태에서 'NOMOUNT' 상태로 변경된다.

 

리스트 5.1 기동 명령어 입력

OS 프롬프트> sqlplus /nolog -- 데이터베이스를 기동하기 위해 SQL*Plus를 시작함. '/nolog'는 기동할 때
                            -- 사용하는 옵션이며, 로그인하지 않고도 SQL*Plus를 사용할 수 있음
                       
SQL*Plus: Release 18.0.0.0.0 Production on Sat Sep 1 16:58:12 2022
Version 18.1.0.0.0

Copyright (c) 1982, 2017, Oracle. All rights reserved.

SQL> connect / as sysdba
Connected.

SQL> startup nomount -- 기동 명령어
ORACLE instance started.
-- 인스턴스가 기동되었다는 것과 메모리의 크기 등을 알 수 있음
Total System Global Area 2768239832 bytes
Fixed Size                  8899800 bytes
Variable Size             704643072 bytes
Database Buffers         1979711488 bytes
Redo Buffers               74985472 bytes
SQL>

명령어를 실행하면 ORACLE_HOME과 ORACLE_SID 환경 변수를 토대로 초기화 파라미터 파일을 찾아서 읽어오며, 파일에서 읽어온 파라미터를 토대로 공유 메모리를 확보하고 백그라운드 프로세스를 생성한다.(리스트 5.2)

 

리스트 5.2 NOMOUT 시의 ps 명령어 결과

--                                         nomount에 의해 생성된 백그라운드 프로세스
oracle 1004     1    0  21:41:49 ?            0:00 ora_reco_test
oracle  998     1    0  21:41:49 ?            0:00 ora_lgwr_test
oracle 1000     1    0  21:41:49 ?            0:00 ora_ckpt_test
oracle  996     1    0  21:41:49 ?            0:00 ora_dbw0_test
oracle 1002     1    0  21:41:49 ?            0:00 ora_smon_test
oracle  994     1    0  21:41:49 ?            0:00 ora_mman_test
oracle  992     1    0  21:41:48 ?            0:00 ora_pmon_test
oracle  903   464    0  20:34:08 pts/2        0:00 sqlplus /nolog
oracle 1005   903    0  21:41:50 ?            0:00 oracletest (DESCRIPTION 
=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) -- 기동을 수행한 SQL*Plus에 대응하여 생성된 서버 프로세스
SQL>

5.5.2 NOMOUNT로부터 MOUNT로 전환

 

다음은 'MOUNT' 상태로의 전환이다. 'alter database mount'라고 입력하면 NOMOUNT 상태에서 MOUNT 상태가 된다.(리스트 5.3) 오라클은 초기화 파라미터에 기술된 컨트롤 파일의 경로를 사용해 컨트롤 파일을 열어 내용을 읽어오는 것으로 REDO 로그 파일이나 데이터 파일의 위치를 파악한다.

 

리스트 5.3 NOMOUNT에서 MOUNT로

SQL> alter database mount;

Database altered.

'데이터베이스가 변경되었습니다'고만 표시되었으나, 컨트롤 파일을 읽어 와서 MOUNT 상태로 전환됨

 

5.5.3 MOUNT에서 OPEN으로 전환

 

MOUNT에서 OPEN 상태로 전환하기 위해서는 'alter database open;'을 입력한다. 명령어를 실행하면 데이터 파일을 열어서 간단한 점검을 하고, 백그라운드 프로세스를 기동한다. 데이터베이스의 오픈이 마무리되면 업무를 개시할 수 있는 상태(OPEN 상태)가 된다.(리스트 5.4)

 

리스트 5.4 MOUNT에서 OPEN으로

SQL> alter database open;

Database altered.
-- '데이터베이스가 변경되었습니다'라고만 표시되었으나,
-- 실제로는 데이터 파일을 열어 점검함. 그리고 OPEN 상태로 전환됨

이번에는 데이터베이스의 기동을 좀 더 자세하게 설명하기 위해서 세 가지 명령어를 사용해서 상태를 변경했지만, 앞에서 설명했듯이 일반적으로는 기동 정지 상태에서 startup이라고 입력하는 것만으로도 OPEN 상태가 된다.(리스트 5.5)

 

리스트 5.5 기동 정지에서 OPEN으로(일반적으로 사용하는 명령어)

SQL> startup
ORACLE instance started. -- 인스턴스가 기도했으며, NOMOUNT 상태

Total System Global Area 2768239832 bytes
Fixed Size                  8899800 bytes
Variable Size             704643072 bytes
Database Buffers         1979711488 bytes
Redo Buffers               74985472 bytes
Database mounted.
Database opened. 
SQL>

5.5.4 파일의 사용 순서를 확인해봄

 

앞에서 설명한 세 가지 명령어에서는 초기화 파라미터 파일 -> 컨트롤 파일 -> 데이터 파일순으로 파일을 열었다. 정말로 그 순서로 파일을 사용하고 있는지를 확인해보자.

우선은 '초기화 파라미터의 파일이 올바른 위치에 있지 않을 떄'이다. 그러면 리스트 5.6과 같은 에러가 발생한다.

 

리스트 5.6 초기화 파라미터 파일이 올바른 위치에 있지 않을 때

SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/18.0.
0/dbhome_1/dbs/inittest.ora'
-- 에러가 발생하며 기동하지 않음. 'ORACLE instance started/'가 표시되지
-- 않았다는 것과 NOMOUNT 상태가 되지 않았다는 것에 주목

다음으로 컨트롤 파일을 지워 보면 예상대로 MOUNT할 수 없습니다(리스트 5.7).

 

리스트 5.7 컨트롤 파일이 없을 떄는?

SQL> startup
ORACLE instance started.

Total System Global Area 2768239832 bytes
Fixed Size                  8899800 bytes
Variable Size             704643072 bytes
Database Buffers         1979711488 bytes
Redo Buffers               74985472 bytes
ORA-00205: error in identifying controlfile, check alert log for more info
-- 에러가 발생하며 기동하지 않음. 'ORACLE instance started.'가
-- 표시되어 있으므로 NOMOUNT까지는 성공했지만, 'Database mounted.'가 표시되지 않았음.
-- 즉 MOUNT에 실패함

그리고 데이터 파일을 지우고 기동해보면 OPEN할 때 에러가 발생한다(리스트 5.8). 

 

리스트 5.8 데이터 파일을 삭제했을 떄는?

SQL> startup
ORACLE instance started.

Total System Global Area 2768239832 bytes
Fixed Size                  8899800 bytes
Variable Size             704643072 bytes
Database Buffers         1979711488 bytes
Redo Buffers               74985472 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/u01/app/oracle/oradata/ORCL/users01_1.dbf'
-- 에러가 발생하며 기동하지 않음. 'Database mounted.'가 표시되어 있으므로 MOUNT까지는 성공했지만,
-- Database opened.'가 표시되지 않았음. 즉 OPEN에 실패함

오래된 데이터 파일과 교체하는 장난을 쳐본 후 기동해보았으나, 오라클은 점검할 떄 오래된 데이터 파일이라는 것을 알아채고 데이터의 복구가 필요하다고 지적하면서 데이터베이스를 오픈하지 않는다.(리스트 5.9).

 

리스트 5.9 오래된 데이터 파일로 바꾸어 기동해보면?

SQL> startup
ORACLE instance started.

Total System Global Area 2768239832 bytes
Fixed Size                  8899800 bytes
Variable Size             704643072 bytes
Database Buffers         1979711488 bytes
Redo Buffers               74985472 bytes
Database mounted.
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/u01/app/oracle/oradata/ORCL/users01_1.dbf'
-- 에러가 발생하며 기동하지 않음. 'Database mounted.'가 표시되어 있으므로 MOUNT까찌는 성공했지만,
-- 'Database opened.'가 표시되지 않았음. 즉 OPEN에 실패함. 오라클은 복구가 필요하다고 알려줌

TIP 

여러 버전의 오라클을 설치하기 위해서는?

 

오라클의 프로그램은 ORACLE_HOME이라고 불리는 경로 아래의 bin 안에 들어 있다. 즉, 이 말은 여러 버전의 오라클을 설치하기 위해서는 ORACLE_HOME을 분리할 필요가 있다는 의미이다. 실제로 테스트 등을 위해서 여러 버전의 오라클을 하나의 서버에 설치하는 경우가 많다.

 

5.5 기동 처리에서의 요점

 

오라클의 기동에 관한 요점을 정리해보면 다음과 같다.

- 우선은 초기화 파라미터를 읽어서 백그라운드 프로세스를 생성하고 공유 메모리(버퍼캐시나 공유 풀)를 확보한다. 이것을 NOMOUNT라고 부른다.

- 초기화 파라미터 파일에 입력된 컨트롤 파일의 위치를 확인하고 컨트롤 파일을 열어 데이터베이스를 구성하는 각종 파일의 위치를 확인한다. 이것을 MOUNT라고 부른다. 다만, 위치를 알아내는 것뿐이므로 이 시점에서는 파일이 없어도 에러가 발생하지 않는다.

- 데이터 파일이나 REDO 로그 파일에 문제가 없다면(오라클이 내부적으로 사용하는 데이터들의 앞뒤가 맞지 않는 상황이 아니라면) 데이터 파일을 읽고 기록할 수 있는 상태로 전환한다. 즉, SQL을 실행할 수 있는 상태가 된다. 이것을 OPEN이라고 부른다.

 

오라클 클라이언트에 서비스를 제공하는 서버 프로세스는 데이터베이스 기동 시에는 존재하지 않는다. 클라이언트에서 접속 요청이 있을 때 응답하는 형태로 생성되며, 이 부분은 다음 장에서 자세히 다루자.

 

Tip

PFILE과 SPFILE

 

초기화 파라미터에는 'PFILE'과 'SPFILE'의 두 종료가 존재하며, 인스턴스는 기본적으로 SPFILE을 사용한다.

 

- PFILE(파라미터 파일)

텍스트 형식으로 저장된 파라미터 파일이다. 텍스트 에디터를 통한 파라미터 수동 변경이 가능하지만, 변경을 반영하기 위해서는 인스턴스를 재기동할 필요가 있다. PFILE은 데이터베이스 생성할 때나 장애 발생 시에 사용한다.

- SPFILE(서버 파라미터 파일)

오라클 9i 이후에 추가된 바이너리 형식의 파라미터 파일이다. 텍스트 에디터를 사용한 파라미터 변경은 불가능하며, 파라미터 변경을 하기 위해서는 SQL문(ALTER SYSTEM문)을 사용한다. 파라미터를 변경할 때는 반영할 범위(현재는 인스턴스만인지, 재기동 후인지, 둘 다인지)를 지정할 수 있다. SPFILE은 PFILE을 사용해 수동으로 생성되거나, 데이터베이스를 생성할 때 사용하는 DBCA에 의해 자동으로 생성된다.

 

5.6 업무 종료에 해당하는 오라클의 정지

 

일반적인 회사나 가게라면 마지막 고객이 돌아가면 가게의 정리를 시작한다. 창고 회사 오라클 역시 마찬가지로 접속한 모든 오라클 클라이언트의 접속이 종료된 후에 업무를 종료(기동 정지)합니다. 이 정지 작업은 기동 작업의 역순으로 데이터베이스를 닫은 후에 인스턴스를 종료한다. 인스턴스의 정지라는 것은 공유 메모리를 반환하고 백그라운드 프로세스를 정지하는 것을 말한다. 단, 인스턴스를 정지할 때는 기동 시에 하지 않는 작업이 포함되어 있다. 그것은 버퍼 캐시에 분산된 데이터를 정리하는 것이다. 3장에서 설명했지만, 성능상의 이유로 변경된 데이터를 즉시 데이터 파일에 저장하지 않는다.

기록하지 않은 변경된 데이터를 데이터베이스를 닫는 작업의 일환으로 데이터 파일에 기록하는 것이 바로 이 작업이다.

 

리스트 5.10 일반적인 데이터베이스의 정지

SQL> shutdown
Database closed.            -- 메세지가 뜨는 차례를 보면 기동할 때와 반대의 순서로
Database dismounted.        -- 진행한 것을 알 수 있음. 인스턴스의 shutdown에서
ORACLE instance shut down   -- 백그라운드 프로세스의 정지와 공유 메모리 반환을 수행함

하지만 항상 위와 같은 방법으로 종료할 수 있는 것은 아니다. SQL문이 끝나지 않았을 때, 오라클 클라이언트가 접속을 끊어주지 않았을 때, 긴급 사태가 발생해서 접속을 즉시 종료시켜야 할 떄, 그리고 명령어가 작동하지 않을 때 등 여러 경우가 있다. 그래서 shutdown에는 여러 옵션이 준비되어 있다.

 

표 5.1 shutdown의 옵션과 그 동작

옵션	커넥션의 종료를 기다리는가?	변경된 데이터를 데이터 파일에 기록하는가?
없음(기본)#	커넥션의 종료를 기다린다.	YES
transactional	트랜잭션이 끝나는 것을 기다린다. 트랜잭션이 끝나면 커넥션을 끊어 버린다.	YES
immediate	NO. 커밋하지 않은 데이터는 없어진다.	YES
abort	NO. 커밋하지 않은 데이터는 없어진다.	NO

# 데이터베이스의 커넥션들을 유지하기 위해 커넥션 풀(connection pool)을 사용하는 경우에는 애플리케이션이 종료할 떄까지 커넥션을 종료하지 않는다. 따라서 커넥션 풀로 사용 중인 오라클을 정지하기 위해 옵션을 필수적으로 지정해야 할 때가 있다.

 

표에서 알 수 있듯이, abort는 변경된 데이터를 기록하지 않고 종료한다. 하지만 오라클은 RDBMS이므로 데이터를 잃어버려서는 안된다. 따라서 다음 기동 시에 데이터를 복구한다. 이 작업은 인스턴스 복구(instance recovery)라고 부른다. 데이터 파일에 기록되지 않은 데이터는 REDO 로그 파일의 데이터를 사용해서 복구한다. 이 REDO 로그 파일은 변경된 내용이 기록되어 있어서 오래된 데이터 파일의 내용을 최신의 것으로 변경할 수 있다. 인스턴스 복구는 사용자가 신경 쓸 필요는 없으며, 오라클이 기동할 때 알아서 수행한다.

마찬가지로, OS의 장애나 서버 장비의 장애 등 오라클이 비정상적으로 종료했을 때도 인스턴스 복구가 수행된다. 단 캐시의 변경된 데이터만 손실된 것이 아닌, 데이터 파일이 존재하지 않는 등의 파일에 관한 장애가 발생했을 때는 본격적인 복구 작업을 해야만 한다.

 

칼럼 

데이터베이스의 생성과 파괴를 실제로 해보자

 

데이터베이스의 생성이나 파괴를 해보면 내부 구조가 이해하기 쉬워지며, 평소에 작업을 진행할 때도 자신을 가질 수 있으므로 손상되어도 상관없는 환경에서 꼭 연습해봤으면 한다.

 

5.7 데이터베이스를 수동으로 생성하기

 

최근엔 'DBCA(DataBase Configuration Assistant)'라고 불리는 도구로 데이터베이스를 간단히 생성할 수 있지만, 수동으로 생성함으로써 여러 가지를 배울 수도 있다. 데이터베이스의 생성을 창고 회사에 비유해보자면, '사원을 모집하고 창고를 만드는 것'이다.

생성이 완료된 데이터베이스의 파일 구성을 머리속에 떠올려보자. 파일을 어떤 순으로 어디에 생성하면 좋을까? 기본적으로 데이터베이스를 생성할 때의 파일 생성 순서와 기동할 떄 접근하는 파일의 순서는 같다. 그래서 우선은 초기화 파라미터 파일을 만든다. 기존의 파일을 복사해도 상관없지만 데이터베이스명, 인스턴스명, 컨트롤 파일의 경로는 바꾸도록 하자(리스트 5.11).

 

리스트 5.11 초기화 파라미터 파일의 예

db_name=ORCL

control_files = (/u01/app/oracle/oradata/ORCL/ontrol01.ctl, /u02/app/
oracle/fast_recovery_area/ORCL/control02.ctl) -- 컨트롤 파일의 위치 정보 및 해당 데이터베이스가
db_file = 80                                  -- 최대로 열 수 있는 파일의 개수에 관한 정보

-- 주로 공유 메모리(각종 캐시)에 관한 정보
db_block_size = 8192
db_cache_size = 1800M 
shared_pool_size = 600M
log_buffer = 67108864

undo_management = AUTO
undo_tablespace = TS_undo

compatible='18.0.0'
processes = 200

-- REDO 로그를 아카이빙해둘 위치나 각종 에러 로그의 장소를 지정
log_archive_dest_1 = 'LOCATION=/u01/app/oracle/oradata/ORCL/arch'
diagnostic_dest = /u01/app/oracle

다음으로 ORACLE_SID 환경 변수를 변경해서 SQL*Plus를 실행하고, 기동/정지와 데이터베이스를 생성할 수 있는 관리자 계정으로 접속한다. 이 시점에서는 초기화 파라미터 파일밖에 없으므로 startup nomount를 실행하여 인스턴스만 생성한다. 기동 절차를 생각해보면 이제부터 컨트롤 파일, 데이터 파일, REDO 로그 파일이 필요하므로 CREATE DATABASE문을 수행해서 해당 파일들을 생성해보자(리스트 5.12).

 

리스트 5.12 데이터베이스 생성 예

SQL> create database ORCL
user sys identified by king825      -- 데이터베이스 관리 계정을 생성.
user system identified by queen549  -- 이 계정을 사용해서 데이터베이스를 관리함
logfile
-- group 1~3는 REDO 로그 파일의 정보. 이 정보를 토대로 REDO로그 파일을 생성함. 단, 컨트롤 파일에도 이 정보가 보관됨
group 1 ('/u01/app/oracle/oradata/ORCL/redo01.log','/u01/app/oracle/
oradata/ORCL/redo11.log') size 1G,
group 2 ('/u01/app/oracle/oradata/ORCL/redo02.log','/u01/app/oracle/
oradata/ORCL/redo12.log') size 1G,
group 3 ('/u01/app/oracle/oradata/ORCL/redo03.log','/u01/app/oracle/
oradata/ORCL/redo13.log') size 1G
maxlogfiles 6
maxlogmembers 2
maxdatafiles 80
character set K016MSWIN949
archivelog
-- 데이터베이스를 구성하는 데이터 파일의 정보. 이 정보를 토대로 데이터 파일을 생성함. 단, 컨트롤 파일에도 이 정보가 보관됨
datafile '/u01/app/oracle/oradata/ORCL/system.dbf' size 4G
sysaux datafile '/u01/app/oracle/oradata/ORCL/sysaux.dbf' size 4G
default temporary tablespace TS_temp tempfile '/u01/app/oracle/oradata/
ORCL/TS_temp01.dbf' size 8G
undo tablespace TS_undo datafile '/u01/app/oracle/oradata/ORCL/TS_undo
01.dbf' size 8G;

Database created.

오라클은 CREATE DATABASE문이 끝나면 OPEN 상태로 자동 전환된다. 나머지는 카탈로그를 생성(관리용 뷰 등을 생성)하고 업무용으로 사용하는 데이터 파일을 생성한다. 이 부분은 생략하지만 관심이 있는 사람들은 매뉴얼을 확인하자.

 

5.8 요약

 

Q1. 컨트롤 파일이 손상되었을 때 컨트롤 파일을 생성하기 위해 명령어를 사용할 수 있다. 어떤 상태(SHUTDOWN, NOMOUNT, MOUNT)에서 이 명령어를 사용할 수 있을까?

 

A1. 컨트롤 파일이 손상되었을 떄는 MOUNT할 수 없다. 즉, NOMOUNT 상태에서 컨트롤 파일을 생성하는 명령어를 실행해야 한다.

 

Q2. 데이터베이스의 파일이 손상되었을 때는 복구 작업을 수행해야 한다. 중요한 데이터 파일이 손상되어 데이터베이스를 OPEN할 수 없을 때, 복구를 하기 위한 명령어는 어떤 상태(SHUTDOWN, NOMOUNT, MOUNT)에서 수행해야 할까?

 

A2. 데이터 파일의 위치를 알고 있지 않으면 복구할 수 없다. 따라서 MOUNT 상태에서 복구 명령어를 실행해야 한다.

 

- 사원이 출근해서 창고를 점검하고 업무를 개시(오픈)하는 이미지. 또한, 영업 담당이 고객에게 연락을 받은 다음(연결되고 난 후)에야 출근하는 모습

- 파일의 종류와 의미, 그리고 기동할 때 읽어오는 순서

 

칼럼 

컨트롤 파일의 중요성

 

이번 장의 설명으로 컨트롤 파일의 중요성을 이해했을 것이다. 데이터베이스는 실제 데이터가 들어가는 데이터 파일이 손상되지 않고, 컨트롤 파일이 손상된 것만으로도 사용할 수 없게 된다. 컨트롤 파일에는 데이터 파일 등의 구성 정보가 들어 있으므로 데이터 파일의 추가/삭제, REDO 로그 파일에 관한 설정 등을 변경했을 때는 컨트롤 파일을 잘 백업해두자. 물론, 평소에 수행하는 백업 절차에서도 잊지 말고 컨트롤 파일을 백업할 수 있도록 처리해두어야 한다.