이펙티브 오라클 (2009년)
제공된 기능을 사용하라 0 0 43,544

by 구루비스터디 [2018.05.26]


사람들이 사용하기를 꺼려하는 기능들
  • 감사 : 느리다는 이유로 내장된 AUDI 명령을 사용하거나 트리거를 이용하여 직접 감사하려는 경향
  • 복제 : 내장된 기능은 복잡하다는 이유로 마스터간 복제, 스냅샷 기반의 복제(스트림)보다는 스스로 복제를 수행
  • 메시지 큐잉 : 데이터베이스의 AQ(advanced queuing) 소프트웨어를 사용하는 대신 문서화되지 않은 기능을 사용
  • 레코드 변경 내력 유지 : 자동으로 유지해 주는 Workspace Manager를 사용하는 대신 엄청난 양의 트리거를 작성
  • 시퀀스 : 확장성을 이유로 내장된 시퀀스 번호를 사용하기보다는 데이터베이스 테이블을 이용하여 직접 기능을 구현
  • 데이터베이스 기능을 사용하지 못하는 이유는 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개의 행을 삽입하는 이 프로시저를 백그라운드로 다섯 번을 실행


내부 감사를 포함한 T1DIY 감사를 포함한 T2비고
트랜잭션/초38027827% 감소
CPU 시간30244346% 증가


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


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

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


13.3 하고 싶지 않다

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


13.4 몰랐다

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


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

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


요약

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

- 강좌 URL : http://www.gurubee.net/lecture/3458

- 구루비 강좌는 개인의 학습용으로만 사용 할 수 있으며, 다른 웹 페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^

- 구루비 강좌는 서비스 제공을 위한 목적이나, 학원 홍보, 수익을 얻기 위한 용도로 사용 할 수 없습니다.

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입