Month: October 2008

Inner Join, Outer Join, FOR ALL ENTRIES IN

Inner Join, Outer Join, 그리고 독특한 Open SQL 문법인 FOR ALL ENTRIES IN 까지.
정리가 잘 안 되어서(특히 performance 입장에서) 여러 문서를 찾아다녀 보았다.
아래는 그에 대한 간단한 정리.

  • database view는 inner join을 이용한다. 즉 database view는 모든 table에 공통적으로 있는 records만 제공한다.
  • help views와 maintenance views는 outer join을 이용한다.
  • INNER JOIN 과 FOR ALL ENTRIES IN 중 어떤 것이 낫다고 단정짓기 어렵다. 보통 FOR ALL ENTRIES IN 을 추천하지만 경우에 따라서 INNER JOIN 이 나은 성능을 보여주기도 하기 때문이다.
  • FOR ALL ENTRIES IN 은 ‘outer join’이다… 라기보다, 이 문법을 통해 outer join을 구현할 수 있다 – 고 이해해야 한다.
    단 주의할 점이 몇가지 있다.
    1. FOR ALL ENTRIES IN 을 사용할 땐 Select 하는 Field들이 모여서 자동으로 키 값이 되어 중복되는 값을 모두 배제해버린다. (즉 SELECT * FROM … 과 SELECT COL1 COL2 COL3 FROM … 의 결과가 틀려질 수 있다) 따라서  반드시 원래 테이블의 키 값들을 SELECT 다음에 다 써주는 것이 좋다.
    2. If the “one” table (the table that appears in the clause FOR ALL ENTRIES IN) is empty, all rows in the “many” table (the table that appears in the SELECT INTO clause) are selected. Therefore make sure you check that the “one” table has rows before issuing a select with the “FOR ALL ENTRIES IN” clause.
    3. If the table on which the For All ENTRIES IN clause is based is very large, the performance will go down. Hence attempt should be made to keep the table size to a moderate level.
  • SELECT … FOR ALL ENTRIES IN <itab> WHERE <cond> 의 로직은 다음과 같다.
    If you specify a field of the internal table <itab> as an operand in a condition, you address all lines of the internal table. The comparison is then performed for each line of the internal table.
    For each line, the system selects the lines from the database table that satisfy the condition. The result set of the SELECT statement is the union of the individual selections for each line of the internal table.
    Duplicate lines are automatically eliminated from the result set. If <itab> is empty, the addition FOR ALL ENTRIES is disregarded, and all entries are read.

새로운 SE30, 몇가지 흥미로운 것들

지난 주 참석한 TechEd@BST, ‘ABAP Performance and Trace Analysis’의 내용은 사실 SE30 – 엄밀히 말하면 새 버젼인 SAT – 의 소개와 사용법이 대부분이었습니다.
현재 자주 사용하고 있는 툴이라 대부분의 내용이 낯익은 것들이긴 했지만 몇가지 흥미로운(또는 새로운) 것들을 접할 수 있었지요.

몇가지만 적어보면,

  • Variants 설정 옵션에서 ‘Full aggregation’은 더이상 가용하지 않습니다. 대신 ‘Per Call Position’을 선택해야 하는데, 둘의 차이는 다음과 같습니다.

    Full aggregation → calling A func 1번 기록
    Per Call Position → loop 밖에서의 호출 1번, loop 내 호출 1번. 즉 총 2번 기록
  • 역시 Variants 설정 옵션에 보면 ‘Measure in Sections (See Long Text)’란 부분이 있는데, 즉 특정 부분의 측정이 가능합니다. 이에 대한 설정은 System > Utility > Runtime Analysis > Switch On / Off 를 이용해서 쉽게 할 수 있습니다.
  • 측정 결과를 보면 internal table의 이름은 it_xxx … 식으로 적힙니다. 첫 화면 하단의 ‘Data Formatting’ 섹션에서 ‘With Names of Internal Tables’ 옵션을 선택하면 원래 internal table의 이름으로 결과가 적히게 할 수 있습니다.
  • ‘In Parallel Session’ 부분은 장시간 수행되는 프로세스를 측정할 때 유용합니다. 제 경우 늘 골치 썩히는 ‘Poller’라는 Parallel Processing Job이 있는데 얘가 문제 발생시 주로 사용합니다. 급하게 Performance 측정시 유용하더군요.
  • ‘Schedule’ 역시 유용합니다. 옵션을 여러개 선택해야 하는데… 그냥 대부분 ‘Any’로 셋팅하고 사용합니다. 설정 문제인지 모르겠으나 제가 이용하는 테스트 시스템에서는 얘가 잘 동작을 안 하네요. (해서 옛날 SE30을 이용합니다)
  • Evaluate 부분에 다양한 feature가 소개되고 있더군요. 가장 인상적인 것은 1) 다양한 Filter option과 2) Sequence Diagram 자동생성 기능 이었습니다. 특히 Sequence Diagram 부분은 정말 환상적이었는데, 이것 역시 제가 이용하는 시스템에서는 아직 가용하지 않더군요. 괜히 한참 찾아 헤맸습니다… 헐…

TIOBE Programming Community Index

TIOBE Programming Community Index 가기

어떤 Programming Language가 가장 인기있는가를 보여주는 index 입니다.

제가 매일 사용하는 ABAP의 경우 순위가 가장 많이 떨어졌네요. 20위.
얼마전 시작한 Haskell의 순위는 36위. 헐…

하지만 저에겐 언제나 흥미로운 언어인 C++와 Python은 각각 3위와 6위를 차지하고 있네요.
all-time-favorite인 C는 부동의 2위를 차지하고 있고.

Self-Control

스튜디오 판타지아에서 읽은 흥미로운 글 – Self-Control.

골자는, 자제력을 관장하는 PFC(Prefrontal Cortex)라는 뇌의 부분은 비교적 연약해서 뇌에 약간의 부하가 걸려도 이 부분의 자원이 고갈되기 쉽고 그로 인해 자제력을 잃기 쉽다는 것이다. 즉 자제력이란 것이 천성적인 특성으로 생각하는 게 일반적이지만 사실은 일련의 외부적(천성과 반대 의미로) 요소에 의해 영향을 받으며, 이러한 외부적 요소는 우리의 뇌가 주어진 상황에 어떤 식으로 반응하는지에 영향을 미친다는 것.

… ‘생각에 쓸 수 있는 자원(thinking resources)’은 무한한 것이 아니라 한정적이며 우리는 싸우는 상대를 잘 선택해야 한다. 누구나 가끔은 맛나지만 살찌는 음식에 탐닉하게 되거나 어려운 문제를 만나면 금방 포기해 버리곤 한다. 이때 중요한 것은 완벽주의, 다시 말해 절대로 ‘나쁜 짓’은 하지 않겠다 – 라는 게 아니라 중요할 때 ‘좋은 짓’을 하는 것에 초점을 맞추는 것이다.
우리 뇌의 PFC는 금방 지쳐버리는 탓이다.

매사 완벽주의를 지향하는 잘못된 자세, 그러면서도 스스로를 계속 몰아치는 자신에게 보약과도 같은 글이었다.

background process 및 aRFC debug 하기

background process와 aRFC는 debug 할 때 아주 골치 아프다.
aRFC의 경우 F5 – F7 – F5 를 번갈아 작동시킴으로 debug를 하는데 background process는, 특히 ‘submit’로 다른 session으로 날라가는 경우는 breakpoint가 전혀 작동하지 않는다.

이 경우 보통 endless(infinite) loop를 이용하는 꼼수를 쓴다.

1. use the following code instead of break-point:

data a type c. do.
if a = 'X'. exit. endif.
enddo.

2. while the program is running in background, launch transaction SM50.

3. select the program in the list and choose Program/Mode > Program > Debugging

4. at this point the program should stop in the infinite loop. to exit from the loop, set the variable a to ‘X’

좋지 않은 SAP 3분기 실적

음, 회사가 어렵기는 한 것 같습니다.

그제 저녁 Henning과 Leo, 그리고 모든 보드멤버가 사내 video에서 언급했던 내용들은 모두 cost-saving에 대한 것들이었지요. 굉장히 이례적인 분위기에서 생방송으로 진행된 이야기는 headcount and hiring freeze, third-party 계약 연장 금지, 출장 금지, new equipment 신청 금지, 예산 동결 등등.

부정적인 3분기 실적으로 인한 주가 대폭락, 무엇보다 앞으로의 전망도 확인하기 어렵다는 판단하에 내린 일련의 조치였습니다.
Work Council 입장에서도 job security를 지킬 수 있는 한 적극 협조하는 분위기구요.

뭐, 좋은 건 휴가를 맘놓고 쓸 수 있다는 것 뿐이네요. (쓰지 않은 휴가는 부채로 잡히기 때문에 반강제적으로 사용하도록 종용하고 있습니다)
나머지는 다 어두운 이야기들 뿐이고.

회사가 힘든 이상, 개개인도 절감을 위해서 많이 노력해야 할 것 같습니다.
이 와중에 우리 solution에 대한 새로운 고객을 하나 더 확보한 것 같아 조금은 마음이 놓입니다만.