DBMS 1

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

관리 기능

DBMS 1
Oracle 가이드
10g, DBA를 위한 신기능
관리 기능
작성자
dataonair
작성일
2021-02-17 16:57
조회
928

관리 기능

ASM 커맨드라인 툴

Oracle Database 10g Release 1에서 처음 소개된 Oracle Automatic Storage Management (ASM, 본 시리즈의 제 1 부 참고)는 오라클 데이터파일의 관리를 위해 사용되는 새로운 형태의 파일시스템입니다.

ASM은 SQL 커맨드 또는 Oracle Enterprise Manager 인터페이스를 통해 관리되며, SQL 인터페이스 또는 GUI를 통해 확인 가능합니다. 이러한 관리 방식은 대부분의 DBA들에게는 아무런 문제가 없지만, SQL에 익숙하지 않은 시스템 관리자에게는 문제가 될 수 있습니다. 또 DBA의 입장에서는 DBA가 아닌 관리자들에게 Oracle Enterprise Manager에 대한 접근을 개방하는 것이 꺼려질 수 있습니다.

Oracle Database 10g Release 2에 추가된 새로운 ASM 커맨드라인 툴이 이러한 고민을 해결해 줄 수 있습니다. asmcmd라는 이름의 이 툴은, ASM 디스크그룹에 저장된 데이터파일의 관리를 위해 활용됩니다. 이 툴은 perl을 기반으로 구현되었으며, 따라서 perl의 실행경로가 미리 설정되어 있어야 합니다. perl 실행경로가 올바르게 정의되지 않았다면, perl 프로그램이 존재하는 디렉토리를 위한 소프트 링크를 생성하거나, asmcmd 파일을 수정하여 perl 경로를 새롭게 정의해 주어야 합니다.

이때 ORACLE_SID는 (서버에서 실행되는 실제 데이터베이스 인스턴스가 아닌) ASM 인스턴스(일반적으로 “+ASM”으로 표시됩니다)를 사용해야 합니다: 커맨드는 다음과 같은 방법으로 호출됩니다.

asmcmd -p

-p 옵션이 명시된 경우, 프롬프트 상에 현재 경로가 표시됩니다.

이제 몇 가지 간단한 명령을 실행해 봅시다. 커맨드라인 프롬프트(ASMCMD >)가 표시된 후 ls를 입력하여 마운트된 디스크그룹을 확인합니다.

ASMCMD [+] > ls
DGROUp1/
DGROUp10/
DGROUp2/
DGROUp3/
DGROUp4/
DGROUp5/
DGROUp6/
DGROUp7/
DGROUp8/
DGROUp9/

이 명령을 통해 ASM 인스턴스 (DGROUp1~DGROUp10)에 생성되고 마운트된 모든 디스크그룹의 내역을 확인할 수 있습니다.

이제 디스크그룹 DGROUp1을 확인해 봅시다. 디스크그룹을 변경할 때에는, 디렉토리를 변경할 때처럼 cd 커맨드를 사용합니다.

ASMCMD [+] > cd dgroup1

또 cd ..를 입력하면 부모 디렉토리로 이동할 수도 있습니다. 이제, 어떤 파일이 디스크그룹에 생성되었는지 확인해 봅시다.

ASMCMD [+dgroup1] > ls
ORCL/

디스크그룹에 새로운 디렉토리 “ORCL”이 추가되었습니다. 이름 뒤에 슬래시(/) 기호가 붙어 있는 것으로 ORCL이 디렉토리임을 알 수 있습니다. cd 명령으로 해당 디렉토리로 이동하고 ls 명령으로 컨텐트를 확인합니다.

ASMCMD [+dgroup1] > cd orcl
ASMCMD [+dgroup1/orcl] > ls
CONTROLFILE/
pARAMETERFILE/
control01.ctl => +DGROUp1/ORCL/CONTROLFILE/Current.256.551928759
spfileorcl.ora =< +DGROUp1/ORCL/pARAMETERFILE/spfile.257.551932189
ASMCMD [+dgroup1/orcl] >

cd, ls 명령 이외에도 rm (디렉토리/파일의 삭제), mkdir (디렉토리의 생성), find (파일/디렉토리 찾기) 등의 UNIX 스타일 명령이 사용 가능합니다.

그 밖에 유용한 커맨드가 아래와 같습니다:

lsdg(“list diskgroup")- ASM 인스턴스에 의해 마운트된 디스크를 확인할 수 있습니다.

ASMCMD [+] > lsdg
State Type Rebal Unbal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB
Offline_disks Name
MOUNTED EXTERN N N 512 4096 1048576 100 40 0 40 0 DGROUp1/
MOUNTED EXTERN N N 512 4096 1048576 100 33 0 33 0 DGROUp10/
MOUNTED EXTERN N N 512 4096 1048576 100 41 0 41 0 DGROUp2/
MOUNTED EXTERN N N 512 4096 1048576 1000 787 0 787 0 DGROUp3/
MOUNTED EXTERN N N 512 4096 1048576 1000 537 0 537 0 DGROUp4/
MOUNTED EXTERN N N 512 4096 1048576 1000 928 0 928 0 DGROUp5/
MOUNTED EXTERN N N 512 4096 1048576 1000 742 0 742 0 DGROUp6/
MOUNTED EXTERN N N 512 4096 1048576 1000 943 0 943 0 DGROUp7/
MOUNTED EXTERN N N 512 4096 1048576 1000 950 0 950 0 DGROUp8/
MOUNTED EXTERN N N 512 4096 1048576 100 33 0 33 0 DGROUp9/

lsdg 명령을 통해, 디스크 네임 정보 이외에도 얼마나 많은 공간이 할당되었는지, 여유공간이 얼마나 되는지, 오프라인 디스크는 몇 개나 되는지 등을 확인하는 것이 가능합니다. 이 정보를 이용하면 문제의 진단이 한층 용이해질 수 있습니다.

du(“disk utilization”)- ASM 디스크에 데이터가 로드된 이후에는, 디스크그룹에서 사용되고 있는 공간이 얼마나 되는지 확인할 필요가 있습니다. 이때 (UNIX, Linux, Windows 환경과 마찬가지로) du 커맨드를 이용할 수 있습니다. 디렉토리 내에 사용되고 있는 공간을 확인하려면 아래와 같이 실행하면 됩니다.

ASMCMD [+] > du /dgroup1
Used_MB Mirror_used_MB
9 9

실행 결과, 9MB의 공간이 사용되고 있음을 알 수 있습니다. 디스크는 ASM 외부에서 미러링되어 있으므로, 전체 디스크 사용량 (Mirror_used_MB) 역시 9MB로 표시됩니다. ASM 디스크의 이중화 매개변수(redundancy parameter)를 사용하는 환경이라>

help- 위에서 설명한 모든 커맨드를 굳이 외우고 있을 필요는 없습니다. help 명령을 입력하면 전체 커맨드의 목록이 표시됩니다. 특정 커맨드에 대한 도움말을 보려면 help 를 입력하면 됩니다. 예를 들어, mkalias 커맨드에 대한 정보를 확인하려면 아래와 같이 실행합니다:

ASMCMD [+] > help mkalias
mkalias Create the specified user_alias for the system_alias. The user_alias
must reside in the same diskgroup as the system_alias, and only one
user_alias is permitted per file. The SQLpLUS equivalent is "alter
diskgroup add alias for ".

지금까지 확인한 것처럼, (SQL 인터페이스, Oracle Enterprise Manager에 의지하지 않고도) ASM이 제공하는 다양한 커맨드를 이용하여 파일시스템의 관리성을 개선할 수 있습니다. 이 커맨드는 셸 스크립트에서도 실행 가능하므로 그 활용의 폭이 매우 넓다 하겠습니다.

빈 데이터파일의 Drop

관리자들은 데이터파일을 엉뚱한 디렉토리 또는 테이블스페이스에 추가하는 실수를 자주 범하곤 합니다. 하지만 자포자기할 필요는 없을 것입니다. 데이터파일에 아직 아무런 데이터도 저장되어 있지 않으므로, 간단하게 삭제(drop) 처리해 버리면 되지 않을까요

안타깝게도 현실은 그렇지 못합니다. Oracle Database 10g Release 2 이전 버전에서 데이터파일을 삭제하려면 전체 테이블스페이스를 drop 처리하고 다시 리빌드하는 방법밖에 없었습니다. 테이블스페이스에 이미 데이터가 저장되어 있는 경우라면, 데이터를 다른 저장공간으로 이동하여 마운트하는 매우 수고스럽고 지루한 과정을 거쳐야 할 것입니다. 작업에 많은 시간이 소요된다는 것도 문제지만, 그 동안 테이블스페이스를 사용할 수 없다는 것이 더 큰 문제입니다.

Oracle Database 10g Release 2에서는 이 프로세스를 대폭적으로 단순화하는 것이 가능해졌습니다. 데이터파일은 쉽게 drop 처리될 수 있습니다. 아래 명령을 실행하면, 지정된 데이터파일을 서버와 테이블스페이스로부터 완전하게 삭제할 수 있습니다.

alter tablespace users drop datafile '/tmp/users01.dbf'
/

하지만 몇 가지 제약사항이 존재합니다. 먼저, 데이터파일이 비어 있는 경우에만 삭제가 가능합니다. 그리고 테이블스페이스에 단 하나의 데이터파일만이 존재하는 경우에는 삭제할 수 없으며, 이 경우 테이블스페이스를 삭제해야 합니다. 또 테이블스페이스는 온라인 상태이어야 하며, 읽기/쓰기가 가능해야 합니다.

성능이 저하된 시스템 환경에서의 SGA 직접 액세스

데이터베이스가 느려지거나 타임아웃이 자주 발생하는 경우, 대부분의 DBA가 가장 먼저 취하는 조치는 SYSDBA로 데이터베이스에 연결하여 wait 이벤트를 점검하는 것입니다. 하지만 인스턴스가 행(hang) 상태라면, 그래서 로그인조차 불가능하다면 어떻게 해야 할까요 이러한 경우라면 아무리 강력하고 유용한 트러블슈팅 쿼리도 무용지물이 될 것입니다.

Oracle Database 10g Release 2의 Oracle Enterprise Manager Grid Control은 SGA에 사용자를 직접 연결하고, SGA의 프로세스 상태 정보를 직접 확인할 수 있는 기능을 제공합니다. Memory Access Mode라고도 불리는 이 기능은, 인스턴스가으로 활용이 가능합니다. 또 SQL 액세스가 사실상 불가능한 경우에는 이 기능이 자동적으로 수행됩니다.

그 실행 방법은 다음과 같습니다: Oracle Enterprise Manager UI에서 performance 탭을 선택하고 페이지 하단의 "Related Links”로 스크롤합니다 (아래 그림 참고).

dba_02_01.gif

“Monitor in Memory Access Mode” 링크를 클릭하면 아래와 같은 화면이 나타납니다. "View Mode" 드롭다운 메뉴에 "Memory Access"가 선택되어 있는 것을 확인하실 수 있습니다.

dba_02_02.gif

“View Mode” 드롭다운 메뉴를 통해 Oracle Enterprise Manager가 데이터를 조회하는 방식을 제어할 수 있습니다. 위의 경우, 데이터를 메모리로부터 직접 가져옵니다 ("Memory Access"). 또 "SQL Access"를 선택하면 성능 뷰에 대해 SELECT 쿼리를 수행할 수 있습니다.

Memory Access Mode가 SQL 액세스를 대체하는 것은 아니라는 점을 참고하시기 바랍니다. 이 기능은 SQL 액세스가 불가능한 경우에 한해 활용되어야 합니다. 또, Memory Access Mode에서는 성능 분석에 필요한 데이터의 일부만을 조회할 수 있습니다. (다음 연재 “성능 관련 기능” 에서 좀 더 자세히 설명하기로 합니다.)

파티션의 온라인 재정의

(파티셔닝과 같은) 테이블 변경 작업을 수행하려면 기본적으로 다운타임이 수반됩니다. 다운타임이 허용되지 않는 환경에서, 대부분의 DBA들은 DBMS_REDEFINITION과 같은 온라인 재정의 툴에 의존하곤 합니다. 이 툴을 이용하면 온라인 상태에서 오브젝트 정의를 변경하는 것이 가능합니다.

하지만, 어떤 경우에는 DBMS_REDEFINITION이 전혀 도움이 되지 않을 수도 있습니다. 한 예로, 테이블의 파티션을 다른 테이블스페이스로 이동해야 하는 경우를 생각해 봅시다. 이를 위해서는 (파티션된 테이블이라 하더라도) 전체 테이블을 이동해야만 합니다. 테이블의 사이즈가 크다면, 많은 redo/undo 작업이 발생하고 파티션에 대한 원활한 액세스가 불가능해질 수 있습니다. 만일, 개별 파티션 단위로 이동 작업을 수행할 수 있다면 시간과 공간 면에서 많은 절감이 가능하고 redo/undo 작업의 수도 줄어들 것입니다.

Oracle Database 10g Release 2에는 바로 이러한 기능이 추가되었습니다. Oracle Enterprise Manager 또는 커맨드라인을 통해 테이블 내의 개별 파티션을 재정의할 수 있습니다.

USERS 테이블스페이스 내에 11개의 파티션으로 구성된 ACCOUNTS 테이블이 존재한다고 가정해 봅시다. 이 테이블을 새로운 ACCDATA 테이블스페이스로 이동하되, 한 번에 파티션 하나씩 이동하고자 합니다.

먼저, ACCDATA 테조를 갖는 임시 테이블을 생성합니다.

SQL> create table accounts_int
2 tablespace accdata
3 as
4 select * from accounts
5 where 1=2
6 /

다음으로 파티션의 위치를 확인합니다:

SQL> select partition_name, tablespace_name, num_rows
2 from user_tab_partitions
3 /pARTITION_NAME TABLESpACE_NAME NUM_ROWS
------------------------------ ------------------------------ ----------
p1 USERS 1014
p2 USERS 1042
p3 USERS 1002
p4 USERS 964
p5 USERS 990
p6 USERS 1042
p7 USERS 915
p8 USERS 983
p9 USERS 1047
p10 USERS 1001
pMAX USERS 011 rows selected.

모든 파티션이 USERS 테이블스페이스에 위치하고 있음을 확인할 수 있습니다. 이제, 첫 번째 파티션 p1을 ACCDATA 테이블스페이스로 이동합니다.

SQL> begin
2 dbms_redefinition.start_redef_table (
3 uname => 'ARUp',
4 orig_table => 'ACCOUNTS',
5 int_table => 'ACCOUNTS_INT',
6 part_name => 'p1'
7 );
8 end;
9 /pL/SQL procedure successfully completed.

6번째 라인의 part_name 매개변수는 재구성되는 파티션을 지정하는 용도로 사용됩니다. 이 매개변수가 생략되는 경우, 모든 파티션이 동시에 재정의됩니다.

이제 임시 테이블과 기존 테이블을 동기화합니다 (이 작업은, ACCOUNTS 테이블에 새로 업데이트된 데이터가 있는 경우에만 수행합니다.)

SQL> begin
2 dbms_redefinition.sync_interim_table (
3 uname => 'ARUp',
4 orig_table => 'ACCOUNTS',
5 int_table => 'ACCOUNTS_INT',
6 part_name => 'p1'
7 );
8 end;
9 /pL/SQL procedure successfully completed.

마지막으로 재정의 프로세스를 완료합니다.

SQL> begin
2 dbms_redefinition.finish_redef_table (
3 uname => 'ARUp',
4 orig_table => 'ACCOUNTS',
5 int_table => 'ACCOUNTS_INT',
6 part_name => 'p1'
7 );
8 end;
9 /pL/SQL procedure successfully completed.

p1 파티션이 ACCDATA 테이블스페이스로 성공적으로 이동되었음을 확인합니다.

SQL> select partition_name, tablespace_name, num_rows
2 from user_tab_partitions
3 /pARTITION_NAME TABLESpACE_NAME NUM_ROWS
------------------------------ ------------------------------ ----------
p1 ACCDATA 1014
p2 USERS 1042
p3 USERS 1002
p4 USERS 964
p5 USERS 990
p6 USERS 1042
p7 USERS 915
p8 USERS 983
p9 USERS 1047
p10 USERS 1001
pMAX USERS 011 rows selected.

여기까지입니다. 이제 다른 파티션에 대해 같은 과정을 반복하면 됩니다.

만일체 테이블 사이즈와 동일한 용 대한 undo 작업을 수행해야 했을 것입니다 (이 과정에서 에러가 발생할 가능성도 있습니다). 그 대신 개별 파티션 단위로 프로세스를 수행함으로써 디스크 요구사항과 undo 작업의 발생량을 줄일 수 있었습니다.

이처럼 강력하고 유용한에서 재구성하는 것이 가능합니다. 또, 통계정보가 재정의된 파일에 함께 복사되므로 (위 실행결과에서 NUM_RWS의 값을 참고하시기 바랍니다), 새롭게 생성된 테이블 또는 파티션을 위해 통계정보를 재생성할 필요도 없습니다.

메모리의 블록 무결성 점검

액티브 상태의 데이터베이스 인스턴스에는 다양한 형태의 데이터 흐름(사용자 세션->버퍼 캐시, 캐시->디스크 등)이 존재하며, 이러한 이동 과정에서 데이터 블록이 손상될 가능성이 있습니다.

오라클은 데이터 블록을 디스크에 기록하기 전에 데이터의 체크섬(checksum)을 계산하는 방법으로 데이터 블록의 무결성을 검증합니다. 이 체크섬은 디스크에도 기록됩니다. 디스크로부터 블록을 읽어올 때, 프로세스는 체크섬을 다시 한 번 계산하고 저장된 값과 비교합니다. 이때 체크섬이 동일하지 않다면, 데이터 블록이 손상된 것으로 판단할 수 있습니다.

대부분의 데이터 작업이 메모리 내부에서 수행되기 때문에, 이 작업을 소스(버퍼 캐시)에서 직접 수행할 수 있다면 더 바람직할 것입니다. Oracle Database 10g Release 2에서 DB_BLOCK_CHECKSUM 초기화 매개변수를 FulL로 설정하면, (디스크 뿐 아니라) 메모리 상에서도 무결성 점검 작업을 수행하는 것이 가능합니다.

이와 같이 설정된 경우, 오라클은 변경 작업을 수행하기 전에 체크섬을 계산하고 그 결과를 저장된 값과 비교합니다. 이 과정에서 메모리 내부의 데이터 손상 여부를 확인할 수 있으며, 따라서 손상된 데이터가 디스크 또는 스탠바이 데이터베이스로 전달되는 것을 사전에 차단할 수 있습니다.

이 매개변수는 (TRUE의 디폴트 값을 가졌던 이전 버전과 달리) 디폴트 상태에서 FALSE로 설정됩니다.

매개변수의 온라인 변경

데이터베이스를 생성하는 시점에 정의한 MAXDATAFILES, MAXLOGFILES 등의 매개변수는 어떻게 변경할 수 있을까요
Oracle Database 10g Release 2 이전 버전에서는 다음과 같은 방법만이 가능했습니다:

  1. 컨트롤파일을 트레이스(trace) 파일로 백업합니다
  2. 트레이스 파일 내의 매개변수를 변경합니다.
  3. 데이터베이스를 셧다운합니다.
  4. Mount 상태로 데이터베이스를 시작합니다.
  5. 컨트롤파일을 재생성합니다.
  6. RESETLOGS 모드로 데이터베이스를 오픈합니다.

말할 필요도 없는 이야기겠지만, 이런 방법을 사용하면 가용성이 저하될 수 밖에 없습니다. 또 RMAN은 (카탈로그와 별도로) 컨트롤 파일에 백업에 관련한 메타데이터를 저장하고 있는데, 이 정보가 손실되어 버립니다. 게다가 컨트롤파일은 RESETLOGS 모드에서 재생성되므로, 이 과정에서 백업 정보의 일부가 추가적으로 손실됩니다.

Oracle Database 10g Release 2에서는 이 매개변수를 변경하기 위해 컨트롤파일을 재생성할 필요가 없습니다. 따라서 컨트롤파일에 저장된 RMAN 정보 역시 소실되지 않습니다.

더 빨라진 데이터베이스 스타트업

2GB 메모리가 “대용량”으로 간주되던 시절은 이미 옛날이 되어 버렸습니다. 이제는 버퍼 캐시 용량으로 100 GB를 할당하는 경우도 심심치 않게 볼 수 있습니다. 데이터베이스를 스타트업하는 과정에서, 이처럼 큰 용량의 버퍼 캐시를 초기화하는 데 짧게는 수 분, 길 게는 수 시간이 걸릴 수 있습니다.

하지만 데이터베이스 인스턴스가 처음 시작되는 과정에서 굳이 전체 버퍼 캐시를 활성화할 필요는 없습니다. 인스턴스의 버퍼 캐시는 처음에는 완전히 빈 상태에서 시작하여 점차 데이터 쿼리가 수행되면서 차오릅니다. 따라서 인스턴스가 시작되는 시점에 전체 버퍼 캐시 용량을 초기화할 필요가 없습니다.

Oracle Database 10g Release 2에서는 이러한 로직이 새롭게 반영되었습니다. 처음에 인스턴스가 시작되면 전체 버퍼 캐시 용량의 10%만이 초기화되고, 나머지 공간은 체크포인트 프로세스에 의해 데이터베이스가 오픈된 이후 초기화됩니다. 따라서 인스턴스의 스타트업 시간을 대폭적으로 단축하는 것이 가능합니다.

하지만, 전체 버퍼 캐시가 초기화될 때까지 자동 버퍼 캐시 사이징(automatic buffer cache sizing) 기능을 사용할 수 없다는 사실에 주의할 필요가 있습니다.

Oracle Enterprise Manager를 이용한 다수 오브젝트의 관리

스키마 내에서 다수의 “invalid object”가 발생하는 경우 어떻게 조치해야 할까요 대부분의 DBA는 “invalid object”를 컴파일하는 스크립트를 다이내믹하게 생성하기 위한 SQL 스크립트를 작성합니다. 적어도 써드선의 대안이었습니다.

하지만 Oracle Enterprise Manager Grid Control을 이러한 용도로 활용할 수 있다면 좋지 않을까요 “invalid object”들을 선택하고 “컴파일” 메뉴를 단 한 차례 클릭해서 한꺼번에 컴파일해 버릴 수 있다면 편리하지 않을까요

Oracle Database 10g Release 2가 바로 이러한 기능을 제공합니다. 아래 그림에서처럼, DBA가 오브젝트 옆의 체크박스를 클릭한 후 “Actions” 드롭다운 메뉴에서 “Compile”을 선택하면, 여러 개의 오브젝트를 동시에 컴파일할 수 있습니다.

Oracle Database 10g Release 스크린샷

컴파일 작업 이외에도, DDL의 생성, 오브젝트의 드롭(drop)과 같은 다양한 작업이 가능합니다.

XML 포맷의 Audit Trail 지원

오라클 데이터베이스에 내장된 감사(audit) 툴을 오랜 기간 사용해 온 관리자라면, 감사 기록(audit trail)을 파일시스템에 저장할 수 있다는 사실을 이미 알고 계실 것입니다. 이처럼 감사 기록을 데이터베이스가 아닌 파일시스템에 저장함으로써, 시스템의 보안 수준을 한 차원 끌어올리는 것이 가능합니다.

관리자는 두 개의 초기화 매개변수만을 설정해 주면 됩니다:

audit_file_dest = '/auditfs'
audit_trail = xml

그런 다음 인스턴스를 재시작합니다. 매개변수를 설정하고 나면, 감사 기록이 /auditfs 디렉토리에 저장됩니다 (이 매개변수는 다이내믹하지 않음에 주의하시기 바랍니다). audit_file_dest 매개변수를 설정하지 않은 경우에는 $ORACLE_HOME/rdbms/audit 디렉토리가 디폴트로 사용됩니다. 또 감사 기록 파일을 .xml 확장자를 갖는 XML 파포맷으로 저장된 감사 기록의 예가 아래와 같습니다:

XML 포맷으로 저장된 감사 기록의 예가 아래와 같습니다:

- <Audit xmlns="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-10_2.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-10_2.xsd">
<VERSION>10.2</VERSION>
- <AUDITRECORD>
<AUDIT_TYpE>8</AUDIT_TYpE>
<ENTRYID>1</ENTRYID>
<EXTENDED_TIMESTAMp>2005-03-05T20:52:51.012045</EXTENDED_TIMESTAMp>
<DB_USER>/</DB_USER>
<OS_USER>oracle</OS_USER>
<USERHOST>oradba</USERHOST>
<OS_pROCESS>18067</OS_pROCESS>
<TERMINAL>pts/0</TERMINAL>
<INSTANCE_NUMBER>0</INSTANCE_NUMBER>
<RETURNcode>0</RETURNcode>
<OS_pRIVILEGE>SYSDBA</OS_pRIVILEGE>
<SQL_TEXT>CONNECT</SQL_TEXT>
</AUDITRECORD>
</AUDIT>

XML 파서(parser)를 이용하면 이 트레이스 파일로부터 유용한 정보를 추출해 낼 수 있습니다. 또 이 정보를 XML 타입으로 데이터베이스에 로드하고, XML Query를 이용하여 조회하는 것도 가능합니다.

Oracle Database 10g Release 2에서는 XML과 SQL 쿼리를 조합하여, 마치 단일 SQL 소스에 대해 질의하는 것처럼 정보를 조회할 수 있는 기능을 제공합니다. 또 X$XML_AUDIT_TRAIL 테이블을 기반으로 사전정의된 V$XML_AUDIT_TRAIL 다이내믹 뷰가 지원됩니다. 이 다이내믹 뷰는 일반적으로 사용되는 DBA_AUDIT_TRAIL 뷰와 구조 면에서 유사합니다.

DBA는 써드 파티 XML 파서/에디터를 활용하여 XML 포맷으로 저장된 감사 기록을 조회하고, XML 입력을 지원하는 툴을 통해 리포트를 생성할 수도 있습니다. 이제는 감사 기록을 조회하기 위해 파서(parser)를 직접 구현할 필요가 없습니다.

Automatic Segment Advisor

하이워터마크(high-water mark) 이하 영역에 많은 여유 공간을 갖고 있는 세그먼트가 무엇인지, 그리고 재구성(reorganization) 작업을 통해 효과를 볼 수 있는 세그먼트가 무엇인지 어떻게 확인할 수 있을까요

Oracle Database 10g가 제공하는 Oracle Enterprise Manager 인터페이스를 이용하면 개별 테이블스페이스 별로 온라인 재구성 작업이 필요한 세그먼트를 확인할 수 있습니다. 하지만 테이블스페이스의 수가 수백 개에 달하는 환경이라면, 이러한 작업을 매일 수작업으로 수행할 수는 없을 것입니다. 세그먼트를 스캐닝하고 재구성 작업이 필요한 세그먼트를 리포팅해 주는 자동화된 툴이 있다면 편리하지 않을까요

Oracle Database 10g Release 2의 DBMS_SpACE 패키지가 바로 이러한 기능을 제공합니다. 패키지에 내장된 ASA_RECOMMENDATIONS 함수는 “pipelined” 함수이므로 아래와 같은 방법으로 실행되어야 합니다:

select * from table (dbms_space.asa_recommendations());

컬럼의 수가 워낙 많아 결과를 다 보여드리기는 어렵겠습니다. 대신, 반환된 결과 중 레코드 하나만을 확인해 보기로 합시다.

TABLESpACE_NAME       : USERS
SEGMENT_OWNER : ARUp
SEGMENT_NAME : ACCOUNTS
SEGMENT_TYpE : TABLE pARTITION
pARTITION_NAME : p7
ALLOCATED_SpACE : 0
USED_SpACE : 0
RECLAIMABLE_SpACE : 0
CHAIN_ROWEXCESS : 17
RECOMMENDATIONS : The object has chained rows that can be removed
by re-org.
C1 :
C2 :
C3 :
TASK_ID : 261
MESG_ID : 0

위 결과에서 ARUp 스키마, ACCOUNTS 테이블의 p7 파티션이 “chained rows”를 포함하고 있음을 알 수 있습니다. 따라서 재구성 작업을 수행하면 이 파티션의 풀 테이블 스캔(full table scan) 성능이 향상될 것이라고 기대할 수 있습니다.

이 정보는 사전정의된 유지보수 시간대(maintenance window; 주중 10pM - 6AM, 토요일 12 AM - 월요일 12 AM)에 스케줄 기반으로 자동 실행되는 작하여 작업의 스케줄을 변경하는 것도 가능합니다. 만일 작업이 정의된 시간 내음날 유지보수 시간대가 재개될 때 다시 시작됩니다.

스캔 작업이 수행되면 wri$_segadv_objlist 테이블에 확인된 세그먼트 및 테이블스페이스 정보가 저장됩니다. 이 정보는 DBA_AUTO_SEGADV_CTL 뷰를 통해 확인할 수 있습니다.

이벤트 기반 스케줄링

Oracle Database 10g Release 1에서 처음 소개된 Oracle Scheduler는 기존의 DBMS_JOB 패키지를 대체하는 차세대 작업 스케줄링 시스템입니다. Oracle Scheduler 툴은 기존 패키지보다 훨씬 뛰어난 기능을 제공합니다 (자세한 정보는 이곳을 참고하시기 바랍니다.)

Oracle Database 10g Release 1의 Oracle Scheduler에서, 작업은 시간을 기준으로 실행됩니다. 하지만, 시간이 아닌 이벤트를 기준으로 작업을 실행하고자 하는 경우가 있을 수 있습니다. 예를 들어 특정 고객 어카운트의 어카운트 관리자가 변경되는 경우, 매출을 재계산하고 리포트를 재생성하는 배치 프로그램을 자동으로 실행해야 할 수 있을 것입니다.

Oracle Database 10g Release 2는 이벤트 기반 트리거(trigger)를 지원하는 Scheduler 툴을 제공합니다. 이벤트는, 오브젝트 타입의 데이터를 처리하는 Advanced Queueing (AQ)을 통해 Scheduler로 전달됩니다. 따라서, 이벤트를 큐에 저장하기 위해 먼저 “proc_queue”와 같, 이 이벤트를 기반으로 스케줄을 설정하면 됩니다.

begin
dbms_scheduler.create_event_schedule (
schedule_name => 'accadmin.acc_mgr_change',
start_date => systimestamp,
event_condition => 'tab.user_data.event_name = ''acc_mgr_change''',
queue_spec => 'proc_queue');
end;

다음으로, 이 스케줄에 연동할 작업을 생성합니다. (물론 스케줄을 만들기 전에 작업을 먼저 생성할 수도 있습니다.)

begin
dbms_scheduler.create_job (
job_name => acc_mgr_change,
program_name => acc_mgr_change_procs,
start_date => 'systimestamp,
event_condition => 'tab.user_data.event_name = ''acc_mgr_change''',
queue_spec => 'proc_queue'
enabled => true);
end;The default value is UNliMITED.

이벤트 기반 스케줄링은, 시간이 아닌 이벤트를 기준으로 작업을 스케줄링하고자 하는 경우 매우 유용하게 활용됩니다.