<ABAP> ITAB 대량건 처리시 MEMORY 덤프 방지 및 처리속도 튜닝 방법.. (bkpf besg)

최근 hana 도입한 것들은 이런 고민을 안하겠지만..
구abap을 쓰고 있다면 수십만건 다운로드나 로직 처리시 메모리 덤프를 경험하거나 그걸 회피하기위해 로직을 짜면 느려지게 짜는 경우가 있다..
바로 아래와 같은 경우다..

우선 선언부터 occurs 0 를 쓴게 마음에 안드는데.. ㅎㅎㅎ
저상태면  느려지는 이유가 loop 안에서 bseg를 하나하나 읽는다......

물론
우리가 다 아는 빠르게 하려면 bkpf를 읽고 for all entries로 bseg를 수십만건불러와서 loop를 돌며
read table bseg .......
하는 방식으로 처리하면 된다 하지만 너무 건수가 많고 인터널 테이블 메모리 적은 회사는 메모리 덤프를 뱉는다 .......

그럼 이걸 어찌 처리해야 조금 더 빠르고....
메모리 덤프도 없앨 수 있을까??

개발자 마음이지만..
난 이런방식을 썼다...

우선 bkpf는 10~20만건 특정필드 15개 이내정도 담는건 메모리에 문제가 없으니.. 그걸 다 담고 ..

bseg를 itab에 담긴 bkpf의 key값 5만~10만건씩 끊어서 bseg db로 한번씩 다녀오는 방식을 취했다...

로직은 아래와 같다.

p_cnt는 입력받을 수 있게 만들어놨다 .

위 로직 설명을 해보겠다.

lt_bkpf는 키만 저장하는 itab으로 선언했다.
아래처럼... types 로.. 왜? perform으로 빼주려고..

그럼 perform get_bseg_data는 언제 들어가느냐??
내가 정한 p_cnt 수에 lv_tabix가 도달하면  들간다.
즉 내경우 3만건 담아서 bseg 부르러 가는거...

그리고 나와서.... 다음을 처리한다.
이 아래 캡쳐 처리가 상당히 퍼포먼스에 좋게 만들었다..

맨위 loop 안 select bseg 와 다르게
loop 안에서 read table gt_bseg를 하는데
미리 sort를 bseg로 해둔 후니 binary search 하고나서 해당 위치부터 gt_bseg loop from lv_tabix를 돌게 만드는것이다 .
왜? 속도를 빠르게 하기 위해서......

그리고 전표번호가 바뀌면 빠져나가게 만든것이다 ..

이런식으로 3만건씩 끊어서 처리하다가...
마지막엔 3만건이 아닌 3천건만 남았다 치면 처리 안하고 나갈 것 아닌가....

그래서
다시 2번째 사진으로 돌아가서

else.
at last.
구문으로 남은 잔바리들을 처리하게 넣어두었다....
perform모듈화 시켜두었으니 그냥 같다 붙이면 끝...


어떤가.... 재밌지 않은가...

개발자의 그냥 짜잘한 스킬이었다.. ㅎㅎㅎ