S/4HANA에서 S_ALR_87013611 리포트 퍼포먼스를 올리는 방법

 

 

 

 

 

T-CODE: S_ALR_87013611 리포트는 CO의 가장 대표적인 리포트 중 하나다. 회사마다 다르지만 "CCA 리포트"라고 부르는 걸 많이 봤다. 나도 그렇게 부른다.

 

 

T-CODE: S_ALR_87013611(코스트센터 실제/계획/차이 리포트)

 

 

그런데 이 리포트가 S/4HANA 환경에서는 퍼포먼스가 떨어질 때가 있다. 언제 그런가? 사실 구축만 하면 알기가 어려운데 이 현상이 통합 테스트 시기나 구축 초기에는 잘 발견되지 않기 때문이다. 데이터가 어느 정도 쌓인 이후부터 퍼포먼스가 떨어지기 시작한다.

 

지금 내가 있는 프로젝트의 경우 오픈 초기에는 10초 이내로 나오던 것이, 이제는 5분 이상도 더 걸리게 됐었다.

 

 

 

 

---

 

1. 해결 방법

 

 

이 부분의 해결을 위해서는 『SAP NOTE: 2178537 - RW: Performance in Releases sFIN 2.0 and higher』에 있는 내용을 적용하면 된다. 위 노트에 따르면 테이블 T811FLAGS 테이블에 아래와 같은 행을 추가하고 리포트를 재생성하면 된다고 한다.

 

 

필드	TAB	FIELD	VALIMIN
값	ACODCA	DBSEL	X

 

 

테이블: T811FLAGS

 

 

이렇게 추가하고 T-CODE: GR55로 간다.

 

 

T-CODE: GR55(레포트 그룹 실행)

 

 

리포트 그룹 '1SIP'를 재생성한다. S_ALR_87013611 리포트는 이 그룹 내에 있다.

 

이렇게 조치한 이후 리포트의 속도는 5분에서 1분 30초 정도로 줄어들었다.

 

 

 

 

---

 

2. 왜 이런 일이 생기는가?

 

그렇다면 왜 이런 일이 생길까? 이 리포트가 과거 테이블인 COSP, COSS, COEP 등에서 데이터를 추출해오기 때문이다. 엄밀히 말하면 S/4HANA부터는 이 테이블들은 더이상 물리적인 테이블이 아니다. "Compatible View"라는 뷰가 되었다.

 

Compatible View란 게 뭘까? S/4HANA에 와서는 기존의 테이블 구조가 많이 바뀌었다. 회계의 트랜잭션 테이블은 과거 BKPF, BSEG, COBK, COEP, COSP, COSS, FAGLFLEXA, FAGLFLEXT 등등에서 하나의 ACDOCA 테이블로 통합되었다. 그에 따라 과거 테이블들은 다 필요 없게 되었다.

 

그런데 그렇다고 과거 테이블을 다 삭제해버릴 수 있었을까? 그럴 수는 없었다. 과거 테이블들을 활용한 프로그램들이 스탠다드와 CBO를 불문하고 엄청 많았기 때문이다. 따라서 안정적인 업그레이드를 위해서는 과거 테이블을 남겨둘 수밖에 없었다. 그렇지만 과거 테이블에 여전히 데이터가 쌓이게 놔두는 것은 엄청난 비효율이므로, 과거 테이블들은 뷰 형태로 바꿔서 남기게 됐다. 이게 바로 Compatible View이다.

 

이 노트를 적용하면 더이상 Comaptible View에서 데이터를 추출하지 않고 관련 DB 테이블을 직접 접근해서 데이터를 추출해오게 된다. 이 뷰들의 원천 테이블은 결국 통합 원장(Universal Journal) 테이블인 'ACDOCA'이므로, ACDOCA를 통해서 데이터를 추출한다고 보면 된다.

 

그렇다면 왜 Compatible View가 테이블 ACDOCA보다 느린가?

 

이는 S/4HANA에서 테이블(엄밀하게는 Compatible View인) COSP의 DDL 소스를 보면 알 수 있다.

 

 

뷰 V_COSP_VIEW

 

 

v_cosp_view 뷰의 가장 하단을 살펴보면 v_cosp_wdv_11_view로부터 데이터를 추출해온다.

 

 

뷰 V_COSP_WDV_11_VIEW

 

 

다시 v_cosp_wdv_11_view 뷰의 하단을 보면 v_cosp_wdv_10_view로부터 데이터를 추출해온다. 이런 식으로 무려 10회 이상의 중첩이 걸려 있다. 그리고 그 중첩을 계속해서 따라가보면 결국 테이블 ACDOCA로 시작됨을 알 수 있다.

 

 

마지막 뷰인 V_COSP_WDV_1_VIEW

 

 

그러니까 이런 거다. 결국 Compatible View로 추출하든 테이블 ACDOCA로 추출하든 결과는 같다. 그런데 Compatible View로 추출하게 되면 여러 번의 중첩으로 인해 내부적으로는 SELECT를 10번 이상 수행하게 되는 것이다. 당연히 더 느릴 수밖에 없다.

 

 

 

 

---

 

3. 앞으로는 어떻게 해야 할까?

 

 

그럼 앞으로는 어떻게 해야 할까? 특히 CBO를 개발할 때는 어떻게 하면 좋을까? 과거처럼 COSP, COSS, COEP를 그대로 써도 괜찮은가?

 

이에 대해서는 『SAP NOTE: 2185026 - Compatibility views COSP, COSS, COEP, COVP: How do you optimize their use?』에 가이드가 나와있다.

 

이 노트에 따르면 네 가지 방법이 있다.

 

첫 번째는 과거 Compatible View를 그대로 활용하되 프로그램 내에서 선택 조건을 최적화하는 방법이다.

 

어떻게? 일반적인 ABAP SQL 최적화와 같다. 대량 테이블과의 JOIN을 피한다, SELECT *을 피하고 필요한 필드만 선택한다, WHERE절을 이용해 조건을 줄인다, FOR ALL ENTRIES IN 구문을 피한다 등등.

 

 

두 번째는 대체 뷰를 활용하는 방식이다.

 

COVP를 대신해서는 V_COEP_KAEP를, COSP와 COSS를 대신해서는 V_COSP_R과 V_COSS_R을 사용하라고 한다. 데이터 양이 많을 수록 이 대체 뷰의 속도가 더 빠르다고 한다. (데이터 양이 적을 때는 COSP와 COSS가 더 빠르다)

 

 

세 번째는 테이블 ACDOCA에서 직접 추출하는 방식이다.

 

중첩이 없기 때문에 훨씬 더 빠르게 추출할 수 있다. 다만 몇 가지 주의사항이 있다. 우선 COEP, COSP 등의 필드명은 ACDCOA와 다르다. 필드 매핑이 필요하다. 이 필드 매핑 정보는 『SAP NOTE: 2156822 - sFIN: Mapping of ACDOCA fields to old FI/CO tables』에서 찾아볼 수 있다. 또는 CDS 뷰 'V_COEP_ACDOCA'라는 뷰를 보면 그 내용을 알 수 있다.

 

다만 평가유형 04(실적) 데이터는 ACDOCA를 가져오되, 평가유형 11(통계실적) 데이터나 그 외의 값들은 V_COEP_ORI를 가져오는 게 더 낫다고 한다.

 

 

네 번째는 신규 개발된 클래스를 이용하는 방법이다.

 

CL_FCO_COEP_READ, CL_FCO_COSP_READ, CL_FCO_COSS_READ 클래스의 메소드를 활용해서 데이터를 추출한다. 다만 이 경우는 버전 000만 지원하고, 다중 평가뷰를 지원하지 않는다. 유저가 추가한 필드도 지원하지 않는다.

 

이 방법은 사용은 간단하지만, 기술적 최적화를 위해서는 세 번째 방법으로 최적화한 쿼리를 구성하는 게 가장 낫다고 한다.

 

 

나라면 어떻게 할까? 사이트 요구사항마다 조금씩 다르겠지만 기본적으로는 ACDOCA와 COSP_BAK 테이블을 갖고서 나만의 CDS 뷰를 만드는 식으로 대응할 것 같다.