Db file sequential read

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[편집] Basic Info

오라클은 사용자가 요청한 데이터가 SGA의 버퍼 캐쉬에 존재하지 않을 경우 서버 프로세스가 데이터 파일로부터 해당 데이터 블록을 버퍼 캐쉬로 로드한다. 이를 Conventional Path I/O라 한다. Conventional Path I/O는 멀티 블록 I/O 방식과 싱글 블록 I/O 방식으로 나뉘어지게 된다. 멀티블록 I/O 방식은 한 번에 여러 개의 연속된 블록을 읽어 들이는 작업을 수행하는 I/O이며, 싱글블록 I/O 방식은 한 번에 하나의 블록만 읽어 들이는 작업을 수행하는 I/O 이다.

오라클에서는 Conventional Path I/O가 발생하게 되면 두 가지의 대기 이벤트를 통해 멀티 블록 I/O가 발생하였는지 싱글 블록 I/O가 발생하였는지를 알 수 있도록 하였다. 이 두 가지 대기 이벤트가 db file sequential read / db file scattered read 이벤트이다. 해당 이벤트들은 오라클에서 가장 보편적으로 발생하는 대기 이벤트이다. 데이터 파일에서 블록을 읽으려면 멀티 블록 I/O나 싱글 블록 I/O를 수행할 수 밖에 없기 때문이다.

db file sequential read 이벤트는 싱글블록 I/O와 함께 발생하는 대기 이벤트이다. 한 번의 싱글블록 I/O가 발생할 때마다 한 번의 db file sequential read 이벤트 대기가 발생한다. 싱글 블록 I/O는 파일로부터 하나의 블록을 읽는 모든 작업들에서 발생 가능하다. 보통 인덱스 스캔, ROWID에 의한 테이블 스캔, 컨트롤 파일(Control file), 파일 헤더(File header)를 읽을 때 발생한다.

[편집] Parameter & Wait Time

[편집] Wait Parameters

db file sequential read 대기이벤트의 대기 파라미터는 다음과 같다.

  • P1 : File#
  • P2 : Block#
  • P3 : 블록수 (대부분 1이다. 오라클 7버전에서는 Temp 세그먼트를 읽을 때 1 이상인 경우가 있다. 하지만 direct path I/O기능이 도입된 이후로는 항상 1의 값을 지닌다.)

[편집] Wait Time

I/O 관련 대기이벤트이므로 타임아웃이 발생하지 않으며, 세션은 지정된 개수의 블록에 대한 I/O가 완료될 때가지 대기한다.

[편집] Check Point & Solution

[편집] 오라클의 I/O 레이어 별 db_file_sequential_read 해결책

SGA에 해당 데이터를 로드하는 I/O는 일반적인 작업이다. 그러므로 db file sequential read 이벤트에 대한 대기는 정상적인 대기이다. db file sequential read 대기에 의해 성능이 문제가 생기는 경우는 대부분 비효율적인 인덱스 스캔이나 Chained Row, Migrated Row에 의해 추가적인 I/O가 발생하는 경우이다. db file sequential read 대기가 인덱스와 연관이 있다는 이유로 db file scattered read 대기에 비해 심각하지 않은 대기로 생각하는 경향이 있지만, 인덱스를 사용한다는 것이 항상 FTS(Full Table Scan)보다 좋은 방법은 아니라는 것을 명심해야 한다.

오라클의 I/O 레이어를 기준으로 db file sequential read 대기 문제가 발생하는 경우와 해결책을 논의해 보자.

[편집] 어플리케이션 레이어

비효율적인 SQL 문장이나 비효율적인 인덱스 스캔이 자주 수행되는 경우 불필요한 물리적 I/O로 인해 db file sequential read 대기가 증가할 수 있다. 선택도(Selectivity)가 좋지 않은 인덱스의 사용은 db file sequential read 대기의 주범이다. 부적절한 인덱스의 사용은 I/O 뿐만 아니라 버퍼 캐시의 경합을 유발할 수 있다. SQL 문장이 최적화되고, 인덱스를 효율적으로 사용하는 것만으로 대부분의 문제를 미연에 방지할 수 있다는 사실을 명심하자.

오라클에서 사용가능한 인덱스는 크게 비트리 인덱스(B-Tree Index), 함수 인덱스(Function Index), 비트맵 인덱스(Bitmap Index), 도메인 인덱스(Domain Index)등으로 나눌 수 있다. 각 인덱스별로 다른 특징을 지니며, 특정 상황에서만 성능개선에 도움이 된다. 이들 인덱스의 작동원리를 이해한 후에 인덱스를 생성하는 태도가 필요하다.

통계정보를 항상 최신으로 유지해주는 것 또한 중요하다. DBMS_STATS 패키지를 이용하면 데이터베이스내의 모든 객체에 대해 최적의 방식으로 통계정보를 생성할 수 있다.

간혹, SQL*Plus와 같은 환경에서 수행했을 때는 정상적인 인덱스를 사용하는 SQL 문장이 실제 어플리케이션에서 수행하면 잘못된 인덱스를 사용해서 db file sequential read 대기로 인해 성능이 크게 저하되는 경우가 있다. 동일하게 바인드 변수를 사용하는 환경에서도 이런 문제가 발생한다면, 바인드 피킹(Bind peeking) 기능을 사용하는지 점검해 볼 필요가 있다. 오라클 9i 부터는 기본적으로 바인드 피킹 기능을 활성화해서 사용한다. 이 기능이 활성화되면 바인드 변수를 사용한 SQL문장이라 하더라도, 최초에 수행되는 단계에서 접수된 변수의 값을 이용해서 실행계획을 세우게 된다. 따라서 테스트환경에서 정상적으로 작동했던 SQL 문장이라 하더라도 실제 운영될 때는 최초에 어떤 값이 접수되느냐에 따라 전혀 다른 실행계획을 사용하게 된다. 만일 이런 현상이 발생해서 db file sequential read 대기가 증가하는 것으로 판명되면 _OPTIM_PEEK_USER_BINDS 히든 파라미터의 값을 FALSE로 변경할 것을 권장한다. 이 값을 FALSE로 지정하면 바인드 피킹 기능이 사용되지 않는다.

[편집] 오라클 메모리 레이어

만일 버퍼 캐시의 크기가 지나치게 작은 경우 반복적으로 물리적 I/O가 발생하고 이로 인해 db file sequential read 대기가 증가할 수 있다. 이 경우 free buffer waits 대기가 함께 나타날 확률이 높다. 만일 free buffer waits 대기가 광범위하다면 버퍼 캐시의 크기를 증가시키는 것을 고려해 보아야 한다. 다중 버퍼 풀을 사용해서 버퍼 캐시를 효율적으로 사용하는 것을 항상 고려하자. 다중 버퍼 풀에 의한 db file sequential read 대기의 감소는 db file scattered read 대기를 감소시키는 것과 동일한 원리이다.

인덱스가 효율적으로 생성되었음에도 불구하고 db file sequential read 대기가 기대이상으로 높다면 다음과 같은 사항을 의심해보아야 한다.

- 클러스터링 팩터(Clustering Factor. CF)가 지나치게 높지 않은가?
- Row chaining이나 Row migration이 지나치게 많이 발생하지 않았는가? 
- 높은 클러스터링 팩터

클러스터링 팩터(이하 CF)는 인덱스의 테이블에 대한 군집도(Clustering factor)를 의미한다. CF는 메모리에 단 하나의 블록만을 담을 수 있는 공간이 있다고 가정하고, 인덱스 스캔에 따라 테이블을 얼마나 스캔해야 하는지를 계산한 값이다. 좀 더 정확하게 말하면 인덱스의 리프 블록을 따라가면서 ROWID 값에서 블록번호에 해당하는 1~15번째 자리의 값이 이전 ROWID와 비교하여 바뀌는 회수를 나타낸다. 이 개념을 이해하기 위해 하나의 예를 들어보자. 5개의 블록으로 이루어진 인덱스와 5개의 블록으로 이루어진 테이블이 있다. 하나의 블록에는 4개의 로우가 있다. 따라서 총 로우수는 5*4 = 20개이다. 인덱스를 차례로 스캔하면서 이와 매칭되는 테이블을 읽어오는 경우, 두개의 극단적인 경우가 있을 수 있다.

첫째, CF가 가장 낮은 경우: 하나의 인덱스 블록에 포함된 4개의 ROWID가 하나의 테이블 블록에 모두 포함된다면 인덱스를 통해 테이블을 스캔할 때 인덱스5번 + 테이블5번으로 10번의 스캔만으로 원하는 데이터를 얻을 수 있다. 이 경우 CF는 5(테이블 블록 스캔회수)가 된다. CF의 최소값은 테이블 블록수와 같다.

둘째, CF가 가장 높은 경우: 하나의 인덱스 블록에 포함된 4개의 ROWID가 모두 다른 테이블 블록에 포함된다면 인덱스를 통해 테이블을 스캔할 때 5(인덱스 블록수) + 5(인덱스 블록수)*4(각 인덱스 블록마다 스캔해야하는 테이블 블록수) = 25번의 스캔을 해야 원하는 데이터를 얻을 수 있다. 이 경우 CF는 20(테이블 블록의 스캔회수)가 된다. CF의 최대값은 테이블 로우수와 같다.

만일 메모리 I/O가 없다고 가정하면, CF가 높을수록 테이블 블록을 읽는 회수가 증가하고 이로 인해 물리적 I/O가 증가하게 된다. 즉 CF가 높을 수록 ROWID에 의한 테이블 블록을 읽는 회수가 늘어나고 이와 비례해서 db file sequential read 대기가 증가하게 된다. 버퍼 캐시를 통해 한번 읽은 블록은 이후 추가적인 물리적 I/O가 발생하지 않으므로 CF가 높다고 해서 반드시 SQL 문의 성능이 저하되는 것은 아니다. 하지만 CF값이 높은 인덱스를 넓은 범위로 스캔하게 되면, 그만큼 읽어야 할 테이블 블록수가 늘어나 성능에 치명적인 영향을 줄 수 있다.

ANALYZE 명령문이나, DBMS_STAS 패키지를 이용하면 인덱스의 CF를 구할 수 있다. 인덱스에 대해 통계정보를 생성하면 DBA_INDEXES.CLUSTERING_FACTOR에 CF의 값이 들어간다. 만일 CF가 테이블의 블록수와 유사하다면 좋은 것이고, 로우수와 유사하다면 좋지 않은 징조가 된다. SQL문의 성능 문제의 원인이 CF에 있는 것으로 판단되면, 인덱스 스캔 대신 FTS를 사용하는 것이 대안이 된다. 또는 다른 인덱스를 이용하게끔 유도할 수도 있다. 이 모든 것이 여의치 않은 경우에는 테이블을 인덱스의 정렬순서와 동일한 순서로 재생성함으로써 해결할 수 있다.(CREATE TABLE NEW_TABLE AS SELECT ... FROM OLD_TABLE ORDER BY INDEXED_COLUMN과 같은 명령문을 이용) 하지만 테이블 재생성은 최후의 선택으로 남기는 것이 바람직하다. 다시 한번 말하지만, CF가 좋지 않다고 해서 항상 성능이 느린 것은 아니며 문제의 원인을 정확하게 파악하는 것이 매우 중요하다. 더구나 ASSM과 같은 관리기법을 사용할 경우 기존에 비해서 CF 값이 높아지는 경향이 있으므로 판단에 주의를 요할 필요가 있다.

[편집] Row chaining / Row migration

인덱스의 ROWID를 이용해 테이블을 스캔하는 경우, 해당 로우에서의 Row chaining이나 Row migration에 의해 추가적인 I/O가 발생하고 이로 인해 db file sequential read 대기가 증가하게 된다. ANALYZE 명령을 이용해 통계정보를 생성하면 DBA_TABLES 뷰의 CHAIN_CNT 컬럼에 chaining이나 migration이 발생한 로우 수가 기록된다. V$SYSSTAT 뷰나 V$SESSTAT 뷰를 이용하면 간접적으로 chaining이나 migration이 발생했는지 확인할 수 있다. table fetch by rowid 통계값은 ROWID를 통해 테이블 로우를 스캔한 회수이다. 인덱스를 경유해서 테이블을 페치하는 경우에 증가한다. table fetch continued row 값은 chaining이나 migration에 의해 추가적으로 페치가 이루어진 회수이다. 만일 chaining이나 migration이 여러 블록에 거쳐있으면 블록수만큼 증가하게 된다. Row chaining이나 Row migration에 의해 db file sequential read 대기가 증가하는 경우에는 해당 현상을 해소시켜 주는 것이 해결책이다.

Row chaining은 로우의 크기가 블록보다 큰 경우에 발생한다. 따라서 테이블 정의를 변경하거나 PCTFREE 값을 작게 해서 테이블을 재생성하거나, 혹은 더 큰 크기의 블록을 사용하는 것외에는 Row chaining을 피할 방법은 없다. Row chaining에 대해 export/import 등을 이용해서 테이블을 재구성하는 것은 아무런 의미가 없다. 하지만 PCTFREE 값을 지나치게 작게 하는 경우 또 다른 성능문제를 야기할 수 있으므로, 이에 대한 고려가 필요하다. 한가지 재미있는 것은 Row chaining이 발생했다고 해서 항상 추가적인 I/O가 발생하는 것은 아니라는 것이다. Select ... 에 명시된 모든 컬럼이 만일 처음에 방문한 블록안에 있다고 하면 한번의 I/O만으로 원하는 결과를 얻을 수 있다. 이 경우에는 table fetch continued row 값이 증가하지 않는다. 따라서 Select에서 불필요한 컬럼을 페치하지 않는 습관을 가지는 것이 좋다.

- export 후 import 한다.
- alter table xxx move ... 를 수행한다.
- analyze table xxx list chained rows into yyyy 를 수행해서 migration이 발행한 로우들을 추출하고
해당 로우들에 대해 Delete/Insert 를 수행한다.

위의 작업을 통해 migration을 제거했더라도 문제의 근본원인이 해결된 것이 아니라는 것을 유념해야 한다. 어플리케이션의 패턴이 동일하다면 시간이 지남에 따라 똑같은 문제가 재현되기 때문이다. 따라서 테이블 재구성과 같은 임시방편보다는 PCTFREE 조정, 어플리케이션 보완 등의 근본적인 해결책을 적용하도록 해야한다.

[편집] OS/디바이스 레이어

SQL 최적화나 버퍼 캐시 최적화, 테이블 재구성으로도 문제가 해결되지 않는다면, I/O 시스템 자체의 성능을 의심해 보아야 한다. db file sequential read 이벤트의 대기회수와 대기시간을 비교해서 평균대기시간이 길다면 느린 I/O 시스템이 원인일 가능성이 높다. 앞서 논의한 것처럼 I/O 시스템의 성능문제는 매우 다양한 상황에서 발생할 수 있다. 다양한 팩터를 충분히 조사할 필요가 있다.

V$FILESTAT 뷰를 이용하면 데이터 파일별로 멀티 블록 IO와 싱글 블록 IO의 활동성에 관한 정보를 얻을 수 있다.

SQL> select f.file#, f.name,
s.phyrds, s.phyblkrd, s.readtim, -- 전체 읽기 작업 정보
s.singleblkrds, s.singleblkrdtim, -- Single block IO
(s.phyblkrd - s.singleblkrds) as multiblkrd, -- Multi block IO
(s.readtim - s.singleblkrdtim) as multiblkrdtim, -- Multi block IO
round(s.singleblkrdtim/decode(s.singleblkrds,0,1,s.singleblkrds),3)
as singeblk_avgtim, -- Single block IO 평균대기시간(cs)
round((s.readtim-s.singleblkrdtim)/(s.phyblkrd-s.singleblkrds),3)
as multiblk_avgtim -- Multi block IO 평균대기시간(cs)
from v$filestat s, v$datafile f
where s.file# = f.file#;

만일 특정파일에서 평균수행시간이 지나치게 높게 나온다면 해당 파일이 존재하는 I/O 시스템의 성능을 높임으로써 성능개선이 가능하다.

[편집] Event Tip

[편집] Physical I/O 분류

Physical I/O 분류를 참조하도록 한다.

[편집] Chained Row VS Migrated Row

멀티블록 I/O일 경우에는 Chained rowsMigrated rows의 Scan 방식에 차이가 난다. 멀티블록 I/O 처리 시 Chained rows는 부가적인 싱글블록 I/O가 발생되지만, Migrated rows는 멀티블록 처리시에는 부가적인 싱글블록 I/O가 발생되지 않는다.

많은 데이터를 처리하는 JOB이 수행 중일 때 모니터링을 하다보면 db file scattered read 대기 현상이 발생하고 있는 중간에 db file sequential read 대기 현상이 발생되는 것을 확인할 수 있다. 이는 Full table scan을 수행 중인 테이블에 Chained rows가 있어 싱글블록 I/O가 부가적으로 발생되고 있는 것을 의미하며, 해당 테이블의 Chained rows 비율을 테이블의 총 로우 수와 비교하여 보통 10%이상일 경우에는 제거하여 해당 테이블을 액세스하는 쿼리들의 성능을 개선할 수 있게 된다.

[편집] 왜 Physical I/O 비용이 비싼가?

왜 Physical I/O 비용이 비싼가?를 참조하기 바란다.

[편집] Analysis Case

[편집] 1. Clustering Factor 개선에 의한 db file sequential read 대기 감소

db file sequential 이벤트 발생 시나리오는 다음과 같다.

  • 총 160 만 건의 로우를 가지는 t_db_file_sequential_read(id, name) 테이블을 생성한다. 로우 생성시 id 컬럼에 대해 무작위적으로(Random) 데이터가 생성되도록 한다.
  • t_db_file_sequential_read(id)에 대해 idx_db_file_sequential_read 인덱스를 생성한다. t_db_file_sequential_read.id 컬럼의 데이터가 무작위적인 순서로 생성되어 있는 반면, idx_db_file_sequential_read 인덱스는 id 컬럼에 대해 정렬되어 있다. 따라서 CF값이 매우 높아진다. 즉 CF 값이 불량해 진다.
  • idx_db_file_sequential_read 인덱스를 경유해 t_db_file_sequential_read 테이블을 스캔 하는 쿼리(SQL)를 수행한다. idx_db_file_sequential_read 인덱스의 CF 값이 높기 때문에 많은 수의 테이블 데이터 블록을 읽어 들여야 하고 이 과정에서 Physical reads가 증가한다. 인덱스를 경유한 테이블 블록 스캔은 싱글 블록 I/O를 유발하며, db file sequential read 이벤트 대기로 관찰된다.

위의 시나리오를 그림으로 표현하면 아래 그림과 같다
그림:sequential01.jpg
그림 db file sequential read 이벤트 발생 시나리오

해당 SQL 실행에 대한 아래 표와 같다. db file sequential read 이벤트 대기가 가장 광범위하게 발생함을 알 수 있다.

표 모니터링 결과 그림:sequential_2.jpg

RealTime Client의 Active Session List는 아래 그림과 같다. 하나의 액티브 세션이 db file sequential read 이벤트를 대기하고 있는 것을 확인할 수 있다.
그림:sequential_3.jpg
그림 RealTime Client – Active Session List

Log Viewer의 Session List에서 해당 세션(SID=125)을 관찰한 결과는 아래 그림과 같다. 수행 기간 동안 대부분의 시간을 db file sequential read 이벤트를 대기하는데 소비하고 있음을 확인할 수 있다.
그림:sequential_4.jpg
그림 Log Viewer - Session List

위와 같은 상황에서 db file sequential read 이벤트 대기가 발생하는 이유는 다음과 같다.

  • 세션은 인덱스 키를 경유해 ROWID에 해당하는 데이터 블록을 읽는다.
  • 인덱스의 CF가 불량하기 때문에, 즉 테이블 블록이 인덱스 키의 순서와 무관하게 무작위적으로 흩어져 있기 때문에, 연속적으로 같은 데이터 블록을 읽지 못하고 매번 다른 데이터 블록을 읽는 작업이 빈번하게 발생한다.
  • 이 과정에서 많은 량의 테이블 블록을 읽어 들이게 되고, 이전에 읽은 테이블 블록이 메모리(버퍼 캐시)에서 밀려 나면서, 추가적인 물리적 I/O가 발생하게 되며, 이로 인해 db file sequential read 이벤트 대기가 증가한다.

불량한 CF에 의해 Physical Reads가 증가하는 문제는 CF 값을 개선시킴으로써 해결할 수 있다. CF 값을 개선시키는 가장 좋은 방법은 테이블을 인덱스의 키 순서대로 재구성(Reorganization)하는 것이다. 다음과 같은 방법으로 재구성할 수 있다.

CREATE TABLE t_db_file_sequential_read 
AS SELECT id, name FROM t_old_db ORDER BY id;  ID 컬럼 기준 정렬
CREATE INDEX idx_db_file_sequential_read ON t_db_file_sequential_read(id);

테이블을 인덱스의 키 순서로 재 구성한 후의 시나리오는 아래 그림과 같다. 그림:sequential_5.jpg
그림 db file sequential read 대기 개선 시나리오

성능 개선 후의 자체 모니터링 결과는 아래 표와 같다. 아래 표에서 db file sequential read 이벤트의 대기 시간이 31(cs)로, 성능 개선 전인 3772(cs)이었던 것에 비하면 1/100 이상 크게 줄어든 것을 확인할 수 있다.

표 모니터링 결과
그림:sequential_6.jpg


[편집] 2. 싱글 블록 I/O 과다로 인한 성능 저하 분석 사례

선택도가 나쁜 인덱스를 통한 과다한 싱글 블록 I/O 요청은 시스템의 성능을 저하시키는 주요 요인이다. Oracle DBMS의 성능진단/분석 툴인 Maxgauge(맥스게이지)를 활용하여, 과다한 싱글 블록 I/O 요청에 의한 성능 저하 문제의 원인을 규명해 보고자 한다.

[편집] 성능저하구간의 확인

[Trend Analysis]화면에서 08시30분 이후부터 CPU 사용률과 Active Session 수, 대기 시간이 크게 증가하는 것을 확인할 수 있다.

■ CPU사용률의 추이그래프 그림:Case7_1.jpg

■ Active Session수의 추이그래프 그림:Case7_2.jpg

■ Wait Events의 추이그래프(Wait Time or Waits) 그림:Case7_3.jpg

[편집] 대기이벤트의 검출 및 분석

문제 구간의 대기이벤트 목록은 아래 그림과 같다. db file sequential read 이벤트 대기가 광범위하게 발생하는 것을 확인할 수 있다. 그림:Case7_4.jpg

[편집] 대기이벤트 발생원인의 조사

db file sequential read 이벤트 대기시간과 physical reads 통계값을 비교하면 아래 그림과 같다. 두 값이 거의 동일한 패턴을 보인다. 이것은 싱글 블록 I/O에 의한 물리적 I/O 증가가 성능 저하 현상의 근본 원인임을 말해 준다. 그림:Case7_5.jpg

[편집] 세션 및 SQL의 분석을 통한 문제원인의 규명

[SQL List] 화면을 이용해, 문제 구간에서 물리적 I/O를 수행한 SQL 문장을 조회하면 아래 그림과 같다. 하나의 SQL 문장이 대부분의 물리적 I/O를 수행하는 것을 확인할 수 있다. 즉 이 SQL 문장이 성능 저하의 근본 원인이다. 따라서, 해당 SQL문장을 적절히 튜닝함으로써 싱글 블록을 줄이면 성능 저하 현상은 자연스럽게 해결된다. 그림:Case7_6.jpg

[편집] 결 론

성능 저하 현상(db file sequential read 이벤트 대기) →

비효율적인 SQL에 의한 과다한 싱글 블록 I/O →

SQL 튜닝을 통해 I/O 요청을 줄여야 함

[편집] 3. 일중 지속적으로 발생하는 db file sequential read 분석

모니터링 대상 인스턴스에서 “db file sequential read” 대기의 대기시간이 가장 많다. 그림:6_4_1.jpg

“db file sequential read” 대기는 Logging 구간에서 평균 6secs/sec 정도로 나타난다. 그림:6_4_2.jpg

“db file sequential read” 대기이벤트는 일중 지속적으로 발생하고 있다. 그림:6_4_3.jpg

문제 인스턴스의 single block read에 대한 DISK I/O Performance는 다음과 같이 측정할 수 있다.

single block read performance 
            = 24시간동안의 single block read 대기시간 / 24시간동안의 single block read request
            = time waited (diff) / total waits (diff)
            = 536,712 / 211,805,699
            = 0.0025 sec
               1개의 single block i/o 대기시간은 0.0025초임 (일반적인 평균은 0.01~0.004)

single block read에 대한 DISK I/O Performance는 0.0025초로 평균 이상이므로, “db file sequential read” DISK I/O 성능은 큰 문제가 없다.

즉, 튜닝을 통해 single block read request의 절대량을 줄이는 것이 필요하다.

1) SQL Tuning을 통한 block i/o 절대량 감소필요
2) 건수에 비해 blevel이 큰 index check 
    (blevel 3이상인 index중에 건수가 1000만 건 이하인 것 위주로 check)
3) row chaining check

1) SQL Tuning을 통한 block i/o 절대량 감소를 위해서 MaxGauge의 Wait Detail에서 해당 대기이벤트의 Wait 시간이 긴 SQL 순으로 튜닝한다.

그림:6_4_4.jpg

2) 건수에 비해 blevel이 큰 index check는 해당 시스템에 Online으로 접속하여 dictionary check가 필요하다.

  -  DBA_INDEXES.NUM_ROWS & DBA_INDEXES.BLEVEL를 체크한다.

3) row chaining check는 “table fetch by continued row” 지표를 통해 체크한다.

그림:6_4_5.jpg

   평균적으로 100건/sec 이므로, row chaining이 많이 발생한 테이블을 체크한 후
   ( 체크 방법: DBA_TABLES.CHAIN_CNT <- 해당 정보는 DBMS_STATS 수행 시에는 생성되지 않으며,
                    Analyze 수행 시에만 생성됨)  row chaining 제거가 필요하다.