안녕하세요!
궁금한 것이 있어서 글을 올립니다.
인덱스를 달려고 하는 테이블이 있는데 현재 그 테이블에는 키가 잡혀 있지 않습니다. 데이타 문제로 키를 안 잡아 놓았다고 합니다.
하지만 다시 살펴보니 인덱스도 설정되어 있지 않더군요 그래서 제가 달려고 하는데
키가 아닌 인덱스만요 이 테이블의 데이타 건수가 55억건인데.... 인덱스 달때 유의사항이 있다면 좀 알려주시기 바랍니다.
아무래도 조심스럽다 보니... 글을 올립니다.
사용하시는 제품이 IQ 인지, ASE 인지 확인부터 하고 싶네요. IQ 라면 기본 인덱스가 있기 때문에 ASE 라고 추정하고, 일단은 인덱스 컬럼을 선택했다고 가정하겠습니다. 1. 가장 중요한 것은 카디널리티에 따라 index 컬럼 순서를 정해야죠. (55억건이라니.. 이거 group by로 count 뽑아 내는 것 부터가 시간싸움이겠습니다. ....아멘...) 일단 컬럼별 group by 카운트 값을 바탕으로 카운트 값이 가장 큰 값(카디널리티가 큰 값)을 index 첫 컬럼으로 정하고, 순차적으로 다음 컬럼을 정하시면 됩니다. 1. 충분한 DISK 공간 (55억건에 해당하는 인덱스를 만드니 최소 테이블 공간정도는 확보해야 할 것 같습니다) 2. 생성 시간이 오래 걸릴텐데, nonclustered 인덱스를 생성하면 그나마 select 쿼리는 blocking이 되지 않아 인덱스 생성중에도 select 쿼리는 가능합니다. clustered index 보다는 nonclustered index 가 좋을 것 같네요. cover index가 되도록 컬럼이 선택되었다면 더 좋을 것 같구요 3. 인덱스 생성시 프로시져 cache 공간을 사용하는데, 공간이 작으면 fail 이 날 경우 rollback되는 경우도 발생합니다. 프로시져 cache 공간을 평소보다 늘려서 작업하시는 게 좋습니다. 4. 인덱스 생성 속도를 빠르게 하는 방법을 docment 에서 찾아 보시는게 좋을 것 같습니다. 많이 도움이 되실 겁니다. 5. 인덱스 생성 옵션을 필요하다면 쓰시는게 좋을 것 같습니다. 예를 들어 step이라든지, fill factor 등은 차후에 인덱스 생성후 쿼리 성능에 영향을 줄 수 있으니까요. 6. 마지막으로 인덱스 없는 테이블에 인덱스 생성시 문제점이라면, insert가 느려진다는 겁니다. 시스템 마다 차이가 있긴 하겠지만, 제가 경험한 곳에서는 30~40만건 을 인덱스 없는 빈 테이블에 넣었을때, 15초 정도도 안걸리던 것이 인덱스 하나 생성한 빈테이블에 넣을 경우 2~3분정도 소요되었고, 같은 인덱스에 1억건 정도 있는 테이블에 30~40만건을 넣을 경우 1시간 30분에서 2시간 정도 소요되었습니다. 입력한 데이터는 동일한데두요. 필요 이상으로 인덱스를 많이 만들지는 마세요.
먼저 왕궁금이님에 답변에 감사드립니다. 글을 처음 올리다보니 충분하지 못한 내용으로 글을 올리게 되었네요 현재 사용하는 제품은 IQ 이며 버전은 12.6 입니다. 인덱스 설정시 테이블 공간만큼의 공간이 확보되어야 하나요? 생각보다 많은 공간을 사용하네요.. index 컬럼 순서를 정한다는 것도 좀 생소하구요.! 지금까지 인덱스 설정시 순서 고려해본적이 없었거든요... 뱅쿄뱅쿄 가 필요하군요^^
IQ군요... 55억건을 ASE에서 사용하는 곳이 없을 거라 생각하긴 했지만... 인덱스가 없다고 하셔서...ㅋ
- 일단 일반적인 DBMS에서 index는 2진 트리 형태로 구성되기 때문에, 컴포짓 인덱스(인덱스 컬럼이
여러개)의 경우검색 노드를 줄이기 위해서 카디널리티순으로 인덱스 컬럼 순서를 만드는 것이 io를
줄이는데 효과적입니다. IQ에서 composite index (보통 HG 인덱스)도 마찬가지입니다.
- IQ에선 인덱스 종류도 많고, 데이터 타입에 따라 선호인덱스가 다르기 때문에 머라 꼬집어 말하긴
어렵네요. IQ는 인덱스를 많이 만들면 만들수록 좋죠. 공간을 많이 차지하는 문제를 뺀다면요.
1. 모든 테이블은 FP 인덱스를 기본적으로 가집니다.
2. 단일 컬럼 데이터가 unique 하거나 primary key 라면 HG인덱스 여부를 확인해 봅니다.
3. 단일 컬럼 데이터가 1500 카디널리티 보다 작으면 LF 인덱스 생성을 고려해 볼 수 있습니다.
4. 컬럼 데이터가 1500 카디널리티 보다 크면 HG 인덱스를 고려해 봅니다.
5. 날짜타입의 데이터에 range 쿼리가 있다면 DT/TM/ATTM 인덱스 생성을 고려해봅니다.
6. range 쿼리와 대규모 sum/avg 작업이 있다면 HNG 인덱스 생성을 고려해 봅니다.
7. 같은 테이블의 컬럼 비교시 CP 인덱스 생성을 고려해 봅니다.
8. contains 나 like 쿼리시는 WD 인덱스 생성을 고려해 봅니다.
9. 데이터의 변화가 없는 정적인 join 쿼리라면 join index를 생성을 고려해 봅니다.
10. 인덱스 조합 궁합사항을 검토해 봅니다.
-- 인덱스 조합 궁합
HG - HNG , HG - CMP , HG - DT/TM/DTTM
HNG - HG . HNG-LF , HNG-CMP
LF-HNG , LF-CMP, LF-DT/TM/DTTM 은 궁합이 좋은 편입니다.
11. composite index는 HG인덱스로 만듭니다. (공간은 많이 차지 합니다. )
IQ 12.6 부터는 index_advisor 옵션이 존재하는데 옵션을 임시로 활성화 시킨 상태에서 쿼리를 실행하면,
iqmsg 에 권장 인덱스 내용이 출력되게 됩니다.
ex) set temporary option "Index_advisor" = 'ON';
사용자 쿼리 ;
set temporary option "Index_advisor" = 'OFF';
하면. iqmsg 파일에
Index Advisor :
Advice : .....어쩌구 저쩌구 무슨 인덱스를 생성하세요 라고 떠듭니다. ....
항상 퍼포먼스가 좋아진다고 장담하긴 힘들지만, index 생성시 좋은 시작이 될 수 있다고 생각합니다.
퍼포먼스 테스트는 왠만하면 운영머신이 아닌 테스트 머신에서 하는 센스...
상세한 조언 감사드립니다. 즐거운주말 되세요!