• Deterministic 키워드는, 함수의 입력 값이 같다면 출력 값도 항상 같음을 선언 (10gR2에 새롭게 추가된 캐싱 효과)
  • 함수의 일관된 결과를 보장해 주는 역할을 하지 않음
  • Deterministic 함수로 선언했는데 실제 내용이 Deterministic이 아닐 시 문제 발생

          (컬럼의 값 변경 시 일관성을 해치는 문제 발생)

  • Deterministic 함수가 호출 시 캐싱 효과는 Fetch Call 내에서만 유효

          (새로운 Fetch Call 시점에서 일관성이 유지되지 않는 문제 발생 가능)


SQL> create or replace function lookup(l_input number) return varchar2
  2  DETERMINISTIC
  3  as
  4    l_output LookupTable.value%TYPE;
  5  begin
  6    select value into l_output from LookupTable where key = l_input;
  7    return l_output;
  8  end;
  9  /


사용자 정의 함수 사용 시 일관성이 없는 읽기의 쿼리

사용자 정의 함수 사용 시 일관성 문제 해결 쿼리

select /*+ index(t t_no_idx) */ (select lookup(t.no) from dual)
from    big_table t
where   t.no > 0 ;

 

select l.value
from   big_table t, LookupTable l
where  l.key(+) = t.no ;

select (select value from LookupTable where key = t.no)
from   big_table t ;

☞ Join, 스칼라 서브쿼리 사용

→ 스칼라 서브쿼리는 메인 쿼리가 시작되는 시점을 기준으로 블록 읽기 때문에 읽기 일관성 보장


  • Deterministic 키워드는 FBI(Function-Based Index)와 함께 태동
  • FBI는 인덱스가 처음 생성 또는 엔트리가 추가되는 시점의 함수 출력 값을 저장해 두는 원리
  • 오라클은 Deterministic으로 선언하지 않은 함수에 대해서 FBI 생성 거부

          ☞ FBI 생성 시 Deterministic을 선언하도록 강제함


    ▼ Deterministic 이 아닌데 Deterministic 선언으로 일관성이 깨지는 사례 (Windows7, Oracle 11g)


ora1.png


  Update 


 ora2.png  

Update

후 

 ora3.png



   ※ FBI 생성 외, update문으로 반정규화 컬럼을 갱신하거나 insert문으로 가공 테이블에 레코드 삽입 시

       중간에 값이 변경되면 일관성 없는 상태로 값들이 영구 저장될 수 있음


   ☞ 캐싱 효과를 얻기 위해 함부로 Deterministic으로 선언하는 것은 위험