B*Tree Search의 기본적인 Algorithm을 이용하는데 주로 온라인 업무의 적은 데이터 처리에 유리하고 분포도가 나쁜 데이터 처리는 성능에 악영향을 줄 수 있다. 하나의 ROW를 검색 시 어느 ROW나 동일한 양의 블록을 ACCESS하게 되므로 검색 시간이 동일하다. (DML문의 잦은 사용으로 좌우 대칭이 안 맞을 수 있는데 이때는 index rebuild를 해야 한다.) 대체적으로 분포도가 전체 데이터의 20% 이상인 경우 인덱스를 통해 SELECT 하면 FULL TABLE SCAN보다 성능이 떨어질 수 있다. 예를 들어 직책이라는 컬럼이 있는데, A,B,C,D라는 값이 들어올 수 있다고 하면 분포도는 25%가 된다. 이런 경우에는 B*TREE 인덱스를 이용하면 성능이 떨어질 수 있다는 것이다. 데이터베이스에서 IO 단위는 블록이며 데이터를 블록 단위로 전송한다. 인덱스를 사용하지 않을 때는 MULTI BLOCK I/O를 수행하며 한 번에 수 십개의 BLOCK을 읽게 되는데 이는 인덱스를 검색해 하나씩 블록을 읽는 것보다 빠를 수 있다.

1. Oracle Hint, Tuning
비트리 인덱스
(B*Tree Index)

2. Oracle Hint, Tuning_ Hints For Online Application
4.3 Hints For Online Application Upgrade :
RETRY_ON_ROW_CHANGE
Update, Delete에 사용되는 힌트, Insert/Merge에는 사용 불가능한 힌트로 테이블
을 UPDATE 하는 중에 나중에 시작된 다른 트랜잭션에 의해 변경이 완료된 ROW 를
만났을 때 원래 UPDATE 문이 롤백 된 후 다시 수행하도록 하는 힌트이다.(write
consistency)

3. Oracle Hint, Tuning_ Hints For Online Application
[세션1]
SQL> drop table ojc1;
SQL> create table ojc1 (
c1 number primary key,
c2 number
);
SQL> insert into ojc1
select level c1,
level c2
from dual
connect by level <= 100000;
100000 개의 행이 만들어졌습니다.
SQL> drop table ojc1_log;
SQL> create table ojc1_log (
c1 number );
SQL> create or replace package pkg_ojc1
as
cnt number := 0;
end;
/
패키지가 생성되었습니다.

4. Oracle Hint, Tuning_ Hints For Online Application
-- pragma autonomous_transaction  블록에서 자신의 작업을 수행하기 위해서 그 블록 고유의 트
랜잭션을 생성하는 경우에 해당하며 그 블록의 트랜잭션의 결과가 자신을 포함하거나 호출한 트랜잭
션 (마스터 트랜잭션)에의 상태에 의해 영향을 받지 않는 트랜잭션을 의미한다. 즉 본 예제에서 자신을
호출한 UPDATE 문장이 롤백 되더라도 자신은 롤백 되지 않고 묵묵히 COMMIT하겠다는 의미
SQL> create or replace procedure p_ojc1 (p_c1 ojc1.c1%type)
is
pragma autonomous_transaction;
begin
insert into ojc1_log values (p_c1);
commit;
end;
/
프로시저가 생성되었습니다.
SQL> create or replace trigger tr_ojc1
after update on ojc1
for each row
begin
pkg_ojc1.cnt := pkg_ojc1.cnt + 1;
p_ojc1(:new.c1);
end;
/
트리거가 생성되었습니다.

5. Oracle Hint, Tuning_ Hints For Online Application
SQL> exec pkg_ojc1.cnt := 0
-- 아래 쿼리에서 where절이 없다면 읽기 일관성 검사하지 않는다.(retry_on_row_change 힌트 작동
안함) 즉 c2값이 다른 트랜잭션에 의해 변경되었는지 검사할 필요가 없다. 하지만 where절이 있으면
가져온 이후 실제 업데이트할 때 최종적으로 변경된 값을 가지고 update해야 하므로 SCN값을 검사하
여 변경 여부를 검사하여 변경된 경우 최종적인 c2값으로 update 하는 것이다.
SQL> update /*+ retry_on_row_change */ ojc1 set c2 = c2 * -1 where c1 = c2;
[세션2]  1초 후에 실행하세요!
-- 세션2에서 COMMIT을 하면 종료 된다.
SQL> update ojc1 set c2 = 19999 where c1 = 15000 ;
SQL> COMMIT;
[세션1]
99999 행이 갱신되었습니다.
SQL> commit;
SQL> exec dbms_output.put_line('update cnt = ' || pkg_ojc1.cnt)
update cnt = 120003
 이세션 진행 중에 다른 세션에서 UPDATE했으므로 롤백하고 다시 실행했으므로 100000 넘은 값이
나오게 되는 것이다.

6. Oracle Hint, Tuning_ Hints For Online Application
-- ojc1_log 테이블에 INSERT하는 프로시저에서 pragma autonomous_transaction로 선언했으므로
세션2의 UPDATE문에 의해 롤백되지 않아 아래처럼 100000건이 넘게 기록된다.
SQL> select count(*) from ojc1_log;
COUNT(*)
----------
120003
만약 pragma autonomous_transaction로 선언하지 않았다면 ojc1_log 테이블의 건수는 100000건이
될 것 이다.
SQL> select * from ojc1 where c1 = 15000;
C1 C2
---------- ----------
15000 19999  세션2에서 간섭이 들어온 행이며 세션2에서 변경한 값으로 되어 있다.
읽기일관성 검사를 했으므로 세션1에서 실제 UPDATE건수는 99999건이 된다,