2014년 7월 23일 수요일

ABAP 튜닝 충고

[출처 : http://www.erpschool.net/ ]                                                    튜닝관련문서 다운


당사에서 약 1개월간 튜닝을 진행하면서 많이 수정하고, 개선했던 부분들을 언급해 보니 참고해 보시길 바랍니다.

1) SQL 문장 분석후 수정
2) 적절한 Index 추가
3) 중복로직 삭제
4) Internal Table 처리방법 수정
5) 기타참고 사항

1) SQL 문장 분석후 수정
주요 포인트는 건처리를 지양 하는 부분에 포커스를 두었습니다.
select single 문은 loop at ~ endloop 사이에는 될수 있는 한 제거 하고,
대상건을 internal table 에 담아서 read table 처리하여 db read time을 줄였습니다.
SQL 에서 where 절에 order by 조건들을 지양하였습니다.
order by 를 없애고, internal table 에 대상건을 넣은후 sort 문을 이용하여 db read time 을 줄였습니다.
Inner Join, Outter Join 문에서 결합 조건이 잘못되어 Full Scan 하는 경우가 있어서 해당 문장의 Join 결합조건에 키필드들을 조건으로 추가하였습니다.
그리고 가장 기본적인 where 절에 key field 가 빠진경우가 있었습니다. 의외로 이러한 key field 가 빠진 구문들이 많았습니다.

2) 적절한 Index 추가
대부분의 튜닝작업에서 큰 효과를 거두는 부분은 적절한 Index를 잡아주는것입니다.
특히나 CBO 프로그램에서 Standard Table 을 읽을때, 기본 index를 타지않게 SQL 문장을 쓰는 경우가 있습니다. (초급자가 코딩한 경우)
Index를 탈수 있게끔 where 절 조건을 정확하게 수정하였고, 조건이 특수하여 index를 탈수 없는경우는 적절한 index를 추가하여 Table Full Scan 하는것을 예방 하였습니다.

3) 중복로직 삭제
이 부분은 프로그램 개발시 정확한 분석없이, 짧은시간에 결과 출력에만 중점을 둔 프로그램들에서 중복로직들이 발견되었습니다.
되풀이 되는 로직들, 특히 동일한 table을 여러곳에서 select single 하는 경우에는 internal 테이블에 대상건을 넣어주고, 필요한 부분에서 read table 문으로 읽게끔 수정하였습니다.
대부분 업무적으로 분석이 잘못되어서 발생한 문제들 이었습니다.
정확한 요구사항분석이 중요하다는 것을 깨닫게 되는 case 입니다.

4) Internal Table 처리방법 수정
loop at ~ endloop 사이에서 select single 사용 지양하고 binary search 옵션을 추가함.
loop at ~ endloop 사이에서 delete 문 사용시 where 조건 제거하여 internal table full scan 하는경우 없앰
key 값이 unique 한 경우 internal 테이블 선언시 SORTED형 테이블로 선언하여 internal table을 full scan 하는 상황을 없앰

5) 기타참고 사항
CBO 프로그램들의 경우 소스내에 BDC 를 수행하는 경우가 있습니다.
이 경우 소스코드를 튜닝하는 것은 한계가 있으므로 필요시 다른방법들은 간구 할수있습니다.
일반적인 SQL 튜닝외에 다른방법들을 언급해 봅니다.

첫번째는 병렬처리 방법입니다.
AP Server 와, DB Server 에서 동시에 병렬로 프로세스를 띄어서 부하분산효과를 누리는 경우입니다.
이 병렬처리 방법은 BC 쪽에서 지원이 필요한 부분이기도 합니다.
예를들어 DIA 프로세스 개수를 더 증가 시켜야 할 경우도 있습니다.
관련 소스는 향후에 공개토록 하겠습니다.

두번째는 Archiving 입니다.
트랜잭션 데이터가 많이쌓이는 테이블을 읽는 프로그램들은 기본적으로 그 대상건이 줄어들면 당연히 속도가 줄게 마련입니다.
Archiving 하여 전반적인 속도를 줄이는것은 단순한 튜닝 수준을 넘어서, 장기적인 관점으로 접근 하여야 합니다.
해당회사의 데이터관리 정책에 우선하여야 하고 최초 비용이 많이들기 때문에 구축후 장기적인 관점에서 유지보수 비용, 데이터 관리 비용의 이점을 살려서 진행하여합니다.
아무튼 Archiving을 한 경우 부수적으로 대상건들이 줄일수 있으므로 Performance 향상을 기대할 수 있습니다.
다만 중요한 것은 Archiving 이후 BC 쪽에서 DB Reorg. 작업을 꼭 해줘야 Size 감소 효과를 볼수 있습니다.

세번째는 하드웨어적인 튜닝입니다.
단순하게 CPU, Memory 를 증설하는 것입니다.
소스 튜닝의 방법으로는 기대하는 수준의 효과를 못보는경우 해볼수 있는 방법입니다.
비용이 발생하기 때문에 쉽게 시도하기는 어려운 부분입니다.

댓글 없음:

댓글 쓰기