1. 데이터베이스 Call 종류

가. SQL 커서에 대한 작업 요청에 따른 구분

나. Call 발생 위치에 따른 구분

2. 데이터베이스 Call 과 성능

가. One SQL 구현의 중요성

3. Array Processing 활용

4. Fetch Call 최소화

가. 부분범위처리 원리

set arraysize 100
call  count cpu   elapsed disk query current rows
----- ----- ----- ------- ----- ----- ----- ------
Parse     1 0.00    0.00     0     0     0     0
Execute   1 0.00    0.02     2     2     0     0
Fetch   301 0.14    0.18     9   315     0 30000
----- ----- ----- ------- ----- ----- ----- ------
total   303 0.14    0.20    11   317     0 30000

나. ArraySize 조정에 의한 Fetch Call 감소 및 블록 I/O 감소 효과

1) SQL*Plus 이외의 프로그램 언어에서 Array 단위 Fetch 기능 활용 방법

*1) Oracle PL/SQL(커서를 열고 레코드를 Fetch)

\-9i : 한번에 한 로우씩만 처리(Single-Row Fetch)

\-10g : 자동으로 100개씩 array Fetch가 일어남. (Cursor For Loop 구문을 이용할때만 작동)

for item in cursor
loop
   ......
end loop;

2) JAVA(FetchSize를 100으로 설정했을때 데이터를 Fetch 해오는 매커니즘)

String sql = "select custid, name from customer";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setFetchSize(100); -- Statement에서 조정

ResultSet rs = stmt.executeQuery();
// rs.setFetchSize(100); -- ResultSet에서 조정할 수도 있다.

while( rs.next() ) {
  int empno = rs.getInt(1);
  String ename = rs.getString(2);
  System.out.println(empno + ":" + ename);
}

rs.close();
stmt.close();

1. 최초 rs.next() 호출 시 한꺼번에 100건을 가져와서 클라이언트 Array 버퍼에 캐싱한다.

2. 이후 rs.next() 호출할 때는 데이터베이스 Call을 발생시키지 않고 Array 버퍼에서 읽는다.

3. 버퍼에 캐싱 돼 있던 데이터를 모두 소진한 후 101번째 rs.next() 호출 시 다시 100건을 가져온다.

4. 모든 결과집합을 다 읽을 때까지 2~3번 과정을 반복한다.

5. 페이지 처리 활용

• 페이지 처리를 하지 않을때 발생하는 부하요인
  
  1. 다량 발생하는 Fetch Call의 부하
  
  2. 대량의 결과 집합을 클라이언트에 전송하면서 발생하는 네트워크 부하
  
  3. 대량의 데이터 블록을 읽으면서 발생하는 I/O 부하
  
  4. AP 서버 및 웹 서버 리소스 사용량 증가
  
• 페이지처리를 통한 부하해소
  
  1. 페이지 단위로, 화면에서 필요한 만큼만 Fetch Call
  
  2. 페이지 단위로, 화면에서 필요한 만큼만 네트워크를 통해 결과 전송
  
  3. 인덱스와 부분범위처리 원리를 이용해 각 페이지에 필요한 최소량만 I/O
  
  4. 데이터를 소량씩 나누어 전송하므로 AP웹 서버 리소스 사용량 최소화
  
• 조회할 데이터가 일정량 이상이고 수행빈도가 높다면 필수적으로 페이지 처리 구현해야함

6. 분산 쿼리

분산 DB간 테이블 조인

select channel_id, sum(quantity_sold) auantity_cold
from order a, sales@lk_sales b
where a.order_date between :1 and :2
and b.order_no = a.order no
group by channel_id

Rows    Row Source Operation
-----   ---------------------------------------------
5 SORT  GROUP BY
10981    NESTED LOOPS
500000    REMOTE
10981     TABLE ACCESS BY INDEX ROWID ORDER
500000     INDEX UNIQUE SCAN (ORDER_PK)

• 원격의 lk_sales l테이블을 전송받아 order 테이블과 NL 조인
• 50만건이나 되는 데이터를 네트워크를 통해 전송받고 있어 성능저하의 원인이 됨.
  
  분산 DB 간의 성능저하 해결방안

select /*+ driving_site(b) */ channel_id, sum(quantity_sold) auantity_cold
from order a, sales@lk_sales b
where a.order_date between :1 and :2
and b.order_no = a.order_no
group by channel_id
Rows   Row Source Operation
----   ---------------------------------------------
5 SORT GROUP BY
10981   NESTED LOOPS
939      TABLE ACCESS (BY INDEX ROWID) OF 'ORDER'
939       INDEX (RANGE SCAN) OF 'ORDER_IDX2' (NON-UNIQUE)
10981    REMOTE

• order_date에 조건에 해당하는 데이터만 원격으로 보내서 조인과 group by를 거친 결과 집합만 전송받음
• 원격서버가 처리가능하도록 dirving_site 힌트 사용
  
  분산쿼리의 성능을 높이는 핵심은, 네트워크를 통한 데이터 전송량을 줄이는 데 있다

7. 사용자 정의 함수 / 프로시저의 특징과 성능

가. 사용자 정의 함수/프로시저의 특징

create or replace function date_to_char(p_dt date) return varchar2 as
  begin
    return to_char(p_dt, 'yyyy/mm/dd hh24:mi:ss');
  end;
/

나. 사용자 정의 함수/프로시저에 의한 성능 저하 해소 방안