해당 컬럼에 반드시 인덱스가 필요하다면 키컬럼 갱신 비용보다는

bitmap index 와 b-tree index의 특성을 고려하여 생성시켜야 할것 같습니다. 님의 설명중 값의 분포도가 낮은 컬럼이라는 의미가

여러개 값들의 중복도가 낮다는 말씀이신지 아니면 중복도가 높은 값이 적다는 의미인지요.

전자라면 b-tree, 후자라면 bitmap을 고려해 보시는게 좋을것 같습니다.

bitmap index의 특징은 인덱스의 값을 bit로 표현 하여 생성하는걸로

알고 있으며, 중복도가 높으면서 값의 종류가 낮은 부분에

사용하는걸로 알고 있습니다. 예를들어 신호등처럼 red, green, yellow

처럼 colord의 종류가 3개만 나오는 경우에 사용을 고려하며,

또한 bit로 표현 되기때문에 부정형으로 인덱스를 사용 가능하다는 특징이 있습니다.

오라클은 기본 row level의 lock 을 지원합니다. 즉 해당 row의 트랜잭션이 종료되면 바로 해제가 되지요..

하지만... bitmap index 는 block level 의 lock 을 지원하기 때문에..

dml 이 많이 발생하는 oltp 환경에서는 사용을 권장하지 않습니다.

dml 작업이 거의 없는 olap 환경의 dw 나 dss 에서 사용되는 것이 일반적입니다. 물론 인덱스의 분포도가 아주 좋지 않은 경우 사용하면 물론 성능에 이롭지만... block level로 lock 을 걸어 버리기 때문에..해당 트랜잭션이 지연될 가능성이 아주 크며..그에 따른 동시성 및 전체적인 lock 리소스의 낭비등 좋지 않은 결과를 초래할수 있으니..

사용하려고 하는 테이블및 인덱스가 자주 dml 이 발생하는oltp 환경이시라면... 사용을 권장하지 않습니다.

수고하세요..

답변 감사합니다.

비트맵 인덱스와 OLTP성 그리고 한계 비용....

저도 비트맵인덱스에 대하여 관심이 많습니다..

그래서 이것 저것 테스트를 해보았는데요

일단

앞에서 말하신 분들의 말씀은 전적으로 옳습니다.

단 좀 고려해야 할 부분은

OLTP성 환경에서는 사용하지 않는 것이 좋다는 말의 OLTP성 환경의 정확한 의미입니다.

비트맵인덱스는 일반적으로 대량 갱신에서는 (한번에 여러 레코드를 갱신하는 것) 성능상의 큰 저하가 발견되지 않더군요

단 동일한 작업의 크기를 모든 행에 대하여 개별적으로 수행할 경우 느려집니다.

여기까지는 우리가 알고 있는바 그대로구요

제가 테스트한 바에 의하면

800만건의 테이블에 있는 한 컬럼이 전체 레코드를 10개의 그룹으로 분할하는 경우에 varchar2(1)의 컬럼으로 테스트해보니(P3급 7200rpm=> 한마디로 좀 된 PC급) 한 레코드를 갱신하는 데 수행된 시간이 1초가 안되더군요

이 이야기는 시사하는바가 있는데요...

뭐냐면 초당 갱신SQL이 1개 미만이라면 800만건 정도의 테이블도 비트맵 인덱스에 대하여서는 OLTP테이블이 아니라는 거죠

일반적으로 갱신 작업은 임계치를 넘어설때 급격히 느려지는 경향을 갖습니다.

OLAP 성 테이블이 아니더라도

OLTP 응용프로그램에는 여러 성격의 테이블들이 존재합니다.

코드테이블 성격,시간의 흐름에 따라 일정하게 증가하는 거래 테이블 성격,시간의 흐름에 따라 증가하나 일정하지 않고 사건 기반으로 증가하는 테이블,시간의 흐름에 따라 증가 또는 감소를 반복하는 테이블 등등등

음...

특히나 레코드의 상태를 나타내는 플래그 형태의 컬럼은 갱신이 전체 레코드에 고르게 일어나는 경향보다는 부분적으로 일어나는 경향이 많죠

결론적으로 설계자의 의도에 따라 사용하시되 OLTP에서는 쓰면 안된다는 생각은 안하셔도 된다는 점입니다.

100만건 안되고 하루에 한 1000건 정도 해당 컬럼이 갱신된다면....

그냥 비트맵이 필요한 상황이면 쓰십시오.