database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
ㆍOracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Oracle Q&A 21911 게시물 읽기
No. 21911
특정 테이블의 조회가 느립니다.
작성자
궁금
작성일
2005-03-04 16:25ⓒ
2005-03-04 16:27ⓜ
조회수
6,195

빈번한 추가와 삭제가 이루어지는 테이블이 있습니다.

하루에 백만건 정도 추가했다가 처리한 뒤에 삭제합니다.

어느 날 갑자기 느려졌습니다.

단순히 그 테이블에

select * from 테이블

이런 쿼리만 던져도 1분정도 걸립니다.

이런 경우 문제점을 확인할 수 있는 방법을 아시는 분 조언을 부탁드립니다.

감사합니다.

이 글에 대한 댓글이 총 7건 있습니다.

에널라이즈 해보세요. ^^

 

공샐님이 2005-03-04 16:36에 작성한 댓글입니다. Edit

빈번한 추가/삭제 작업이 대량으로 발생하는 경우..

해당테이블을 analyze하는 것만으로 부족할 때가 있습니다

왜냐면 해당 테이블에 걸려 있는 Index의 스큐현상이 발생하기

때문입니다(스큐현상이란 인덱스는 기본적으로 밸런스 트리이기

때문데 잦은 변동으로 인해 depth가 깊어지면 인덱스를 사용하여

검색하는 쿼리가 효율성이 떨어지고 응답시간도 그만큼 늦어집니다)

-> 해결방법은 index rebuilding을 하는 겁니다...

 

그리고 select * from 테이블 하면 느려졌다고 하셨는데..

토드 같은 툴에서 실행을 하신건가요?

일반적으로 select * from 테이블 full scan을 하기 때문에

당연히 응답속도가 느린게 맞는거 같고요..

툴에서 실행을 하신거라면...

select * from 테이블 하더라도 툴에서 설정한 만큼만

(전체건중 일부만) 읽어 옵니다

툴의 설정에 변동사항이 있는지 확인 해보시기 바랍니다

 

bluepark님이 2005-03-04 18:26에 작성한 댓글입니다.
이 댓글은 2005-03-04 18:27에 마지막으로 수정되었습니다. Edit

답변 감사합니다.

상황을 좀 더 설명하자면

 

해당 테이블은 임시테이블입니다.

대용량의 데이터를 처리하기 위해 데이터를 삽입하고 처리후 모두 삭제합니다.

select * from 테이블(해당 테이블에 문제가 생긴 것을 확인하기 위해 그냥 실행해본 겁니다.) 구문을 실행한 시점에서는 데이터가 한건도 없을 때였습니다.

 

중복된 데이터 처리때문에 기본키도 없고 인덱스도 없습니다.

--> 해당 임시 테이블에 키나 인덱스를 설정해야 할까요? 데이터 삽입 작업은 비교적 빠른 시간내에 이루어집니다.

 

이런 현상은 4000만건 정도의 데이터를 처리한 뒤 발생하였습니다.

테이블에 많은 데이터를 추가하고 삭제해서 조각이 나있었던 거 같은데요.

조각 모음같은 것을 할 수는 없나요?

 

지금 현재는 테이블을 삭제하고 다시 생성해서 문제는 없습니다만 이런 경우가 다시 생길 것 같습니다.

정확한 원인과 대처 방안을 세우고자 글을 남깁니다.

 

 

궁금님이 2005-03-04 18:55에 작성한 댓글입니다. Edit

말씀을 보니

인텍스 스큐현상은 아닌듯하구요

select * from ...

이건 full-scan 이구요

그럼 이건 테이블의 상위 워터 마크가 중가하여서 그런겁니다.

오라클은 데이타가 삽입되면 일단 삭제하여도 그 영역을 제사용하기 위해 free-list를 관리합니다.

자세한 건 책을 참조하시구요

해결 법은 임시테이블이라면 truncate table로 데이타를 지우십시오.

그러면 상위워터마크가 잘려나갑니다.

그리구 SP같은데서 truncate table 안되는 경우는 동적 sql을 사용하십시오.

 

김흥수(protokhs)님이 2005-03-06 00:07에 작성한 댓글입니다.

그리구 첨가하여

인덱스 스큐현상에 대하여....

인덱스 스큐현상은 인덱스가 구멍난 치즈처럼 되는 현상이구요

대부분의 대량 삭제에서는 이런 현상이 발생하지 않습니다.

물론 인덱스가 커진 상태이긴 하지만

어차피 다시 데이타를 채운다면 인덱스는 점점 더 커지는 현상은

안 일어납니다.

이 부분에 대한 자세한 내용은 토마스 카이트의 이펙티브 오라클이라는 책에 자세히 나와 있습니다.

김흥수(protokhs)님이 2005-03-06 00:10에 작성한 댓글입니다.

위의 답변처럼..

4000만건의 데이터 처리후 상위워터마크가 증가해서 생긴 현상 같습니다. 일반적으로 테이블의 전체 스캔할때는 상위워터마크까지 스캔하는데, 이는 삭제 후에도 아래로 떨어지지 않습니다.

그래서 전체 스캔할 때 데이터가 하나도 없더라도 4000만건에 해당하는 블럭을 스캔하는 결과만큼 시간이 걸리는 것입니다.

 

TRUNCATE가 상위워터마크를 내리는 것은 사실이지만..

위의 경우는 반드시 그것이 답이라고 보기는 힘들 것 같습니다.

왜냐면 TRUNCATE이후에 그 테이블에 INSERT를 할 경우

익스텐트를 재할당해야 하는 오버헤드가 있기 때문이죠..

그리고 위의 경우는 100만건을 처리하는 경우도 있고 4000만건을

처리하는 경우도 있어서 너무 편차가 심하군요..

 

임시테이블이라면 처리하는 동안 존재하다가 처리 후 삭제를 할텐데..

입력의 부담과 조회의 부담을 비교해서 유리한 방법을 쓰는 것이

좋을 듯 합니다..

예를 들면 일반적으로 100만건 처리 후엔 그냥 DELETE를 하고..

4000만건 정도의 대용량처리후엔 TRUNCATE하는 방법등..

상황에 따라 유리한 방법을 선택해서 사용하셔야 할 듯..

 

인덱스에 대한 것도 처리에서 임시테이블 사용시에 랜덤 엑세스가

많다면, 인덱스를 만드는 것이 유리하겠지만..

항상 전체 테이블을 읽어서 처리한다면 인덱스 생성에 대한 부담만

있겠죠..

 

더 좋은 것은 임시테이블을 없애고 처리할 방법은 없는지..

(임시테이블이 업무상 임시테이블이란 거죠?

오라클의 TEMPERARY 테이블이 아니구..)

MUR님이 2005-03-07 09:10에 작성한 댓글입니다.
이 댓글은 2005-03-07 09:15에 마지막으로 수정되었습니다. Edit

truncate 의 경우 말씀하신데로 high waiter mark 를 다 삭제 해 주는 것은 사실이며, 데이터 삭제에서도 delete 보다는 성능이 월등함은 다 아시리라 생각합니다.

하지만, 윗분의 상태는 인덱스 스큐 현상은 아닐듯 싶습니다.

* from  전체 범위 처리를 하기 때문에 인덱스 서치 부분과는 관련이 없을 듯 합니다.

 

wait event 를 보시면 sequential wait 부분이 많이 보인다면.. 윗분들이 말씀하신 인덱스 스큐 현상일 가능성이 있으며, rebuilding 작업으로 어느정도 문제를 해결하는 것이 가능합니다.

 

 오라클이 8i 이상 버전이시라면,... move 나 기타 export 를 이용해서 해당 테이블에 대한 fragmentation 을 제거 하는 것도 좋은 방법이 될듯합니다. 이미 어느정도 문제점을 알고 계시는 것 같습니다만.. ^^

나그네님이 2005-03-07 10:39에 작성한 댓글입니다. Edit
[Top]
No.
제목
작성자
작성일
조회
21914오라클 에러에 대한 문의 [2]
김태진
2005-03-04
2259
21913rollup 조회 기초... [3]
아폴론
2005-03-04
4598
21912풀dmp파일을 imp 시킬경우 필요한 정보가...?! [3]
김규홍
2005-03-04
1471
21911특정 테이블의 조회가 느립니다. [7]
궁금
2005-03-04
6195
2191014379에 대한 연속질문.....부탁이요 [1]
김지명
2005-03-04
661
219099i에서(win2000)에서 db start시키는방법좀 알려주세요 [2]
hho
2005-03-04
1028
21908세로로 얻어지는 결과물을 얻게 되는 쿼리문을 세로로 얻을수 있게 수정하고싶습니다. [1]
박기훈
2005-03-04
1552
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2021 DSN, All rights reserved.
작업시간: 0.031초, 이곳 서비스는
	PostgreSQL v13.1으로 자료를 관리합니다