2. 컴퓨터 이야기/데이타베이스

Unique 인덱스를 Full Scan 하는 플랜이 떠져서 확인했더니, 아차차.. ㅠ.ㅠ

래빗 크리스 2010. 9. 13. 11:28

역시 튜닝은 DB 모델링 시기부터 진행되어야 함을 다시 한번 뼈저리게 되새기는 기회가 되었습니다.
일단 아래 쿼리를 보시죠. (참고로 DB 클라이언트는 WareValley 사의 Orange 입니다).
두 테이블을 조인해 오는데, Hash Join 이 됩니다. 이부분은 어쩔 수 없는 부분이라 지금 이야기 하는 주제는 아닙니다.
양 테이블 모두 데이타가 천만건 단위로 쌓여 있기 때문입니다.
아래 쿼리는 두번째 테이블(b) 을 Full Scan 하기 때문에 좋은 구조는 아닙니다.
힌트를 주더라도 Full 스캔되는 것은 마찬가지 입니다. 물론 한쪽은 인덱스를 탑니다만..



그래서 일단 exists 로 b 테이블을 내려 보내고 exists 문 안에서는 힌트를 주었습니다.
힌트는 b 테이블에 a 테이블과 조인하는 키가 unique 인덱스로 존재하기 때문입니다.
그런데, 결과는 인덱스를 Full Scan.. 이런이런.. 치사하게 옆에 Unique 라고 나오져.
Unique 인덱스인데도 Full Scan 을 하는 오라클, 네가 밉다.. ㅠ.ㅠ (데이타가 많아서 라고 하기에는 아쉬움이 남습니다)
아, where 절에 ||'' 를 한 것은 혹시나 이넘 때문에 영향을 받나 해서 넣은 것인데 있으나 없으나 동일한 결과가 나옵니다.



혹시나 해서 힌트를 빼 보았습니다. 그랬더니, 다른 인덱스를 Fast Full Scan 하네요.
아시다시피.. Fast Full Scan 이 Full Scan 보다는 빠르죠.
위의 플랜과 비교해 보면 Unique 인덱스는 Full Scan 하면서, 우찌하여 Non-Unique 인덱스를 Fast Full Scan 하냐구요..
참, 고민이 많습니다. 이거 뭐가 문제인거야.. 크윽..
Full Scan 이 나오는 Unique 인덱스는 구성요소가 조인이 되는 키 하나만으로 구성되고,
Fast Full Scan 이 되는 Non-Unique 인덱스는 2개의 컬럼으로 구성되고 조인되는 키도 첫번째가 아니고 두번째..
(참고로, 상기 쿼리로 4천여건이 잡힙니다. 기본 데이타는 천만 단위이고요..)



도대체 어떤 인덱스인지 확인하려고 보았더니..
왼쪽에 보이는 인덱스는 Unique 로 생성되어 있고, 오른쪽은 Non-Unique 인덱스입니다.
7번 Tablespace Name 을 보시면 왼쪽은 ...Data, 오른쪽은 ...Idx..
아아, 정말 이런거였군요.. ㅠㅠ
...Data 로 생성된 테이블스페이스는 기본 데이타용이고,
...Idx 로 생성된 테이블스페이스는 인덱스용으로 만들어 놓은 테이블스페이스였습니다.
정말, 어떻게 할 수가 없는 상황이네요. 인덱스를 우찌하여 데이타가 잔뜩 쌓이는 테이블스페이스에 만들어 놓은 것인지.
그런데, 이건 시스템이 만들어 놓은 인덱스라.. 물론, 사용자가 만들어도 이런 실수를 할 수 있겠지만..
 



그나저나, 저 테이블에는 데이타가 계속 쌓여만 가고 이미 천만건 단위의 rows 가 생성되었으니,
인덱스를 재생성하면 시스템 장애가 발생할 정도로 일파만파의 테이블.
언제 시스템 정지하고 정비할때 작업을 해야 할 듯.. 쩌업.