SELECT SEGMENT_TYPE, SEGMENT_NAME, TABLESPACE_NAME, TRUNC((SUM(BYTES)/1024)/1024,2) as "용량(MB)"
FROM DBA_SEGMENTS
WHERE SEGMENT_TYPE IN ('TABLE', 'INDEX', 'TABLE PARTITION', 'TABLE SUBPARTITION')
AND OWNER = '사용자명'
GROUP BY SEGMENT_TYPE , SEGMENT_NAME, TABLESPACE_NAME
ORDER BY 1 desc, "용량(MB)" desc;
출처 : http://koreantramp.tistory.com/216
기존에 개발해 놓았던 LOG 분석 시스템에서
동시 요청 정보를 확인해 보고 싶어서 작업을 돌려 봤더니 세월아 .. 내월아...
체크해 보니.. 시간이 Overlap 되는 정보를 확인하려면 시간 정보에 index가 있어야 하는데.. Index가 없어서 실행 계획이 엉망인것이다.
그래서 Index를 생성해 보았더니.. 이 Index가 생성되는데.. 세월아 .. 내월아..
다행이 예전에 back ground로 query 돌리던 script가 있어서 실행해 보았더니,
한참 돌다가.. TEMP 테이블스페이스가 용량이 부족해서 에러 발생...
https://forums.oracle.com/thread/369703
결국 TEMP 테이블 스페이스 용량을 추가 한 후 정상 생성..
그런데.. Index 생성하는데.. 하루 이상 걸렸다...
뭐.. 그래도 Index 생성했더니... 전에 보다는 몇 백배는 빨라 졌다.
근데.. 동시 요청 정보를 Account Level로 Check했더니 특정 User의 동시 사용 정보 때문에 다른 sequential 요청도 동시 요청으로 잡히는 문제 점 확인...
결국 코드를 수정했더니.. 전엔 Index access로만 데이터를 처리할 수 있었던 Query가
테이블 access가 발생하면서 다시 느려지는...
결국 User 정보를 Index가 다시 추가하는데...
속도는 느리고.. 또 Index 생성하다가 용량 부족으로 에러 나고... -.-
주말내내 Index 생성되는 걸 기다려야 할 듯 하다..
근데 Index 테이블 생성하고.. 위 Query로 체크해 보니..
Index가 테이블 사이즈 보다 훨 커져 버렸다.
말로만 듯던.. ( 어찌보면 분석 시스템에서는 필연적인..) 인덱스가 테이블보다 더 커지는 현상...
예전에 여러 회사에서 시스템 운영하면서 한번도 격어 보지 못했던..
대용량 DB 시스템 관련 이슈를 개인용 ( 물론 업무적으로 개발한거지만.. ) 분석툴에서 겪게 될 쭐이야....
좀 중구 난방 으로 개발 운영하여서 누더기 갇기는 하지만..
그동안 겪어 보고 싶던 대용량 데이터를 다루는 기쁨이라고 나 할 까...
