많은 DBA 및 개발자는 새로운 기능을 습득하기 위해 현재 것은 물론 새로운 기능을 공부한다. 하지만 꾸준한 공부는 누구에게나 힘들며, 그 힘든 일을 꾸준히 하면서 얻은 지식을 제대로 활용하고 있다고 말할 수 있을지 모르겠다.

물론 이유는 있다. 안정적일까, 버그는 없을까 등의 걱정과 두려움이 따르는 건 사실이다. 위험 부담을 최소화하고 안정적인 운영을 해야 하는 것은 당연하다. 하지만 이미 해당 기능이 많이 퍼지고 안정적으로 운영하는 곳이 많음에도 불구하고 해당 기능을 적용시키지 않는 곳이 많다.

DBMS가 변하지 않는다고 해도 사람은 계속 변한다. 알고 있었던 것이 잊혀지기도 하고 공부를 통해 모르던 것을 알게 되기도 한다. 간단한 하나의 예를 들어 보자.

A 회사의 홍 군은 오라클 11g를 처음 설치하고 계정을 만들었다. 그리고 계정에 접속하려고 했는데 방금 만든 계정임에도 비밀번호가 맞지 않아 Connect가 되지 않는다고 나왔다.

그래서 잘못 눌렀을지도 모른다는 생각에 ALTER USER 명령어를 이용해 비밀번호를 바꾸어도 마찬가지였다. 왜일까?

11g에서는 SEC_CASE_SENSITIVE_LOGON 서버 파라미터에 의해 대소문자를 구분하기 때문이었다. 방금 만들었던 계정이 로그인되지 않으면 난감할 것이다.

DB LINK를 이용해 10g 시스템 1개와 9i 시스템 2개가 서로 통신하고 있었는데 메인 DB 10g가 11g로 업그레이드된 경우를 보자. 11g 업그레이드 이후에 10g에서 11g로의 DB LINK를 이용한 쿼리 실행 시 유저계정이나 비밀번호가 맞지 않다는 에러가 발생할 수 있다.

비슷한 경우를 보자. A 회사의 홍군은 11g를 처음으로 운영하고 있다. 잘 운영하고 있던 것이 갑자기 업무가 마비되어 전화가 폭주하는 일이 생겼다. 왜였을까?

계정을 생성한 지 180일이 지나 해당 계정의 비밀번호 사용 기간이 지났기 때문이다. 11g R2부터는 DEFAULT PROFILE이 변경되어 PASSWORD_LIFE_TIME 180일이 default 이다.

그러므로 ALTER PROFILE을 이용해 원하는 설정을 해야 할 것이다.

ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

위 명령어를 수행한다면 PASSWORD_LIFE_TIME 값은 10g와 동일하게 설정되는 것이다. 11g에 대해 알면 간단한 부분이지만 알지 못하면 크게 당황할 수밖에 없는 일이다.

다른 경우를 보자. 우리는 항상 백업을 한다. 솔루션을 사용하는 업체도 있지만 비싼 솔루션을 사용하지 못하는 곳도 많다. 이에 EXPORT를 이용해 백업하는 곳이 많다.

그런데 오라클 10g 이상을 사용하지만 DATAPUMP를 사용하지 않는 곳이 많다. DATAPUMP를 많은 곳에서 사용하고 있지만 EXPORT를 이용해 예전부터 문제없이 사용해왔기 때문이다.

DATAPUMP라는 기능을 알고 많이 사용하고 있음을 알지만 예전부터 문제없이 사용해 온 기능이라고 해서 바꾸지 않는다면 비싼 라이선스 비용을 주고 좋은 기능을 사용하지 않는 것 밖에 되지 않는다.

더욱 중요한 것은 11g에서는 오라클의 지원이 중단되었으므로 사용하는데 위험 요소가 있게 되었다. 그리고 DATAPUMP 기능을 이용하면 ENCRYPTION_PASSWORD 옵션을 사용해 DATA PUMP로 받은 파일에 비밀번호를 걸 수 있다.

마치 로그인해야 하는 것처럼 비밀번호를 맞게 넣어야만 IMPORT할 수 있는 것이다.

10g 버전은 전체 덤프파일을 암호화하는 것이 아니라 Transparent Data Encryption의 적용을 받는 컬럼만을 암호화했다.

하지만 이것이 11g가 되면 DATAPUMP를 이용해 받은 파일에 비밀번호를 거는 것은 물론, ENCRYPTION 옵션을 이용해 어느 부분을 암호화할 것인지 결정하고 ENCRYPTION_ALGORITHM 옵션을 이용해 암호화 알고리즘을 결정할 수 있다.

알고 있어도 사용할 것인지 사용하지 않을 것인지는 운영하는 사람의 몫이다.

간단한 이관의 예

운영 DB에서 테스트 DB로 DB LINK를 이용해 테이블 복제를 빠르게 실행하기 위해 각 세션에서 작업되는 테이블 세그먼트의 크기를 비슷하도록 쪼개어 여러 개의 세션을 동시에 실행시키는 스크립트를 생성했다.

그리고 DBA_SEGMENTS의 BYTES필드를 이용해 6개로 쪼개어 작업하는 크기가 거의 동일하도록 만들었다. 수행을 한 뒤 6개의 세션이 거의 비슷한 수행시간을 보이고 있어 원하는 대로 작업이 진행되었음을 확인할 수 있었다.

그러나 이행 작업을 확인하는 과정에서 테이블이 생성되지 않았음을 확인했다. 확인해 보니 DBA_TABLES 테이블에는 해당 테이블의 정보가 존재하지만 DBA_SEGMENTS 테이블에는 해당 테이블에 대한 정보가 존재하지 않았기 때문이다.

왜 이런 것인가?

이유는 11g의 Deferred Segment Creation 기능에 의한 것이다.

DEFER RED_SEGMENT_CREATION 서버 파라미터 (DEFAULT : TRUE)에 의해 테이블 생성 시 데이터가 존재하지 않으면 SEGMENT를 바로 생성하는 것이 아니라 데이터가 들어와야 SEGMENT가 만들어지는 것이다.

• - CREATE TABLE 명령어 사용 시 SEGMENT CREATION DEFERRED 옵션이나 SEGMENT CREATION IMMEDIATE 옵션을 사용해 직접 제어할 수도 있으며 파라미터를 변경할 수도 있다.
• - CREATE TABLE A (A NUMBER(2)) SEGMENT CREATION DEFERRED를 이용해 생성한다면 DBA_SEGMENTS 테이블에서 해당 테이블을 볼 수 없을 것이다.
• - CREATE TABLE A (A NUMBER(2)) SEGMENT CREATION IMMEDIATE를 이용해 생성한다면 DBA_SEGMENTS 테이블에서 해당 테이블을 바로 조회할 수 있을 것이다.

운영 환경이 변하면 운영하는 자신도 그에 대응할 수 있어야 할 것이다. 그럼 다른 예를 들어보자.

10g RAC에서 INTERCONNECT 부하를 미연에 방지하기 위해 INSTANCE_GROUPS 서버 파라미터와 PARALLEL_INSTANCE_GROUP 서버 파라미터를 이용해 PARALLEL PROCESS에 의한 INTERCONNECT 부하를 PARALLEL PROCESS의 작업 노드로 제한할 수 있었다.

여러 노드에 PARALLEL PROCESS를 많이 띄운다 해도 PARALLEL PROCESS에 의한 INTERCONNECT 부하가 크다면 오히려 더 느려질 수 있기 때문이다.

11g RAC에서는 어떤가? 10g와 마찬가지로 PARALLEL PROCESS에 의한 INTERCONNECT 부하를 미연에 방지하기 위해 INSTANCE_GROUPS 서버 파라미터와 PARALLEL_INSTANCE_GROUP 서버 파라미터를 설정한다면 STARTUP 시에 ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance라는 에러를 만나게 된다.

11g를 공부하지 않았다면 당황스러울 수밖에 없다. 10g까지 잘 사용하고 있던 서버 파라미터인데 11g로 변경되면서 INSTANCE_GROUPS 설정에 의해 해당 에러가 나오게 되는 것이다.

11g부터는 서비스를 이용해 PARALLEL 작업을 제어하기 때문이다. 하지만 에러가 발생한다고 사용할 수 없는 것은 아니다.

예전 호환성을 위해 해당 서버 파라미터의 기능이 유지되고 있는 것이다. 하지만 STARTUP 시 에러를 일으키는 deprecated된 서버 파라미터를 사용할 것인가?

성능과 관련된 예

A 회사의 DBA 홍 군은 요즘 튜닝에 관심이 있어 공부를 하고있었다. AWR을 이용해 문제가 있거나 시스템의 리소스 사용에서 큰 부분을 차지하는 SQL을 찾을 수 있기에 주기적으로 AWR 기능을 이용해 REPORT를 저장하기로 했다.

하지만 현재 홍 군의 시스템은 CPU를 60~70% 정도 사용하지만 아무런 문제없이 운영되고 있다. 이러한 이유로 홍 군은 공부는 하지만 AWR REPORT를 이용해 어떠한 작업도 하지 않는다.

아무런 문제가 없다고 방치해 두는 것이 맞는가? AWR REPORT를 이용해 성능을 개선시키고 해당 시스템의 수명을 증가시킬 수 있다면 수백에서 수천만 원이 들지 모르는 서버 증설 혹은 교체가 필요 없어 지거나 수년 늦춰질 수 있다.

성능을 위해 인덱스를 활용해 ORDER BY를 제거하는 튜닝을 하는 경우가 많다. ORDER BY 자체를 SQL에서 삭제했다면 INDEX를 잘 관리한다고 해도 11g에서는 결과의 순서가 맞지 않는 경우가 생긴다.

오라클에서는 New Implementation for Nested Loop Joins라고 소개한다. 이것을 알기 위해 9i에 나온 table prefetch를 기억해 보자.

이것의 원리는 single block I/O 요청에 의한 physical read 시 block을 미리 읽는 작업을 한다는 것이다.

그런데 여기서 중요한 것은 인덱스 SCAN의 성능은 향상되었지만 기존에는 인덱스를 활용해 NESTED LOOP 조인이용 시 해당 인덱스의 정렬된 순서대로 데이터가 나왔는데 이러한 기능에 의해 정렬되지 않은 채로 데이터가 나올 가능성이 생겼다는 것이다.

10g까지는 잘 되었는데, 11g에서는 데이터가 정렬될 때도 있고 되지 않을 때도 있다. 버그인가라고 생각할 수 있겠지만 11g에 대한 지식이 있다면 원인을 바로 알 수 있다.

해당 기능이 실행될 때 OUTLINE을 보면 NLJ_BATCHING이라는 힌트를 볼수 있다.