롤백 세그먼트

8-1. 인스턴스가 사용할 롤백 세그먼트를 지정하는 파라미터는?

a. TRANSACTIONS_PER_ROLLBACK_SEGMENT

b. ROLLBACK_SEGMENTS

c. SESSIONS

d. PROCESSES

<해설>

롤백 세그먼트에는 SYSTEM, DEFERRED, PUBLIC, PRIVATE의 4 가지 종류가 있지만 DBA가 컨트롤 할 수 있는 것은 PUBLIC과 PRIVATE 롤백 세그먼트이다.

롤백 세그먼트를 만들 때 특별히 PUBLIC 이라고 지정하지 않으면 PRIVATE 롤백 세그먼트가 만들어 진다. PRIVATE 롤백 세그먼트는 하나의 인스턴스에 종속되어 사용되는 반면 PUBLIC 롤백 세그먼트는 병렬 서버에서 롤백 세그먼트를 필요로 하는 인스턴스는 누구든지 사용할 수 있다. 물론 하나의 롤백 세그먼트를 여러 개의 인스턴스가 공유할 수는 없으며 필요로 하는 인스턴스에게 할당된다. 이해를 돕기 위해서 인스턴스가 롤백 세그먼트를 어떻게 할당 받는지를 알아보자.

인스턴스가 기동할 때 다음 수식에 의해서 필요한 롤백 세그먼트의 수가 결정된다.

CEIL(TRANSACTIONS / TRANSACTIONS_PER_ROLLBACK_SEGMENT)

예를 들어 TRANSACTIONS=50 이고 TRANSACTIONS_PER_ROLLBACK_SEGMENT=4 라면 50/4=12.5 이므로 이 값보다 큰 가장 적은 정수인 13개가 필요한 롤백 세그먼트의 개수이다.

먼저 ROLLBACK_SEGMENTS에 등록된 롤백세그먼트를 PRIVATE, PUBLIC 구분 없이 ONLINE 시킨다. 이 파라미터에 등록된 개수가 위에서 계산한 13개보다 많더라도 무조건 ONLINE 시켜서 사용한다.

ROLLBACK_SEGMENTS에 등록된 롤백 세그먼트가 13개보다 적다면 부족한 부분은 PUBLIC 롤백 세그먼트를 할당 받아 충당한다. 하지만 사용할 수 있는 PUBLIC 롤백 세그먼트가 없거나 부족하더라도 인스턴스는 정상적으로 기동된다.

TRANSACTIONS_PER_ROLLBACK_SEGMENT는 롤백 세그먼트 당 몇 개의 트랜잭션을 처리하면 적당한가를 지정하는 것으로 인스턴스가 필요로 하는 롤백 세그먼트의 수를 계산하기 위해서 사용되는 것이지 실제로 하나의 롤백 세그먼트가 처리할 수 있는 트랜잭션 수를 지정하는 것은 아니다. 롤백 세그먼트가 감당할 수 있는 트랜잭션의 수는 블록의 크기에 의해서 결정된다.

TRANSACTIONS는 동시에 실행 가능한 트랜잭션의 최대 수를 지정하는 것으로 특별히 명시하지 않는다면 SESSIONS에 의해서 결정되고 SESSIONS는 다시 PROCESSES에 의해서 계산된다.

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

8-2. ‘ORA-1555 Snapshot too old’ 에러에 대한 조치방법으로 옳지 않은 것은?

a. 롤백 세그먼트의 각 익스텐트를 보다 크게 만든다

b. 롤백 세그먼트가 들어 있는 테이블스페이스의 용량을 확장한다

c. OPTIMAL을 큰 값으로 변경한다

d. 오랫동안 수행되는 쿼리는 가급적 사용자가 적을 때 실행한다

e. 롤백 세그먼트의 MINEXTENTS를 큰 값으로 변경해서 다시 생성한다.

<해설>

‘Snapshot too old’는 롤백 세그먼트와 관련된 에러 중에서 가장 골치 아픈 에러이다.

예를 들어 LARRY가 1998년의 판매 데이터를 수정하고 아직 커밋은 하지 않은 상태에서 SCOTT가 1991년부터 2000년 까지 10년 동안의 판매 데이터를 조회하는 쿼리를 실행했다고 생각해 보자. LARRY가 커밋을 하지 않았기 때문에 SCOTT가 실행한 쿼리는 읽기 일관성(read consistency)을 유지하기 위해서 1998년 데이터는 롤백 세그먼트에서 읽어와야 한다.

지금까지는 아무런 문제가 없지만 SCOTT의 쿼리가 1998년 데이터를 가져 오기 전에 LARRY가 커밋을 하면 위험이 발생하기 시작한다. 커밋을 하면 이전의 1998년 데이터가 저장되어 있던 롤백 세그먼트의 블록이 재사용 가능 상태가 되므로 SCOTT가 이 블록에서 필요한 데이터를 읽기 전에 다른 사용자의 트랜잭션에서 발생한 롤백 정보가 이 블록을 덮어 쓸 수 있는 가능성이 있는 것이다. 그렇게 되면 SCOTT의 쿼리는 읽기 일관성을 유지할 수 없기 때문에 ‘Snapshot too old’ 에러가 발생한다.

이 에러가 발생하지 않으려면 롤백 세그먼트의 정보가 가능한 오랫동안 지워지지 않고 남아있도록 해야 한다. (b)를 제외한 보기가 모두 옳은 조치 방법이다. 이 에러는 저장 공간의 용량 부족 때문에 발생한 것은 아니기 때문에 (b)와 같이 테이블 스페이스를 확장하는 것으로는 해결 할 수 없다.

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

8-3. 다음 명령에서 잘못된 부분을 골라라. (정답은 두 가지)

CREATE ROLLBACK SEGMENT rbs05

STORAGE

a. (INITIAL 100K

b. NEXT 200K

c. MINEXTENTS 3

d. OPTIMAL 5

e. PCTINCREASE 0)

TABLESPACE RBS;

<해설>

롤백 세그먼트의 모든 익스텐트의 크기가 동일한 것이 성능 향상에 좋은 것으로 알려져 있지만 강제적인 조건은 아니므로 (a)와 (b)처럼 INITIAL과 NEXT 값이 달라도 상관은 없다. MINEXTENTS는 2 이상이면 되므로 (c)도 문제가 없다.

OPTIMAL은 MINEXTENTS 만큼의 익스텐트 크기와 같거나 커야 하는데 5라고 지정하면 5 개의 익스텐트가 아니라 5 바이트로 인식된다. 여기서는 500K 이상으로 설정해야 하므로 (d)에서 에러가 발생한다.

데이터베이스를 사용하다 보면 롤백 세그먼트의 크기가 점점 커져서 테이블스페이스를 불필요하게 많이 차지하게 된다. 따라서 주기적으로 직접 롤백 세그먼트의 크기를 줄여주거나 또는 아예 삭제한 다음에 재생성 하는 작업을 실시해 주는 것이 좋다. 자동으로 크기를 축소시키려면 OPTIMAL 값을 설정하면 되는데 너무 작은 값을 지정하면 잦은 확장과 축소로 인한 상당한 성능 저하가 발생하므로 유의해야 한다.

PCTINCREASE는 롤백 세그먼트의 스토리지 파라미터로 지정할 수 없으며 무조건 0으로 설정된다. (e)와 같이 0으로 지정하는 것도 허용되지 않는다.

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

8-4. A 대학교의 수강 신청 시스템은 동시에 최대 100명의 학생들이 단말기를 통해서 접속한다. 한 명이 하나의 트랜잭션을 유발한다고 가정할 때 몇 개의 롤백 세그먼트를 만드는 것이 적절한가?

a. 10

b. 25

c. 50

d. 100

<해설>

수강 신청 시스템과 같은 OLTP 환경에서 권장되는 롤백세그먼트는 트랜잭션 당 4개이다. 따라서 100개의 트랜잭션을 수용하기 위해서 25개의 롤백 세그먼트가 필요하다는 계산이 나온다. 그러나 롤백 세그먼트의 개수가 너무 많아도 테이블스페이스의 공간이 부족해 지는 등 부작용이 있기 때문에 상한선을 설정해 두는 것이 좋다.

배치 작업을 수행하는 트랜잭션에는 하나의 롤백 세그먼트를 완전히 할당할 때도 있으므로 작업의 성격에 맞게 적절히 개수를 조절해야 한다.

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

테이블 관리

9-1. 다음 명령에서 에러가 발생하는 이유는?

        CREATE TABLE books
	(isbn CHAR(12),
	 title VARCHAR2(80) NOT NULL,
	 pages NUMBER(4) NOT NULL,
	 author VARCHAR2(30) NOT NULL,
                CONSTRAINT uk_books UNIQUE (isbn, title))
	ORGANIZATION INDEX TABLESPACE USERS;

a. ORGANIZATION INDEX가 아니라 ORGANIZED INDEX로 변경해야 한다.

b. 기본 키(primary key)를 만들어야 한다.

c. IOT에서는 NOT NULL 제약 조건을 사용할 수 없다.

d. UNIQUE 제약 조건을 복합 인덱스로 만들면 안 된다.

<해설>

인덱스를 통해서 레코드를 액세스 할 때에는 키 값을 가지고 인덱스를 탐색해서 ROWID를 얻은 다음에 다시 ROWID를 이용해서 테이블을 읽는 두 번의 과정을 거쳐야 한다. 또한 키 컬럼이 인덱스와 테이블 양 쪽에 중복해서 저장되므로 키 값이 큰 경우에는 디스크의 낭비 또한 무시할 수 없다.

이런 문제점을 해결하고자 고안된 것이 IOT(Index Organized Table)이다. IOT는 인덱스 안에 테이블을 넣어 버린 구조로 되어 있기 때문에 인덱스를 읽는 것으로 모든 작업이 완료된다. 키 값에 해당되는 레코드를 테이블에서 읽을 필요도 없고 데이터의 중복 문제도 자연스럽게 해결할 수 있다.

IOT는 겉보기에는 테이블이지만 실제로는 기본 키(primary key)를 근간으로 한 인덱스이기 때문에 전제 조건으로 기본 키를 필요로 한다. 본 문제에서는 기본 키를 생성하지 않았기 때문에 에러가 발생하였다.

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

9-2. 클러스터에 대한 설명으로 옳은 것은? (정답은 세 가지)

a. 저장 공간을 절약할 수 있다.

b. 테이블을 클러스터 키로 조인해서 사용할 때에 적합하다.

c. 각 테이블을 별도로 조회할 때에도 속도가 빠르다.

d. 세 개의 테이블은 클러스터로 묶을 수 없다.

e. 키 값은 한 번만 저장된다.

<해설>

여러 개의 테이블을 클러스터로 묶는 것은 메듀사를 생각하면 이해가 쉽다. 공통적으로 사용되는 부분(몸통)은 공유하고 그 외의 부분(머리)은 각각 가지고 있지만 이들은 언제나 함께 붙어서 존재한다. 클러스터로 여러 개의 테이블을 묶을 때에는 서로를 연결해 주는 키 컬럼을 중심으로 엮어지며 같은 키 값을 가진 데이터가 물리적으로 같은 위치(블록)에 저장된다. 따라서 키 컬럼을 이용한 조인 시에 읽어야 하는 블록의 수가 대폭 감소하므로 클러스터의 진가를 발휘할 수 있다.

또한 동일한 키 값에 여러 건의 레코드가 있더라도 키 값은 한 번만 저장되기 때문에 저장 공간의 절약이 가능하며 세 개, 네 개의 테이블도 얼마든지 클러스터로 구성할 수 있다.

그러나 클러스터의 각 테이블을 개별적으로 조회할 때에는 불필요하게 다른 테이블의 내용까지 읽게 되어 속도가 느려지며 키 값이 변경되면 레코드의 마이그레이션이 자주 발생할 위험도 내포하고 있다.

데이터 딕셔너리 테이블을 보면 클러스터로 묶어서 성능을 극대화한 것들이 많은데 클러스터에는 장점과 단점이 상존하기 때문에 클러스터로 꾸몄을 때 과연 얼마나 효과를 거둘 수 있을 지는 실제로 만들어서 운영해 보지 않고는 장담하기가 어렵다.

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

9-3. parts 테이블이 다음과 같은 4개의 익스텐트로 구성되어 있다.

익스텐트      크기 
0                100KB 
1                200KB 
2                400KB 
3                800KB 

하이 워터 마크가 500KB 지점에 위치하고 있다면 아래의 두 명령을 실행한 다음에 남아 있는 익스텐트의 개수와 크기의 총 합은?

	ALTER TABLE parts ALLOCATE EXTENT;
	ALTER TABLE parts DEALLOCATE UNUSED KEEP 100K;

a. 1 개, 100KB

b. 1 개, 500KB

c. 3 개, 500KB

d. 3 개, 600KB

e. 4 개, 600KB

<해설>

홍수가 나면 한강 수위가 계속 높아지다가 비가 그치면 수위는 다시 낮아지지만 물이 닿았던 흔적은 남는다. 마찬가지로 데이터가 증가하면 익스텐트 내의 블록 사용량이 늘어나고 익스텐트가 가득 차면 다음 익스텐트를 할당 받으면서 테이블의 크기가 커지지만 데이터를 삭제해도 한번 늘어난 몸집은 줄어들지 않으며 단지 테이블 내의 여유 공간만 늘어난다. 이와 같이 데이터가 저장되었던 공간의 끝자락 혹은 최전방을 하이 워터 마크(High Water Mark, HWM)라고 부른다.

ALTER TABLE DEALLOCATE 명령을 이용해도 HWM의 수위를 낮출 수는 없으며 HWM 이상의 사용되지 않은 공간을 해제 시킬 수 있을 뿐이다. TRUNCATE 명령을 이용하면 HWM을 MINEXTENTS 까지 낮출 수 있지만 데이터는 모두 삭제된다.

첫번 째 ALTER TABLE 명령의 ALLOCATE 옵션에 의해서 4번 익스텐트가 생성된다.

두번 째 명령을 실행하면 HWM 이상의 공간이 해제(deallocate) 되는데 KEEP 100K 라고 지정했기 때문에 HWM+100KB보다 상위 공간을 해제 시킨다. HWM가 2번 익스텐트의 중간에 위치하고 있으므로 0, 1 번 익스텐트는 이 명령의 영향을 받지 않으며 2번 익스텐트에서 HWM+100KB 이상에 해당되는 나머지 100KB와 3, 4번 익스텐트 전체가 해제 된다. 그리고 2번 익스텐트의 크기는 100KB 줄어서 300KB가 된다.

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

9-4. emp 테이블에 1만 건의 데이터가 들어 있을 때 가장 적은 수의 레코드를 샘플로 사용하는 것은?

a. ANALYZE TABLE emp COMPUTE STATISTICS;

b. ANALYZE TABLE emp ESTIMATE STATISTICS;

c. ANALYZE TABLE emp ESTIMATE STATISTICS SAMPLE 1000 ROWS;

d. ANALYZE TABLE emp ESTIMATE STATISTICS SAMPLE 20 PERCENT;

<해설>

ANALYZE 명령의 용도는 몇 가지가 있지만 주로 테이블이나 인덱스, 클러스터에 관한 물리적 정보를 수집하는 목적으로 사용된다. 여기서 모아진 정보는 딕셔너리에 기록되며 옵티마이저가 최적의 실행 계획을 세울 수 있도록 하기 위한 자료로 이용된다.

테이블의 데이터가 많지 않다면 COMPUTE STATISTICS 옵션을 사용해서 데이터 모두를 대상으로 분석 해도 상관 없지만 데이터가 많으면 상당한 시간이 걸리기 때문에 사용하기 곤란하다. 따라서 데이터의 일부 만을 표본으로 뽑아서 분석하는 것이 일반적인데 얼마 만큼을 표본으로 추출할 것이냐에 따라 실행 시간과 통계 정보의 정확도가 달라진다.

각 보기에서 샘플로 사용하는 레코드의 수를 정리해보면 다음과 같다.

a. 10000건 – COMPUTE STATISTICS는 테이블 전체를 대상으로 함

b. 1064건 – ESTIMATE STATISTICS의 디폴트 샘플 수

c. 1000건 – 사용자가 1000건을 지정

d. 2000건 – 1만건의 20%

따라서 (c)가 가장 적은 1000 건의 레코드를 샘플링 함을 알 수 있다.

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

인덱스 관리

10-1. 비트맵 인덱스에 관한 설명으로 옳지 않은 것은? (정답은 두 가지)

a. DSS보다는 OLTP 환경에 적합하다.

b. 데이터의 변경은 많은 리소스를 소비한다.

c. Cardinality가 낮은 컬럼에 적합하다.

d. 일반 인덱스보다 크기가 작다.

e. Unique 인덱스로 만들 수도 있다.

<해설>

Oracle8이 처음 출시되면서 자랑했던 기능 중의 하나가 바로 비트맵(bitmap) 인덱스였다. 골치 거리였던 cardinality가 낮은(성별과 같이 데이터의 분포도가 불량한) 컬럼의 액세스 속도를 획기적으로 개선할 수 있게 되었다.

비트맵 인덱스는 확실히 관계형 데이터베이스의 성능을 한 단계 격상시켰다. 비트맵 인덱스의 구조적 특성상 데이터가 자주 변경되고 사용자 수가 많은 OLTP 환경에서는 리소스를 많이 소비하기 때문에 효용성이 떨어진다. 그러나 사용자 수는 적지만 쿼리 하나가 실행되는데 오랜 시간이 걸리는 DSS 시스템에서는 놀라운 위력을 발휘할 수 있다.

비트맵 인덱스는 각 레코드의 키 값을 종류마다 한 비트로 표현하기 때문에 일반 인덱스에 비하여 디스크 사용량이 월등히 적다.

비트맵 인덱스의 대상이 cardinality가 낮은 컬럼이기 때문에 Unique 인덱스로 만든다는 것은 본래의 의도와 완전히 상충되며 지원되지 않는다.

비트맵 인덱스에 대해서는 매뉴얼을 참조해서 원리를 꼭 이해해 두기 바란다.

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

10-2. dept 테이블의 deptno 컬럼에 걸려 있는 인덱스의 종류를 확인하려면 어떤 딕셔너리 뷰를 참조해야 하는가? (정답은 두 가지)

a. USER_TAB_INDEXES

b. USER_INDEXES

c. USER_COLUMNS

d. USER_IND_COLUMNS

e. USER_COL_INDEXES

<해설>

USER_INDEXES에는 인덱스에 관한 대부분의 정보가 들어 있지만 컬럼에 관한 것은 나와 있지 않다. 반면 USER_IND_COLUMNS에는 인덱스가 걸려 있는 테이블과 컬럼은 들어 있으나 인덱스의 유형을 비롯한 기타 정보는 구할 수가 없다. 따라서 문제에서 요구하는 답을 얻으려면 이 둘을 다음과 같이 조인해야 한다.

SELECT i.index_type
        FROM USER_INDEXES i, USER_IND_COLUMNS c
        WHERE i.index_name = c.index_name AND c.table_name = 'DEPT'
                   AND c.column_name = 'DEPTNO';

(a), (c), (e)와 같은 딕셔너리 뷰는 존재하지 않는다.

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

10-3. 인덱스가 주어진 공간을 얼마나 사용하고 있는지 확인할 수 있는 딕셔너리 뷰는?

a. INDEX_STATS

b. IND

c. USER_INDEXES

d. INDEX_HISTOGRAM

<해설>

인덱스의 키 값이 추가되고 변경, 삭제되는 과정이 반복되면 처음에는 비교적 알차게 들어가 있던 공간에 빈 자리가 늘어나면서 차츰 인덱스가 차지하는 공간의 활용도가 떨어지게 된다. 따라서 정기적으로 인덱스의 상태를 점검해서 평소보다 활용도가 떨어지면 재구성을 통해 크기를 줄이고 성능을 개선시키는 것이 좋다.

먼저 'ANALYZE INDEX 인덱스명 VALIDATE STRUCTURE’를 실행한다. 그러면 인덱스의 공간 사용도를 INDEX_STATS로부터 확인할 수 있다. 'ANALYZE INDEX 인덱스명 COMPUTE STATISTICS' 명령은 INDEX_STATS가 아니라 USER_INDEXES에서 정보를 구할 때 사용된다.

그리고 PCT_USED 컬럼의 값을 보면 공간 활용도가 퍼센트로 출력되므로 인덱스를 재구성할 시점을 판단할 수 있다. 인덱스를 재구성 하는 명령은 다음과 같다.

ALTER INDEX 인덱스명 REBUILD;

아래의 예를 보면 초기에 55% 였던 공간 활용도가 데이터가 삭제된 다음에 38%까지 떨어졌으나 인덱스를 재구성해서 86%로 높일 수 있었다.

1) 초기 상태

NAME    BTREE_SPACE   USED_SPACE        PCT_USED 
IDX2      174496                 95930                    55 

2) 데이터를 상당량 삭제한 후

NAME    BTREE_SPACE    USED_SPACE         PCT_USED 
IDX2      174496                  66074                    38 

3) 인덱스 재구성 후

NAME    BTREE_SPACE     USED_SPACE        PCT_USED 
IDX2      76128                    65366                    86 

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

10-4. 인덱스를 만들 때 사용되는 옵션에 관한 설명으로 옳은 것은? (정답은 두 가지)

a. 인덱스 엔트리의 크기가 테이블에 비해서 작기 때문에 INITRANS를 테이블보다 크게 설정해 주는 것이 좋다.

b. 인덱스 엔트리는 업데이트 빈도가 높으므로 PCTFREE를 작게 설정하는 것이 좋다.

c. PCTUSED의 디폴트 값은 40 이다.

d. 비트맵 인덱스를 만들 때에도 스토리지 파라미터를 지정할 수 있다.

<해설>

INITRANS는 테이블보다 높게 설정하는 것이 바람직하다. 보편적으로 키 값과 ROWID가 저장되는 인덱스 엔트리의 크기가 테이블의 경우보다 작기 때문에 한 블록에 저장되는 건 수가 테이블보다 많다. 따라서 동시에 한 블록에 접근하는 트랜잭션 또한 테이블 보다 많으므로 INITRANS를 높게 잡아 주어야 한다. 디폴트 값은 2 이다.

인덱스 엔트리에는 업데이트 개념이 없기 때문에 PCTFREE는 테이블에 지정할 때와는 의미가 달라서 새로운 인덱스 엔트리가 적절한 블록에 추가될 수 있도록 하기 위한 공간을 확보하는 데 이용된다. 인덱스를 만든 다음에 새로운 데이터가 추가될 가능성이 낮다면 PCTFREE를 조금만 잡아서 블록의 공간 활용도를 높이는 것이 좋지만 인덱스 생성 후에도 새로운 데이터가 많이 추가될 예정이라면 PCTFREE를 높게 설정하여 인덱스 엔트리가 제 위치를 찾아갈 수 있도록 준비해야 한다.

PCTUSED는 인덱스에서 사용할 수 없다는 점도 기억 대상이며 비트맵 인덱스를 만들 때에도 물론 스토리지 파라미터를 지정할 수 있다.

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

데이터 무결성

11-1. 다음 일련의 명령을 실행했을 때 people 테이블에 저장되는 레코드 수는?

CREATE TABLE people

(id NUMBER(4),

name VARCHAR2(20),

CONSTRAINT pk_people PRIMARY KEY(id) DEFERRABLE);

INSERT INTO people VALUES(1, 'James');

INSERT INTO people VALUES(2, 'Scott');

INSERT INTO people VALUES(3, 'Gary');

COMMIT;

SET CONSTRAINTS ALL DEFERRED;

INSERT INTO people VALUES(4, 'Larry');

INSERT INTO people VALUES(1, 'Jimmy');

INSERT INTO people VALUES(5, 'Alan');

COMMIT;

a. 0

b. 2

c. 3

d. 4

e. 5

<해설>

데이터의 무결성(integrity)을 유지하기 위한 방편으로 제약 조건(constraints)이 가장 많이 이용된다. 그런데 제약 조건은 복잡한 비즈니스 룰을 처리하기에는 역부족이기 때문에 종종 데이터베이스 트리거의 도움을 받거나 혹은 응용 프로그램에서 직접 처리하기도 한다. 데이터베이스 트리거는 서버에 생성되므로 관리가 용이하다는 장점이 있고 응용 프로그램에서 처리하는 방법은 관리는 불편하지만 클라이언트 파워를 활용할 수 있다는 특징이 있다.

제약 조건이 적용되는 시기는 두 가지가 있는데 데이터가 추가될 때 마다 할 수도 있고(IMMEDIATE) 나중에 커밋할 때 한 번에 검사할 수도 있다(DEFERRED). people 테이블의 PRIMARY KEY를 만들 때 DEFERRABLE이라고 선언했으므로 이 제약 조건은 SET CONSTRAINTS ALL DEFERRED 명령을 통해서 커밋 시점으로 적용이 연기된다.

처음 세 개의 INSERT 문은 제약 조건에 위배되지 않으므로 정상적으로 수행되어 저장된다. 네 번째와 여섯 번째 INSERT 문에도 이상이 없지만 다섯 번 째 INSERT 문에서 키 값이 중복되므로 COMMIT 명령을 만났을 때 현재의 트랜잭션이 롤백된다. 중복된 데이터만 제외되는 것이 아니라 트랜잭션 전체가 롤백되므로 마지막 세 개의 INSERT 문이 모두 롤백되고 테이블에는 처음 세 개의 레코드만 입력된다.

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

11-2. 제약 조건을 만들 때 인덱스가 자동으로 생성되는 것은?

a. PRIMARY KEY

b. FOREIGN KEY

c. CHECK

d. NOT NULL

e. UNIQUE

<해설>

PRIMARY KEY와 UNIQUE 제약 조건은 새로운 데이터가 입력되었을 때 기존의 데이터와 비교해서 중복 여부를 가려내야 하기 때문에 비교 메커니즘으로 인덱스를 필요로 한다. 그러나 CHECK와 NOT NULL은 기존 데이터와 비교할 필요가 없기 때문에 인덱스를 요구하지 않는다. FOREIGN KEY도 PARENT 데이터와의 비교는 필요하지만 자신과의 비교는 불필요하므로 역시 인덱스가 생성되지 않는다. 그러므로 이들 나머지 제약 조건이 걸린 컬럼에는 필요한 경우 별도로 인덱스를 생성해야 한다.

제약 조건을 만든 다음에 USER_INDEXES를 확인해 보면 인덱스가 함께 만들어졌는지를 알 수 있다.

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

11-3. exceptions 테이블을 생성하는 데 이용되는 스크립트는?

a. exceptions.sql

b. utlexcpt.sql

c. utlexception.sql

d. utlexpt1.sql

e. catexp.sql

<해설>

제약 조건이 걸린 상태에서 데이터를 넣는 것과 일단 데이터를 모두 넣은 다음 제약 조건을 활성화 시키는 것 중 어느 것이 속도가 빠를까? 배치 처리에 해당되는 후자가 훨씬 빠를 것임은 쉽게 짐작할 수 있다. 그래서 대량의 데이터를 넣을 때에는 제약 조건이 DISABLE된 상태에서 작업을 하고 나중에 ENABLE 시키는 방법을 택하게 된다.

그런데 제약 조건이 없는 상태에서 데이터를 넣으면 제약 조건에 위배되는 데이터가 들어올 수도 있는 까닭에 ENABLE 명령에서 에러가 발생할 공산이 크다. 입력 데이터가 얼마나 깨끗한 지가 관건이겠지만 실제로 완벽한 데이터가 제공되는 경우는 행운에 가깝다고 볼 수 있다.

제약 조건에 위배되는 데이터를 찾아서 삭제하거나 변경해 주는 수고를 조금이라도 덜어주기 위한 목적으로 사용되는 것이 exceptions 테이블이다. utlexcpt.sql 스크립트를 실행해서 exceptions 테이블을 만든 다음에

ALTER TABLE people ENABLE PRIMARY KEY EXCEPTIONS INTO exceptions;

와 같이 실행하면 people 테이블의 PRIMARY KEY를 ENABLE 시키면서(VALIDATE도 함께 됨) 제약 조건에 위배되는 레코드 정보가 exceptions 테이블로 저장된다. 물론 제약 조건에 위배되는 데이터가 있으면 이 명령은 에러 처리된다. exceptions 테이블에는 문제를 일으킨 레코드의 ROWID가 기록되므로 이를 이용해서 데이터를 확인한 다음에 처리해 주면 된다.

exceptions라는 테이블 이름은 절대적인 것이 아니므로 원하는 대로 변경해도 괜찮다.

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

데이터 로딩과 재구성

12-1. Direct-Load INSERT를 사용할 것을 지시하는 힌트는? (두 가지)

a.INSERT

b.APPEND

c.LOAD

d.PARALLEL

e.DIRECT

<해설>

Direct-Load INSERT란 'INSERT ... SELECT ...' 구문으로 데이터를 입력할 때 버퍼 캐시를 통하지 않고 직접 블록을 만들어 데이터 파일에 기록함으로써 빠른 속도를 끌어내는 방법이다. 또한 리두 로그 정보를 생성하지 않도록 하거나 병렬 처리도 가능하기 때문에 더욱 성능을 높일 수 있다.

그러나 속도가 빠른 만큼 치러야 할 대가도 있다. 일반적인 INSERT는 HWM(High Water Mark) 이하의 빈 공간을 사용할 수 있지만 Direct-Load INSERT로 처리할 때에는 HWM 아래 쪽의 여유 공간을 활용하지 못한다. 게다가 파티션 테이블이 아닌 경우 병렬 Direct-Load INSERT를 사용하면 HWM 이상의 빈 공간까지 무시하고 새로운 익스텐트를 할당 받기 때문에 공간의 낭비가 더욱 심해진다.

Direct-Load INSERT를 쓰려면 일반적인 경우에는 APPEND, 병렬로 처리할 때에는 PARALLEL 힌트를 사용해서 지시한다. 명령문의 예는 다음과 같다.

INSERT INTO emp SELECT /*+ APPEND */ * FROM new_emp;

ALTER SESSION ENABLE PARALLEL DML;

INSERT /*+ PARALLEL(emp, 5) */ INTO emp

SELECT /*+ PARALLEL(new_emp, 5) */ * FROM new_emp;

SQL*Loader에도 비슷한 기능이 있다. SQL*Loader는 사진과 같은 바이너리 파일도 처리할 수 있지만 많이 이용되지는 않고 주로 텍스트 파일을 데이터베이스에 올리는데 사용되는 프로그램이다. 외부 파일에 있는 데이터를 오라클에 입력하기 위한 수단으로 SQL*Loader의 Direct Path 속도를 당해낼 상대는 없다. 개인적으로는 오라클 제품 중에서 가장 완성도가 높은 프로그램으로 SQL*Loader를 꼽고 싶다.

SQL*Loader를 실행할 때에는 Conventional Path와 Direct Path의 두 가지 방법을 선택할 수 있다. Conventional Path는 평범한 INSERT 문을 이용하여 데이터를 입력하는 방식이고 Direct Path는 Direct-Load INSERT와 유사하게 직접 데이터 블록을 만들어 기록하는 방식이다. 데이터가 적은 경우에는 차이를 느낄 수 없지만 많을 때에는 Direct Path의 속도가 월등히 빠르다.

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

12-2. 익스포트의 모드를 지정할 때 사용되는 옵션이 아닌 것은?

a.TABLES

b.OWNER

c.TABLESPACES

d.DATAFILES

e.FULL

<해설>

익스포트를 할 때에는 데이터베이스 전체(FULL), 사용자(OWNER), 테이블과 파티션(TABLES) 중에서 어떤 것을 익스포트 할 것인지를 지정할 수 있고 추가적으로 TABLESPACES 파라미터를 통해서 Transportable Tablespace를 지정할 수 있다. 단, 이 때에는 제약 조건, 트리거 등의 데이터베이스 정보가 들어 있는 메타 데이터만 익스포트 되므로 데이터파일을 별도로 복사해와야 한다. DATAFILES는 Transportable Tablespace를 임포트 할 때 사용하는 파라미터이다.

Transportable Tablespace가 등장하기 전에는 왜 테이블스페이스 별로 익스포트를 받을 수 없냐는 항의 섞인 질문을 하는 사용자가 많았다. 다행히 Transportable Tablespace 덕분에 그런 물음 앞에 당당해 질 수 있게 되었지만 몇 가지 제약 사항 때문에 여전히 불씨가 남아 있다. 이에 관해서는 마지막 문제에서 다루기로 한다.

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

12-3. 다음과 같은 물리적 구조를 갖는 테이블을 디폴트 옵션으로 익스포트 한 다음에 다른 데이터베이스에 임포트 했을 때 생성되는 INITIAL 익스텐트의 크기는?

익스텐트 번호 크기

0 100K

1 200K

2 200K

3 200K

HWM = 400K

a. 100K

b. 200K

c. 400K

d. 500K

e. 700K

<해설>

익스포트한 덤프 파일은 바이너리 포맷이긴 하지만 에디터로 열어 보면 테이블을 포함하여 각종 객체를 만드는 SQL 명령을 눈으로 확인할 수 있다. 이런 방법으로 직접 INITIAL 값을 볼 수 있는데 이 것은 COMPRESS 파라미터에 따라 달라진다.

COMPRESS=N 상태로 익스포트를 하면 스토리지 파라미터는 원래의 테이블 것을 그대로 사용한다. 하지만 COMPRESS=Y(디폴트)로 익스포트를 하면 INITIAL 값은 테이블이 할당받은 익스텐트의 전체 크기로 설정된다. 이렇게 INITIAL 값을 크게 만드는 이유는 익스텐트의 개수가 많으면 성능이 떨어지기 때문에 적어도 현재 저장되어 있는 데이터는 하나의 익스텐트에 수용할 수 있도록 하기 위함이다.

그러다 보니 테이블의 크기가 큰 경우 새로운 INITIAL 값이 과도하게 커지기 때문에 그에 적합한 연속된 여유 공간이 없어서 임포트 시에 테이블을 생성조차 하지 못하고 에러가 발생하는 경우가 상당히 많다. 따라서 평소에는 COMPRESS 파라미터를 Y 상태로 사용하는 것이 좋지만 때때로 N으로 설정할 필요가 있으며 이미 COMPRESS=Y로 익스포트를 받았는데 INITIAL 값이 너무 커서 곤란을 겪는다면 수작업으로 테이블을 먼저 생성한 다음에 데이터를 넣어야 한다.

COMPRESS 파라미터가 데이터의 크기를 압축하는 기능이라고 잘못 이해하는 분이 없기 바란다.

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

12-4. 테이블 스페이스를 트랜스포트하기 위해서 두 데이터베이스 사이에 일치해야 할 조건이 아닌 것은?

a.블록 크기

b.데이터베이스 이름

c.문자 집합

d.플랫폼 호환성

e.SID

<해설>

다른 데이터베이스의 테이블스페이스를 통째로 가져오는 Transportable Tablespace 기능은 기술적으로는 별 것 아닌 듯 하지만 시간에 쫓기는 DBA에게는 눈물겹게 고마운 존재다. 이 기능을 필요로 하는 상황이 자주 발생하지는 않더라도 다른 곳에서 가져온 테이블을 임포트 하면서 밤을 지새어 본 사람이라면 그 가치를 충분히 인정하리라 믿는다. 임포트와는 속도면에서 비교가 되지 않는다.

물론 아무 테이블스페이스나 가져와서 붙일 수 있는 것은 아니다. 데이터 파일의 물리적 구조가 호환이 되어야 하므로 플랫폼 간의 호환성이 우선되어야 하고 오라클 블록의 크기가 같아야 하며 문자 집합(character set)도 동일해야 한다. 데이터베이스 이름이나 SID는 달라도 상관 없다.

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

사용자 및 리소스 관리

13-1. 일정 시간 동안 아무런 작업을 하지 않을 때 자동으로 세션을 종료시키기 위해서 사용되는 리소스 파라미터는?

a. CONNECT_TIME

b. CPU_PER_SESSION

c. IDLE_TIME

d. KEEP_ALIVE

e. LOGICAL_READS_PER_SESSION

<해설>

한 유저가 너무 복잡한 SQL문을 실행해서 CPU 파워를 독점한다거나 엄청난 분량의 데이터를 조회하여 I/O를 포화시키는 일이 발생하면 곤란하므로 오라클에서는 이를 방지하기 위해서 프로파일(profile)이란 리소스 관리 기능을 제공한다.

프로파일은 유저 별로 할당하게 되는데 CPU 사용 시간, I/O 규모 등을 비롯해서 최대 접속 시간, 패스워드 유효 기간 등의 각종 자원 사용 제한 및 규칙을 제정하고 있다.

유저를 만들 때 어떤 프로파일을 사용할 것인지를 지정할 수 있으며 아무 것도 지정하지 않으면 DEFAULT 라는 프로파일을 사용하게 된다. DEFAULT 프로파일은 오라클이 자동으로 생성하는 프로파일로 기본적으로 리소스를 무제한으로 사용하도록 설정되어 있다.

리소스 사용을 제한하기 위해서는 먼저 init.ora에서 RESOURCE_LIMIT=TRUE로 설정하거나 아니면 ALTER SYSTEM SET RESOURCE_LIMIT=TRUE 명령으로 설정을 변경해 주어야 한다. 그렇지 않으면 프로파일을 이용해서 리소스 사용을 제한해도 효력이 없다.

일정 시간동안 아무런 작업이 없을 때 세션을 종료시키려면 IDLE_TIME 파라미터를 사용한다. 이 파라미터의 값은 분 단위로 설정되며 지정된 기간동안 아무런 작업이 없으면 세션을 강제로 해제시킴으로써 잡고 있던 리소스를 풀어준다. 참고로 CONNECT_TIME도 분 단위로 지정하지만 CPU_PER_SESSION의 단위는 1/100초 이므로 혼동하기 쉽다.

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

13-2. SYSTEM 테이블스페이스에 저장되어 있던 SCOTT 유저의 테이블을 익스포트 받은 다음에 이 테이블을 삭제하고 SYSTEM 테이블스페이스에 대한 SCOTT 유저의 쿼타를 0으로 설정하였다. 다시 이 테이블을 임포트 할 때 발생하는 현상으로 옳은 것은? 단, SCOTT의 디폴트 테이블스페이스는 USERS, 쿼타는 UNLIMITED이고 UNLIMITED TABLESPACE 권한은 갖고 있지 않다.

a. SYSTEM 테이블스페이스에 쿼타가 없으므로 임포트는 실패한다.

b. USERS 테이블스페이스에 임포트된다.

c. SYSTEM 테이블스페이스에 임포트된다.

d. 어느 테이블스페이스에 임포트될지 예측할 수 없다.

<해설>

어떤 테이블스페이스에 객체를 만들거나 익스텐트를 할당 받으려면 UNLIMITED TABLESPACE 라는 권한이 없는 한 반드시 해당 테이블스에 충분한 쿼타(quota)를 가지고 있어야 한다. 쿼타는 특정한 크기 만큼 지정할 수도 있고 무한대로 설정할 수도 있다. 보통 습관적으로 유저를 만들고 난 다음에 CONNECT와 RESOURCE 롤(role)을 부여하는데 RESOURCE 롤에 UNLIMITED TABLESPACE 권한이 포함되어 있기 때문에 알게 모르게 이 권한이 사용자에게 부여되는 경우가 많다.

테이블을 임포트 할 때에는 먼저 그 테이블이 원래 있던 테이블스페이스에 테이블을 생성하려고 시도한다. 일반적인 CREATE TABLE 명령에서는 쿼타가 없는 테이블스페이스에 테이블을 생성하려고 하면 에러가 발생하고 끝나지만 임포트에서는 원래의 테이블스페이스에 쿼타가 없다고 바로 테이블 생성이 중단되는 않고 한번 더 디폴트 테이블스페이스에 테이블을 만들려고 시도한다. 만약 디폴트 테이블스페이스에도 쿼타가 없다면 테이블은 만들어 지지 않는다.

이 문제에서는 먼저 SYSTEM 테이블스페이스에 테이블 생성을 시도하지만 쿼타가 없으므로 결국 USERS 테이블스페이스에 테이블이 생성된다.

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

13-3. 다음과 같은 물리적 구조를 갖는 테이블을 디폴트 옵션으로 익스포트 한 다음에 다른 데이터베이스에 임포트 했을 때 생성되는 INITIAL 익스텐트의 크기는?

정체를 알 수 없는 LARRY라는 유저가 만들어져 있고 이미 여러 개의 테이블도 생성하였음을 발견하였다. 현재 누군가가 이 유저로 접속해 있는 상태에서 LARRY 유저를 삭제하려면 어떻게 해야 하는가?

a.DROP USER larry를 실행한다.

b.DROP USER larry CASCADE를 실행한다.

c.LARRY 유저 세션을 모두 끊은 다음에 DROP USER larry를 실행한다.

d.LARRY 유저 세션을 모두 끊은 다음에 DROP USER larry CASCADE를 실행한다.

e.LARRY 유저 세션을 모두 끊은 다음에 DROP USER larry INCLUDING CONTENTS를 실행한다.

<해설>

유저를 삭제할 때에는 DROP USER 유저명 CASCADE 명령을 이용한다. CASCADE 옵션을 주지 않으면 유저가 테이블과 같은 객체를 가지고 있는 경우 에러가 발생하도록 안전 장치가 되어 있다. 간혹 유저를 삭제하면 그 유저가 가지고 있던 테이블은 어떻게 되는지를 궁금해하는 분들이 있는데 소유자가 없는 테이블이란 있을 수 없으므로 함께 사라진다. 단, CASCADE 옵션을 명시해 주어야 한다. INCLUDING CONTENTS 옵션은 테이블스페이스를 삭제할 때 내용물이 있는 경우 사용된다.

그리고 유저를 삭제할 때 해당 유저로 접속중인 세션이 있다면 에러가 발생하므로 먼저 그 세션을 찾아서 끊은 다음에 유저를 삭제해야 한다.

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

13-4. 오라클에서 기본적으로 제공하는 패스워드 검증 루틴에 부합되는 패스워드는?

a.tiger

b.wild$cat

c.#sharp

d.49#$

e.m700$

<해설>

운영 체제의 암호 관리에는 많은 노력을 기울이면서도 정작 중요한 데이터가 집결되어 있는 오라클의 암호에는 별 신경을 쓰지 않는 경우가 많다. 오라클에서도 패스워드 관리를 강화하기 위해서 다양한 기능이 제공되는데 특히 아무 패스워드나 사용하지 못하도록 하는 검증 루틴이 준비되어 있으며 직접 만들 수도 있다.

기본적으로 제공되는 패스워드 검증 루틴은 utlpwdmg.sql 스크립트에 들어 있으며 패스워드가 다음과 같은 요건을 만족하는지 확인한다.

1. 길이는 4자 이상

2. 유저 아이디와 같으면 안됨

3. 적어도 하나 이상의 알파벳, 숫자, 특수문자를 포함해야 함

4. 이전의 패스워드와 최소 3자 이상 달라야 함

이전의 패스워드나 유저 아이디는 알 수 없으므로 논외로 하면 보기에서는 m700$만 이 조건을 만족시킨다.

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

권한과 롤

14-1. SELECT ANY TABLE과 같은 ANY 권한을 가진 유저가 SYS 소유의 객체에 접근할 수 없도록 할 때 사용되는 초기화 파라미터는?

a. OS_ROLES

b. O7_DICTIONARY_ACCESSIBILITY

c. COMPATIBLE

d. REMOTE_OS_ROLES

e. SQL92_SECURITY

<해설>

권한과 롤에 대해서는 Introduction to Oracle 과목에서 이미 다룬 적이 있으므로 일반적인 내용은 건너뛰기로 한다.

Oracle7에서는 SELECT ANY TABLE 권한을 가지고 있으면 남의 테이블을 모두 조회할 수 있을 뿐 아니라 딕셔너리를 포함한 SYS 소유의 테이블도 볼 수 있다. 그러나 일일이 객체와 유저별로 권한을 주기가 번거롭기 때문에 편의상 SELECT ANT TABLE과 같은 강력한 시스템 권한을 부여하는 경우가 많다.

딕셔너리에 절대로 공개할 수 없는 정보가 들어 있는 것은 아니지만 굳이 딕셔너리까지 펼쳐 보이면서 위험을 감수할 필요는 없기 때문에 초기화 파라미터를 이용해서 ANY 권한으로부터 SYS 스키마를 보호할 수 있게 되었다. O7_DICTIONARY_ACCESSIBILITY=FALSE로 설정하면 ANY 권한을 가져도 SYS 소유의 객체를 건드릴 수 없으며 필요하다면 개별적으로 권한을 부여해야 한다.

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

14-2. 다음 명령 중에서 잘못된 것은? (두 가지)

a. SET ROLE ALL EXCEPT RESOURCE;

b. REVOKE ALL ON emp FROM PUBLIC;

c. GRANT TRUNCATE ON emp TO scott;

d. GRANT SELECT,UPDATE,DELETE ON emp TO my_role WITH GRANT OPTION

e. REVOKE READ ON DIRECTORY tmp_dir FROM scott;

<해설>

a) RESOURCE를 제외한 모든 롤을 활성화 시킨다(O).

b) 전체 유저(PUBLIC)로부터 emp 테이블에 대한 권한을 모두 철회한다(O).

c) TRUNCATE 권한을 별도로 줄 수는 없다(X).

d) 롤에 권한을 줄 때에는 WITH GRANT OPTION은 사용할 수 없다(X).

e) tmp_dir 디렉토리에 대한 읽기 권한을 scott로부터 철회한다(O).

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

14-3. SCOTT 에게 EXP_FULL_DATABASE롤을 GRANT 했을 때 다음 중에서 내용의 변화를 일으키는 딕셔너리는? (세 가지)

a. USER_TAB_PRIVS_MADE

b. USER_TAB_PRIVS_RECD

c. USER_ROLE_PRIVS

d. SESSION_ROLES

e. SESSION_PRIVS

<해설>

scott가 어떤 롤을 받았는지는 USER_ROLE_PRIVS에서 확인할 수 있다. 롤은 어느 누구의 소유도 아니므로 이 뷰는 scott가 만든 롤을 보여주는 것이 아니라 부여 받은 롤을 알려주는 것임을 유의해야 한다.

SESSION_ROLES는 현재의 세션에서 이용 가능한 롤에 대한 정보이므로 여기에도 EXP_FULL_DATABASE 롤에 관한 내용이 추가되며 SESSION_PRIVS에서는 롤을 통해서 받은 각각의 권한을 조회해 볼 수 있다.

USER_TAB_PRIVS_MADE와 USER_TAB_PRIVS_RECD는 주고 받은 객체 권한에 대한 것이므로 본 문제와는 관련이 없다.

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

NLS (National Language Support)

15-1. . NLS_LANG 파라미터를 설정할 수 있는 방법이나 위치는?

a. 초기화 파일(init.ora)

b. 환경 변수

c. ALTER SESSION 명령

d. ALTER SYSTEM 명령

e. ALTER DATABASE 명령

<해설>

한글이나 한자, 일본어와 같이 한 바이트로 문자를 표현할 수 없는 곳에서는 아직도 가끔 NLS가 이슈가 되고 있는데 아시아 시장의 확대로 웬만한 소프트웨어는 NLS를 기본적으로 지원하고 있으며 오라클도 NLS에 관한 별도의 매뉴얼을 제공하는 등 사용자 지원을 강화하고 있다.

NLS에는 코드 차원의 문자 집합에서부터 사용 언어, 날짜 표기 방법, 소팅 순서 등의 각 국가별 관습이 얽혀 있기 때문에 생각만큼 간단한 문제가 아니다.

NLS 파라미터는 여러 곳에서 지정할 수 있다. init.ora 초기화 파일에 넣을 수도 있고 윈도우의 레지스트리나 유닉스의 쉘 환경변수에 설정할 수도 있으며 데이터베이스에 접속한 상태에서는 ALTER SESSION 명령으로 바꿀 수도 있다. 그러나 각 경우에 지정할 수 있는 NLS 파라미터가 제한되어 있는데 NLS_LANG은 유독 환경 변수나 레지스트리에만 넣을 수 있다.

사실 NLS_LANG 외의 나머지 NLS 파라미터는 그다지 자주 사용되지는 않는다. 여러 개를 사용하면 서로 중복되는 부분이 있어서 혼란스러우므로 한 번에 세 가지를 지정할 수 있는 NLS_LANG만을 가지고 버티는 것이 여러 모로 편리하다. NLS_LANG은 AMERICAN_AMERICA.US7ASCII와 같은 형태로 삼등분 되어 있다. 맨 처음은 LANGUAGE 파트로 에러 메시지 등을 표시할 때 사용되는 언어를 결정하고 그 다음의 TERRITORY 파트는 지역별 특성에 따른 날짜나 숫자 등의 포맷을 지정한다. 마지막은 문자 집합이다.

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

15-2. 여러 곳에 설정된 NLS 파라미터 간의 상충되는 부분이 있을 때 적용되는 우선 순위를 올바르게 나열하라(주관식).

a. 환경 변수

b. ALTER SESSION 명령

c. 초기화 파일(init.ora)

d. SQL 함수에서 직접 명시

<해설>

NLS 파라미터는 보기와 같이 네 곳에서 지정할 수 있다. 앞의 문제에서 설명한 것 외에 SQL 함수가 하나 더 추가되었는데 SQL 함수에 따라서 NLS 파라미터를 직접적으로 명시할 수가 있으며 이 때 지정한 값이 가장 우선적으로 사용된다. 예를 들면 다음과 같다.

TO_CHAR(sysdate, 'YYYY/MON/DD', 'NLS_DATE_LANGUAGE = AMERICAN')

두 번째 우선 순위는 ALTER SESSION 명령에서 지정한 값이며 그 다음이 환경 변수이고 초기화 파일에 지정된 파라미터의 우선 순위가 가장 낮다.

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

15-3. 문자 집합(character set)의 변경에 관한 설명으로 옳지 않은 것은?

a. ALTER DATABASE CHARACTER SET 명령을 이용한다.

b. 새로운 문자 집합이 이전 문자 집합을 포함해야(superset) 한다.

c. 내셔널 문자 집합(national character set)도 변경 가능하다.

d. WE8ISO8859P1에서 US7ASCII로 변경할 수 있다.

<해설>

오라클을 사용하는 국내 사이트에서 가장 많이 볼 수 있는 문자 집합은 US7ASCII과 KO16KSC5601이고 본의 아니게 WE8ISO8859P1을 사용하기도 한다. US7ASCII는 7비트를 사용하여 128개의 문자를 표현할 수 있는 가장 전통적인 문자 집합이고 WE8ISO8859P1은 한 비트 많은 8비트를 이용하여 영어를 포함한 프랑스어, 독일어, 스페인어 등의 유럽 문자를 지원한다. KO16KSC5601은 한글은 두 바이트 완성형 한글 코드를, 영문은 한 바이트를 이용하는 가변 길이 문자 집합이다.

데이터베이스를 만들 때에는 문자 집합과 내셔널 문자 집합(national character set)을 각각 지정할 수 있는데 서로 같게 만들 수도 있고 다른 것으로 사용해도 된다. 내셔널 문자 집합은 NCHAR, NVARCHAR2, NCLOB 컬럼에 저장할 때 사용되는 문자 집합으로 KO16KSC5601FIXED처럼 길이가 일정한 멀티 바이트 문자 집합을 이용하면 LIKE 문과 같은 텍스트 처리 속도가 한결 빠르기 때문에 유용하게 쓸 수 있다. 또한 길이가 두 바이트로 고정적이므로 프로그래밍이 편한 일면도 있다. 오라클은 여러 문자 집합의 장점을 살릴 수 있도록 두 가지를 동시에 지원한다.

Oracle7에서는 데이터베이스의 문자 집합을 변경하는 공식적인 방법은 없었고 비공식적인 백 도어만 존재했다. 그러나 현재는 엄연히 ALTER DATABASE CHARACTER SET 또는 ALTER DATABASE NATIONAL CHARACTER SET 이라는 명령이 지원되므로 떳떳하게 사용할 수 있다.

그렇다고 원하는 대로 문자 집합을 바꿀 수 있는 것은 아니다. 변경하고자 하는 문자 집합이 이전의 문자 집합을 포함하는 수퍼 집합(superset)이어야 하며 이 관계가 완전하지 않을 경우 데이터의 손상이 발생할 수 있다. 오라클에서 수퍼 집합이 아닌 경우에는 변환 명령을 에러 처리하지만 만약을 위해서 작업 전에 백업을 하는 것은 필수적이다. 문자 집합을 바꿀 때에는 익스포트/임포트를 이용해서 데이터베이스를 새롭게 만드는 것이 고전적인 정석이지만 엄청난 시간이 걸리기 때문에 손쉬운 방법의 유혹을 떨쳐버리기 힘들다. 손쉬운 방법을 사용하는 대신 백업 정도의 수고는 감수할만 하다.

WE8ISO8859P1은 8bit를 사용하고 US7ASCII는 7bit를 사용한다. US7ASCII에서 WE8ISO8859P1으로의 변경은 가능하지만 역은 성립되지 않는다.

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