SAP Tuning 실무 2003.02 SK㈜ ERP TFT.

SAP Tuning 실무 SK㈜ ERP TFT

3. Tuning 방법 결정(DB or ABAP) 4. Performance Trace (DB)
목 차 1. SAP Architecture의 이해 2. Monitoring 3. Tuning 방법 결정(DB or ABAP) 4. Performance Trace (DB) 5. Run Time Analysis (CPU) 6. SAP Table 내 Index 생성 7. 기타 Tuning시 참고 사항 8. Q & A

1. SAP Architecture의 이해 Process의 흐름 **** 2 KB 0.1 ms 5 MB 120 MB 1 ms
SAP GUI SAP GUI SAP GUI SAP GUI SAP GUI Frontend- App Presentation **** 2 KB Application Dispather Dispather Gateway Gateway 0.1 ms 5 MB Table Buffer Enqueue Table Table Buffer DIA WP BTC WP SPO WP DIA WP ENP WP 120 MB 1 ms 32 KB Database DB WP DB WP 500 MB DB WP **** 10 ms ABAP Performance의 2가지 중심 Focus - Reducing the CPU load  Reducing the run time of programs on the application server - Reducing the Database load 10 GB – GB

1. SAP Architecture의 이해(2)
Database Interface Native SQL Database data Application server Database server ABAP interpreter SELECT * FROM ... EXEC SQL. SELECT ... END EXEC. OPEN SQL Data DB interface Local buffers Database Open SQL을 쓸 경우 DB Interface 가 MANDT를 붙여주고, 실제 DBMS에서 수행 될 SQL문장을 만든 후 DBMS와 통신하여 Data를 가져옴 (Local buffer에 저장) Exec SQL을 쓸 경우 DB Interface를 거치지 않고 바로 DBMS와 통신 - R/3상세서 SQL 분석 불가 - Local Buffer 사용되지 않음 - 반드시 MANDT 조건을 SQL문장에 삽입하여야 함

Process ID 로 ST04에서 Query 분석시 사용
2. Monitoring - SM66 가. SM66 : System wide work process overview Process ID 로 ST04에서 Query 분석시 사용 Time 순 Sort Report 항목에 같은 이름이 많이 뜨는 것 or 같은 Table항목에 오랬동안 걸려있는 경우등은 DB Tuning 대상이 됨  ST04로 이동 (PID항목의 Process 번호는 ST04 조회시 구분 Key 임) Processing 중인 Report 항목중 Table 항목에 Display 되는 내용없이 오랫동안 지속되면 Runtime analysis 대상임  SE30으로 이동 SM66에서 해당 프로세스를 Double click 하여도 Report의 Full name이 보이지 않는 경우, Login App. Server가 Job이 수행되고 있는 App. Server 와 틀린경우는 SM51에서 해당 서버로 들어가면 (SM50) Full name 조회 가능, App. Server가 동일한 경우는 SM50으로 바로 이동하여 조회 가능 접속 App. Server

2. Monitoring - SM51 vs SM50 나. SM51 vs SM50 Dbl Click Dbl Click

2. Monitoring - ST04  Thread Activity
Next Page ST04 : Database performance anaysis : DB2 for OS/390  실시간(현재 Processing 중인 Job) Database performance analysis 에 사용 사용방법 - Thread activity 버튼 Click - Thread activity 화면에서 검색대상 Process를 WP ID 항목에서 찾은 후 SQL Statement 버튼 Click(WP ID 검색시 Sort 버튼 사용하면 편리함)

2. Monitoring - Thread Activity : SQL Statement
Next Page ST04  Thread Activity  Thread Activity : SQL Statement 사용방법 - SQL statement test 에서 현재 Processing 중인 SQL문 확인 가능 (실제 수행중인 조건은 “?”로 표시 되며, 필드 조건만 확인 가능) - Explain SQL Statement 버튼을 눌러 DB Performance 관련 세부 사항 확인

2. Monitoring – Explanation of SQL Access Path
ST04  Thread Activity  Thread Activity : SQL Statement  Explanation of SQL Access Path : Access Path Tab 사용방법 - 현재 수행중인 SQL의 Access path 적합성을 확인 - Table을 Full Scan하고 있거나, 잘못된 Index를 Access하고 있는지 여부 감지 (만약 잘못되어 있다고 의심되는 SQL이 있는 경우 DB Tuning 대상임) 동일 화면은 T-Code SDBE 에서도 조회 가능

Table Information Next Page ST04  Thread Activity  Thread Activity : SQL Statement  Explanation of SQL Access Path : Table Information Tab 사용방법 - 현재 수행중인 SQL에 포함되어 있는 Transparent Table 정보  실제 현 상황의 Table 정보가 아닌, Table의 Static(통계) 정보  Table 통계정보는 주단위로 Basis에서 Table에 Runstatic 을 돌리면 갱신됨 - Table을 선택 후 Col.card, Col.dist 버튼을 누르면 상세 정보 조회 가능 가. Col.card 버튼 : Column Cardinalities (Table의 Column 별 Distinct 수) 나. Col.dist. 버튼 : Column Distributions (Table의 Index 순서별 Distinct 수)

Column Cardinalities vs Column Distributions Column Distributions Column Cardinalities ST04  Thread Activity  Thread Activity : SQL Statement  Explanation of SQL Access Path : Table Information Tab 수행방법 가. List에서 Table 선택 후 Col.card. 버튼을 누른다 나. List에서 Table 선택 후 Col.dist. 버튼을 누른다 다. Column Cardinality 및 Ditribution은 Index 생성 변경시 중요 참고 자료가 됨

Index Information First Key Cardinality Full Key Cardinality ST04  Thread Activity  Thread Activity : SQL Statement  Explanation of SQL Access Path : Index Information 수행방법 가. Index 별 First key cardinality, Full key cardinality 등을 확인 할 수 있다 나. First key cardinality, Full key cardinality는 DBMS의 Optimizer가 적합한 Index를 선정할 때 선정기준이 될 수있음

STAT : Local Transaction Statistics
2. Monitoring – STAT STAT : Local Transaction Statistics STAT : Local Transaction Statistics  Login한 App. Server에서 수행된 JOB의 수행정보를 조회한다.  일정Log 이상이 차면 새로운 Data로 Refresh 되므로 오래전의 수행정보는 볼수없음 수행방법 가. 검색대상 User, T-Code, Program, Start date, Start time등을 입력하고 Enter Next Page

App. Server에서만 수행된시간 (DB Time 제외)
2. Monitoring – STAT STAT – Workload : Display Statistical Records 총 수행시간 Next Page App. Server에서만 수행된시간 (DB Time 제외) 전체 수행시간 중 DB에 관련하여 수행된 시간 STAT – Workload : Display Statistical Records  조회조건에 해당하는 수행 List가 출력됨 사용방법 가. 수행된 Job의 List 중 Response time, CPU Time, DB Req Time 을 확인한다 나. Response time에 비해 CPU Time의 비율이 높은 것은 Run time analysis 대상임 다. Response time에 비해 DB Req. time의 비율이 높은 것은 DB Tuning 대상임 라. List항목 Double click하면 세부 List로 이동

STAT – Workload : Display Statistical Records
2. Monitoring – STAT STAT – Workload : Display Statistical Records STAT – Workload : Display Statistical Records (List 상세) 사용방법 가. 수행된 Job의 List 중 Response time, CPU Time, DB Req Time 을 확인한다 나. Response time에 비해 Processing Time의 비율이 높은 것은 Run time analysis 대상임 다. Response time에 비해 DB Req. time의 비율이 높은 것은 DB Tuning 대상임

ST03 – Workload : Analysis of SAP System (System명)
2. Monitoring – ST03 ST03 – Workload : Analysis of SAP System (System명) ST03 – Workload : Analysis of SAP System (System 명)  APP. Server에 상관없이 전체 System의 수행 Log 분석 가능  STAT에 비해 개괄적인 정보 조회 사용방법 가. Performance database 버튼을 누름 나. 분석대상 서버 선택 or 특정 App. Server 선택 다. 분석대상 기간 선택 Next Page

ST03 – Performance : Workload overview for Server TOTAL
2. Monitoring – ST03 ST03 – Performance : Workload overview for Server TOTAL Next Page ST03 – Performance : Workload overview for Server TOTAL  Total Server에 대한 평균적인 Response Time 현황을 볼수있다  해당기간에 수행된 Job중 수행속도가 상위 40위까지를 보거나(Top time) Program, T-Code에 해당하는 수행로그를 조회하는 화면으로 이동할 수있다 (Transaction Profile) 사용방법 가. Top time 버튼을 누른다 수행시간 기준 상위 40개 항목을 확인하고, Response time, CPU Time, DB req time 등을 확인한다.(Tuning 대상선정시 활용 가능)  Workload : Top 40 with Respect to time consumption 나. 특정 프로그램 및 T-Code에 해당하는 수행시간 분석을 위해 Transaction profile 버튼을 누른다.

ST03 – Workload : Transaction Profile Report
2. Monitoring – ST03 ST03 – Workload : Transaction Profile Report ST03 – Workload : Transaction Profile Report  특정 Program, T-Code에 해당하는 작업 수행 log 분석 사용방법 가. 검색버튼을 누른 후 찾고자 하는 Program명 or T-Code를 입력 후 검색

ST03 – Workload : Transaction Profile Report
2. Monitoring – ST03 ST03 – Workload : Transaction Profile Report ST03 – Workload : Transaction Profile Report  특정 Program, T-Code에 해당하는 작업 수행 log 분석 사용방법 가. 해당 프로그램, T-Code에 해당하는 Job의 전체 Step 수, Response time, CPU time DB time 등을 확인한다 Step 수 : 수행 STEP 수(대략 Dialog 인 경우는 화면 전환수, Report인 경우는 조회 수) Response time : 전체 수행시간 (보통 CPU time + DB time + 기타 time) CPU time : DB에 상관없이 App. Server단에서 수행된 시간 DB time : DBMS에 request를 던져 결과를 받는데 걸린 시간 나. Response time에 비해 CPU time의 비중이 큰경우  Run time analysis (SE30) 다. Reponse time에 비해 DB time의 비중이 큰경우  DB Tuning (ST05 , Index, Join 등…) * 수행시간이 길어서 수 만초 이상이 되는 경우는 CPU time, DB time의 숫자가 왜곡될 수 있음

3. SAP Tuning 방법의 결정 (DB or ABAP)
DB 관련 Tuning 작업 수행 - ST05 에서 SQL 분석 - Index 생성/변경/삭제 - Nested Loop  Join 등… Monitoring - SM66 - ST04 - STAT - ST03 DB What is a bottleneck ? DB or CPU ? CPU ABAP Tuning 수행 - SE30 : Run time analysis - Binary search… - Logic 수정 SM66 (SM50,SM51), ST04, STAT, ST03을 통해 확보한 프로그램, T-code의 수행정보를 기준으로 해당 프로그램의 Bottleneck을 파악한다. 만약 해당 프로그램의 Bottlneck이 DB에서 자료를 가져오거나 처리하는데 있다면 - ST05 (DB Performance Trace) 화면에서 해당 프로그램의 SQL 분석을 수행하거나 - ST04, ST05에서 파악된 SQL에 포함되어 있는 Table에 적합한 Index가 없는 경우 Table분석을 통해 적합한 Index를 생성/변경/삭제 하거나 - 해당프로그램에서 Loop로 수행되는 것에 대해 JOIN을 수행하거나 하여 프로그램을 Tuning 한다. 만약 Bottleneck이 CPU라면 - SE30 (Runtime analysis)에서 프로그램중 어느 부분이 많은 수행시간을 주는지 파악 하여 조치한다.  대개의 경우 다량의 Data를 Standard type의 Internal table을 Key로 Handling하여 처리하는 경우임, 이경우에는 ABAP의 Binary search 기능을 사용함 - Logic상 문제가 없는지 파악하여 수정한다.

4. Performance Trace (DB) – ST05
ST05 – Trace Requests Next Page 특정시점에 특정 User가 수행하는 SQL의 분석이 가능하다  R/3 Database Interface 가 수행하는 Job에 대한 Log임 (App Server 단에서 수행되는 부분은 분석이 안되며, App. Server와 DBMS간의 통신 부분만 List됨) 수행방법 가. Trace on : 해당 Login user의 DB Interface에 대한 Trace on 나. Trace on for user : 특정 User 지정 가능 다. Trace off : 현재 Trace가 off 됨 라. List Trace : Trace된 결과 분석 마. Explain one SQL request : SQL Statement에 대한 Plan 분석 가능 (T-Code : SDBE 와 동일) 수행순서 가. Trace on  Job 수행  Trace off  List trace 주의사항 가. Log가 많이 남을 경우 Data가 많아 분석이 용이 하지 않음 (너무 장시간 돌리지 말 것) 나. Trace on 상태에서는 Log를 남기기 위해 시스템에 무리가 갈 수있음으로 운영시스템에서는 사용시 Basis와 협의 다. 한 App. Server당 한 개의 Trace file이 생성되며, 다른 사람이 수행시에는 Log File이 Overwrite 됨 기타 활용 가능 부분 가. Table Access 정보 : CBO PGM 생성시 활용 가능

ST05 – Basic SQL List – Sorted by PID Explain ABAP Display Next Page Duration Operation Double Click시 실제 DBMS에 전송된 SQL 조회 가능 Table or View name ST05 – Basic SQL List – Sorted by PID 버튼 및 화면 설명 가. Operation : PREPARE, OPEN, FETCH, REOPEN, EXEC 등 DBMS에서 수행된 Operation 구분 나. Duration : Operation 수행될때 걸린 시간(단위 micro second) 다. Explain : ST04에서 본 것과 같은 SQL 분석 화면으로 이동 라. ABAP Display : 해당 SQL이 있는 Program내 ABAP Source로 이동 마. 화면상 SQL을 Double click시 실제 DBMS로 전송된 SQL 조회 가능 바. Extended list : 좀더 상세한 정보가 보임  Next Page

ST05 – Extended SQL List – Sorted by PID Next Page Array Record counts ST05 – Extended SQL List – Sorted by PID 버튼 및 화면 설명 가. Array : DBMS에서 App. Server로 Data Fetch시 32KB에 담길 수 있는 Record Count 나. Record counts : Fetch시 실제 Fetch 되어오는 Record counts  실제 Fetch가 얼마나 효율적으로 이루어지는지 판단 가능 다. 메뉴 Goto >> Summary : List의 Access하는 Table의 Summary 정보  Next Page

ST05 – SQL Trace : Select Data for Compression Next Page ST05 – SQL Trace : Select Data for Compression 버튼 및 화면 설명 가. Table 항목은 Table or View의 Access 시 소요된 시간을 순차적으로 표시  Table 항목을 분석하면 실제 PGM에서 Loop로 수행되고 있는지 판단 가능 나. Summarize 버튼 : Summary List를 Table 소요시간으로 집계  Next Page

ST05 – SQL Trace : Display Compressed Data ST05 – SQL Trace : Display Compressed Data 화면 설명 가. Table : Access한 Table or View 나. Accesses : Table or View에 Access한 횟 수 다. Recs. : Table or View를 Access하여 가지고 온 Record 수 라. Time : Table or View를 Access하여 Data를 가지고 올때 걸린 시간의 총합 마. Percent : Table or View를 Access하여 Data를 가지고 올때 걸린 시간의 Percent 비율

5. Run Time Analysis (CPU) – SE30
SE30 – ABAP Runtime Analysis : Initial Screen 분석 결과 파일의 Short Desc. In parallel session: 현 App. Server에서 수행중인 Job에 대한 분석 In Current session: 특정 PGM, T-Code, Func. 에 대한 분석 Next Page Restriction : 분석에 대한 Option 지정 Performance file : 분석 결과 파일 및 해당 파일에 대한 분석 수행 ST30 – ABAP Runtime Analysis : Initial Screen  해당 App. Server에서 수행중인 Job에 대한 분석이나, 특정 PGM, T-Code, Func. 에 대한 수행 결과 분석에 사용됨  해당 App. Server내 분석결과가 적용 됨  App. Server가 다를경우 SM51에서 다른 서버로 Login후 분석하여야 함  Log File 크기에 제한이 있음으로 장시간의 분석은 한번에 할 수는 없음  여러 차례 분석결과가 서버별로 파일로 저장되어 있음 화면 설명 가. Comment : Runtime Analysis 결과 File의 Short Description 나. In Current Session : 특정 T-Code, PGM, Func. 모듈명을 입력하고 Execute 버튼을 누르면 수행 로그에 대한 분석 가능 다. In parallel session : 현재 Login되어있는 App. Server에서 수행되고 있는 Job에 대한 실시간 분석 가능  아래에 추가 설명 라. Restrictions : 분석시 사용될 기준에 대한 Option을 지정하는 Variant를 지정하거나, 생성/변경/조회  Next Page 마. Performance Files : 분석결과를 Analyze 하고 기 생성되어 있는 결과의 조회 및 분석 수행 가능  아래에 추가 설명

SE30 – Restrictions에 Variant Setting 기존 Variant option 변경시 사용 ST30 – Restrictions에 Variant Setting  Variant 항목에서 Search help 하면 Selection Criteria for Variants 항목이 나오고 계속 진행하면 자신이 만든 Variant 항목이 Display 된다  기존 Variant 를 조회 변경하거나, 신규 Variant 생성 할 수있다. (기존 Variant 변경은 Restriction 사용방법 가. 신규 Variant를 생성하여 분석시 사용될 조건에 대한 option 설정을 한다  Next Page Next Page

SE30 – Change Measurement Restriction Variant ST30 – Change Measurement Restriction Variant  Pragram (Parts) Tab - 프로그램내 어느 부분에 대해 분석을 수행할 지 제한함 사용방법 가. Particular units : 이 옵션이 Check 되어 있으면 ABAP Program내의 SET RUNTIME ANALYZE ON : SET RUNTIME ANALYZE OFF 구문 사이의 로그만 분석함 나. Within and below : 이 옵션이 Check 되어 있으면 Sub Routine 까지 분석함 다. 특이사항이 없는 경우 위의 화면과 같이 Setting 권장

SE30 – Change Measurement Restriction Variant ST30 – Change Measurement Restriction Variant  Statement Tab - 어떤 종류의 Statement의 분석을 저장할지 지정 사용방법 가. 프로그램의 각 부분중 Runtime Analysis를 수행할 부분을 Check 한다 나. 대개 프로그램 수행시 전체 PGM, Event, Func. 모듈, Subrotine의 수행속도 Internal Table Operation DB Access시 수행속도 및 Data Fetch시 수행속도 등에 관심이 많으므로 위의 화면대로 수행한다. 다. 세부항목의 설명은 Help를 참조

SE30 – Change Measurement Restriction Variant 분석 File의 크기 및 분석 최대 시간 지정 Aggregation : 분석 Type 지정 ST30 – Change Measurement Restriction Variant  Duration and Type Tab - 분석 File의 최대크기 및 최대 시간 지정 - 분석시 프로그램내 동일 part와 Statement에 대해 수행된 시간을 어떻게 합쳐 줄지 Option 지정 사용방법 가. Aggregation type ) Full 프로그램내 동일 part 또는 동일 Statement에 해당하는 시간을 합계하여 보여줌 2) By Call 분석 레벨이 동일한 (예 동일 Sub routine )경우 동일 part, 동일 Statement에 해당하는 시간을 합계하여 보여줌 3) None 시간의 합계없이 각 part, statement에 대한 수행시간을 보여줌 나. 사용방법 프로그램 분석시 Full option으로 분석하면 전체 프로그램에서 buttleneck이 되는 part 또는 statement를 확인할 수있음 None 으로 각 part, statement에 대한 세부 수행시간을 볼 수있음(단 Log file 크기가 제한이 있고, Log가 많이 쌓임으로 장시간의 분석이 어려움) 대개 Full 로 분석후 상세내용을 알기위해 By Call, None의 순으로 분석 수행함

SE30 – Measuring the Data 현재 Login되어 있는 App. Server내에서 수행되고 있는 Job의 실시간 분석 Transaction, Program, Function module명을 입력한 후 직접 실행하여 분석시 사용 1. Start measurement : 분석을 수행하고자 하는 Job에 해당하는 Line에 Cussor 위치 2. End measurement ST30 – Measuring the Data 사용방법 가. In Current session : 직접 T-code, PGM 명, Function 모듈명등을 입력한 후 Execute 버튼을 누르면 해당 화면으로 이동함, Job 수행 완료 후 Back 버튼 이용하여 SE30 화면으로 이동하면 분석 File이 생성됨 나. In parallel session : 현재 Login 되어있는 App. Server에서 수행되고 있는 Job 의 실시간 분석에 사용되며, Enable/Disable 버튼을 누른 후, 해당 프로세스를 찾아 Cussor를 위치하고 Start measurement  End measurement 하면 Start 와 End 사이의 분석 File 생성됨

SE30 – Analysing the Data Log File 정보 Log File 삭제 이전 Log file 분석시 사용 Next Page ST30 – Analysing the Data - 현재 Login 되어 있는 App. Server에 저장되어 있는 Log File 분석 - 다른 서버로 이동시는 SM51로 이동 사용방법 가. Analyze 버튼 : 현재 창에 Display 되고 있는 File에 대한 분석  Next Page 나. Other file… : 이전 Log file 분석

SE30 – RunTime Analysis Evaluation : Overview HIT List Group(Interanl Table, DB Table, Method…) 별 세부 HIT List가 조회 Next Page 금번 분석시 App. Server의 CPU에서 수행된 시간과 DB작업을 수행한 시간 을 비교 할 수 있음 ST30 – RunTime Analysis Evaluation : Overview - Log file 분석의 Initial 화면 - 전체 Log 중 App. Server 수행시간(ABAP), DB 작업시간(Database)를 비교할 수 있으며 각종 분석 List로 이동 할 수있다 사용방법 가. Hit List : 세부 분석 List 화면으로 이동  Next Page 나. 기타 Hit List 버튼들 Group Hit List : DB table 별, Internal Table별, Method Table 별등으로 Grouping 되어 Hist List가 집계됨 DB Table Hit List, Internal Table Hit List, Method Hit List….. : 각 Group별 특화된 Hit List 조회 주의사항 - Aggregation Type이 Full 인 경우는 Hit List 버튼만 보임

SE30 – RunTime Analysis Evaluation : Hit List Absolute<->% Display Source Code Call Hiearachy Net Time Call 되어지는 Part or Statement Gross Time Call Hiearachy ST30 – RunTime Analysis Evaluation : Hit List - Log file의 Hit List(Call 되어지는 Part 별 수행시간 Log) 분석 사용방법 가. Gross Time과 Net Time Gross : Call 되어지는 Part or Statement내에 포함되어 있는 Sub part, statement 의 수행시간까지 포함된 시간  전체 프로그램 중 수행시간이 가장오래걸린 Part or Statement를 찾는데 용이 Net : Call 되어지는 Part or Statement내에 포함되어 있는 Sub part, statement 의 수행시간은 포함되지 않은 시간  실제 Part별 수행시간을 분석하는데 용이 * 대개 Net Time 순으로 Sort 하여 검색하면 실제 수행시간에 가장 영향을 주는 Part를 찾는데 용이함 나. Absolute <-> % : 시간단위(micro second) 로 표시할 건지 전체대비 Percentage로 표시 할 것인지 여부 다. Display Source Code : Call 되어지는 part or statement의 ABAP Source로 이동 라. Call Hiearachy : 해당 Part의 수행시간을 구성하고 있는 세부 내역으로 이동 (Aggregation type이 “Full””인 경우는 볼 수없음)

6. SAP Table 내 Index 생성 – 기본 원칙
Index 생성/변경/삭제 시에는 Table에 관련된 모든 SQL을 검토 한 후 수행 Standard PGM의 SQL은 대상에서 제외  Standard 화면에 대한 Tuning은 SAP Notes등을 참조함 Table에 연결되어 있는 View를 사용한 CBO PGM도 분석함 Equal 조건, Date 조건은 Index를 만드는데 중요한 기준임 Column 별 Cardinality(분포도) 고려 필요 Column 별 Data 분포 파악 필요 기존에 Access 되고 있는 Index에 중간 필드가 누락되 부분이 없는지(BUKRS 등..) 등을 살펴 보아야 함 Index 생성시에는 Standard Index와 경쟁이 되지 않도록 구성 Open SQL의 경우 DB Interface가 MANDT필드를 넣어줌 Index 생성 후에는 반드시 Index를 DB 단에 만들어 주어야 하며 (Activate), 통계정보도 수정 해 주어야 DBMS Optimizer가 생성 /변경/삭제된 Index를 인식할 수있음(Run Static) Index 생성시 Table에 해당되는 PGM과 함께, 관련 View(CBO)에 연결되어 있는 PGM도 함께 봐야 함 Select 문 Matrix 생성을 위해 Excel에서 1차 작업하여 필요없는 부분 지운후 출력하면 작업 용이 Index 생성/변경시 기준이 되는 것(또는 Driving 하여야 하는) 필드는 Date가 있는 경우에는 Date를 가져오면 좋음(Date에 연결되어 있는 것 중 크거나 같은 조건이면 Index 생성에 유리하나, 작거나 같은 것은 있으나 마나-현재일 보다 작은 자료는 전 체 자료임) Index 생성시에는 EQ 조건인지, IN or <=, >= 인지가 중요함, Index의 제일 먼저 와 야할 필드는 EQ 조건으로 생성되어 있는 것이어야 함 Index 생성시에는 해당조건에 대한 자료의 건수 파악이 중요, Catdinality가 좋지 않 아도 특정 조건에 대한 건수의 비율이 작으면 Index를 만들어 주는 것이 좋음 ABAP Open SQL의 경우 DB Interface 데몬이 SQL에 MANDT를 넣어줌, 그러므로 Index 구성시 반드시 MANDT를 고려하여 만들어야 함 Index를 개발 시스템에서 생성하여 CTS하여도 ABAP Data Dictionary 상에만 Index 가 존재하고 실제 DB에는 존재하지 않음, 해당 시스템(SKD, SKQ, SKP)에서 Activate 하여야 실제 Index가 DB에 생성됨 Index가 DB에 생성되어 있다 하더라도, DBMS의 Optimizer가 생성/변경/삭제된 Index 를 인식하기 위해서는 DBMS내의 통계정보를 Update 해주어야 함, 이런 작업을 Run Static이라고 하며, BASIS가 담당함 (운영시스템의 경우 1주일에 한번 일요일에 모든 Table의 Run Static을 수행함)

6. SAP Table 내 Index 생성 – Table Index 정보조회
SE11 – Display Table ABAP Data Dictionary 와 실제 DB의 상태를 점검하면서 Display ABAP Data Dictionary 와 실제 DB에 Index가 동일한지 여부 표시 Table에 생성되어 있는 Index SE11 : Display Table - 메뉴 utility >> Database object >> Check : ABAP Data Dictionary와 실제 DB상의 Object(예 Index)등의 동일성 여부등을 Check 하고, 해당 List를 Display 함  위의 메뉴에서 실제 Table에 생성되어 있는 Index를 확인 가능 Table에 생성되어 있는 Index 중 “Table명~0” 은 Primary Index로 Table에 Primary key 지정시 자동 생성됨 ABAP Data Dictionary와 DB내부가 Inconsitent 할 경우에는 비교 List가 Display되며 이 같은 경우 Index Activate등의 작업을 통해 Consistency를 유지 할 수있다 (DB상에 Index Generation 후에는 반드시 Run Static을 돌려야 함)  BASIS와 협의 필요

6. SAP Table 내 Index 생성 – Cardinality 조회
SE38 에서 ZMIRALUZ3 입력 후 실행  Table명에 입력 후 실행 최종 Run Static 수행일자 Column별 Cardinality Index Column별 Cardinality Column의 Cardinality 정보, Index정보 및 Run Static 정보를 조회하기 위해 Miraluz사에서 설치한 프로그램임 (ZMIRALUZ3)  DBMS내의 통계정보를 읽어다 Display 해줌 동일 정보는 T-Code SDBE에서도 조회 가능

6. SAP Table 내 Index 생성 – Table에 연관된 SQL 조회
SE11 – Display Table Where Used List - Table에 연관된 각종 Object 의 정보 조회 Table에 연결된 프로그램 조회시 : 연관된 SQL 조회 가능 Table에 연결된 View 조회시 사용 SE11 : Display Table – Table에 연관된 SQL 조회 - Where Used List의 Programs 를 선택하면 해당 Table을 참조한 모든 프로그램이 List 됨 Next Page

6. SAP Table 내 Index 생성 – Table에 연관된 SQL 조회
SE11 – Database table Table명 in Programs (** hits) Detail View Lines : 선택한 Program 항목에서 Table과 관련 된 부분을 Display Collapse : 펼쳐진 Program List를 접음 SQL 문장 SE11 : Database table Table명 In Programs (** hits) - Table이 연관되어 있는 Program의 부분을 조회 할 수있다 사용방법 가. Detail View Lines 버튼을 누르면 세부 List가 펼쳐짐 나. 해당 List가 많은 경우 List를 Download 받아 Excel등으로 가공하여 필요없는 부분을 삭제하고 검토하는 것이 편함

6. SAP Table 내 Index 생성 – SQL 검토 및 Matrix 생성
Z01 : MANDT + VGABE + BUDAT Z02 : MANDT + LFBNR + LFPOS Table과 연관되어 있는 SQL을 검토/분석하여 각 CASE 별 횟수 및 유형을 정리한다. (실제 프로그램내 어느 부분이 어느 유형에 해당되는지 조사하면 편리) Table과 연관된 View에 대해서도 분석한다. 유형검색시에는 - Equal 조건으로 들어온 것 - OR, IN 조건으로 들어온것 - 날짜의 경우에는 >, <, Between등으로 들어 왔는지를 분석한다. Matrix 생성작업이 끝나면 필요한 Index를 만들거나, 변경/삭제 할지를 결정한다. (이때 Table의 기 생성된 Index List, Column의 Cardinality, Data 분포등이 참고 자료가 됨) 생성/변경/삭제 대상 Index가 결정되면, Tuning Report를 작성하고 해당모듈의 ABAP 담당자와 협의 후 실제 Index를 생성한다.

7. 기타 Tuning시 참고 사항 Select *  Select 해당 필드
Loop 내에서 Loop or Read table 하는 경우  Binary Search Date 조건중 작거나 (같다) 조건인 경우  업무 재분석을 통해 조건을 빼거나, 범위값으로 주도록 수정 Where 절이 없는 Select 문  Where 절 수정 Nested Loop, For all entries  Inner Join, Outer Join 활용 Index를 통한 Access시 Index 구성 필드중 중간에 빠진 것이 없도록 구성(BUKRS 등…)

8. Q & A ?

SAP Tuning 실무 2003.02 SK㈜ ERP TFT.

Similar presentations

Presentation on theme: "SAP Tuning 실무 2003.02 SK㈜ ERP TFT."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SAP Tuning 실무 2003.02 SK㈜ ERP TFT.

Similar presentations

Presentation on theme: "SAP Tuning 실무 2003.02 SK㈜ ERP TFT."— Presentation transcript:

Similar presentations

About project

Feedback