database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
ㆍOracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Oracle Tutorials 8758 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 8758
OCP 강좌 - Architecture and Administration (1)
작성자
정재익(advance)
작성일
2001-12-07 22:58
조회수
10,497

공략 포인터

 

OCP 시험에서 수험자들이 느끼는 난이도는 상당한 편차가 있는 듯 하다. 평이한 SQL 과목을 어려워하는 사람이 있는가 하면 오히려 튜닝 과목을 가볍게 통과하는 이들도 있다. 본 과목의 문제 수준은 중간 레벨에 해당되지만 개인적인 성향과 그 동안 공부하고 경험한 배경에 따라서 체감하는 수준이 다를 것이다. 다루는 내용이 광범위하므로 오라클에 대한 경험이 많지 않다면 충분한 시간적 여유를 갖고 준비할 필요가 있다.

 

데이터베이스의 관리 정보는 대부분 데이터 딕셔너리에 들어있기 때문에 딕셔너리만 마스터하면 이미 절반은 합격한 것이나 다름없다. 딕셔너리에 대한 직접적인 문제도 많이 출제되지만 딕셔너리 각각에 대한 이해를 통해서 자연스럽게 데이터베이스 전반을 파악할 수 있으므로 오라클 DBA가 되기 위한 필수 코스이기도 하다.

 

백업과 복구는 보험에 가까운 성격을 띄고 있어서 그 효과가 겉으로 드러나는 기회가 많지 않지만 이 과목에서 평가하는 내용은 DBA라면 매일같이 만나게 되는 업무에 속한다. GUI 도구가 활성화되면서 복잡한 명령과 옵션을 달달 외워야 하는 번거로움은 많이 감소했지만 백그라운드에 대한 이해가 없다면 DBA로서는 자격 미달일 뿐 아니라 시험을 준비하기도 심히 고달플 것이다.

 

외국에서는 DBA가 데이터베이스 관리에만 전념하는 경우가 많지만 우리나라는 안타깝게도 규모가 큰 회사를 제외하면 DBA가 한가롭게(?) 데이터베이스에만 신경 쓸 수 있는 여건이 마련되어 있지 않다. 기업에서는 인원이 부족하기 때문이라고 항변하겠지만 그보다는 DBA 업무의 중요성을 간과한 경영진의 실수라고 하는 편이 옳을 것이다. 역량 있는(Qualified) DBA를 확보하지 않은 상태에서 프리랜서나 외부 지원에 의존하다가 나중에 큰 대가를 치르는 경우를 많이 보았다. DBA에 대한 자부심을 가지고 열심히 공부하기 바란다.

 

오라클 서버의 구조와 구성요소

 

1-1. 임시 세그먼트(temporary segment)는 데이터 정렬을 위해서 사용되는 공간이다. 정렬 작업이 끝난 다음에 임시 세그먼트를 정리하는 프로세스는?

 

a. SMON

b. PMON

c. LOCK

d. RECO

e. 서버 프로세스

 

 

<해설>

 

오라클은 크게 소프트웨어, 인스턴스, 데이터베이스로 이루어져 있다.

 

소프트웨어는 CD에서 인스톨한 프로그램을 말하며 데이터베이스는 각종 테이블과 인덱스 등이 들어 있는 데이터 파일과 리두 로그 파일, 컨트롤 파일 등으로 구성된 파일 집합을 가리킨다. 그리고 인스턴스는 데이터베이스를 관리하는 백그라운드 프로세스와 데이터 및 제어 정보가 들어 있는 SGA(System Global Area)라는 메모리 영역에 대한 총칭이다. 간단히 말해서 인스턴스는 메모리에 존재하고 데이터베이스는 디스크에 존재한다고 생각하면 된다.

 

오라클 인스턴스 = 백그라운드 프로세스 + SGA

SGA = 데이터베이스 버퍼 + 리두 로그 버퍼 + Shared Pool + Large Pool + Java Pool

 

 

백그라운드 프로세스에는 DBW0(Database Writer), LGWR(Log Writer) 등을 비롯하여 여러 가지 종류가 있는데 대부분 이름과 기능을 연관 지어 기억하면 되지만 SMON과 PMON은 혼동할 소지가 많기 때문에 단골로 출제되곤 한다.

 

SMON은 System Monitor의 약자로 다음과 같은 기능을 담당한다.

 

1) 인스턴스 기동 시 인스턴스 복구를 수행한다.

2) 사용되지 않는 임시(temporary) 세그먼트를 정리한다

3) 사용되지 않는 익스텐트를 병합하여 큰 익스텐트로 만든다.

 

오라클 인스턴스가 정상적으로 종료(shutdown)되었다면 다음에 기동 될 때 인스턴스 복구 과정은 필요 없지만 Abort 옵션이나 정전 등에 의해서 종료되었을 때에는 SMON이 자동으로 인스턴스 복구를 수행한다.

 

모든 소프트웨어가 그렇듯이 오라클에도 크고 작은 버그가 많이 있는데, 한 때 SMON이 임시 세그먼트를 삭제하지 못하는 버그가 유행한 적이 있었다. SMON이 특정한 경우에 있어서 임시 세그먼트를 제거하지 않는 바람에 쓸모없는 임시 세그먼트가 계속 늘어나서 결국 테이블 스페이스를 가득 채워버리곤 했다.

 

PMON은 Process Monitor의 약자로 다음과 같은 기능을 담당한다.

 

1) 유저 프로그램의 다운 시 사용 중이던 데이터베이스 버퍼 캐시를 정리한다.

2) 유저 프로그램의 다운 시 사용 중이던 리소스를 해제 시킨다. 여기에는 락도 포함된다.

3) 디스패처(dispatcher)와 서버 프로세스의 상태를 감시해서 원인 모르게 죽은 프로세스를 다시 기동 시킨다.

 

정답 : (a) (<- 마우스로 정답 부분을 선택하세요)

 

 

1-2. LGWR가 리두 로그 버퍼를 리두 로그 파일에 기록하는 경우로 옳지 않은 것은?

 

a. 리두 로그 버퍼가 절반 이상 찼을 때

b. DBW0가 변경된 버퍼를 디스크에 기록할 때

c. 트랜잭션을 커밋(commit) 할 때

d. 매 3초마다

 

 

<해설>

 

LGWR(Log Writer)는 리두 로그 버퍼를 리두 로그 파일에 기록하는 백그라운드 프로세스이다. 리두 로그 파일은 데이터베이스의 변경 내역이 기록되는 곳으로 데이터베이스의 복구와 일관성 유지를 가능하게 하는 핵심적인 요소이다.

 

‘리두(redo)’의 사전적 의미가 ‘다시 하다’ 이듯이 리두 로그 파일에 들어 있는 정보를 이용하면 과거의 트랜잭션에 의해서 처리된 작업을 다시 재생할 수 있다. 오라클에서 데이터베이스의 복구는 과거의 어느 시점으로부터 앞으로 전진해 가면서 진행되는데(roll forward) 이 때 리두 로그 파일의 정보를 이용해서 이전의 작업 내용을 그대로 재현하게 된다.

 

예전에 일본 오라클에서 발행된 DBA 핸드북을 번역 회사에 맡겼더니 리두 로그 파일을 ‘다시 하는 로그 파일’ 이라고 번역해온 사건이 있었다. 리두 로그 파일은 별도로 번역을 하지 않고 원어 그대로 사용하는 것이 일반적이다.

 

로그 엔트리들은 리두 로그 파일에 기록되기 전에 리두 로그 버퍼에 저장된 다음 보기와 같은 몇 가지 시점에 리두 로그 파일로 기록된다. 단, 리두 로그 버퍼가 절반이 아니라 1/3 이상 찼을 때 리두 로그 파일로 기록된다.

 

정답 : (a) (<- 마우스로 정답 부분을 선택하세요)

 

1-3. 데이터베이스 버퍼 캐시의 각 버퍼는 상태에 따라서 불리는 이름이 다르다. Pinned Buffer란 어떤 상태의 버퍼를 의미하는가?

 

a. 비어있는 버퍼

b. 현재 사용중인 버퍼

c. 변경되었지만 데이터베이스 파일에는 아직 기록되지 않은 버퍼

d. 손상된 버퍼

 

 

<해설>

 

데이터베이스 버퍼 캐시는 SGA의 구성요소 가운데 하나로 자주 사용되는 데이터를 디스크가 아닌 메모리에서 가져오도록 하여 처리 속도를 높이기 위한 공간이다. 데이터베이스 버퍼 캐시는 오라클 블록과 같은 크기를 가지는 여러 개의 버퍼로 이루어져 있는데 특히 Dirty Buffer와 Pinned Buffer란 용어를 기억해두는 것이 좋다.

 

Pinned Buffer는 현재 사용 중인 버퍼를 말하고 Dirty Buffer는 내용은 변경되었지만 아직 디스크에 기록되지 않은 상태의 버퍼를 말한다. 이와 같은 버퍼들은 Write 리스트와 LRU 리스트를 통해서 관리된다. Write 리스트에는 디스크로 기록되기를 기다리는 Dirty Buffer가 들어 있고 LRU 리스트에는 Free Buffer, Pinned Buffer, 그리고 아직 Write 리스트로 넘어가지 않은 Dirty Buffer가 들어 있다.

 

정답 : (b) (<- 마우스로 정답 부분을 선택하세요)

 

 

1-4. Pro*C로 만든 프로그램에서 SQL문을 실행했을 때 필요로 하는 데이터가 SGA에 없는 경우 해당 데이터를 찾아서 SGA에 올리는 프로세스는?

 

a. CKPT

b. DBW0

c. LGWR

d. PMON

e. 서버 프로세스

f. 유저 프로세스

 

 

<해설>

 

먼저 서버 프로세스와 백그라운드 프로세스를 서로 구분해 보도록 하자.

 

서버 프로세스는 Pro*C, 델파이, 파워빌더 등으로 만든 유저 프로그램으로부터 작업 요청을 받아서 처리해 주는 프로세스로 구성하는 방법에 따라서 Dedicated Server와 Shared Server로 분류된다(자세한 것은 Network 과목에서 다루기로 함).

 

백그라운드 프로세스는 오라클 인스턴스가 기동될 때 함께 뜨는 프로세스이다. Shared Server는 인스턴스와 같이 기동되므로 백그라운드 프로세스에 포함되지만 Dedicated Server는 사용자가 접속할 때 뜨기 때문에 백그라운드 프로세스에 해당되지 않는다. 사용자가 접속하지 않더라도 미리 Dedicated Server를 띄워 놓을 수도 있지만 그것은 리스너(listener)에서 제공하는 기능이다.

 

서버 프로세스는 유저 프로세스로부터 SQL 명령을 받아서 파싱한 다음에 실행하는 역할을 담당하다. 또한 필요로 하는 데이터가 SGA에 없을 때에는 데이터 파일에서 SGA로 데이터를 읽어오기도 한다. 이와 같이 실제로 SQL 작업을 처리하는 것은 서버 프로세스인 것이다.

 

유저 프로세스와 서버 프로세스는 별개의 프로세스이기 때문에 서로를 연결하는 통로가 필요한데 로컬 환경에서는 IPC, 네트워크 환경에서는 TCP/IP 프로토콜을 사용하는 것이 통례이다. IPC의 속도가 가장 빠르긴 하지만 두 프로세스 간의 커뮤니케이션에서 발생하는 오버헤드를 조금이라도 줄이기 위해서 유저 프로세스와 서버 프로세스를 하나로 통합한 프로그램도 만들 수 있다. DBA의 고충을 들어보면 임포트 작업의 속도에 대한 불만이 상당히 큰데, 밤새도록 임포트로 데이터를 넣는 경우가 비일비재하기 때문에 조금이라도 성능을 향상시키고자 서버 프로세스와 임포트 유틸리티가 결합된 싱글 태스크 버전을 암암리에 사용하는 경우가 있었다. 그러나 실제 효과는 별로 크지 않았기 때문에 요즘에는 이런 방법을 사용하는 경우를 찾아보기 어렵다.

 

정답 : (e) (<- 마우스로 정답 부분을 선택하세요)

 

오라클 인스턴스 다루기

 

2-1. 데이터베이스는 몇 가지 단계를 거쳐서 기동된다. Alert 로그 파일이 오픈되는 시점은?

 

a. NOMOUNT

b. MOUNT

c. OPEN

d. 항상 오픈되어 있음

 

 

<해설>

 

백그라운드 프로세스와 SGA를 합쳐서 오라클 인스턴스라고 부르며 서버 매니저나 SQL*Plus, OEM 등을 이용해서 띄울 수 있다. 그런데 오라클 인스턴스만 띄운다고 데이터베이스를 사용할 수 있는 것이 아니고 데이터베이스와 인스턴스를 연결한(mount) 다음에 최종적으로 데이터 파일과 온라인 리두 로그 파일까지 모두 오픈되어야 한다. 일반적으로 데이터베이스가 기동되는 단계는 다음과 같다.

 

1) NOMOUNT

 

오라클 인스턴스만 기동된 상태로 백그라운드 프로세스와 SGA는 형성되었지만 아직 데이터베이스와의 연결은 이루어지지 않은 상태이다. 이 상태에서는 새로운 컨트롤 파일이나 데이터베이스를 생성하는 작업이 가능하다.

 

2) MOUNT

 

데이터베이스의 물리적인 정보가 들어있는 컨트롤 파일까지 오픈된 상태이다. 인스턴스와 데이터베이스가 연결되었지만 아직까지 데이터베이스를 이용할 수 없다.

 

3) OPEN

 

필요한 복구 과정(crash recovery)을 거쳐서 데이터 파일과 리두 로그 파일이 오픈되어 비로소 데이터베이스를 이용할 수 있는 상태이다.

 

Alert 로그 파일에는 오라클의 시작과 종료 및 파라미터 정보, 치명적인 에러 등이 계속해서 쌓이게 된다. 인스턴스의 기동 내역도 기록되기 때문에 NOMOUNT 상태에서부터 오픈되어 사용된다.

 

정답 : (a) (<- 마우스로 정답 부분을 선택하세요)

 

 

2-2. 현재 여러 명의 사용자가 데이터베이스를 사용하고 있다. 이들이 작업중인 내용이 유실되지 않도록 하면서 가장 빨리 데이터베이스를 셧다운(shutdown) 시키려면 어떤 옵션을 사용해야 하는가?

 

a. NORMAL

b. IMMEDIATE

c. TRANSACTIONAL

d. ABORT

 

 

<해설>

 

데이터베이스를 셧다운 하는 옵션은 네 가지가 있다.

 

1) NORMAL

 

디폴트 옵션으로 모든 사용자가 작업을 끝내고 접속을 종료할 때 까지 기다린 후에 데이터베이스를 셧다운 한다. 사용자가 접속을 끊지 않거나, 또는 비정상적인 세션이 남아 있는 경우에는 무한정 기다리기 때문에 비실용적인 방법이다.

 

2) IMMEDIATE

 

작업중인 사용자의 트랜잭션을 강제적으로 롤백시키고 접속을 끊은 다음 데이터베이스를 셧다운 한다. SGA에 남아 있던 내용들까지 모두 정상적으로 디스크에 저장되기 때문에 가장 효과적이고 안정적인 셧다운 방법에 속한다. 단, 셧다운 시점에 커밋되지 않은 작업은 롤백되므로 사전 예고 없이 셧다운 하면 사용자의 불만을 야기할 수 있다.

 

3) TRANSACTIONAL

 

현재 수행중인 모든 트랜잭션이 끝나는 것을 기다린 다음에 접속된 사용자들을 끊고 데이터베이스를 셧다운 한다. 이미 접속중인 사용자도 새로운 트랜잭션을 시작할 수는 없고 단지 현재 작업중인 트랜잭션까지만 허용하므로 IMMEDIATE와 함께 유용하게 사용할 수 있다.

 

4) ABORT

 

무조건적으로 데이터베이스를 셧다운한다. 트랜잭션에 대한 처리나 버퍼의 내용을 기록하는 등의 아무런 정리 작업을 수행하지 않기 때문에 나중에 기동 시에 SMON에 의한 복구 작업이 자동으로 수행된다. 이 옵션은 오라클 프로세스들을 강제적으로 KILL 시키는 것이나 다름없기 때문에 최후의 수단으로 선택하는 것이 좋다. 또한 셧다운 후에도 인스턴스의 일부분이 남아 있어서 새로운 인스턴스가 뜨지 않는 경우에 사용하면 깨끗하게 정리할 수 있다.

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

 

2-3. 한 사용자가 UPDATE 명령을 실행했더니 작업이 진행되지 않고 대기 상태에 머물러 있었다. DBA에게 도움을 요청한 결과 SID = 5, SERIAL# = 10 인 세션이 문제의 테이블에 락을 걸고 있음이 발견되었다. DBA가 이 세션을 제거해서 락을 해제 시키려면 어떤 명령을 사용해야 하는가?

 

a. ALTER DATABASE KILL SESSION ‘5,10’;

b. KILL SESSION 5,10;

c. ALTER SYSTEM KILL SESSION ‘5,10’;

d. ALTER SESSION KILL ‘5,10’;

e. ALTER SYSTEM RELEASE LOCK ‘5,10’;

 

 

<해설>

 

하나의 세션은 고유한 SESSION ID와 SERIAL# 을 가지고 있다. 따라서 세션을 제거할 때에는 이 두 가지 정보를 이용해서 작업해야 한다. 명령은 다음과 같다(따옴표 주의).

 

ALTER SYSTEM KILL SESSION 'SID, SERIAL#';

 

 

KILL SESSION 대신 DISCONNECT SESSION을 사용할 수도 있다.

 

ALTER SYSTEM DISCONNECT SESSION 'SID, SERIAL#' POST_TRANSACTION;

 

 

DISCONNECT SESSION 과 POST_TRANSACTION 옵션을 사용하면 해당 세션이 트랜잭션을 종료할 때 까지 기다린 다음에 세션을 끊게 되는데 일반적으로 세션을 끊을 때에는 시급한 상황이 많기 때문에 별로 사용되지 않는다.

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

2-4. 데이터베이스가 생성되지 않은 상태에서도 사용할 수 있는 다이나믹 퍼포먼스 뷰를 모두 골라라.(네 가지)

 

a. V$VERSION

b. V$DATABASE

c. V$SESSION

d. V$OPTION

e. V$PARAMETER

f. V$LOG

 

 

<해설>

 

다이나믹 퍼포먼스 뷰는 SGA, 컨트롤 파일 등의 여러 소스로부터 필요한 정보를 가져온다. 정보의 원천이 사용 가능한 상태인지, 정보의 내용이 의미가 있는지 등에 따라서 사용할 수 있는 것이 있고 그렇지 않은 것이 있다.

 

이에 대응되는 것으로는 DBA_TABLES, ALL_VIEWS, USER_INDEXES 등과 같은 정적 데이터 딕셔너리 뷰가 있다. 정적 데이터 딕셔너리 뷰는 딕셔너리가 변경되어야지만 변화된 결과를 보여주지만 다이나믹 퍼포먼스 뷰는 데이터베이스가 사용되는 동안 계속해서 결과가 갱신된다는 차이점이 있다.

 

데이터베이스가 만들어지지 않았다면 NOMOUNT 상태를 의미하는데 이 상태에서는 인스턴스가 기동되어 있으므로 SGA에서 정보를 가져오는 다이나믹 퍼포먼스 뷰는 사용할 수 있다. 몇 가지 예를 들면 다음과 같다.

 

V$SESSION - 세션에 관한 정보

V$OPTION - 오라클 서버와 함께 설치된 각종 옵션의 유무

V$PARAMETER – 인스턴스의 초기화 파라미터 정보

V$SGA – SGA의 부분별 크기

 

이외에도 V$VERSION, V$PROCESS, V$INSTANCE 등을 NOMOUNT 상태에서 참조할 수 있다.

 

컨트롤 파일로부터 정보를 가져오는 뷰는 NOMOUNT 상태에서는 사용할 수 없으며 데이터베이스가 MOUNT 되어 컨트롤 파일이 오픈된 시점에서 이용할 수 있다.

 

정답 : (a) (c) (d) (e) (<- 마우스로 정답 부분을 선택하세요)

 

 

2-5. DBA가 디스크를 정리하다가 실수로 Alert 로그 파일을 삭제하였다. 현재 데이터베이스는 오픈된 상태인데 앞으로 어떻게 될 것으로 생각되는가?

 

a. 데이터베이스는 계속 작동하지만 Alert 로그 파일에 기록을 하는 시점에 데이터베이스가 셧다운된다.

b. 새로운 Alert 로그 파일이 자동으로 생성되고 데이터베이스 작동에는 지장을 주지 않는다.

c. 데이터베이스는 계속 작동하지만 새로운 Alert 로그 파일이 생성되려면 일단 셧다운 후에 다시 기동시켜야 한다.

d. 데이터베이스가 자동으로 셧다운되며 백업 받은 Alert 로그 파일이 없다면 데이터베이스를 다시 만들어야 한다.

 

 

<해설>

 

Alert 로그 파일과 트레이스 파일은 오라클을 위한 것이 아니라 DBA에게 시스템의 정보와 문제점을 알려주기 위한 텍스트 파일이다. 따라서 필요 없다고 생각되거나 디스크가 부족할 때에는 지울 수 있도록 허용하고 있다.

 

Alert 로그 파일에는 계속해서 내용이 누적되지만 삭제할 경우 오라클이 필요한 시점에 자동으로 다시 생성하므로 데이터베이스 운용에는 아무런 영향을 주지 않는다. 단, 기존 파일에 남아있던 내용은 복구할 수 없으므로 삭제하기 전에 압축해서 백업해 두는 것이 바람직하다.

 

정답 : (b) (<- 마우스로 정답 부분을 선택하세요)

 

데이터베이스 만들기

 

3-1. 파라미터의 파일의 DB_NAME과 CREATE DATABASE 명령에서 지정한 데이터베이스 이름이 서로 다르다면 CREATE DATABASE 명령의 결과는 어떻게 되는가?

 

a. 파라미터 파일의 DB_NAME을 사용해서 데이터베이스를 생성한다.

b. CREATE DATABASE 명령에서 지정한 데이터베이스 이름이 사용된다.

c. 두 값이 서로 다르므로 에러가 발생한다.

d. CREATE DATABASE 명령에서 지정한 데이터베이스 이름으로 생성되지만 다음에 기동할 때에는 DB_NAME과 서로 다르므로 에러가 발생한다.

e. DB_NAME을 사용해서 데이터베이스가 생성되지만 다음에 기동할 때에 에러가 발생한다.

 

 

<해설>

 

CREATE DATABASE에서 지정하는 데이터베이스 이름과 파라미터 파일의 DB_NAME은 서로 일치해야 하며 그렇지 않으면 데이터베이스를 만들 때 에러가 발생한다. 데이터베이스가 생성되면 데이터베이스 이름은 컨트롤 파일에 저장되는데 데이터베이스를 기동할 때 컨트롤 파일에 저장된 데이터베이스 이름과 DB_NAME을 비교하여 서로 다르면 역시 에러가 발생한다.

 

컨트롤 파일은 파라미터 파일과는 달리 바이너리 파일이기 때문에 저장된 내용을 변경하기 위해서는 컨트롤 파일을 다시 생성해야 하는 번거로움이 있다. 데이터베이스 이름 외에도 ‘사용 가능한 데이터 파일의 최대 개수’와 같은 정보도 파라미터 파일과 컨트롤 파일 양쪽에서 지정할 수 있는데 이 때에는 둘 중에서 작은 값이 우선하게 된다.

 

init.ora로 통칭되는 파라미터 파일은 예전에는 ‘이닛 쩜 오라’라고 읽는 경우가 많았지만 시간이 지날수록 ‘이닛 닷 오라’가 우세해 지고 있다. 마치 인터넷 기업을 ‘쩜컴’ 기업이 아니라 ‘닷컴’ 기업이라고 부르는 것과 같다. 때로는 ‘이닛 닷 쩜 오라’ 라고 하는 분도 있는데 이것만큼은 삼가도록 하자.

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

 

3-2. CREATE DATABASE 명령으로 데이터베이스를 생성한 직후에 만들어져 있지 않은 것은? (정답은 두 가지)

 

a. 시스템 테이블스페이스

b. 롤백 테이블스페이스

c. 온라인 리두로그 파일

d. 컨트롤 파일

e. SCOTT 유저

f. 시스템 롤백 세그먼트

 

 

<해설>

 

CREATE DATABASE 명령으로 만들어진 데이터베이스는 겨우 뼈대만 있는 상태이다. 가장 기초적인 데이터베이스의 형상만을 갖추고 있기 때문에 실제로 운영을 하기는 거의 불가능하다.

 

CREATE DATABASE 명령이 끝난 직후에는 다음과 같은 것들이 만들어져 있다.

 

시스템 테이블스페이스

온라인 리두로그 파일

컨트롤 파일

시스템 롤백 세그먼트

SYS 및 SYSTEM 유저

데이터 딕셔너리 테이블

 

 

SCOTT 유저와 데모 테이블, 데이터 딕셔너리 뷰, 각종 테이블스페이스와 패키지, 롤백 세그먼트 등은 계속해서 만들어 주어야 한다.

 

정답 : (b) (e) (<- 마우스로 정답 부분을 선택하세요)

 

3-3. 데이터 딕셔너리 테이블과 딕셔너리 뷰를 만드는 스크립트가 순서대로 옳게 나열된 것은?

 

a. catalog.sql – catproc.sql

b. catproc.sql – catalog.sql

c. sql.bsq – catalog.sql

d. catalog.sql – sql.bsq

e. bsq.sql – catalog.sql

f. catalog.sql – bsq.sql

 

 

<해설>

 

데이터베이스를 제대로 사용하려면 여러 가지 스크립트를 통해서 데이터 딕셔너리와 각종 패키지 등을 생성해야 한다.

 

가장 핵심적인 스크립트는 sql.bsq이다. 확장자가 sql이 아니라 bsq인 점이 특징적인데 이 스크립트는 데이터베이스가 생성될 때 자동으로 수행되기 때문에 사용자가 별도로 실행할 필요는 없는 관계로 많이 알려져 있지는 않다. 그러나 데이터 딕셔너리 테이블을 만드는 중요한 역할을 담당한다.

 

데이터베이스가 만들어진 다음에는 일반적으로 catalog.sql과 catproc.sql을 실행하는데 catalog.sql은 sql.bsq에서 만든 딕셔너리 테이블을 바탕으로 데이터 딕셔너리 뷰를 만들고 catproc.sql은 PL/SQL을 사용할 수 있도록 준비를 하고 각종 패키지 등을 생성한다.

 

PL/SQL과 관련된 원인 불명의 에러들은 catproc.sql 스크립트를 다시 한번 실행해주면 해결되는 경우가 많기 때문에 catproc.sql은 만병 통치약처럼 사용되기도 한다. 단, 스크립트가 실행되는 화면을 스풀로 받아서 제대로 실행이 되었는지를 꼭 확인할 필요가 있다. catproc.sql가 실행되는 도중에 SGA 부족 등의 이유로 에러가 발생함으로써 결국 PL/SQL이 제 기능을 하지 못하는 사례가 왕왕 발생하기 때문이다.

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

컨트롤 파일

 

4-1. 컨트롤 파일의 위치를 확인할 수 있는 명령이나 딕셔너리 뷰를 선택하시오(정답은 세 가지).

 

a. V$DATABASE

b. V$PARAMETER

c. V$CONTROL_FILE

d. V$CONTROLFILE

e. DICTIONARY

f. SHOW PARAMETER

g. SHOW CONTROL

h. V$CONTROLFILE_RECORD_SECTION

 

 

<해설>

 

컨트롤 파일의 위치는 파라미터 파일에 명시되어 있으므로 파라미터 정보를 볼 수 있는 방법을 찾아야 한다. 딕셔너리 뷰 중에서는 V$PARAMETER에서 control_files 파라미터의 값을 확인해 보면 되고 V$CONTROLFILE에서도 컨트롤 파일 정보를 알아낼 수 있다. 또한 SQL*Plus에서 SHOW PARAMETER 명령을 사용하면 파라미터 전체 또는 일부를 확인할 수 있으므로 컨트롤 파일을 찾는데 이용 가능하다.

 

V$CONTROLFILE_RECORD_SECTION은 컨트롤 파일의 위치를 알려주는 것이 아니라 컨트롤 파일에 들어 있는 각 섹션별 크기와 여유 공간, 사용 현황 등을 보여준다.

 

정답 : (b) (d) (f) (<- 마우스로 정답 부분을 선택하세요)

 

 

4-2. 하나의 데이터베이스에서 사용할 수 있는 컨트롤 파일의 최소 및 최대 개수는?

 

a. 2-2

b. 2-3

c. 1-5

d. 1-8

e. 2-10

f. 1-무제한

g. 2-무제한

 

 

<해설>

 

컨트롤 파일은 적어도 두 개 이상을 사용하는 것이 권장되지만 한 개만 사용할 수도 있다. 그러나 만약을 위해서 여러 개의 컨트롤 파일을 사용하는 것이 좋은데 이와 같이 멀티플렉싱된 컨트롤 파일은 내용은 동일하며 단지 이름만 다르다.

 

컨트롤 파일은 최대 8개 까지 멀티플렉싱해서 사용할 수 있다. 여러 개의 컨트롤 파일을 만들어서 디스크마다 분산시켜 놓으면 일부 디스크가 손상되더라도 안전하게 보호할 수 있다. 물론 항상 여러 개의 컨트롤 파일을 갱신해야 하기 때문에 오버헤드가 증가한다는 단점도 있지만 컨트롤 파일에 저장되는 정보의 크기가 작을 뿐 아니라 기록 빈도도 낮기 때문에 부하의 증가는 체감하기 어렵다. 그보다는 컨트롤 파일의 개수가 많을 경우 관리하기가 어렵다는 것이 더 큰 문제점이다. 따라서 3~4개 정도가 가장 적당한 개수로 알려져 있다.

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요

 

4-3. 다음 중 컨트롤 파일에 들어있는 정보가 아닌 것은?

 

a. 데이터베이스 이름

b. 데이터 파일의 이름과 위치

c. 데이터베이스 생성 날짜

d. 롤백 세그먼트 정보

e. 체크포인트 정보

 

 

<해설>

 

컨트롤 파일은 데이터베이스의 물리적 정보를 저장하는 곳이다. 롤백 세그먼트와 관련된 정보는 컨트롤 파일이 아니라 데이터 딕셔너리에 저장된다.

 

이외에도 컨트롤 파일에는 현재의 로그 시퀀스 번호, 온라인 리두 로그 파일의 이름과 위치, 로그 히스토리, 테이블스페이스 정보 등이 기록된다.

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

 

리두 로그 파일

 

5-1. MAXLOGFILES = 3, MAXLOGMEMBERS = 2 로 설정된 데이터베이스가 가질 수 있는 온라인 리두 로그 파일의 최대 개수는(미러링된 파일 포함)?

 

a. 2

b. 3

c. 6

d. 8

e. 9

 

 

<해설>

 

리두 로그 파일은 롤백 세그먼트를 포함한 데이터베이스의 변경 정보가 기록되는 곳으로 복구를 위한 핵심 메커니즘이다. 데이터 파일에 데이터가 아직 저장되지 않은 상태에서 데이터베이스가 다운되었을 때 리두 로그 파일의 정보를 이용해서 복구를 한다는 원리이다.

 

리두 로그 파일은 최소 2 개 이상의 그룹으로 구성되며 각 그룹은 미러링된 여러 개의 파일로 이루어진다. 미러링을 하지 않아도 동작하지만 최소한의 보호 장치로서 미러링의 역할은 거의 필수적이다.

 

MAXLOGFILES는 리두 로그 그룹의 최대 개수를 지정하는 파라미터이고 MAXLOGMEMBERS는 각 그룹의 최대 파일 개수를 지정한다. 따라서 리두 로그 파일의 최대 개수는 이 둘을 곱한 값으로 결정된다.

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

 

5-2. V$LOG에서 리두 로그 그룹의 STATUS가 INACTIVE라면 어떤 상태를 의미하는가?

 

a. 현재 사용중인 그룹

b. 현재 사용중은 아니지만 인스턴스 복구에 필요한 그룹

c. 현재 사용중은 아니며 인스턴스 복구에도 필요 없는 그룹

d. 재생성중인 그룹

 

 

<해설>

 

V$LOG는 컨트롤 파일에 기록되어 있는 리두 로그 그룹의 정보를 제공한다. 각 그룹의 상태를 알려주는 STATUS 컬럼은 보통 CURRENT, ACTIVE, INACTIVE 중의 하나를 가지고 있다.

 

CURRENT는 현재 사용중인 리두 로그 그룹을 뜻한다. 오라클은 한번에 하나의 리두 로그 그룹에만 기록을 하므로 CURRENT로 표시될 수 있는 리두 로그 그룹은 항상 하나 밖에 존재하지 않는다.

 

ACTIVE는 현재 사용하고 있지는 않지만 인스턴스 복구에 필요한 그룹이다. 아직 이 그룹에 들어있는 내용 모두가 데이터 파일에 반영된 상태는 아니므로 데이터베이스가 다운되었을 때에는 이 그룹의 정보를 이용하여 인스턴스 복구가 수행된다.

 

INACTIVE는 이 그룹에 들어 있는 내용이 모두 데이터 파일에 반영되었으므로 데이터베이스가 다운되더라도 복구에 사용되지 않는 그룹을 말한다.

 

따라서 INACTIVE 그룹에 속한 파일이 모두 손실되더라도 인스턴스 복구가 가능하지만 ACTIVE나 CURRENT 그룹이 모두 손실된 경우에는 완전한 복구는 불가능하다.

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

5-3. 체크포인트를 자주 하게 만드는 방법으로 옳지 않은 것은?

 

a. LOG_CHECKPOINT_TIMEOUT을 작은 값으로 설정한다.

b. ARCHIVE 모드로 운영한다.

c. LOG_CHECKPOINT_INTERVAL을 작은 값으로 설정한다.

d. 작은 크기의 로그 파일을 사용한다.

 

 

<해설>

 

체크포인트가 발생하면 지금까지의 작업 내용이 데이터 파일에 기록되어 데이터베이스가 다운되더라도 리두 로그 파일로부터 복구를 할 필요가 없게 된다. 즉, 데이터베이스 버퍼 캐시의 정보가 모두 데이터 파일에 기록되며 각 데이터 파일과 컨트롤 파일, 리두 로그 파일의 헤더 정보도 새롭게 갱신된다.

 

체크포인트를 자주 발생하도록 하면 오버헤드가 조금 늘어나긴 하지만 데이터베이스가 다운되었을 때 복구해야 하는 데이터가 적으므로 복구 시간이 단축된다는 이점이 있다.

 

LOG_CHECKPOINT_TIMEOUT은 체크포인트에 타임 아웃을 설정하는 파라미터로 만약 이 값에 지정된 시간(초)동안 체크포인트가 발생하지 않았을 때에는 체크포인트가 수행된다. 다시 말해서 이 파라미터에 지정된 시간이 넘도록 체크포인트가 발생하지 않는 경우는 없게 된다. 0은 무한대와 같이 취급되기 때문에 타임 아웃에 의한 체크포인트는 발생하지 않는다.

 

LOG_CHECKPOINT_INTERVAL은 리두 로그 파일에 기록된 블록의 개수를 기준으로 일종의 타임 아웃을 설정하는 파라미터로 예를 들어서 이 값이 1000이라면 1000개의 블록(오라클 블록이 아니라 운영체제 블록)이 리두 로그 파일에 기록될 때 까지 체크 포인트가 발생하지 않았다면 체크포인트를 수행한다는 것을 말한다.

 

로그 파일의 크기가 작으면 하나의 로그 파일에 기록이 끝나고 다음 로그 파일로 넘어가는 로그 스위치가 자주 발생할 뿐 아니라 체크포인트가 이루어지지 않아서 리두 로그 파일을 재사용할 수 없는 지연 사태가 발생하지 않도록 체크포인트가 자주 발생된다. 잦은 로그 스위치로 인한 부하를 감소시키기 위해서 대량의 데이터 작업을 할 때에는 리두 로그 파일을 수백 MB 이상의 크기로 만들고 작업하기도 한다.

 

정답 : (b) (<- 마우스로 정답 부분을 선택하세요)

 

 

5-4. 리두 로그 그룹이 현재 3개의 파일로 구성되어 있다. 데이터베이스를 사용하던 중 한 그룹에 속한 두 개의 파일을 실수록 삭제했다면 데이터베이스는 어떻게 되는가?

 

a. 삭제된 파일이 CURRENT 리두 로그 파일이라면 데이터베이스가 셧다운된다.

b. 삭제된 파일이 ACTIVE 리두 로그 파일이라면 데이터베이스가 셧다운된다.

c. ARCHIVE 모드가 아니라면 데이터베이스가 셧다운된다.

d. 어떤 파일이든 간에 정상적으로 사용할 수 있다.

 

 

<해설>

 

리두 로그 파일의 각 그룹을 여러 개의 파일로 미러링하는 이유는 파일의 삭제나 디스크의 손상 위험에 대비하기 위해서다. 따라서 그룹 내의 파일 중에서 하나만이라도 남아 있다면 데이터베이스는 마치 아무 일도 없었던 것처럼 동작하기 때문에 사용자는 전혀 이상을 느끼지 못한다. 그러나 지워진 파일은 자동으로 복구되지는 않으므로 DBA가 직접 만들어 주어야 한다.

 

리두 로그 파일의 손실이 감지되면 LGWR은 트레이스 파일을 생성하며 Alert 로그 파일에도 리두 로그 파일이 없다는 에러 메시지가 기록되므로 수시로 Alert 로그 파일을 확인해서 데이터베이스의 이상 유무를 점검하는 것이 좋다.

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

 

테이블스페이스와 데이터 파일

 

6-1. 다음과 같이 테이블을 생성하였을 때 네 번째 익스텐트의 크기는?

 

CREATE TABLE parts

(name VARCHAR2(30),

inventory NUMBER,

code CHAR(4))

STORAGE

(INITIAL 500K

NEXT 100K

PCTINCREASE 200

MINEXTENTS 2);

 

 

a. 100KB

b. 300KB

c. 500KB

d. 700KB

e. 900KB

 

 

<해설>

 

오라클을 처음 접할 때에는 테이블스페이스의 개념을 이해하고 나면 오라클에 대해서 시야가 확 트이게 된다. 테이블스페이스는 하나 이상의 파일로 이루어진 데이터 저장소이다. 테이블스페이스에는 테이블, 인덱스, 클러스터, 롤백 세그먼트 등의 여러 가지 객체를 생성할 수 있다. 객체를 만들 때에는 초기에 일정한 크기를 테이블스페이스로부터 할당 받고 그 다음부터는 데이터가 증가하면서 객체도 함께 성장하게 된다.

 

테이블스페이스 내에서 공간을 할당할 때에는 익스텐트라는 단위를 사용하며 익스텐트는 다시 여러 개의 오라클 블록으로 구성된다. 오라클 블록의 크기는 DB_BLOCK_SIZE 파라미터에 정의되어 있으며 데이터베이스를 생성할 때 결정되고 일단 데이터베이스를 만든 다음에는 변경이 불가능하다.

 

익스텐트의 크기를 결정하는 파라미터는 테이블스페이스와 객체에 각각 지정할 수 있는데 객체 생성시에 지정한 파라미터가 우선적으로 적용되고 별도로 명시하지 않은 파라미터는 테이블스페이스로부터 가져온다.

 

parts 테이블의 첫 번째 익스텐트는 INITIAL 값에 따라서 500KB가 되고 두 번째 익스텐트는 NEXT 값인 100KB가 된다. MINEXTENTS가 2 이므로 이 테이블은 처음 생성될 때 두 개의 익스텐트를 할당 받는다.

 

세 번째 익스텐트부터는 이전의 익스텐트에 PCTINCREASE(퍼센트) 만큼을 추가한 값으로 결정된다. 따라서 세 번째 익스텐트는 두 번째 익스텐트보다 200% 증가한 300KB가 되고 네 번째 익스텐트는 세 번째 익스텐트보다 다시 200% 증가한 900KB가 된다. 이와 같이 PCTINCREASE를 0이 아닌 값으로 지정하면 비록 작은 값이라도 익스텐트의 크기가 기하급수적으로 커지게 되므로 공간 활용에 문제를 야기할 소지가 있다.

 

테이블을 만들 때 스토리지 파라미터를 지정하지 않은 경우에는 그 테이블이 생성되는 테이블 스페이스의 디폴트 스토리지 파라미터를 사용하게 되는데 이 관계를 정확히 파악하지 못해서 문제가 발생하는 경우가 있다. 통상적으로 테이블을 구성하는 익스텐트의 개수가 많아지면 퍼포먼스가 떨어지기 때문에 INITIAL 값을 크게 설정해서 익스텐트의 개수를 가급적 적게 유지하게 된다. 그래서 DBA는 테이블 스페이스의 INITIAL 값을 매우 크게 세팅하는 반면 사용자들은 테이블을 만들 때 스토리지 파라미터를 지정하기가 귀찮으므로 생략하는 경우가 많다. 결과적으로 사용자가 아무런 생각 없이 테이블을 여러 개 만들고 나면 아직 데이터를 하나도 넣지 않았음에도 테이블스페이스가 가득 차버리는 기현상이 발생하게 되는 것이다.

 

정답 : (e) (<- 마우스로 정답 부분을 선택하세요)

 

 

6-2. SYSTEM 테이블스페이스의 데이터파일이 위치한 디스크의 여유 공간이 부족해서 다른 디스크로 옮기려고 한다. 필요한 작업을 모두 선택하시오(정답은 네 가지, 순서는 무시).

 

a. ALTER TABLESPACE SYSTEM OFFLINE 명령을 실행한다.

b. ALTER TABLESPACE SYSTEM RENAME DATAFILE 명령으로 파일을 다른 디스크로 옮긴다.

c. ALTER DATABASE RENAME FILE 명령으로 파일을 다른 디스크로 옮긴다.

d. OS 상에서 파일을 다른 디스크로 옮긴다.

e. ALTER TABLESPACE SYSTEM ONLINE 명령을 실행한다.

f. 데이터베이스를 셧다운 후 STARTUP NOMOUNT를 실행한다.

g. 데이터베이스를 셧다운 후 STARTUP MOUNT를 실행한다.

h. 데이터베이스를 오픈 시킨다.

 

 

<해설>

 

실제로 데이터베이스를 운영하다 보면 데이터파일을 다른 곳으로 옮겨야 하는 경우가 비일비재하다. 이유로는 역시 디스크가 가득찬 경우가 제일 많고 새롭게 디스크를 확충한 다음에 여기 저기 흩어져 있는 데이터 파일을 깔끔하게 정리할 때에도 이 작업을 많이 하게 된다.

 

데이터파일을 옮길 때에는 오라클과 운영 체제 양쪽에서 모두 작업해 주어야 한다. 오라클에서 RENAME 기능으로 파일을 옮기는 것은 단순히 컨트롤 파일의 정보를 수정하는 것에 불과하기 때문에 OS 상에서 파일을 새로운 위치로 복사하거나 이동시켜 주어야 한다.

 

일반적인 테이블스페이스를 옮긴다면 해당 테이블스페이스만 OFFLINE 시켜놓고 작업하면 되지만 SYSTEM 테이블스페이스는 OFFLINE 시킬 수 없기 때문에 데이터베이스가 오픈된 상태에서는 할 수 없고 마운트 상태에서 작업해야 한다. 순서를 정리해 보면 다음과 같다.

 

 

데이터베이스를 마운트 상태로 만든다.

 

SYSTEM 테이블스페이스의 파일을 OS 상에서 새로운 곳으로 복사하거나 이동시킨다. 파일이 크지 않다면 이동시키는 것 보다는 만약을 위해서 복사하는 편이 안전하다.

 

ALTER DATABASE RENAME FILE 명령으로 새로운 파일의 위치를 지정한다.

 

데이터베이스를 오픈한다.

 

정답 : (c) (d) (g) (h) (<- 마우스로 정답 부분을 선택하세요)

 

6-3. 사용자가 USERS 테이블스페이스에 있는 테이블을 수정하는 도중에 DBA가 다음 명령을 실행하였다.

 

ALTER TABLESPACE USERS READ ONLY;

 

 

결과는 어떻게 될까?

 

a. USERS를 사용하는 트랜잭션이 종료할 때 까지 ALTER TABLESPACE 명령은 기다린다.

b. ALTER TABLESPACE 명령에서 에러가 발생한다.

c. USERS를 사용하는 트랜잭션이 강제로 롤백되고 ALTER TABLESPACE 명령이 수행된다.

d. USERS를 사용하는 트랜잭션이 강제로 커밋되고 ALTER TABLESPACE 명령이 수행된다.

 

 

<해설>

 

읽기 전용(read only) 테이블스페이스는 내용이 변경되지 않으므로 한번만 백업해 두면 백업과 복구의 번거로움에서 해방될 수 있으며 중요한 데이터의 변경을 방지하고 가격이 저렴한 CDROM에 보관할 수도 있다. 단, 테이블의 내용은 변경할 수 없지만 읽기 전용이라는 이름과는 달리 아예 테이블을 삭제(drop)하는 것은 허용되므로 주의해야 한다.

 

Oracle8i은 테이블스페이스를 사용하는 트랜잭션이 있으면 테이블스페이스가 일단 transitional read-only 모드로 설정된 다음 트랜잭션이 종료될 때 까지 기다리도록 인본주의에 입각한 구조를 갖추고 있다.

 

정답 : (a) (<- 마우스로 정답 부분을 선택하세요)

 

 

6-4. 현재 다음과 같은 4개의 테이블스페이스가 있다. 새로운 유저를 만들 때 사용할 임시 테이블스페이스를 지정하지 않았다면 이 중에서 어떤 테이블스페이스를 사용하는가?

이름                타입 
SYSTEM         PERMANENT 
RBS                PERMANENT 
TEMP             TEMPORARY 
USERS            PERMANENT 

 

a. SYSTEM

b. RBS

c. TEMP

d. USERS

 

 

<해설>

 

유저를 만들 때 TEMPORARY TABLESPACE 구문을 이용해서 임시 테이블스페이스를 지정하지 않으면 디폴트로 SYSTEM 테이블스페이스가 사용된다. 오라클에서는 SYSTEM 테이블스페이스에 일반 테이블, 그리고 특히 임시 세그먼트를 만드는 것을 금기시 하면서도 왜 디폴트로 SYSTEM 테이블스페이스를 사용하도록 만들었는지 불가사의한 일이다.

 

TEMP 테이블스페이스는 TEMPORARY 상태이므로 이 곳에는 다른 객체는 만들 수 없고 오직 임시 세그먼트만 만들 수 있다. 임시 세그먼트는 사용자가 직접 만드는 것이 아니라 오라클이 필요할 때 만들게 된다.

 

TEMPORARY 상태의 테이블스페이스에 만들어진 임시 세그먼트는 여러 세션에서 함께 공유해서 사용하므로 공간 할당의 부하가 적고 시스템 전체의 성능 향상에 도움이 된다. PERMANENT 테이블스페이스에 임시 세그먼트와 테이블이 공존하게 되면 테이블스페이스의 단편화가 급속히 진전되기 때문에 어떠한 경우에도 이렇게 구성하는 것은 바람직하지 않다.

 

정답 : (a) (<- 마우스로 정답 부분을 선택하세요)

 

논리적 저장구조

 

7-1. 데이터베이스의 논리적 구조에 해당되는 것이 아닌 것은? (정답은 세 가지)

 

a. 데이터 파일

b. 테이블스페이스

c. 리두로그 파일

d. 익스텐트

e. 세그먼트

f. 데이터 블록

g. 컨트롤 파일

h. 스키마 객체

 

 

<해설>

 

데이터베이스의 논리적 구조란 운영 체제가 아니라 오라클 입장에서 바라본 저장 구조를 의미한다.

 

가장 작은 단위는 데이터 블록이다. 데이터 블록은 운영 체제 블록을 모아서 만들어지며 데이터베이스의 최소 입출력 단위이다.

 

데이터 블록이 모이면 익스텐트가 만들어진다. USER_EXTENTS를 보면 익스텐트마다 한 줄씩 정보가 출력되는데 BLOCKS 컬럼을 통해서 각 익스텐트가 몇 개의 블록으로 구성되었는지를 파악할 수 있다.

 

세그먼트는 익스텐트가 모여서 이루어진다. 세그먼트에는 테이블이나 파티션, 클러스터를 구성하는 데이터 세그먼트, 인덱스를 위한 인덱스 세그먼트, 롤백 세그먼트, 임시 세그먼트가 있다. 익스텐트와 세그먼트의 중요한 차이점은 하나의 익스텐트는 하나의 파일 안에 존재하지만 하나의 세그먼트는 여러 개의 파일에 걸쳐서 존재할 수 있다는 것이다. 예를 들어 2개의 데이터 파일로 구성된 테이블 스페이스가 있을 때 각각의 파일에 여유 공간이 1MB씩 남아 있다면 2MB 크기의 익스텐트는 만들 수 없지만 1MB 크기의 익스텐트 두 개를 생성하여 세그먼트를 구성하는 것은 가능하다.

 

더 상위의 개념으로는 스키마 객체와 테이블스페이스가 있으며 데이터베이스의 물리적 구조에는 데이터 파일, 컨트롤 파일, 리두 로그 파일이 있다.

 

정답 : (a) (c) (g) (<- 마우스로 정답 부분을 선택하세요)

 

 

7-2. 업데이트가 거의 되지 않는 테이블 A와 빈번하게 업데이트가 발생하는 테이블 B의 PCTFREE 값의 적절한 크기는?

 

a. PCTFEEE(A) > PCTFREE(B)

b. PCTFEEE(A) < PCTFREE(B)

c. PCTFEEE(A) = PCTFREE(B)

 

 

<해설>

 

INITIAL, NEXT 등이 익스텐트의 크기를 결정하는 파라미터라면 PCTFREE와 PCTUSED는 오라클 블록 내부의 공간을 어떻게 활용할 것인가를 결정한다. PCTFREE와 PCTUSED를 테이블의 성격에 맞게 잘 지정하면 디스크를 절약할 수 있고 퍼포먼스도 증가하지만 데이터의 성격과 맞지 않으면 역효과를 가져오기 때문에 쉽게 접근하기 어려운 항목이다.

 

블록 내의 여유 공간(free space)이 PCTFREE(디폴트 10%) 아래로 떨어지면 더 이상 그 블록에 새로운 레코드는 추가하지 않게 되며 남은 공간은 기존의 레코드가 수정되어 크기가 증가하는 것에 대비하게 된다.

 

PCTFREE 조건에 걸려서 새로운 레코드의 추가가 금지되었던 블록의 사용량이 PCTUSED(디폴트 40%) 아래로 떨어질 경우 다시 새로운 레코드의 추가가 허용된다. PCTUSED 값이 사용되기 위해서는 그 전에 먼저 PCTFREE 조건에 걸려야 한다는 것에 주의하기 바란다.

 

일단 저장된 후에는 변경될 가능성이 거의 없는 데이터라면 업데이트에 대비하기 위한 여유 공간이 적어도 되므로 PCTFREE 값을 작게 설정하여 블록의 공간 활용도를 극대화 시킬 수 있다. 이렇게 하면 조회 할 때 읽어야 하는 블록의 수가 적으므로 성능 향상이 가능하지만 레코드의 크기가 증가하여 블록 내의 남은 공간에서 수용할 수 없게 될 경우에는 로우 체인이나 마이그레이션으로 인한 성능 저하를 감수해야만 한다.

 

데이터의 수정으로 레코드의 크기가 증가할 가능성이 높다면 PCTFREE 값을 크게 설정하여 여유 공간을 충분히 확보해 두어야 한다. 하나의 레코드가 하나의 블록에 들어가지 못하고 여러 개의 블록에 걸쳐서 존재하는 로우 체인이나 레코드의 크기 가 증가하여 자신의 크기에 맞는 블록을 찾아서 이동하는 마이그레이션에 의한 오버헤드가 발생하는 것을 최대한 방지해야 한다.

 

정답 : (b) (<- 마우스로 정답 부분을 선택하세요)

 

7-3. 테이블을 만들 때 INITRANS=10, MAXTRANS=100으로 설정했다면 이 테이블의 한 블록을 동시에 업데이트 할 수 있는 트랜잭션의 수는?

 

a. 1

b. 10

c. 100

d. 255

e. 제한 없음

 

 

<해설>

 

테이블을 만들 때 INITRANS와 MAXTRANS에 대해서 크게 신경 쓰지 않는 이유는 주어진 대로 사용해도 별 지장이 없을 뿐 아니라 최적의 값을 찾기가 사실 매우 어렵기 때문이다. 때문에 오라클에서는 이 두 값을 디폴트로 사용할 것을 강력하게 권장하고 있다.

 

오라클 블록에 들어있는 레코드에 업데이트, 삭제 등의 작업을 할 때에는 블록의 일부 공간을 트랜잭션 엔트리를 위해서 사용하게 된다. 트랜잭션 엔트리는 운영 체제에 따라서 다르지만 보통 23바이트의 크기를 갖는다. 미리 트랜잭션 엔트리를 위한 공간을 많이 확보해 놓으면 실제 데이터가 들어갈 공간이 줄어들기 때문에 INITRANS 만큼만 최소한으로 할당하고 필요에 따라서 그 양을 늘려가도록 되어 있다. 그러나 너무 많은 공간을 트랜잭션 엔트리에 할당해 줄 수는 없기 때문에 MAXTRANS로 상한선이 설정되며 그 이후의 트랜잭션은 작업을 수행하지 않고 대기하게 된다.

 

INITRANS의 디폴트 값은 테이블은 1 이고 클러스터와 인덱스는 2이다. MAXTRANS의 디폴트 값은 블록의 크기와 운영 체제에 따라서 가변적으로 결정된다.

 

정답 : (c) (<- 마우스로 정답 부분을 선택하세요)

 

 

7-4. 아래의 명령으로 USERS 테이블스페이스의 여유 공간을 확인했더니 10483712 라는 결과를 얻었다.

 

SELECT SUM(BYTES) FROM DBA_FREE_SPACE

WHERE TABLESPACE_NAME=’USERS’;

 

 

이 테이블스페이스에 다음과 같은 스토리지 파라미터를 갖는 테이블을 만들려고 한다면 어떤 결과가 발생하겠는가? 단, USERS 테이블스페이스의 AUTOEXTEND는 OFF 상태라고 가정한다.

 

INITIAL 1M

NEXT 1M

MINEXTENTS 5

 

 

a. 정상적으로 테이블이 생성되고 5개의 익스텐트를 모두 할당 받는다.

b. 테이블은 생성되지만 5개의 익스텐트를 모두 할당 받지는 못할 수도 있다.

c. 여유 공간이 부족하므로 에러가 발생한다.

d. 테이블스페이스의 단편화 정도에 따라서 테이블이 생성될 수도 있고 에러가 발생할 수도 있다.

 

 

<해설>

 

USERS 테이블스페이스에는 10MB 정도의 여유 공간이 남아 있지만 이 수치는 남아있는 익스텐트의 크기를 모두 합친 것이기 때문에 실제로 각 익스텐트에 관한 정보는 알 수 없다. 문제의 테이블은 1MB 크기의 익스텐트를 5개 만들어야 하므로 여유 공간의 총합이 아니라 1MB의 연속된 공간을 5개 확보할 수 있는지가 관건인데 주어진 정보만으로는 판단할 수 없으므로 (d)가 가장 정답에 가깝다고 볼 수 있다.

 

테이블이 생성될 때 MINEXTENTS 만큼의 익스텐트를 모두 할당받지 못하면 테이블이 아예 만들어지지 않으므로 (b)는 정답이 될 수 없다.

 

정답 : (d) (<- 마우스로 정답 부분을 선택하세요)

[Top]
No.
제목
작성자
작성일
조회
8761OCP 강좌 - Backup and Recovery (2)
정재익
2001-12-07
9832
8760OCP 강좌 - Backup and Recovery (1)
정재익
2001-12-07
9976
8759OCP 강좌 - Architecture and Administration (2)
정재익
2001-12-07
11171
8758OCP 강좌 - Architecture and Administration (1)
정재익
2001-12-07
10497
8751OCP 강좌 - Introduction to Oracle: SQL and PL/SQL (2)
정재익
2001-12-07
14183
8750OCP 강좌 - Introduction to Oracle: SQL and PL/SQL (1)
정재익
2001-12-07
22039
8679오라클 강의록 일부
정재익
2001-12-03
9540
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.051초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다