사람들이 사용하기를 꺼려하는 기능들

• (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개의 행을 삽입하는 이 프로시저를 백그라운드로 다섯 번을 실행

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

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

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

13.3 하고 싶지 않다

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

13.4 몰랐다

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

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

• 관계형 세계(와 거의 모든 객체 구현)에서 20년 이상 변경되지 않고 유지되고 있는 것이 데이터베이스 자체이다.

• 프로시저를 통해 누가 쿼리를 수행하는지, 언제 쿼리를 수행하는지, 어느 단말기로부터 수행하는지를 감시할 수 있으며 데이터 액세스를 적절히 제한할 수 있는 FGAC를 사용하면 다음과 같은 보안 기능을 시행할 수 있다.
• (1)특정 클래스의 사용자가 정상적인 영업 시간을 지나서 실행하는 모든 쿼리는 아무 레코드도 반환하지 않는다.
• (2)보안 기능이 장착된 단말기에는 모든 데이터가 반환될 수 있지만 원격 클라이언트 단말기에는 민감하지 않는 정보만 갈 수 있다.

• 데이터베이스 독립과 철저한 개방성 추구보다는 기종에 상관없이 철저히 활용되어야 한다.
• 대상 데이터베이스의 기능을 이용함으로써 애플리케이션을 5배나 빠르게 할 수 있다면 데이터베이스 독립성 요구는 신속하게 허물어진다.

요약

• 이 장에서는 오라클 데이터베이스 구현을 둘러싸고 있는 많은 가벼운 이슈, 즉 DBA/개발자 관계와 이 관계의 상호작용 바익, 수중의 툴(오라클 데이터베이스)을 이해하는 것이 얼마나 중요하지 등과 같은 사항, 데이터베이스는 데이터가 덤프되는 장소(비트 버킷) 이상이라는 것을 강조하였다.
• 또한 테스트 환경을 사용하지 않을 경우 발생할 수 있는 문제와 기타 수많은 이슈를 다루었다.

• 참이라고 증명되지 않은 것은 참이 아니라는 것과 참(또는 거짓)으로 증명될 수 있는 것들은 반드시 증명되어야 한다.
• 주어진 기능을 최대한 활용할 경우 신속하게 개발할 수 있으며 저렴할 뿐만 아니라 결국에는 제품의 품질이 높아진다.