데이터와이즌, 데이터를 잘 다루다!

불완전한 비용기반 옵티마이저인 FIRST_ROWS 모드 사용으로 인해 잘못된 실행계획이 수립되는 경우, 온전한 비용기반 옵티마이저 모드인 ALL_ROWS 또는 FIRST_ROWS_N 모드를 사용하여 개선한다. 개선 전 (문제 상황) 점번호 컬럼 조건이 인덱스 access 조건이 되지 못하여 총계정기본 테이블 및 인덱스 액세스 량이 과다해 짐 SQL문을 확인해 보면, 기준일자 컬럼 조건절 외에 점번호 컬럼 조건절도 인덱스 access 조건이 되어야 총계정기본 테이블  또는 인덱스 액세스 범위를 줄일 수 있는데, 실행계획이 그렇게 수립되지 못함 개선 방안 (문제 원인) 기준일자와 점번호 컬럼이 선두인 인덱스가 있음에도 불구하고 점번호 결과집합을 만드는 IN 서브쿼리 부분이  먼저 실행되지 못한 것은 FIRST_ROWS 모드 특성 때문임. FIRST_ROWS 옵티마이저 모드는 ORDER BY 오퍼레이션을 회피할 수 있는 대안을 항상 (비용 산정 않고) 선택하는데, 여기서는 PK 인덱스를 범위 스캔하는 것이 그 대안이었음 (개선 방안) FIRST_ROWS 옵티마이저 모드 대신 온전한 비용기반 옵티마이저인 ALL_ROWS 모드를 사용하도록 힌트 사용함 개선 후 (개선 결과) IN서브쿼리 부분이 먼저 수행되었고, 총계정기본 데이터 액세스 량이 개선전 보다 현저히 감소함 조건절 정보(Predicates Information)을 통해, 기준일자 조건절과 점번호 조건절이 모두 인덱스 access 조건이 된 것을  확인할 수 있음

컬럼의 부분값 검색을 위해 SUBSTR 함수 같은 예외적인 로직을 사용함으로써 인덱스를 사용하지 못하고, 최적 실행계획이 수립되지 않는 경우, 그런 예외 로직을 개선한다. 개선 전 (문제 상황) 관리내역 데이터를 과다하게 액세스함 (문제 원인) 암호화고객실명번호, 접촉전화번호 컬럼 조건절이 액세스 범위를 크게 줄일 수 있으나, 그 컬럼이 선두인  인덱스가 없고, 만약 있더라도 조건절의 ‘예외처리’로직으로 인해 그런 인덱스를 사용할 수 없는 상태임 참고로, 예외로직은 암호화고객실명번호 값이 NULL이면 암호화고객실명번호 컬럼 대신 고객실명번호 컬럼을 사용하라는 로직이며, NVL, DEDODE, OR 구문을 사용하면 적절한 인덱스가 있더라도 옵티마이저가 최적 실행계획을 수립하기 어려움 개선 방안 (개선 방안) 암호화고객실명번호, 접촉전화번호 각각 선두인 인덱스 2개를 생성함 (개선 방안) 인덱스 사용을 어렵게 하는 예외로직을 수정함 테이블 데이터를 조사해 보면 암호화고객실명번호 값이 NULL이면서 고객실명번호 값이 NULL이 아닌 것은 전체 15백만 건 중 1600여건(약 0.1%)으로 확인되며, 게다가 그 값은 암호화 불가한 비정상적인 값이고 조회할 가능성이 없는 값이어서 결국 예외로직이 무의미한 것으로 판단함 (따라서, 데이터 정제 대상임) 개선 후 (개선 결과) 암호화고객실명번호 컬럼 조건절 및 접촉전화번호 컬럼 조건절이 인덱스 access 조건이 되면서 액세스량이  개선 전에 비해 현저히 감소함

조회 요건과 데이터 특성을 고려하여 데이터 유무 확인을 위한 1건 찾는 로직을 개선한다. 개선 전 (문제 상황) 상각내역_PK, 입력기본_PK 인덱스를 과다하게 액세스함 기준일자가 입력되지 않거나, 입력되더라도 넓은 범위인 경우 SKIP SCAN이 성능에 도움이 될 수 있으나, 상각내역_PK,  입력기본_PK 인덱스 모두 1건 또는 0건을 찾기 위해 너무 많은 인덱스 블록을 읽음(각각 7983블록, 4281블록 읽기) (문제 원인) 데이터 유무 확인 로직이 비효율적임 개선 방안 (개선 방안) 기준일자, 계좌번호 컬럼 순으로 구성된 상각내역_PK를 사용하여 사용자 입력 계좌로 데이터를 1건을 찾을 때,  과거부터 찾는 것 보다 최근부터 찾는게 평균적으로 더 빨리 찾을 수 있음을 전제로, 과거->최근 탐색(순방향 탐색,  index_ss힌트 사용) 대신 최근->과거 탐색(역방향 탐색, index_ss_desc힌트 사용)하도록 함(사실 계좌번호+기준일자로  구성된 신규 인덱스를 만드는게 더 확실한 개선 방안임) (개선 방안) 입력기본_PK 사용 유도한 index 힌트를 삭제하여, 자연스럽게 계좌번호 선두인 IX02 인덱스가 사용되도록 함 개선 후 (개선 결과) 2개 인덱스 액세스량이 개선 전 보다 현저히 감소함

옵티마이저가 잘못된 조인 방법을 선택한 경우, USE_NL, USE_HASH, USE_MERGE 등의 힌트를 사용하여 조인 방법을 바꿀 수 있다. 개선 전 (문제 상황) 온라인 처리 SQL문인데, 송금기본_IX04 인덱스를 과다하게 액세스함 (문제 원인) 온라인 처리에 부적합한 해시조인(HASH JOIN)이 수행됨 일반적으로 해시조인이 대량 배치 처리에 적합한 조인 방법이나, 온라인 처리이더라도 예외적인 경우  해시조인이 NL 조인보다 유리할 수 있음 개선 후 (개선 방안) "USE_NL(A B)" 힌트 사용하여 해시조인 대신 NL조인 수행되도록 함 (개선 결과) 송금기본 데이터 액세스량이 크게 감소함

옵티마이저가 잘못된 액세스 방법을 선택한 경우 INDEX, INDEX_DESC,  INDEX_SS, INDEX_FFS, FULL 힌트 등을 사용하여 액세스 방법을 바꿀 수 있다. 참고로, 인덱스 신규 생성이나 컬럼 추가는 인덱스 설계 변경으로 구분하고, 단순히 힌트를 통해, 있는 인덱스를 사용하도록 하는 것은 액세스 방법 변경으로 구분한다. 개선 전 (문제 상황) 고객관계 데이터를 과다하게 액세스함 (문제 원인) 주고객번호 컬럼 조건절이 액세스 범위를 크게 줄일 수 있고, 그 컬럼이 선두인 PK 인덱스가 있음에도  불구하고, 상대적으로 비효율적인 액세스 방법인 IX02 인덱스 사용 실행계획이 수립되었음 참고로, PK인덱스 사용하는 것과 IX02 인덱스 사용하는 것 모두 비용이 4로 동일하게 나오는데, (힌트를 주지 않는다면)  옵티마이저는 이런 경우 알파벳 정렬 순으로 앞에 있는 인덱스를 선택함 (비용계산에 중요한 요소인 컬럼 distinct 값은  아래와 같음)      개선 후 (개선 방안) PK 인덱스가 사용되도록 ‚INDEX(고객관계(주고객번호))‛ 힌트를 추가함 (개선 결과) 주고객번호 컬럼 조건절이 인덱스 access 조건이 되면서 인덱스 및 테이블 액세스량이 현저히 감소함

주요 조건절 컬럼으로 구성된 인덱스는 온라인 SQL 최적화에 가장 기본적이고 필수적인 도구이다. 만약, 인덱스 액세스 범위를 크게 줄일 수 있는 어떤 컬럼 조건절이 인덱스 filter 조건이라면, 인덱스를 신규 생성하거나, 현 인덱스에 컬럼을 추가하여 인덱스 access 조건이 되도록 하면 액세스 량이 크게 감소한다. 개선 전 (문제 상황) 결과 건수에 비해 거래요약_IX01 인덱스 액세스 량이 과다하고, 처리에 많은 시간이 소요됨 (문제 원인) 인덱스 정보를 확인해 보면, 인덱스 액세스 범위를 크게 줄일 수 있는 처리기준일자 조건이 인덱스 filter  조건으로 사용되었음을 알 수 있음(인덱스 구성 상 처리기준일자 앞 컬럼 인 재판매유형코드 조건절이 없기 때문임) 개선 후 (개선 방안) 처리기준일자 조건절을 인덱스 filter 조건 대신 access 조건이 되도록 하기 위해‚ "INDEX(T 거래요약_IX08)"   힌트를 추가함 (개선 결과) IX01 인덱스 대신 IX08 인덱스를 사용하면서 거래요약 인덱스 액세스량이 개선 전 57396개 블록에서, 개선 후  2199개 블록으로 크게 감소함

주요 조건절 컬럼으로 구성된 인덱스는 온라인 SQL 최적화에 가장 기본적이고 필수적인 도구이다. 만약, 액세스 범위를 크게 줄일 수 있는 어떤 컬럼 조건절이 테이블 filter 조건이라면, 인덱스를 신규 생성하거나, 현 인덱스에 컬럼을 추가하여 인덱스 access 또는 filter 조건이 되도록 하면 액세스 량이 크게 감소한다.  개선 전 (문제 상황) 거래내역 테이블을 15513회 만큼 액세스 후 결과 건수가 4362로 감소하였는데, 테이블 액세스에 많은 시간이  소요됨 (문제 원인) 데이터 확인을 통해 구분코드 컬럼 조건절이 15513에서 4361건으로 감소하게 된 결정적인 요인임을 확인함 개선 후 (개선 방안) 구분코드 조건절이 인덱스 access 조건이 되도록 현 IX05 인덱스에 구분코드 컬럼 추가함    변경 전 : 고객번호, 거래일자    변경 후 : 고객번호, 거래일자, 구분코드 (개선 결과) 인덱스 변경 반영함에 따라 구분코드 컬럼 조건절이 인덱스 access 조건이 되었고, 그 결과 테이블 랜덤 액세스 횟수가 15513회에서 4735회로 감소하였으며, 소요시간도 크게 감소함

선택적인 조건절을 사용하는 대신, AP로직을 통해 SQL문 조건절을 동적으로 구성(흔히 Dynamic SQL 이라고 함)하여 옵티마이저가 최적 실행계획을 수립하기 용이하도록 할 수 있다. 개선 전  (문제 상황) 문서관리기본 및 신분증기본의 테이블/인덱스 블록을 많이 액세스함 (문제 원인) 문서관리기본 및 신분증기본 테이블 모두 (액세스 범위를 크게 줄일 수 있는) 계좌번호 컬럼 선두인  인덱스가 있으나, 쿼리문에 사용한 INDEX 힌트와 OR 구문으로 인해 그 인덱스를 사용하지 못함 개선 방안 (개선 방안) 조건절이 AP를 통해‘dynamic’하게 추가되므로 특정 인덱스를 고정적으로 사용하는 대신, 만들어진 조건절에  따라 옵티마이저가 최선의 인덱스를 선택할 수 있도록 현 index 힌트를 삭제함 (개선 방안) 실명번호 값 입력시  "A.실명번호 = :변수" 조건절을 추가하듯, 계좌번호 값 입력 시 "A.계좌번호 = :변수"  조건절 추가하도록 AP 로직을 수정하고, 대신 현재 고정적으로 사용되고 있는 OR 조건절은 쿼리문에서 삭제함 개선 후 (개선 결과) X11 및 X03 인덱스가 사용되고, 계좌번호 조건절이 access 조건이 되면서 액세스 량이 현저히 감소함 위 결과는 SQL문에 OR 구문으로 작성된 ‘복잡한’ 계좌번호 조건절 대신 ‚계좌번호 = :변수‛와 같이 심플한 조건절을  사용할 때, 수립되는 실행계획과 트레이스 결과임 참고로, 운영DB에서는 실명번호 조건절이 있는 것과 없는 것 2개 SQL문이 실행되고 있으며, 현 index 힌트를 제거하더라도  실명번호 조건절이 있는 경우에는 개선 전과 같이 X07과 X01 인덱스 사용하는 것을 확인함

복잡한 선택적 조건절을 사용하는 경우, 옵티마이저가 최적 실행계획을 수립하기 어려운데, 쿼리 수정 또는 USE_CONCAT 힌트 사용을 통해 OR EXPANSION을 유도하거나, UNION ALL 구문으로 입력 케이스별로 실행계획을 강제적으로 분리시키는 방법을 사용하여 성능을 최적화 한다. 개선 전 - 트레이스 결과 (문제 상황) 외환기본_IX08 인덱스 액세스에 대부분의 시간이 소요됨 IX08 인덱스가 거래일자와 과목코드 순으로 구성되어 있어서, 거래일자 범위 조건은 인덱스 access 조건이 되었지만,  과목코드 조건을 인덱스 filter 조건이 됨 (참고로, 과목코드 값이 ‘EX’인 것은 전체 로우의 약 5%임) 개선 전 - SQL문 (문제 원인) 고객번호 및 관리점번호 입력값이 필수가 아니어서, 해당 값 입력 여부에 따라 최적 실행계획이 달라질 수  있는데, 앞의 실행계획을 보면, 고객번호(:B3) 입력 여부 따라 실행계획이 분리되었음 (CONCATENATION/FILTER 오퍼레이션  등장) INDEX 힌트를 사용하여 항상 IX08 인덱스가 사용되도록 했는데, 이 INDEX 힌트를 제거하더라도 최적 실행계획이 수립되지  않았음 개선 방안 (개선 방안) 고객번호와 관리점번호 입력 여부에 따른 3가지  경우 각각을 구분하여 처리할 수 있도록 UNION ALL 사용 이때, 배타적인 3개 집합은 반드시 상호 배제되고 전체를  포괄해야 함 (MECE, Mutually Exclusive, Collectively Exhaustive) 개선 후 (개선 결과) 3가지 경우 각각에 최적인 실행계획이 수립됨(각각 IX01, IX04, IX08 인덱스를 사용) (개선 결과) 본 사례는 고객번호가 입력된 경우로서 IX01 인덱스가 사용되었고, 개선 전에 비해 액세스량/소요시간이  현저히 감소함

복잡한 선택적 조건절을 사용하는 경우, 옵티마이저가 최적 실행계획을 수립하기 어려운데, 쿼리 수정 또는 USE_CONCAT 힌트 사용을 통해 OR EXPANSION을 유도하거나, UNION ALL 구문으로 입력 케이스별로 실행계획을 강제적으로 분리시키는 방법을 사용하여 성능을 최적화한다. 개선 전 (문제 상황) PK 인덱스가 참조번호+거래일련번호로 구성되었음에도 불구하고, 거래일련번호 컬럼 조건절이 인덱스 access  조건이 되지 못하고 인덱스 filter 조건이 됨 (문제 원인) 조건절 로직에 따라 :b1값이 입력되는 경우와 입력되지 않는 경우의 실행계획이 분리될 필요가 있었는데(OR  EXPANSION 실행계획이 수립될 수도 있었는데), 현재의 조건절은 그렇게 작성되지 않았음 개선 후 (개선 방안) OR EXPANSION 실행계획이 자연스럽게 만들어질 수 있도록 조건절을 수정함 (개선 결과) :b1 변수값 입력 여부에 따라 실행계획이 분리되었고(CONCATENATION 및 FILTER 오퍼레이션  등장), 개선 전 보다 액세스량이 현저히 감소함

옵티마이저는 Query Transformation 기능 중 하나인 OR EXPANSION(실행계획 분리)을 통해 선택적인  조건절을 최적화할 수 있는데, 그런 기능이 적용된 실행계획이 오히려 성능에 불리한 경우, NO_EXPAND,  INDEX 힌트 등을 통해 OR EXPANSION 기능이 작동하지 않도록 한다. 개선 전 (문제 상황) 고객번호 조건으로도 액세스해야 할 데이터 건수가 충분히 줄어들지 않았고, 전문발송내역 테이블과  조인하면서 결과 건수가 급감함 (문제 원인) :고객번호 값이 입력되면 외환기본 테이블이 먼저 액세스되고, :고객번호가 입력되지 않으면 전문발송내역  테이블이 먼저 액세스되도록 실행계획이 분리되었는데(오라클 옵티마이저의 OR EXPANSION 기능), :고객번호가  입력되더라도 전문발송내역이 먼저 액세스 되는 것이 성능에 유리함을 확인함 개선 후 (개선 방안) :고객번호 값 입력되더라도 전문발송내역 테이블이 먼저 액세스되도록(OR EXPANSION 되지 않도록)  NO_EXPAND 힌트를 추가함 (LEADING 힌트로도 가능) (개선 결과) CONCATENATION 오퍼레이션이 사라지고, :고객번호 값 입력 여부 상관없이 전문발송내역 테이블을 먼저 액세스하는 실행계획이 수립되었으며, 개선 전보다 액세스 량이 크게 감소함

주요 조건절이 2개 테이블에 분산된 경우, 인덱스만으로 2개 테이블을 조인하고, 주요 조건절을 모두 사용한 후, 그외 사용해야 할 조건절과 컬럼값 획득을 위해 테이블을 액세스하도록 함으로써 테이블 액세스량을 크게 줄인다(여기서는 오라클의 INDEX JOIN과는 다른 개념으로 사용함) 개선 전 (문제 상황) 거래기본 및 계약기본 데이터를 많이 액세스하였고, 거래기본, 계약기본, 상품기본 순서대로 조인하면서  결과건수가 216천건->2124건->698건으로 점차 감소함 (최종 30건은 그룹핑 결과임) (문제 원인) 액세스 범위를 크게 줄일 수 있는 조건절에 처리기준일자 컬럼이 포함되어 있으나 그것 만으로는 액세스 범위를 충분히 줄이지 못해 거래기본 테이블 액세스량이 많음 개선 방안(1/2) (수정 전) 216천건 만큼의 거래기본 테이블 랜덤 액세스가 성능에 문제됨 (수정 후) 거래기본 테이블에 대한 랜덤  액세스를 줄이기 위해, 인덱스 만으로  상품기본과 1차 조인하고, 그 이후 거래기본  테이블을 액세스하도록 함(756회로 크게  감소) 개선 방안(2/2) (개선 방안) SQL문 수정을 통해 거래기본 인덱스와 계약기본 인덱스 조인으로 결과 집합 범위를 충분히 줄인 후 거래기본 테이블을 랜덤 액세스 하도록 함으로써 거래기본 테이블 랜덤 액세스 량과 소요시간을 많이 줄어들도록 함 인라인뷰 CS 내 처리 시 거래기본 테이블 랜덤 액세스가 없도록 하는 것이 튜닝의 주된 포인트이며, 이를 위해, 인라인뷰 CS 내  사용 가능한 거래기본 테이블 컬럼은 처리기준일자, 참조번호 등 IX12 인덱스 구성 컬럼으로 제한해야 함 개선 후 (개선 결과) 새롭게 작성한 인라인 뷰 처리 결과 756건 만큼만 거래기본 테이블을 랜덤 액세스함 인라인뷰 부분으로서, 뷰 바깥의 거래기본 부분과 합치더라도 개선 전 보다 액세스량과...

옵티마이저의 비용 추정 오류 또는 조건절(조인 조건 포함)에 맞는 인덱스 부재로 인해 최적 조인 순서의 실행계획이 수립되지 않았다면, LEADING 힌트 사용, PUSH_SUBQ 힌트 사용, 인덱스변경, SQL 로직 수정 등의 방법을 통해 최적 조인 순서를 유도한다. 개선 전 (문제 상황) 로우를 읽고, 조인 하면서 많은 데이터/인덱스 블록을 액세스하였는데, 내역 테이블 액세스 후에 결과 건수가  크게 줄어듦 개선 후 (개선 방안) LEADING 힌트로 ‘내역’ 테이블을 먼저 액세스하도록 함 (개선 결과) ‘내역’ 테이블 액세스 결과 0건이 되었고, 이후 요약내역 테이블을 액세스 하지 않게 됨

수천 건 이상의 데이터를 읽은 후 MAX/MIN 함수를 통해 최종 또는 최초 이력을 얻는 것이 당연할 수도 있겠지만, 다양한 방법을 통해 최종 또는 최초 데이터에 직접 도달하는 효율적인 방안이 있을 수 있다. 개선 전 (문제 상황) 넓은 범위의 데이터를 액세스함(그룹핑 전까지 12천건, 그룹핑 후에도 3.4천건) 개선 방안   (문제 원인) 작성된 SQL 로직과 트레이스 결과를 분석해 보면, 거래상세 테이블에서 계좌별 최종 이력 데이터 1건만  액세스하는 것이 아니라, 계좌의 모든 이력을 액세스하고, GROUP BY 구문을 통해 최종 이력 데이터를 선택했음을 알 수  있음 (개선 방안) 계좌별 최종 이력 데이터 1건만 액세스하도록 로직을 개선함 개선 후 (개선 결과) 최종 순번 찾는 로직 부분의 액세스량이 개선 전보다 현저히 감소함 참고로 수정 후와 같이 SQL을 작성하고, 조건에 부합하는 인덱스가 있으면, ‚INDEX RANGE SCAN (MIN/MAX)와 FIRST FOW‛  오퍼레이션이 등장함

ORDER BY, GROUP BY, 분석함수, 해시조인(building) 등은 액세스 해야 할 데이터 범위 모두를 액세스한 후 결과를 리턴할 수 있는 "전체범위 처리" 오퍼레이션이어서 "부분범위 처리"의 잇점을 누릴 수가 없는데,  SQL 수정 및 인덱스 변경 등을 통해 "부분 범위 처리" 가능한 실행계획이 수립되도록 한다. 참고로, '부분범위 처리"는 결과 로우 전체를 한꺼번에 리턴하는 대신 FETCH 단위로 리턴할 수 있는 기능이며, Multi-Tier 환경에서는 SQL문에 ROWNUM 조건절을 사용하고, 전체 범위 처리 오퍼레이션이 없어야 그 잇점을 누릴 수 있다. 개선 전 (문제 상황) 넓은 데이터 범위를 액세스함(STOPKEY 오퍼레이션 전까지 약 24천여건을 유지) (문제 원인) SORT ORDER BY 오퍼레이션 후 STOPKEY를 적용하여 101건을 리턴하지만, 24천여건을 만들기 위한  데이터/인덱스 액세스량은 줄이지 못함 개선 방안 (수정 전) ORDER BY 절로 인해 전체 범위 처리되어서 넓은 데이터 범위를 액세스함 (수정 후) 전체 범위 처리 영역을 최소화하기 위해 먼저 액세스 되는 테이블에만 ORDER BY 적용하도록 SQL문 ‘구조’를  변경함 참고로, 먼저 액세스되는 데이터 집합에 대해서만 ORDER BY를 적용하더라도 이후 NL조인이 수행되면 ORDER BY가 유지됨(단, batched I/O가 아니어야 함) 개선 후 (개선 결과) 전체 범위(24천건) 처리 영역이 줄어들었고, 읽은 전체 블록도 종전 82천건에서 2천여건으로 크게 감소함

시계열성으로 쌓여진 (대용량) 거래 내역을 특정 고객번호로 조회하면, 액세스할 블록이 거의 로우당 1개인 경우가 일반적인데, 이때 고객번호별로 데이터를 모아두는 정렬재구성을 하면, 액세스해야 할 블록이 크게 감소한다. 참고로, 온라인 업무나 업무 배치 처리 과정에서 자연스럽게 데이터가 흩어진게 아니고, 차세대/고도화 사업 데이터이행 과정에서 데이터가 크게 흩어지는 경우도 빈번하다. 개선 전 (문제 상황) 평이한 실행계획이나 넓은 데이터 범위를 액세스하면서 10초 가량 소요됨(특히 계좌가 많은 기업고객인 경우) (문제 원인) 16천 여건의 결과 모두를 리턴해야 하므로 절대적으로 많은 시간이 소요될 수 밖에 없고, 특히 클러스터링  팩터가 좋지 못해 읽은 로우수에 비해 읽은 블록도 많은 편임 - 인덱스 스캔 결과가 16899건 인데, 테이블 (12182-281)  블록을 읽었음 참고로, 조건절 정보(Predicate Information)를 볼때, IX04 인덱스는 고객번호+...+여신활동구분코드로 구성되어 있음을 추정할 수 있음 문제 원인 분석 기업고객의 계좌가 한꺼번에 개설되지 않고 시차를 두고 개설되었다면 해당 고객의 계좌 정보는 각기 다른 데이터  블록에 저장됨 참고로 하나의 데이터 블록은 (보통) 8K byte 크기이며, 대개 100건 이상의 로우가 저장될 수 있음 참고로, 차세대 또는 통합 프로젝트의 데이터이행 과정을 통해서도 데이터가 크게 흩어질 수 있음 계좌 데이터가 저장된 모든 데이터 블록을 액세스 해야 하는데, 여신계약기본과 같은 대형 테이블의 데이터 블록이 DB 캐시에 있을 확률은 (보통) 10% 내외이므로 거의 계좌 건수 만큼 물리 읽기를 해야 함 이 DB의 경우 물리 읽기 1회 당 1ms~5ms 정도 소요되므로, 10000건의 계좌를 읽는데, (DB 서버 구간에서만) 10~50초가 소요될 수 있음 개선 방안 계좌가 많은 ...