저도 찾아봐서.. 명확하게 나온건 아니구요..
일딴 Long 칼럼에 대해서는 Index 생성 차제가 안되구요..
CLOB 칼럼에 대해서는 명시적으로 생성 안됩니다.
lob 칼럼 생성( 혹은 추가시) DBMS 가 자동으로 LOB 칼럼에 대한 Index 를
생성 합니다.
LOB 을 생성 ==> LOB Segment 와 LOB Index Segment 가 생성 됩니다.
일반적인 Index 는 특정 칼럼을 정렬하여 빠르게 해당 Row 에 접근 가능하게
해주는것이지만. LOB Index 자체는 Lob Segment ( LOB Column) 자체를
정렬해서 만들순 없겠죠..Lob Segment 를 관리 하기 위한 일종의 map 정보를
가지고 있는것으로 생각됩니다.
결론적으로 일반적인 인덱스와 LOB Index(Oracle DBMS 가 자동으로 생성하는)
는 구조도 다르고, 쓰이는 용도도 다른것으로 생각됩니다.

타락천사님 답변 감사합니다.

필드타입이 Raw 이며 인덱스는 생성되어 있습니다.
제 추측에는 아무래도 Raw데이터가 바이너리값이다 보니 0과1의 조합에 의한
B*트리를 탄다고 가정해도 거의 풀스캔에 가깝지 않을까 싶긴 합니다.
그래도 힌트를 통한 인덱스를 명시 함에도 불구하고 아예 안타는게 좀 의하합니다.
해당 필드가 아마 DBMS유틸로 암호화 한 값인듯 한데.. 무식하게 Raw로 잡아놔서... 이 고생이네요..

제가 알기론 암호화 되어 있으면 인덱스 사용 못할꺼에요..

암호화 업체에서 말하기를 암호화가 되어 있더라도 인덱스 스캔은 한다고 합니다.(암호화 제품에 따라서..)

그런데 제 개인적인 생각으로는 암호화 되어 있다면 인덱스를 타면 안된다고 생각합니다.
인덱스라는 것은 값에 따라 정렬이 되어 있는 것이고,
암호화라는 것은 말 그대로 값에 대해 암호가 걸려 있고 그 자체는 정렬되면 안되는 것이겠지요.
정렬이 되어 버린다면 암호화한 의미가 없을 테니까요...

에고, 말로 쓰기는 좀 곤란한데..
암튼, 암호화 컬럼이라면 인덱스 부분에서는 자유로우면 안된다는 것이 제 생각이긴 합니다...

관심가져주신 타락천사님, 현님 일단 감사합니다.
문제를 찾았습니다. 결국 저의 사소한 불찰이었네요..ㅠㅠ

제가 쿼리시 raw타입필드와 비교하는 값을 바이너리로 줄수없기에
바이너리를 to_char해서 얻은 스트링을 넘겼는데
쿼리파싱시 타입캐스팅이 Raw쪽에서 발생하는 듯 합니다.
즉 Raw필드에서 타입캐스팅에 의한 데이터값의 변경으로 인덱스를 타지 못한거였습니다. 넘겨주는 값을 Raw로 변환해서 넘기면 인덱스를 잘 타네요 ^^

덕분에 좋은 정보 얻었네요 ^^