데이터베이스 질문과 답변
안녕하세요^^;
방대한 데이터를 가지고 있는 집계성테이블을 년별로 파티셔닝하였습니다.
파티셔닝 조건은 '201101' values less than 입니다.
아래 쿼리들을 봐주세요.
1. select sum(재고)
from a
where 발생월 = '201006'
2. select sum(재고), 매장
from a
where 발생월 = '201006'
group by 매장
3. select sum(재고), 매장, 품번
from a
where 발생월 = '201006'
group by 매장,품번
쿼리 시간이 각 쿼리별로 36초(1번), 45초(2번), 1분30초(3번)이 걸렸습니다.
이경우 집계성 데이터이기 때문에 시간이 이렇게 많이 걸리면 안될듯 한데요..
혹시 월별로 파티셔닝을 하게되면 위 쿼리시간이 더 줄어들까요??
아니면 방대한 데이터때문에 어쩔 수 없는 것일까요??
후자라면 어쩔 수 없지만 전자로 해결 가능하다면 처리해야 할 듯 해서요~
아 물론 발생월/매장/품번에 대해 인덱스는 걸려 있습니다.
많은 조언 부탁드립니다.
by ^^
[2011.04.05 16:55:58]
월별로 파티셔닝을 하게되면 쿼리시간이 줄어들것 같습니다.
월별 데이터량을 알면 더 정확한 답을 드릴 수 있을것 같은데..
DBMS 버젼은 먼가요??
월별 데이터량을 알면 더 정확한 답을 드릴 수 있을것 같은데..
DBMS 버젼은 먼가요??
by 장우람
[2011.04.05 17:03:23]
현재 10그람 이구요.. 조만간에 11그람으로 올릴 예정이어서 올리기 전에 이것저것 튜닝 하는 중입니다.
그리고 2010년도 데이터는 3천만건이구요.(좀.. 많죠??;;;)
월별로는 2010년 05월은 220만건.
06월은 230만건.
이녀석은 기하급수적으로 점점 늘어나는 데이터 입니다.....ㅠㅠ ㅋ
그리고 2010년도 데이터는 3천만건이구요.(좀.. 많죠??;;;)
월별로는 2010년 05월은 220만건.
06월은 230만건.
이녀석은 기하급수적으로 점점 늘어나는 데이터 입니다.....ㅠㅠ ㅋ
by 이재현
[2011.04.05 18:26:22]
10그람 == 10g?
300만건 풀스캔해서 그룹바이 탑쿼리 가져오는것두.. 0.6초만에 가져오는데..
조회 조건이 월별로 많이 이뤄지나요??
300만건 풀스캔해서 그룹바이 탑쿼리 가져오는것두.. 0.6초만에 가져오는데..
조회 조건이 월별로 많이 이뤄지나요??
by 장우람
[2011.04.05 18:33:18]
넵 현재 오라클 버전은 10.2.0.3.0 입니다. 11g r2로 업글 예정이구요.
재고관련 집계테이블이라 발생월 조건은 항상 들어간답니다.
재고관련 집계테이블이라 발생월 조건은 항상 들어간답니다.
by 장우람
[2011.04.05 18:34:37]
이부분을 월별로 파티셔닝을 하면 쿼리속도가 빨라질까요??
by 장우람
[2011.04.05 18:37:50]
풀스캔시 3분30초, 인덱스 타면 1분 30초가 걸리네요.
by finecomp
[2011.04.06 01:09:08]
파티션하나에 3천만건이면 별로 많은 건수는 아닙니다...(저희는 한 파티션이 1억이 넘어가요)...^^;;;
몇 백만건을 인덱스스캔 + 테이블 random엑세스해서 1분 30초는 어느정도 이해가 가지만, 3천만건 정도의 풀스캔이 3분이상은 좀 이해가 안가네요...;
테스트가 가능하다면, 해당 파티션만 별도의 테이블로 만들어 보신 후, 테스트 해 볼수 있겠습니다.
별도의 테이블성능이 빨라졌다면, 원 테이블의 대량데이터 삭제로 불필요한 size증가 또는 row migration, row chaning 이 된건 아닌지 등의 확인이 필요하겠고,
비슷한 성능을 보인다면, lob컬럼이 들어있거나 multiblock read count의 설정이 너무 낮다던가, 테이블의 extents size가 너무 작게 잡힌 것은 아닌지? 또는 다른 이유로 가용메모리가 부족하다던가 하는 문제겠죠?
물론 이런 시스템적인 테스트 전에 먼저 원래의 쿼리를 수행 시,
쿼리 전 ALTER SESSION SET db_file_multiblock_read_count = 128; 정도의 실행.
full scan시 Parallel 수행 검토.
실행계획의 변경여부 검토 등은 반드시 먼저 해봐야 하겠죠?
그리고 200만건 정도의 소량데이터를 위해서 무작정 월별로 파티션을 변경하는 것은 얻는 것보다 잃는 것이 훨씬 더 많을 수도 있는 일입니다...기억하세요~~
몇 백만건을 인덱스스캔 + 테이블 random엑세스해서 1분 30초는 어느정도 이해가 가지만, 3천만건 정도의 풀스캔이 3분이상은 좀 이해가 안가네요...;
테스트가 가능하다면, 해당 파티션만 별도의 테이블로 만들어 보신 후, 테스트 해 볼수 있겠습니다.
별도의 테이블성능이 빨라졌다면, 원 테이블의 대량데이터 삭제로 불필요한 size증가 또는 row migration, row chaning 이 된건 아닌지 등의 확인이 필요하겠고,
비슷한 성능을 보인다면, lob컬럼이 들어있거나 multiblock read count의 설정이 너무 낮다던가, 테이블의 extents size가 너무 작게 잡힌 것은 아닌지? 또는 다른 이유로 가용메모리가 부족하다던가 하는 문제겠죠?
물론 이런 시스템적인 테스트 전에 먼저 원래의 쿼리를 수행 시,
쿼리 전 ALTER SESSION SET db_file_multiblock_read_count = 128; 정도의 실행.
full scan시 Parallel 수행 검토.
실행계획의 변경여부 검토 등은 반드시 먼저 해봐야 하겠죠?
그리고 200만건 정도의 소량데이터를 위해서 무작정 월별로 파티션을 변경하는 것은 얻는 것보다 잃는 것이 훨씬 더 많을 수도 있는 일입니다...기억하세요~~
by finecomp
[2011.04.06 01:13:59]
group by시 충분한 메모리가 확보되지 않으면,
disk와 페이징작업이 발생하여 엄청난 성능저하가 일어납니다.
group by시 기준항목이나 select항목들이 늘어날수록 더 많은 메모리가 필요합니다.
이 부분은 trace나 dbms_xplan의 결과를 참고하세요~~
disk와 페이징작업이 발생하여 엄청난 성능저하가 일어납니다.
group by시 기준항목이나 select항목들이 늘어날수록 더 많은 메모리가 필요합니다.
이 부분은 trace나 dbms_xplan의 결과를 참고하세요~~
) 버튼을 클릭하여 작성 하시면 됩니다.