by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

제공된 기능을 사용하라




  • 사람들이 사용하기를 꺼려하는 기능들
    (1)감사 : 느리다는 이유로 내장된 AUDI 명령을 사용하거나 트리거를 이용하여 직접 감사하려는 경향
    (2)복제 : 내장된 기능은 복잡하다는 이유로 마스터간 복제, 스냅샷 기반의 복제(스트림)보다는 스스로 복제를 수행
    (3)메시지 큐잉 : 데이터베이스의 AQ(advanced queuing) 소프트웨어를 사용하는 대신 문서화되지 않은 기능을 사용
    (4)레코드 변경 내력 유지 : 자동으로 유지해 주는 Workspace Manager를 사용하는 대신 엄청난 양의 트리거를 작성
    (5)시퀀스 : 확장성을 이유로 내장된 시퀀스 번호를 사용하기보다는 데이터베이스 테이블을 이용하여 직접 기능을 구현
  • 데이터베이스 기능을 사용하지 못하는 이유는 FUD(두려움, 불확실성, 의심), 기능에 대한 무지, 데이터베이스 독립성 추구 등이다.

13.1 기능 X가 느리다고 들었다

  • 내장된 감사 기능이 느리다는 신화
    (1)감사 기능을 켜지 않았을 때는 정상적으로 실행되었다
    (2)감사 기능을 켰을 때는 속도가 느려졌다.
    (3)따라서 감사는 느리다.
  • 이에 대한 질문
    (1)그것을 벤치마킹했습니까?
    (2)확실한 수치를 가지고 있습니까?
    (3)오버헤드가 정확하게 무엇입니까?
    (4)수치는 어떻습니까?
  • 벤치마킹 결과 다른 어떤 솔루션보다 내장된 감사의 이점
    (1)커널 내부에 포함되어 있기 때문에 더 빠르다. C코드로 작성된 내장 모듈이 이의 흉내를 내는 트리거보다 빠른 건 당연하다.
    (2)하나의 명령으로 구성되기 때문에 애플리케이션의 전체 하위 시스템 디자인, 프로그램 작성, 스키마 디자인
    등의 작업을 수행하는 것보다 훨씬 쉽다.
    (3)아무나 끌 수 있는 단순한 트리거가 아니며 데이터베이스의 일부이기 때문에 보다 안전하며 정확한 것으로 평가되었다.
    (4)오라클 또는 운영체제의 감사 추적에 존재할 수도 있는 등 융통성이 뛰어나다.
    사용자의 테이블 구조를 알고 있는 툴이 몇이나 될 것 같은가?
  • 실습
    
    -- 내장된 감사 추적 기능 활용
    create table t1 ( x int );
    audit insert on t1 by access;
    
    -- 트리거를 이용하여 직접 감사
    create table t2 ( x int );
    create table t2_audit
    as
    select sysdate dt
          ,a.*
      from v$session a
     where 1=0;
    create index t2_audit_idx on t2_audit(sid,serial#);
    
    -- 트리거 작성시 오류가 발생했음.
    create trigger t2_audit
    after insert on t2
    begin
       insert into t2_audit
       select sysdate
             ,a.*
         from v$session a
        where sid = ( select sid 
                        from v$mystat 
                       where rownum=1 );
    end;
    /
    
    -- 두가지 방법의 성능을 비교하는 프로시저 작성
    create table t1_times ( xstart timestamp, xstop timestamp );
    create or replace procedure p1( n in number )
    as
      l_rowid rowid;
    begin
       insert into t1_times (xstart) values (systimestamp)
       returning rowid into l_rowid;
       for i in 1 .. n
       loop
          insert into t1 values (i);
          commit;
       end loop;
       update t1_times set xstop = systimestamp where rowid = l_rowid;
       commit;
    end;
    /
    -- T2에 대해서도 동일한 작업 수행 한 후 매번 30,000개의 행을 삽입하는 이 프로시저를 백그라운드로 다섯 번을 실행
    
      내부 감사를 포함한 T1 DIY 감사를 포함한 T2 비고
    트랜잭션/초 380 278 27% 감소
    CPU 시간 302 443 46% 증가

    이 결과를 통해 본래의 기능을 사용하는 것이 더 쉽고 빠르며 훨씬 효율적이라는 것이 증명되었다.

13.2 기능 X가 복잡하다는 얘기를 들었다

  • 데이터 웨어하우스 테이블에서 느리게 변경되는 차원의 새로 고침을 "최적화"하는 사례
    -> 복잡한 데이터베이스의 내부 기능을 알려고 하는 것도 중요하지만,
    자신의 목적을 달성하기 위해 무엇이 필요한지(가능성,변수등) 조사하는 것이 더 중요하다.

13.3 하고 싶지 않다

  • 해답을 알고 있으면서도 "하고 싶지 않다"는 태도를 바꿀 수 있는 유일한 방법은
    동료 또는 관리자로부터 압력을 받도록 하는 방법뿐이다?

13.4 몰랐다

  • 각 릴리스의 메뉴얼(적어도 새 기능 가이드와 개념 가이드)을 읽을 것을 권장

13.5 데이터베이스 독립이 필요하다

  • 관계형 세계(와 거의 모든 객체 구현)에서 20년 이상 변경되지 않고 유지되고 있는 것이 데이터베이스 자체이다.
  • 프로시저를 통해 누가 쿼리를 수행하는지, 언제 쿼리를 수행하는지, 어느 단말기로부터 수행하는지를 감시할 수 있으며
    데이터 액세스를 적절히 제한할 수 있는 FGAC를 사용하면 다음과 같은 보안 기능을 시행할 수 있다.
    (1)특정 클래스의 사용자가 정상적인 영업 시간을 지나서 실행하는 모든 쿼리는 아무 레코드도 반환하지 않는다.
    (2)보안 기능이 장착된 단말기에는 모든 데이터가 반환될 수 있지만 원격 클라이언트 단말기에는 민감하지 않는 정보만 갈 수 있다.
  • 데이터베이스 독립과 철저한 개방성 추구보다는 기종에 상관없이 철저히 활용되어야 한다.
  • 대상 데이터베이스의 기능을 이용함으로써 애플리케이션을 5배나 빠르게 할 수 있다면 데이터베이스 독립성 요구는 신속하게 허물어진다.

요약

  • 이 장에서는 오라클 데이터베이스 구현을 둘러싸고 있는 많은 가벼운 이슈,
    즉 DBA/개발자 관계와 이 관계의 상호작용 바익, 수중의 툴(오라클 데이터베이스)을 이해하는 것이 얼마나 중요하지 등과 같은 사항,
    데이터베이스는 데이터가 덤프되는 장소(비트 버킷) 이상이라는 것을 강조하였다.
    또한 테스트 환경을 사용하지 않을 경우 발생할 수 있는 문제와 기타 수많은 이슈를 다루었다.
  • 참이라고 증명되지 않은 것은 참이 아니라는 것과 참(또는 거짓)으로 증명될 수 있는 것들은 반드시 증명되어야 한다.
  • 주어진 기능을 최대한 활용할 경우 신속하게 개발할 수 있으며 저렴할 뿐만 아니라 결국에는 제품의 품질이 높아진다.

문서에 대하여

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.