3481건이면 건수가 너무 많은것 같아요

vbrk테이블에 fkdat 필드로 인덱스가 있는지 확인해 보세요.

없다면 당연히 조회시 시간이 오래걸리겠죠.

한달 조회했는데 3천건 넘는다면 전체건수는 엄청날테니요.

인덱스가 있는데 오래걸린다면 where 조건이 잘 못 걸려 인덱스를 안 탈수도 있으니 조건을 변경해야 겠죠.

만약 인덱스가 없어서 만들어야 한다면 그건 잘 생각해야 합니다.

Standard 테이블에 인덱스를 걸수도 있지만 기존에 데이터도 많이 들어있으므로 인덱스 생성 자체 시간도 많이 걸리겠죠.

보통 Standard경우 개발자가 판단해서 인덱스를 생성하지 않으니 BC나 운영이랑 검토해서 생성할지 판단을 해야 합니다.

조금 위험한 방법으로는 병렬처리가 있습니다만.. 총 건수가 100만건 넘는상태에서 3400건이 나왔다면 병렬처리를 돌리는게 더 효율적일 수도 있을듯 합니다.

그리고 제가 확인해보지는 못했지만 EQ보다 NE가 조금 더 시간이 걸린다고 들었습니다.

참고로 VBRK 전체 레코드 수 : 450만여건...VBRP 전체 레코드 수 : 1005만여건...인데 혹시 이거랑 연관이 있나요?? ㅡ_ㅡ;;

sap폐인님 ^^;; 맞습니다 데이터베이스들 다 확인해보면 부정연산 즉, Not Equal, Not In 등 부정연산을 하는것들은 속도가 느립니다.

물론 maxdb뿐 아니라 oracle, my/mssql 전부다욥. ㅋㅋ

어이쿠.. 왠지 8분 30초가 엄청 빨리 된 느낌인데요? =ㅅ=..

1) 100만단위로 병렬처리한다.

2) Inner join을 풀고 각각 select한 다음에 itab에서 재가공한다..

2개 방법으로는 대략 3분정도 줄어들 듯 합니다만.. 아무래도 데이터 건수가 건수이다보니 -_-ㅋ.. 위의 분 말처럼 index를 거시는게 ;;

부정 연산자 "<>, !="가 들어 가면 full table scan이 일어 납니다..

말그대로 인덱스를 타지 않고 한건씩 읽어서  모든데이터(정확하게 말하자면 oracle에서는 water mark)가 있는 곳 까지 읽게 됩니다.

그래서 좀 늦어지지요..

인덱스를 사용하지 못하는 경우(오라클 기준)를 몇가지 말씀드리겠습다.

1. 부정연산자사용(<>, !=)

2. IS NULL, IS NOT NULL

3. WHERE절에 함수사용

4.일치하지 않는 데이터 유형의 비교

입니다.

참고하세요.

ABAP 튜닝이 아니라 ORACLE SQL문 튜닝 이군요...

위의 전군님께서 말씀 하신것이 맞습니다.

해당 필드의 fkdat에 인덱스를 거는것이 맞을듯 합니다.

사실 한달에 3000건 정도는 기업의 데이터 용량에서 보면 얼마 되지 않습니다.

그리고 부정연산자나 여러가지 FULL SCAN은 인덱스 필드에 적용할때 맞습니다.

그렇지 않은 필드는 단순 체크입니다.

따라서 인덱스 필드가 where절에 없으면 full scan이 일어 납니다.

그리고 JOIN은 A TABLE ROW 갯수 * B TABLE ROW 갯수 만큼 진행하지 않습니다.

빠르게 하고 싶으면 FKDAT에 인덱스를 걸면 제가 보기에는 10초 안에 끝날것 같습니다.