• 대량의 데이터파일을 전송한다면 arraysize 크게하여 fetch call 횟수를 줄여주는것이 유리
• 반대로 적은량의 데이터만 fetch 하다가 멈추는 프로그램이라면 arraysize를 작게 설정하는것이 유리
• arraysie를 증가시키면 네트워크 부하감소 및 서브프로세스가 읽어야할 블록 갯수 감소 효과
  

• ArraySize와 Fetch Count 및 블록 I/O 관계 : 반비례
• ArraySize 를 키운다고 해서 Fetch count 와 블록 I/O가 같은 비율로 줄지 않음
• ArraySize를 무작정 크게 설정한다고 좋은것이 아니며, 일정크기 이상이면 리소스만 낭비하는 결과를 초래할 수 있음

# 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;
/