Academia Basis

ACADEMIA
BASIS
Junho/200
Joo Luiz Barbosa
jluiz@cemig.com.br
Pgina 1
ACADEMIA
BASIS
ndice
NDICE .................................................................................................................................................... 2
INTRODUO..................................................................................................................................... 11 PLANO DE ESTUDO................................................................................................................................. 11 ADVERTNCIA ........................................................................................................................................ 11 DIREITO DE AUTORIA ............................................................................................................................ 11 MARCAS REGISTRADAS. ........................................................................................................................ 12 PARTICIPANTES DA ACADEMIA ............................................................................................................ 12 PRIMEIRA SEMANA.......................................................................................................................... 13
R/3 BASIS TECHNOLOGY................................................................................................................ 13 BASIS SYSTEM AND THE SYSTEM ENVIRONMENT ............................................................................... 13 BUSINESS FRAMEWORK ARCHITECTURE ............................................................................................ 13 R/3 SYSTEM CLIENT/SERVER CONFIGURATIONS ............................................................................... 14 THE MIDDLEWARE BASIS ..................................................................................................................... 15 NAVIGATION ...................................................................................................................................... 17 LOGGING ONTO R/3 SYSTEM ................................................................................................................ 17 R/3 MENU STRUCTURE.......................................................................................................................... 17 SYSTEM KERNEL .............................................................................................................................. 19 R/3 PRESENTATION INTERFACE ........................................................................................................... 19 R/3 DATABASE INTERFACE ................................................................................................................... 19 WORK PROCESSES AND DISPATCHER .................................................................................................. 20 R/3 APPLICATION SERVICES................................................................................................................. 21 RULES FOR THE TYPE AND NUMBER OF PROCESSES IN THE APPLICATION ..................................... 21 R/3 TRANSACTION AND LUW............................................................................................................... 21 LOCK CONCEPT AND ASYNCHRONOUS UPDATE ................................................................................. 22 BACKGROUND PROCESSING ................................................................................................................. 23 R/3 PRINTER SERVICES ......................................................................................................................... 24 R/3 INSTANCE......................................................................................................................................... 24 INTERFACES....................................................................................................................................... 25 R/3 AS AN OPEN SYSTEM ....................................................................................................................... 25 R/3 GATEWAY SERVICE ........................................................................................................................ 25
jluiz@cemig.com.br Pgina 2
ACADEMIA
BASIS
COMMUNICATION WITH CPI-C............................................................................................................ 25 REMOTE FUNCTION CALL .................................................................................................................... 25 BUSINESS OBJECTS AND BAPIS ............................................................................................................ 26 R/3 SYSTEM AS AN OLE SERVER OR AN OLE CLIENT ....................................................................... 26 INTERNET ARCHITECTURE ................................................................................................................... 27 EDI ARCHITECTURE ............................................................................................................................. 27 DISTRIBUTION OF BUSINESS PROCESSES WITH ALE.......................................................................... 27 DATA TRANSFER AND BATCH INPUT.................................................................................................... 27 R/3 GRAPHICAL USER INTERFACE............................................................................................. 29 FRONTEND ADMINISTRATION .............................................................................................................. 29 SAPGUI INSTALLATION ....................................................................................................................... 29 TYPES OF ONLINE HELP........................................................................................................................ 29 SAPLOGON OPTIONS E TRACES ...................................................................................................... 30 SAP MAPI AND SAPGUI FOR JAVA .................................................................................................... 31 SAP ONLINE SERVICE SYSTEM (OSS)......................................................................................... 32 OSS OVERVIEW ..................................................................................................................................... 32 SAPNET .................................................................................................................................................. 32 SAP TECHNET ....................................................................................................................................... 32 STARTING AND STOPING R/3 NT VERSION ........................................................................... 33 OPERATING SYSTEM TASKS ................................................................................................................. 33 ADMINISTRATOR TASKS ....................................................................................................................... 33 PROCESS STARTUP SEQUENCE ............................................................................................................. 33 PARAMETER READ SEQUENCE ............................................................................................................. 34 LOGS AND TRACES ................................................................................................................................ 34 STARTUP DIAGNOSTICS......................................................................................................................... 34 BEFORE STOPPING THE R/3 SYSTEM .................................................................................................... 35 STOPPING THE R/3 SYSTEM................................................................................................................... 35 BACKUP OFF-LINE: DATABASE RECONNECT........................................................................................ 35 STARTING AND STOPING R/3 UNIX VERSION ...................................................................... 36 OPERATING SYSTEM TASKS ................................................................................................................. 36 DATABASE STARTUP AND LOGS ........................................................................................................... 36 R/3 STARTUP AND LOGS ........................................................................................................................ 36 STOPPING R/3 SYSTEMS ........................................................................................................................ 37 CCMS CONFIGURATION................................................................................................................. 38 OVERVIEW.............................................................................................................................................. 38 RZ10: PROFILE MAINTENANCE ........................................................................................................... 38 R/3 PROFILES ......................................................................................................................................... 38 OPERATION MODES ............................................................................................................................... 39 BACKGROUND PROCESSING ........................................................................................................ 41 BACKGROUND CONCEPTS AND FEATURES .......................................................................................... 41
ACADEMIA
BASIS
OPERATION MODES AND SCHEDULING ............................................................................................... 41 EVENTS IN JOB SCHEDULING ................................................................................................................ 42 CHANGING OR MONITORING BACKGROUND JOBS ............................................................................. 42 JOB API, XBP-API AND XMI-API....................................................................................................... 43 AUTHORIZATION FOR BACKGROUND JOBS ......................................................................................... 43 ADVANCED BACKGROUND PROCESSING ................................................................................ 44 TYPES OF BACKGROUND JOBS ............................................................................................................. 44 PARALLEL PROCESSING USING ASYNCHRONOUS RFC...................................................................... 44 XMI/XBP INTERFACE ........................................................................................................................... 45 EVENTS IN JOB SCHEDULING ................................................................................................................ 45 EXTERNAL COMMANDS AND EXTERNAL PROGRAMS ........................................................................ 46 AUTHORIZATIONS FOR BACKGROUND ................................................................................................ 46 ABAP API SCHEDULING ....................................................................................................................... 46 BACKGROUND CHECK AND TROUBLESHOOTING ............................................................................... 47 DATA ARCHIVING ............................................................................................................................ 48 DEFINITION ............................................................................................................................................ 48 HOW ARCHIVE WORKS ......................................................................................................................... 48 ARCHIVE ENVIRONMENT ...................................................................................................................... 48 ACESSING ARCHIVED DATA ................................................................................................................. 49 PREPARATIONS FOR DATA ARCHIVING ............................................................................................... 49 MONITORING AN ARCHIVING RUN ...................................................................................................... 49 SYSTEM MONITORING ................................................................................................................... 51 WHAT, WHY, WHO AND WHEN .............................................................................................................. 51 MONITORING ARCHITECTURE ............................................................................................................. 51 PREPARING THE MONITOR ................................................................................................................... 51 MONITORING AND TOOLS ..................................................................................................................... 52 SEGUNDA SEMANA........................................................................................................................... 54
USERS AND AUTHORIZATION IN THE R/3 SYSTEM .............................................................. 54 USERS IN THE R/3 ENVIRONMENT ........................................................................................................ 54 AUTHORIZATION CONCEPTS ................................................................................................................ 54 AUTHORIZATION AS ER ........................................................................................................................ 55 AUTHORIZATION CHECKS .................................................................................................................... 55 PROFILE GENERATOR ........................................................................................................................... 55 USER MASTER RECORD ........................................................................................................................ 57 SETTINGS FOR SYSTEM PROFILE PARAMETERS ................................................................................. 57 SECURITY ............................................................................................................................................... 57 INFORMATION SYSTEM E AUTHORIZATION TRACES ......................................................................... 57 PASSWORD RULES ................................................................................................................................. 58 PROFILE GENERATOR SETUP ............................................................................................................... 58 TRANSPORTING AUTHORIZATIONS AND USERS .................................................................................. 58 SAPROUTER........................................................................................................................................... 59 SNC SECURE NETWORK COMMUNICATION ........................................................................................ 59
jluiz@cemig.com.br
Pgina 4
ACADEMIA
BASIS
SOFTWARE LOGISTICS................................................................................................................... 61 R/3 SYSTEM, SERVERS AND INSTANCES............................................................................................... 61 R/3 DATA ................................................................................................................................................ 61 R/3 CLIENTS ........................................................................................................................................... 61 STANDARD CLIENT ROLES.................................................................................................................... 62 R/3 LANDSCAPE ..................................................................................................................................... 62 CHANGE REQUESTS AND TRANSPORTS ............................................................................................... 62 CHANGE AND TRANSPORT SYSTEM PREREQUISITES ........................................................ 64 CONFIGURING THE SYSTEM LANDSCAPE ............................................................................................ 64 INITIALIZING CTO ................................................................................................................................ 65 TMS - TRANSPORT MANAGEMENTA SYSTEM ...................................................................................... 65 CHANGE MANAGEMENT FOR DEVELOPMENT...................................................................... 67 CHANGE REQUESTS ............................................................................................................................... 67 WBO - WORKBENCH ORGANIZER ........................................................................................................ 67 DEVELOPMENT CLASS AND TRANSPORT LAYERS .............................................................................. 68 HANDLING REPOSITORY OBJECTS....................................................................................................... 69 THE REPOSITORY .................................................................................................................................. 69 R/3 UPGRADE ......................................................................................................................................... 70 WORKBENCH ORGANIZER TOOLS ....................................................................................................... 70 SETTINGS FOR WBO ............................................................................................................................. 70 PLANNING CHANGE MANAGEMENT..................................................................................................... 71 CHANGE MANAGEMENT FOR CUSTOMIZING........................................................................ 72 CUSTOMIZING CONCEPTS ..................................................................................................................... 72 CUSTOMIZING TOOLS IMPLEMENTATION GUIDE (IMG)................................................................ 72 CUSTOMIZING CHANGE REQUESTS ..................................................................................................... 73 CUSTOMIZING TESTS............................................................................................................................. 74 CUSTOMIZING EXCEPTIONS ................................................................................................................. 74 CLIENT-INDEPENDENT CUSTOMIZING ................................................................................................. 74 PLANNING CUSTOMIZING CHANGE MANAGEMENT ........................................................................... 74 TRANSPORT MANAGEMENT......................................................................................................... 76 TRANSPORT PROCESS............................................................................................................................ 76 IMPORT QUEUES .................................................................................................................................... 76 TRANSPORTING BETWEEN TRANSPORT GROUPS ............................................................................... 77 TRANSPORT MONITORING .................................................................................................................... 77 TRANSPORT PROCESS............................................................................................................................ 77 ADVANCED TRANSPORT MANAGEMENT ................................................................................ 78 TRANSPORT DIRECTORY ...................................................................................................................... 78 THE TP PROGRAM .................................................................................................................................. 78 THE R3TRANS PROGRAM ...................................................................................................................... 79 THE IMPORT PROCESS .......................................................................................................................... 79 TRANSPORT MONITORING .................................................................................................................... 81
jluiz@cemig.com.br
Pgina 5
ACADEMIA
BASIS
CLIENT TOOLS .................................................................................................................................. 82 CLIENT TRANSPORT .............................................................................................................................. 82 CLIENT COMPARE ................................................................................................................................. 83 CLIENT MAINTENANCE SETTINGS ....................................................................................................... 84 AUTHORIZATIONS FOR CLIENT TOOLS ................................................................................................ 84 CLIENT AND SYSTEM STRATEGIES ........................................................................................... 85 TYPES OF LANDSCAPES ......................................................................................................................... 85 THREE-SYSTEM LANDSCAPES .............................................................................................................. 85 TWO-SYSTEM LANDSCAPES .................................................................................................................. 85 ONE-SYSTEM LANDSCAPES................................................................................................................... 85 LANDSCAPE REQUIREMENTS ................................................................................................................ 86 ASAP SYSTEM LANDSCAPE .................................................................................................................. 86 ASAP RECOMENDATIONS ..................................................................................................................... 87 ALTERNATIVE LANDSCAPES ................................................................................................................. 87 TRANSPORT ORGANIZER ...................................................................................................................... 88 R/3 UPGRADES AND OCS PATCHES............................................................................................ 89 R/3 EVOLUTION AND RELEASE STRATEGY ......................................................................................... 89 R/3 UPGRADE ......................................................................................................................................... 89 REPOSITORY SWITCH ............................................................................................................................ 90 MODIFICATION ADJUSTMENT .............................................................................................................. 91 AVOIDING MODIFICATIONS IN R/3 SYSTEMS ...................................................................................... 91 ONLINE CORRECTION SERVICE (OCS)................................................................................................ 92 TERCEIRA SEMANA ......................................................................................................................... 93
R/3 SPOOL AND PRINT..................................................................................................................... 93 R/3 SPOOL SYSTEM................................................................................................................................ 93 SPOOL AND OUTPUT REQUESTS ........................................................................................................... 93 SPOOL WORK PROCESS ........................................................................................................................ 93 LOCAL AND REMOTE PRINTING ........................................................................................................... 93 SPOOL ADMINISTRATION ...................................................................................................................... 94 FRONTEND PRINTING ............................................................................................................................ 94 LOGICAL SPOOL SERVERS .................................................................................................................... 95 SPOOL REQUEST MANAGEMENT .......................................................................................................... 95 R/3 OUTPUT MANAGEMENT.......................................................................................................... 96 DEVICE POOLS ....................................................................................................................................... 96 EXTERNAL OUTPUT MANAGEMENT SYSTEMS (OMS) ....................................................................... 96 SPOOL SERVER AND REQUESTS MANAGEMENT ................................................................................. 96 NON-STANDARD PRINTERS ................................................................................................................... 97 CHARACTER SET .................................................................................................................................... 97 FORMAT, PAGE FORMAT E FORMAT ACTIONS .................................................................................... 97 PRINT CONTROLS ................................................................................................................................... 97 MESSAGE CONTROL AND EDI .............................................................................................................. 97
jluiz@cemig.com.br
Pgina 6
ACADEMIA
BASIS
SAPCONNECT ......................................................................................................................................... 98 INSTALLATION CHECK .................................................................................................................. 99 HARDWARE E SOFTWARE ..................................................................................................................... 99 ORACLE DATABASE ............................................................................................................................... 99 R/3 SYSTEM .......................................................................................................................................... 100 R/3 WORKLOAD DISTRIBUTION ................................................................................................ 102 OVERVIEW............................................................................................................................................ 102 MECHANISM ......................................................................................................................................... 102 LOGON LOAD BALANCING .................................................................................................................. 102 BACKGROUND LOAD BALANCING ...................................................................................................... 103 SPOOL LOAD BALANCING ................................................................................................................... 103 UPDATE LOAD BALANCING ................................................................................................................ 103 CONFIGURATION SUMMARY ............................................................................................................... 104 QUARTA SEMANA........................................................................................................................... 106
DATABASE FUNDAMENTALS...................................................................................................... 106 ORACLE OVERVIEW ............................................................................................................................ 106 STARTING AND STOPING THE DATABASE .......................................................................................... 108 ORACLE SHARED PROCESSES ............................................................................................................. 108 R/3 ORACLE STRUCTURE .................................................................................................................... 109 NET8 BASIS .......................................................................................................................................... 110 DATABASE MONITORING .................................................................................................................... 111 BACKUP ESTRATEGY .................................................................................................................... 112 DATABASE BACKUP ............................................................................................................................. 112 BACKUP TYPES .................................................................................................................................... 112 BACKUP AND RECOVER DIAGRAM ..................................................................................................... 113 DATA LOSS ........................................................................................................................................... 113 BACKUP RECOMMENDATIONS ............................................................................................................ 113 FINAL RECOMMENDATIONS ............................................................................................................... 114 TAPE MANAGEMENT..................................................................................................................... 115 TAPE POOLS ......................................................................................................................................... 115 TAPE INITIALIZATION ......................................................................................................................... 115 TAPE LOCKING .................................................................................................................................... 115 TAPE SELECTION ................................................................................................................................. 115 TAPE LAYOUT ...................................................................................................................................... 116 SCHEDULING, PERFORMING AND MONITORING BACKUPS ........................................... 117 BACKUP TOOLS FEATURES ................................................................................................................. 117 BACKUP PROFILE PARAMETERS ......................................................................................................... 117
ACADEMIA
BASIS
PHASES OF DATABASE BACKUP.......................................................................................................... 117 DATABASE BACKUP CHECK AND MONITORING ............................................................................... 118 OFFLINE REDO LOG FILES BACKUP .................................................................................................. 118 LOG FILE CLEANUP ............................................................................................................................. 119 FREESPACE ADMINISTRATION ........................................................................................................... 119 ONE-RUN STRATEGY ........................................................................................................................... 119 FURTHER DOCUMENTATION............................................................................................................... 119 ADVANCED BACKUP TECHNIQUES .......................................................................................... 120 ONE-RUN STRATEGY ........................................................................................................................... 120 CONSISTENT ONLINE BACKUP ........................................................................................................... 120 PARALLEL TAPE SUPPORT .................................................................................................................. 120 PARTIAL DATABASE BACKUPS ........................................................................................................... 120 BACKING UP DATA TABLESPACES ONLY .......................................................................................... 120 TWO-STEP DISK BACKUP.................................................................................................................... 121 STRUCTURES-RETAINING DATABASE COPY ..................................................................................... 121 SPLIT MIRROR DISK BACKUPS ........................................................................................................... 121 SAP TOOLS AND ORACLE STANDBY DATABASE ............................................................................... 122 EXTERNAL BACKUP TOOLS USING BC-BRI ..................................................................................... 122 RESTORE AND RECOVERY.......................................................................................................... 123 DATABASE ERRORS ............................................................................................................................. 123 SCENARIO ............................................................................................................................................. 123 PARTIAL RESTORE AND COMPLETE RECOVERY .............................................................................. 123 DATABASE RESET ................................................................................................................................ 123 POINT IN TIME RECOVERY ................................................................................................................. 124 HOW TO PROCEED AND WHO SHOULD MANAGE THE PROBLEM.................................................... 124 PARTIAL RESTORE USING SAPDBA.................................................................................................. 124 DATABASE RESET USING SAPDBA ................................................................................................... 125 FULL RESTORE AND RECOVERY USING SAPDBA............................................................................ 125 STORAGE MANAGEMENT............................................................................................................ 126 SPACE MANAGEMENT ......................................................................................................................... 126 FRAGMENTATIONS .............................................................................................................................. 126 DAILY MONITORING: SAPDBA -CHECK ........................................................................................... 126 TABLESPACE EXTENSION.................................................................................................................... 127 TABLES AND INDEXEX MONITORING ................................................................................................. 127 ANALYZING STORAGE ALLOCATION: SAPDBA -ANALYZE ............................................................ 127 REORGANIZATION ............................................................................................................................... 128 PERFORMANCE MONITOR.......................................................................................................... 130 PERFORMANCE ISSUES ........................................................................................................................ 130 COST-BASED OPTIMIZER .................................................................................................................... 130 MEMORY CONFIGURATION ................................................................................................................ 131 APPLICATION DESIGN ......................................................................................................................... 132 PHYSICAL AND LOGICAL LAYOUT ..................................................................................................... 133 QUINTA SEMANA ............................................................................................................................ 135
jluiz@cemig.com.br
Pgina 8
ACADEMIA
BASIS
TOP 10 PROBLEMS.......................................................................................................................... 135 ARCHIVE STUCK SITUATION .............................................................................................................. 135 THE INCORRECT TAPE SIZE DRIVERS WITH HARDWARE COMPRESSION ...................................... 135 A MISSING END BACKUP................................................................................................................. 135 A TABLESPACE OVERFLOW................................................................................................................ 136 A TABLE OR INDEX REACHING THE MAXEXTENTS LIMIT .......................................................... 136 ORACLE ERROR ORA-1555, SNAPSHOT TOO OLD........................................................................... 136 NET8 TCP/IP DELAY........................................................................................................................... 136 ORACLE ERROR ORA-1578, DATA BLOCK CORRUPTION ............................................................... 137 ORACLE ERROR ORA-600, INTERNAL DATABASE ERROR .............................................................. 137 POOR PERFORMANCE OF THE COST-BASED OPTIMIZER ................................................................. 137 INTRODUCTION TO WORKLOAD ANALYSIS......................................................................... 138 PERFORMANCE PROBLEMS................................................................................................................. 138 RESPONSE TIMES ................................................................................................................................. 138 WAIT TIME ........................................................................................................................................... 138 ROLL IN TIME ....................................................................................................................................... 139 DATABASE TIME ................................................................................................................................... 139 PROCESSING TIME ............................................................................................................................... 139 CPU TIME ............................................................................................................................................. 139 WORKLOAD STATISTICS ..................................................................................................................... 139 WORKLOAD ANALYSIS ........................................................................................................................ 139 ANALYSIS ROADMAP USING WORKLOAD MONITOR (ST03) ............................................................. 140 PERFORMANCE ANALYSIS MONITORS .................................................................................. 141 WORK PROCESS OVERVIEW ............................................................................................................... 141 ST06 - OPERATING SYSTEM MONITOR.............................................................................................. 141 ST02 - BUFFER MONITOR ................................................................................................................... 141 R/3 MEMORY MANAGEMENT ..................................................................................................... 142 R/3 MEMORY AREAS ........................................................................................................................... 142 LOCAL MEMORY ................................................................................................................................. 142 SHARED MEMORY ............................................................................................................................... 142 ALLOCATION CONCEPTS .................................................................................................................... 143 HEAP MEMORY MANAGEMENT ......................................................................................................... 143 R/3 EXTENDED MEMORY .................................................................................................................... 144 ANALYSIS ROADMAP: R/3 MEMORY CONFIGURATION (ST02) ....................................................... 144 HARDWARE CAPACITY VERIFICATION ................................................................................. 145 HARDWARE BOTTLENECKS ................................................................................................................ 145 ANALYSIS ROADMAP: HARDWARE CONSUPTION (ST06) ................................................................. 145 OPTIMIZING THE CONFIGURATION ................................................................................................... 145 EXPENSIVE SQL STATEMENTS .................................................................................................. 146 DETECTING EXPENSIVE SQL STATEMENTS ...................................................................................... 146 MONITORS TO ANALYSE ..................................................................................................................... 146
jluiz@cemig.com.br
Pgina 9
ACADEMIA
BASIS
DETAIL ANALYSIS AND TUNING ......................................................................................................... 147 TABLE STATISTICS FOR OPTIMIZER .................................................................................................. 147 TIPS FOR OPTIMIZING ABAP ............................................................................................................. 147 TABLE BUFFERING ........................................................................................................................ 148 CONCEPTS ............................................................................................................................................ 148 SYNCHRONIZATION ............................................................................................................................. 148 GRANULARITY OF INVALIDATION ...................................................................................................... 149 BYPASSING THE BUFFER ..................................................................................................................... 149 STRATEGY FOR TECHNICAL CRITERIA ............................................................................................. 149 OPTIMIZATION ..................................................................................................................................... 150 OTHERS ASPECTS ABOUT ORACLE ......................................................................................... 151 CACHE ANALYSIS ................................................................................................................................ 151 SHARED SQL AREA ............................................................................................................................. 151 ANALYZING SQL STATEMENTS ......................................................................................................... 151 UPDATE STATISTICS ............................................................................................................................ 152 IDENTIFY CODING ............................................................................................................................... 152 WORKFLOW AND REPORTING ............................................................................................................ 152 INDEX UTILIZATION ............................................................................................................................ 153 CREATING NA INDEX ........................................................................................................................... 153 SIMILAR STATEMENTS ........................................................................................................................ 153 VIEW PROCESSING .............................................................................................................................. 154 POOLED AND CLUSTERED TABLES ..................................................................................................... 154 WORKLOAD ANALYSIS GUIDE .................................................................................................. 155
DIRECTORY SUMMARY................................................................................................................ 156
TO BE KNOWN ................................................................................................................................. 156
ANEXOS .............................................................................................................................................. 158 GLOSSRIO........................................................................................................................................... 158 TRANSACTIONS .................................................................................................................................... 160 REPORTS ............................................................................................................................................... 165 OSS NOTES ........................................................................................................................................... 166 RZ10 PARAMETERS ............................................................................................................................. 167
jluiz@cemig.com.br
Pgina 10
ACADEMIA
BASIS
Introduo
Plano de Estudo
A estratgia para o estudo durante a academia ser de sete horas durante o perodo de aulas na SAP e de cerca de quatro horas dirias no hotel para rever a aula do dia. Idealmente a reviso da sexta-feira deve ser feita no sbado e uma re-leitura de todo o texto da semana no domingo. Este texto engloba e leva em conta o texto elaborado pelo meu grande amigo e colega de empresa() Mrcio Cicarelli (cicareli@cemig.com.br), durante a academia de Unix/Oracle de 1999. Na prtica eu (jluiz@cemig.com.br) vou elaborando o meu prprio resumo e anexando as partes elaboradas pelo Mrcio que acho relevantes. A ordem dos dois resumos um pouco diferente e em alguns captulos os textos no tem nada a ver um com o outro, mas na maioria os textos so bem parecidos ou com pequenas alteraes provocadas por um maior detalhamento ou comentrios. S para ter uma idia at o momento este resumo tem 75 mil palavras e o do Mrcio tinha cerca de 52 mil. A minha previso que at o final ele tenha cerca de 80 mil palavras. Apesar deste alto volume de palavras, o que interessa o contedo final (para eventualmente passarmos na prova). Por enquanto, alm da reviso do texto, ainda no foi incluido os desenhos e figuras que acho interessantes (para facilitar a compreeno dos conceitos). Elas sero disponibilizadas aps o aval da SAP (elas so muito parecidas e funcionalmente identicas as que esto nas apostilas).
Advertncia
Todos os exemplos e conceitos apresentados nesse texto so meramente ilustrativos. Eles so destinados apenas aos profissionais qualificados para as tarefas propostas, sendo extremamente recomendados a anlise dos mesmos antes da sua execuo. No existe qualquer garantia, quer implcita ou explcita, do perfeito funcionamento ou da aplicao dos conceitos aqui descritos. No garantimos com relao ao uso, ou ao resultado do uso, das instrues aqui apresentadas, em termos de correo, acurcia, confiabilidade, atualidade, ficando todos os riscos, tais como resultados, por sua conta e total responsabilidade. Se os exemplos provocarem erros, perda de dados ou quaisquer danos diretos, indiretos, decorrentes ou acidentais (incluindo danos por perda de receita, interrupo dos negcios, perda de informaes e similares), voc e no o autor assume o custo integral de todos os servios, reparos e correes necessrios. A garantia acima descrita a nica de qualquer tipo, tanto explcita como implcita. Nenhuma informao verbal ou escrita, ou anncio fornecido, pode contituir uma garantia ou de qualquer forma aumenta o escopo dessa garantia. Ao usar os exemplos e conceitos apresentados nesse texto, voc assume ter lido essa garantia limitada, compreendido-a, e concorda em se submeter a seus termos e condies. Voc tambm concorda que a garantia limitada o documento completo e exclusivo de acordo entre as partes e se sobrepe a todos os acordos e propostas anteriores, verbais ou escritos, e qualquer outra cominicao entre as partes com relao ao assunto termo de garantia limitada. Alm disso, o texto esta na sua forma inicial e no recebeu nenhum tipo de reviso ortogrfica ou gramatical, portanto voc certamente encontrar algumas frases com sentido duvidoso ou at mesmo erros grosseiros de portugus. Isso ocorreu porque o texto foi sendo elaborado durante a academia. Conto com a sua colaborao para corrigir o texto e agregar maiores detalhes ou informaes relevantes. Desde j, muito obrigado pelas dicas que voc certamente enviar para o meu e-mail.
Direito de autoria
Lembre-se sempre, copiar no crime, ignorar o autor ou assumir todo o crdito .
jluiz@cemig.com.br
Pgina 11
ACADEMIA
BASIS
Marcas registradas.
DEC, DECNet, VAX e VMS so marcas registradas da Digital Equipment Corporation. HP e HP-UX so marcas registradas da Hewlett-Packard. Microsoft, WINDOWS, NT, EXCEL e SQL-Server so marcas registradas da Microsoft Corporation. IBM, MVS, OS/2, DB2/6000, AIX, OS/400 e AS/400 so marcas registradas da IBM Corporation. OSF/Motif uma marca registrada da Open Software Foundation. ORACLE, Server manager, SQLPlus, Net8, SQL*Net so marcas registrada da ORACLE Corporation, Califrnia, EUA. INFORMIX-OnLine para SAP uma marca registrada da Informix Software Incorporated. UNIX e X/Open so marcas registradas da SCO Santa Cruz Operation. ADABAS uma marca registrada da Software AG. SAP, R/2, R/3, RIVA, ABAP/4, SAPoffice, SAPmail, SAPaccess, SAP-EDI, SAP ArchiveLink, SAP EarlyWatch, SAP Business Workflow e R/3 Retail so marcas registradas da SAP AG.
Participantes da Academia
Participante Instrutores : Erika Quirs Luiz Mestrinel Rinaldo Morais Empresa Alguns e
SAP SAP SAP
erika.quiros@sap.com luiz.mestrinel@sap.com rinaldo.morais@sap.com e rinaldomorais@yahoo.com
Acadmicos : Ana Maria Aroldo Higashi Cludio Milos Joao Luiz Barbosa Marcelo Silva Priscila Silva Renan Guedes Ricardo Magalhes
Solangol Skyline SAP CEMIG CEMIG SAP SPEC SAP
asousa@sondist.ebonet.net ahigashi@dmc-2.com.br e aroudo.higashi@zipmail.com claudio.milos@sap.com e milos27@hotmail.com jluiz@cemig.com.br e jluiz_barbosa@yahoo.com.br mvsilva@cemig.com.br priscila.silva@sap.com renan.guedes@spec.com.br ricardo.magalhaes@sap.com
Demais colaboradores : Mrcio Cicarelli CEMIG
cicareli@cemig.com.br
jluiz@cemig.com.br
Pgina 12
ACADEMIA
BASIS
Primeira Semana R/3 Basis Technology

Basis System and the System Environment The Integration Model
Sistema R/3 composto dos seguintes mdulos: Logstica SD Sales & Distribution MM Materials Management PP Production Planing QM Quality Management PM Plant Maintenance Human Resources HR Human Resources Accounting FI Financial Accounting CO Controlling TR Treasury PS Project System Industry and Cross-Application WF Workflow IS Industry Solutions (no vem no standard) A camada Basis integra todos estes mdulos. a parte central do diamante do diagrama do R/3 e as demais so os mdulos funcionais. Estes mdulos se interconectam e interagem para garantir que o sistema todo integrado, tanto na parte de processos quanto em relao a base de dados que reside em um nico local.
Business Framework Architecture

O Business Framework Architecture (BFA) a arquitetura estratgica do produto R/3. Ela trabalha com business components que so os mdulos funcionais (FI, CO, etc.) configurveis para se adaptar a cada empresa. A BFA, apesar da estrutura baseada em componentes, garante que as informaes so tratadas e mantidas a nvel do processo de negcio. Esta arquitetura fornece agilidade para se adaptar a um novo negcio, alm da facilidade de se integrar com pacotes externos e fcil integrao com a internet e intranet, permitindo desta forma uma fcil evoluo sem a interrupo da operao do negcio da empresa. O princpio da arquitetura que cada componente possui vida prpria e sua complexidade est restrita a ele mesmo. Para o mundo externo somente os mtodos de interfaceamento so visveis e acessveis, fato que garante a total conexo deste com os demais sem causar grandes impactos ou interferncias O Business Framework se mostra no R/3 como uma famlia de componentes separados porm integrados entre si. Estes componentes so: Business Components: so os mdulos funcionais (FI, CO, etc.) so formalmente conhecidos como componentes relativos ao negcio; Business Objects: Ordem, Empregado, Material, etc. So o prximo nvel de hierarquia do R/3. Pertencem a um Business component e podem ser considerados como objetos bsicos do sistema; BAPI Interfaces: So os mtodos com que os objetos de negcio foram implementados dentro do R/3 (criar uma ordem, alterar o endereo de um empregado, etc.) e eventualmente podem ter mais de uma verso para o mesmo interfaceamento. A forma bsica de distribuir as informaes o ALE e este ser detalhado mais a frente.
jluiz@cemig.com.br
Pgina 13
ACADEMIA
BASIS
R/3 as an Open System

O R/3 utiliza protocolos standard da industria para garantir a integrao com outras aplicaes: TCP/IP: o protocolo de comunicao difundido mundialmente; EDI: Electronic Data Interchange, o mecanismo utilizado para trocar informaes de negcio com diferentes sistemas; muito utilizado pelos bancos; OLE: Object Linking and Embendding, integra aplicaes PC com o R/3 (padro microsoft); Open Interfaces, tais como arquivamento tico, dispositivos de cdigos de barras, etc. Alm de standard da indstria, o R/3 tambm utiliza protocolos proprietrios para comunicao: RFC: Remote Function Call, que utiliza o protocolo copiado do CPI-C da IBM para comunicao e processamento das aplicaes e tasks dentro do sistema R/3 ou com o sistema R/2 ou outros sistemas; ALE: Application Link Enabling permite o processamento distribudo dentro do R/3. Na prtica est associado a distribuio de informaes a partir de um modelo de divulgao preestabelecido;
Scalability and the Client/Server Concept

O R/3 possui uma arquitetura modular de software seguindo o princpio da arquitetura cliente/servidor com enfoque na distribuio da fora de processamento entre as vrias plataformas envolvidas (apresentao, aplicao e banco de dados) Esta arquitetura permite que se separe a lgica da aplicao da base de dados e da camada de apresentao. Esta configurao permite ainda otimizar os custos e distribuir a carga atravs de configuraes variadas de hardware. Com isto possvel dimensionar os servidores de acordo com a carga, permitindo a fcil escalabilidade do ambiente. Os ganhos nesta arquitetura na implementao R/3 so muitos: Simples instalao de novos servidores para eliminar eventuais gargalos de processamento; Servidores trabalham em paralelo, com carga homognea e execuo local dos programas; Baixo trfego de rede com a localizao dos buffers de dados e programas prximo de onde sero utilizados; Balanceamento de carga, seja para o processamento online (logon) seja para o processamento batch. Ou seja, o ponto alto da arquitetura a facilidade para escalar e aumentar o poder de processamento
Client/Serve Principles
Na implementao R/3, a arquitetura client/server orientada para o software, e no para o hardware como estamos acostumados a ver. Desta forma, Client quem requisita e utiliza o servio e Server quem vai fornecer determinado servio. Um servidor de aplicao por exemplo server de alguns servios das estaes clients, porm client dos servios fornecidos pelo servidor de banco de dados. Ou seja, o conceito do papel de quem o cliente e de quem o servidor o que prevalece no importando quem tem mais hardware ou quem normalmente executa a atividade.
R/3 System Client/Server Configurations

Os servios (ou camadas) fundamentais de uma aplicao so trs: Presentation, Application e Database services e existem vrias formas de se implementar um sistema R/3, a saber :
jluiz@cemig.com.br
Pgina 14
ACADEMIA

BASIS
Central, onde todos os componentes esto implementados em um mesmo host. Esta implementao corresponde a clssica implementao mainframe e no comum de ser implementada; Two-tier, onde uma camada normalmente executa as funes de presentation (usualmente um PC) e a outra camada executa os servios de application e database. Uma outra implementao two-tier poderia ser uma camada executando os servios de database e a outra composta por PCs mais potentes que executariam as funes de presentation e application. A primeira implementao comum em ambientes pequenos e com pouca disponibilidade de hardware para os servidores. A ltima implementao normalmente utilizada em simulaes ou desenvolvimento de software. Three-tier, onde cada servio tem o seu prprio host. Nesta configurao possvel ainda assegurar uma diviso de carga na camada de aplicao, garantindo que determinados hosts fiquem dedicados para aplicaes especficas. Por exemplo dedicar um host para servidor de aplicao dos usurios de MM, ganhando com isto performance na distribuio dos servios.
A configurao three-tier a mais recomendada em R/3 por garantir a melhor distribuio de carga e escalabilidade nos grandes sistemas. Todos os servidores de aplicao e banco de dados em uma configurao R/3 devem possuir endereo de IP fixo e estarem ligados entre si atravs de uma rede de alta velocidade. Um sistema R/3 agrupa todos os componentes que esto associados com um banco de dados. Se utilizamos uma implementao em 3 camadas, os componentes do R/3 estaro presentes em todas as camadas da hierarquia: Database Server, instalado em um host central, onde todos os servios de bancos de dados sero executados. Um ou mais Application Servers conectados ao servidos de banco de dados. Nestes servidores estaro sendo processados a lgica da aplicao, ou seja, os programas. Vrios Presentation Servers conectados aos servidores de aplicao. Estas mquinas so tambm chamadas de frontends ou workstations. Nestas mquinas os usurios iro interagir com o sistema R/3 utilizando uma interface que prover os servios de presentation.
The Middleware Basis

O software Basis do R/3 (tambm chamado de middleware) roda em diferentes plataformas e tambm pode ser adaptado para atender as necessidades individuais das empresas. Na prtica ele isola a complexidade do sistema operacional e do banco de dados permitindo ao administrador realizar suas atividades sempre de dentro do R/3. So vrios os servios que ele presta: Prov o ambiente de runtime para as aplicaes R/3 Cuida da perfeita interao das aplicaes com o sistema Define uma arquitetura estvel para as melhorias do sistema Contm todas as ferramentas necessrias para a administrao do ambiente, incluindo a administrao da memria e paginao, agendamento de processos, controle das tarefas em andamento, etc. Permite a distribuio eqitativa dos recursos e componentes do sistema Prov as interfaces necessrias para os sistemas descentralizados e os produtos externos ao R/3 com o devido controle para gerenciar as trocas de informaes As principais caractersticas da tecnologia Basis so: uma arquitetura voltada para a configurao client/server Trabalha com bancos de dados relacionais Possui interface grfica com o usurio (GUI) Basis o responsvel ainda pela integrao dos aplicativos e do ABAP workbench com o software bsico.
Portability and System Plataforms for the R/3 System

Para garantir uma alta portabilidade, as interfaces com o software bsico so divididas em suas prprias camadas que variam de sistema para sistema (NT ou UNIX, Oracle ou Informix, etc.). Acima jluiz@cemig.com.br Pgina 15
ACADEMIA
BASIS
destas camadas as funcionalidades dos componentes R/3 so basicamente as mesmas, independentemente do hardware, software ou sistema operacional. A System Interface responsvel pelo interfaceamento do R/3 com as diversas plataformas em que ele pode ser implementado. A Flow Control fica logo acima das interfaces com o software bsico (System Interfaces). Ele o responsvel por tarefas tipo scheduling ou gerenciamento de memria, tarefas estas muito prximas ainda do sistema operacional e que so parcialmente efetuadas por ele, mas so gerenciadas pelo R/3 por razes de portabilidade e performance. A User Interface prov as opes de apresentao dos aplicativos. A Communication Interface o canal para a troca de informaes, seja pela transferncia de dados com o legado, seja pela comunicao program-toprogram provida pelo protocolo CPI-C ou ainda atravs da troca de informaes pelo protocolo EDI. Todos os programas no R/3 so escritos na linguagem ABAP, proprietria do sistema. O DYNPRO o screen interpreter e o sistema possui ainda um ABAP interpreter. A interao entre estes dois componentes forma a tecnologia Basis das aplicaes R/3. O funcionamento destes dois interpretadores (tela e programa) se baseia em informaes armazenadas no dicionrio do sistema, o ABAP Dictionary.
System Plataforms for the R/3 systems

O R/3 roda nos mais diversos hardwares, sejam plataformas Intel, Risc ou Unix Systems. Os sistemas operacionais so tambm os mais diversos, de acordo com as plataformas utilizadas (AIX, Solaris, HP-UX, Windows NT, OS/400,etc.). Os bancos de dados utilizados pelo R/3, todos relacionais so: Oracle, Informix, MS SQL Server ou ainda o DB2 para as diversas plataformas. O SAPGUI que faz a camada de apresentao possui verses para Windows (3.1, 95, NT), OS/2 e Java. As linguagens utilizadas no R/3 so ABAP (aplicaes com entendemos no R/3), C e C++ (para construo do kernel) e HTML e Java (para a parte de intranet e internet).
jluiz@cemig.com.br
Pgina 16
ACADEMIA
BASIS
Navigation
Logging onto R/3 System
O R/3 um sistema voltado para clients. Com este conceito possvel controlar vrias empresas em nico sistema, separando-as por client (ou mandante). As chaves para se logar no sistema tambm so separadas por client. Para efetuar um logon preciso ter chave no client especfico. Alm disso o sistema exige uma password e por ser multilngue, deve-se ainda especificar a lngua desejada no momento do logon. Um client pode ser visto como uma entidade organizacional separada dentro do R/3, com seus prprios dados : master data, transaction data, user master records e parmetros especficos de customizao. Apesar dos dados serem armazanados em tabelas nicas, os dados dos diferentes clients coexistem separados pela diferenciao do campo MANDT que faz parte da chave da maioria das tabelas (client dependents). A exceo mais famosa a tabela T000 (definio dos clients no sistema) que independent apesar de ter como primeiro o campo MANDT. Outra exceo so os objetos independentes de mandante (telas, programas, dicionrio de dados, programas compilados) que so mantidos em tabelas que servem a todos os mandantes de uma determinada instncia. O conceito de customizao a adaptao do sistema R/3 para as necessidades especficas de um usurio. Ao instalar um sistema R/3, ele vem basicamente com 3 clients default: 000 definido como um SAP standard no dever ser alterado pelos clientes, devendo ser utilizado como um template para a criao de novos clients 001 uma cpia do 000 com algumas configuraes j feitas para facilitar o trabalho (vale somente para os Estados Unidos). A partir da verso 4.0 este cliente j pode ser apagado e foi mantido apenas para compatibilidade com as verses anteriores. 066 utilizado pela SAP para se logar no ambiente do usurio para a execuo de determinadas tarefas Um client identificado pelos trs dgitos numricos e, com exceo dos 3 citados acima, cada instalao pode definir quantos clients se desejar (ou a sua base de dados suportar).
R/3 Menu Structure

Uma vez logado no sistema R/3 o sistema exibe um menu principal, onde temos as principais reas do R/3 (Logistic, Accounting, Human Resources) entre outras entradas. Ao se escolher uma determinada entrada o sistema exibe um menu pull-down com opes de cascading em algumas entradas. As opes System e Help so comuns a todas as telas do sistema. Um nvel abaixo fica o menu especfico de cada aplicao, que exibe as funes bsicas disponveis para aquele sistema (criar um registro, por exemplo). Dynamic Menu disponvel na tela inicial d a opo de navegar em todas as opes disponveis no formato de rvore do explorer, podendo selecionar a funo desejada. uma ferramenta que permite efetuar searchs por palavras chave. Uma tela tpica do sistema R/3 possui as seguintes partes:
Title Bar, exibe o ttulo da task que est sendo executada Command Field, onde se pode escolher uma task diretamente sem a necessidade de navegar no menu Options, (tres bolas coloridas no canto superior direito), onde se pode configurar a interface SAPGUI de acordo com necessidades individuais dos usurios Standard Toolbar, onde se encontram os cones mais freqentemente usados para navegao no sistema, bem como cones para salvar dados e ativar o online help Checkboxes, Radio buttons, Text boxes e outras interfaces comuns no ambiente windows para a exibio de dados Status bar, exibe informaes referentes ao status atual do sistema (session number, system name, application server, worksations time, alm de mensagens de interao com o usurio. Text box inicializados com interrogao (?) so de preenchimento obrigatrio
jluiz@cemig.com.br
Pgina 17
ACADEMIA
BASIS
Uma tela no R/3 pode ser acessada de 3 maneiras distintas: Selecionando a opo no menu Atravs de teclas de atalho (ALT + tecla) Atravs do cdigo da transao diretamente digitado no command field O command field aceita vrios comandos que funcionam em conjunto com o cdigo da transao /n para encerrar a transao atual /o para abrir uma nova sesso /i para encerrar a sesso corrente /nend e /nex para efetuar logoff no sistema com e sem prompt, respectivamente Veja as notas 26171 (Possible entry values for command fields) e 182592 (Delete/change transactions codes in command fields) para saber mais a respeito do command field. A tecla F1 ativa o help de campos, menus, funes e mensagens. Help tambm exibe informaes tcnicas referentes aos campos de uma tela, como por exemplo o parameter ID do campo que pode ser utilizado para customizar a tela com parmetros default do usurio. (F1 + F9 tambm exibe as technical infos). A tecla F4 exibe os valores possveis em um campo, onde esta informao est disponvel (combo boxes). A opo System do menu utilizada para exibir as tarefas comuns aos usurios do R/3. A opo User profile Own Data do menu System permite ao usurio especificar valores defaults para seus campos, baseado no ID do campo (ver technical info). Na opo System possvel ainda configurar a lista de favoritos de cada usurio (User Profile Favorite maint) Session Manager uma ferramenta que permite ao usurio gerenciar todo o ambiente e at mesmo vrios sistemas de uma nica interface. No release 4.0 esta ferramenta ainda no se encontra em um estgio muito til, mas cresceu muito no release 4.6. De qualquer forma esta ferramenta no parece ser muito adequada ao ambiente windows pois ela simula a funcionalidade da barra de tarefa e a cada nova janela ela tenta fazer um novo login, ou seja, ela um pouco lenta. Ele tambm pode ser acessado a partir do R/3. Ele o boto dynamic menu e monta toda a arvore de menus do R/3. muito til para descobrir a transaction e o caminho de menu associado a ela. Alm do SapLogon e do Session Manager temos ainda o SapIcon que permite o acesso configurado direto a um mandante especfico.
jluiz@cemig.com.br
Pgina 18
ACADEMIA
BASIS
System Kernel
R/3 Presentation Interface
A interface de apresentao do R/3 o SAPGUI que apresenta uma funcionalidade muito parecida entre as diversas plataformas do R/3. Um usurio treinado em uma determinada plataforma, salvo pequenas excees est apto a operar o sistema nas suas mais diversas implementaes. O fluxo de informao entre o SAPGUI e o servidor de aplicao no consiste de telas preformatadas, mas sim de strings lgicos contendo dados e caracteres de controle, o que faz com que o trfego de dados se mantenha na casa de 1 a 2K por tela (cada enter). Estes strings so na verdade um protocolo de comunicao que sempre utilizado para conversar com o dispatcher e chamado de DIAG (dynamic information and action gateway) e a rede adequada a receber essa carga a prpria wan do ambiente. Do lado do servidor de aplicao temos o dispatcher que quem cuida da troca de dados, entre o application e o sapgui, e a ordem de processamento est na dispatche queue ou request queue. A regra sempre obedecer a FIFO (first in, first out) das conexes estabelecidas.
R/3 Database Interface

O R/3 trabalha com bases de dados relacionais, que so compostas de tabelas bidimensionais e interagem com os sistemas atravs da linguagem padronizada SQL (Structured Query Language) que comum a todas as implementaes de bases relacionais, embora cada fabricante implemente algumas extenses no seu produto. O DB Interface um mdulo dentro do R/3 que converte os comandos SQL codificados nos programas ABAP para o SQL nativo do banco implementado em cada ambiente R/3. Ou seja, cada implementao (Oracle, Informix, SQL Server) possui um mdulo de DB Interface particular para aquela implementao, o que torna os programas ABAP independentes da implementao do banco. Estes comandos SQL escritos no ABAP so denominados OPEN SQL e o DB Interface responsvel pela sua correta transcrio para o SQL nativo do banco. Alm disso, um programa ABAP pode codificar o comando diretamente em Native SQL. Neste caso o comando no passar pelo DB Interface, indo diretamente para a DB machine. Estes comandos podero no ser independentes do banco utilizado, se utilizarem extenses particulares de um determinado RDBMS. Os comandos SQL escritos em OPEN SQL tem sua sintaxe verificada pelo DB Interface que inicialmente faz um acesso no buffer interno do application server para evitar acessos desnecessrios ao DB server. Comandos escritos em native SQL no fazem uso deste buffer interno, uma vez que o acesso no passa pelo DB Interface. Normalmente as tabelas que vemos no R/3 so armazenadas no DB. Estas tabelas so conhecidas com tabelas transparentes. Elas so implementadas no DB exatamente como vemos no dicionrio do R/3. Existem outros tipos de tabelas que so declaradas no dicionrios mas no so implementadas exatamente como aparecem. As tabelas do tipo Pool so declaradas no banco como uma s mas para o R/3, aparentemente, so tabelas como outras quaisquer. Este recurso utilizado para tabelas de poucas ocorrncias e para evitar um grande nmero de tabelas. Existem tambm as tabelas tipo Cluster. Essas so uma desnormalizao do dado dentro do modelo relacional. Mais precisamente como se tivssemos o conceito de campos mltiplos dentro de um registro (que infringe a primeira regra normal). O DB Interface no o processo que acessa e mantm a conexo com o banco. Este processo conhecido como shadow process e roda na mquina onde est o banco de dados fazendo a ligao do db interface, que est na maquina onde est a instance, e o banco de dados.
jluiz@cemig.com.br
Pgina 19
ACADEMIA
BASIS
Work Processes and Dispatcher

O R/3 tem sua carga de processamento disponvel nos application servers. Esses servidores que so responsveis por realizar o processamento descrito nas aplicaes realizando as devidas interaes com o banco de dados e com o front-end do usurio. Em uma instncia R/3 temos pelo menos um application server que chamaremos de central instance. Se houverem outros chamaremos os demais de dialog instance. Essa diferena existe pois algumas atividades so comuns a toda a instncia R/3 e so realizadas na central instance, j outras atividades relacionadas a processar as requisies dos usurios podem ser distribudas por vrios servidores, os j conhecidos como dialog instance. Os principais componentes de um application server (central ou dialog) so: Um dispatcher como o controle central da instance Dispatcher queues para enfileirar as requisies (FIFO) Um nmero configurvel de work processes para processar os programas ABAP Buffers e shared memory. Os work processes so servios dentro de um sistema R/3 especializados em determinadas tarefas. O centro de um sistema R/3, a nvel de controle de aplicao, o Dispatcher. Ele, juntamente com o sistema operacional, o responsvel pelo controle e disponibilizao dos recursos do sistema. Suas principais tarefas so o controle da comunicao, a conexo com o presentation e a distribuio de carga entre os work processes. O dispatcher distribui os servios requisitados entre os WP disponveis e se encarrega de enviar o dado processado para o SAPGUI, que dever interpret-lo e exibir para o usurio. No existe um WP fixo para um determinado usurio, cuidando o dispatcher de ir utilizando-os conforme as requisies vo chegando, em um processo de fila FIFO. Quando um sistema R/3 inicializado, o dispatcher o responsvel por lr os parmetros de configurao (profiles), gerar as rol areas, inicializar os work processes e se conectar com o message server da central instance. Cada work process desempenha uma atividade especfica, a saber : Dialog responsvel pelo processamento solicitado pelo usurio Update responsvel por processar as alteraes no banco de dados Enqueue responsvel pelo enfileiramento e proteo das atualizaes Background responsvel pelo processamento a ser feito sem a interao do usurio Spool responsvel por processar as requisies de impresso Cada dialog work process coordenado por um componente interno denominado Task Handler. Ele ativa o screen processor ou o ABAP processor e ainda o responsvel pelo roll in e roll out das reas de usurio. Existem memrias de uso exclusivo de um determinado work process e memrias que podem ser compartilhadas por todos eles. Esta diferenciao gerenciada pelo memory management. A memria utilizada exclusivamente por um work process possui duas reas reservadas para dados especficos de uma determinada sesso de usurio (user context area) e devem ser mantidas entre as pseudo conversas do dialog. Estas reas so denominadas roll e paging areas. A roll area contm dados que ficam imediatamente disponvel para o processamento no incio do dialog step (roll in) e salva novamente no final do dialog step (roll out). Este mecanismo de roll in e roll out que permite o share dos work process permitindo o compartilhamento do recurso entre todos os usurios. Nesta rea so salvos os dados referentes ao usurio (user context) tais como suas autorizaes, informaes administrativas alm de dados adicionais para o ABAP e dialog processors, que so dados que j foram coletados por dialog steps anteriores. Na shared memory existem dados disponveis para todos os work processes, tais como o calendar, screen, table e program buffers.
jluiz@cemig.com.br
Pgina 20
ACADEMIA
BASIS
R/3 Application Services

Um sistema R/3 composto de uma srie de work processes que funcionam em paralelo cooperativamente. Cada application server possui um dispatcher e um nmero configurvel destes processos, que depende dos recursos disponveis no host (basicamente memria e processamento). Work processes podem ser instalados para efetuar servios de dialog, update, background e spool. Uma central instance possui ainda servios de enqueue (que tambm um work process) para gerenciamento de lock e dois outros servios prprios: Message Server responsvel pelo servio de comunicao entre os vrios dispatchers que compem um sistema R/3, que portanto um pr requisito para a escalabilidade de vrios servidores de aplicao trabalhando em paralelo. Ele muito usado para a troca de dados de controle. Gateway Server, tambm chamado de CPI-C handler, que permite a comunicao entre R/3, R/2 e aplicativos externos. muito utilizado para trocar dados da camada da aplicao, incluindo ai dados da mesma instncia. Resumindo, uma instncia nomeada pelos servios que ela presta. Um bom exemplo disto a instncia DVEBMGS00 que possui dialog, update, enqueue, batch, message, gateway e spool e todos respondendo pelo system number 00 que significa que a porta 3200 ser utilizada pelo sapdp00 (dispatcher), a 3300 ser utilizada pelo sapgw00 (gateway) e a 3600 ser utilizada pelo sapmsXXX (message).
Rules for the Type and Number of Processes in the Application

Service Dialog Update Enqueue Background Message Gateway Spool R/3, System-wide >= 2 >= 1 1 >= 2 1 >= 1 >= 1 For each R/3 Instance >= 2 >= 0 0 ou 1 >= 0 0 ou 1 1 >= 0
R/3 Transaction and LUW

Transaes so unidades de processamento agrupadas em funes que executam alteraes consistentes na base de dados, de acordo com a funcionalidade a que se propem. Um exemplo tpico seria o dbito em uma conta para crdito em outra, que somente fazem sentido consistente quando executadas como um todo. Uma transao SAP implementada atravs de uma srie de dialog steps consistentes e conectados de forma coerente. Uma transao SAP no executa necessariamente em um nico work process, uma vez que cada um dos seus dialog steps podero estar sendo atendidos por WP diferentes que o dispatcher encontrou disponvel em cada momento. Alm disso, quando se utiliza o asynchronous update para processar as atualizaes da base de dados, estes processos estaro sendo atendidos por outros work process que podero inclusive se encontrar em outros hosts. No R/3 cada dialog step composto de um processamento que inicia aps o usurio entrar o dado (PAI Process After Input) e pelo processamento e envio da prxima tela (PBO Process Before Output). Do ponto de vista do usurio, cada dialog step comea com o preenchimento de uma tela e o posterior processamento at o envio da prxima tela. Para o sistema apenas as partes referentes ao processamento (PAI e PBO) compem o dialog step j que durante o preenchimento da tela nenhum processamento ser requerido. Este conceito de transao, que pode compor de um ou vrios dialog steps, chamado de LUW, ou Logical Unit od Work. Como os bancos de dados no suportam o conceito de transao para todos os processos conversacionais (begin/end transaction commands), necessrio saber diferenciar uma transao do ponto de vista SAP (SAP-LUW) de uma transao de banco de dados jluiz@cemig.com.br Pgina 21
ACADEMIA
BASIS
(DB-LUW) que totalmente executada ou totalmente desfeita. No existe meio termo numa DB-LUW. Enquanto uma SAP-LUW garante a integridade lgica do banco de dados (um determinado lanamento dever existir nas tabelas x, y e z), uma DB-LUW garante a integridade fsica do DB e executado necessariamente pelo gerenciador do banco. Uma transao SAP inicia uma SAP-LUW que somente termina ao encontrar um comando COMMIT WORK no programa ABAP ou ento no final do asynchronous update.
Lock Concept and Asynchronous Update

A tcnica principal utilizada numa SAP-LUW a atualizao assncrona, onde as requisies de update na base de dados so coletadas separadamente e iniciam aps o COMMIT WORK, onde so executadas em uma nica DB-LUW para garantir a integridade do banco. Os mecanismos de lock existentes nos gerenciadores de bancos de dados no so suficientes para garantir a correta manipulao dos objetos de negcio, que muitas vezes envolvem uma srie de tabelas em um nico lanamento. Com o seu prprio mecanismo, O R/3 assegura que determinados dados permaneam protegidos durante todo o processo de atualizao do objeto. Esta tarefa executada pelo Enqueue Work Process que utiliza uma tabela armazenada na memria principal (de onde o enqueue work process est rodando, tambm conhecido como enqueue server e que normalmente a central instance) para este gerenciamento. Sempre que um lock requisitado o sistema verifica (atravs do enqueue wp) se a requisio no fere outro lock j postado na tabela. Havendo coliso de interesses, o processo informado atravs de uma mensagem de erro, o que permite ao programa ABAP informar ao usurio que a sua operao no poder ser executada no momento. Caso o enqueue work process no se encontre na mesma instance em que o processo est correndo, o que normal em uma sistema R/3 de tres camadas, esta comunicao efetuada pelo message server. Para que este mecanismo de requisio de lock funcione no sistema R/3, necessrio que um objeto de lock seja definido no dicionrio ABAP especificamente para aquele objeto que se deseja travar. J existem objetos definidos em uma tabela primria no dicionrio do R/3, porm o usurio pode definir seus prprios objetos em tabelas secundrias (estes objetos do usurio precisam ter seus nomes comeados por EY ou EZ. Os locks podem ser do tipo S (share read) ou E (exclusive write). Um lock do tipo E somente poder ser postado se no existe nenhum outro lock j definido sobre o registro. Quando um objeto de lock ativado, o sistema gera duas funcion modules, uma para ENQUEUE_<object> e outra para DEQUEUE_<object>. Os lock postados por um programa permanecem at que sejam retirados pelo prprio programa ou ainda pelo procedimento de update (segunda parte da SAP-LUW). Work processes podem gerar atualizaes diretamente na base de dados mesmo que o banco no se encontre no mesmo host. Quando o programa ABAP utiliza os comandos CALL FUNCTION ... IN UPDATE TASK, criado no R/3 o mecanismo de asynchronous update. Neste caso a requisio direcionada para uma tabela (a VBLOG) existente fisicamente no banco de dados que age como um buffer intermedirio onde as requisies de atualizao so enfileiradas. Esta tabela contm basicamente o nome da rotina que ser disparada para efetuar a atualizao e os dados (parmetros) para a rotina efetuar as atualizaes necessrias. Transaes que so canceladas pelo usurio no tem o seu registro de header completado na VBLOG e portanto suas atualizaes no so efetuadas. Os registros de atualizao podem ser divididos em componentes V1 e V2. Basicamente processos que so crticos so armazenados em componentes V1 e processos secundrios que so menos time-criticals so armazenados nos componentes V2. Informaes de estatsticas caem nesta segunda categoria. O processo assncrono de update disparado pelo comando COMMIT WORK especificado no ltimo dialog step de uma SAP transaction. Nesta fase que ocorre na segunda parte da SAP-LUW, os registros escritos na VBLOG so recuperados e atualizados fisicamente na base de dados. Caso ocorram erros nesta fase em processos V1, as alteraes no DB daquela DB-LUW so desfeitas por rollback e os registros permanecem na VBLOG assinalados com um flag de erro. Caso ocorram erros
jluiz@cemig.com.br
Pgina 22
ACADEMIA
BASIS
em processos V2, apenas aquele registro ser setado com erro e as demais atualizaes V2 continuam sendo executadas. Quando ocorrem os erros descritos acima, o usurio notificado atravs de mail e medidas corretivas precisam ser avaliadas. Ao trmino da SAP-LUW, a task de update remove os locks postados pelos dialog steps anteriores. Caso ocorram erros durante o update os locks tambm sero removidos. Updates pendentes com erro podem ser restartados pelo administrador do sistema. A SAP no recomenda que updates V1 sejam restartados, devendo este procedimento somente ser efetuado para updates dos tipo V2. Processos V1 devero ser regerados processando novamente a transao (veja a nota 16083) Quando um sistema R/3 sai, as entradas que esto com status INIT na VBLOG so processadas to logo o sistema retorne ao ar. Esta funcionalidade pode ser parametrizada pela profile do sistema. Resumindo uma SAP-LUW, onde cada tpico um dialog step : usurio abre uma transao para atualizar uma determinada informao; Na prtica o SAPGUI do usurio entra em contato com o dispatcher da instncia em questo e aciona o PAI da janela corrente e providencia a exibio da janela desejada; usurio preenche os dados chave para a identificao da informao e o PAI novamente acionado. Neste momento o work process selecionado pelo dispatcher para tratar deste dialog step localiza a informao desejada atravs do DB Interface e solicita ao Enqueue que a respectiva informao seja locada. Isto feito pela funo call function enqueue e pela incluso da lock table que fica na memria da onde esta sendo executado o enqueue. usurio, de posse da janela com os dados a serem atualizados, atualiza a informao e inicia um novo dialog step. Este o dialog step da nossa transao. Ele vai chamar a funo call function in update task que incluir as informaes a serem atualizadas na tabela vblog. Para o dialog work process a atividade encerra quando o commit work realizado. Mas na verdade para o R/3 o assunto ainda no est terminado pois o work process de update, a partir da tabela vblog, vai providenciar que a atualizao seja feita nas tabelas que possuem as informaes reais e desfazer o lock atravs da call function dequeue. Esta parte da transao, que feita pelo update work process conhecida como a segunda parte da SAP-LUW.
Background Processing
Processos que so schedulados para processamento pelos background work processes so tratados no sistema da mesma forma que os processos online. Processos background so schedulados na forma de jobs. Cada job possui um ou mais steps (que podem ser external ou ABAP programs) que so processados seqncialmente. Atravs das classes de processamento (A, B ou C) possvel setar prioridades entre os jobs. Os jobs batch normalmente no so schedulados para processamento imediato, mas so especificados para uma data/hora futura podendo ainda, quando necessrio, serem definidos como peridicos. O batch scheduler o responsvel pelo disparo automtico dos jobs configurados no sistema. Este mdulo um programa ABAP que roda em um dialog work process por instncia do sistema R/3. Ele varre a tabela de scheduling e encontrar um job candidato o encaminha para processamento pelos background work processes. O sistema efetua balanceamento de carga para distribuir os jobs batch entre os diversos servers que possuem work processes disponveis (do tipo B). Jobs batch podem ainda ser schedulados para processamento em servers especficos. Na escala de prioridade, para os jobs com mesmo horrio de inicio, os Jobs classe A tem maior prioridade que os classe B e por ltimo os jobs classe C. Dentro de um mesmo servidor e jobs schedulados com a mesma classe, tem prioridade aquele schedulado com especificao explcita de server (sem balanceamento). A partir da a ordem de inicializao definida pela ordem de criao do job. Se for necessrio saber a ordem em que os jobs sero executados basta abrir a SM37, listar os jobs e classifica-los pela ordem cronologica. Se houver alguns jobs no mesmo horrio devemos entrar em um a um para ver a data de criao e descobrir qual a ordem exata de execuo. Se for necessrio bloquear a execuo de jobs, basta setar o parmetro rdisp/btctime = 0
jluiz@cemig.com.br
Pgina 23
ACADEMIA
BASIS
R/3 Printer Services

Spooling a transferncia bufferizada de dados para dispositivos de sada do tipo printers, fax, etc. O R/3 suporta spooling para dispositivos locais ou em rede. As requisies de spool so geradas tanto pelo processamento online (dialog) quanto pelo processamento batch (background). Os dados a serem impressos ficam armazenados nos TemSe (Temporary Sequential Objects). Quando o sistema necessita de impresso, gerado um output request que encaminhado para um spool work process. Uma vez formatado o dado para impresso, a requisio de impresso encaminhada para o spool do sistema operacional, que fica responsvel pelo encaminhamento do output request para o dispositivo de sada.
R/3 Instance
Uma instncia R/3 uma unidade administrativa que combina componentes de um sistema R/3 para prover um ou mais servios. Todos os servios providos por uma instncia so iniciados (start da instncia) e parados (stop da instncia) ao mesmo tempo. Uma instncia parametrizada atravs de parmetros que descrevem todas as suas caractersticas. Cada instncia possui seus prprios buffers e um sistema R/3 central composto de uma nica instncia que possui todos os servios (DVEBMSGnn). O message server o responsvel pela comunicao entre os application servers e um central message service para prover servios de update trigger, enqueue e dequeue, background requests, e outras pequenas trocas de informaes (normalmente dados de controle e pequenas quantidades de dados da camada de aplicao) Cada dispatcher de um application server se comunica com um nico message server em cada ambiente R/3, que portanto s instalado uma nica vez na central instance. ele quem atribui qual work process vai processar o dialog step que est iniciando. O controle desta fila armazenada na dispatcher queue, tambm conhecida como request queue. Alm dos dispatcher, os presentation (SAPGUI) podero se logar nos application server atravs do message server para desta forma efetuar balancemento automtico de carga (load balancing). O gateway o responsvel pela troca de dados (normalmente com bom volume de dados) entre as instncias de um sistema R/3, entre sistemas R/3 e entre um sistema R/3 e outros sistemas So as profiles que configuram as diversas instncias e desta forma definem quem executa quais servios que estaro disponveis. Por nomeclatura costumamos chamar os dialogs, background, enqueue, update e spool de work process e o gateway e message de servios.
jluiz@cemig.com.br
Pgina 24
ACADEMIA
BASIS
Interfaces
R/3 as an Open System
R/3 um sistema aberto que permite a comunicao com vrias outras plataformas, quer seja entre as instncias de um sistema R/3 ou com outros sistemas R/3, R/2 ou sistemas no SAP atravs de rede. A Comunicao em rede pode ser dividida em 7 camadas, onde cada camada serve de interface entre a camada de baixo e camada de cima. Do ponto de vista da programao, desenvolver uma comunicao entre sistemas mais fcil a medida que esta conversa implementada nas camadas mais superiores. A SAP suporta os protocolos TCP/IP e SNA LU6.2. A comunicao entre sistemas R/3 se d em TCP/IP e a comunicao LU6.2 utilizada para a comunicao com sistemas R/2 baseados em mainframe. A programao R/3 suporta ainda CPI-C, RFC e OLE Automation como interfaces de comunicao. Os dois primeiros protocolos so proprietrios da SAP e o OLE um protocolo da Microsoft para a comunicao entre aplicativos na plataforma windows
R/3 Gateway Service

SAP Gateway o CPI-C handler, responsvel pela conexo entre os protocolos TCP/IP e LU6.2, utilizado para a conexo entre sistemas R/3 e sistemas R/2 baseados em mainframe. O Gateway pode rodar tanto em um application server quanto em um database server. Pequenas mensagens, como visto anteriormente, fluem entre os application e a central instance em um sistema R/3 atravs do message server. J os volumes mais elevados de dados, tais como os dados da aplicao fluem atravs do gateway. Com isto podemos ver que a comunicao atravs do gateway tanto pode se dar dentro de um sistema R/3 quanto entre um sistema R/3 e um sistema R/2 ou com programas externos. O gateway utiliza o protocolo TCP/IP, atravs de RFC, para comunicao com os clients e LU6.2 apenas para a comunicao com mainframes. A transao para visualizar a fila de mensagens no gateway a SMGW.
Communication with CPI-C

CPI-C um protocolo utilizado para a comunicao elementar program-to-program. utilizada basicamente para a comunicao entre sistemas R/2 e outros aplicativos mainframe. a implementao SAP da LU6.2. A comunicao faz uso dos verbos bsicos da comunicao LU6.2 (INIT, ALLOCATE, ACCEPT, SEND, RECEIVE e DEALLOCATE). Como no padro IBM, um protocolo de comunicao que exige que enquanto um parceiro esteja transmitindo o outro se encontre em modo de escuta, e vice versa (sempre funciona na modalidade sincrona). Lembrar que se for o caso de estabelecer uma conexo com ambiente IBM ser necessrio usar funes feitas pela SAP para converter o conjunto de caracter de ascii para ebcdic. Os parmetros enviados pelo comando INIT so definidos atravs da tabela TXCOM e mantidos pela transao SM54.
Remote Function Call

RFC uma interface de comunicao baseada em CPI-C mas que possui mais funes alm de ser mais simples de se utilizar. Pode ser utilizada para a comunicao entre sistemas R/3, R/3 com R/2 bem como aplicaes externas. O RFC permite a chamada de subrotinas remotamente pela rede. Estas subrotinas so chamadas de function modules. Estas funes possuem parmetros e retornam valores como qualquer outra funo e so gerenciadas dentro do R/3 atravs de sua prpria function library, denominada Function Builder.
jluiz@cemig.com.br
Pgina 25
ACADEMIA
BASIS
Function Builder (transao SE37) d ao programador uma excelente ferramenta para programar, documentar e testar as function modules, que tanto podem ser chamadas em modo local quanto remotamente. O Sistema R/3 gera automaticamente todo o protocolo necessrio para a comunicao RFC entre os sistemas. Os requerimentos para o RFC so os mesmos para o CPI-C. Os parmetros para a comunicao RFC so mantidos travs da transao SM59. O R/3 vem ainda acompanhado de uma biblioteca de funes C para comunicao externa via RFC com o R/3, o RFC-SDK (Software Development System), sendo que o que diferencia uma chamada RFC local de uma remota apenas o parmetro (destination) que especifica onde o comando ser executado Existem trs tipos de chamadas RFC : Synchronous RFC call, onde o programa que emitiu a chamada suspende a execuo at o retorno da chamada Asynchronous RFC call, onde a funo chamada roda em paralelo e independente do programa que emitiu o comando. O programador fica responsvel pela conexo lgica dos resultados obtidos Transactional RFC call, onde vrias funes so agrupadas em uma nica transao que executada no sistema remoto como uma nica LUW na seqncia com que elas foram codificadas. Caso ocorra um erro, o sistema que emitiu o comando recebe um cdigo de retorno que pode ser consultado pela transao SM58. Ainda neste caso o sistema destino no precisa estar disponvel no momento em que o comando emitido, podendo ainda ser parametrizado o intervalo entre os queries.
Business Objects and BAPIs

Os business objects formam a base para a comunicao em alto nvel no sistema R/3, tornando possvel por exemplo implementaes R/3 na internet e tem as seguintes caractersticas: Formam a base para uma bem sucedida comunicao em sistemas client/servers So orientados ao negcio. Existem BAPIs chamados Customer, Order, etc. Possui mtodos, que so os business functions que facilitam e padronizam a utilizao destes objetos So gerenciados internamente pelo R/3 em uma biblioteca central, a Business Object Repository, ou BOR As BAPIs (Business Application Programming Interfaces) so interfaces funcionais que utilizam business methods para executar funes de negcio. Elas podem ser chamadas tanto pelos programas R/3 quanto encapsuladas e instnciadas por programas externos.
R/3 System as an OLE Server or an OLE Client

OLE (Object Linking and Embedding) uma forma de comunicao entre programas orientada para objeto. Com isto possvel conectar aplicaes desktop que utilizam OLE2 (Word, Excell, etc.) com o sistema R/3. Quando o sistema R/3 est agindo como um client OLE, o usurio chama o programa (word, excell) de dentro do programa ABAP. Os comandos OLE so transferidos para o PC atravs de chamadas RFC. Os objetos OLE aos quais o R/3 pode se conectar como client so definidos internamente no R/3 (atravs de type informations) onde se definem os mtodos, atributos e parmetros do objeto. A linguagem ABAP possui comandos prprios (CREATE OBJECT, CALL METHOD, GET/SET PROPERTY e FREE OBJECT) que permitem instnciar e manipular o objeto. Quando o R/3 funciona como um OLE server, suas funes podem ser chamadas de dentro das aplicaes que rodam no desktop. Estas chamadas so enviadas ao SAP Automation Server que converte os calls para RFCs que so enviados ao sistema R/3. Estas chamadas ativam BAPIs ou function modules dentro do sistema R/3 que processam as informaes que so ento enviadas de volta para o Automation Server que a repassa para o aplicativo no desktop. Do ponto de vista da programao, usurios podem utilizar as function modules do R/3 em uma programao orientada para objeto, como por exemplo utilizando C++ ou Visual Basic. Isto vlido
jluiz@cemig.com.br
Pgina 26
ACADEMIA
BASIS
para todos os objetos que so gerenciados centralizadamente pelo R/3 atravs da BOR (Business Object Repository). Como os BOR e function modules se encontram no R/3, para utiliza-los necessrio antes efetuar um logon, que pode ser feito de forma automatizada pelo programa.
Internet Architecture
ITS (Internet Transaction Server) forma o componente principal da arquitetura Internet da SAP. Ele composto de dois componentes, o Application Gate (A Gate) e o Web Gate (W Gate). Do ponto de vista do R/3, o A Gate age como um usurio comum, uma vez que o IST converte toda a conversa com o sistema para protocolos utilizados pelo SAPGUI. O A Gate mescla os dados recebidos com templates HTML e os envia atravs do W Gate para o HTTP server, onde so finalmente exibidos para o usurio atravs dos browsers padro (explorer ou netscape). A SAP fornece o IAC (Internet Application Component) que possui Web Transactions que nada mais so que mapeamentos Web de transaes standard R/3. Assim como qualquer pgina HTML, o usurio pode customizar o lay out de acordo com suas necessidades. Para permitir uma boa performance a SAP est rescrevendo algumas transaes para que essas funcionem de forma integrada com a internet.
EDI Architecture
Electronic Data Interchange uma forma estruturada e eletrnica para trocar informaes entre diversos sistemas. Esta arquitetura tem as seguintes caractersticas: EDI-enabled applications, que permite que transaes de negcio sejam processadas automaticamente A interface IDOC, que foi criada como uma interface aberta e consiste de documentos intermedirios e seus respectivos function modules subsystem EDI, que converte os documentos intermedirios em mensagens EDI e vice versa. O SAP no implementa esta facilidade O componente principal desta interface o Idoc, que um SAP standard que especifica a estrutura e o formato do dado que est sendo transferido.
Distribution of Business Processes with ALE

Por razes tcnicas ou de negcio pode ser necessrio fazer uma implementao descentralizada do R/3. O conceito ALE (Application Link Enabling) permite configurar e operar aplicaes distribudas em SAP. ALE consiste de uma troca controlada de mensagens de negcio, mais especificamente os dados do negcio, que permitem a integrao consistente de sistemas distribudos. Os aplicativos so integrados atravs de comunicaes tanto sncronas quanto assncronas e por TRFC (transactional RFC). Para especificar um sistema distribudo necessrio especificar o modelo lgico de distribuio de dados para definir em que sistema rodar e ainda entre quais e como os dados devero ser intercambiados. Os dados tambm so transferidos atravs de Idocs (Intermediate Documents) para possveis aplicaes de EDI.
Data Transfer and Batch Input

Quando se transfere dados entre sistemas R/3 ou entre o legado e o R/3, importante garantir que estes dados entrem de forma consistente dentro do sistema destino. Desde que se utilize as mesmas transaes conversacionais utilizadas pelos usurios para entrar com os dados no sistema, fica assegurado que os dados passaro pelas mesmas consistncias que se efetuam nas entradas online de informao. O mtodo comumente utilizado para entrada de dados do legado conhecido como batch input. A SAP prov uma srie de mtodos implementados atravs de tcnicas de batch input para a jluiz@cemig.com.br Pgina 27
ACADEMIA
BASIS
transferncia de dados do legado. Estes mtodos standard so controlados atravs do Data Transfer Workbench (transao SXDA). Caso no existam SAP standard disponvel, possvel definir e criar seus prprios mtodos. O mtodo consiste na bufferizao das operaes em uma BDC table (Batch Data Communication) que fica organizada em uma fila (batch input session). No passo seguinte esta fila processada e os dados so transferidos para a base de dados. O mtodo funciona como uma screencam mergeado com um pacote de dados onde cada registro submetido ao screencam simulando um usurio processando a transao. Um outro mtodo para entrada de dados o CALL TRANSACTION que fora a chamada de uma transao para processar os dados armazenados na BDC table. Tanto o batch input quanto o mtodo de call transaction chamam os mesmos programas que so processados em dialog mode pelos usurios, o que garante desta forma que as mesmas consistencias sejam efetuadas sobre a massa de dados. Outra forma de atualizao o Direct Input, onde os dados so lidos diretamente do arquivo de entrada, consistidos e transferidos para a base de dados sem passar pelas funes de aplicao normais. Dado a natureza atpica desta operao, ela efetuada apenas por algumas poucas funes R/3 e reservadas apenas para programas desenvolvidos pela prpria SAP. Devemos sempre ter em mente que a principal diferena entre o batch input e o call transaction a existencia de um arquivo intermedirio (conhecido como sesso) que viabiliza o reprecessamento. J no call transaction, quem deve possuir ou permitir este tipo de controle ou recurso o proprio programa abap que esta preparando os dados para serem inseridos no sistema. Uma outra boa forma de fazer a integrao de dados do legado para o R/3 a LSMW ou DLSM que agiliza na gerao das pastas de BDC e na eliminao da necessidade de codificao abap.
jluiz@cemig.com.br
Pgina 28
ACADEMIA
BASIS
R/3 Graphical User Interface

Frontend Administration
Usurios no necessitam da mesma configurao em seus PCs, embora uma padronizao da workstation simplifica o trabalho de administrao. Considere a facilidade e a dificuldade para atualizar os softwares da estao Frontend Requirements: A nota 86895 descreve detalhadamente a configurao da estao Configurao para Windows 95 Item Configurao Mnima Processador 486 RAM 16MB Net connection Winsocket API Configurao para Windows NT Item Configurao Mnima Processador Pentium 90 RAM 32MB Net connection TCP/IP
Configurao desejvel Pentium 133 32MB Winsock.dll
Configurao desejvel Pentium 133 48MB TCP/IP
Para testar o funcionamento da rede entre a estao e o host basta efetuar um ping ou telnet. As configuraes no windows ficam nos arquivos host e services, sendo que nesse ultimo devemos ter as linhas do tipo : SAPDPxx 32<sid#>/tcp dispatcher SAPGWxx 33<sid#>/tcp gateway SAPMS<sid> 36<sid#>/tcp message Para testar o funcionamento do SAPGUI utilize o comando sapgui <appserver> <nn> ou sapgui /H/appserver/S/32nn
SAPGUI Installation
Sempre que for instalar uma nova verso do SAPGUI necessrio deletar a verso anterior. O programa sappurge.exe pode ser utilizado para esta finalidade (ele interno da SAP mas pode ser conseguido). A instalao feita individualmente em cada PC. Programe a melhor forma para otimizar o trabalho. O arquivo SAPSETUP.INI pode ser editado para parametrizar a instalao. Nele se configura quais os componentes a serem instalados e os diretrios target e de work. O sapsetup.exe permite uma instalao dialog free startada a partir da linha de comando (veja o R/3 Installation Guide) o que assegura uma distribuio automtica do software e a manuteno do frontend utilizando logon scripts. A vantagem neste tipo de instalao que a configurao das estaes feita a partir de uma localizao central atravs de um logon script, que faz todas as checagens necessrias (hardware e network) e executa as operaes necessrias para instalar e manter o frontend. A desvantagem deste mtodo que se tem mais trabalho para implementar o check de verso no logon script e para analisar os resultados da instalao no arquivo sapsetup.log. A SAP recomenda que sob windows 95 e NT primeiro se faa uma instalao em um servidor (installation server) utilizando o installation wizard e posteriormente se instale os clients a partir dele. O programa utilizado na instalao o \Gui\Windows\Win32\Sapsetup.exe
Types of Online Help

Existem diversos tipos de implementao do online help no R/3: PlainHtmlHelp converte documentos para HTML standard. Pode ser instalado em todas as plataformas de frontends e exibida atravs dos browsers convencionais. Pode ser utilizado jluiz@cemig.com.br Pgina 29
ACADEMIA
BASIS
tanto com Windows 95, NT ou ainda quando um Web server disponvel na instalao (intranet) PlainHtmlFile converte documentos para HTML standard. Pode ser instalado em todas as plataformas de frontends e os documentos so acessados atravs de um file server que disponibiliza os dados de um diretrio por compartilhamento onde so exibidos atravs dos browsers convencionais nas estaes. Pode ser utilizado tanto com Windows 95, NT ou ainda quando um Web server disponvel na instalao (intranet) HtmlHelpFile converte documentos armazenados no formato HTML comprimido para Html convencional. Pode ser utilizado apenas em estaes Windows 95 ou NT. instalado em um file server compartilhado, como o anterior, mas sua principal vantagem que o espao necessrio no file server cerca de 90% menor, j que os arquivos se encontram compactados. O nico pr requisito que o browser j esteja instalado na estao antes da instalao do SAPGUI, j que o browser que contm todos os HTML controls necessrios.
O tipo de help e sua localizao so especificados como parmetros nas profiles do R/3. A configurao do arquivo SAPDOCCD.INI no frontend sobrepe a definio genrica das profiles do R/3 e deve ser utilizada como complementao a definio do sistema central. Os parmetros importantes e relevantes para a configurao do help so o eu/iwb/help_type, o eu/iwb/installed_language e o eu/iwb/path_win32.
SAPLOGON Options e traces

O programa saplogon.exe se encontra no diretrio drive:\<target>\sapgui, conforme foi definido no momento da instalao. O saplogon utiliza o programa sapgui.exe para se conectar com o application server. O arquivo saplogon.ini configura as entradas disponveis na janela do saplogon e mantido quando se atualiza as entradas disponveis do usurio. As informaes l contidas so utilizadas para montar o string de conexo ao application server. Para evitar que o usurio edite as entradas deste arquivo preciso defini-lo como readonly. Ao se clicar no canto esquerdo da janela do saplogon possvel obter informaes about que descrevem a localizao dos dois arquivos (sapgui.exe e saplogon.ini). O boto do canto superior esquerdo da janela permite ainda que se configure as opes de trace do saplogon e as funcionalidades de edio. Estas definies ficam armazenadas na seo [Configuration] do saplogon.ini Assim como o saplogon.ini, os arquivos sapmsg.ini e saproute.ini so mantidos implicitamente quando edita as entradas do saplogon. O primeiro contm a relao dos message servers e seus respectivos servios (logical service names) que ser lido sempre que se efetua uma requisio de logon a um logon group atravs do saplogon. O segundo arquivo (saproute.msg) lista os saprouters que podem ser selecionados no saplogon. J o arquivo services do windows no editado pelo saplogon embora possua entradas fundamentais para o seu funcionamento, devendo portanto ser editado em separado. Nele so especificadas entradas para os message servers definidos no sapmsg.ini, como por exemplo: sapms<SID> 36nn/tcp. O saplogon utiliza o programa sapgui.exe para se conectar com o sistema R/3 e o string de conexo depende do target escolhido: Para conexo com uma instncia R/3: sapgui /H/<appserver>/S/32nn Para conexo com um message server: sapgui /M/<host name>/S/36nn/G/<logon group> Para conexo saprouter: sapgui /H/<host1>/S/3299/H/<host2>/S/3299/H/<oss host>/S/36nn/G/Public Os nmeros dos servios podero ser substitudos pelas respectivas entradas colocadas no services: sapdp<nn> para o dispatcher e sapms<SID> para o message server. S para constar, as portas do gateway (sapgw00) so as 3300. Se for necessrio, o log de start do sapgui pode ser ativado. Ele recebera o nome dev_9999.TDW (ascii) e dev_9999.log (binrio) e sero gravados na area de work do sapgui. Eles possuem a log de tudo que aconteceu.
jluiz@cemig.com.br
Pgina 30
ACADEMIA
BASIS
Resumindo os arquivos ini. O saplogin.ini possui a configurao das instncias e seus respectivos system numbers. No sapmsg.ini teremos a indicao de quais so os messages de cada um dos sistema R/3. No saproute.ini teremos as strings de roteamento do R/3 e no arquivo services teremos as portas que sero utilizadas pelo dispatcher, gateway, message e etc. Devemos sempre tomar cuidado ao alterar o service pois ele no segue um padro entre maquinas diferentes e principalmente com usos diferentes. Em relao a localizao dos arquivos, os sap*.ini esto no diretrio do windows e o service ou est no diretrio do win9x ou no system32/drivers/etc do winnt.
SAP MAPI and SAPGUI for java

O SAP MAPI permite a integrao dos softwares de correio eletronico e o R/3. Especificamente o MAPI permite que o ambiente de troca de mensagens do R/3, conhecido como Office, passe a ser acessado como se fosse uma pasta do Outlook ou do exchange da microsoft. Uma outra evoluo da SAP a disponibilizaro do sapgui na linguagem java. Isto, pelo menos a princpio, facilitaria a distribuio de softwares para as estaes mas ainda possui o inconveniente do ambiente ser mais complexo. Outra desvantagem a tecnologia estar no inicio do vida e portanto ainda sem contar com uma boa performance e estabilidade de ambiente. O arquivo que corresponderia ao saplogon.ini neste ambiente o IDES.html. Durante a ativao de um sapgui java devemos lembrar que at o aparecimento da janela para o usurio houveram trs momentos : identificao do template (ides.html) que identifica o servidor a ser acessado; carga das classes java que sero processadas no lado do cliente; troca de mensagens entre os servidores para a montagem da pgina atravs do orbixd (object requeste broker daemon). Se for necessrio saber mais sobre o assunto, procure pela nota 42268.
jluiz@cemig.com.br
Pgina 31
ACADEMIA
BASIS
SAP Online Service System (OSS)

OSS Overview
OSS um servio 24 x 7 disponibilizado pela SAP que permite acesso ao banco de dados de Notas, que provm solues para problemas no sistema R/3. Atravs do OSS os clientes abrem chamados ao suporte relatando problemas que so analisados pela equipe da SAP. Atualmente a SAP est migrando estes servios para a internet. Isto faz parte da nova estratgia mysap.com. Aparentemente todo o OSS ser disponibilizado no site http:/service.sap.com que faz parte do market place. Apesar disso ainda podemos acessa-lo atravs do R/3 utilizando a transao OSS1.
OSS Functionality
A tela de pesquisa permite entrar com palavras chave relacionadas ao problema e incluir filtros na pesquisa, tais como release, database, verso de Hot Package, etc. Ao abrir chamados, o OSS j configurado com dados gerais da sua instalao requisita informaes sobre rea do problema, transao, descrio do problema e severidade. O SSCR uma funcionalidade do OSS que permite ao cliente obter key para desenvolvedores e para os objetos SAP que iro sofrer modifications. O SSCR exibe uma lista de todos os objetos e desenvolvedores registrados para o cliente na SAP. O OSS permite listar os Hot Packages e Legal change patches disponveis bem como as datas dos treinamentos oferecidos pela SAP.
OSS Access
O acesso ao OSS efetuado atravs da transao OSS1, que abre uma nova conexo SAPGUI no frontend do usurio. O acesso ao OSS preciso ser configurado atravs de um SAPRouter gateway que abre uma conexo segura entre a instalao do cliente e a rede mundial da SAP atravs dos roteadores que ligam as duas redes. O saprouter tambm controla e filtra quem pode e quem no pode acessar a partir de cada um dos lados envolvidos na conexo.
SAPNet
A SAPNet uma ferramenta que prov informaes e servios via internet. O acesso a SAPNet feito atravs da rea CUSTOMER PARTNER da pgina pblica da SAP (WWW.SAP-AG.DE). Dentro da SAPNet existem reas de Assistncia, Informao, Comunicao e Servios. Cada dia mais esta ferramenta est se aproximando do OSS e hoje em dia j dispomos da maioria dos recursos via browser. Alm disto dispomos de mecanismos para perquisar em todo o site da SAP incluindo ai muitos documentos no disponveis no OSS. Outro bom recursos j disponvel o download de hot packages e legal changes patches alm dos patches de kernel (executveis do R/3). No sapnet encontramos um bom recurso para um sizing inicial. A ferramenta se chama quick sizing e a partir de alguns dados funcionais e indicao da preferencia do ambiente operacional a ferramenta consegue um bom resultado no dimensionamento do ambiente de hardware.
SAP TechNet
A SAP TechNet uma ferramenta focada mais para o lado tcnico, acessada atravs de endereo www.sap.com/technet ou atravs da rea de communication da SAPNet. Os assuntos na SAP TechNet esto divididos por reas de interesse e podem ser navegados para encontrar uma grande diversidade de documentos e pdfs. Para facilitar a organizao a maior parte dos documentos esto na knowledge base e ainda existe uma rea conhecida como forum com um conjunto de perguntas feitas por outros clientes.
jluiz@cemig.com.br
Pgina 32
ACADEMIA
BASIS
Starting and Stoping R/3 NT Version

Operating System Tasks
Durante o startup do NT todos os servios relacionados podero ser inicializados automaticamente (desde que configurados atravs do control panel -> services). Em relao ao R/3 neste momento temos que ter em mente que os servios SAP<SID>_<SystemNumber>, SAPOSCOL e OracleService<SID> devem ser inicializado. A seqncia de inicializao no relevante pois um no depende do outro, mas para o start do R/3 todos j devem estar ativos. O SAP<SID>_<SystemNumber> o responsvel por coordenar o start/stop do message e do gateway. O usurio utilizado para inicializar o servio o SAPService<SID> com a senha informada durante a instalao do R/3. O SAPOSCOL o responsvel por coletar as informaes sobre os recursos do sistema operacional e suas respectivas cargas e disponibilizar estas informaes para o R/3. O usurio utilizado para inicializao tambm o SAPService<SID>. O OracleService<SID> responsvel pelo controle da instncia oracle e no necessita de usurio para ser inicializado.
Administrator Tasks
Para inicializar o R/3 devemos sempre seguir a seguinte seqncia : Os servios bsicos devem estar ativos (saposcol, sapSID_## e OracleServiceSAP) Abrir a conta SIDadm na console do NT Ativar a instncia do Oracle (pode ser feito pelo instance manager da oracle) Ativar a instncia do R/3 (pode ser feito atravs do sap service manager) O Sap Service Manager usa as cores para indicar a fase em que est cada servio, a saber : verde (processo sendo executado), vermelho (processo terminado anormalmente), amarelo (processo sendo inicializado) e branco (servio no est ativo ou com situao desconhecida)
Process Startup Sequence

Seqncia bsica do start do SAP Service Manager : Na camada de servios Verifica se os servios bsicos esto no ar (SAP<SID>_<SystemNumber> e OracleService<SID>) Aciona o SAP<SID>_<##>, que a Start Profile do sistema R/3 do qual o SIDadm o administrador e executa-a. Verifica e se necessrio executa o script strdbs.cmd de inicializao do banco de dados Verifica e se necessrio executa o script msg_server.exe que coloca no ar o message Verifica e se necessrio executa o script disp+work que coloca no ar o dispatcher Na camada de processos Com as informaes da default profile e a instance profile o dispatcher (disp+work) inicializa o R/3 criando os work process necessrios e o servio de gateway As profiles esto no compartilhamento \\<sapGlobalHost>\sapmnt\<SID>\SYS\profile conhecido tambm como \usr\sap\SID\SYS\profile (se ignorarmos o disco onde est a instalao). Para o acesso remoto o compartilhamento a ser utilizado ser o sapmnt, para o acesso local o compartilhamento a ser utilizado o saploc. Se for necessrio iniciar a instncia atravs da linha de comando utilize o comando startsap que tambm possui seu inverso, o stopsap.
jluiz@cemig.com.br
Pgina 33
ACADEMIA
BASIS
Parameter Read Sequence

A seqncia para a leitura dos parmetros a seguinte : NT register Ambiente do NT Declaradas no start profile Default profile Instance profile O valor que ser utilizado ser o que aparecer por ultimo nesta lista. Para certificar qual o valor assumido para um determinado parmetro utilize o relatrio RSPFPAR. Resumindo, o SAP service l as variveis de ambiente, a start profile e a default profile; o R/3 kernel (conhecido com dispatcher) l a default e a instance profile. Se algum parmetro for alterado, para ele passar a valer, tudo que for afetado deve ser reinicializado.
Logs and Traces Logs and Traces for Database Startup

Para saber o que aconteceu durante o startup do banco, alm de erros e eventos do sistema, procure pela log <drive:>\oracle\SID\saptrace\background\<SID>ALRT.LOG. Esta log conhecida com database alert file. Maiores detalhes sobre erros procure por <drive:>\oracle\SID\saptrace \usertrace\ora<####>.trc, que tambm conhecido como oracle trace information. Em relao ao sapdba, as logs ficam nos diretrios sapcheck, sapreorg e sapbackup.
Startup logs and traces in Windows NT

Todas as mensagens geradas pelos servios, SAP server manager ou outra aplicao do NT so logadas no Event Viewer (utilizar o caminho Menu iniciar, programas, aplicao administrative tools (common), event viewer eventvwr) nas logs de sistema, de aplicao e de segurana.
Startup logs and traces in R/3

O diretrio de work contm todos os arquivos de trace e de mensagens de erros da instncia R/3.. Os arquivos so: Arquivos de erros gravados pelo executvel sapntstartb.exe que acionado pelo SAP service manager ou pelo startsap : Stderr1 contm as logs do banco de dados Stderr2 contm as logs do message server Stderr3 contm as logs do dispatcher Sapstart.trc contm o trace do programa sapntstartb. Vale lembrar que o nvel do trace a ser logado pode ser alterado pelo parmetro rdisp/trace e este varia de 0 (no trace) at 3 (todas as mensagens e trace completo) Arquivos de trace : Sapstart.log contm, de forma um pouco menos detalhada, a toda a log da inicializao Dev_ms contm o trace do message server Dev_disp contm o trace do dispatcher Dev_w0 n contm o trace de um work process especifico Uma boa transao para ver as logs a transao RZ03 e menu utility. Outra boa transao para ver mensagens de log a SM21, mas esta mostra as mensagens de log de R/3.
Startup Diagnostics
As principais razes de falha durante o processo de inicializao so : SAP Service Manager no consegue conectar com o SAP service. Normalmente ou ele no est ativo ou no esta configurado corretamente.
jluiz@cemig.com.br
Pgina 34
ACADEMIA

BASIS
SAP service no inicia. Ou as entradas no NT register esto erradas, ou tem algum problema de configurao ou a senha est errada Database no inicia. Verifique as variveis de ambiente, se o db est em dba mode, se algum arquivo foi perdido ou corrompido ou se o listener est desativado R/3 no inicia. Pode ser os compartilhamentos de disco, a configurao do servio (por exemplo, usurio errado ou sem autorizao), problemas de permisso nos arquivos, erro de tcp (host, services, dns, etc) ou erro na conexo com o database.
Reasons for R/3 Downtime

Eventualmente podemos parar o sistema para alterar a configurao e parametrizao, para manuteno de hardware ou sistema operacional ou para fazer algum tipo de upgrade.
Before stopping the R/3 system

Sempre que o sistema tiver que ser paralisado, certifique-se que : Nenhum job est sendo executado ou perto de ser executado. Para isso use a SM37 para verificar o schedule do R/3. Verifique se outros sistemas no podem estar prximos de disparar jobs no R/3, via sapevt ou rfc Nenhuma atualizao est em andamento. Para isso use a SM13; Nenhum usurio est trabalhando no sistema. Para isso use a SM04; No existe atividade para o gateway. Para isso use a SMGW. bastante conveniente enviar mensagem para os usurios do que ser feito. Para isso use a SM02.
Stopping the R/3 system

Para parar uma instncia R/3 podemos faze-lo atravs do CCMS (que na verdade a transao SRZL) ou pelo SAP Service Manager (neste caso ele manda uma mensagem pelo named pipe para a instncia). A grande diferena do NT para o Unix que o stopsap no para o banco de dados, ou seja, a pesar do startsap inicializar o banco de dados o stopsap no o paralisa. Para o banco de dados podemos utilizar o sapdba ou alguma ferramenta do oracle, como Oracle Instance Manager ou o Oracle Server Manager
Database Error Stopping

Eventualmente, durante a paralisao do R/3 e do oracle, o oracle no consegue parar. Isto pode ocorrer por que o banco de dados ainda est trabalhando na realizao do rollback, ou porque um backup online est sendo tirado, ou porque a rea de archive est cheia. Normalmente este ultimo motivo (archive cheia) o grande motivo de travamento do R/3 e a nica soluo para o problema o aumento desta rea.
Backup off-line: database reconnect

Quando do backup off-line o R/3 pode ser configurado para no ser paralisado junto com o banco de dados. Isto feito atravs dos parmetros rsdb/reco_trials e rsdb/reco_sleep_time que configuram a quantidade de tentativas de recuperar a conexo e o tempo de espera por esta conexo. Com isto conseguimos que os buffers sejam preservados e as aplicaes que estavam sendo executadas naquele momento no so abortadas. Na prtica esta poltica est associada a backups com recursos de split mirrow de discos que contm os arquivos de dados do oracle.
jluiz@cemig.com.br
Pgina 35
ACADEMIA
BASIS
Starting and Stoping R/3 Unix Version

Operating System Tasks
O usurio <sid>adm utilizado para administrao do sistema R/3. O start do R/3 efetuado atravs do script startsap_<host>_<instance nbr>, que fica no diretrio home do usurio. Este script tem um alias: startsap. O startsap verifica se o processo saposcol est rodando e o ativa, se necessrio. O scipt pode ainda chamar o script startdb caso o banco se encontre em shut down. Em seguida o script starta a instncia R/3. O script aceita 3 tipos de parmetros: startsap R3, ativa apenas a instncia R/3, desde que o banco esteja rodando startsap DB, ativa apenas o banco de dados startsap all, ativa o banco e a instncia ( o default quando nenhum parmetro especificado Um sistema R/3 possui basicamente 3 profiles que se encontram no diretrio /usr/sap/<SID>/SYS/profile: Start profile: START_<instance>_<host>, que contm a relao dos componentes que sero ativados pelo sapstart na instncia Default profile: DEFAULT.PFL, que contm alguns parmetros globais do sistema Instance profile: <SID>_<instance>_<host>, que contm parmetros especficos da instncia Ao ativar o script startsap_<host>_<nn>, o seguinte processo executado para levantar uma instncia R/3: Ativa o programa sapstart sapstart l a start profile para ativar os servios disponveis na instncia Em uma central instance, o sapstart ativa o message server, o dispatcher, o collector e o sender. Em uma dialog instance apenas o sender e o dispatcher sero ativados. Os processos sender e collector so utilizados para implementar o system log central do R/3 dispatcher forka e cria processos child, tais como work processes e o gateway reader. Os work pocesses so criados de acordo com as informaes da instance e da default profile. O gateway reader independe de parmetros de profile, sendo sempre ativado Os work processes se conectam com a base de dados, que j se encontra rodando Durante o processo de start, o sapstart grava no diretrio de work um arquivo kill.sap que contm o comando kill 2 <sapstart process nbr>, que ser executado pelo script de stop da instncia. Para garantir um start consistente, a seqncia dos parmetros lidos pelos work processes seguem um padro definido, conhecido como parameter replace sequence: So lidos os parmetros hard coded nos fontes C do kernel Parmetros contidos na default profile sobrescrevem valores ja lidos no step anterior Parmetros da instance profile sobrescrevem os anteriores kernel do R/3 (disp+work) l os parmetros contidos nas default e instance profiles. Desta forma, alteraes nelas executadas somente tero validade no prximo start.
Database Startup and Logs

Durante o processo de start, quando requerido, o startsap chama o script startdb que grava uma log apropriada no startdb.log. Eventos significantes (start, stop, errors) so logados pelo no Oracle alert file: /oracle/<SID>/saptrace/background/alert_<SID>_.log. Informaes detalhadas de erro so logadas no Oracle trace file: /oracle/<SID>/usertrace/ora_<pid>.trc. Quando se utiliza o sapdba para start e stop do banco de dados, o sapdba grava uma log no diretrio /oracle/<SID>/sapreorg, .../sapcheck, .../sapbackup, dependendo da ao que foi executada
R/3 Startup and Logs

O script startsap grava uma log de start no diretrio home do usurio <sid>adm. O diretrio de work contm trace files e error files de mensagens relacionadas com o start dos work processes e jluiz@cemig.com.br Pgina 36
ACADEMIA
BASIS
demais servios. O nvel de informaes gravadas nos trace files definido pelo parmetro rdisp/TRACE da instance profile. O default 1 (errors e warnings), aceitando valores 0, 1, 2 e 3. O correto acompanhamento das logs permite identificar o ponto onde ocorreu um erro no processo de start de uma instncia R/3
Stopping R/3 Systems

As razes para se parar uma instncia R/3 vo desde paradas planejadas (mudana na profile, manuteno do sistema R/3 ou DB, upgrades) at quedas no planejadas, por exemplo por falha de hardware. Antes de parar um sistema R/3 convm verificar os seguintes pontos no sistema. Havendo qualquer problema o stop poder ser postergado: Verifique jobs background e batch input (SM37) Estado da fila de update (SM13) Informe os usurios (SM02) Verifique os usurios logados (SM04, AL08) Verifique interfaces externas A parada do sistema dever ocorrer primeiro nos dialog instances e posteriormente na central instance e database. O comando utilizado o stopsap (alias do script stopsap_<host>_<nbr>) que possui basicamente os mesmos parmetros e funcionalidades do startsap (R3, DB, all). A parada apenas do database (stopsap db ou sapdba) faz com que os work processes do R/3 interrompam a conexo com o Oracle. Estes processos tentaro uma reconexo (parametrizada por profile) e em caso de insucesso, entraro em modo de reconnect e somente tentaro nova conexo sob demanda. O processo de retirar apenas o database poder ser uma opo para efetuar o backup offline do banco de dados preservando porm os buffers da instncia R/3 intactos durante o processo. Erros durante a tentativa de parada do database podero ocorrer erros caso o Oracle esteja efetuando um rollback, executando um online backup ou ainda por se encontrar travado devido a falta de rea para o archive. Caso a causa no possa ser identificada facilmente, utilize a SM21 para tentar identificar possveis mensagens. De qualquer forma, elimine a causa antes de fazer novas tentativas de shutdown.
jluiz@cemig.com.br
Pgina 37
ACADEMIA
BASIS
CCMS Configuration
Overview
O Computing Center Management System, conhecido como CCMS e acionado pela transao SRZL, a ferramenta que prove o gerenciamento de : Performance, monitorao e anlise do R/3, sistema operacional e rede Profiles, modos de operao e logon groups Start/stop dos ambientes Banco de dados e do archiving do banco de dados; Carga de trabalho (workload) Impresses Segurana de acesso Antes de utiliz-lo, em toda sua potencialidade, ele deve ser configurado. Para isto os principais passos so : Importar as profiles e adequ-las ao ambiente disponvel para processamento Definir os modos de operao do sistema. Normalmente definimos dois (diurno e noturno) para balancear e distribuir a carga segundo o perfil de utilizao de cada horrio Criar as definies dos perfis das instncias com os seus respectivos parmetros de inicializao Associar cada um destes perfis aos modos de operaes Definir a tabela de horrios de entrada e sada de cada um destes perfis definidos no modo de operaes
RZ10: Profile Maintenance

Esta a ferramenta para manuteno das diversas profiles do R/3 (start, default e instance). Com ela podemos editar e manter todos os parmetros. A manuteno pode ser feita de forma bsica ou estendida, o que difere se os parmetros sero manipulados de forma individual ou de forma coletiva. A transao ainda permite deletar, comparar e verificar as profiles e suas diferentes verses. Lembrando, as profiles seguem o seguinte padro de nome : Start : START_DVEBMGS00_hostname Default : DEFAULT.PFL Instance : SID_DVEBMGS00_hostname Os passos para a manuteno inicial das profiles so : Importa-las a partir do sistema operacional; Mante-las utilizando a RZ10; salva-las e ativa-las. Tomar cuidado com o boto import pois ele importa apenas o servidor corrente. Para importar use o menu Utilities, Import profiles, of active servers.
R/3 Profiles
A incorreta configurao do CCMS no impede o funcionamento do R/3, porm impede que o CCMS exiba dados teis. A transao RZ10 do CCMS permite que se d manuteno nas profiles das instncias do R/3. Ela mantm os parmetros na base de dados do R/3 e a cada alterao efetuada uma nova verso gerada nesta base de dados. Quando ativamos uma verso de profile atravs desta interface, seus parmetros so copiados e transferidos para a profile ativa, que fica em diretrio prprio do sistema operacional. Desta forma a base de dados do R/3 pode conter vrias verses de uma mesma profile, um histrico das alteraes alm de documentao dos parmetros. Em ambientes distribudos com vrias instncias R/3, o diretrio de profiles compartilhado entre todas as instncias e permanece como repositrio central de todas as profiles. Para cada sistema R/3 existem vrias profiles. Uma DEFAULT profile e, para cada instncia do ambiente, uma instance e uma start profile. Atravs da ferramenta RZ10, existem dois modos de exibio/edio das profiles:
jluiz@cemig.com.br
Pgina 38
ACADEMIA
BASIS
Em basic mode, os parmetros que so alterados mais freqentemente so agrupados de acordo com suas interdependncias de modo que a alterao em um deles se reflita automaticamente nos demais. Nesta interface basic os parmetros aparecem sem os seus nomes tcnicos, mas apenas como campos em screen. Em extended mode, os parmetros aparecem e so editados em uma interface tipo editor de texto, onde cada parmetro listado com o seu nome tcnico e respectivo valor. O administrador aqui dever conhecer os seus nomes tcnicos e claro suas interdependncias.
O programa de instalao, R3SETUP, cria a primeira verso das profiles no sistema operacional de acordo com os recursos do sistema (memria e CPU). Durante o processo de configurao inicial do CCMS, importamos estas profiles para a base de dados R/3 utilizando a RZ10 e efetuamos as nossas customizaes. Isto permite uma gerncia centralizada de todas as profiles de um ambiente. As profiles utilizadas pelo R/3 para configurao da instncia durante o startup sempre a profile ativa, ou seja, aquela que se encontra copiada no sistema operacional. A partir do momento que importamos as profiles pela RZ10, todas as manutenes sempre devero se dar atravs desta interface nunca diretamente no sistema operacional para evitar que haja dessincronizao das ferramentas. Qualquer dvida quanto ao sincronismo poder ser verificado atravs de seus mecanismos de check e da comparao de verses. Do ponto de vista do R/3, uma profile consiste de duas partes lgicas: entradas nas tabelas da base de dados do R/3 e um arquivo no sistema operacional. Como a verso utilizada pelo startup a do OS (profile ativa), alteraes efetuadas nos parmetros devero ser salvas no sistema operacional e somente tero efeito no prximo start da instncia. Somente a verso mais recente de uma profile pode ser ativada pela ferramenta RZ10. Na prtica isto significa que a tentativa de ativar uma verso mais antiga faz com que a profile seja copiada com uma nova verso e ativada. Qualquer manuteno vai sempre gerando novas verses na base de dados que ficam documentadas como comentrios e headers no file do sistema operacional. Alteraes em parmetros de configurao de memria do R/3 podero ser ativados sem a necessidade de stop/start atravs da opo de Dynamic Switching na RZ10. O procedimento de check de profiles oferece vrios mecanismos de aferio de suas integridades: Comparar a profile da base de dados com a profile ativa no sistema operacional Verificar a sintaxe dos parmetros codificados Verificar se os valores especificados nos parmetros so vlidos ou ainda se no esto muito discrepantes (por exemplo 10 vezes maior que o default, etc.) Efetuar comparaes entre todas as profiles definidas para encontrar inconsistncias de definio. Com isto possvel encontrar erros na definio de mais de um message server, por exemplo. sistema efetua um check automtico de consistncia entre a profile ativa e a base de dados sempre que efetua um startup. Caso encontre alguma discrepncia um alert ativado no Alert Monitor
Operation Modes
Operation mode uma facilidade do R/3 que permite que se configure diferentes combinaes nos tipos de work processes que podem ser ativados ao longo do dia sem a necessidade de stop/start da instncia. Isto permite que possamos ter por exemplo uma maior disponibilizao de background work processes durante perodos de maior demanda desta funcionalidade, como perodos noturnos. J os perodos diurnos so caracterizados por uma demanda muito maior de processamento dialog. Operation mode permite portanto maximizar a utilizao dos recursos do sistema sem a necessidade de stop/start das instncias para que as configuraes tomem efeito. Uma configurao bsica de operation mode especifica os servios ou tipos dos work processes e os perodos escolhidos para cada intervalo. atravs desta funcionalidade que conseguimos configurar background work processes para processamento exclusivo de jobs classe A. Operation mode pode ser configurado baseado em alguns conceitos bsicos: nmero total de work processes deve permanecer o mesmo entre os operation modes de uma instncia, j que nenhum novo servio ser startado, apenas os processos tero suas funcionalidades reconfiguradas. jluiz@cemig.com.br Pgina 39
ACADEMIA

BASIS
Cada instncia dever permanecer com o requisito mnimo de dois dialog processes Cada sistema dever permanecer com um processo de enqueue e pelo menos um update.
A transao RZ10, atravs de seus mecanismos de check, oferece recursos para efetuar estas verificaes das profiles e dos operation modes configurados. A mudana de configurao entre operation modes pode ocorrer manualmente sob demanda do administrador do sistema atravs da RZ04 ou ento de forma automtica atravs da definio de um schedule de horrios chamado de timetable, que configura um ciclo completo de 24 horas. Este schedule de horrios mantido atravs da transao SM63. A timetable nica para todas as instncias de um sistema. Isto significa que todas devero possuir a mesma configurao de operation modes, porm cada uma poder ter a sua configurao individual de work processes. Alm da timetable normal que configura o ciclo de 24 horas do operation mode, possvel definir uma timetable excepcional para ser ativada em uma data especfica. Enquanto uma timetable normal deve possuir entradas que cobrem todas as 24 horas do dia, uma timetable excepcional poder possuir entradas apenas para um determinado perodo do dia. Nos demais perodos continuariam valendo as definies da timetable normal. Quando a mudana entre modos de operao ocorre, os work processes so distribudos automaticamente, sem necessidade de parada e restart das instncias. Nenhum tempo perdido por indisponibilidade do sistema, apenas o tipo dos work processes alterado, permanecendo porm o nmero total inalterado. possvel simular o switch de um operation mode em test mode e desta forma analisar possveis falhas atravs da log de switch. Discrepncias existentes na configurao das profiles ou na definio dos operation mode podero ser identificadas e eliminadas.
Starting and Stopping Instances with the CCMS

Atravs do CCMS, transao RZ03, possvel startar e parar as instncias R/3 de um sistema. A instncia de banco de dados e pelo menos uma instncia do ambiente precisam porm ter sido startadas atravs das ferramentas do sistema operacional. Em plataformas UNIX utilizada a facilidade de rexec para esta operao remota. J no NT esta facilidade (rexec) no padro e deve ser startada se precisarmos que uma instncia NT manipule uma instncia Unix. Alm de permitir a parada de uma instncia a RZ03 tambm permite o switch de operation mode manualmente.
jluiz@cemig.com.br
Pgina 40
ACADEMIA
BASIS
Background Processing
Background Concepts and Features
Um job background um ou mais programas ABAB, external programs ou external commands que rodam seqencialmente (steps) sem a interveno do usurio, baseados em eventos (event-based) ou horrios (time-based) pr estabelecidos. So utilizados principalmente para: Processar automaticamente tarefas rotineiras Processar informaes vindas de sistemas legados Processar tarefas baseado na ocorrncia de determinados eventos Processar uma carga em massa no ambiente em horrios de baixa atividade online Podem ser schedulados para serem disparados baseados em determinados eventos que ocorram tanto dentro quanto fora do R/3 (event-based jobs). Podem ser arranjados em classes (A, B ou C) que possuem uma hierarquia de prioridade na execuo. O sistema permite que se reserve work process livres para execuo exclusiva de jobs classe A. O mecanismo de funcionamento o seguinte: pelo menos x (configurado pela RZ04) work processes ficam reservados para classe A independente de quais sero eles. Os jobs so disparados atravs de um servio, o batch scheduler, que roda no sistema R/3. Este servio um programa ABAP que roda em um dialog work process no servidor parametrizado nas profiles do ambiente atravs do parmetro rdisp/bcttime. Neste parmetro especificado o tempo em segundos com que este programa roda, normalmente 60 segundos. Quando se especifica um valor igual a 0, o batch scheduler fica inibido naquele server. Um outro parmetro, o rdisp/bctname, define o nome do server onde os events sero checados para o disparo de jobs atravs desta facilidade, os event-based jobs. A definio de quantos batch work process estaro disponveis, sem levar em conta o modo de operao, est no parmetro rdisp/wp_no_btc. Por definio um sistema R/3 deve ter pelo menos 2 batch work process, independente de qual instncia eles vo estar, para atender o sistema de transporte. Se o sistema R/3 no for trabalhar com transportes no necessrio ter batch work process (mas isto meio absurdo se pensarmos no dia-a-dia prtico). O mecanismo do batch scheduler, aps a ativao, segue o seguintes passos : Verifica a job-scheduling table ordenado por data de start, classe, servidor de destino e data da criao do job; Se o job for para ser executado na prpria instncia o dispatcher acionado para alocar um BTC, se o job for para ser executado em qualquer instncia o message acionado para determinar qual o servidor com menor carga.
Operation Modes and Scheduling

O sistema efetua balanceamento de carga automtica entre os servidores, a menos que se especifique o server target do job. A especificao do server durante o schedule faz com que o job tenha prioridade sobre outros da mesma classe sem a especificao explcita do server. possvel configurar operation modes (atravs da transao RZ04) para efetuar um switch entre work processes de dialog e batch em horrios pr determinados sem a necessidade de um stop/start do R/3 para reconfigurao dos work processes A gerncia dos jobs feita a partir do CCMS e os jobs so schedulados a partir da transao SM36. Ao efetuar o schedule do job possvel especificar o nome de quem ir receber o spool request (opo Spool list recipient) que tanto pode ser um usurio R/3 quanto um mail do SAPOffice ou mail externo. Os Programas ABAP que requerem um determinada entrada de dados para execuo podero ser schedulados em background bastando que se informe uma variant (lista de parmetros) para processamento. Eventualmente o schedule pode ser acessado pela transao RZ01 que um visualizador grfico dos jobs que esto schedulados. Quando um job background executa comandos ou programas externos, o R/3 starta o programa server SAPXPG no host target atravs de chamadas RFC. Programas externos somente podem ser executados por usurios com autorizao para background administrator. Comandos externos podem jluiz@cemig.com.br Pgina 41
ACADEMIA
BASIS
ser executados por usurios com autorizaes R/3 apropriadas. Os programas externos somente rodam em modo sncrono e os comandos externos rodam tanto em modo sncrono quanto assncrono, dependendo das necessidades do usurio. Os jobs podem ser schedulados para rodar de diferentes maneiras: Imediatamente, Com data e hora programada, Aps a ocorrncia de um evento Aps a execuo de um outro job Em um modo de operao especifica Com periodicidade, etc
Events in Job Scheduling

Os eventos com que os jobs podero estar dependentes so eventos internos do R/3 (system start, opmode switch, etc) ou eventos definidos pelo usurio, como por exemplo o trmino de uma transferncia de dados Atravs da transao SM62 podemos definir os user events e a transao SM64 utilizada para disparar os eventos. O programa sapevt (Unix ou NT) utilizado para disparar um determinado evento a partir de uma linha de comando no sistema operacional. A sintaxe do comando SAPEVT <event> [-p <parameter>] [-t] [pf=<profile_path>] [name=<SID>] [nr=<instance]. O sapevt se conecta ao message server da instncia via tcp/ip para disparar o trigger no R/3. Internamente em um programa ABAP possvel ainda disparar um evento a partir da chamada a uma funo, a BP_EVENT_RAISE. Da mesma forma que o R/3 utiliza o SAPXPG para startar programas no sistema operacional o SAPEVT tambm utiliza o SAPXPG para startar eventos no R/3. Com isto possvel concatenar os steps e schedular os jobs de forma a atender praticamente qualquer necessidade de schedule.
Changing or Monitoring background Jobs Changing background job

Um job que esteja com o status de scheduled ou released pode ser alterado atravs da SM37. Estas alteraes podero ser desde a incluso de novos steps quanto a alterao de seu scheduling. Uma alterao tpica a classe de submisso, por exemplo para alterar a fila de prioridades. Jobs que esto rodando ou que j foram processados no podem ser alterado. Os jobs que esto rodando podem ser capturados, ou seja, debugados e eventualmente cancelados. Os jobs que j terminaram, com erro ou no, podem ser copiados.
Job Monitoring
Atravs da SM37 se monitora tanto os jobs que j rodaram quanto aqueles que se encontram schedulados. O job log pode ser pesquisado para verificar as mensagens do sistema para aquela execuo. A Spool list exibe a sada da execuo. A lista exibida na SM37 depende dos critrios marcados na tela inicial. necessrio uma especial ateno para a seleo dos jobs que no possuem uma data de start e para aqueles que dependem de algum evento (colocar * no evento e clicar nas opes de jobs sem data e com predecessores). Outro ponto a ser observado a diferena entre um job released e um job ready. O released j pode ser rodado, em funo da marcao do horrio e das autorizaes, mas no est na hora de ser executado. O ready j pode ser rodado mas ainda no foi atribudo para o work process que est disponvel (provavelmente o dispatcher est muito ocupado). De qualquer forma o tempo na situao de ready mnimo.
jluiz@cemig.com.br
Pgina 42
ACADEMIA
BASIS
Para ver os jobs existe tambm o Job Scheduling Monitor (RZ01) que exibe em modo grfico o schedule nos vrios servidores que compem o sistema ao longo do tempo. Esta transao tambm pode ser ativada a partir do Control/Monitoring do CCMS.
Job API, XBP-API and XMI-API

Atravs de programas ABAP possvel gerenciar e schedular jobs utilizando o Job Application Programming Interface, ou Job API. Atravs do Job API possvel por exemplo rodar jobs seqencialmente ou ainda incorporar lgica de deciso no ambiente de processamento ( O R/3 no consegue tratar schedule de jobs muito complexos. Um exemplo disto um job que precisaria de dois predecessores). As funes ABAP para o Job API se encontram no ABAP workbench com o nome BP_*. O XMI ou External Monitoring Interface um conjunto de mdulos de funes que agregam todas as funcionalidades para interface externas de gerenciamento do CCMS O XBP ou External Interface for Background Processing a interface externa para backgroundjob-scheduling. Estes mdulos possuem o nome comum SXMI_* e no devem ser confundidos com os Job APIs. Ferramentas externas de job scheduling (XBP) permitem que se integre em um nico ambiente o gerenciamento do schedule de jobs R/3 e no R/3 atravs de uma nica interface
Authorization for Background Jobs

A utilizao do job scheduling exige perfis especiais de autorizao para as funes de schedule e administrao. Os objetos de autorizao envolvidos so: S_BTCH_ADM que d as autorizaes para as funes administrativas. O usurio com esta autorizao com field setado para Y pode administrar jobs em todos os clients do sistema e no apenas do client onde ele est definido. S_BTCH_NAM d aos usurios a autorizao necessria para executar jobs em background. S_BTCH_JOB: este objeto possui funes que do aos usurios diversas facilidades na administrao de seus jobs e de outros usurios (DELE, LIST, PROT, RELE, PLAN e SHOW) S_ADMI_FCD: funes especiais para o administradordo sistema que devem ser utilizada somente pelo pessoal de basis S_RZL_ADM: administrador do sistema (CCMS)
Authorization for External Commands

Os objetos de autorizao envolvidos so: S_RZL_ADM que atravs de seus activity codes d autorizao para administrao do CCMS (01 equivale a all e 03 a display) S_LOG_COM que possui fields que autorizam a execuo de external commands S_TCODE que d autorizao para as transaes SM49 e SM69
Authorization for External Management Interfaces

Os objetos de autorizao envolvidos so: S_XMI_PROD define atravs de seus fields quais interfaces XMI e quais ferramentas externas podero ser utilizadas S_XMI_LOG define se o usurio pode acessar interfaces XMI e como este acesso ser feito
Dicas sobre jobs

Ao executar um comando do sistema operacional utilize cmd /c dir Quando o resultado de um comando externo no aparecer verifique os flags (aguardar o retorno)
jluiz@cemig.com.br
Pgina 43
ACADEMIA
BASIS
Advanced Background Processing

Types of Background Jobs
Os background jobs em um sistema R/3 podem ser divididos em duas categorias: Basis background jobs, que efetuam tarefas necessrias dentro do ambiente R/3, seja na coleta e armazenamento de estatsticas ou na tarefa de housekeeping da instncia, onde so normalmente schedulados como jobs peridicos Application background jobs, que so os jobs disparados pelos usurios em suas tarefas funcionais dentro do sistema. Os jobs de housekeeping efetuam tarefas tais como limpeza do spool, jobs antigos, sesses de batch input j processadas, limpeza de estatsticas, etc. Alguns possuem caractersticas de serem client independentes, outros j precisam ser schedulados em todos os clients do sistema e outros ainda possuem a caracterstica de que devem ser schedulados atravs de usurios especficos ou ainda com autorizaes especficas. A nota 16083 define esta sistemtica e descreve detalhadamente os jobs de housekeeping, inclusive quanto a periodicidade aconselhada. Os outros jobs que se enquadram na categoria dos jobs Basis so aqueles utilizados para coleta e organizao de estatsticas de utilizao do R/3. Nesta categoria, o SAP_COLLECTOR_FOR_PERFMONITOR (conhecido tambm como PERFORMANCE_MONITOR) executa de hora em hora o programa RSCOLL00 que, baseado em uma tabela (TCOLL) do sistema, dispara uma srie de outros programas a cada execuo para efetuar as mais diversas tarefas relacionadas ao recolhimento e consolidao de estatsticas. Os jobs que executam na categoria dos aplicativos efetuando tarefas funcionais dos mdulos do R/3 necessitam de monitorao constante, j que muitas vezes manipulam grandes quantidades de dados e so elevados consumidores de recursos, podendo portanto interferir com a performance do sistema online. Os jobs de aplicao devem ter uma programao estudada e ser cuidadosamente parametrizados pelas variantes para no trabalhar volumes muito elevados de informao. Em um ambiente R/3 produtivo, deve-se inclusive montar uma planilha de execuo para evitar gargalos de elevados volumes de processamento simultneos. Para uma maior compreenso veja as notas 24092 (distribuio de jobs em background), 70639 (agendando jobs em background), 16083 (limpeza de jobs do sistema), 12103, 32050 e 127642. Os principais programas a serem agendados para o basis so : RSBTCDEL: elimina as logs de job antigos RSPO0041: elimina os spools antigos RSBDCREO: elimina as pastas de batch input antigas RSSNAPDL: elimina os shortdumps antigos RSBPSTDE: elimina os jobs de estatsticas RSM13002: elimina updates antigos e pendentes. Este job s deve ser agendado se alguns dos seguintes parmetros for alterados: rdisp/vb_delete_after_execution, rdisp/vb_reorg, rdisp/vb_v2_start RSSTAT15: RSCOLL00 RSBPCOLL
Parallel Processing Using Asynchronous RFC

interessante que se verifique se programas batch problemticos e que no utilizam a facilidade de processamento paralelo atravs do uso de RFC assncrono possam ser reanalisados para incorporar esta facilidade. Uma chamada do tipo Asynchronous RFC permite uma otimizao no compartilhamento dos work processes por splitar o programa ABAP em vrias partes menores que so disparadas paralelamente entre os vrios dialog work process disponveis que compem um determinado grupo RFC, onde os resultados so coletados mais tarde. Esta tcnica foi desenvolvida jluiz@cemig.com.br Pgina 44
ACADEMIA
BASIS
para suprir o problema de que longos background jobs no encontravam janela noturna suficiente ou ainda quando no se encontra background work process em nmero suficiente para processar os jobs. Esta sistemtica exige alguns pr requisitos de ordem tcnica e conceitual para que seja implementada corretamente. preciso garantir que: comando ABAP que dispara RFC assncrono o CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP. Outras tcnicas de processamento RFC assncrono podem levar a um impacto negativo na performance do sistema Existam pelo menos trs dialog work processes disponveis alm dos dois que so necessrios para o processamento dos dialogs job possa ser dividido em unidades lgicas independentes, uma vez que sero processadas paralelamente A dispatcher queue dever estar com menos de 10% ocupada para garantir que o critrio de balanceamento da carga seja feito corretamente Este critrio portanto no se adapta a programas que devem ser processados seqencialmente onde as unidades lgicas dependem do resultado da anterior. Da mesma forma no existe uma garantia da seqncia com que as partes sero processadas individualmente. Os resultados de todas as partes separadas devero ser coletadas, sincronizadas e analisadas no final. Para maiores detalhes veja as notas 66612 e 99284. Para ver quais so os servidores disponveis no RFC group utilize a transao RZ12.
XMI/XBP Interface
A nota 69352 descreve a forma como external programs devem se comunicar com o R/3 utilizando a external monitoring interface (XMI) ou o external background processing interface (XBP) Atravs da transao SE37 pode-se ter acesso aos functions groups que implementam estas facilidades: External job management: Function group SXJI cujos function modules possuem o prefixo SXMI_XBP External monitoring basics: Function group SXMB cujos function modules possuem o prefixo SXMI_XMB Connecting to esternal tools: Function group SXMI cujos function modules possuem o prefixo SXMI Existem sistemas de terceiros certificados pela SAP que permitem a administrao e gerncia do schedule de jobs no R/3 atravs de um ambiente externo ao sistema. Estes sistemas se comunicam com o R/3 efetuando um logon via RFC e posteriormente atravs dos function modules da interface XMI. A principal vantagem neste sistema a possibilidade de gerenciar diversas plataformas, inclusive diversos sistemas R/3 a partir de uma nica interface centralizada. A desvantagem que se trata de um produto externo ao R/3 que deve portanto ser homologado e de fornecedor idneo e confivel para possibilitar possveis upgrades em novos releases do R/3. Do lado do R/3 podemos monitorar a utilizao da interface XMI atravs da transao RZ15.
Events in Job Scheduling

Os eventos utilizados para disparar jobs no R/3 podem ser: System events, que so definidos pela SAP e disparados a partir de determinadas aes definidas no ambiente, tais como um switch de operation mode User events, que so definidas pelo prprio usurio atravs da transao SM62 para permitir uma administrao mais personalizada de operao Os eventos podem possuir argumentos que sero verificados no momento do disparo e neste caso o job s ser executado se o parmetro for igual ao que foi definido no evento. Este argumento especificado tanto quando se schedula o job quanto no momento em que se dispara o evento, permitindo desta forma uma perfeita sincronizao de tarefas. Um bom exemplo para este uso o evento END_OF_DATA_TRANSFER que deve ser associado a uma parmetro para disparar um job especifico. Com isto no necessrio especificar vrios eventos para a mesma funcionalidade
jluiz@cemig.com.br
Pgina 45
ACADEMIA
BASIS
conceitual. Outro exemplo o uso do evento SAP_OPMODE_SWITCH com um parametro NOITE e que vai significar que o job s deve ser disparado quando o switch for para o perodo noturno. Jobs schedulados sem argumentos so disparados tanto quando o evento ocorre com argumento quanto sem argumentos. Os user events podem ser disparados por trs formas distintas: manualmente atravs da transao SM64, dentro de um programa ABAP atravs de chamada prpria de funo (BP_EVENT_RAISE) ou ainda atravs de chamada a um programa externo, o sapevt. Neste ltimo caso a chamada poderia estar contida em um script ou at mesmo como um step de um job R/3 (external program step)
External Commands and External Programs

External commands podem ser executados tanto pelos administradores do sistema quantos por usurios que possuam autorizao especfica. A transao SM69 utilizada para criar e dar manuteno em external comands, que posteriormente podem ser executados atravs da transao SM49 ou inseridos em steps dos background jobs. Atravs de chamadas de funes especficas tambm possvel executar external commands de dentro de programas ABAP. Alm destas transaes podemos utilizar tambm a AL11 para listar os comandos. External commands somente podem ser executados em modo sncrono e para garantir a correta execuo dos programas e comandos, especifique sempre o seu path completo. Para rodar um external program os seguintes requisitos so necessrios: Gateway server do R/3 dever estar ativo para estabelecer a comunicao entre o servidor host do processo e o target system, j que o processo startado utilizando o CPI-C. Para ter certeza que no havera problema utilize o parmetro gw/remsh como /bin/rsh para solaris e rsh para NT. Se o comando/programa no se encontra no path do CPI-C user, o path completo dever ser especificado, que quem ser utilizado para executar o comando. Normalmente este usurio o <SID>adm diretrio de executveis do R/3 (/usr/sap/SID/SYS/exe/run) dever estar no path do CPI-C user, uma vez que o comando executado atravs de um programa de controle do R/3 que gerencia o cdigo de retorno do sistema operacional. Um external program pode apresentar problemas para ser utilizado, ou por no poder ser startado ou ainda por no conseguir retornar um resultado para o job background. Estes problemas devero ser identificados e corrigidos atravs da analise da log de erro do job ou ligando o trace de analise de external programs O SAPXPG, ou trace de programas externos, pode ser ligado atravs da execuo do comando pela SM69 e pela especificao de uma varivel de ambiente, a sapxpg_trace, no sistema target onde o comando ir rodar. O trace mais detalhado obtido quando esta varivel setada com o valor 3 (levels 1, 2 e 3) que possui o maior nvel de detalhe.
Authorizations for Background

muito importante que o usurio tenha acesso restrito a utilizao de jobs. Preferencialmente permita que os usurios submetam em classe B e C mas limite o acesso a comandos externos e do sistema operacional. Permita somente o administrador do sistema ter acesso ao perfil de administrador de segurana e libere para o usurio a submiso, deleo, liberao, alterao e agendamento de seus proprio jobs.
ABAP API scheduling

A Application Programming Interface (API) permite que se gerencie e schedule jobs a partir de programas ABAP ou external programs. Com isto possvel alm da total gerencia sobre o job (display, copy, delete), exibir a log gerada ou ainda disparar eventos. A API oferece duas funes de uso simplificado que, apesar de no oferecerem muitos recursos, so extremamente simples de se
jluiz@cemig.com.br
Pgina 46
ACADEMIA
BASIS
usar: A BP_JOBVARIANT_SCHEDULE que schedula um report ABAP passando apenas a sua variante para execuo e o BP_JOBVARIANT_OVERVIEW para gerencia simplificada de jobs Para a programao normal, utiliza-se as funes JOB_OPEN, JOB_SUBMIT e JOB_END. Atravs destas facilidades possvel dar ao usurio a capacidade de schedular e gerenciar jobs sem contudo ter acesso a transao SM36 e SM37. Com isto possvel implementar uma maior segurana e implementar uma padronizao no nome dos jobs no ambiente atravs de uma interface bem mais simplificada para o usurio final.
Background Check and Troubleshooting

Alm da SM37, existem outras transaes no sistema que permitem ao usurio analisar a sua pasta particular de jobs. A transao SMX oferece uma forma simplificada para o usurio analisar seus prprios jobs atravs de listas mais compactas e campos sumariados. J a SM39 exibe uma analise bem mais detalhada, inclusive com informaes estatsticas. Caso um usurio no esteja conseguindo administrar seus jobs, a causa mais provvel ser autorizaes incorretas pois eventualmente o job pode ficar release mas por falta de autorizao ele no inicializa. Caso os jobs no estejam rodando, alm de verificar a existncia de work process disponveis (SM50), verifique se os batch schedulers (time-based e event-based) esto rodando corretamente atravs da transaes SM61 e SM65. Lembre-se da configurao dos parmetros de profile vistos anteriormente.
jluiz@cemig.com.br
Pgina 47
ACADEMIA
BASIS
Data Archiving
Definition
Archiving uma sistemtica que permite transferir dados das bases de dados R/3 para arquivos, do tipo texto estruturado, armazenados fora do ambiente R/3, seja meio magntico ou tico, em formato compactado. implementado no R/3 atravs da transao SARA. Vrias razes podem justificar um projeto de archive: Falta de espao fsico no database Problemas com backup e recovery devido ao tamanho do banco Performance baixa devido a tabelas muito extensas Banco de dados possui grandes volumes de dados que raramente so utilizados Devido a razes legais ou motivado pelo negcio da empresa, uma srie de informaes precisam ser mantidas disponveis para consulta ao longo do tempo A freqncia e a necessidade de efetuar archiving varia portanto de empresa para empresa, baseado nos seus recursos de hardware disponveis e no seu objeto de negcio. Em relao ao negcio s faz sentido fazer archive de informaes que realmente podem ir para o arquivo morto.
How Archive Works

O processo consiste de duas etapas: na primeira os dados so lidos na base de dados R/3, marcados e copiados para arquivos externos a partir das orientaes do archiving objects (conjunto de tabelas que estipula quais dados deve transitar de forma conjunta). Na segunda etapa os dados marcados so consistidos e deletados da base de dados. Este processamento em duas fases existe exatamente para garantir a mxima segurana desta sistemtica. A arquitetura de archiving baseada em objetos de archiving que definem os processos e contm informaes sobre o processo: Informao sobre as tabelas que contm os dados que sero arquivados programa que extrai os dados e armazena em files externos programa de deleo, que compara os dados armazenados com a base e efetua o delete se ambos esto idnticos, garantindo a integridade dos dados extrados Documentao do processo (visualizado atravs da opo Info na SARA) A compresso dos dados nos files gerados da ordem de 5, embora cluster tables no possam ser compactadas. O processo pode demandar muito processamento e I/O sendo recomendado rodar em horrios fora do pico no sistema. O processo de delete (segunda fase do arquive) pode ser selecionado para rodar imediatamente aps o extact ou para processamento posterior, comandado pelo usurio. Apesar do processo de deleo somente ocorrer aps um verificao dos dados armazenados, interessante que durante a implantao e testes de um ambiente de archive garantir que esta facilidade no seja disparada automaticamente.
Archive Environment
Existem uma srie de objetos de archive j desenvolvidos pela SAP para operacionalizar o archive em diversas reas e tabelas standard do SAP. A cada nova verso do R/3, uma tendncia que novos objetos sejam introduzidos. A ferramenta ADK (Archive Development Kit) a interface disponibilizada pela SAP entre os ABAP archiving programs e os archive files. Ela consiste de uma srie de function modules. Desta forma a leitura dos dados arquivados efetuada atravs de chamada a funes do ADK. Durante o processo de gravao, o ADK pode splitar os dados que sero arquivados em vrios files. Esta interface nica atravs do ADK garante que o dado armazenado seja visto pelos programas ABAP na forma exata com que foram arquivados. possvel utilizar o ADK para desenvolver objetos de archiving para tabelas Z, definidas pelo usurio. Nunca a utilize para acessar tabelas SAP standard, mesmo que no exista um objeto desenvolvido para determinada tarefa. O SAP ArchiveLink uma interface para gerencia dos files arquivados.
jluiz@cemig.com.br
Pgina 48
ACADEMIA
BASIS
Acessing Archived Data

Quase todos os objetos de archive possuem programas de leitura prprios que lem o arquivo seqencial gerado e emitem relatrios. Alguns objetos nos do ainda a facilidade de emitir relatrios que mesclam informaes arquivadas com informaes do banco, como comum em quase todas as anlises de relatrios FI. Algumas telas R/3 podem consultar dados diretamente dos archive files, como o caso da FB03, MB61, VB03, entre outras. Apesar de alguns objetos de archive possurem a facilidade de reload dos dados (operao inversa do archive), recomendado que esta operao somente seja efetuada para corrigir erros de operao, como por exemplo archive disparado antes da hora. A SAP recomenda inclusive que esta operao seja efetuada somente nestes casos e imediatamente aps a operao mal feita, nunca alguns dias depois. S para lembrar, SD no pode sofrer o reload a partir da verso 4.0a.
Preparations for Data Archiving

Archiving um projeto que envolve de forma cooperativa a rea de Basis, analistas e usurios das reas funcionais alm de uma assessoria jurdica para um amparo legal dos documentos gerados. Do ponto de vista dos aplicativos, o archive se justifica j que alguns dados se tornam obsoletos e no mais se fazem necessrios para consulta online. o conhecido arquivo morto das empresas. Do ponto de vista da administrao do sistema, o archive se faz necessrios para esvaziar o banco, seja por questes de tempo de backup/restore, performance ou ainda por falta de espao em disco. Os administradores de sistemas acessam as funes de archiving normalmente atravs da transao SARA. Os usurios dos aplicativos ativam a interface atravs de entradas nos seus menus funcionais. necessrio uma identificao cuidadosa das tabelas com alto ndice de crescimento e objetos que se justificam pelas necessidades do negcio. A transao DB15 um excelente auxlio nesta anlise por fornecer uma referncia cruzada entre tabelas e objetos de archiving. Identifique e estude todas as notas no OSS que se referem aos archive objects que sero implementados Para cada objeto de archiving preciso definir suas parametrizaes que configuram os dados que sero arquivados e a forma como esta operao ser efetuada (tamanho dos datafiles gerados, nmero de registros em cada file, etc.). A transao SF01 utilizada para customizar o logical file e paths. O objeto de archive possui duas variantes para o programa de deleo. O archive run possui uma outra variante onde voc define os dados que sero arquivados Durante todo o processo deve ser garantido a existencia de recursos computacionais para o processo como pelo menos dois work process livres para o archive e disco disponvel para a movimentao de dados.
Monitoring an Archiving Run

Um archive roda em background e pode ser monitorado atravs da SM37. Dependendo da configurao efetuada (tamanho dos files), o sistema pode gerar mais de um job de write, um para cada file. Para cada file gravado o sistema gera ainda um respectivo job para efetuar a segunda parte do archive, a fase do check e delete. Atravs da transao SARA (funcionalidade management) possvel monitorar o tamanho, localizao dos files e nmero de registros arquivados. Caso o processo de archive no seja completado com sucesso, diversas opes tero que ser tomadas, dependendo do caso: Caso ocorra um erro durante um dos jobs da primeira fase (write), preciso fazer um backup dos files que foram gerados com sucesso, excluir o que estava sendo gerado no momento do erro e aps isto restartar o processo para que os demais files sejam gerados e os registros deletados Se o erro ocorrer durante a fase do delete, ou seja, todos os files foram gerados com sucesso e um dos jobs da segunda fase abendou, basta startar os jobs de delete manualmente. Se ocorreu um erro durante a primeira fase e os jobs de delete no esto com start automtico, preciso deletar os files que foram gerados at o momento e recomear o processo
jluiz@cemig.com.br
Pgina 49
ACADEMIA
BASIS
Para efetuar operaes de archive preciso possuir a autorizao especfica (S_ARCHIVE). A transao SARA possui uma funcionalidade de Info que descreve para cada objeto de archive as autorizaes necessrias para percorrer as tabelas do R/3 e recolher os dados. Alm disso no se deve esquecer que o archive roda em background, significando que o usurio envolvido no processo alm de possuir autorizao para a area funcional precisa possuir as autorizaes suficientes para esta tarefa de rodar os jobs de archives. Dicas prticas : Veja a tabela arch* para entender a relao entre os objetos de archives e as tabelas envolvidas Sempre que for fazer um archive faa o ciclo completo para evitar perda de controle, tanto do operacional quanto do R/3 Sempre procure notas sobre o objeto que ser arquivado pois como esta area est sendo desenvolvida podem ter novas verses e atualizaes Utilize o objeto bc_archive para arquivar os documentos de archive.
jluiz@cemig.com.br
Pgina 50
ACADEMIA
BASIS
System Monitoring
What, why, who and when
Os principais focos de monitorao so : R/3 (application servers, buffers, ) Database (performance, buffers, backups, ) Operationg system (cpu, file system, hardware contention, ) A monitorao no R/3 4.0 feita de uma forma simplificada atravs de uma grande arvore que ira mostrar, atravs de suas folhas, os diversos item que devemos estar atentos em todo o ambiente. A grande vantagem desta arvore a hierarquizao e categorizao de todos os elementos (tree elements e objects) que so relevantes, seus parmetros de valores (Attributes) e a captura automtica e centralizada de todas as informaes e um ponto de acesso unico para a tarefa de monitorao.
Monitoring Architecture
O Alert Monitor uma ferramenta configurvel que existe no R/3 e permite a monitorao de todo o ambiente a partir de uma nica interface que exibe mensagens e sinais de alerta no sistema. A monitorao dos diversos componentes e ferramentas do ambiente R/3 uma operao necessria executada pelos administradores do sistema para melhorar a performance, garantir a disponibilidade do sistema e identificar, analisar e corrigir erros que aparecerem no ambiente. Esta monitorao uma tarefa peridica que abrange desde o sistema operacional, passando pelos componentes do kernel R/3 e indo at a base de dados do sistema. Os objetos passveis de monitorao no ambiente R/3 so arranjados em uma rvore que sumariza em seus ns as diversas reas de atuao. Esta monitoring tree agrega atributos em seus ns que podem ir sendo detalhados at chegar a granularidade mnima da entidade monitorada. Um alert identificado em um destes atributos se reflete visualmente atravs de cores (verde-ok, amarelowarning, vermelho-alert) nos ns da rvore e hierarquicamente so transferidos para os galhos mais elevados. necessrio portanto ir efetuando operaes de drill down no Alert monitor at identificar o atributo que gerou a mensagem. previsto para releases futuros do R/3 que a funcionalidade do monitor se estenda para anlise do transport system e das transaes de aplicao O monitor do R/3 concebido com uma arquitetura aberta que permite inclusive que ferramentas de terceiros sejam incorporadas a sua rvore de monitorao. Cada n da rvore denominado MTE (monitoring tree element), que podem ser agrupados em classes de monitorao. Os objetos fsicos ou lgicos que so passveis de monitorao so denominados Monitoring Objects.
Preparing the Monitor

O Alert Monitor precisa ser customizado e configurado para funcionar corretamente. Cada MTE class pode ser configurada baseado em quesitos tipo nvel de visibilidade (operador, administrador, etc.), prioridade do alerta e descries. Estas configuraes ficam vlidas para todos os objetos pertencentes a uma determinada classe, evitando assim redundncia de definies. Os atributos comuns tambm podem ser agrupados em customizing groups aos quais so associados thresholds para os alerts e textos de alerta. Uma vez configurados os alerts, possvel ento associar tools aos MTEs. Estas ferramentas permitiro: Coletar dados Analisar os alerts Reagir aos alerts (OnAlert tool) As ferramentas podem ser associadas aos MTE classes ou a um MTE individualmente. Estas ferramentas tanto podero ser ferramentas standard da SAP quanto ferramentas definidas e criadas
jluiz@cemig.com.br
Pgina 51
ACADEMIA
BASIS
pelo usurio. A rvore bsica de monitorao contm o Basic monitor, porm o usurio pode criar suas prprias rvores customizadas de monitorao.
Tool Assignment
Para adicionar uma ferramenta ou uma classe na MTE devemos seguir os seguintes passos : Definir a ferramenta e especificar o tipo da ferramenta (relatrio, funo, mdulo, transao, programa, etc), a localizao (servidor, banco de dados, etc) e modus operandis (background, foreground, manual) Liberar a transao para a finalidade Associar a ferramenta a classe ou ao no MTE. Isto facilita o acesso a ferramenta pois voce vai aciona-la diretamente. Eventualmente voce pode herdar esta definio de outra arvore ou at no implementar a ferramenta
Monitoring and Tools

Na estrutura do Alert monitor cada server exibido separadamente. Cada server tem sua prpria rvore que contm as seguintes estruturas: Operating system, Database, R/3 services, R/3 basis system, R/3 ABAP e R/3 system log. As principais transaes e mtodos para monitorar o sistema so : A system log (transao SM21) contm informaes referentes ao sistema R/3 e suas instncias e exibe mensagens categorizadas por classes: S (R/3 start/stop/operation mode switches), W (rollback perfomed), K (kernel program error) e T (ABAP transaction error). No NT a transao mostra o log (/usr/sap/SID/dvebmgs00/log/slog00.log) apenas da instncia corrente. No Unix ela pode mostrar as logs de todas as instncias n R/3 services prov informaes sobre os work processes do sistema. A transao SM51 nos d um overview (incluindo a queue do dispatcher, system log, remote logon, etc) das instncias disponveis enquanto a SM50 analisa os work process de uma instncia especfica. A SM66 oferece um overview de todos os work processes ativos (se for necessrio o default pode ser alterado para ver todos ou em um status especifico) em todos as instncias do sistema. A SM04 e AL08 nos d um overview dos usurios logados no ambiente R/3. A SM04 mostra os usurios de uma determinada instncia e a AL08 de todas as instncias ativas. processo de update no R/3 usualmente executado em modo assncrono, onde os dados so escritos em tabelas intermedirias (VB* tables) e posteriormente transferidas para a base de dados pelos work processes de update V1 e V2. A transao SM13 permite a monitorao da fila e dos processos de update. A fila de update poder conter processos que terminaram com erro. Apesar de ser possvel em alguns casos restartar estes processos, a SAP no recomenda que se proceda ao restart da transao pelo usurio. R/3 possui seu prprio mecanismo de lock que fica residente em uma tabela na memria da instncia que contm o processo de enqueue. Os locks podem ser monitorados atravs da transao SM12. Os locks que permanecem no sistema podero ser eliminados manualmente aps exaustiva verificao das causas, uma vez que o procedimento normal quando os locks postados so eliminados automaticamente pelo update das tabelas ou cancelamento da transao. A transao ST22 permite que se analise os dumps de programas ABAP. Atravs desta anlise possvel identificar o erro pela anlise dos campos e variveis envolvidos e eventualmente procurar no OSS por notas que corrijam o problema. A ST03 o workload monitor que permite analisar os tempos de resposta. As estatsticas dos tempos de resposta das transaes so apresentados de forma detalhada e estratificadas por componentes (rolltime, wait time, DB time, processing time e load time) permitindo a rpida identificao de possveis gargalos no ambiente R/3. As estatsticas apresentadas pela ST03 permanecem em um arquivo do sistema operacional (file stat no diretrio data da instncia) e so recolhidas e consolidadas de tempos em tempos pelo programa RSCOLL00 schedulado no ambiente. Este programa se baseia na tabela TCOLL para disparar uma srie de outros programas satlites que efetuam as mais diversas tarefas de consolidao por nveis de tempo/data.
jluiz@cemig.com.br
Pgina 52
ACADEMIA

BASIS
A SMLG permite definir e monitorar logon groups. Com esta facilidade possvel fazer balanceamento de carga atravs da distribuio inteligente dos usurios das diversas reas pelos servidores de aplicao da rede. A transao ST02 prov informaes referentes aos status dos buffers e o gerenciamento de memria do ambiente. A transao ST04 permite monitorar a base de dados do ambiente deforma detalhada, seja atravs de anlise de buffers ou da anlise fsica de discos e locks. A ST06 exibe informaes referentes ao sistema operacional recolhidas pelo programa saposcoll. A anlise pode ser tanto um retrato do instante quanto uma comparao evolutiva das ltimas 24 horas.
Os work processes alocam reas na memria para trabalhar os processos. Um dialog work process trabalha em modo multiplexado para otimizar a sua utilizao entre os diversos dialog steps que compem um transao R/3. Para permitir esta multiplexao, os dialog work processes efetuam operaes de roll out e roll in da user context area dos processos. Quando um processo rolled out por um work process e posteriormente rolled in por outro dialog da instncia ocorre o que chamamos de work process dispatch Diferentes tipos de memria so alocados pelos dialog work processes. Inicialmente o sistema aloca uma pequena poro da roll area (definido no parmetro ztta/roll_first) onde estabelece ponteiros para os diversos pedaos de memria que vo sendo alocados na extended memory do sistema. Uma vez esgotado o limite de memria obtido na extended memory, o dialog passa a utilizar o restante da roll area disponvel. Note que ao entrar em multiplexao, o processo de roll out/roll in efetua rolagem apenas da poro de memria alocada na roll area, j que a extended memory permanece alocada mas tem os seus ponteiros salvos no processo. Quando toda esta rea esgota, o dialog lana ento mo da memria local, ou heap area. Como esta memria no pode ser rolled out (por ser grande), o dialog entra em modo PRIV (private) e para de fazer multiplexao, permanecendo alocado para o usurio mesmo durante os dialog steps. Como os background work processes no necessitam fazer roll in/roll out por no serem conversacionais, a seqncia de alocao de memria varia em relao aos dialog. O sistema aloca a roll area, posteriormente a privaty memory (heap) e somente ento faz uso da extended memory, que fica desta forma mais dedicada para os dialog process. Quando se trabalha com vrios application servers em um ambiente R/3, necessrio que os servers permaneam sincronizados para garantir a integridade dos insert e updates que ocorrem no ambiente. Os dados que necessitam de sincronizao so escritos em uma tabela (DDLOG) que de tempos em tempos consultada e os dados l presentes sofrem refresh na memria das instncias, sendo desta forma sincronizados. O parmetro rdisp/buffrefmode especifica como a escrita e leitura desta tabela ocorre e o parmetro rdisp/buffreftime especifica a frequencia do refresh. O parmetro rdisp/buffrefmode possui um valor dividido em duas partes. O primeiro campo especifica se o sistema ir (sendon) ou no (sendoff) escrever valores na DDLOG. O segundo campo especifica se o sistema ir (exeauto) ou no (exeoff) efetuar leitura e consequentemente refresh dos dados l gravados. Sistemas distribudos com vrias instncias devero ter o parmetro rdisp/buffrefmode=sendon/ exeauto especificado em cada uma de suas instance profiles. At mesmo sistemas que possuem apenas uma instncia devero especificar este parmetro para sendoff/exeauto j que durante o processo de transporte o tp grava entradas nesta tabela para posterior refresh.
jluiz@cemig.com.br
Pgina 53
ACADEMIA
BASIS
Segunda Semana Users and Authorization in the R/3 System

Users in the R/3 environment
O Ambiente R/3 possui vrias formas de controle de acesso mas devemos lembrar que ele est sendo executando em um sistema operacional e utiliza um banco de dados como repositrio e portanto devemos observar os aspectos de segurana nestes ambientes e na inter-relao entre o R/3 e eles. Devemos tomar cuidado com os usurios do sistema operacional (normalmente SIDadm) e do banco de dados (sys/change_on_install e system/manager) tanto na central instance quanta nos applications. Com estas chaves podemos acionar utilitrios no sistema operacional, como sapevt, e/ou acessar o banco de dados diretamente a partir de utilitrios do oracle. Do lado do R/3 temos que ter os mesmos cuidados pois uma brecha na autorizao pode permitir que uma chave no R/3 acabe por ter acesso ao sistema operacional e aos mesmos utilitrios mencionados anteriormente. Uma das primeiras atividades aps a instalao do sistema a troca das senhas dos usurios (SIDadm, sys, system, sap, sap*, ddic e earlywatch). .
Authorization Concepts
As autorizaes existem para limitar o acesso a transaes e objetos do sistema R/3 que necessitam de proteo. As autorizaes so agrupadas em profiles e estas profiles so associadas ao master record do usurio. Autorizaes podem ser no nvel da transao ou nos mais diversos nveis, como por exemplo em operaes na transao ou ainda em range de valores de campos As autorizaes sempre pertencem a authorization objects. Estes objetos de autorizao so agrupados em object classes que por sua vez so organizados ou categorizados por business area (FI, SD, etc.). As autorizaes so mantidas atravs da especificao de valores para determinados fields dentro de cada objeto de autorizao (que pode ter at 10 fields). Todas as autorizaes so do tipo positivas, ou seja, efetuam grants para o usurio e no revokes, ou seja, se duas autorizaes forem dadas, uma mais restritiva e outra mais ampla, vale a mais ampla. Um user master record pode possuir uma ou mais profiles, que podem ter sido geradas atravs da definio de activity groups (profile generator PFCG) ou manualmente. Uma profile pode ainda ser composta de mais de uma profile (composite profile) mas limitada a um mximo de 150 profiles. As profiles so associadas ao usurio tanto manualmente atravs da SU01 quanto durante o processo de gerao e manuteno das activity groups. Eventualmente pode ser necessrio criar objetos de autorizaes alm do standard. Para isso usamos a transao SU21 para manter objetos de autorizaes e a SU20 para manter os campos dos objetos de autorizaes. Em relao aos papis dos administradores de segurana no sistema poderamos dividir a administrao em trs nveis, a saber : Administrador de usurio: responsvel por manter os dados dos usurios, por associar os grupos de atividades e as profiles aos usurios e atender aos chamados dos usurios Administrador de profiles: responsvel por manter os grupos de atividades e as profiles de forma genrica sem entrar no mrito dos valores atribudos as responsabilidades e atendo-se apenas as transaes do perfil Administrador dos dados da autorizao: responsvel por manter os valores dentro das responsabilidades dos grupos de atividades Desta forma o superuser poderia delegar grande parte das tarefas para se dedicar as demais atividades de basis e os demais administradores poderiam entender bem mais das questes
jluiz@cemig.com.br
Pgina 54
ACADEMIA
BASIS
semnticas associadas as autorizaes aplicadas a cada funo a ser desempenhada pelos usurios.
Authorization as ER
Classes Objects Fields
1-n na task e n-n no cdigo abap
Authoriz.
Values
Transaction
Profiles
Users
Authorization Checks
Quando o usurio efetua o logon no sistema suas autorizaes so carregadas para a user context area (que fica na roll area da instncia) e so verificadas a cada transao ou atividade executada pelo usurio. Antes que uma determinada transao ou operao ocorra, os fields do authorization object so checados contra os fields do usurio para aquele mesmo objeto de autorizao. Esta operao do tipo AND, ou seja, todos os n fields do objeto tem que ser atendidos. Caso a verificao falhe, o usurio recebe uma mensagem de erro e a operao no executada. Caso o usurio possua duas autorizaes contrastantes, vale aquela que libera o acesso, j que entre fields do mesmo tipo a operao OR. Para simplificar, podemos entender que a verificao de segurana ocorre nos seguintes em passos : Para ganhar acesso a transao Verifica se o usurio est autorizado a acessar a transao atravs da verificao do objeto s_tcode Verifica o objeto associado a transao em questo e se o usurio tem autorizao para este objeto e quais so elas. Ex. O usurio possui o s_tcode para mm01, mas possui o valor 03 para o campo actvt do objeto m_mate_sta Durante o processamento do cdigo abap Verificao das autorizaes verificadas pelo comando abap authority-check Algumas outras dicas isoladas de autorizaes : Durante um call transaction os dois primeiros passos, relacionados a segurana da transao, no so verificados Se o buffer do usurio for pequeno demais (veja parmetro auth/auth_number_in_userbuffer) algumas autorizaes podem ser perdidas Se for necessrio cancelar a verificao do s_tcode utilize o parmetro auth/no_check_on_tcode Se for necessrio saber quais autorizaes esto carregadas no buffer utilize a transao SU56 e se for necessrio saber qual autorizao est faltando utilize a SU53 Dicas de tabelas: Tabela TACT contm todos as atividades possveis no r/3 e a TACTZ contm o relacionamento das atividades possveis para um objeto
Profile Generator
O profile generator (PFCG) uma ferramenta que simplifica a administrao de segurana atravs de uma viso voltada para o menu de transaes da empresa permitindo que de forma mais interativa se crie e associe profiles para usurio ou grupo de usurios que executam determinada funo. Este
jluiz@cemig.com.br
Pgina 55
ACADEMIA
BASIS
grupo lgico de funes comuns que possuem profiles comuns so denominados Activity Groups. Um usurio pode estar associado a um ou mais activity groups. Ao se associar uma transao a um determinado activity group, o profile generator automaticamente identifica os authorization objects necessrios para aquela atividade e os associa a profile que ser gerada. Caso os fields sejam customer-independents, o sistema j prov os valores necessrios para a atividade, caso contrrio os valores precisam ser completados pelo administrador durante o processo de gerao. Ao gerar um activity group o administrador de segurana dever checar os valores propostos pelo sistema para os diversos field e altera-los ou prov-los conforme o caso, antes de salvar o processo O R/3 permite ainda que se crie os activity group com responsabilities, o que permite que uma mesma descrio funcional (activity group) seja associada para diferentes grupos de usurios, provendo assim diferentes nveis de autorizao dentro de uma mesma funcionalidade. Isto simplifica a administrao de segurana. Neste caso os usurios so associados a responsabilitie e no mais ao activity group. Isto significa que caso grupos distintos de usurios que efetuam as mesmas transaes em um sistema R/3 diferindo apenas nas autorizaes para operaes permitidas dentro destas transaes no mais precisam ser administrados a partir de activity groups distintos, mas sim atravs de responsabilities distintas dentro do mesmo activity group. Neste tipo de administrao, as autorizaes para transao so associadas apenas uma vez no activity group para os diversos usurios, o que simplifica caso uma nova transao comece a fazer parte de suas atividades. Ao exibir a lista de autorizaes no profile generator, o sistema divide a exibio em 3 nveis: primeiro nvel contm as object class, por exemplo Standard Finantial Accounting - FI segundo nvel contm os authorization objects, por exemplo Customer: Authorization for company codes F_KNA1_BUK No terceiro nvel contm authorizations, por exemplo Customer: Authorization for company codes T..... e abaixo dele o sistema lista todos os fields com seus respectivos valores Nesta lista possvel dar manuteno nos valores (clicando no lpis) ou ainda obter documentao detalhada de um authorization object s dar um duplo click na sua descrio (segundo nvel). Ao se clicar no item da montanha (authorization object) possvel obter uma lista das transaes daquele activity group que necessitam deste objeto de autorizao. O profile generator possui outra caracterstica. Nele possvel fazer o apontamento para os usurios que iro possuir um determinado perfil. Neste caso devemos executar o programa RHAUTUPD para rever as profiles e task profiles dos usurios. Na prtica o programa varre o cadastro de usurios removendo todas entradas relacionadas ao grupo de atividade que esta sendo trabalhado e depois insere-as novamente. Se for necessrio fazer isto para todos os grupos de atividades devemos utilizar a transao PFUD, que aciona o programa RHAUTUP1. recomendado que este programa esteja agendado para rodar diariamente durante o periodo noturno. Com isto temos a garantia que os apontamentos sempre estaro corretos. Os principais passos para a criao de um perfil, tambm conhecido como activity group, so : Especificar as atividades que sero desenvolvidas a partir dos caminhos de menu Criar as responsabilidades (opcional) Criar a authorization profile Associar os usurios ao activity group Atualizar, utilizando o rhautupd, o mestre de usurios Devemos procurar sempre alterar o nome gerado pelo standard para facilitar o compreendimento e a localizao. A SAP sugere que o nome sempre comee por S_. O profile utiliza as cpias de algumas tabelas standard (USOBT e USOBX) para trabalhar. A USOBT_C contm os objetos que precisam ser verificados e a USOBX_C os valores necessrios aos objetos. Estas tabelas podem ter seus contedos mantidos pela transao SU25. J a transao SU24 pode ser utilizada para ajustar os checks dos objetos. Como ilustrao, a transao SU24 mantm o tipo de check que ser feito, a saber : U no mantido; N no checked; C checkado mas os valores no so mostrados no profile generator e CM o check feito e o profile generator conhece os valores possveis.
jluiz@cemig.com.br
Pgina 56
ACADEMIA
BASIS
User Master Record

Atravs da transao SU01 possvel dar manuteno nos usurios. As informaes esto agrupadas por identificao e localizao, dados de logon, defaults, task profiles, profiles e parmetros. J a transao SU3 (ou System User profile Own data) permite que o prprio usurio altere seus dados, tais como Address, Defaults e Parameters, sem violar a segurana de acesso estabelecida pelo administrador. Lembrar sempre que se for associar uma task ou responsibility (profiles geradas por profile generator) a um usurio, o correto faze-lo pela pasta de task profiles. Se a incluso for feita pela pasta de profiles a autorizao vai funcionar mas na prxima reconciliao (execuo do rhautupd) este dado ser perdido pois vai prevalecer apenas as profiles adicionadas na task profiles.
Settings for System Profile Parameters

Diversos parmetros configuram o funcionalidade de segurana no R/3, a saber : Configurar o tamanho mnimo da senha, login/min_password_lng com default 8 Marcar de quanto em quanto tempo a senha deve ser alterada, login/password_expiration_time Bloqueio de usurios aps logons incorretos, login/fails_to_user_lock com default 12 Fechar a sesso aps logons incorretos, login/fails_to_session_end com default 3 Desbloqueio de logons incorretos, login/failed_user_auto_unlock com default 1 (desbloqueia), a meia noite Bloquear o sap* de logar no sistema, login/no_automatic_user_sapstar com default 0 Existem diversos outros parmetros para configurar o sistema de segurana de login do R/3. Para maiores informaes pesquise a nota 66533 e a 68048. Outra boa dica a remoo do sap* na tabela usr02. Com isto, e a alterao do parmetro que impede do sap* logar, voce pode utilizar o sap* com a senha pass. A transao SUIM exibe, atravs da SARP ou SU01->information, a lista de todos os usurios bloqueados no sistema e mais uma dezena de relatrios de usurios, profiles e outros relacionados ao tema.
Security
Os clients 000 e 001 possuem os users SAP* (pwd 06071992) e DDIC (pwd 19920706) com, por default, autorizaes SAP_ALL, devendo o administrador alterar suas senhas na instalao. O client 066 utilizado pela SAP para consultoria remota possui o usurio EARLYWATCH (pwd support) que tambm dever ter a sua password alterada. O SAP possui um usurio SAP* com password PASS e autorizao SAP_ALL hard-coded em todos os seus sistemas. Isto significa que quando no existe um usurio SAP* na user master table (USR02) do sistema, este usurio pode ser usado para efetuar logon como SAP_ALL. Por razes de segurana portanto interessante que sempre tenhamos um usurio SAP* definido em cada client. A nota 68048 sugere um parmetro (login/no_automatic_user_sapstar) que quando especificado suprime a possibilidade de utilizao deste SAP* hard-coded. Porm sempre que se for criar um novo client necessrio permitir a existncia desta feature hard-coded para que se possa logar no novo client que no possua nenhum user ainda criado.
Information System e Authorization Traces

O R/3 permite que se check quais verificaes de segurana esto sendo efetuadas em uma determinada execuo de programa atravs de traces, que so ativados atravs do caminho Tools Administration Monitor Traces System trace (veja nota 66056 para detalhes de utilizao) ou transao ST01. O log gravado no diretrio \usr\sap\SID\DVEBMGS00\log\trace*.log.
jluiz@cemig.com.br
Pgina 57
ACADEMIA
BASIS
Para uma analise localizada de falha de segurana pode-se utilizar a transao SU53, que exibe quais authorizations so requeridas em determinada task. A transao SU56 exibe o buffer de autorizao do usurio. Se uma determinada autorizao no est aparecendo, verifique: Se no houve uma manuteno de profile ou activity group enquanto o usurio estava logado. Neste caso necessrio um novo logon Se as autorizaes foram alteradas atravs de um transporte, preciso emitir um reset dos user buffers para que os novos dados sejam carregados (SU01 Environment Mass changes Reset all user buffs) Se o buffer no est muito pequeno. O parmetro auth/auth_number_in_userbuffer define o nmero de entradas reservada nesta rea para cada usurio, devendo ser aumentado se for o caso Ao se criar um usurio pela SU01 deve-se especificar a sua categoria, se Dialog, BDC (batch input), Background (batch jobs) ou CPIC (para conexo remota). Algumas destas categorias tem caractersticas prprias, como dialog ou background, mas servem tambm como informao documentacional.
Password Rules
Existem uma srie de parmetros para configurar o tratamento que o R/3 vai dar a senha do usurio. Alm da lista abaixo ainda podemos fazer uso da tabela USR40, atravs da SM30, para inserir palavras ou seqncias de caracter que no poderam ser utilizadas na senha. As entradas na USR40 podem tambm fazer uso de wildcards como *. Alm disso temos as seguintes regras : Tamanho mnimo da password (login/min_password_lng) com default 3 Primeiro caracter diferente de ! e ? Os tres primeiros caracteres no podem ser o mesmo nem ser iguais a parte do user name No pode ser sap* ou pass Nmero mximo de erros na senha para fechar a sesso (login/fails_to_session_end) com default 3 Nmero mximo de erros na senha para bloqueio da chave (login/fails_to_user_lock) com default 12 Libera os usurios que esto bloqueados por logon incorreto a meia-noite (login/failed_user_auto_unlock) Nmero de dias para que a senha expire (login/password_expiration_time) com default igual a 0, que significa que nunca expira O R/3 tambm j vem preparado (hard coded) para impedir uma srie de outras senhas, a saber :
Profile Generator Setup

Para ativarmos o profile generator devemos seguir alguns passos, a saber : Gerar o enterprise IMG atravs da SPRO, se ningum tiver feito. Provavelmente o time funcional j fez Ativar o profile generator atravs da incluso do parmetro auth/no_check_in_some_cases = Y Desativar a solicitao a todo instante de chance request pelo profile generator atravs da transao OOCR Criar a classe de desenvolvimento utilizando a transao OY08 Criar as cpias das tabelas standard (USOBX e USOBT) que o profile generator necessita para gerar os grupos de atividades, utilizando a transao SU25 Alterar os check indicators e os valores dos campos dos objetos de autorizaes Criar o menu da companhia para o profile generator utilizar
Transporting Authorizations and Users

Devemos sempre ter em mente que os grupos de atividades podem ser transportados mas o cadastro de usurios no. Com isto temos um inconveniente que quando transportamos o grupo de
jluiz@cemig.com.br
Pgina 58
ACADEMIA
BASIS
atividades perdemos o link com os usurios que possuem este grupo no ambiente de destino. Por outro lado, podemos levar todo o cadastro de usurios de um mandante para o outro. Isto pode resolver problemas pontuais mas no resolve o problema da manuteno das profiles que esto na produo e nem do ciclo normal de trabalho com os grupos de atividades. Para transportamos um grupo de atividade, lembre-se ele foi desativado pela transao OOCR, devemos clicar no icone do caminho na transao PFCG para transportarmos um grupo de atividade especifico. Para transportamos um conjunto de grupos de atividades devemos utilizar o programa RHMOVE30 que possui diversas formas de seleo. Aps importarmos a change que foi gerada no ambiente de destino devemos executar a transao SUPC para regerarmos a profile. Neste caso, quando geramos um grupo de atividade que veio do ambiente de desenvolvimento, precisamos atualizar a tabela T77TR (utilizando a SM31) para que o transporte fique configurado para no perder a associao com os usurios no ambiente de destino nos prximos transportes deste grupo de atividades.
SAPRouter
O SAPRouter um componente de software que vem com o R/3 ( no unix um script que pode ser adicionado no startsap e no NT um servio que deve estar ativo) para viabilizar a ligao de duas redes com a garantia de segurana e proteo de acesso em cada uma delas pelo proprio parceiro. Com o SAPRouter voce pode : Controlar e logar as conexes com o sistema R/3 Permitir que outros saprouters tenha acesso a uma rede especfica Proteger o sistema contra conexes e envio de dados de usurios no autorizados Encripitar senhas e outros dados por parceiros certificados pela SAP Controlar o acesso ao servio de OSS da sap Para utilizar o SAPRouter precisamos criar o diretrio saprouter debaixo da arvore \usr\sap; obter a verso mais nova disponvel no OSS e criar a tabela de rotas permitidas no arquivo \usr\sap\saprouter\saprouttab. Esta tabela que contm a definio de quem poder ou no passar de um lado para o outro. Ela um arquivo texto com cinco campos, a saber : Permit/Deny/Secure, endereo de origem, endereo de destino, servio e password. Os endereos podem tanto ser hostnames com ip e neste ultimo caso podemos utilizar tambm os wildcards para selecionarmos uma rede inteira (Ex. 123.45.*). J o servio e a password so opcionais, sendo que o servio assume o defalt de 3299 que a porta padro utilizada normalmente para saprouter. A grande dica na construo da routtab a definio do que proibido no inicio do arquivo e do que permitido no final. Isto necessrio por que a leitura e deciso feita do primeiro para o ultimo. Para especificarmos uma rota para o saprouter devemos utilizar o mesmo padro utilizado no SAPGUI. A nica novidade a chave /W/ para conter uma eventual password a ser passada a um saprouter. Para testar a rota podemos utilizar a dobradinha niping s no host origem e niping c H <host_origem> no host destino ou simplismente niping c H /H/<saprouter>/H/<host_destino>. O saprouter possui uma srie de variaes de parmetros. Elas podem ser obtidas simplismente acionando o saprouter na linha de comando sem parmetros. Algumas delas so importantes como R para dizem onde esta a routtab, -r para startar o servio, -s para parar o servio, -r V3 para selecionar o nvel mais alto de trace, -t para ativar o trace, -T para dizer onde vai ser gravado o arquivo de trace e G para dizer onde ser gravado o arquivo de log.
SNC secure Network communication

A SNC interface permite que o sistema R/3 passe a utilizar algoritmos de criptografia para os dados que iro transitar na rede e para autenticar as senhas de usurios. Normalmente o R/3 no faz criptografia de dados e a senha transita pela rede como caracter. O SNC uma camada na arquitetura R/3 que estabelece um padro de interface para os softwares de segurana e autenticao de usurio disponveis no mercado. Atualmente os softwares certificados pela SAP so o Kerberos 5 do MIT e o Secude 5. Para maiores detalhes veja a nota jluiz@cemig.com.br Pgina 59
ACADEMIA
BASIS
66687. O padro SNC prove trs nveis de segurana, a saber : A autenticao da comunicao entre os parceiros sem a proteo do dados que ser trocado; Integridade que garante a autenticao e mais uma assinatura digital da informao que est trafegando para garantir sua autenticidade; e Confidencialidade que garante a autenticao a integridade e a confidencialidade que o dado no pode ser interpretado por outro que no sejam os parceiros da comunicao. Para ativarmos o SNC temos que definir qual ser o padro de nome dos usurios. Podemos escolher entre X.500 (que distingue o nome pela formao de diversos elementos), nome@dominio (que usa uma concatenao simples do nome do usurio e de seu domnio) e o padro de nome externo do R/3. Alm de definirmos o padro de nomes temos que incluir o parmetro snc/enable = 1 na default profile para ativar efetivamente o SNC. Com isto a SU01 passa a possuir mais uma pasta que contm o nome SNC do usurio. Podemos ainda alimentar a tabela USRACL, que contm o depara, diretamente com o nome interno e o nome externo dos usurios. Para os usurios RFC e CPIC podemos definir apenas um usurio interno para vrios usurios externos atravs da tabela USRACLEXT. Podemos tambm ativar nveis de insegurana para alguns casos. Por exemplo, aceitar sesses no seguras atravs do parmetro snc/accept_insecure_gui =1 ou snc/accept_insecure_cpic = 1. Alm da SU01, outras transaes passam a possuir maiores detalhes sobre o SNC, a saber : SM59 que controla as chaves RFC; a SM54 que controla as chaves CPIC e a SNC0 que controla a lista de acesso entre sistemas R/3. A utilizao do SNC pressupe a instalao de uma dll (secure.dll) junto com o SAPGUI alm do cliente do software de segurana que ser utilizado. Para o saplpd temos que incluir na cliente uma entrada no win.ini que habilita o uso do SNC pelo saplpd e indica a dll que ir interfacear com o produto de segurana. No geral devemos seguir algumas recomendaes para implementar o SNC. A primeira nunca misturar applications que utilizam SNC com outros que no utilizam. A seguinte ter certeza que o produto de segurana est apto a trabalhar com os padres de nomes estabelecidos pelo R/3; E por fim garantir as definies do nvel de proteo desejado, dos parceiros e protocolos que sero implementados, quais conexes sero protegidas e as respectivas portas a serem bloqueadas pelo software de segurana.
jluiz@cemig.com.br
Pgina 60
ACADEMIA
BASIS
Software Logistics
R/3 System, Servers and Instances
Uma instncia R/3 um grupo de servios que so inicializados e parados simultaneamente por um dispatcher, possuindo em comum uma profile de instncia. O nome de uma instncia composto pelos nomes que identificam os servios (Dialog Update (Verburren em alemo) Enqueue Background Message Gateway) por ela executados. Uma central instance contm tipicamente todos os servios R/3 instalados, da o seu nome ser DVEBMGSnn, j uma dialog instance possui o nome Dnn, onde nn o system number utilizado para compor o nmero das portas que efetuaro as chamadas ao dispatcher (32nn) e ao message server (36nn) na camada TCP/IP. Um server pode conter uma ou mais instncias R/3 configuradas. Um PC com o frontend SAPGUI instalado tambm considerado um server da camada presentation na arquitetura R/3. O database server um hardware que possui o RDBMS relacional instalado. comum em R/3 instalarmos o database server no mesmo host que contm a central instance. O conjunto de todos estes servidores com suas respectivas instncias R/3 compem um R/3 System. Um sistema agrega uma nica central instance que aloja o message server e normalmente um ou mais application servers.
R/3 Data
Os dados no R/3 podem ser divididos em duas categorias: Client dependents data, que so os dados pertencentes a apenas um client de um sistema R/3, como por exemplo os master, os transactional, customizing e user master data. Client independent data, que so as informaes pertencentes a todo o sistema, como algumas configuraes ou o repositrio de objetos O dicionrio ABAP um dicionrio de dados que faz parte do repositrio ABAP de um sistema R/3. Seus dados so client independents. Os programas ABAP armazenados no dicionrio so compilados uma vez no primeiro acesso (early binding) e ficam armazenados em um outro repositrio de executveis (tabelas D010*). Cada alterao em um programa fora a sua recompilao no primeiro acesso posterior. Este procedimento denominado late binding possvel atravs de um mecanismo de comparao de timestamp. Este mecanismo de early binding e late binding garante que a integridade das informaes contidas no dicionrio ABAP no afete a performance do sistema, uma vez que os executveis de telas e programas so mantidos atualizados automaticamente em uma rea separada dos respectivos fontes.
R/3 Clients
Um client em R/3 uma unidade independente em termos organizacionais, tcnicos e comerciais. Um client possui seus prprios usurios e seus prprios dados nas tabelas do R/3. Isto permite que um nico sistema R/3 administre vrios clients diferentes, cada um com seus prprios dados. Como a base de dados (consequentemente as tabelas) nica em um sistema R/3 os dados dos diferentes clients ficam armazenados no mesmo local e so diferenciados pelo kernel do R/3. Na prtica o R/3 implementa esta separao atravs de um campo MANDT (de mandante, ou client em alemo) que participa da chave primria das tabelas client dependents do R/3. Em qualquer chamada a estas tabelas o sistema incorpora na clausula WHERE do SQL o campo MANDT = nnn. A nica excesso a tabela T000 que defini quais so os clientes existentes na instncia e uma tabela com definio independente de client. Este campo que identifica um client composto de 3 dgitos nmericos. portanto importante que sempre que efetuamos um logon informemos o nmero do client. Este campo obrigatrio na tela de login inicial do R/3, juntamente com a chave e a password do usurio. Como os dados de clients diferentes funcionam no R/3 como bases de dados diferentes (separao por kernel), as empresas quando desejam implementar uma administrao coorporativa de suas subsidirias, o controle centralizado possvel atravs de uma outra facilidade que o campo configurvel jluiz@cemig.com.br Pgina 61
ACADEMIA
BASIS
denominado company code. Este campo define a menor unidade administrativa com que os relatrios externos podem varrer para uma viso centralizada. O conceito de authorities do R/3 sobre este campo company code permite ainda que uma companhia matriz acesse as suas filiais com finalidades de consultas ou auditoria impedindo que as diversas subordinadas tenham acesso aos dados umas da outras.
Standard Client Roles

recomendado que um ambiente R/3 de uma empresa tenha no mnimo os seguintes clients: Client CUST, como o ambiente central onde o desenvolvimento e as customizaes so efetuadas pelos times funcionais e de abap. Neste client podemos fazer alteraes no ambiente e gerar change request Client QTST, utilizado para o teste de novas customizaes Client PROD, que a produo da empresa Em um ambiente ideal, os seguintes clients adicionais so recomendados: Client SAND, que um sandbox onde novas customizaes so experimentadas antes de efetivamente efetuadas no ambiente CUST. Neste client podemos fazer alteraes mas no podemos gerar change request Client TEST, para teste de customizaes com uma massa reduzida de dados Client TRNG, como um ambiente de treinamento
R/3 Landscape
O conceito de Landscape no R/3 refere-se a um grupo de sistemas R/3 compreendendo normalmente um desenvolvimento, uma qualidade e uma produo que compartilham change requests e rotas de transporte com o propsito de manter um sistema de desenvolvimento e customizao consistente. Por questes de segurana, aconselhado proteger o sistema utilizando o conceito de clients, implementando a segurana atravs do conceito de autorizaes garantindo a separao dos dados entre clients. aconselhvel ainda separar fisicamente os ambientes de implementao do desenvolvimento, qualidade e produo. Alm das questes bvias de segurana e performance do ambiente produtivo, tal implementao protege o sistema evitando que configuraes client independents do ambiente de desenvolvimento sejam implementadas na produo antes de um teste de validade. Uma implementao em dois ambientes tambm no aconselhvel porque todos os objetos transportados para o ambiente de consolidao ficam imediatamente valendo no ambiente de produo. A implementao mais recomendada pela SAP um landscape de trs ambientes que implementam clients e rotas prprias de transporte, consistindo dos 3 clients bsicos e os 3 adicionais: Um host composto de trs clients (SAND, TEST, CUST) onde fica o ambiente de desenvolvimento Um host de quality assurance (com dois clients QTST e TRNG) onde os novos desenvolvimentos so testados antes de serem migrados para o ambiente produtivo Um host para o ambiente de produo com o client PROD Os sistemas R/3 que compem um mesmo landscape devem possuir system IDs diferentes para a correta identificao das rotas de transporte
Change Requests and Transports

O sistema R/3 integra mais de 800 processos de negcio que precisam ser customizados e configurados de acordo com as necessidades de cada empresa para atender e se adequar ao seu ramo de negcio. Atravs de customizaes e desenvolvimentos especficos o sistema R/3 adaptado ao processo de negcio da empresa e estas alteraes precisam ser distribudas entre todos os clients que compem o landscape da empresa, garantindo assim a consistncia do sistema.
jluiz@cemig.com.br
Pgina 62
ACADEMIA
BASIS
Transporte o processo no R/3 que permite a distribuio destas alteraes ao longo do landscape. O R/3 fornece todas as ferramentas necessrias para a criao, documentao e distribuio das alteraes no landscape. A correta configurao do ambiente de transporte fundamental para o sucesso desta administrao: Todas as alteraes devem ser bem documentadas Um nico client recomendvel para todas as customizaes Todo o trabalho de desenvolvimento dever ocorrer em um nico sistema R/3, garantindo uma origem nica de todos os change requests Os desenvolvedores e customizadores devero ter profiles de autorizaes de acordo com suas necessidades de criao e release de change requests O CTS (Change and Transport System) uma facilidade introduzida pela SAP no release 4.0 do R/3 e composta das seguintes ferramentas: CTO, Change and Transport Organizer que prov funes para gerenciar o desenvolvimento de projetos que ocorram centralizados ou distribudos no ambiente. Ele composto das seguintes ferramentas: Workbench organizer (transao SE09), Customizing organizer (SE10) e Transport organizer (SE01) TMS, Transport Management System que organiza, monitora e executa os transporte ao longo de um landscape definido. O TMS utilizado ainda para as rotas de transporte ao longo do landscape e acionado pela transao STMS Ferramentas a nvel do sistema operacional (TP e R3Trans) que executam a comunicao com o sistema R/3, o banco de dados e os arquivos gerados no processo de export dos transportes
jluiz@cemig.com.br
Pgina 63
ACADEMIA
BASIS
Change and Transport System Prerequisites

Configuring the System Landscape
Antes de iniciar a instalao de um sistema R/3, defina a estrutura de rede necessria para comportar o ambiente. Inicie a instalao pelo ambiente de desenvolvimento. nele normalmente que residir o Transport Management System. Durante a instalao do sistema defina um diretrio para o transport system. Este diretrio ser posteriormente compartilhado pelos demais ambientes que comporo o landscape. Aps a instalao do R/3, configure o arquivo TPPARAM que parametriza o sistema de transporte (informando qual o banco de dados e a onde ele est), inicialize o Change Transport Organizer (CTO) utilizando a transao SE06 e configure o system landscape utilizando o Transport Management System (transao STMS). As change requests que permitem sincronizar as customizaes e desenvolvimentos entre os sistemas R/3 fluem no landscape atravs de rotas pr definidas em um nico sentido. So as denominadas transport routes. O sistema de transporte utiliza um diretrio prprio para onde os change requests liberados so exportados da base de dados. Neste diretrio o sistema armazena alm de data files, arquivos de comandos e logs de transporte. Fisicamente em um landscape de trs sistemas, o transporte de um change request ocorre em trs etapas: Todos os objetos encapsulados em um change request que liberado (released) so exportados da base de dados do sistema fonte para o diretrio de transporte Em um segundo passo, os objetos sero importados do diretrio de transporte para a base de dados do ambiente de quality assurance. Finalmente aps o teste e verificao das alteraes, os objetos so importados para a base de dados do ambiente de produo (deliverya system) definido O diretrio de transporte (\usr\sap\trans) e todos os seus subdiretrios so exportados pelo ambiente onde foi originalmente definido (normalmente o desenvolvimento) e montado via NFS nos demais hosts dos sistemas que compem o landscape. Este compartilhamento de uma rea nica pr requisito para o correto funcionamento do sistema de transporte. No ambiente NT o diretrio exportado pelo compartilhamento sapmnt e montado nos outros hosts como um disco e acessado por \\hostdev\sapmnt\trans que deve ser setado no parmetro DIRTRANS. A configurao deste parmetro necessrio pois o diretrio \usr\sap\trans existe em todas as mquinas mas devemos utilizar uma rea nica para todo o landscape. Para maiores detalhes sobre sistemas heterogeneous veja a nota 83327. O arquivo TPPARAM contm informaes que parametrizam o funcionamento do programa de transporte, o tp. O TPPARAM reside no subdiretrio bin do transport directory e deve ser configurado aps a primeira instalao a partir do arquivo template fornecido durante a instalao. A cada novo sistema introduzido posteriormente no landscape, este arquivo precisa ser editado para incorporar os parmetros dbname e dbhost e transdir do novo ambiente. Para o parmetro transdir, e outros relacionados a diretrios, sempre utilize o nome da mquina e o respectivo compartilhamento (Ex. \\host\sapmnt\trans). Para checar se o programa tp est disponvel em todos os ambientes do landscape, utilize o comando R/3 system -> Check -> Transport tool. possvel ainda testar todo o diretrio de transporte atravs do check de transport directory. Para consultar os parmetros definidos no arquivo TPPARAM, utilize o caminho de menu Goto -> TP parameter. Na verso 4.0b temos alguns problemas com os mecanismos de transporte pois o conjunto do STMS ainda no est finalizado (j est mais bem acabado na verso 4.6). O primeiro problema a seqncia de importao das changes request: ele sempre segue a seqncia de export, ou seja, uma vez exportada o usurio no vai conseguir alterar a seqncia para uma seqncia mais lgica. O segundo problema que uma change que foi importada no sistema de qualidade j pode ser importada no ambiente produtivo independente se ela j foi verificada e confirmada pelo desenvolvedor. Podemos criar um mecanismo para tentar minimizar erros onde o diretrio \usr\sap\trans do ambiente produtivo seria separado. Com isto o analista basis passa a ter que
jluiz@cemig.com.br
Pgina 64
ACADEMIA
BASIS
controlar as changes que devem ser importadas na produo atravs da manipulao do arquivo de buffer por um editor de texto. Desta forma passamos a in foreign group import no sistema R/3.
Initializing CTO
A transao SE06 utilizada para configurar o change and transport organizer. Ela deve ser executada uma vez a cada nova instalao de um sistema R/3, independentemente de ser uma instalao standard ou um database copy. Estas configuraes so globais no sistema R/3 e tem prioridade inclusive sobre as configuraes dos clients (SCC4). A transao SE06 estabelece o valor inicial para os change request e configura as opes iniciais do sistema definindo se o repositrio de objetos e os objetos de customizao client independents sero globalmente modificveis. Para os ambientes de produo e de qualidade no faz sentido permitir modificaes no sistema. J no sistema de desenvolvimento tudo pode ser permitido. Eventualmente podemos bloquear os objetos locais para garantir que o time de abap no vai criar objetos sem encapsula-los em change requests.
TMS - transport managementa system

Atravs da transao STMS possvel definir as regras de transporte no landscape e os respectivos papis de cada um dos sistemas R/3, definindo assim a estratgia de transporte baseadas em rotas pr definidas. As rotas podem ser definidas de forma grfica ou no editor hierrquico da STMS, onde possvel ainda visualizar as filas de transporte e importar objetos.
Transport Domain
Um transport domain compreende todos os sistemas R/3 administrados centralizadamente atravs do TMS. Quando se configura uma definio no TMS, o sistema cuida de distribuir via RFC a definio entre todos os sistemas que compem o domnio. Isto garante que as configuraes de transporte sejam consistentes em todos os sistemas pois todas as configuraes so feitas apenas no Domain Controler (sistema R/3 que ira controlar todos os outros sistemas R/3 do landscape). Por segurana podemos eleger um backup domain controler que entra em ao se o domain controler sair do ar. Este switch feito na mo e depois deve ser desfeito quando o domain controler estiver de volta. A SAP sugere que o Domain Controler seja o sistema R/3 dedicado a qualidade pois ele o que tem o menor volume de trabalho. Na prtica o Domain Controler o sistema R/3 de desenvolvimento pois ela normalmente a primeira a ser instalada. O TMS suporta vrios diretrios de transporte em um transport domain. Os sistemas R/3 que compartilham um mesmo diretrio compem um transport group. Atravs do TMS podemos executar transportes entre sistemas que pertenam a transport groups distintos mas ela no suportam transportes entre domnios diferentes. Devemos lembrar que se fizermos o tp import entre domnios diferentes o processo ser bem sucedido. O mesmo no pode ser garantido entre sistemas R/3 de verses diferentes pois podem existir diferenas na estrutura e na utilizao nos objetos encapsulados pela change. O Landscape pode ser definido como todos os sistemas R/3 que compartilham change requests com o propsito de manter ambientes consistentes de desenvolvimento e customizao. Por este motivo um system landscape normalmente sinnimo de um transport domain, embora um transport domain possa conter mais de um system landscape apenas para fazer uso da vantagem de um ambiente TMS centralizado. A configurao do TMS executada atravs da transao STMS no client 000 e com o usurio DDIC, ou um equivalente com a profile S_CTS_ADMIN, e passa pelos seguintes passos: Configurao do transport domain atravs da especificao dos sistemas R/3 e dos transport groups alm da definio de um deles como sendo o controlador do domnio. Configurao das rotas de transporte atravs da definio do sistema onde as changes sero consolidadas e do sistema onde a change ser finalmente delivered aps os testes Check e verificao das configuraes atravs das ferramentas do TMS
jluiz@cemig.com.br
Pgina 65
ACADEMIA
BASIS
O sistema escolhido como controlador do domnio dever ser um sistema com alto grau de segurana e disponibilidade, normalmente o production system ou o QAS. Esta tarefa no oferece nenhuma carga adicional ao sistema mas a SAP sugere que seja instalado no QAS que supostamente o sistema R/3 com menor carga de trabalho. A transao STMS, no momento da configurao inicial, ir criar um transport domain (DOMAIN_<SID>), um transport group (GROUP_<SID>), user CPIC no client 000 (user TMSADM para acesso de leitura), os destinos RFC requeridos pelo TMS (tmsADM@ para leitura e tmsSUP@ para leitura/gravao) e um arquivo DOMAIN.CFG no subdiretrio bin do diretrio de transporte que conter a configurao do TMS. recomendado que se tenha um servidor configurado como backup controler para o TMS, em caso de falha do principal. Como comum, no momento da configurao do TMS nem todos os sistemas existem, o R/3 permite que se defina todo o ambiente atravs da especificao de sistemas virtuais, permitindo com isto que se configure antecipadamente todas as rotas de transporte. A SAP prov o TMS com configuraes standard default que j prove rotas para landscape de um, dois ou trs sistemas, agilizando desta forma o trabalho de configurao inicial. As rotas de transporte so de dois tipos: de consolidao, do desenvolvimento (integration system) para o sistema de quality assurance (consolidation system) atravs de uma transporte layer (Z<SID>), e de delivery, onde os transportes consolidados so finalmente transportados do sistema de qualidade (consolidation system) para a produo (delivery system). Aps configurar o transport domain e definir as rotas de transporte, o TMS utilizado para distribuir esta configurao entre os sistemas e ativar a nova configurao. As alteraes efetuadas em objetos SAP so transportadas atravs da consolidation route SAP. Atravs do hierarchical list editor possvel visualizar e editar a configurao do TMS. O sistema aceita ainda a configurao atravs de ferramenta grfica drag-and-drop. O TMS prov ainda ferramentas para testar as conexes RFC, checar o diretrio de transporte e verificar o funcionamento do programa tp.
jluiz@cemig.com.br
Pgina 66
ACADEMIA
BASIS
Change Management for Development

Change Requests
As alteraes no software R/3 podem ser divididas em cinco categorias: Customizing: a configurao dos processos de negcio e funes de menu atravs do IMG Personalization: so as mudanas globais das caractersticas das telas e definio de valores default para determinados campos (SM3) Modification: so mudanas efetuadas pelo cliente no repositrio de objetos do R/3 (os SAP objects). estas alteraes precisam ser cuidadosamente avaliadas quando do upgrade de verses do sistema. A partir do release 4.5A a SAP introduziu o Modification Assistent para auxiliar a gerenciar e automatizar estas mudanas Enhancement: criao pelo cliente de objetos no repositrio que so referenciados pelos objetos standard do R/3 atravs de user exits. Estes desenvolvimentos so os ideais por reduzirem as necessidades de modification adjustments durante o processo de upgrade Customer Development: criao pelo cliente de objetos no repositrio atravs do ABAP Workbench (programas, etc.) Uma change request um pacote contendo os objetos que sero transportados de um sistema R/3 para outro. Por exemplo, no caso de um abap ser encapsulado o source, no caso de uma configurao ser encapsulado as entradas nas tabela e sua respectiva ao (cria/deleta/altera). Uma change request pode ser atribuida a vrios usurios atravs do conceito de tarefa. Apesar do nome tarefa ela no representa o que vai ser feito, ela representa a associao da change request com o usurio e a respectiva documentao (que no obrigatoria) do que foi feito. Todas as alteraes efetuadas nos objetos do repositrio so criadas e mantidas atravs do ABAP Workbench e gravadas em change requests. As demais alteraes de customizing e personalizations so criadas e mantidas pelas ferramentas de business engineer e tambm gravadas em change requests. Estes mecanismos permitem que estas alteraes sejam posteriormente propagadas pelo landscape para consistncia do ambiente. O workbench organizer oferece mecanismos que permite que os change requests sejam documentados atravs de uma descrio do seu propsito. Os change requests devem ser criados por gerentes de projeto que associam os objetos do repositrio que sero trabalhados, onde permanecem lockados com acesso permitido apenas aos desenvolvedores que foram autorizados ao change. As alteraes nos objetos do repositrio so criadas como tasks associadas ao change request e quando liberadas so transferidas como um todo atravs das rotas que definem o landscape, j que a unidade de transporte o change request. A liberao de um change request faz com que uma nova verso dos objetos nele contidos seja gravado no database de verses (somente no sistema R/3 que foi utilizado para o desenvolvimento).
WBO - workbench organizer

O Workbench Organizer (transao SE09) permite gerar, gerenciar e liberar as tasks e os change requests. Os change requests podem ser pesquisados por vrios critrios, tais como desenvolvedor, status, tipo do request ou ainda por data. O frame Global Information da tela SE09 d uma viso grfica do status dos change requests transportados e repairs. O Workbench Organizer exibe os change requests de um determinado usurio atravs de uma estrutura em rvore que permite a visualizao hierarquizada da estrutura. Esta rvore organizada entre change requests com status Transportable (que poder ser transportada para outro sistema), Local (no poder ser transportada) e Unclassified. (No confunda uma local change request com local object. Um local object est preso a development class $tmp e nunca poder ser transportado. No caso de um objeto, com uma development class vlida, associado a uma change request local significa que esta change no ser transportada mas eventualmente em outra change o objeto pode ser transportado).
jluiz@cemig.com.br
Pgina 67
ACADEMIA
BASIS
Quando o lder de um projeto cria um change request, o sistema associa a ele um nmero (<SID>K9nnnnn como por exemplo DEVK900736) e ao associar os desenvolvedores, cada um recebe uma task cujo cdigo estruturado no mesmo critrio. A medida que os desenvolvedores vo terminando suas tasks elas vo sendo liberadas individualmente. Quando todas estiverem liberados o gerente do projeto libera o change request que pode ento ser transportado para outros sistemas. As autorizaes do Change Management so usualmente gerenciadas em quatro grupos distintos e com abrangncia crescente na lista abaixo : S_CTS_SHOW, que permite apenas visualizar os change requests e ver suas logs S_CTS_DEVELO, mais abrangente que a anterior, fornecida aos desenvolvedores que passam a ter gerencia sobre suas tasks S_CTS_PROJECT, que a autorizao dos gerentes de projeto, que podem criar e gerenciar os change requests S_CTS_ADMIN, a autorizao do administrador do CTS e tem acesso mais abrangente a todas as suas ferramentas Para o dia-a-dia do projeto utilizaremos esta lista abaixo de profiles para os principais papeis a serem desempenhado durante o projeto : S_A.SYSTEM, normalmente utilizada pelos administradores do sistemas e inclui todas as autorizaes relativas ao CTS e STMS. Esta profile contm a autorizao s_cts_admin S_A.CUSTOMIZ, normalmente utilizada pelo lider da equipe e inclui autorizao para todas as atividades de configurao do ambiente. Esta profile contm a autorizao s_cts_project S_A.DEVELOP, normalmente utilizada para os abapers e configuradores e no permite a criao de change request. Esta profile contm a autorizao s_cts_develo S_A.SHOW, este perfil utilizado como curinga pois ele possui todas as autorizaes de basis mas todas elas somente para display. Esta profile contm a autorizao s_cts_show Todos os desenvolvedores ABAP precisam ter um registro composto de 20 dgitos obtido junto ao OSS e denominado SSCR, SAP Software Change Registration. Sem esta chave no possvel efetuar alteraes no repositrio de objetos. Cada access key associada com o logon ID do desenvolvedor e ao license number do sistema R/3. Esta chave requisitada no primeiro acesso ao repositrio e no mais requisitada nos acessos posteriores. Os objetos criados pelos desenvolvedores no repositrio devero sempre comear com Z ou Y, que o range reservado pela SAP para os objetos dos clientes, evitando assim conflito de nomes com objetos standard do repositrio. A nota 16466 descreve em detalhes a nomenclatura a ser adotada na criao dos nomes. Da mesma forma que temos que registrar um desenvolvedor, temos que registrar no SSCR a modifio em um determinado objeto standard. O conceito de name ranges permite que se adote critrios de nomenclatura associados a classes de desenvolvimento. A SAP adota ainda o critrio de reservar namespaces para objetos desenvolvidos pelos seus parceiros de desenvolvimento. O comportamento do repositrio no que diz respeito aos namespaces e name ranges determinado em cada sistema R/3 atravs de global settings que determinam se os critrios sero modificveis ou no. Escolha a opo Tools -> Administration -> Transports -> Installation follow-up work -> Goto -> System change options. Para manter estes name rangers use a view v_tresn atravs da transao sm30.
Development Class and Transport Layers

Todos os objetos do repositrio so associados a development classes que provm um agrupamento lgico de objetos que coordenam os esforos de desenvolvimento. Development classes no SAP devero comear com Z, Y, $ ou T. $ define development classes para objetos temporrios que no sero transportados e T development classes para objetos locais. Quando associamos transport layers a development classes, todos os objetos pertencentes ao determinado development class tero a mesma rota de consolidao pr definida pela transport layer. Os objetos SAP pertencem a uma transport layer pr instalada denominada SAP. Para definirmos a development classes podemos utilizar o repository browser (transao SE80) ou simplesmente utilizar a SM30 para manter a view V_TDEVC. Se for necessrio podemos manter a view v_tresn para associar os namespaces com as development classes. Esta associao de development classes e transport layers utilizada para definir as rotas de transporte de consolidao que podem ser gerenciadas atravs do TMS. Objetos que no possuem jluiz@cemig.com.br Pgina 68
ACADEMIA
BASIS
esta associao ou no possuem transport layers configurados no podero ser transportados atravs desta ferramenta.
Handling Repository Objects

O sistema possui dois mecanismos de lock para proteo dos objetos do repositrio. No primeiro mecanismo baseado na gerencia do change request que garante que os objetos nele contidos somente sejam alterados pelos usurios autorizados pelo gerente do change request que consequentemente estejam trabalhando no projeto. Um segundo mecanismo no editor de programa no permite que dois desenvolvedores abram o mesmo objeto simultaneamente pois quando o primeiro desenvolvedor pegar o objeto o lock permanecer at o release da task. Objetos que tenham sido associados manualmente ao change request no so lockados pelo sistema, mas podem ter lock explcito tanto para a change quanto para a task atravs da SE09 ao selecionar Request/task -> Object list -> Lock objects Uma task s pode ser liberada pelo correspondente desenvolvedor associado a ele ou pelo dono da change. J a change s pode ser liberada pelo seu dono e aps todas as task terem sido liberadas. Ao trmino das tasks e liberao do change request (release), as alteraes ficam disponveis para transporte (se a change for do tipo transportable). Este processo somente poder ser executado pelo owner do change request e tenha as autorizaes corretas. Tasks liberadas no podem mais ser alteradas porm tasks adicionais podero ser criadas para corrigir eventuais problemas. Tasks vazias no podem ser deletadas mas so automaticamente eliminadas quando se libera o change request. O processo de release do change request grava uma nova verso dos objetos no repositrio e exporta as alteraes para arquivos no sistema operacional (diretrio de transporte). Change requests locais quando liberados gravam novas verses no repositrio porm no geram arquivos no sistema operacional, no sendo portanto transportveis. As verses dos objetos geradas quando da liberao dos change requests ficam armazenadas no version database, que reside no sistema de desenvolvimento. Os objetos ativos ou suas verses temporrias (sob manuteno) residem em outro local, no development database. As verses dos objetos podem ser comparadas ou restauradas atravs de ferramentas do sistema, seja pela SE80 ou pela SE09. O nico sistema que contm o histrico de todas as verses o sistema de desenvolvimento. Na produo no teremos este histrico o que significa se perdermos o sistema de desenvolvimento perderemos toda a histria da evoluo dos abaps. Quando um change request liberado o sistema exporta seus dados para o sistema operacional e este processo pode ser acompanhado atravs da SE09 que exibe o return code da operao e uma log do export para possvel anlise. A lgica do nome do arquivo de log do export <SID>E9xxxxx. Tambm produzido uma log do test import no sistema de consolidao seguindo o padro <SID>P9xxxxx para o nome do arquivo. Ento, a partir do release da change request, ela passa a ser apenas um retrato da histria.
The Repository
O Object Directory um catlogo de todos os objetos standard SAP e dos objetos desenvolvidos pelo usurio na sua instalao e pode ser acessado pela SM30 tabela TADIR. Durante o processo de customizing o sistema pode gerar automaticamente objetos dentro do repositrio como parte do processo. Objetos que so alterados fora do seu ponto de origem, por exemplo a alterao no ambiente de QAS de um objeto originrio do sistema de desenvolvimento denominado um repair. Os objetos do repositrio possuem como chave primria o program identification (PGMID), o object type e o object name. O campo PGMID normalmente R3TR, embora existam outros ids: R3OB e LIMU. Object types podem ser por exemplo PROG (ABAPs), DEVC (development class), VIEW, FORM, COMM (command file) e CHD0 (change document). O sistema R/3 trabalha com o conceito de objetos originais e cpias. Um objeto criado no ambiente de desenvolvimento e transportado para os demais ambientes do landscape possuir nestes locais apenas uma cpia do objeto original. Este mecanismo garante que os objetos sejam alterados apenas nos locais onde foram criados. Excepcionalmente possvel alterar uma cpia jluiz@cemig.com.br Pgina 69
ACADEMIA
BASIS
de um objeto, que neste caso denominado de um repair, ou seja: uma alterao executada em um ambiente diferente daquele onde o objeto foi desenvolvido. Diferentemente dos developments e corrections, que so manutenes de objetos originais, os repairs quando associados a tasks de um change request no permitem que outros desenvolvedores do mesmo time tenham acesso ao objeto, mas que so, assim como os objetos das demais tasks, protegidos por mecanismo de lock. Quando um repair liberado o sistema requisita uma confirmao que retira o lock de proteo do objeto e permite que o mesmo seja posteriormente sobrescrito por transportes futuros. Repairs liberados sem confirmao podem entretanto ser confirmados a posteriori atravs da opo Request/task -> Confirm repair Diferentemente das alteraes e desenvolvimentos de objetos criados pelo usurio, Modifications so na realidade repairs executados em nossa instalao sobre as cpias dos objetos originais SAP. Estes objetos para serem alterados ser necessrio informar um access key (obtido no OSS) que associado ao objeto em uma determinada instalao. Este procedimento de registro fica gravado na SAP que uma determinada instalao efetuou alteraes sobre objetos standard SAP. Uma vez definido o access key, o objeto associado a uma task do change request como um repair, sendo tratado como tal da para a frente. Nem todos os objetos SAP do repositrio so controlados por este mecanismo rgido de SSCR (access key): matchcodes, database indexes, buffer settings, customer objects, precorrections e objetos gerados pelo customizing. Este mecanismo vai permitir que a SAP procure inicialmente por alteraes introduzidas pelo usurio no seu ambiente diferenciando potenciais erros de programa de manutenes indevidas de objetos, alm do que o registro facilita os processos de upgrade de verses
R/3 Upgrade
Quando de um upgrade, objetos originais SAP so reintroduzidos na instalao o que fora a uma anlise obrigatria dos objetos que sofreram repairs para que as antigas alteraes sejam confirmadas e refeitas quando necessrio. Para isto importante uma documentao detalhada destas modifications e a deciso de que se vale a pena o esforo para reintroduzir as alteraes que muito possivelmente j esto incorporadas no novo release Durante a fase de PREPARE do processo de upgrade, o sistema pede que todos os repairs sejam confirmados e liberados. A transao SPDD dever ser utilizada para ajustar o dicionrio ABAP durante o processo de upgrade. A transao SPAU utilizada para efetuar um merge de todos os objetos do repositrio
Workbench Organizer Tools

O Workbench Organizer possui uma srie de ferramentas que facilitam as tarefas administrativas, podendo ser acessadas atravs da opo Goto -> Tools: Verificar relatrios, como por exemplo o Object in requests que oferece informaes detalhadas sobre os change requests Modification monitor que prov informaes dos objetos que esto sendo alterados Object directory que permite alterar os atributos dos objetos na tabela TADIR Alterar namespaces Ativar ou desativar o check de objetos e ainda setar as change system options A opo Search for objects in request/tasks permite encontrar um relacionamentos cruzados com tasks/change requests a partir de um determinado objeto desejado.
Settings for WBO

O workbench organizer possui uma facilidade para verificao das logs de transportes e para verificao dos objetos incluidos nas change requests. Isto pode ser feito para todo o sistema ou especificamente para um usurio. Quem controla isso so os object checks que permitem verificar a integridade (normalmente syntax check) das alteraes efetuadas pelo change request antes que ele seja liberado e exportado para files do sistema operacional. Eles permitem tambm que sempre que for feito uma operao de import/export o usurio recebe uma mensagem no prximo logon.
jluiz@cemig.com.br
Pgina 70
ACADEMIA
BASIS
Para configurar este recurso para todo o sistema utilize a transao SE01 -> settings -> organizer e para configurar este recurso para um usurio especifico use a SE03 -> global customizing workbench organizer.
Planning Change Management

Um sistema R/3 necessita de uma soluo de procedimento para controlar o processo de alterao e propagao destas alteraes por todo o landscape. Para isto no podemos esquecer de algumas coisas que so muito importantes como : Restringir as alteraes no repositrio do R/3 atravs de uma poltica bem definida de autorizaes, pela proteo dos clients atravs da especificao correta de seus change options (SCC4) e ainda centralizando todo o desenvolvimento em um nico sistema R/3. A definio de times de projetos bem definidos com a especificao de um lder responsvel que deve organizar o mecanismo de gerncia de tasks e change requests e controlar a qualidade do processo dos desenvolvedores. A definio de padres de desenvolvimentos, seja atravs da especificao de classes de desenvolvimento, da padronizao e cobrana de uma correta documentao e a manuteno de verses para simplificar os futuros esforos de upgrade do sistema R/3 ou da aplicao de correes via Hot Packages
jluiz@cemig.com.br
Pgina 71
ACADEMIA
BASIS
Change Management for Customizing

Customizing Concepts
Customizing o processo de parametrizao do R/3 de acordo com o processo de negcio que atende a empresa que o est implantando. Esta parametrizao realizada nas transaes de negcio e provocaro alterao no comportamento do sistema para atendero a uma empresa especfica. Apesar de podemos implementar alguns mdulos e no implementar outros temos que ter em mente que temos que fazer, eventualmente, configuraes em todos os mdulos. A maioria das customizaes so client dependents e afetam portanto apenas um determinado client. Existem entretanto algumas customizaes como por exemplo as pricing conditions que so client independents. As atividades de customizao basicamente criam ou alteram entradas em views da base de dados. Views so vises pr definidas que podem agregar uma ou mais tabelas em tabelas virtuais e so facilidades implementadas pelos RDBMS. Estas entradas que provocam a alterao do comportamento dos programas abap. claro que s podemos configurar o comportamento se ele tiver sido planejado e implementado no standard do R/3.
Customizing Tools Implementation Guide (IMG)

A SAP prov diferentes ferramentas para a implementao das customizaes e para o desenvolvimento no R/3. Comparativamente: Workbench Organizer (SE09) utilizado pelos desenvolvedores ABAP para criar e gerenciar seus change requests do tipo SYST que podem ser liberados para transporte no landscape. Customizing Organizer (SE10) a transao utilizada pelos customizadores para criar e gerenciar seus change requests do tipo CUST SYST que podem ser liberados para transporte no landscape. Esta ferramenta mais ampla que a SE09 pois ela pode englobar as change requests dos dois tipos. ABAP Development Workbench (SE38) utilizado pelos desenvolvedores para acessar as ferramentas necessrias para todo o ciclo de desenvolvimento de enhancements, modifications e developments. Outra boa ferramenta que pode ser utilizada ao invs desta a SE80 (Repository browser) Implementation Guide ou IMG (SPRO) a transao da principal ferramenta de customizao disponvel no R/3, onde apresentada uma lista hierrquica dos passos que devero ser implementados no processo de customizao e implantao de um sistema R/3. Enquanto um processo tpico de desenvolvimento requer a alterao e criao de objetos no dicionrio, um processo de customizao implementado pela entrada e alterao de valores em campos de tabelas do R/3. Os dois processos geram change requests, porm de categorias diferentes (SYST e CUST respectivamente). Tecnicamente o processo de desenvolvimento mais complexo que o de customizao, j que existe a necessidade de um gerenciamento mais rgido atravs do registro de desenvolvedores no SSCR, do conceito de version dos objetos e da utilizao de classes de desenvolvimento. O R/3 disponibilizado com o set completo das atividades de customizao para todos os seus mdulos no IMG, denominado SAP Reference IMG. Os clientes definem os mdulos que sero implementados na empresa bem como as funes especficas que sero utilizadas dentro destes mdulos, com isto teremos o Enterprise IMG. Todas as transaes de customizao relevantes, documentao necessria e informaes para gerenciamento dos projetos so definidos dentro do IMG atravs de subsets conhecidos como Project IMGs. Estes projects so levantados a partir das definies iniciais de implementao do cliente. O IMG e seus respectivos projects so definies client independents em um sistema R/3. O IMG no apenas uma ferramenta de implementao da customizao no R/3. Atravs documentaes, conceitos e gerenciamento de projetos o IMG a metodologia para customizao do R/3. A implementao incorpora as seguintes partes: acesso as Activities de implementao executado atravs de transaes prprias
jluiz@cemig.com.br
Pgina 72
ACADEMIA

BASIS
IMG Description descreve os conceitos, recomendaes, requerimentos e as atividades necessrias para executar as tarefas Project Management permite o acompanhamento do processo atravs do controle de status, scheduling e gerncia dos recursos Project Documentation para a documentao de todo o processo
Customizing Change Requests

As customizaes executadas no IMG podem ser gravadas em change requests o que permite distribuir posteriormente um processo centralizado de customizao para os demais clients e sistemas do landscape. Durante o processo de customizao, o client pode ser configurado para requisitar ao customizador um change request para onde todas as alteraes sero gravadas automaticamente para posterior transporte. Quando esta opo est desligada, as configuraes executadas so gravadas no R/3 porm no so gravadas em change requests. Alm dos controles globais de changes que os sistemas R/3 possuem implementados e configurados atravs da SE09, os chamados global settings, um sistema R/3 possui a facilidade de se configurar individualmente seus clients atravs da especificao detalhada de seus atributos client dependents e independents. A transao de criao e definio de clients (SCC4) permite a definio de dois subsets de atributos que so gravados na tabela T000 e fornece a diretriz maior para o funcionamento dos clients. No subset das client dependents, as change options determinam e protegem o sistema das customizaes client dependents: 1. Changes without automatic recording, permite customizaes client dependents mas no as inclui em change requests. Se desejado pelo customizador, as alteraes devero ser includas manualmente em change requests para posterior transport 2. Automatic recording of changes, permite customizaes nas tabelas que so automaticamente gravadas em change requests 3. No changes allowed, bloqueia as customizaes no client 4. No transport allowed, permite as alteraes nas tabelas mas impede que as changes sejam transportadas, seja manual ou automaticamente No subset das client independents, as change options protegem o repositrio e as customizaes client dependents: A. Changes to repository and client-independent, permite o desenvolvimento e customizaes client independents B. No changes to client-independent customizing objects, permite desenvolvimento mas bloqueia as customizaes client independents C. No changes to repository objects, bloqueia o desenvolvimento mas permite as customizaes client independents D. No changes to repository and client-independent custom. obj., impede o desenvolvimento e customizaes client independents A combinao destas opes permite que se configure diversos perfis de clients em uma instalao R/3: 3.D. para um client de produo 2.B. para um client de desenvolvimento ABAP 2.C. para um client de customizao 2.A. para um client de desenvolvimento ABAP e customizao 3.D. para um client de teste 4.D. para um client sandbox Quando a opo de automatic recording no est ligada, as customizaes podero ser gravadas manualmente no change request. Ao entrar na transao de customizao deve-se usar a opo de menu (Table/view -> Transport) para fornecer o change request. Aps selecionar todas as entradas de customizao que desejam inclur, click em Include in Transport e depois basta salvar a alterao e sair do IMG. O processo de liberao de um change request de customizing pela SE10 pode ser efetuado de duas maneiras distintas: no primeiro mtodo (release and export) a change liberada e seus dados transferidos para os files do diretrio de transporte. No segundo mtodo (release to request) a change
jluiz@cemig.com.br
Pgina 73
ACADEMIA
BASIS
liberada porm seus dados so transferidos para um outro change request transportvel porm seus dados no so transportados para o OS.
Customizing Tests
Antes de distribuir as customizaes, elas devero ser testadas em separado e dentro do contexto do sistema, em um client de consolidao. preciso abrir o change request e verificar se o seu contedo est completo com todas as alteraes. A transao SCC1 utilizada para transferir as alteraes contidas em um change request ou mesmo em uma task individual para outro client do sistema. No caso de ser necessrio levar objetos que esto apenas nas task o flag Incl tasks for request deve estar marcado. Como apenas um change request pode ser transferido por vez, as change podem ser agrupadas em um nico change atravs da opo Include Objects da SE10, o que poupar tempo do administrador. IMPORTANTE: a opo de cpia atravs da SCC1 somente funciona para dados client dependents. Se a change contiver objetos client independents os mesmos no sero transportados. A transao SCC1 deve ser sempre acionada no client de destino.
Customizing Exceptions
Certos tipos de customizaes, conhecidas como Data-only Customizing Changes, precisam ser executadas diretamente no ambiente de produo sem passar por processo de change request, como por exemplo: taxas de cmbio, regras de penso, etc. Estes tipos de alteraes no tem efeito sobre o negcio da empresa no necessitando portanto de testes extensivos em ambiente separado. Como so passveis de alteraes constantes e para evitar necessidades de controle por change requests, a SAP introduziu o conceito de funes de Update Settings. Os Update Settings podem ser utilizados diretamente no ambiente de produo sem impacto para o negcio da empresa. A tabela CUSAMEN mantm a lista dos objetos aprovados pela SAP para esta funcionalidade. No se recomenda que o cliente faa alteraes nesta tabela sem a autorizao expressa da SAP.
Client-independent Customizing
Uma tarefa difcil no proceso de customizao do R/3 identificar quais tasks so client independents e quais so dependents. Customizaes client independents podem ser: Em objetos client independents, que so objetos do repositrio gerados pelo processo de customizao, como por exemplo matchcodes, condition tables e hierarquias. Para garantir que sejam corretamente transportados, devero ser associados a uma development class Global customizings, que so configuraes standard globais do ambiente em tabelas que no possuem o campo MANDT, como por exemplo calendrios, impressoras, etc. Enquanto customizaes client dependents so gravadas em change requests da SE10, as customizaes client independents precisam ser associadas a change requests do workbench organizer (SE09). Uma boa forma de descobrir se a configurao dependent ou independent ou transportada automaticamente, manualmente ou no transportada utilize a SPRO -> IMG -> Information -> Title and IMG info.
Planning Customizing Change Management

importante restringir as alteraes no Enterprise IMG atravs de uma poltica bem definida de autorizaes, pela proteo dos clients atravs da especificao correta de seus change options (SCC4) e ainda centralizando todo o desenvolvimento (abap e customizaes) em um nico client. A definio de times de projetos bem definidos com a especificao de um lder responsvel organiza o mecanismo de gerncia de tasks e change requests
jluiz@cemig.com.br
Pgina 74
ACADEMIA
BASIS
A definio de padres de desenvolvimentos seja atravs da especificao de classes de desenvolvimento ou da padronizao e cobrana de uma correta documentao e a manuteno de verses simplifica os futuros esforos de upgrade do sistema R/3 ou da aplicao de correes via Hot Packages
jluiz@cemig.com.br
Pgina 75
ACADEMIA
BASIS
Transport Management
Transport Process
O TMS a ferramenta existente no R/3 onde esto centralizados todos os recursos para efetuar e gerenciar os transportes no ambiente. At o release 3.1H os transportes eram efetuados atravs de ferramentas no sistema operacional e baseava-se nas configuraes das tabelas TSYST, TWSYS, TASYS e DEVL principalmente. O primeiro passo no processo de transporte o release dos change requests que so exportados para files do diretrio comum de transporte (\\hostgroup\sapmnt\trans). Para cada change liberado, arquivos so gerados nos subdiretrios data (dados exportados) e cofiles (control files). Este diretrio de transporte tambm possui um subdiretrio buffer que contm um import buffer file para cada sistema que compartilha aquele transport group. Cada change liberado acrescenta uma entrada neste file de forma que ele conter informaes sobre os transportes que esto disponveis para import e a seqncia de importao. Esta informao acessada no TMS atravs da facilidade das import queues A rota de consolidao nas quais os transportes so liberados normalmente especifica um sistema de quality assurance para validao das changes. Quando se efetua o import do transporte para este sistema QAS, o sistema coloca as entradas no import buffer do sistema de delivery, normalmente o PRD, ou algum outro especificado no TMS. O processo de validao no sistema QAS poder detectar erros que sero corrigidos no DEV e novamente transportados para consolidao. A fila de import do sistema PRD poder ento conter mais um import que dever ser efetuado. Um ciclo de alterao poder conter um ou mais change requests, dependendo da necessidade de correo aps os testes no QAS. Quando finalmente o processo estiver pronto para import no delivery (PRD), o TMS permite que toda a fila de import seja efetuada carregando o sistema de produo com a verso final do objeto. Para o correto funcionamento deste mecanismo imprescindvel garantir que os transports sejam importados na correta seqncia.
Import Queues
A ferramenta mais importante para o mecanismo de import do TMS so as import queues que refletem a situao dos import buffers de um determinado sistema. Ela lista os change requests disponveis para import bem como a ordem com que foram liberados. Os dados exibidos no TMS so lidos no momento em que a transao chamada. A opo de refresh permite atualizar as informaes exibidas na tela. O programa RSTMSCOL pode ser schedulado para rodar de hora em hora e efetuar este refresh em background. Isto normalmente utilizado durante a fase de desenvolvimento do projeto onde o numero de change requests muito grande. Durante a manuteno do sistema normalmente no utilizado pois o nmero de changes provavelmente ser bem menor. Atravs da administrao da fila de imports possvel excluir change requests, efetuar forwards para outros sistemas, estabelecer dead lines e end marks, etc. A administrao do TMS permite muita liberdade no tratamento das filas, porm recomendvel que estas manipulaes sejam bastante conscientes para garantir a integridade e consistncia dos transportes. A SAP um pouco mais forte que a vida real, ela recomenda que nenhuma change seja deletada ou manipulada na fila para evitar qualquer tipo de consistncia. Para estabelecer end marks nas filas de import necessrio fechar (close) nas filas. Este processo eqivale a estabelecer stopmarks nos files do sistema operacional (tp setstopmark <SID>). A diferena bsica que enquanto no sistema operacional possvel acrescentar uma stopmark apenas no final da fila, atravs do TMS possvel colocar o end mark onde for mais conveniente. Este processo muito til quando desejado disparar um import em bloco porm at um determinado ponto apenas. O import all (caminho) efetua o import at encontrar a marca postada na fila. Operacionalmente recomendvel que sempre se feche a fila (end mark) antes de iniciar um import, evitando que requests liberados durante o processo tambm sejam transportados inadvertidamente.
jluiz@cemig.com.br
Pgina 76
ACADEMIA
BASIS
Para evitar inconsistncias entre change requests, somente efetue imports de changes isolados quando, com completa certeza, conhecer o seu contedo e sua independncia dos demais requests. Estes imports so denominados Preliminary imports. Como garantia, o TMS mantm os preliminary imports na fila para que sejam retransportados quando se efetuar o import padro (all). Em condies especiais possvel especificar parmetros diferentes quando do import. So as opes u do comando tp no sistema operacional. Este processo chamado expert mode. Existem uma srie de opes nos expert modes e elas sero detalhadas mas adiante.
Transporting Between Transport Groups

Transporte so gravados nas import queues de um determinado transport group que compartilha o mesmo diretrio de transporte. A opo In foreign groups (Extras -> Other requests -> In foreign groups) permite que se efetue transporte entre sistemas que possuem diferentes diretrios de transporte. Esta opo til quando o compartilhamento NFS dos sistemas no permitido por alguma razo tcnica (conexo ruim, segurana, compatibilidade, etc.). Neste caso o TMS cuida de sincronizar as informaes entre os buffers do grupo de origem e do o grupo de destino.
Transport Monitoring
possvel monitorar o processo de transporte atravs de uma srie de ferramentas do Import Monitor do TMS. O sistema permite ainda que se verifique a consistncia dos arquivos no sistema operacional (Consistency check) e o return code produzido por cada transporte atravs da visualizao da ALOG. O TMS tem ainda ferramentas para testar as funcionalidades do tp program e ainda verificar a configurao do diretrio de transporte (System check) alm do funcionamento das conexes RFC com os sistemas que compem o landscape. Atravs do Alert Monitor do CCMS possvel integrar algumas funes de monitorao com o TMS permitindo a gerncia centralizada do sistema R/3.
Transport Process
O processo de transporte pode ser descrito nos seguintes passos: O lder do projeto libera o change request aps verificar o trmino das tasks com os integrantes do grupo de trabalho O lder verifica ainda se o export foi realizado com sucesso informando ao administrador do sistema qualquer anormalidade O administrador importa o change request no sistema de consolidao e garante a execuo correta do processo com return codes aceitaveis. O time funcional garante os testes exaustivos no ambiente de consolidao. Qualquer problema detectado dever ser informado ao lder do projeto para que se inicie a correo e repita o export de uma nova correo para o sistema de consolidao O administrador do sistema efetua o import para o ambiente de delivery e demais sistemas configurados do conjunto consistente de change requests no landscape e garante a execuo correta do processo com a devida verificao dos return codes. Durante o processo de testes de uma funcionalidade pode ser necessrio congelar o trabalho no ambiente de desenvolvimento para garantir a estabilidade dos testes. Isto facilita a correo de possveis problemas encontrados nos objetos, que seria mais difcil de ser corrigido se o processo de desenvolvimento tivesse continuado no objeto durante os testes. Uma estratgia peridica para a importao dos transportes dever ser implementada e negociada com as equipes de desenvolvimento. Import all devero ocorrer mensalmente, semanalmente ou diariamente. Imports mais freqentes no so recomendados no ambiente R/3. O processo de import deve ser feito durante a baixa atividade do sistema e logo aps um backup da base. A SAP recomenda que o transporte de um projeto seja efetuado apenas quando todos os seus componentes estiverem totalmente desenvolvidos evitando a estratgia de enviar objetos individualmente a medida que vo ficando prontos.
jluiz@cemig.com.br
Pgina 77
ACADEMIA
BASIS
Advanced Transport Management

Transport Directory
Os change requests so gerados obedecendo a nomenclatura <source SID>K9nnnnn onde nnnnn um seqencial de 5 dgitos controlado pelo sistema source (tambm conhecido como sistema integrador ou sistema de desenvolvimento e configurao). O file system do diretrio de transporte fica montado na rea compartilhada /usr/sap/trans de uma das mquinas (normalmente aquela de onde os transportes se originam) e atravs de NFS, o file system compartilhado com os demais sistemas que compartilham o mesmo transport group. No ambiente do NT o compartilhamento feito atravs do sapmnt que contm, entre outros, o diretrio trans. O diretrio trans contm os seguintes subdiretrios, entre outros: actlog, onde so gravados cada action em um request ou task. Contm files com nomes <source SID>Z<6 digits> sapnames, com arquivos com o nome do usurio que efetuam release em changes. Com este arquivo podemos saber exatamente que gerou a request (no sistema operacional) buffer, com arquivo com nome <SID> contendo o import buffer para cada sistema R/3. Quando um change request liberado, o file correspondente ao sistema target atualizado data, contendo arquivos do tipo R9<5 digits>.<source SID> que contm os dados que foram exportados no transporte. Eventualmente neste diretrio podemos ter arquivos no formato D9<5 digits>.<source SID> que tambm contm dados a serem importados. cofiles, com command files do tipo K9<5digits>.<source SID> contendo por exemplo os import steps que sero executados log, com todas as logs de transportes, como por exemplo ULOGs, ALOGs, SLOGs e as demais logs que descrevem as operaes executadas nos steps individuais ou coletivos bin, com os arquivos de configurao do funcionamento do mecanismo de transportes (TPPARAM e DOMAIN.CFG) tmp, com os arquivos de log que esto sendo gerados durante o processo. Aps o trmino de um transporte os arquivos so movimentados para o diretrio LOG.
The tp Program
O transport control program uma ferramenta executada a nvel de sistema operacional que controla todas as operaes de transporte no sistema R/3 usando programas especiais (por exemplo em C), comandos de sistema operacional e programas ABAP no R/3. O TP opera as operaes de export e import separadamente, extraindo/atualizando as informaes de controle na base de dados do R/3 e levando para files (buffer, log e cofiles) no diretrio de transporte e posteriormente, atravs de comando explcito, importa os dados no sistema destino. Ele no faz a manipulao dos dados que sero transportados (o responsvel por isso o R3trans que ser visto a seguir). Apesar de ser uma ferramenta no sistema operacional (diretrio de exes), o tp deve ser utilizado atravs da interface do TMS que efetua as chamadas apropriadas para cada tarefa. Sua utilizao uma chamada tp <command> [argumento] [option(s)] como pode ser visto abaixo : tp help, exibe o help do tp tp <command>, exibe o help de um comando especfico tp go <SID>, checa o database de um sistema destino tp connect <SID>, checa a conexo tp showinfo <request>, exibe informaes de um determinado change request tp count <SID>, numera os requests para import em um sistema tp checkimpdp <SID>, exibe como o RDDIMPDP est schedulado em um determinado sistema tp showparams <SID>, exibe a parametrizao atual de um sistema tp status <SID>, exibe o status de serializao de um sistema O comando tp import all <SID> client=nnn executa o import de toda a fila de transporte do sistema <SID> no client nnn. Este o comando normalmente emitido pelo TMS.
jluiz@cemig.com.br
Pgina 78
ACADEMIA
BASIS
O comando tp import <request> <SID> client=nnn u0 executa o import de um request especfico e o mantm na fila, eqivalendo ao preliminary import do TMS. Quando se suprime a opo u0 o request retirado da fila de import. preciso tomar cuidado com imports individuais para garantir a manuteno da seqncia correta com que os mesmo foram exportados.
O import mode incondicional (com especificao da opo u<dgito>) tem os seguintes modos: u0, importa o buffer sem deletar o request da fila u1, ignora se o request j havia sido importado u2, sobrescreve os originais u3, sobrescreve objetos especficos do sistema u6, sobrescreve objetos em modo unconfirmed u8, ignora restries estabelecidas na tabela de classificaes u9, ignora o fato do sistema estar lockado para este tipo de transporte O buffer de um determinado <SID> manipulado pelos comandos tp especficos, como por exemplo addtobuffer, showbuffer, delfrombuffer, cleanbuffer, setstopmark e delstopmark. Estes comandos manipulam as linhas do arquivo especfico de cada sistema existente no subdiretrio buffer do diretrio de transporte.
The R3trans Program

O R3trans a ferramenta de transporte que efetivamente efetua os transportes no sistema R/3, sendo interativamente chamada pelo programa tp ou outros programas no ambiente, como por exemplo o R3up. Efetivamente o R3trans que vai ler os dados para construir o arquivo K9xxxxx e durante o processo de import vai ler os dados neste arquivo para fazer a atualizao dos dados da request em tabelas temporrias no banco de dados do sistema destino. O uso direto do programa R3trans no suportado e somente utilizado em casos muito especiais. A SAP no suporta ainda o uso do tp ou do R3trans entre releases diferentes do R/3.
The ABAP Programs

Durante os steps de um processo de import de um transporte alguns programas ABAP so executados no ambiente R/3. O programa RDDIMPDP um programa schedulado no ambiente para ser disparado pelo evento SAP_TRIGGER_RDDIMPDP. Este evento disparado no momento correto devido ao programa tp atravs de chamada ao sapevt. Este programa tem que estar schedulado corretamente (baseado no evento) pelo user DDIC no client 000 e em cada client que receber transportes para que o import funcione corretamente ( possvel verificar isso utilizando o comando tp checimpdp SID). A execuo do programa RDDNEWPP efetua este schedule no sistema, embora o sistema normalmente schedula este job automaticamente aps um client copy. A verificao do schedule pode ser efetuada pela SM37. O programa RDDIMPDP se baseia em informaes passadas pelo programa tp para ativar programas RDD* que efetuam tarefas especficas requisitadas pelo tp. As principais tarefas, a saber, so : mass activation (rddmasgl), convertion and generation (rddgendb) e versioning management (rddversl).
The Import Process

O processo de import composto de uma srie de steps que executam tarefas distintas e, dependendo do tipo do transporte, so ativados ou no. A organizao da fila de import no buffer file uma espcie de tabela onde para cada entrada referente aos requests, colocado um flag 0 ou 1 na posio referente a cada step. O programa tp no l esta fila individualmente, mas sim coletivamente. Desta forma o processo de import ocorre de forma seqencial no pelos requests, mas sim pelos steps. Desta forma o sistema executa o step 1 para todos os requests que o requisitaram, depois o step 2 e assim sucessivamente. Este processo garante por exemplo que caso exista na fila de transporte mais de uma referncia a um determinado objeto (por exemplo a segunda corrigindo um erro detectado em uma primeira consolidao) o step de ativao (posterior ao de importao) ocorra
jluiz@cemig.com.br
Pgina 79
ACADEMIA
BASIS
somente quando a verso correta esteja importada no sistema, evitando desta forma que a verso com erro seja ativada temporariamente como ocorreria se o processo fosse seqencial por request. Para garantir a consistncia do tratamento da fila de import, o programa tp coloca automaticamente um setstopmark na fila no incio do processo e a retira no final. Cada operao efetuada durante o processo logada pelo tp com o respectivo return code nos arquivos de log do sistema de transporte. Ocorrendo erros no processo o programa tp interrompe e aps a correo pelo administrador, um restart faz com que o tp encontre o ponto de parada e recomece o processo a partir daquele ponto. Qualquer return code maior que 8 interrompe o programa tp. Este valor entretanto pode ser configurado no arquivo TPPARAM (atravs do parmetro stoponerror) Os passos durante o import so (os passos com * so genricos e feitos em todas as requests) : DDIC Abap dictionary import ACTIV Abap dictionary activation Distribution Structure conversion (*) Move nametabs (*) MAIN Main import MC ACT Activation of the enqueue definitions MC CONV Enqueue conversion (*) ADO Import of application defined objects ADOs LOG Logical import (esta fase ainda no foi implementada e ser utilizada para a importao em um shadow client antes de fazer em um target client) VERS Versioning XPRA Execution of user defined activities GENERA Generation of abap prograns and screens
Communication During Imports

O programa R3trans, que chamado durante as fases de ABAP dictionary e main import) se comunica com o programa tp utilizando o subdiretrio tmp. Um control file passado pelo tp para cada step do processo de import e por sua vez o R3trans grava a log do transporte no tmp para que posteriormente seja transferido pelo tp para o subdiretrio log. A comunicao entre o programa tp e os jobs background no sistema se d atravs da tabela TRBAT que contm dados temporrios. O tp grava nesta tabela os steps que devero ser executados durante o import e ento dispara o evento que ativa o RDDIMPDP. Este programa por sua vez l a tabela e atravs das informaes recolhidas dispara programas RDD* que efetuam tarefas especficas requisitadas pelo tp. Cada um dos jobs RDDs disparados pelo RDDIMPDP registrado na tabela TRJOB atravs de uma entrada onde so gravados seus return codes que desta forma podem ser acompanhados pelo programa tp. As logs geradas pelos programas RDD* so gravadas no subdiretrio tmp e posteriormente transferidas para o log pelo programa tp. Qualquer problema detectado pelo tp durante a monitorao das tabelas TRBAT e TRJOB faz com que o tp reative o RDDIMPDP atravs da emisso de novo evento pelo sapevt. O RDDIMPDP analisa estas tabelas e verifica se o processo anterior ainda est ativo ou se necessrio, recomea o processo no step cancelado. Por este motivo que pelo menos dois background process precisam estar disponveis para o sistema de transporte.
jluiz@cemig.com.br
Pgina 80
ACADEMIA
BASIS
Transport Monitoring
Todas as logs do processo de transporte so gravadas no subdiretrio de log. So logs criadas pelo tp program (ULOG, SLOGs e ALOG) e pelas demais ferramentas de transporte. A ULOG contm todos os comandos tp sem erros de sintaxe. Cada linha representa um comando. Existe um arquivo SLOG<YY><WW>.<SID> para cada sistema R/3 do landscape e usado para monitorar as atividades de transporte de um sistema especfico. Contm uma viso geral dos imports efetuados indicando os respectivos return codes e consequentemente o sucesso de cada import. O ALOG<YY><WW> contm todos os return codes de cada um dos steps executados nos processos de import efetuados no seu transport group. Alm destes arquivos de log, o diretrio de logs possui uma log por change request. Estes arquivos possuem o formato <source SID><action>9<5digits>.<target SID> onde o action pode ser : E de main export feito pelo R3trans P de test import feito pelo R3trans H de dd import objects feito pelo R3trans A de dd activiation object feito pelo RDDMASGL S de dd distribution object feito pelo RDDGENBB N de dd conversion object feito pelo RDDGENBB 6 de dd move nametabs I de main import feito pelo R3trans T de import of table entries feito pelo R3trans M de enqueue activation feito pelo RDDGENBB G de repository object generation feito pelo RDDIC03L V de version update feito pelo RDDIC As diversas ferramentas envolvidas no transporte envia return codes que so consolidados pelo programa tp da seguinte forma: 0 a 16, indica os valores mximos de todos os return codes das ferramentas 17 a 99, que um valor calculado a partir daqueles retornados pelas ferramentas de transporte e so warnings indicando problemas detectados pelo tp, como por exemplo a no permisso de write no diretrio buffer 100 a 149, so warnings indicando que alguma coisa vai mal e nem todas as tarefas puderam ser completadas 150 a 199, so erros (raros de acontecer) indicando uma operao ilegal solicitada pelo operador 200 ou mais, indica erros no tp Para obter uma descrio de um return code, utilize o comando tp explainrc <rc>. Para acompanhar todo o processo verifique as logs dos transportes que foram feitos. As logs de transporte podem ser visualizadas atravs do Alert Monitor sob a forma de uma estrutura em rvore que pode sofrer drill down. O diretrio de transporte deve ser limpo de tempos em tempos para eliminar transportes antigos e desta forma liberar rea no sistema. O comando tp check all varre os diretrios de transporte e os arquivos referentes a transportes j executados so gravados em um arquivo denominado ALL_OLD.LIS no tmp. O comando tp clearold all l o arquivo gerado pelo comando tp check all e percorre os arquivos referentes as suas entradas e elimina aqueles que aparentemente no sero mais necessrios e se tornaram obsoletos baseados em timestamps definidos pelos parmetros datalifetime, olddatalifetime, filelifetime e loglifetime do TPPARAM. Antes de efetuar esta operao recomendado que se efetue uma cpia backup por segurana.
jluiz@cemig.com.br
Pgina 81
ACADEMIA
BASIS
Client Tools
As ferramentas de client copy e client transport foram criadas para executar a transferncia de dados entre clients. Estes dados sobrepem os dados do client destino. As ferramentas de client no foram concebidas para combinar dados de vrios clients. Os dados so categorizados como dados de customizao, dados mestre de usurio ou ainda application data. Dentre estes somente o mestre de usurios pode ser manipulado mais livremente e combinado com outros de outras fontes. No lado oposto est o application data que no pode ser manipulado de forma alguma sem o correspondente dado de customizao. Os mecanismos de cpia permitem a cpia local, remot ou atravs de transporte. Cada um destes possui uma caracterstica diferente. A cpia local utilizada para copiar clients dentro da mesma instncia e no consegue copiar as customizaes client-independents e os objetos de repositrio. J a cpia remota permite faz exatamente a mesma coisa s que entre sistemas R/3 diferentes e utilizando conexes RFC. O transporte de client o mais abrangente, com ele podemos levar um client de um sistema R/3 para outro, mesmo que o destino no esteja ativo no momento, e podemos levar todo tipo de customizaes. As ferramentas de transferncia de dado entre clients so definidas por profiles que definem o escopo dos dados que sero transferidos. Por exemplo: SAP_ALL, todos os dados do client SAP_CUST, customizing data SAP_CUSV, customizing e variantes de relatrio SAP_UAPP, user master e reports SAP_UCSV, user master, customizing e variantes SAP_UCUS, user master e customizing SAP_USER, user master Quando a inteno a criao de um client novo, uma entrada dever ser criada inicialmente atravs da transao SCC4. Clients recm criados possuem apenas o user SAP* hard coded (password PASS) e atravs dele que efetuaremos a cpia Clients protegidos contra cpia no podem ser sobrescritos. Esta proteo especificada na SCC4. Por questes de integridade, recomendado que no se log no client destino durante a cpia. Pela mesma razo recomendado que no se utilize o client source durante o processo
Local Client Copy

A cpia local permite a transferncia dos dados entre clients de um mesmo sistema R/3 e deve ser disparada estando-se logado no client destino atravs da transao SCCL, especificando o client source e a profile de cpia. Em uma primeira implementao, a SAP recomenda que se utilize o client 000 como source para o primeiro client
Remote Client Copy

A cpia remota permite a transferncia dos dados entre clients de diferentes sistemas R/3 e, assim como a local client copy, deve ser disparada estando-se logado no client destino e utiliza-se a transao SCC9, especificando o sistema e client source e a profile de cpia. A cpia exatamente igual a local, apenas que os dados so enviados atravs de uma conexo RFC. Para garantir o sucesso da cpia, ambos os sistemas devero possuir a mesma estrutura de database. Qualquer inconsistncia causa o trmino do processo com erro
Client Transport
Diferentemente do processo de cpia remota, a transferncia no executada por RFC, embora este processo tambm permita a transferncia de dados entre sistemas distintos. O processo consiste de dois steps: no primeiro os dados so exportados para files no sistema operacional e no segundo estes dados so importados para o client destino.
jluiz@cemig.com.br
Pgina 82
ACADEMIA
BASIS
Diferentemente tambm dos dois outros processos, necessrio logar no client source e efetuar atravs da transao SCC8 o export dos dados. Durante este processo necessrio especificar o sistema target que dever compartilhar o mesmo transport domain. Por ser um processo demorado dever ser schedulado em batckground. O processo de export de um client utiliza chamadas ao programa tp e cria at 3 arquivos no sistema operacional: RTnnn com dados client dependent, ROnnn com dados client independent e finalmente SXnnn contendo SAPscripts. Alm destes files o processo cria arquivos na import queue (buffer) do sistema target (S-SID-KOnnn para independent e S-SIDKTnnn para dependent data). A segunda parte do processo, que a fase de import executada atravs da transao SCC7 que comanda o import. Primeiro deve-se importar os dados client independent e posteriormente os client dependent. Em seguida necessrio se logar no sistema target e executar o Post-process import para efetuar atividades requeridas pelo SAPscript e possveis steps de gerao de objetos ainda pendentes.
Copy Process
Durante o processo de cpia de client, o sistema inicialmente limpa os dados com a key do client no sistema destino. Number ranges so copiados do cliente source. Se o dado de aplicao no for copiado, o number range ser resetado. No possvel copiar dados de aplicao sem copiar junto os dados de customizao e os number ranges. A cpia apenas dos dados de customizao pode causar inconsistncias no momento do merge no client destino A profile SAP_USER a nica que no possui a opo de Initialize and Recreate O processo pode ser bastante demorado (dependendo do profile utilizado e volume de dados no source) devendo o processo rodar em background process. Durante o processo de cpia o logon fica inibido no client target exceto para os users SAP* e DDIC. ainda recomendado que no se trabalhe no client source durante a cpia. O processo de cpia ir gerar entradas nas tabelas do banco de dados e consequentemente exigir a disponibilidade de rea suficiente nos tablespaces do banco. As logs dos processos de cpia visualizada atravs da transao SCC3 e exibe informaes sobre estatsticas das tabelas, informaes de controle e informaes detalhadas sobre cada tabela copiada e suas interaes com os objetos do IMG. Cpias de client pelo processo de client transport so monitoradas atravs da SE01 (transport organizer) A monitorao do processo de cpia permite, em caso de abend do processo, o restart a partir do ponto em que ocorreu o problema. Esta opo pode ser utilizada aps uma anlise do problema ocorrido, sendo mais eficiente que a opo de um new start. Objetos do repositrio associadas a classe de desenvolvimento local ($TMP) no so copiadas durante o processo de client copy.
Client Delete
Clients so deletados atravs da transao SCC5. O processo de cpia poder inclusive ser agilizado se o client tiver sido anteriormente excludo do ambiente destino. No processo de delete os dados, SAPscripts e batch inputs
Client Compare
Quando vrios sistemas R/3 com clients distintos esto sendo implementados, pode ser necessrio comparar e ajustar as customizaes entre os diferentes sistemas e clents. A funo Compare. Esta funo compare permite comparar e ajustar o contedo de tabelas ou vises entre dois clients distintos. A transao SCUO utilizada para selecionar os tipos de objetos que sero comparados e ainda especificar se a comparao ser de dados clint dependents ou independents. A sada da comparao exibida de forma tabular e torna fcil a anlise das eventuais diferenas
jluiz@cemig.com.br
Pgina 83
ACADEMIA
BASIS
Eventuais ajustes podero ser efetuados atravs da transao SM30, que permite a manuteno da maioria dos objetos de customizao. Objetos que no podem ser ajustados pela SM30 podero apenas ser comparados.
Client Maintenance Settings

Alm das opes de proteo dos dados client dependent e client independent, a transao SCC4 possui opo para proteger o client contra client copy, atravs de niveis de proteo 0 (sem proteo), 1 (no pode ser sobrescrito) ou 2 (no pode ser sobrescrito nem acessado externamente para comparao)
Authorizations for client tools

Para manipular as ferramentas de movimentao e manuteno de clients dispomos dos seguintes objetos de autorizao : S_TABU_CLI para manter a tabela de dados dependentes de um client S_TABU_DIS para manter qualquer tipo de tabela S_CLNT_IMP para fazer import de dados durante uma cpia S_DATASET para acessar arquivos do sistema operacional S_USER_PRO para manter as profiles de cpia S_USER_GRP para manter os dados mestres de usurios S_TRANSPRT para manipular o CTO (change and transporte organizer)
jluiz@cemig.com.br
Pgina 84
ACADEMIA
BASIS
Client and System Strategies

Types of Landscapes
Uma implementao R/3 pode ser executada de diversas maneiras distintas. As implementaes mais comuns so sistemas R/3 em hardware diferentes e os possveis landscapes so os com 3, 2 ou 1 sistemas R/3:
Three-System Landscapes
No landscape com 3 sistemas temos os seguintes ambientes: Development, contendo um client de customizao e desenvolvimento (CUST), e um client para testes unitrios (TEST) Quality Assurance, contendo um client de consolidao e teste sistmico (QTST) Production, contendo um client de produo (PROD) Esta implementao apresenta as seguintes vantagens: Desenvolvimento, qualidade e produo so implementados em ambientes distintos Maior segurana dos dados no ambiente de produo A performance do ambiente de produo no afetada pelos demais sistemas Ambiente de teste separado Consolidao dos transportes antes do envio para a produo A principal desvantagem desta opo o alto custo do hardware em funo da quantidade de mquinas necessrias
Two-System Landscapes
No landscape com 2 sistemas temos os seguintes ambientes: Development, contendo um client de customizao e desenvolvimento (CUST), um client para testes unitrio (TEST) e um client de consolidao e teste sistmico (QTST) Production, contendo um client de produo (PROD) Esta implementao apresenta as seguintes vantagens: Desenvolvimento e produo so implementados em ambientes distintos Maior segurana dos dados no ambiente de produo A performance do ambiente de produo no afetada pelos demais sistemas Ambiente de teste separado Administrao simplificada em funo da diminuio do hardware Esta implementao apresenta as seguintes desvantagens: Desenvolvimento e qualidade so implementados em um nico ambiente, ou seja, um ambiente pode impactar o outro. No possvel fazer um teste completo dos objetos do repositrio nem customizaes client independents antes que sejam transportados para a produo, que age aqui como o ambiente de consolidao No possvel consolidar os transportes antes de envia-los para a produo
One-System Landscapes
No landscape com 1 sistema temos os seguintes clients: Ambiente nico, contendo um client de customizao e desenvolvimento (CUST), um client para testes unitrios (TEST) , um client de consolidao e teste sistmico (QTST) e um client de produo (PROD)
jluiz@cemig.com.br
Pgina 85
ACADEMIA
BASIS
Esta implementao apresenta as seguintes vantagens: Toda a implementao em apenas um hardware Menor esforo de administrao, sem transporte de objetos do repositrio e customizaes client independents Esta implementao apresenta as seguintes desvantagens: Desenvolvimento de objetos e customizaes client independent afetam imediatamente o ambiente de produo Um ambiente impacta todos os outros ambientes tanto em performance, quanto integridade e segurana Upgrade da produo realizado sem um teste das funcionalidades Produo compartilha recursos de hardware com os demais ambientes com conseqncias ruins para a performance Como esta opo a mais precria e sucetivel a grandes impactos aps a entrada em produo ela s aceitvel se os desenvolvimentos parassem antes da entrada em produo. Se for necessrio fazer alguma correo no ambiente deve ser feito durante o perodo sem atividade produtiva.
Landscape Requirements
preciso que se tenha uma estratgia consistente para configurao dos sistemas no landscape para proteo dos repositrios e dos transportes consistentes entre os sistemas. Atravs de uma configurao correta de clients para os ambientes de produo e qualidade, possvel bloquear customizaes e desenvolvimentos fora do ambiente reservado para esta finalidade. A estratgia bem montada de distribuio de transportes, atravs da especificao cuidadosa de rotas de consolidao e distribio, e a definio de um ponto nico de alterao do ambiente (client de desenvolvimento) garante assim que todos os clients do landscape tenham configuraes consistentes. A configurao correta dos clients na SCC4 poder proteger produo e qualidade de configuraes e desenvolvimento e ao mesmo tempo fora a gravao automtica em change requests dos esforos de customizao e desenvolvimento ABAP. Alm disto um bom procedimento e agendamento dos mecanismos de transportes junto com padres de nomeclatura ajudam a garantir a estabilidade do ambiente.
ASAP System Landscape

A ASAP recomenda um roteiro passo a passo para configurao de um landscape de 3 sistemas, dentro do ASAP Roadmap, que consolida as experincias tanto da SAP quanto dos seus parceiros de implementao. Passo 1: Aps a primeira instalao do sistema no ambiente de Desenvolvimento, utilizar o client 000 para, atravs de client copy, criar os clients de TEST e CUST. TEST configurado como uma produo, com no changes allowed e No changes to repository and client independent customizing. CUST configurado para gravao automtica de change requests e permisso para alterao do repositrio e client independent customizing Passo 2: Estabelea uma estratgia de manter o CUST sem dados e qualquer teste dever ser efetuado atravs do transporte das customizaes nele executadas para o client TEST atravs da transao SCC1. Os transportes gerados no sistema CUST sero liberados para o diretrio de transporte Passo 3: Quando chegar a hora de criar o ambiente de consolidao, instale um sistema R/3 no ambiente de qualidade e, a partir do client 000, crie os clients TRNG para treinamento e QTST para qualidade. Ambos os sistemas estaro protegidos atravs das opes No changes allowed e No changes to Repository and client independent customizing.
jluiz@cemig.com.br
Pgina 86
ACADEMIA
BASIS
Passo 4: Os transportes liberados no ambiente CUST e que se encontram na fila de import devero ser importados para a o client QTST. Atravs da SCC1 os change requests podero transferidos para a TRNG. Volumes muito grandes de change requests podem ser agrupados em um nico change request ou simplismente podemos importar a fila no TRNG. Passo 5: Instale um sistema R/3 no ambiente de produo e, a partir do client 000, faa um client copy para criar o client PROD, que dever ser configurado para No changes allowed e No changes to repository and client independent customizing. Em seguida import toda a fila de requests para o novo client configurado. A partir deste momento, qualquer change request liberado na CUST dever ser copiado para a TEST utilizando a SCC1. Uma vez testado, o change ser importado para consolidao na QTST e eventualmente transferido atravs da SCC1 para a TRNG. Changes consolidadas sero finalmente importadas no ambiente de produo.
ASAP Recomendations
As change requestes e seus histricos devero estar muito bem documentadas no ambiente e nenhuma alterao pode ser feita sem estar contida em uma change request. Documente o que contm a request, o que resolvido, quem fez a alterao e quando foi transportada para cada um dos ambientes. Tenha estabelecido desde o incio critrios bem definidos para regulamentar as change e seus transportes entre as instncias com as respectivas rotas e a periodicidade do transporte em cada uma das rotas. Distribua os transportes apenas quando eles contiverem uma unidade completa de desenvolvimento ou customizao. Evite fazer upgrade durante o processo de desenvolvimento. Se for impossvel, tenha certeza que requests geradas em uma verso/nvel de hot package s sero transportadas para um ambiente com a mesma verso/nvel de hot package.
Alternative Landscapes
Alternativamente, apenas o client CUST poder ser criado inicialmente com as opes de gerao de change request desligadas. Quando se decide criar o sistema TEST no mesmo sistema, ele ser gerado a partir de um client copy do CUST e a partir deste momento deveremos ligar a gerao automtica de change requests, uma vez que a nica forma de sincronizar os dados client independents daqui para a frente ser atravs da movimentao dos changes via SCC1. A criao do client de qualidade (QTST) feita atravs de um client export/import, assim como o produo. A principal vantagem deste mtodo alternativo que a gerao de transportes somente precisa ser ativada e gerenciada quando acrescentamos um segundo client no landscape. A desvantagem que no possuiremos o histrico completo das change e, principalmente, quando do momento dos client export dados de customizao ainda no totalmente consolidados estaro sendo movimentados para os demais ambientes. Alm disto devemos ter cuidado em relao a objetos do repositrio pois eles no estaro presentes na cpia do client. Para solucionar isto temos que ter todos os objetos alterados documentados para ser possvel gerar uma request que dever ser transportada antes do client import. Uma terceira opo a criao dos ambientes de QAS e PRD a partir de homogeneous system copy, embora esta estratgia no seja recomendada pela SAP. As principais desvantagens esto associadas a falta de controle das request e a eventual presena de configuraes e desenvolvimentos no acabados no ambiente produtivo. Atravs da configurao do TMS e suas rotas de consolidao e distribuio possvel definir os mais complexos cenrios que possamos necessitar na instalao. As rotas de distribuio (delivery) podem ser paralelas para vrias instncias ou ainda em cascata, dependendo da configurao TMS. Uma implementao Phased Development necessria em algumas situaes especiais, como por exemplo em um upgrade ou implementao de novo mdulo SAP. Neste caso, as customizaes efetuadas no seu ambiente de produo precisaro ser replicadas manualmente para o ambiente original para manter a integridade do sistema.
jluiz@cemig.com.br
Pgina 87
ACADEMIA
BASIS
possvel ainda manter um cenrio de desenvolvimento multi-layered com vrios ambientes de integrao com suas prprias rotas de consolidao e distribuio. A maior dificuldade neste cenrio a manipulao das customizaes que no possuem o conceito de proprietrio. O desenvolvimento mais simples de gerenciar atravs da criao de classes de desenvolvimento distintas.
Transport Organizer
O Transport Organizer (SE01) uma ferramenta que fornece solues para a manipulao de cenrios mais complexos que no podem ser gerenciados pelas ferramentas normalmente utilizadas. As funes de transportes e realocaes permite transportar cpias de objetos ou realocaes de originais. possvel manipular Object Lists, que so colees de objetos que podero servir para template da funo Include Object List conseguindo desta forma incluir object lists em change requests.
jluiz@cemig.com.br
Pgina 88
ACADEMIA
BASIS
R/3 Upgrades and OCS Patches

R/3 Evolution and Release Strategy
Um sistema R/3 tpico, uma vez instalado, passa por evolues sejam devido a customizaes ou novos desenvolvimentos, como tambm pela aplicao de patches do OCS (Online Correcton Service) ou ainda por upgrade de novos releases. Novos releases no R/3 podem ser de dois tipos: Functional Releases, que trazem novas funcionalidades e so enviados para os clientes apenas sob demanda (3.1G e 4.0A, por exemplo) Correction Releases, trazem apenas correes e so enviadas automaticamente para todos os clientes. Estes so os releases recomendados para serem instalados em produo, j que possuem suporte total do OCS (3.1H ou 4.0B, por exemplo)
R/3 Upgrade
Em um tpico landscape de 3 sistemas, cada ambiente (partindo do desenvolvimento) passa por uma seqncia de transportes standard. So tarefas tais como customizaes, patches, e ajustes no sistema. Estas alteraes so executadas no ambiente de desenvolvimento e transportadas para os demais ambientes. Uma das tarefas mais importantes durante a preparao para o upgrade rodar o script PREPARE (integrante da ferramenta retrofit que integra a localizao que existia na verso 3.0 com o correspondente standard que vem na verso 4.0) e que responsvel por fazer uma srie de checks, a saber : Quais so as verses do banco de dados, do sistema operacional, e do R/3 Quais abaps preciso ser realterados Existe espao suficiente no banco de dados Existe alguma reparao em andamento Quais so as lnguas suportadas Qual o nvel de hot package e se todos esto confirmados usurio tem as devidas permisses no sistema operacional Aps todo este processo o prepare gera um arquivo chamado \usr\sap\put\log\checks.log) no sistema com as aes necessrias para viabilizar o upgrade. A execuo deste script no faz parte do upgrade em si que feito utilizando o programa R3up que tem funcionamento semelhante ao R3setup que utilizado na instalao. Durante o processo de upgrade, so efetuadas alteraes de ajuste usando as transaes SPDD e SPAU. O processo de upgrade passa por passos que so efetuados com o sistema ativo ainda no release antigo, a retirada do sistema para que o dicionrio seja atualizado e posteriormente mais tarefas novamente com o sistema ativo, agora j no novo release. Antes de fazermos o upgrade do R/3 j temos que ter cumprido alguns passos obvieis como a execuo do script prepare, upgrade do sistema operacional, eventual upgrade do hardware, upgrade do banco de dados e outros fatores que possam ser pr-requisitos para o R/3. O primeiro passo efetivo do upgrade a transferncia para o repositrio do R/3 dos novos objetos enviados em um CD. Este processo passa pela comparao dos objetos para identificar possveis modifications efetuadas pelo usurio nos objetos SAP standard. Todas as modificaes que o cliente desejar manter e cujos objetos SAP no novo release tambm foram alterados, precisam ser casados com os objetos SAP. Este processo executado atravs das transaes SPDD e SPAU e conhecido como Modification Adjustment. Existem diversos tipos de modification adjustment que so executados antes (atravs da SPDD) e depois (atravs da SPAU) da fase do Data Dictionary Activation. Durante esta fase de activation o sistema desativado, que pode durar vrias horas. Aps esta fase o sistema reativado j no novo release. jluiz@cemig.com.br Pgina 89
ACADEMIA
BASIS
Repository Switch
O corao de um processo de upgrade o Repository switch. Inicialmente um repositrio inteiro na nova verso colocado no sistema e permanece inativo. Este processo requer uma rea adicional em disco que somente ser liberada quando o novo repositrio for ativado e o antigo deletado. Para preservar as modifications introduzidas pelo usurio, durante o processo de switch do repositrio as alteraes introduzidas pelo usurio so transferidas para o novo repositrio atravs da modificao dos correspondentes objetos SAP do novo release. A fase de modification adjustment somente ser necessrio quando o objeto alterado pelo cliente tambm foi modificado pela SAP (seno ele ser movido integralmente) e quando questionado, o cliente decide continuar com suas alteraes por achar que o novo release no incorpora devidamente suas necessidades. Caso o cliente aceite o novo objeto, suas antigas alteraes sero descartadas. No processo de preparao do repository switch acontecem as seguintes operaes: Transfere para o novo repositrio modifications introduzidas pelo cliente cujos objetos SAP no sofreram mudana no novo release Salva no version database todas as modifications que foram efetuadas em objetos que sofreram mudana no novo release. Isto permitir efetuar os ajustes posteriormente Copia os objetos que foram gerados atravs do processo de customizing para o novo repositrio Transfere para o novo repositrio todas as documentaes, verses inativas de objetos e desenvolvimentos executados pelo cliente, alm dos objetos locais Uma vez que as operaes acima foram efetuadas, o repository switch poder ser efetuado. Caso no existam objetos que necessitam de adjustment, o switch uma simples questo de reativar o novo repositrio. simples e rpido, sendo portanto sempre desejvel que os objetos SAP permaneam o mais standard possvel.
Switch log during repository upgrade

Durante o processo de upgrade podemos escolher trs estratgias diferentes para o uso da log de alterao. Independente de cada uma destas estratgias evidente que devemos ter backup full offline de cada ponto do processo para que em caso de pane ou necessidade de retorno a situao anterior tenhamos backup para retornar a situao anterior. As principais fases do upgrade so : Inicializao do processo Importe do repositrio Anlise e copia dos novos objetos Switch, ativao do novo dicionrio e ajuste dos objetos impactados Importe dos dados de controle Importe da lingua portuguesa Fase final e backup aps todo o processo As estratgias disponveis para o upgrade so : A_OFF: neste caso durante todo o processo no teremos redo log do que foi feito, ou seja, se precisarmos retornar a um ponto temos que faze-lo no momento do backup full sem a possibilidade de fazer um log-foward. A grande vantagem desta opo a no necessidade de rea para o archive. A grande desvantagem um maior tempo de downtime acrescido de um backup offline no final do processo. A_ON: neste caso manteremos o log do banco ativado. O inconveniente deste mecanismo o consumo de rea de at 6 Gb para a rea de archive. A grande vantagem o menor tempo de downtime e a possibilidade de um backup online. A_SWITCH: uma mescla dos dois processo e a log desativada no momento do da fase de ativao do novo dicionrio. O consumo de disco menor que na opo A_ON mais ainda considervel. O downtime tambm pequeno mas seguido de um backup offline.
jluiz@cemig.com.br
Pgina 90
ACADEMIA
BASIS
Ou seja, ela possui um pouca do lado bom das outras duas e por isto que esta opo a recomendada pela SAP e j o default.
Modification Adjustment
O processo de modification adjustment consiste na transferncia para os novos objetos SAP das modifications introduzidas pelo usurio no release anterior. A transao SPDD utilizada para efetuar esta transferncia em certos objetos do dicionrio ABAP, tais como domains, data elements, table structures, transparent tables, pooled tables, cluster tables e table technical settings. A no execuo desta tarefa causaria a perda de dados Aps a ativao do novo dicionrio, a transao SPAU utilizada para ajustar alguns objetos que se no ajustados no causariam perda de dados, apenas perda de funcionalidade. Estes objetos seriam objetos de lock, matchcodes e views, alm de objetos do repositrio, tais como ABAP programs, function modules, menus, screens ou module pools Ao trmino da execuo destas duas tasks (SPDD e SPAU), todas as modifications estaro incorporadas no novo release. No release 4.0 o processo de pre-upgrade PREPARE (script mencionado anteriormente e integranda retrofit tool) para o upgrade efetua um check geral do sistema e lista todos os objetos que sofreram modifications e consequentemente necessitaro de passar pelas SPDD e SPAU, podendo desta forma haver um melhor planejamento do esforo a ser gasto no processo. O processo de modification adjustment executa um comparao entre as duas verses do objeto. Para cada objeto, as transaes SPDD e SPAU guiam o usurio atravs dos processos de ajuste, oferecendo ainda a opo de aceitar a nova verso ou executar os ajustes necessrios. Estes ajustes, quando efetuados, sero salvos em change requests (um para a SPDD e outro para a SPAU) permitindo que o processo de upgrade nos demais sistemas possam ser efetuados de forma mais simples pela aplicao destes transports. Este procedimento de transporte simples e poupa esforos de efetuar os adjustments em cada ambiente, porm somente possvel apenas se todos os sistemas do ambiente estiverem nos mesmos nveis de modification no momento dos upgrades. Um landscape bem planejado e bem gerenciado torna este processo vivel e diminui sensivelmente os esforos no upgrade. Em relao as responsabilidades do processo de upgrade, temos que ter em mente que os administradores do sistema so responsveis pelo upgrade mas os times funcionais e de abap so responsveis pelos ajustes e testes das funcionalidades que sero afetadas pelo upgrade.
Avoiding Modifications in R/3 Systems

Para simplificar os processos de upgrade (minimizando ou at mesmo eliminando a necessidade de efetuar modification adjustments), a SAP recomenda que se evite modifications tanto quanto possvel. Alm de demandarem mais esforos durante upgrades, estas alteraes no standard core do R/3 podem introduzir erros graves no ambiente R/3. Dependendo do nvel destas modificaes e seus reflexos no negcio da empresa, um processo de upgrade poder ser difcil, demorado ou at mesmo impossvel de ser implementado em verses mais recentes do R/3. Em substituio s modifications, a SAP disponibiliza o conceito de enhancements, atravs da utilizao de user exits e appended structures que tornam o processo de upgrade totalmente transparente para a instalao O conceito de user exits consiste na introduo em determinados pontos mais susceptveis a modifications dos objetos SAP de chamadas a rotinas externas que podem ser desenvolvidas pelo cliente em sua instalao. Novos releases traro estas chamadas nos mesmos pontos no necessitando o cliente de efetuar nenhuma alterao no novo objeto. Os objetos que possuem exit so: Program exits, que permitem includes no cdigo atravs de chamadas externas jluiz@cemig.com.br Pgina 91
ACADEMIA

BASIS
Menu exits, podendo o cliente introduzir novas opes no menu Screen exits, que so telas adicionais Field exits, que so programas ou function modules conectados a um campo de tela para executar funes por exemplo de consistncia personalizada de preenchimento. Ao contrrio dos demais tipos de exits, field exits no precisam ser criadas para um determinado campo, podendo o cliente decidir pela sua colocao em qualquer campo.
As append structures permite que se acrescente campos em tabelas SAP sem a necessidade de alterao dos objetos standard do sistema. Os campos includos ocupam fisicamente uma outra rea e apenas sero incorporados a nova verso do objeto no novo release. Estas estruturas devero possuir nomes no customer range (Z) para evitar que sejam sobrescritas no momento do upgrade. A incluso destas estruturas entretando no so permitidas a pool tables, cluster tables ou tables que possuam campos LONG RAW.
Online Correction Service (OCS)

O OCS oferece patches para correo de um sistema R/3 atravs da disponibilizao de Hot Packages, LCPs, SPAM updates e Conflit Resolution Transport (CRTs). Estes patches reduzem a necessidade de correes manuais no sistema atravs da aplicao de notas que, diferentemente destas correes, no sero reconhecidas por um processo de upgrade como modifications. portanto extremamente aconselhvel que um sistema R/3 esteja up to date no momento de um upgrade para minimizar a necessidade de anlise de modifications que no passam de notas aplicadas. Os tipos de patches na verso 4.0 so : Hot Packages so grupos de vrios patches e devem ser aplicados na ordem em que so disponibilizados pela SAP. Tecnicamente durante a sua aplicao requerem modification adjustments atravs da transao SPAU. LCPs ou Legal Change Patches, so os Hot Packages para o ambiente HR SPAM update uma atualizao para a transao SPAM (utilizada durante a aplicao dos Hot Packages) CRTs ou Conflit Resolution Transports suprem objetos adaptados para resolver conflitos entre o R/3 e alguns SAP add-ons Estes patches ficam disponveis para download no sapnet (ou atravs de download via OSS a partir da SPAM). Para simplificar a sua implementao, a SAP empacota umas 3 vezes ao ano os Hot Packages, SPAM updates e LCPs em um CD que enviado para o cliente. O SAP Patch Manager (transao SPAM) a ferramenta utilizada para aplicar os patches no ambiente R/3 e dever ser executada no client 000 por um usurio que possua todos os privilgios (SAP_ALL) porm no dever ser o DDIC ou o SAP*. A SPAM fora a aplicao dos patches na ordem correta e obriga a um aceite em cada aplicao antes de aceitar a seguinte, forando desta forma a uma verificao da aplicao pelo cliente. O processo de aplicao dos patches deve ser efetuado em todos os sistemas do landscape. Caso se efetuem adjustments pela SPAU durante a aplicao, os mesmos podero ser salvos em change requests para posterior import nos demais sistemas, evitando a utilizao da SPAU mais de uma vez. Ao longo da utilizao e conseqente identificao de problemas nas funcionalidades do sistema, pode ser necessrio aplicar manualmente no R/3 correes disponibilizadas em notas no OSS. Estas notas (porm nem todas) sero posteriormente agrupadas em Hot Packages. Qualquer nota dever ser muito bem avaliada antes de sua aplicao.
jluiz@cemig.com.br
Pgina 92
ACADEMIA
BASIS
Terceira Semana R/3 Spool and Print

As definies de impressora so client independents, ou seja, basta definir a impressora em um dos mandantes para que todos possam utiliza-la. De preferencia aos clients mais nobres de cada um dos sistemas R/3. As principais transaes deste captulo so SP01 e SPAD.
R/3 Spool System

O R/3 possui diferentes formas de enviar documentos atravs de seus sistemas de spool. Um documento formatado, que pode ser uma impresso, um fax ou um EDI, representa uma message no sistema R/3 e, uma vez criada, estar liberada para impresso ou transmisso. As impresses no R/3 podem ser imediatas ou adiadas para sada posterior. Alm do message control, o R/3 possui uma combinao de programas de impresso e SAPScripts para produzir os documentos de impresso. Enquanto o programa de impresso obtm os dados a serem impressos, o SAPscripts especifica o layout do documento a ser impresso. Como o sistema R/3 um ambiente multiplataforma, foi criado um sistema interno de spool para interfacear com os diversos hosts nos quais o R/3 pode rodar. Atravs deste princpio o R/3 formata os documentos e requisita ao spool do sistema operacional que apenas repassa o documento para o dispositivo fsico de impresso que est alocado na porta paralela ou serial.
Spool and Output Requests

Um spool request criado quando um documento R/3 requisitado para impresso mas ainda no foi enviado para o dispositivo de sada. Os dados ficam armazenados em um formato genrico interno do R/3. Um spool request formatado pelo spool work process e passa a ter um determinado formato para um dispositivo especfico, este formato nos chamamos de output request. Vrios output requests podem ser gerados a partir de um nico spool request, contendo cada um os atributos ou comandos especficos de um determinado hardware de impresso. Os spool requests gerados ficam armazenados em um repositrio denominado Temporary Sequential Database, ou TemSe. Este repositrio poder estar no banco de dados do R/3 ou em arquivos do global directory do sistema operacional (determinado pelo parmetro de profile rspo/store_location = db ou G e direcionado pelo parmetro rspo/files/root/G = $(DIR_GLOBAL) ). Os output requests so armazenados apenas como registros de controle. Os formatos de impresso uma vez gerados so repassados diretamente para o gerenciador de impresso do sistema operacional sem serem armazenados na base de dados.
Spool Work Process

Quando uma requisio de impresso de um spool request efetuada, um output request especfico para o device desejado criado pelo spool work process do R/3, que l os dados a serem impressos no TemSe (spool request) e o formata baseado no driver do dispositivo especificado. Uma vez formatado, o dado repassado diretamente para o spool do sistema operacional para que o encaminhe para o dispositivo endereado. Para formatar corretamente a sada, alm do driver especfico do dispositivo o R/3 utiliza informaes referentes ao character set utilizado e comandos especficos do dispositivo para formatao dos dados.
Local and Remote Printing

Os output requests formatados so repassados para os dispositivos atravs de strings de impresso. Quando se utiliza o mtodo Local, os dados so repassados diretamente para o spooler
jluiz@cemig.com.br
Pgina 93
ACADEMIA
BASIS
do sistema operacional da mquina onde o spool work process que cuida de envia-los, seja para uma impressora conectada diretamente ao host ou atravs da rede. o mtodo mais rpido, uma vez que a tarefa de gerenciamento do string at o dispositivo de sada fica a cargo do sistema operacional, liberando o work process desta tarefa. Evite utilizar o host onde o sistema R/3 est rodando como o host que controla esta fila de impresso e possui uma impressora ligada fisicamente pois isto vai consumir recurso do sistema operacional. Existem cinco mtodos de acessos, a saber : L, utilizado onde o output request passado para o gerenciador de impresso do sistema operacional (do tipo line command). O mais comum ser utilizado no ambiente unix mas tambm pode ser utilizado no ambiente Windows NT. Os comandos a serem utilizados para imprimir e para verificar a fila podem ser redefinidos atravs dos parametros rspo/host_spool/print e rspo/host_spool/query, respectivamente C, utilizado onde o output request passado para o gerenciador atravs de call a bibliotecas especficas do sistema operacional. Deve ser utilizado com Windows NT e AS/400 E, utilizado para enviar o output request para um OMS (ser detalhado logo a seguir) P, utilizado para enviar o output request para um device pool F, utilizado para impresso no front-end e quem formata o output device o dialog work process Remote printing consiste na transferncia dos output requests diretamente para os dispositivos remotos. Neste caso o spool work process fica responsvel pela negociao com o dispositivo atravs da rede. Este mtodo de acesso remoto menos otimizado por onerar o work process gerando possveis contenes na impresso. O spool work process fica preso at que ele consiga passar todas as informaes para o spooler remoto (ou saplpd) que eventualmente fica esperando o buffer da impressora, ou seja, o spool work process fica preso at que a maior parte da impresso fsica seja feita. A transmisso remota feita atravs de lpd (line printer daemon) e a SAP prov o programa SAPLPD para as plataformas que no possuem este protocolo standard. Devemos utilizar este mtodo somente quando a rede for muito rpida e muito confivel. Os mtodos de acesso so : U para os ambientes baseados no unix e impressoras de rede S para ambientes windows 9x com saplpd
Spool Administration
A transao SPAD utilizada no R/3 para a administrao de spool. As impressoras (output devices) so definidas especificando o mtodo de acesso (local L ou C - ou remoto U ou S para unix e windows respectivamente ) e suas caractersticas (device type, spool server, print server, atributos documentacionais, etc.). Para impressora remota devemos sempre utilizar o nome do print server no formato UNC //<host_name>/<printer_share_name>. Na verso bsica da SPAD podemos definir output devices, spool servers, access methods e destination hosts. Podemos tambm verificar a instalao, deletar spools antigos, verificar a TemSe e acionar SP01.
Frontend Printing
A impresso frontend no R/3 permite que usurios enviem output requests para impressoras que no foram definidas como output devices no R/3. o denominado mtodo de acesso F. Caso a estao do usurio seja um PC windows, o request enviado para um SAPLPD rodando na estao do usurios. Se o SAPLPD no estiver rodando, ele iniciado e manipula os requests e os envia para a impressora default do usurio. Neste mtodo de acesso o processamento do spool efetuado pelos prprios dialog work processes, no havendo necessidade de encaminhar o request para os spool work processes. Para definir uma impressora frontend para as estaes windows, alm de especificar o mtodo de acesso F, necessrio definir o device type SWIN (qualquer impressora com device instalado no windows) e o host printer dever ser __DEFAULT. Este mtodo dever ser evitado em sistemas produtivos por utilizar os work processes para tarefas que deveriam estar reservadas para os spool work processes alm de prender o dialog work process at que todos os dados da impresso sejam passados para a estao onde est o frontend e o saplpd.
jluiz@cemig.com.br
Pgina 94
ACADEMIA
BASIS
Logical Spool Servers

Logical spool server uma camada que permite mapear spools lgicos para fsicos, permitindo efetuar o switch dinmico e balanceamento dos servidores. Um real spool server no ambiente R/3 uma instncia com pelo menos um spool work processes definido. Este mecanismo de definio lgica permite efetuar o switch facilmente entre servers reais que esto indisponveis sem interrupo do servio de impresso para os usurios. Como estas definies so configuraes do ambiente e portanto podemos utilizar o mecanismo de transportes de change requests do R/3 possvel definir toda uma arquitetura de impresso em um ambiente e posteriormente transporta-la para os demais sistemas do landscape.
Spool Request Management

O spool requests gerados no sistema devem ser gerenciados pelo administrador para garantir a disponibilidade do ambiente. O programa RSPO0041 deve ser schedulado em todos os sistemas para efetuar o trabalho de housekeeping e eliminar spools antigos do sistema. A transao SP01 o spool request viewer, que permite aos usurios ver seus requests e requisitar outputs ou eliminar spools. Administradores com autorizaes apropriadas podem ver todo o spool request do ambiente. A transao SPAD ou o programa RSPO0043 pode ser utilizado para checar a consistncia entre os spool requests, output requests e output datas so consistentes cada um por si e as referencias cruzadas entre eles. A verificao de problemas associados com os spool requests pode ser efetuada tanto pela SP01 quanto pela SM21 ou ST22. Existem objetos de autorizao especficos para diversas operaes de spool no R/3, seja protegendo determinados dispositivos de sada (S_SPO_DEV) ou limitando o poder de gerenciamento (S_SPO_ACT e S_ADMI_FCD) . O objeto S_SPO_PAGE limita o nmero mximo de pginas que um usurio pode imprimir em um determinado dispositivo. Para que esta autorizao tenha efeito necessrio ativar o parmetro de profile rspo/auth/pagelimit=1.
jluiz@cemig.com.br
Pgina 95
ACADEMIA
BASIS
R/3 Output Management

Atravs da opo de administrao estendida na SPAD, uma srie de funes avanadas podem ser escolhidas tais como : definio de device types, print controls, formats, page formats, OMS e character set.
Device Pools
O conceito de device pools permitir que se defina um pool de dispositivos de sada que podem ser referenciados atravs de um nico nome. Device pools so definidos especificando mtodo de acesso P e a lista dos dispositivos que o compem. Output requests podem ser enviados para todos os dispositivos que compem o pool simultaneamente ou pode-se requisitar que o sistema efetue o balanceamento de carga entre os dispositivos de sada da lista. Os dispositivos que compem a lista de um device pool podem ainda ser acessados individualmente como devices independentes. Para o caso de utilizarmos o balanceamento de carga temos que ter certeza que a rede e o gerenciador de impresso do sistema operacional tem bom tempo de resposta pois para balancear a carga o R/3 vai fazer query para saber o status do device.
External Output Management Systems (OMS)

O R/3 permite integrar ao seu ambiente sistemas externos de gerencia de impresso que podem se fazer necessrios em ambientes complexos. Esta comunicao efetuada atravs do XOM-API. Atravs da definio de um objeto real de OMS (ROMS) e de pelo menos um objeto lgico OMS (LOMS), os spool requests de um sistema R/3 podem ser passados para o sistema externo. Os devices no ambiente R/3 que sero gerenciados pelo sistema externo OMS so definidos com o mtodo de acesso E.
Spool Server and Requests Management

Qualquer instncia R/3 que possui spool work processes denominada um spool server. O R/3 permite a definio de um alternate spool server que pode assumir as tarefas de um spool server principal. Quando se assinala o campo non-exclusive spool server no atributo de um spool server o sistema R/3 efetua o balanceamento de carga dos requests de impresso. O sistema R/3 permite que se classifique os servidores e os dispositivos em categorias (High volume, Production, Desktop e Test) o que faz com que o sistema envie uma mensagem de warning quando se efetua o assign de um determinado dispositivo com um server incompatvel. Os requests enviados para um determinado spool server caem em uma fila de spool e so processados sequencialmente. Quando o server possui mais de um spool work process, os requests so manipulados paralelamente de forma que determinado request da fila poder ser enviado para um dispositivo antes de outro documento pesado que ainda esteja sendo formatado. Caso se defina um dispositivo com a opo de sequential request procesing, os output request para o dispositivos sero serializados. Esta definio pode causar impacto em todo o sistema de impresso, j que durante a presena de requests para o device, um determinado spool work process fica reservado para processar a fila do device que possui a caracterstica de processar os requests sequencialmente. Para permitir que os usurios acompanhem o andamento de seus requests, os spool work process questionam os devices sobre o sucesso das operaes. Uma vez que durante este tracking o spool permanece aguardando uma resposta, isto pode ser particularmente problemtico para impressoras remotas ou com baixa performance na rede. Esta opo pode ser desabilitada para um dispositivo de sada especificando a opo no longer ask for print requests in host spool. Ao se especificar o atributo monitoring using monitoring infrastructure, o device pode ser monitorado atrvs da rvore de MTEs do CCMS. Alm das opes da jenela de manuteno do device temos ainda os parametros para controle de time-out e retries (rspo/tcp*). jluiz@cemig.com.br Pgina 96
ACADEMIA
BASIS
Non-Standard Printers
Quando um determinado dispositivo de sada no possui device padro no R/3, possvel criar um driver personalizado para o dispositivo atravs da especificao de alguns objetos. A transao SPAD, em extended admin, fornece todos os mecanismos para formatar e testar o drive a ser utilizado pelo novo dispositivo. Antes de definir um novo dispositivo, verifique no OSS se j no existe disponvel o novo driver para ser baixado do sapservX. Se for necessrio criar realmente um novo driver cpie um j existente e altere o que for necessrio, sempre tentando manter o mais prximo do standard possvel (user references flag)
Character set
O character set especifica os cdigos internos armazenados no spool request e seus respectivos ASCII que sero impressos. um de para. Cada caracter tem um cdigo interno no R/3 (nenhuma relao com o ASCII), cuja lista pode ser visualizada atravs da SPAD (Full Administration SAP characters). possvel acrescentar caracteres nesta lista, utilizando os cdigos 9000 a 9999. Cada tabela de character set disponvel transcreve este cdigo interno R/3 para um determinado ASCII. Para adapter uma determinada tabela, necessrio inicialmente copia-la e ento efetuar as alteraes na cpia e salvando posteriormente as alteraes em um character set identificado por 9nnn (comea por 9)
Format, Page format e Format actions

Format identifica o papel utilizado pelo R/3 (letter, A4, etc.). Quando utilizamos formulrios que no so padres necessrio definir novos formatos pela SPAD. Os Page formats prov a interface entre o format e o SAPscripts, permitindo que os programas R/3 possam determinar o nmero de linhas por pgina, entre outros dados. Para definir format actions, ou seja, como determinado dispositivo manipula um determinado formato de impresso, necessrio editar o dispositivo de sada e acrescentar na sua opo de format as sequencias de caracteres para efetuar as operaes de impresso (printer initialization, new line, skip page, 12 char/inch, etc.)
Print controls
Os print controls determinam como um determinado dispositivo efetua determinadas operaes, como por exemplo imprimir em bold. Print controls so especficos de cada device e durante a formatao so convertidos para determinadas sequencias de caracteres. A sequencia correta deve ser obtida no manual da impressora, aps ter certeza que a SAP no disponibilizou driver para este device.
Message Control and EDI

O message control utilizado no R/3 para troca de informaes entre parceiros envolvidos em uma determinada regra de negcio. Os documentos gerados (EDI, fax, impresses, etc.) so normalmente gerados atravs de exits especficas dentro programas R/3 que so chamadas para formatar a sada desejada. Dependendo da customizao efetuada, o documento gerado enviado como parte da transao ou fica pendente para posterior envio. O EDI, Electronic Data Interchange, a troca de mensagens de negcio entre dois sistemas atravs de interfaces standard. A SAP no fornece um subsistema EDI no R/3, mas prov uma interface aberta para estes sistemas se conectarem. Esta interface baseada em Intermediate Documents, ou IDOCs. No R/3 todos os dados transferidos por EDI so transferidos atravs de RFCs entre os sistemas envolvidos.
jluiz@cemig.com.br
Pgina 97
ACADEMIA SAPconnect
BASIS
O SAPconnect uma camada que permite a comunicao do R/3 com outros sistemas externos, tipo fax ou mail servers. A conexo do R/3 com sistemas externos normalmente requer a especificao de interfaces externas, porm a conexo entre dois sistemas R/3 via SAPconnect pode ser feita diretamente. Estes adapters externos devem ser fornecidos por cada fornecedor interessado em se conectar com o sistema R/3. A SAP fornece um adapter para o Microsoft Exchange Server que pode ser configurado para integrar as duas ferramentas. Para configurar o SapConnect utilize a transao SC0T. Para maiores informaes sobre o SapConnect utilize as notas 34705 e 92950.
jluiz@cemig.com.br
Pgina 98
ACADEMIA
BASIS
Installation Check
Hardware e Software
Antes de comear uma instalao necessrio garantir que os requisitos mnimos do checklist de instalao sejam atendidos. No pacote de instalao existe um checklist completo que deve ser seguido. Para o hardware, certificar-se de que seja um hardware homologado pela SAP e de alta disponibilidade, alm de verificar ainda o nmero de processadores, memria RAM e disco disponveis. Para o software, verificar se a verso do sistema operacional se encontra atualizada e suportada pelo R/3, checar os utilitrios make do compilador C e a configurao do kernel. Na camada de rede, checar a configurao TCP/IP, o hostname em minuscula e com at 8 dgitos. A estrutura de rede dever prover IP fixo para os hosts dedicados ao R/3 e uma boa proteo de segurana. Quando se usam mais de um servidores interessante ainda ter uma rede privada de conexo entre eles de alta capacidade para garantir velocidade na comunicao dos application com a central instance, alm do compartilhamento das mquinas que compem o landscape.Para maiores detalhes veja a nota 23538. O sizing do hardware normalmente especificado pelos fabricantes baseado nas recomendaes da SAP e de suas prprias configuraes. Alm disto necessrio garantir uma boa distribuio de discos alm de uma proteo poe espelhamento e sistemtica de backup do sistema operacional.
Oracle Database
A verso do banco de dados dever ser compatvel com R/3 e com o sistema operacional. O database name ser o mesmo system id do R/3. Alteraes posteriores no nome do database no so simples de serem efetuadas. Para garantir a comunicao entre os processos atravs da rede, as profiles Oracle referentes a configuraes de network so requeridas: listener.ora, tnsnames.ora, sqlnet.ora e protocol.ora. O oracle ser instalado em uma configurao prpria de sua rvore de diretrios e diversas variveis de ambiente so setadas para apontar para os caminhos corretos. A distribuio dos discos no ambiente de banco de dados tem influncia direta sobre a performance do banco, devendo desta forma dedicar um cuidado especial a esta parte. Os redo log files devem ser espelhados (RAID I) por hardware e por software (oracle). Os arquivos sapdata devem, preferencialmente estar isolados entre si e de todo resto. Alm disto e havendo disponibilidade, distribua os tablespaces PSAPSTABD e PSAPBTABD em filesystem nicos. Filesystems crticos (online redo logs, archive, paginao do OS) no devem ser instalados nos mesmos discos dos datafiles, que por sua vez devem estar em discos distintos. Evite utilizar RAID 5 para online redo log, saparch e o tablespace PSAPROLL. Estes pontos tem influncia direta sobre a performance. Aps a instalao, por questes de segurana, a password dos contas oracle SYS, SYSTEM e SAPR3 devero ser alteradas. Durante a instalao do Oracle sero gerados alguns arquivos importantes, a saber : %oracle_home%\net80\database initSID.ora contm todas as informaes da instncia oracle initSID.sap contm todas as informaes para permitir o backup da instncia oracle initSID.dba contm todas as informaes para o SAPDBA conseguir administrar o oracle %oracle_home%\net80\admin listener.ora que contm informaes para o listener (no lado do servidor do banco de dados) saber onde encontrar uma determinada instncia tnsnames.ora contm os parmetros para um processo cliente do oracle (que no est no servidor do banco de dados) conseguir conectar com uma instncia sqlnet.ora contm informaes administrativas para os processos clientes do oracle protocol.ora contm o switch para o tcp.nodelay (opcional)
jluiz@cemig.com.br
Pgina 99
ACADEMIA
BASIS
A estrutura de diretrio do oracle baseada em duas variveis. O oracle_home normalmente o \orant e o sapdata_home normalmente o \oracle\SID. Alm destas variveis temos que diferenciar as rvores do lado oracle server e do lado oracle. A estrutura bsica da rvore : Server site \%oracle_home% \ rdbms80 \ bin \ net80 \ database \%sapdata_home% \ sapdata1 ... \ origlogA Client site \%oracle_home% \ rdbms80 \ net80 \ admin \ nlsrtl31 \ data \ nlsrtl32 \ data \ nlsrtl33 \ data
R/3 System
O system id (SID) de uma instncia R/3 dever ser nica no landscape e composto de 3 caracteres alfanumricos, sendo o primeiro alfabtico. Alguns nomes so reservados, devendo ser escolhidos cuidadosamente, j que qualquer alterao exigir a reinstalao do R/3. Alguns parmetros do kernel Unix so relevantes para a instalao e funcionamento do R/3. Verifique a sua configurao e efetue as alteraes necessrias de acordo com o manual de instalao OS Dependencies. O programa memlimits disponibilizado no CD de instalao pode ser utilizado para checar alguns destes parmetros. A instalao do R/3 dever ser executada em uma mquina que no deve possuir outro servio como pdc, bdc, etc. A estrutura de diretrio a ser utilizada j pr determinada pela SAP. Esta rvore contm dois ramos bsicos, os diretrios globais que sero compartilhados entre sistemas e os diretrios locais da instncia, a saber : \usr\sap (compartilhado como sapmnt e saploc) \ put \ tmp \ trans \ <SID> \ SYS \ profile \ exe \ run \ dbg \ opt \ global \ <instance_name> \ work \ data \ log
Uma instncia R/3 possui um nmero (2 dgitos) informado pelo administrador no momento da instalao e ser utilizado pelo R/3 para compor os nmeros das portas para diversos servios
jluiz@cemig.com.br
Pgina 100
ACADEMIA
BASIS
TCP/IP que sero utilizados pelos processos. Estes servios sero registrados pelo programa de instalao no %windir%\system32\drivers\etc\Services do host: Porta para o dispatcher da instncia: sapdpnn 32nn/tcp Porta para o servio de gateway: sapgwnn 33nn/tcp Porta para o message server: sapms<SID> 36nn/tcp Os gateways 97, 98 e 99 alm do dispatcher 99 so reservados para a SAP para os R/3 service programs (OSS, SapConnect, EPS e SapRouter respectivamente). Para verificar o ambiente TCP/IP utilize os programas sapntchk (command line) ou sapsychk (win32). Para maiores informaes sobre a analise do log produzido veja a nota 65761 O TMS dever ser configurado corretamente em um landscape para permitir o transporte entre os vrios sistemas R/3 que o compem. Cada transport domain possuir um suas rotas de transporte e um dos sistemas receber atribuio de domain controller. Se por questes de performance, os frontend no devero se conectar ao host do database, utilizando para isto application servers. Se o message server for instalado em outro host que no o do database, a DEFAULT.PFL dever informar esta nova configurao atravs dos parmetros SAPDBHOST e rdisp/mshost. Aps a instalao, a transao SICK (ou SM28) utilizada para efetuar um check completo de consistncias entre verses do kernel e database, garantindo assim que no existiro inconsistncias na instalao. Alm disso bom configurarmos o saprouter, importarmos os hotpackages atravs da SPAM e a linguagem portugues atravs da SMLG. Quando se utilizam vrios application servers, necessrio garantir a sincronizao correta do buffer atravs de parmetro da instance profile (sendon,exeauto). Configure corretamente o mecanismo para backup do ambiente, seja do database como tambm do sistema operacional e diretrios do R/3 e faa o backup de tudo.
jluiz@cemig.com.br
Pgina 101
ACADEMIA
BASIS
R/3 Workload Distribution

Overview
A ferramenta de instalao R3SETUP utilizada tanto para a criao de central instances (DVEBMGSnn) quanto de dialog instances (Dnn) no ambiente R/3. O sistema configura profiles iniciais que podem ser editadas seguindo a vontade do administrador para configurar novos servios. Atravs da definio de operation modes podemos distribuir os work processes (dialog, background, update) entre os diversos servidores que compem um sistema R/3. Os work processes de spool so distribudos atravs da definio das profiles pela RZ10. Uma vez que o usurio se logou a um determinado servidor do sistema, todos os seus dialog steps so despachados dentro daquela mesma instncia at o prximo logon. J as suas requisies de servios de spool, update e background podero ser atendidos por qualquer um dos servidores distribudos na rede.
Mechanism
Cada instncia R/3 possui seu prprio dispatcher e sua prpria queue de requisies organizada de forma FIFO first in first out, mantida na shared memory da instncia. Qualquer chamada de servio (outbound request) que no seja uma comunicao com o frontend e nem uma chamada RFC encaminhada pelo dispatcher para o message server. Isto aconter com os outbound requests para spool, update, enqueue e batch processamentos que a instncia no possuir work process para atender. A fila do dispatcher pode ser visualizada atravs do programa dpmon (nvel do sistema operacional) ou da transao RZ03, Edit -> Other views -> Dispatcher queues. Cada dispatcher organiza sua fila criando queues para cada tipo de work process: DIA, BTC, UPD, UP2, SPO, ENQ e uma fila NOWP para outgoing requests vindos destes vrios work processes. O tamanho default para cada uma destas filas 2.000. Caso a instncia no possua um determinado servio (por exemplo UP2), sua fila ter um tamanho de 5 requests apenas. O tamanho da fila do dispatcher mantida atravs do parmetro de profile rdisp/elem_per_queue. Caso ocorra um overflow na queue, ser gerada uma mensagem na SYSLOG. A monitorao das filas pode ser executada atravs da SM51, selecionando um servidor e requisitando Goto -> Queue information Para comparar a distribuio de carga entre os diversos servidores, a transao ST03. Atravs do Detail analysis menu possvel inclusive requisitar que as comparaes sejam exibidas em modo grfico: Compare all servers -> Graphics -> Avg response time/Dialog steps. Uma anlise do CPU time dos work process pela SM50 permite efetuar uma anlise para cada tipo de servio se o nmero de work process foi definido suficientemente. Como a distribuio dos servios pelo dispatcher feita de forma sequencial, os ltimos work processes de um determinado tipo com valores elevados de CPU indicam ocupao constante e portanto uma possvel espera excessiva de processos na queue deste tipo de work process. O incremento do nmero de work process, antes de ser feito, precisa ser analisado visando identificar se o recurso de hardware (principalmente memria mas sem esquecer a cpu) disponvel na instncia comporta mais work process. Evite o logon de usurios na central instance para evitar sobrecarga, j que normalmente esta instncia estar oferendo os servios de DB. Distribua os logons de usurios entre as instncias de dialog e faa o mesmo com a carga de spool e background.
Logon Load Balancing

O logon load balancing utilizado para dinamicamente distribuir os usurios entre os diversos servidores de um sistema. Isto trs uma srie de benefcios: Caso um server caia, os usurios podero continuar a se logar nos outros servers do sistema sem a necessidade de reconfigurao do saplogon
jluiz@cemig.com.br
Pgina 102
ACADEMIA

BASIS
Possibilidade de agrupar usurios de reas afins em servidores especficos com isto otimizando a utilizao dos buffers das instncias que somente contero dados e programas relacionados com aqueles usurios Utilizao racional de code pages especficas quando houver necessidade deste tipo de configurao (por exemplo japanese)
Para termos isto precisamos categorizar os usurios em grupos e configurar os frontends para um logon especfico em um grupo especfico e no mais um servidor especfico. A conexo neste caso feita com o message server (servio sapmsSID 36##/tcp) e no mais diretamente com os dispatcher (servio sapdp## 32##/tcp) O dispatcher inicialmente procurar avaliar entre os servidores disponveis no grupo aquele mais indicado para receber a conexo de logon e a ento encaminha o usurio para o dispatcher selecionado. O programa RSRZLLG0 utilizado para efetuar o balance baseado em critrios como tempo de resposta e nmero de usurios logados em cada server. Este programa roda a cada 5 minutos ou a cada 4 usurios que se logam e determina o server favorito para o logon a cada instante. Este balanceamento baseado em pesos que so dados aos itens. A nota 51789 descreve o critrio e como altera-lo para melhor se adaptar as suas necessidades. O default do sistema o tempo de resposta ter um peso cinco vezes maior que a quantidades de usurios. A transao SMLG pode ser utilizada para monitorar a lista global dos usurios logados (Goto -> User list), a distribuio de carga entre os servers (Goto -> Load distribution) ou ainda ver qual o server favorito para logon (Goto -> System diagnosis -> Msg. Server status area). Procure sempre especificar logon groups com mais de um server provendo assim uma maior disponibilidade para o sistema. Entretanto, no adianta colocar todos os servidores em todos os grupos pois estariamos prejudicando os buffers. Devemos sempre monitorar e procurar um ponto de equilibrio. Preferencialmente faa um agrupamento baseado nas reas funcionais como FI com CO, SD com MM, PP separado dos demais, etc. Em casos extremos podemos criar uma user exit para impedir que um usurio entre em um ou mais grupos.
Background Load Balancing

A tabela TBTCS exibe informaes sobre os jobs schedulados no ambiente. Esta tabela utilizada pelo batch scheduler para enfilerar os jobs. Atravs da transao RZ01 possvel monitorar os jobs que esto ultrapassando o tempo mdio de tempo de execuo e a transao RZ15 permite monitorar os interface-driven jobs. O global work process monitor (SM66) pode ser utilizado para analisar a distribuio de carga dos background jobs no sistema. No permita que jobs batch rodem na central instance. Deixe suas CPUs reservadas para os processos de update. Considere a possibilidade de especificar valores diferentes para o parmetro rdisp/btctime, o batch scheduler, entre os vrios servidores (por exemplo 61, 62, etc.). Com isto eles rodaro em tempos diferenties e efetuaro uma distribuio mais eficiente dos background jobs entre as instncias.
Spool Load Balancing

Considere a possibilidade de acrescentar as impressoras mais crticas ao Alert monitor. Na SM66 dever ser utilizada para identificar spool work processes super ou sub utilizados. A utilizao dos spool lgicos melhora distribuio de carga. Quando especificando um device, no utilize a opo Sequential Request Processing e habilite a opo Do not ask for print requests on host spool. Utilize preferencialmente os access spool methods do tipo local (L ou C) evitando utilizar os remotos (U).
Update Load Balancing

Cada sistema R/3 precisa ter definido pelo menos um update work process. recomendado ainda que pelo menos um update tipo 2 seja definido no ambiente para tratar as atualizaes que no so time criticals. O Dynamic Update Assignment cuida de distribuir os updates V1 e V2 entre os diversos
jluiz@cemig.com.br
Pgina 103
ACADEMIA
BASIS
servidores de update disponveis. Apesar de processado em work processes separado (quando disponvel), os updates V2 somente sero processados aps a poro V1 do processo tiver sido executada com sucesso. Quando um request de update disparado por um dialog server, o sistema verifica uma rea da shared memory denominada Update Dispatcher Information, para descobrir em qual server o update dever ser executado. Ele se baseia em algoritmos internos de balanceamento de carga (o dynamic update assignment) e a partir da o update request colocado na NOWP queue do dispatcher onde o update foi gerado. Os updates so distribudos em um processo cclico sequencial entre os servers disponveis obedecendo ao nmero de update work processes disponveis em cada um. Quando um ciclo completo de distribuio se fecha, o sistema inicia outro baseado no mesmo critrio. Este processo faz com que os updates sejam distribudos ao acaso fazendo com que updates pesados sejam distribudos aleatoriamente entre os servidores disponveis. Quando o algoritmo enderea um update para um determinado server, o message server entra em ao e movimenta o request da NOWP queue do server que gerou o request para a UPD queue do server que executar o servio Ao analisar os update work processes pela SM66, observe se o ltimo update de cada instncia mostra pouca ou nenhuma CPU. Alm disso o primeiro work process dever apresentar muito mais CPU que os demais. Se o sistema no apresentar este perfil, possivelmente estar havendo um gargalo no ambiente causado pela definio de poucos work processes de update. Use ainda a transao SM51 para exibir o maximum request wait. Este valor dever ser muito prximo de zero. Por outro lado caso existam muitos work processes com zero de CPU, certamente est havendo um excesso de recurso alocado. Para verificar a fila dos processos de update no dispatcher, utilize transao RZ03 (Edit -> Other view -> Dispatcher queue). A transao SM13 exibe o status do update. Nesta transao, atravs da opo Goto -> Server, podemos ainda verificar o nmero de updates enviados para cada server bem como informaes do dispatching. Por questes de performance, ao analisar o CPU time dos update processes em cada server, mantenha pelo menos um com 0 de CPU. Isto garante que no haver gargalos neste servio. Existe uma relao de custo benefcio em se manter os updates centralizados na central instance ou distribudos pelos servidores: Central instance: a vantagem que as instncias no precisaro manter programas de update de todos os mdulos otimizando assim a alocao dos buffers dos servidores do logon group. A desvantagem que no se faz uso do balanceamento de carga do update, que se encontra centralizado Distribudo pelas instncias: a principal vantagem o balanceamento distribudo do processamento de update, conforme descrito acima. A contrapartida que todas as instncias tero em seus buffers programas de update de todos os mdulos, j que quem distribui os processos o automatic load balancing de update. A configurao do update executada pelos seguintes parmetros de profile: rdisp/vbname: especifica o nome do servidor de update quando o automatic dispatching desabilitado rdisp/vb_dispatching: habilita o automatic dispatching. Este parmetro somente dever ser alterado quando explicitamente recomendado pela SAP rdisp/vb_context: seletor para partes do contexto de update rdisp/vb_included_server: lista dos servers que participam do dispatching. Quando no especificado o sistema assume todos os servidores que possuem updates configurados rdisp/vb_refresh_info: especifica o tempo em segundo com que haver um refresh da lista de dispatching rdisp/max_vb_server: mximo nmero de VB servers rdisp/wp_no_vb e rdisp/wp_no_up2: especificam os nmeros de update work processes (tipo 1 e 2) configurados na instncia
Configuration Summary
No existe uma regra especfica para o nmero de work processes configurados em cada instncia, devendo o nmero ser ajustado por observao da demanda. Recomenda-se apenas que se deixe sempre um work process de cada tipo com 0 de CPU garantindo a tima distribuio da jluiz@cemig.com.br Pgina 104
ACADEMIA
BASIS
carga. Existe uma recomendao informal da SAP que se configure 3 spool work processes por servidor de spool para que se tenha sempre um livre enquanto os outros dois estejam efetuando job quering e connection checking. Utililize a seguinte regra para definir a quantidade de work processes : Service Dialog Update Enqueue Background Message Gateway Spool R/3, System-wide >= 2 >= 1 1 >= 2 1 >= 1 >= 1 e <= 3 For each R/3 Instance >= 2 >= 0 0 ou 1 >= 0 0 ou 1 1 >= 1 e <= 3
jluiz@cemig.com.br
Pgina 105
ACADEMIA
BASIS
Quarta Semana Database Fundamentals

Oracle Overview
Uma instncia oracle o conjunto voltil de processos e estruturas de memria. Um banco de dados oracle um conjunto de arquivos de dados que so manipulados pela instncia oracle. Podemos dividir o Oracle em uma srie de estruturas de memria. A mais famosa entre elas a SGA (system global area) e ela um grande grupo de buffers de memria compartilhados, a saber : shared pool, database buffer cache e redo log buffer. Para acessar estas estruturas existem os processos que executam uma srie de tarefas de manuteno da instncia. Cada processo distinto, possui uma funo especfica, executado em background e assincronamente. Os principais processos so : pmon, smon, dbwr, lgwr, reco, lck ckpt, snp e arch. A shared pool uma poro de memria compatilhada que contm as reas chamadas de shared sql, library cache, data dictionary cache e sequence cache. Todas participam do processo e so as estruturas que contm os sqls que esto sendo execudados pelos mltiplos usurios. Essas reas contm ainda os comandos na forma interpretada e texto, a anlise dos comandos com os respectivos planos de execuo, informaes de dicionrios e geradores de nmeros sequenciais. O principal objetivo da shared pool viabilizar que um comando sql seja utilizado por diversos processos distintos. Uma nica shared sql area pode ser compartilhada por diversas aplicaes que usam o mesmo comando deixando mais reas em memria disponvel para os outros usurios e melhorando a performance de execuo de um comando, j que o plano de execuo estar definido em memria.
jluiz@cemig.com.br
Pgina 106
ACADEMIA
BASIS
O database buffer cache organizado em duas listas: a lista de blocos alterados e a lista dos blocos menos recentemente utilizados (LRU least recently used). Essa segunda lista contm os blocos livres, aqueles que esto em uso e inclusive blocos alterados. Quando um processo servidor precisa ler dados de um bloco do disco para o database buffer cache, ele pesquisa a LRU para localizar o bloco livre. Se encontrar um bloco alterado, movimenta-o para a lista de blocos alterados. Esse processo termina quando um bloco livre localizado ou quando um nmero especfico de blocos so pesquisados sem encontrar um bloco livre. O redo log buffer armazena todas as alteraes feitas em um banco de dados em memria. Todas as entradas de redo log neste buffer so escritas nos arquivos de redo log, que so usados para a recuperao do banco de dados, se necessrio. O Oracle cria um conjunto de processos que rodam em background para cada instncia, Esses processos executam diversas tarefas. Entre eles podemos destacar : DBWR O processo database writer escreve os blocos modificveis do database buffer cache para os arquivos de dados. Os dados mais antigos so escritos em primeiro lugar. O dbwr adia ao mximo a escrita dos blocos alterados para otimizao de I/O em disco para evitar aquela que uma das principais causas de queda de performance de um banco de dados. LGWR O processo log writer escreve todas as entradas de redo log para o disco. Os dados de redo log so armazenados em memria no redo log buffer, e no momento em que uma transao for efetivada ou o redo log estiver com preenchimento de pelo menos um tero, o lgwr escreve as entradas de redo log para os arquivos online redo log files. CKPT O processo de check point envia um sinal para o dbwr no momento do check point. Ele ento atualiza os headers dos control files e dos datafiles. SMON O processo de system monitoring efetua a recuperao da instncia em caso de falhas, durante a uma inicializao. Ele tambm limpa os segmentos temporrios que no esto sendo usados, liberando memria e recupera qualquer transao pendente no caso de uma falha fsica. Simplificando, o smon um monitor das aes do sistema detectando e corrigindo possveis falhas no sistema PMON O processo monitor executa a recuperao do processo de um usurio em caso de falhas. Ele limpa a rea de memria e libera os recursos que o processo usurio estava usando. Simplificando, o pmon um monitor das aes dos usurios detectando e corrigindo possveis falhas nos processos dos usurios ARCH O processo de archiver copia os arquivos redo log para fita ou mesmo outro disco, no momento em que um deles torna-se completo. Este processo geralmente est presente quando o banco de dados esta sendo utilizado no modo archivelog. RECO O processo de recover usado para resolver transaes distribuidas e pendentes. LCKn Os processos de lock (lckn) so usuados para controlar o lock entre instncias em uma configurao oracle parallel server. Dentro de uma instncia Oracle existem vrios processos que so criados quando a instncia entra em funcionamento. Eles se dividem em dois grupos : Dedicated shadow processes: que so os processos criados no Oracle para as conexes dos work processes. Existe uma relao de 1 para 1 entre estes processos e os work processes da instncia R/3 e eles s aparecem quando o R/3 est no ar Shared processes: so os processos criados no Oracle para gerenciamento e funcionamento da instncia que ir controlar o banco de dados. Eles tem atividades especificas e trabalham para a manuteno da instncia como um todo. Os dados so armazenados em datafiles organizados em blocos de 8k (8192 bytes). Estes blocos so carregados para uma rea comum da memria principal denominada database buffer pool. Sempre que uma leitura feita pelo menos dois blocos so carregados, um para header e outro para dados. Cada bloco do DB buffer pool contm um header com os dados das transaes que podero compartilhar o mesmo bloco. O nmero de entradas no header configurado pelo parmetro INIT<SID> do .ora. As alteraes efetuadas nos dados do banco de dados so feitas inicialmente no database buffer com a imagem anterior copiada para a rea de rollback e refletidas na redo log files garantindo com isso a segurana transacional dos dados. Estes redo log files so espelhados por questes de segurana. Os control files no so espelhados mas deve possuir mais de uma cpia, tambm por motivos de segurana. Para verificar quantos control files existe utilizem a view v$controlfile atravs
jluiz@cemig.com.br
Pgina 107
ACADEMIA
BASIS
de sql ou da ST04. Para criar mais uma cpia do control file, copie o arquivo para o local desejado e altere o parametro control_file no initSID.ora acrescentando o novo caminho, tudo isto com o oracle no estado NoMounted. Se for necessrio acessar o controlfile com o banco for a do ar o estado do banco deve ser Mounted. Os comandos SQL executveis ficam armazenados em outra rea da memria denominada Shared SQL area que tambm parte do shared pool. Nesta rea temos ainda Library cache com os cursores de execuo dos comandos SQL e a Row cache, com informaes dos objetos no dicionrio Oracle. Os work processes do R/3 se conectam com os shadow processes no Oracle com o usurio SAPR3. Caso esta conexo caia, os work processes tentam reconexo com o Oracle seguindo a parametrizao feita nas profiles (default ou instance) atravs das variveis rsdb/reco_trials e rsdb/reco_sleep_time. Uma instncia Oracle aceita 3 tipos de conexes de seus clients: dedicated, que a utilizada pelo R/3, Combined e Multi-thread. Os principais problemas de performance esto associados a shared pool (shared sql area e row cache), ao uso dos data buffers e a redo log. Outro ponto de preocupao o acesso a disco, sua estruturao de alocao e a possvel conteno causada pelo acesso ao disco. Obs: Conceito Importante - O check point uma marca de sincronismo entre todos os datafiles e a online redo logfiles. Sempre que ocorrer um switch no online redo logfiles gravado um check point para garantir a segurana e sincronismo. Se o banco estiver em archivelog mode, a offline redo logfile archivada no diretrio saparch logo aps o switch.
Starting and Stoping the Database

O banco de dados Oracle passa por trs fases distintas ao ser inicializado: Nomount phase: a instncia Oracle construda (shared pool) a partir das informaes parametrizadas no arquivo init<SID>.ora Mount phase: o control file aberto e suas informaes referentes aos logs e datafiles so obtidas mas no podemos acessar os datafiles atravs de um sql. Open phase: todos os files so abertos. Se o ltimo shutdown no foi realizado com sucesso, o sistema efetua um rollback das transaes inflight e retorna todos os arquivos ao ultimo ponto de sincronismo (check point). Os processos podem ento comear a submeter requests ao banco de dados aberto. O shutdown pode ser realizado em trs formas distintas tambm, a crittio do administrador: Shutdown Normal: O sistema para de aceitar novas conexes e aps o encerramento de todas as conexes j efetuadas os datafiles so fechados, o database desmontado e a instncia finalmente sai (shutdown) Shutdown Immediate: Apenas os comandos j em andamento so terminados. Todas as conexes so derrubadas atravs do PMON e caso exista alguma transao inflight, feito um rollback antes da instncia sair atravs de um shutdown consistente, ou seja, um check point gravado. No sapdba ainda temos shutdown immediate force que retira o R/3 antes de derubar o oracle. Shutdown Abort: Em casos de emergncia apenas, este comando derruba todas as conexes e retira a instncia do ar colocando o banco de dados em um estado de inconsistencia. O prximo startup precisar efetuar um recovery das transies que permanecero inflight, at que a base volte a ser consistente (roll foward)
Oracle Shared Processes

Uma instncia Oracle possui trs processos cuja finalidade gravar os dados da SGA (shared global area) para os datafiles Database writer (DBWR): que assincronamente grava os blocos alterados do data buffer para os database data files. Checkpoint process (CKPT): que acelera o processo de gravao dos checkpoints na instncia Oracle
jluiz@cemig.com.br
Pgina 108
ACADEMIA
BASIS
Logwriter (LGWR): que grava em modo sncrono as alteraes efetuadas nos data buffer e logadas na redo log buffer para os online redo log files
Um banco de dados em produo deve sempre rodar em ARCHIVELOG mode. Neste caso um quarto processo, o archive (ARCH), grava os online redo log files para a rea de archive da instncia. Os arquivos do online redo log files funcionam de forma cclica e a cada switch, o file que estava sendo usado transferido para a rea de archive. O parmetro da init<SID>.ora, log_archive_start=TRUE ativa o processo de archive na instncia. O processo ARCH se baseia nos parmetros log_archive_dest (default $ORACLE_HOME/saparch) e log_archive_format para gerar o archive na offline redo log area. Quando o online redo log file foi transferido com sucesso, o respectivo file fica disponvel para ser sobrescrito no processo cclico de utilizao dos files. Caso no haja espao disponvel na offline redo log area para a gravao do novo file, o online redo log file no liberado e consequentemente ir travar a instncia quando o ciclo requisitar novamente o online redo log file, devendo a rea ser liberada para que o Oracle continua com o seu funcionamento normal.
R/3 Oracle Structure

A estrutura de tablespaces do R/3 no Oracle obedece a um padro especfico de nomes: PSAP<name>[D para data e I para index]. Por exemplo, se uma rea de dicionrio do R/3 ficar armazenada nos tablespaces PSAPDDICD (dados) e PSAPDDIC (ndices). Esta nomenclatura obrigatria para o uso do R/3 e suas ferramentas. As tablespaces que normalmente so criadas nas instalaes so : Prefix Tablespace Ext. Meaning SYSTEM Oracle DDIC PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP ROLL TEMP EL<release> ES<release> LOAD SOURCE DDIC PROT CLU POOL STAB BTAB DOCU USER1 D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I D ou I Segmentos de rollback Area temporaria normalmente utilizada para sort Mdulos do ambiente de desenvolvimento Fontes do ambiente de desenvolvimento Mdulos das janelas e relatrios Fontes das janelas e relatrios Dicionrio abap Tabelas do tipo log Tabelas cluster Tabelas pool Tabelas de dados mestres ou transparentes Tabelas de dados transacionais ou transparente Documentaes, sapscripts e sapfind Tabelas do cliente
Owner Oracle rdbms Oracle rdbms Oracle rdbms Basis Basis Basis Basis Basis Aplicaes Aplicaes Aplicaes Aplicaes Aplicaes Aplicaes Aplicaes
Os datafiles que compem o tablespace tambm devero possuir uma estrutura prpria de diretrios: $ORACLE_HOME / sapdatan / <name>[d/i]_n / <name>[d/i].datan. O sapdatan normalmente um mount point (sapdata1, sapdata2, etc.). Caso o tablespace do exemplo acima tivesse dois datafiles e alocado no sapdata5, os arquivos teriam o seguinte nome: /oracle/<SID>/sapdata5/ddicd_1/ddicd.data1 e .../ddicd_2/ddicd.data2. Os data files de ndices obedeceriam o mesmo critrio, apenas o nome seria ddici, e no ddicd (.../ddici_1/ddici.data1) Todos os objetos alocados nos tablespaces PSAP... pertencem ao usurio SAPR3. Os tablespaces SYSTEM, PSAPROLL e PSAPTEMP possuem objetos que pertencem aos usurios SYS ou ao SYSTEM. O usurios que se logam em um sistema R/3 no possuem objetos nas tabelas do Oracle, apenas armazenam linhas nas tabelas do banco de dados atravs da conexo efetuada com o user SAPR3 A estrutura de diretrio do Oracle com o R/3 obedece a seguinte hierarquia : /orant (oracle home)
jluiz@cemig.com.br
Pgina 109
ACADEMIA
BASIS
database: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora, init<SID>.sap, etc.). bin: executveis Oracle (no NT ele est no /orant/bin) /net80/admin: arquivos de configurao do NET8 /oracle/<SID> (sapdata home) sapdata1,2,...: onde se localizam os data files origlogA, origlogB: online redo log files mirrlogA, mirrlogB: mirror online redo log files saptrace/background: Oracle alert files saptrace/usertrace: trace files dos shadow oracle processes sapereorg: rea de trabalho para reorganizaes, compress de backup files, etc. saparch: offline redo log area e logs do BRARCHIVE sapbackup: BRBACKUP e BRRESTORE logs sapcheck: sapdba logs (-next, -check, -analyze)
Dentro do database, existem basicamente trs arquivos de parametrizao: init<SID>.ora: parametrizaes da instncia Oracle init<SID>.dba: parametrizao do sapdba init<SID>.sap: parametrizao das ferramentas BRBACKUP e BRARCHIVE Vrias variveis de ambiente parametrizam o usurio <sid>adm : ORACLE_SID=<SID>: nome da instncia DBS_ORA_TNSNAME: seta o <SID> do banco que ser conectado atravs do tnsnames.ora ORACLE_HOME: o diretrio home do oracle (/oracle/<SID>) SAPDATA_HOME e SAPDATAn: aponta para diretrios especficos contendo dados Alm dos usurios Oracle SYS e SYSTEM, existem os seguintes usurios no unix : ora<sid>: usurio unix pertencente aos grupos dba e oper <sid>adm: usurio unix pertencente ao grupo oper OPS$<sid>adm: usurio definido no oracle como identified externally J no NT temos : <sid>adm: usurio NT pertencente ao grupo ora_SID_dba sapservice<sid>: usurio NT pertencente ao grupo ora_SID_oper OPS$<sid>adm: usurio definido no oracle como identified externally Quando o parmetro OS_AUTHENT_PREFIX=OPS$ codificado no init<SID>.ora, isto indicar que o usurio <sid>adm (OPS$<sid>adm) poder se conectar ao oracle sem autenticao. Isto ser necessrio para determinadas tarefas restritas de administrao. Neste caso a autenticao do usurio fica a cargo do sistema operacional. O mecanismo de conexo dos work processes com o shadow process no Oracle funciona da seguinte forma: o work processes tenta a conexo atravs do usurio SAPR3/SAP. Caso a senha tenha sido alterada, o que aconselhvel, a conexo recusada e o work process tentar uma conexo atravs do usurio OPS$<sid>adm (que no exige autenticao) e acessa a tabela SAPUSER (cujo owner o prprio user OPS$<sid>adm) e atravs dela possui a senha para o SAPR3 e refaz a conexo. O programa chdbpass (no unix) quando utilizado para alterar a senha do usurio SAPR3 j grava nesta tabela OPS$<sid>adm.SAPUSER a nova senha. O NT que no possui este programa disponvel o que torna necessrio a incluso manual da senha na tabela quando se altera o usurio via alter user. A conexo remota dos work processes entretanto com o banco R/3 atravs do user OPS$ somente se dar se o parmetro REMOTE_OS_AUTHEN estiver setado para TRUE.
NET8 Basis
A comunicao dos work processes com o Oracle se d atravs de comunicao TCP/IP atravs da rede. A camada Oracle que interpreta e aceita estas conexes o NET8. Para que o NET8 aceite
jluiz@cemig.com.br
Pgina 110
ACADEMIA
BASIS
conexes atravs da rede, o listener do Oracle precisa estar ativo. O utilitrio lsnrctl80 utilizado no database server para dar start e stop no processo tnslsnr que executar o servio. Trs arquivos configurados no .../net80/admin do oracle configuraro o servio NET8: tnsnames.ora: contm a lista dos servios para todos os bancos de dados acessados na rede sqlnet.ora: contm, no lado client, informaes do default domain alm de parmetros opcionais de diagnsticos usados para trace e logs do client listener.ora: usado no database server e contm Oracle system Ids com o quais o Oracle poder receber conexes e parametrizaes do listener
Database Monitoring
Vrias transaes so utilizadas no R/3 para monitorar a base de dados: A DB16 um system check monitor, a DB12 o monitor de backup, a DB02 a transao utilizada para monitorar os objetos (tableas, ndices, tablespaces) do banco. Alm destas, a ST04 o monitor de performance e a DB14 o monitor das logs das atividades administrativas do banco.
jluiz@cemig.com.br
Pgina 111
ACADEMIA
BASIS
Backup Estrategy
Database Backup
A estratgia de backup da base de dados necessria para garantir a recuperao de uma base de dados que pode falhar por diversos fatores, sejam fsicos (crash de disco), lgicos (operao indevida nos aplicativos) ou fatores externos (fogo, agua, greve, etc). Atravs de cenrios que iremos estudar, possvel fazer full recoveries (recuperao total) dos data bases ou ainda recuperaes point in time (recuperao total em um ponto do tempo passado) a partir de uma boa estratgia de backup. Operaes de recovery, por serem crticas, exigem documentao detalhada, estratgia estudada alm de skill especfico dos administradores de banco de dados. Ou seja, antes de tomar qualquer ao aps um problema, tenha certeza do que est sendo feito e de que a ao a melhor opo entre outras analisadas. Os files que compem uma base de dados Oracle podem ser divididos em cinco grupos: Os data files so os arquivos que contm os dados da aplicao propriamente ditos. aconselhvel que sejam protegidos por espelhamento (RAID V ou superior) Os online redo log files so os arquivos onde so gravadas as logs de transaes no banco de dados e so espelhadas por definio atravs das mirrlogs Os control files so os arquivos que possuem as informaes de controles referentes aos datafiles e a base de dados. O Oracle mantm cpias deste file em mais de um filesystem do ambiente, definido por parmetro na initSID.ora Profiles so os arquivos de configurao da instncia oracle Offline redo log files so as cpias das online redo efetuadas pelo ARCH no momento dos switch. recomendado que estes files sejam espelhados e, quando transferidos para fita, sejam replicados em fitas distintas Um processo de backup de banco de dados copia para outro dispositivo os data files, os online redo log files, os control files e as profiles. Um processo de backup do offline redo log file copia os offline redo log files e as profiles para outro dispositivos. Para garantir a integridade fsica da base de dados ou seja, garantir que as tabelas e blocos estejam fisicamente ntegros necessrio efetuar logical data checks atravs de ferramentas oracle como o utilitrio dbv (database verify). Temos tambm que garantir a integridade das fitas backupeadas necessrio efetuar um physical data check, que verifica a integridade fsica das fitas gravadas atravs da leitura dos dados backupeados na fita.
Backup Types
Um processo de backup offline executado com a instncia em shutdown e os seguintes arquivos so copiados: data files, online redo log files, control file e profiles (init<SID>.ora, .sap e .dba). Um processo de backup online executado com a instncia ativa e os seguintes arquivos so copiados: data files, control file e profiles. Estas cpias online no so consistentes, j que o processo de update no banco continua sendo efetuado pelos usurios. Um recovery a partir de um online backup somente tem sentido com o cruzamento das logs (redo logs) geradas no decorrer do processo. Um processo de partial backup pode ser utilizado para diminuir o tempo gasto no processo. Neste caso apenas alguns tablespaces sero copiados em cada dia at fechar um ciclo. Independente do processo utilizado (offline ou online) este backup inconsistente e precisa das offline redo log de todo o ciclo para permitir um recovery do database. Outro processo para diminuir a janela de backup atravs do paralelismo do backup com a utilizao de vrios drives de fita. Este processo reduz significantemente o tempo de backup e restore, sendo porm caro pelo hardware envolvido.
jluiz@cemig.com.br
Pgina 112
ACADEMIA
BASIS
Backup and Recover Diagram

Backup
ArchiveLog
NoArchiveLog
On-Line
Off-Line
Complete Recover
Incomplete Recover with reset log
Reset
Data Loss
Vrias so as causas que podem causar a perda de dados em uma base de dados. Erros lgicos podem ocorrer pela deleo indevida de objetos do banco de dados (um data file), um drop em uma tabela ou ainda por erro de aplicativo que provoca a perda de dados. Erros lgicos so recuperados atravs de um full database restore seguido de um point in time recovery at o momento imediatamente anterior a causa da perda da informao. A ausncia de um offline redo log file durante um processo de recovery causar a perda de todas as informaes subsequentes, j que o processo no permite a aplicao dos offline seguintes ao que foi perdido. Por este motivo importante a manuteno de pelo menos duas cpias dos offline redo log files em dispositivos diferentes para garantir uma recuperao com uma salva-guarda de contingencia. Uma outra causa de necessidade de recuperao o chamado disaster recovery, efetuado por causas fsicas, como por exemplo um crash de disco. A manuteno de cpias de backup em cofres garantem inclusive a possibilidade de recuperao de todo o ambiente computacional em caso de perda total das instalaes fsicas do cpd.
Backup Recommendations
Alteraes nas estruturas dos arquivos afetaro os restores subsequentes, como ocorre por exemplo quando um data file acrescentado a base de dados. Processos como este que causam a alterao dos control files devero ser seguidos de um backup adicional imediato do banco de dados para que o processo de recuperao, se houver, no seja afetado pelo diferente estado do banco de dados. O ponto crtico de uma alterao estrutural do banco de dados a necessidade de ter ao menos uma cpia do novo datafile e a estrutura gerada no control file. Sem isto impossvel recuperar o banco na nova estrutura ou fazer um log-foward aps este evento.
Backup Cycle
A SAP recomenda um ciclo de backup de 4 semanas. Isto significa que os offline redo log files sero backupeados diariamente e mantidos por 28 dias. O backup online deve seguir a mesma regra, jluiz@cemig.com.br Pgina 113
ACADEMIA
BASIS
ou seja uma cpia a cada dia til do ciclo. importante ainda que tenhamos em cada ciclo pelo menos um backup offline, um check de consistncia do backup e check dos datafiles do banco de dados. Esta recomendao bsica, sendo o ideal fazer tudo isso pelo menos uma vez a cada semana. recomendvel tambm que os arquivos do backup online fiquem em fitas diferentes do backup do offline redo log. Isso viabiliza novas alternativas para os planos de contingencias caso as fitas tambm apresentem problemas.
Final Recommendations
Utilize as ferramentas providas pela SAP para efetuar o backup (BRBACKUP e BRARCHIVE) e tenha certeza que elas esto configuradas corretamente. Para um evetunal restore do banco de dados utilize a ferramenta BRRESTORE. Estas ferramentas que efetuam o backup e o restore trabalham integradas ao sapdba e se baseiam em logs prprias gravadas no sistema operacional para direcionar o seu funcionamento. bom lembrar que alm do banco de dados, necessrio manter backup consistente de outros objetos R/3, tais como archiving, interfaces, executveis e do sistema operacional. No adianta muito ter o backup da base de dados se no tivermos o R/3 e o Oracle instalados e com os arquivos de controles que iro hospedar esta base de dados S a correta implementao de uma boa estratgia de backup a garantia para a recuperao do sistema sem perda de informaes em caso de falhas.
jluiz@cemig.com.br
Pgina 114
ACADEMIA
BASIS
Tape Management
Tape Pools
Os utilitrios BRBACKUP e ao BRARCHIVE que permite a gerencia do pool de fitas utilizadas na estratgia de backup, permitindo encontrar as fitas necessrias no momento do backup e do recovery e garantindo a sua proteo contra utilizao das fitas antes do momento desejado. O sistema trabalha com um pool separado para as fitas utilizadas pelo BRBACKUP e outro para o BRARCHIVE evitando misturar as fitas destinadas aos backups de datafiles e dos offline redo log files. As fitas inicializadas para um pool no podem ser utilizadas no outro pool O nmero de fitas utilizadas no pool do BRBACKUP depender de vrios fatores, como tamanho do banco, durao do ciclo, capacidade das fitas, frequencia e paralelismo dos processos de backup. J o nmero de fitas do pool utilizado pelo BRARCHIVE depender do tamanho do ciclo, nmero de redo logs criadas no ambiente (atualizaes), capacidade das fitas e frequencia dos offline redo backups.
Tape Initialization
As fitas so inicializadas pelo brbackup ou brarchive atravs da opo i force (inicializa novas fitas, fitas no utilizadas alteriormente pelo SAP ou fitas bloqueadas para gravao), i v <tape_name> (renomea fitas que no esto bloqueadas para uso) ou i v SCRATCH (para fitas scratch). Na prtica o processo de inicializao consiste na criao de um arquivo .tape.hdr0 no inicio da fita para identifica-la no momento de uso. Dentro deste arquivo temos informaes do nome da fita, do noma da instncia na qual ela est sendo utilizada, o timestamp da ultima utilizao e o numero de utilizaes feitas at o momento. Os dois utilitrios sempre acessaro este arquivo para decidir se a fita a esperada e se ela est disponvel para uso. Eles levaro em conta os parmetros (expir_period com default de 28 e tape_use_count com default de 100) definidos na init<SID>.sap, sendo que o tape_use_count excedido provoca apenas uma mensagem de warning. O padro de nome a ser utilizado nas fitas <SID><B|A>99 onde o B|A representa o grupo onde ela ser utilizada (backup ou archive) e 99 um nmero sequencial. O nome das fitas que esto disponveis para utilizao esto nos parmetros volume_backup e volume_archive do init<SID>.sap.
Tape Locking
O mecanismo de lock protege a fita de sobre escrita. Este mecanismo funciona baseado no parmetro expir_period que fornece o ciclo de proteo da fita baseado no timestamp do ltimo backup l gravado (informao no label). Este mecanismo denominado lock fsico. Um outro mecanismo de proteo denominado lock lgico e baseado nas tabelas SDBAH e SDBAD. Elas contm informaes das fitas gravadas no perodo e so mantidas pelo BRBACKUP e BRARCHIVE. Baseado nas entradas desta tabela e no pool de fitas gravado nos parmetros volume_backup e volume_archive, o sistema verifica se uma determinada fita est liberada para gravao reforando o mecanismo de lock das fitas. O BRARCHIVE pode se basear em informaes de suas logs para efetuar o lock lgico, podendo desta forma ser executado mesmo quando o banco se encontra offline. A fita seguinte a ltima utilizada no pool a selecionada para utilizao.
Tape Selection
As ferramentas SAP oferecem trs mecanismos para seleo das fitas: mecanismo automtico permite que o BRBACKUP e BRARCHIVE selecione a fita baseado em seus mecanismos de lock e no pool de fitas fornecido nos parmetros volume_backup e
jluiz@cemig.com.br
Pgina 115
ACADEMIA
BASIS
volume_archive. A chamada destes programas com a opo q permite verificar qual ser a prxima fita selecionada para uso. Se for necessrio utilize a opo q check para verificar se a fita que est montada a fita esperada pelos utilitrios. mecanismo manual de seleo atravs da opo SCRATCH. Quando uma fita inicializada com o nome SCRATCH inserido no sistema, o BRBACKUP e o BRARCHIVE a aceita em substituio a fita requisitada e grava o novo label nela antes de comear a gravao. til por exemplo para substituir uma fita do pool danificada. Alternativamente, possvel substituir o pool de fitas informado no init<SID>.sap pelo parmetro SCRATCH. Neste caso o sistema no sugere uma fita, apenas pede uma cujo operador fica responsvel pela manuteno do seu schedule. Ainda neste caso os mecanismos de lock funcionam apenas para proteo de uso indevido das fitas mecanismo de seleo externa utilizado atravs da opo v e til quando um shell ou produto externo utilizado para gerenciamento das fitas. O label neste caso tambm ser checado pelos mecanismos de lock lgico. Todo este processo utiliza uma outra ferramenta de interface com o mundo externo que o BACKINT.
Tape Layout
O layout bsico de gravao da fita praticamente o mesmo para o BRBACKUP e o BRARCHIVE (as diferenas ento marcadas abaixo), a saber : tape.hdr0 init<SID>.ora (configurao do oracle) e init<SID>.dba (configurao do sapdba) init<SID>.sap (configurao do brbackup e brarchive) diferenas Para o BRBACKUP DB files Control files Para o BRARCHIVE Offline redo log files reorg.log (informaes de reorganizaes, restore e recover) e struct.log (histrico das alteraes de estruturas do banco) detail.log (log do processamento) summary.log (lista dos processamentos j realizados)
jluiz@cemig.com.br
Pgina 116
ACADEMIA
BASIS
Scheduling, Performing and Monitoring Backups

Backup Tools Features
Para fazer um backup podemos utilizar uma das ferramentas : Transao DB13 - DBA Planning Calendar - onde possvel schedular backups peridicos em uma instalao R/3 Utilitrio SAPDBA onde possvel ativar backups espordicos de forma interativa por menus e vrias outras operaes de administrao e operao do oracle BRBACKUP e BRARCHIVE onde e possvel realizar backups a partir de linha de comando
Backup profile parameters

Alguns dos parmetros podem possuir valores default definidos na profile init<SID>.sap, como por exemplo o tipo de compresso, comando para compresso, utilitrio para cpia, dispositivo a ser utilizado, etc. Os utilitrios brbackup e brarchive atualizam as tabelas SDBAD e SDBAH, checa o lock de fitas e gera logs especficas das atividades efetuadas sempre levando em conta a parametrizao feita neste arquivo.
tape_size Parameter
O parmetro tape_size da init<SID>.sap define o volume de dados que cabe no modelo de fita utilizado tanto para o BRBACKUP quanto o BRARCHIVE. Este parmetro importantssimo j que a sua m especificao pode causar mal funcionamento do processo de backup. Atravs da especificao do parmetro tape_size os utilitrios de backup (BRBACKUP e BRARCHIVE) calculam o volume de dados que pode ser enviado para cada fita, dimensionando desta forma o nmero de fitas que sero necessrias durante o processo. Quando mal dimensionado pode causar o desperdcio de mdia ou, pior ainda, erro no processo de gravao. O utilitrio dd utilizado no processo de cpia acusa erro quando atinge o end-of-tape. J o utilitrio cpio, desde que no esteja trabalhando em modo parallel, consegue passar os dados para um volume subsequente, porm este volume no ser reconhecido pelas ferramentas de gerencia de fitas por ter sido requisitado ao longo do processo e no possuir o arquivo de identificao da fita (.tape.hdr0). O ideal portanto que este parmetro especifique um valor 10% menor que a capacidade real da fita, como margem de segurana. Quando utilizamos compresso por hardware, o valor do tape_size dever ser ainda um pouco mais folgado, uma vez que a taxa de compresso varia dependendo do tipo de dado armazenado. A nota 8707 d todos os detalhes sobre esta especificao de tape_size. Para distribuir os files pelas fitas, o brbackup utiliza informao da taxa de compresso dos files. Este clculo da taxa de compresso dever ser efetuado uma vez a cada ciclo atravs do comando brbackup k only []. Quando utilizado tape stations com hardware compression, o parmetro compress_cmd da init<SID>.sap dever ser setado para compress b 12 c $ > $ (em unix). A compresso por software efetuada no diretrio especificado (compress_dir) e consumir ciclos de CPU da mquina que est efetuando o backup.
Phases of Database Backup

Um backup online executado com o banco de dados ativo causando durante o processo uma certa concorrncia nos datafiles. Os seguintes processos so efetuados durante o processo. Salva a sada de um backup control file em disco Obtm os files names que sero backupeados Backup do tape header, e das profiles (inits ora, sap e dba) Coloca os tablespaces em backup mode, efetua backup dos datafiles e retira o backup mode Backup do control file jluiz@cemig.com.br Pgina 117
ACADEMIA

BASIS
Faz um log file switch Backup de logs (reorg.log, struct.log, detail.log, summary log)
O backup offline efetuado com o database em shutdown, porm o brbackup deixa a instncia no estado exato em que se encontrava no incio do processo (up ou down): Start no database, se o mesmo se encontra em shutdown Obtm os files names que sero backupeados Shutdown no database Backup do tape header, e profiles Backup dos datafiles Backup dos online redo log files Backup do control file Start no database Backup de logs (reorg.log, struct.log, detail.log, summary log) Deixa o banco no estado inicial, (up ou down) * Eventualmente, se o backup offline no for completo os online redo log no sero backupeados
Database Backup Check and Monitoring

Blocos de dados danificados no banco de dados somente so identificados quando o Oracle tentar manipular este bloco. O utilitrio dbv da Oracle efetua o check de um datafile quanto a estas integridades. Esta verificao lgica da integridade dos dados pode ser realizada em tempo de backup atravs da especificao do parmetro verify use_dbv ou w use_dbv. Este processo faz com que os files sejam lidos da fita aps gravados e transferidos para o diretrio de compress (compress_dir) onde so processados pelo utilitrio dbv da Oracle. O processo alm de detectar blocos corrompidos garante a disponibilidade da fita. aconselhado que seja efetuado uma vez por semana ou no mnimo uma vez no ciclo. Como este processo pelo menos duplica o tempo gasto no backup, possvel adiar a execuo do verify atravs de uma execuo posterior de uma simulao de BRRESTORE, que pode inclusive ser executado em outra mquina. (Para maiores informaes de datafiles corrompidos veja a nota 99962). A opo de verificao da integridade lgica (-verify use_dbv) verifica a integridade dos blocos Oracle porm no garante que o file gravado na fita seja idntico ao file existente no disco. Esta verificao da integridade fsica dever ser efetuada uma vez no ciclo, que ocorrer a nvel binrio com a especificao do parmetro (-verify ou w). Este processo de verificao fsica somente pode ser executado no processo de backup offline e tambm ir provocar a leitura da fita para que o file seja transferido para a rea de compress. Este processo duplica o tempo de backup e, diferentemente do anterior, no pode ser postergado para um posterior BRRESTORE. O BRBACKUP grava logs em files no diretrio sapbackup e nas tabelas SDBAH e SDBAD que devem ser checados constantemente. Os logs gravados obedecem a um padro prprio de nomenclatura (b<timestamp>.<ext>) cuja extenso depende do tipo de backup selecionado. As transaes DB12 e DB13 tambm permitem acompanhar a execuo dos backups
Offline Redo Log Files Backup

O processo Oracle ARCH responsvel pela movimentao as Online redo log files durante o switch de log. Estas logs so transferidas para a rea saparch e devem ser transferidas para fitas de tempos em tempos. Este processo denominado Offline redo log backup e efetuado pelo programa BRARCHIVE. O BRARCHIVE loga o status dos offline redo log files em um arquivo denominado arch<SID>.log, que se localiza na saparch e grava linhas referente s atividades executadas com os redo log files : ARCHIVED: estado indicando que o file foi arquivado SAVED: indicando que uma gravao para fita foi efetuada COPIED: indicando que uma segunda cpia foi efetuada DELETED: indicando que o file foi deletado do diretrio
jluiz@cemig.com.br
Pgina 118
ACADEMIA
BASIS
O BRACHIVE possui uma serie de opes para o backup dos archive logs. A SAP aconcelha a especificao do parmetro cds no BRARCHIVE que faz com que esta gerencia de backup duplo de offline redo log files com posterior deleo seja efetuado automaticamente. Outra boa opo e a opo f (fillup) onde o brarchive grava os files e continua verificando a saparch de tempos em tempos. Qualquer offline que aparea ento gravado at que a fita esteja cheia. Como no BRBACKUP, devemos utilizar a opo verify ou w para efetuar um check fsico dos arquivos gravados e recomendado que seja efetuado uma vez no ciclo. A monitorao do processo de offline backup dever ser efetuado atravs da transao DB12 e atravs da monitorao do arch<SID>.log no diretrio saparch. Atravs da opo o possvel forar a gravao de mais informaes na log.
Log File Cleanup

Os logs gerados tanto pelo BRBACKUP quanto pelo BRARCHIVE so utilizados posteriormente pelo SAPDBA para tomar as aes corretivas e parametrizar o BRRESTORE. Estes files porm vo se acumulando nos diretrios e precisam ser eliminados de tempos em tempos. O SAPDBA possui funes administrativas de clenup no s destes logs como tambm dos traces e logs geradas pelo Oracle e pelo prprio sapdba. A limpeza dos logs de backup e archive se baseia nos parmetros expir_period_* da init<SID>.dba. Estes parmetros devero ser adaptados de acordo com o ciclo de backup adotado na empresa. A chamada a estas funes poder ser executado interativamente via sapdba ou atravs da chamada sapdba cleanup em linha de comando ou via algum utilitrio de agendamento do sistema operacional.
Freespace Administration
Os offline redo log files so transferidos para a rea de archive saparch atravs do servio Oracle ARCH. Se estes arquivos no forem backupeados para fita e deletados, a rea poder estourar, o que causa a parada do Oracle conhecida como archiver stuck. Neste caso a instncia para por no poder sobrescrever um online redo log file ainda no transferido para a rea de offline. Este problema somente ocorre se o ARCHIVELOG mode estiver ativado, o que padro em ambientes produtivos. Atravs da DB12 deve-se monitorar a rea livre no diretrio (ou atravs de df k) e tomar medidas preventivas (archive) antes que o problema ocorra. Outra soluo que pode ser adotada a definio de um arquivo dummy grande o suficiente para que, em caso de archiver stuck, ele possa ser removido dando ao sistemas mais alguns minutos enquanto se processa o archive. Caso o sapdba no mais responda a comandos, ative o brarchive via linha de comando
One-Run Strategy
A estratgia One-Run backup consiste em efetuar o backup e o archive em uma nica chamada ao brbackup atravs da especificao de parmetros prprios (brbackup m all c a cds c). Neste caso apenas uma fita do pool backup (volume_backup) utilizada para armazenar os dois backups. Esta estratgia porm s pode ser utilizada se o backup dos datafiles e todos os offline redo log files couberem em uma nica fita. A soluo neste caso o uso de paralelismo no backup (mais de um drive) ou ento adotar outra estratgia para o backup. Esta soluo possui o incoveniente dos datafiles e ds offline redo log files estarem na mesam fita. Alm disso, em caso de um archiver stuck ocorrer, esta opo no poder ser usada, j que o brbackup tentar se conectar com o banco que se encontra travado.
Further Documentation
Para maiores informaes sobre backup e recover, veja as notas 96896, 19909, 99088, 71058, 8707, 33630, 99962, 23345, 100400 e 83699. jluiz@cemig.com.br Pgina 119
ACADEMIA
BASIS
Advanced Backup Techniques

One-Run Strategy
Consiste em executar em uma nica chamada o backup dos datafiles e offline redo log files. ativado atravs da chamada brbackup m all c a cds -c Principais vantagens: Atende a maioria das instalaes, sendo portanto recomendada pela SAP Efetua os dois processos em uma nica chamada, garantindo backups consistentes Principais desvantagens: backup e os offline redo devem caber em uma nica fita
Consistent Online Backup

um backup online contendo dados logicamente consistentes, o que equivale dizer que todos os offline redo log files gerados durante o backup tambm sero salvos na mesma fita. Pode ser utilizado para realizar um point in time recovery. ativado atravs da chamada brbackup t online_cons. Os offline redo log files gravados neste processo no so documentados no arch<SID>.log, j que so processados pelo brbackup
Parallel Tape Support

Atravs do parmetro tape_address do init<SID>.sap, o brbackup permite a gravao de vrias (at 4) devices em paralelo. Neste caso o parmetro exec_parallel deve ser setado para 0 e os utilitrios vo disparar o processo de cpia (dd ou cpio) um por device fsico. O processo de offline redo log file backup permite at 2 devices atravs da especificao do parmetro tape_address_arch. O BRRESTORE tambm ir utilizar os vrios devices em paralelo Principais vantagens: Menor janela de backup e restore
Partial Database Backups

uma forma de executar o backup de um ou mais tablespaces por vez ou at parte dos tablespaces de cada vez, de tal forma que em um intervalo menor que o ciclo adotado, todos os tablespaces sejam copiados. Durante um recovery com este tipo de backup, todas as offline e online redo log files geradas desde o incio do primeiro tablespace devem estar disponveis. . ativado atravs da chamada brbackup m <objects> e completado por um brbackup m all f <periodo>. Principais vantagens: Menor janela de backup Principais desvantagens: Administrativamente mais complexo Maior tempo de restore
Backing Up Data Tablespaces Only

Uma outra opo para diminuir a janela de backup atravs da especificao para copiar apenas os tablespaces que contenham dados, ignorando os que contm apenas ndices ou estejam vazios. . ativado atravs da chamada brbackup m all_data
jluiz@cemig.com.br
Pgina 120
ACADEMIA
BASIS
Principais vantagens: Diminui o volume de dados que sero backupeados Principais desvantagens: Aumenta o tempo de restore j que ser necessrio reconstruir os ndices
Two-Step Disk Backup

Inicialmente o backup feito para uma rea em disco (direcionado pelo parametro backup_root_dir), que um processo bem mais rpido. Em um segundo step, os arquivos so transferidos do disco para a fita. ativado atravs da chamada brbackup d disk e 4 que faz o primeiro step e para o segundo step b last d tape. Nesta opo tambm podemos fazer o primeiro step de forma paralela. Para isso basta utilizar o parametro exec_parallel e um conjunto de diretrios destinos para o backup em disco. Principais vantagens: Diminui sensivelmente a janela de indisponibilidade ou concorrncia sobre o database Um restore pode ter seu tempo sensivelmente diminudo, j que os dados do ltimo backup permanecem no disco Principais desvantagens: necessrio um gasto maior com discos fsicos apenas para o backup
Structures-Retaining Database Copy

um processo que consiste em copiar toda a rvore do Oracle home para um novo diretrio. um processo que pode ser utilizado por exemplo para transformar um data base de filesystem para raw device, e vice versa. ativado atravs da chamada brbackup d disk_copy e parametrizado pelo parmetro new_db_home da init<SID>.sap. Principais vantagens: Diminui a janela de backup (disco para disco) e agiliza um possvel restore Principais desvantagens: Investimento em hardware (disco) alm da complexidade administrativa maior
Split Mirror Disk Backups

Consiste em abrir o espelho (split mirror) e efetuar o backup a partir de outro host no qual o espelho ser montado. um processo que reduz drasticamente o downtime durante o backup que dever estar em backup mode ou offline apenas durante o processo de quebra (split) dos espelhos, que dura apenas alguns poucos minutos. . ativado atravs da chamada brbackup t online/offline_split d tape Principais vantagens: Baixssimo downtime No h impacto no database server, j que o backup realizado a partir de outro servidor onde o espelho montado Principais desvantagens: Preo elevado da soluo
jluiz@cemig.com.br
Pgina 121
ACADEMIA
BASIS
SAP Tools and Oracle Standby Database

um mecanismo que consiste em um outro server com configurao idntica ao database que se deseja backupear, permanecendo porm em estado de mount. A partir de um sincronismo inicial, apenas os offline redo log files so responsveis por ir atualizando (via NFS) a verso do database da instncia de standby, que possui ainda o diretrio sapbackup compartilhado via NFS. Os offline backups sero transferidos para a nova instncia atravs do comando brarchive sd d disk f w. Na instncia de standby os offline so backupeados com a opo brarchive ssd f m <delay> e os datafiles com a opo brbackup t offline_standby Principais vantagens: No h downtime no ambiente produtivo Principais desvantagens: Administrativamente mais complexo e exige investimento alto em hardware para replicar os ambientes Alteraes na estrutura do banco produtivo precisam ser replicadas manualmente para o ambiente de standby
External Backup Tools Using BC-BRI

a utilizao de ferramentas externas para a execuo do backup que se comunicam com as ferramentas da SAP atravs de uma interface SAP denominada BC-BRI. A ferramenta deve utilizar as ferramentas brbackup e brarchive da SAP, mantendo desta forma a facilidade de monitoramento via CCMS e permitindo a manuteno de todas as logs, o que permite o restore e recovery a partir do sapdba. Esta opo configurada na init<SID>.sap pelos parmetros backup_dev_type = util_file_online/offline e ainda util_par_file = init<SID>.utl, que parametriza a ferramenta backint Principais vantagens: Muito depende da ferramenta utilizada, que pode inclusive oferecer maiores facilidades de gerenciamento de fitas que as oferecidas pela SAP Principais desvantagens: Investimento normalmente elevado em hardware e software
jluiz@cemig.com.br
Pgina 122
ACADEMIA
BASIS
Restore and Recovery

Database Errors
Os erros que podem ocorrer em aplicativos que utilizam bancos de dados so os seguintes: Statement errors, que uma tentativa de entrada invlida em uma tabela. O oracle cuida de abendar a transao e efetuar possveis rollback Process errors, que uma falha na comunicao entre os processos client e os servios oracle. Qualquer falha recuperada pelo oracle Instance error, que pode causar um queda da instncia, mas que recuperada no prximo startup pelos prprios mecanismos do oracle User error, que provocado por uma ao acidental, como um drop table ou delete de linhas indevidamente Media errors, que so provocados por um crash de disco ou um delete datafile. Os user e media errors devem ser recuperados atravs da ao do DBA, efetuando operaes de restore e recovery. O sapdba oferece recursos para a maioria das recuperaes, porm eventualmente pode ser necessrio utilizar ferramentas Oracle na recuperao
Scenario
Uma instncia R/3 com banco de dados Oracle tem todos os seus datafiles normalmente com o status online e read/write. A sincronizao das alteraes efetuadas nestes files mantido atravs de um mecanismo de tempo. O Oracle utiliza o conceito de timestamp para esta sincronizao, que um inteiro que incrementado durante certas aes que so efetuadas no database. Este valor ento gravado pelos processos DBWR e CKPT nos header dos datafiles e control files no checkpoint. O Log Sequence Number (LSN) que incrementado por 1 a cada log switch um exemplo de dado de sincronizao. O Oracle mantm tambm um nvel mais sofisticado de sincronizao das transaes atravs so System Change Number (SCN) que incrementado pelo commit ou pelo processo de checkpoint. As anlises de cenrios seguintes assumiro que foi executado um full backup no LSN 10 e que ocorreu um erro posteriormente no LSN 38
Partial Restore and Complete Recovery

O crash ocorrido no LSN 38 causou uma perda da funcionalidade do database, deixando o banco inconsistente. O partial restore and complete recovery o processo de recuperar o banco de dados at o momento imediatamente anterior a ocorrncia do erro. O conceito de partial restore consiste em retornar apenas os datafiles que foram avariados. Aps este retorno o banco perde o sincronismo e no mais poder ser startado. Para ressincronizar o banco de dados, o oracle abre o banco em modo mount, avalia as informaes gravadas no header dos files e comea o recovery requisitando os offline redo logs que foram gerados desde o mais antigo database file, em sequencia, e reaplica as alteraes logadas (before images) at sincronizar todos os files com o mesmo SCN. O prximo start do banco ir efetuar um rollback das transaes que permaneceram inflight neste processo. O banco reaberto, est operativo e apenas os dados no commitados no momento do crash sero perdidos
Database Reset
Um motivo qualquer, por exemplo um upgrade, deixa o banco em um estado inconsistente que se percebe somente no LSN 38, e se deseja retornar o sistema para a posio do ultimo offline backup efetuado(LSN 10). Este processo exige um full offline backup. jluiz@cemig.com.br Pgina 123
ACADEMIA
BASIS
O database reset esta operao de retornar o banco a situao exata do offline backup atravs de uma operao de full restore. Este processo retorna os datafiles, online redo logs e control files originais (LSN 10). Como estes files foram todos copiados a partir de um offline backup, o banco retornado fica com o status consistente (mesmo LSN), no necessitando de nenhum processo de recovery. Quando o banco reaberto, ele recomea a criar redo log files a partir do LSN 10. Desta forma sero regerados os offline redo logs 11, 12, ..., 38, etc. O perigo consiste em se necessitar de um full restore posteriormente e se escolher os offline redo logs das duas diferentes direes. necessrio um trabalho administrativo aqui, seja para eliminar as logs antigas manualmente ou providenciar um novo backup offline to logo a LSN atinja o valor anterior, provendo o sistema de um novo ponto para restore. Este processo sempre resulta na perda dos dados gerados aps os backup offline, que so sobrescritos no processo e suas offline redo logs ignoradas.
Point in Time Recovery

Esta uma situao em que se deseja retornar o banco at um ponto imediatamente antes de um determinado fato ter acontecido (digamos na LSN 26), eliminando assim as suas consequncias sobre a base de dados. O primeiro passo efetuar um full restore de todos os data files, seja a partir de um offline ou de um online backup. Os control files neste caso devero especificar a situao da estrutura do banco no ponto em que se deseja parar o recovery. Se o banco sofreu alteraes estruturais durante este perodo, necessrio uma anlise e interferncia manual do DBA. O prximo passo o efetuar o incomplete recovery. O banco de dados aberto em modo mount e todas as offline redo log files necessrias at atingir o ponto especificado so requisitadas sequencialmente e aplicadas na base de dados. Este point in time poder ser um timestamp (recover until time) ou uma determinada offline redo log (recover until cancel), a critrio do DBA. Aps um point in time recovery o banco de dados normalmente aberto com a opo de reset logs (alter database open resetlogs), o que significa que o LSN reinicializado e as redo logs comeam a ser geradas a partir do nmero 1 novamente. Isto somente no ocorrer se durante o processo o DBA resolver aplicar todas as logs disponveis, efetuando assim um complete recovery. A partir deste momento no mais possvel efetuar recovery da base de dados (logs foram resetadas) e um full backup deve ser efetuado imediatamente.
How to Proceed and Who Should Manage the Problem

Qualquer necessidade de restore e recovery deve ser analisado com calma para decidir a melhor estratgia a ser seguida. Em caso de dvida jamais se deve tomar decises e/ou aes aleatorias. Decises/aes apressadas e erradas tendem a agravar o problema. Em caso de dvida, sempre consulte DBAs com experincia em processos de recuperao de bases de dados. Analise cuidadosamente a causa do problema, os backups disponveis, os offline redo log files disponveis e comece a desenhar os possveis cenrios de recuperao, decidindo qual deles o melhor a ser escolhido. Havendo tempo e disponibilidade, faa uma cpia full offline da base de dados que possibilite retornar o problema se o cenrio de recuperao piorar a situao tomando rumos no previstos. Caso o ciclo de backup tenha sido bem estruturado, o DBA tem sempre um grande nmero de backups disponveis para proceder a recuperao. A opo inicial ser sempre pela mais recente, que minimizar qualquer necessidade de recovery
Partial Restore Using SAPDBA

O SAPDBA executa o partial restore and complete recovery atravs de seis fases: 1. Check database: check do status dos files do banco
jluiz@cemig.com.br
Pgina 124
ACADEMIA
BASIS
2. Find backup files: a partir das logs de backup determina aquelas que podero ser utilizada, sugerindo sempre a mais recente 3. Restore backup files: copia dos database files de volta para o disco 4. Find archive files: determina os offline redo log files necessrios para o recovery 5. Restore archive files: copia os offline redo logs necessrios de volta para o disco 6. Recover: cria recover scripts para efetuar a operao de recover Este mtodo de recuperao simples e o mais seguro de ser efetuado, j que se aplica a maioria dos casos de perda de dados. Se os control files ou os online redo log files foram perdidos, verifique o help do R/3 (DBA Oracle) pois existem outros mecanismos mais rpidos para corrigir este problema ao inves de voltar um backup.
Database Reset Using SAPDBA

O processo de reset database atravs do sapdba com um full offline backup ir sobrescrever os datafiles, control files e online redo log files e permite que aps o restore o banco seja aberto em mount e o DBA proceda um recover a partir do svrmgrl (server manager). Neste caso especifico, operao manual do svrmgrl, no chamamos de database reset mas esta pode ser uma opo para alguns cenrios de recuperao. Quando se efetua um reset database a partir de um online consistent backup os data files e control files so sobrescritos, assim como todas as offline redo log files, devendo portanto ser salvas anteriormente pelo brarchive, conforme aconselhado pelo sapdba. Posteriormente o banco ser aberto com a opo resetlogs.
Full Restore and Recovery Using SAPDBA

Esta a opo do sapdba que corresponde ao point in time recovery. Como este processo envolve a perda de dados, um full offline backup recomendado antes de iniciar o procedimento, alm de salvar todos os offline redo log files. Este processo poder partir de um full offline, full online ou online consistente backup. Caso se tenha efetuado uma alterao na estrutura do banco, recomendado que se faa um backup da estrutura alterada para que no caso de um restore e recovery as alteraes possam ser reaplicadas a partir da sua log no sapreorg.
jluiz@cemig.com.br
Pgina 125
ACADEMIA
BASIS
Storage Management
Space Management
Todas as tabelas e ndices do Oracle so organizadas em data blocks armazenados nos tablespaces. Estes data blocks com R/3 so de 8K. A necessidade de crescer um tablespace efetuada atravs da incluso de datafiles ao tablespace. Esta operao quando efetuada pelo sapdba, no final do processo o usurio direcionado para tirar um backup do tablespace alterado garante que o tablespace poder ser recuperado em caso de um crash posterior . Quando uma tabela ou ndice necessita de mais rea, alocado um segmento contguo (declarado no catlogo oracle) de data blocks no tablespace com tamanho definido pelo parmetro NEXT de definio da table/index. Caso o espao contguo no esteja disponvel ocorrer um erro ORA-1653 ou ORA-1654 (tabela ou ndice). Uma tabela ou ndice inicialmente alocada baseado no parmetro INITIAL e posterior extents de acordo com o parmetro NEXT at um limite MAXEXTENTS. Na tentativa de superar o maxextents, ocorrer um erro ORA-1651 ou ORA-1652 (tabela ou ndice). Os demais parmetros da clusula STORAGE do Oracle (PCTFREE, PCTUSED PCTINCREASE) no devem ser alterados exceto sob recomendao explcita da SAP. e
Fragmentations
As linhas de dados das tabelas e ndices vo ocupando os data blocks e quando h necessidade de mais espao e alocado um segmento NEXT. Estes segmentos no necessariamente estaro contguos ao longo do tablespace, o que causar a denominada external fragmentation ou fragmentao a nvel do tablespace. Tabelas que contm raw fields, colunas opcionais ou registros de ndices so armazenados de forma compactada. Com isto nem todas as linhas dentro de um data block possuem o mesmo tamanho. A deleo de linhas destes objetos ir produzindo gaps internos nos data blocks denominados internal fragmentation ou fragmentao a nvel da tabela.
Fragmentations in Data Blocks PCTFREE and PCTUSED

Os parmetros PCTFREE e PCTUSED determinam a forma como os objetos sero trabalhados dentro dos data blocks. Enquanto o espao livre de um datablock no atinge o PCTFREE, ele aceitar novas inseres. Quando este valor atingido, o data block para de aceitar inserts assumindo que o espao livre restante ser utilizado para possveis crescimentos de linhas por update. Qualquer insert subsequente ser direcionado para outro data block disponvel no segmento. Somente quando aps deletes no data block causarem a disponibilidade de um espao livre inferior ao PCTUSED, este data block retornar a aceitar inserts. Quando o update de uma linha no cabe na rea reservada pelo PCTFREE, a linha migrada para outro data block. Apesar de ruim, no R/3 este fato no tratado com relevncia. A gerencia dos data blocks que esto disponveis para inserts executada atravs de uma tabela denominada free list. A m especificao destes parmetros para determinados objetos poder causar uma grande movimentao dos data blocks nesta free list, o que ruim para a performance. A Oracle recomenda que a diferena entre o PCTFREE e o PCTUSED seja de pelo menos de tamanho suficiente para caber uma linha. Isto significa que basta um delete para que o data block retorne para a free list. A SAP utiliza como padro os valores de 10% para o PCTFREE e 40% para o PCTUSED..
Daily Monitoring: SAPDBA -check

O check database efetuado pelo sapdba efetua uma srie de verificaes na base de dados e nas configuraes do Oracle que cobrem a quase totalidade dos problemas comuns que podem ocorrer no dia a dia de um DBA Oracle com o R/3. Atravs da DB13 deve-se schedular este check dirio
jluiz@cemig.com.br
Pgina 126
ACADEMIA
BASIS
(atravs do comando sapdba check) para monitorao da base de dados. Os dados analisados so carregados na tabela DBMSGORA e podem ser monitorados atravs da DB16. Os parmetros utilizados para comparao durante o check pdem ser configurados atravs da transao DB17.
Tablespace Extension
O critrio de alocao de data blocks dos objetos Oracle definido a partir dos parmetros INITIAL, NEXT e MAXEXTENT. O INITIAL define a alocao inicial, NEXT o tamanho das alocaes next que podero ocorrer MAXEXTENTS vezes. Devemos sempre lembrar que uma definio destes parmetros que atendia uma determinada tabela/ndice, pode se tornar obsoleta a medida que uma tabela comea a crescer. Por exemplo, um alocao NEXT de 16K faz sentido para uma tabela de 100K de tamanho, mas se torna completamente sem sentido quando esta tabela tem por exemplo 1G. O R/3 mantm uma tabela denominada TGORA (ou IGORA para ndices) que contm especificao da parametrizao para diversos ranges de tamanho de tabelas/ndices. Estas tabelas so organizadas por categorias de tabelas, de acordo com o atributo especificado para cada tabela no dicionrio de dados (SE11). Estas tabelas com seus ranges limitados de valores STORAGE colocam ordem nos valores dos extents alocados nos tablespaces permitindo que um database v sempre gerando gaps de tamanhos mltiplos que podem ser reaproveitados de forma otimizada por posteriores alocaes Para auxiliar a tarefa de adaptao contnua dos parmetros de storage dos objetos da base de dados, o sapdba possui a opo next que percorre todos os objetos e, atravs de um algortmo prprio adapta os parmetros de storage destes objetos para os valores encontrados nas faixas destas tabelas. Esse processo fundamental para a gerencia de fragmentao dos tablespaces e deve ser efetuado regularmente em uma base de dados.
Tables and Indexex Monitoring

A transao DB02 permite a monitorao das tabelas e ndices da base de dados do R/3. Os dados exibidos nesta transao so recolhidos pelo report RSORATDB na tabela MONI. Este programa deve ser schedulado para ser rodado pelo COLLECTOR_FOR_PERFORMANCE MONITOR. Este coletor roda de hora em hora e se baseia na tabela TCOLL para verificar o schedule de vrios reports e dispara-los conforme especificao. O RSORATDB normalmente tem schedule dirio na TCOLL. Atravs da DB02 tambm podemos monitorar objetos crticos (cuja prxima alocao de extent no encontrar espao disponvel no tablespace), objetos com elevado volume de fragmentao (muitos extents), taxa de crescimento, entre outros dados. Para maiores informaes verifique as notas 12103 e 16083.
Analyzing Storage Allocation: SAPDBA -analyze

O Oracle analyse utilizado para atualizar as estatsticas referentes as alocaes de storage, grau de fragmentao e distribuio dos dados. Estas informaes sero utilizadas pelo CBO Cust Based Optimizer. O utilitrio poder ser schedulado via sapdba atravs da opo analyze. possvel ainda analisar tabelas individualmente pelo sapdba ou atravs da DB20. O processo de anlise pode ser executado em modo ESTIMATE (amostragem) ou COMPUTE (full anlise). Os ndices e seus dados so analisados por ANALYSE INDEX VALIDATE STRUCTURE, porm este mtodo efetua um lock nos objetos durante a anlise. Durante a anlise da fragmentao interna atravs dos relatrios gerados pelo mtodo analyze, verifique sempre se a diferena entre EMPTY e NEVER_BEEN_USED. Diferenas grandes indicam fragmentao. Grande diferena entre USED_BY_BTREE e USED tambm indicaro fragmentao de ndice.
jluiz@cemig.com.br
Pgina 127
ACADEMIA
BASIS
Reorganization Basics
O processo de reorganizao tem por finalidade eliminar os problemas de fragmentao relacionados com as estruturas dos objetos. Atravs de uma poltica atenta de monitorao do database e correta especificao dos segmentos NEXT (atravs do sapdba next), esta necessidade ser naturalmente minimizada. O processo de reorganizao consiste na seguintes sequencia de passos: export dos dados, drop dos ndices, drop da tabela, create da tabela, import dos dados, create index. Atravs do sapdba, todos os scripts necessrios para executar estes passos so criados e chamados na seqncia correta sem nenhuma interferencia no processo a ser executado. Vrias so as causas que apontam para uma necessidade de reorganizao: Fragmentao elevada nos ndices ou tabelas, apontado por elevado volume de extents M distribuio das tabelas nos tablespaces ou ainda dos prprios tablespaces ao longo dos discos, gerando hot spot disks Atravs do sapdba, a reorganizao efetuada em duas fases: na primeira cria os scripts que executaro os passos a serem executados para aquele mtodo de reorganizao escolhido e verifica se existe rea suficiente nos filesystems. Na segunda fase do processo estes scripts so iniciados em uma sequncia por ele estabelecida e executam a reorganizao. Entre estas duas fases o DBA pode determinar o start imediato (em foreground ou background), ou se deseja postergar o start para mais tarde. Esta ltima opo pode ser utilizada por exemplo por DBAs experientes que desejam alterar os scripts criados para manipulao dos parmetros de storage dos objetos, por exemplo. Sempre que se efetua uma reorganizao de tabelas, os seus respectivos ndices tambm sero reorganizados. O inverso no verdadeiro
Os erros a seguir so os mais comuns durante o processo de reorganizao : Os datafiles onde os ser feita a reorganizao no comporta a segunda cpia do objeto ou a nova alocao a ser implementada diretrio sapreorg no comporta o export que ser feito durante a reorganizao tablespace PSAPTEMP no comporta a recriao de um indice da tabela que esta sendo reorganizada
Phases and Types

Existem vrios tipos de reorganizao que podem ser manipulados pelo sapdba: Reorganizao de um nico objeto: utilizado para eliminar fragmentao interna, reduzir o nmero de extents ou movimentar objetos entre tablespaces Reorganizao de uma lista de objetos: reorganiza uma lista de objetos especificados em um arquivo ASCII, localizado no diretrio de trabalho Reorganizao de tablespace: reorganiza todos os objetos pertencentes ao tablespace, mantendo a estrutura de datafiles Reorganizao de tablespace com datafiles: reorganiza todos os objetos do tablespace permitindo ainda a realocao dos seus datafiles. Movimentao ou renaming de datafiles, que no encarado como um processo de reorganizao
jluiz@cemig.com.br
Pgina 128
ACADEMIA Methods
BASIS
O processo de reorganizao de tabelas dropa a tabela durante o processo, havendo portanto perigo de se perder dados. Os mtodos utilizados so os seguintes: Export/import: utiliza os comandos Oracle EXPORT e IMPORT para extrair e recarreagar os dados. SAPDBA unload/load e SQL loader: mais rpido que o anterior, porm exige um pouco mais de memria Os mtodos abaixo, quando utilizados, no exigem a exportao dos dados: Create tableas select: gera uma tabela auxiliar, copia os dados e posteriormente dropa a tabela original e da um rename na auxiliar Alter index/rebuild: recria um novo ndice na PSAPTEMP utilizando o ndice existente e o copia para o tablespace destino, dropa o ndice antigo e ativa o novo. Recriate index: o ndice dropado e recriado
Options
Durante o processo de reorganizao podemos especificar vrias opes que, salvo algumas excees, podem ser combinadas entre si: Compress extents: a fragmentao ser reduzida para apenas 1 extent (INITIAL) Reduce object size: o sapdba tenta analisar qual a quantidade real de memria necessria e realoca o novo storage baseado neste valor Chop = yes: o export dos dados se d atravs de um pipe file, permitindo splitar o dumpfile em vrios arquivos menores, atendendo as limitaes do sistema operacional (2G em alguns casos). Esta opo estar disponvel a partir do momento em que se especifica o parmetro chop_util_name na init<SID>.dba Compress = yes: um dumpfile do export comprimido Parallel export/import: o export e import distribudo atravs de vrios processos paralelos ORACLE parallel clause: utiliza a facilidade oracle para acelerar o processo de reorganizao
jluiz@cemig.com.br
Pgina 129
ACADEMIA
BASIS
Performance Monitor
Performance Issues
A performance de um database Oracle est relacionada com quatro fatores bsicos: No layout fsico e lgico do banco No desempenho do aplicativo Na configurao da memria No CBO Cust Based Optimizer
Cost-Based Optimizer Reasons for performance problems

O CBO um mecanismo introduzido no Oracle que determina a estratgia mais eficiente para acessar um determinado dado, baseado nas tabelas especificadas, nos campos informados na clusula WHERE e nos ndices disponveis nas tabelas. O CBO computa todas as estratgias disponveis e escolhe aquela que sai mais barata em termo de acessos. Para ter parmetros de comparao, o sistema precisa se basear em estatsticas atualizadas referentes s tabelas e ndices, como por exemplo nmero de linhas, nmero de data blocks e nmeros de valores distintos em cada coluna da tabela. Estas estatsticas ficam armazenadas no dicionrio do Oracle e so recolhidas atravs do comando Oracle analize table. Informaes antigas ou inexistentes, assim como informaes incorretas sobre a distribuio dos dados poder induzir o otimizador a tomar decises incorretas sobre o melhor caminho a seguir.
Refreshing the object statistics

Estes problemas porm so facilmente resolvidos atravs de um refresh das estatsticas ou ainda atravs de um ajuste fino no procedimento SAP para as rotinas de analyse efetuadas atravs do processo two-phase (check e analyze). Os processos mais crticos de performance podero eventualmente ser ajustados atravs de mudana no critrio de cust-based para rule-based ou finalmente por alteraes no aplicativo.. A SAP recomenda que somente se utilize as ferramentas SAP (SAPDBA e CCMS) para atualizar as estatsticas da base R/3, j que existem regras particulares que quando no forem seguidas podero introduzir srios problemas de performance. Com a finalidade de diminuir o tempo envolvido no refresh das estatsticas, a SAP introduziu o conceito da estratgia two-phase. Este procedimento consiste em uma primeira passada onde ser determinado quais objetos necessitaro de refresh e numa segunda fase apenas os objetos selecionados sofrero o refresh. O comando a ser executado na primeira passada o sapdba checkopt [options]. Ele determina quais tabelas precisam de refresh e armazena sua deciso na tabela DBSTATC. Esta deciso tomada baseado no critrio de que o nmero de linhas da tabela alterou em mais de 10% (para tabelas pequenas) ou 100% (para tabelas grandes). A segunda passada feita pelo comando sapdba analyse [options] e efetivamente atualiza os dados estatisticos que forem necessrios (normalmente para os objetos com flag ativo na dbstatc).
Modifying the standard procedure

A tabela DBSTATC contm campos como o nome do objeto, o mtodo utilizado (se estimate ou compute), o percentual ou nmero de linhas a ser analisado e ainda um tag indicando se a tabela necessita de refresh. A transao DB21 permite efetuar alteraes e novas entradas nesta tabela. A nota 122718 indica regras e tabelas crticas que devero ser observadas.
jluiz@cemig.com.br
Pgina 130
ACADEMIA
BASIS
Repetindo o processo : A primeira fase (sapdba checkopt) grava uma log no diretrio sapcheck (<timestamp>.opt) e deve ser monitorado aps a execuo pela transao DB14 A segunda fase (sapdba analize DBSTATCO) efetua um refresh apenas dos objetos que estiverem flagados na DBSTATC. Aps a execuo, as linhas permanecero na tabela DBSTATC porm o flag de refreshable retirado O procedimento standard da SAP no criar nenhuma estatsticas para tabelas pool e cluster retirando inclusive qualquer estatstica porventura existente. Isto garante que o Rule-Based optimizer seja utilizado no acesso a estas tabelas. Este procedimento do Oracle de selecionar o rulebased quando no possui estatsticas disponveis setado pelo parmetro opmizer_mode = choose da init<SID>.ora. A SAP recomenda que estas duas fases do procedimento de refresh das estatsticas seja schedula atravs da transao DB13. O comando sapdba analyze grava uma log no diretrio sapcheck (<timestamp>.aly) e deve ser monitorado aps a execuo pela transao DB14. O CBO Control Panel (transao DB21) permite modificar o procedimento padro de refresh das estatsticas, seja aumentando a preciso requerida para uma determinada tabela ou eliminando suas estatsticas (para que se use o rule-based optimizer)
Memory Configuration
A System Global Area do Oracle (SGA) contm o data buffer e o shared pool (shared SQL area e o row cache)
Data buffer
Quando um shadow process requisita um dado poder ocorrer um physical read (o dado trazido do disco) ou um logical read (o dado j se encontra no data buffer). Um data block acessado no buffer 1000 vezes mais rpido que quando trazido do disco. O processo de atualizao altera o dado no data buffer e a transferncia para o disco feita mais tarde, assincronamente. A transao ST04 exibe os dados referentes a performance do banco de dados e dever ser utilizada nas anlises relativas ao banco. O conceito de Hit Ratio (Quality) o percentual de logical reads sobre o total de reads (logical + physicals). Este valor dever estar acima de 94%, ou seja, em 94% dos casos o dado j deve estar no data buffer. Uma anlise deste valor somente tem validade algumas horas aps o statup do database, quando o data buffer j atingiu uma estabilidade de runtime. Uma boa regra aguardar pelo menos at o nmero de reads ultrapassar os 20.000.000. Um valor abaixo de 94% indica uma necessidade de aumentar o nmero de blocos (parmetro DB_BLOCK_BUFFERS), o que poder inclusive forar um incremento na memria RAM para no aumentar a paginao (analise a paginao pela ST06). Antes porm de sair aumentando o valor do data buffer indiscriminadamente interessante olhar os aplicativos para encontrar comandos SQL ineficientes. A R/3 possui ferramentas de analise de performance que auxiliam esta tarefa. Cada plataforma de hardware possui um valor mximo de memria que pode ser alocada na shared memory, no devendo a soma do data buffer, log buffer e shared pool exceder este valor
Shared pool
A shared pool composta da Shared SQL Area onde os comandos SQL so armazenados para serem compartilhados pelos shadow prcesses e da Row Cache, que armazena informaes do dicionrio Oracle, incluindo aqui as informaes de estatsticas que sero utilizadas pelo CBO. O conceito de user call so os acessos efetuados pelos shadow processes na shared SQL area. Recursive calls so as leituras fsicas efetuadas pela row cache ao dicionrio Oracle. Os principais pontos a serem observados em relao a shared pool so : A relao entre os user calls e os recursive calls dever ser de pelo menos 2 para 1. A Quality (logical/total reads) do data dictionary cache dever ser maior que 80% A pinration dever ser maior que 95% A relao reload/pins dever ficar abaixo de 1% jluiz@cemig.com.br Pgina 131
ACADEMIA
BASIS
Valores inferiores nestes parmetros indicam uma necessidade de aumentar a shared pool area. Como no existe parmetros especficos para SQL area e row cache separadamente, o aumento dever ser de toda a rea, utilizando o parmetro SHARED_POOL_SIZE. As mesmas recomendaes descritas acima para o data buffer se aplicam ao incremento dos valores desta rea
Application Design Lockwait situations

Um lockwait ocorrer quando diversos work processes requisitarem um lock sobre o mesmo objeto. Para manter consistncia, o RDBMS colocar o lock para aquele que efetuou primeiramente o request. Este procedimento poder causar gargalos na fila de queue do dispatcher do R/3 uma vez que os demais work processes que se encontram em wait estaro com o work process ocupado, apesar de no estarem processando nenhuma transao, mas em wait por um determinado dado. A transao DB01 o Exclusive Lock Monitor do R/3 que permite monitorar o sistema e verificar quem est postando locks e quem est em wait. Para diminuir a conteno por lockwait necessrio muitas vezes reanalisar o aplicativo para emitir commits mais frequentes e garantindo que as transaes segurem os objetos pelo menor tempo possvel. Locks podem tambm ser evitados se os processos puderem ser schedulados para rodarem em diferentes horrios
Unnecessary SQL statements

So comandos que poderiam ser evitados por uma reestruturao do programa evitando comandos dentro de loops WHILE. A opo detail analysis da ST04 permite listar os comandos SQL na shared SQL area. Procure por comandos que so muito executados e que possuam baixa taxa de buffer gets por record. Estes comandos devero ser mais cuidadosamente analisados
Expensive SQL statements

Comandos SQL caros possuem um elevado volume de buffer gets comparado com o valor de total reads do data buffer, devendo esta proporo estar abaixo do 5%. Ou seja, qualquer comando que provocou mais do que 5% dos reads do data buffer dever ser analisado. Esta anlise passar certamente por um explain plan para verificar a estratgia adotada pelo otimizador para o acesso. Estando as estatsticas corretas, este comando precisar ser reanalisado, seja atravs da abertura de um chamado OSS (comando de programa standard SAP) ou pela verificao se o comando no foi mal especificado pelo ABAPer. O explain d a opo de explain with hint, que permite analisar outras alternativas de acesso aos dados
Poorly qualified statements

Normalmente este problema ocorrer quando o SQL no utiliza os ndices corretamente. Estes comandos aparecem sempre com um nmero elevado de bufgets/record. A causa deste problema varia desde uma ausncia de ndices at em problema com as estatsticas da tabela que esto direcionando o otimizador para um caminho errado. ndices standard do R/3 somente devero ser alterados com o aval da SAP. O comando explain plan mostra se o ndice est sendo utilizado ou no no comando SQL. Uma das causas mais provveis deste problema o fato do ndice estar definido no dicionrio do R/3 mas no est ativado, por exemplo devido a uma reorganizao que no foi at o final. Atravs da DB02 possvel exibir os missing indexes. Esta informao fica disponibilizada a partir do report RSORATDB que triggado pelo performance collector (RSCOLL00)
jluiz@cemig.com.br
Pgina 132
ACADEMIA
BASIS
Physical and Logical Layout I/O contention

Ocorre quando numerosos shadow processes e o DBWR acessam o mesmo disco ao mesmo tempo. Comandos SQL caros ou mal qualificados aumentam a probabilidade desta conteno por produzirem volumes elevados de I/O. Aplicativos mal projetados frequentemente causam este problema A transao ST04 (Detail analysis File system requests I/O per path) permite analisar os mount points separadamente e com isso identificar hot spots disks e planejar remanejamento de datafiles. Com volumes elevados de I/O, necessrio certificar-se de que o read time no exceda 30 ms e o write time, 50 ms. Filesystems times que desviam mais que 20% da mdia sero possveis hot spots. Estes valores podero variar entre as vrias plataformas e hardwares disponveis, cabendo talvez uma anlise mais cuidadosa destes targets. A conteno de I/O solucionada atravs da identificao dos hot spots e a posterior distribuio dos datafiles entre os dispositivos e canais. A opo total per device um excelente auxlio nesta deciso
Checkpoint not complete

O sistema Oracle efetua a gravao de checkpoints, que consiste na sincronizao dos SCN no header de todos os seus arquivos (datafiles, redo e control files). Alguns eventos associados a carga elevada no sistema podem causar erros neste processo, que so chamados Checkpoints Not Complete. O erro ocorrer quando o checkpoint ainda se encontra em processamento e o switch de log atinge uma log que ainda no conseguiu ser arquivada. O Oracle congela as atualizaes e aguarda que o processo de checkpoint finalize, os archives sejam efetuados e consequentemente exista online redo disponvel para gravao. A mensagem de checkpoint not complete gravada no alerte do Oracle (/saptrace/background/alert_<SID>.log). A ocorrncia muito constante deste problema pode sugerir a criao de mais grupos de relo logs. A SAP no recomenda aumentar o tamanho das redo log, exceto se o tempo de switch estiver abaixo dos 3 minutos
Rollback statement problems

Os rollback segments so utilizados no Oracle para gravar imagens before que podero ser teis para desfazer transaes no commitadas. Outra funo destes rollback segments no Oracle garantir consistncia na leitura de dados . Isto significa que se um determinado registro foi alterado por uma transao depois que outro query iniciou um processamento, quando chegar o momento da requisio do registro o Oracle entrega a imagem before e no a atual ou seja, aquela que estava corrente no momento em que a transao iniciou e ficou armazenada no rollback segment. Estas imagens permanecero no rollback segment mesmo aps o commit. O problema que pode ocorrer um rollback segment commitado pode vir a ser reutilizado por outra transao posterior. Caso o query chegue na linha alterada, ao verificar o rollback para buscar a imagem consistente para leitura encontrar o bloco sujo e consequentemente no poder mais fornecer a imagem before. Neste caso a transao que estava efetuando o query recebe o abend ORA-1555 (snapshot too old). Para evitar a ocorrncia de ORA-1555, preciso tentar evitar que programas de query sejam schedulados durante perodos de alto volume de atualizao, tentar otimizar o runtime dos programas que abendam com 1555 ou, se nada mais funcionar, aumentar o nmero (preferencialmente) ou o tamanho dos rollback segments O dimensionamento correto dos private rollback segments (aqueles que so especificados no init<SID>.ora) preciso partir de uma anlise dos rollback segments atuais atravs da viso V$ROLLSTAT:
jluiz@cemig.com.br
Pgina 133
ACADEMIA

BASIS
Caso o somatrio dos WAITS de todos os rollback segments representem mais do que 1% do somatrio dos GETS isto indica conteno, ou seja, necessrio definir mais rollback segments valor OPTIMAL representa a marca at onde os rollback segments que sofreram alocao de extents iro encolher na operao de shrink valor HWMARK a marca dgua do segmento. um bom indicativo de qual dever ser o valor do parmetro OPTIMAL para eliminar os extend/shrinks, porm deve ser analisado com cuidado pois pode se tratar de uma demanda isolada Os campos EXTENDS e SHRINKS representam o nmero de alocaes/dealocaes acima do valor OPTIMAL. Para calcular o valor do OPTIMAL ideal, utilize a frmula: new OPTIMAL = OPTIMAL + (EXTENDS SHRINKS) * NEXT. Com isto ser especificado um valor para o optimal que no causar mais os extends/shrinks. volume ideal de alocao de extents dever ficar na casa dos 20. Com isto podemos calcular os parmetros de storage: INITIAL = NEXT = OPTIMAL/20
Fragmented indexes
ndices fragmentados so caracterizados por um baixo volume de preenchimento dos blocos e, pior ainda, por uma distribuio da rvore em mais de 3 nveis. Esta fragmentao normal e vai acontecendo ao longo das operaes de atualizao que uma tabela vai sofrendo. Tabelas com alta volatilidade ou volumes elevados de deleo, como acontece durante uma operao de archiving, esta fragmentao se acelera. O resultado da fragmentao elevada dos ndices sobre a performance que um volume muito mais elevado de index blocks ser percorrido do que em um ndice organizado, gerando I/O e queda da qualidade do data buffer. Para analisar os ndices, utilize a transao DB02, selecione o ndice desejado e em seguida utilize o caminho: Detail analysis Analyse index Storage quality. O valor encontrado para a qualidade do ndice dever ser superior a 50%. possvel tambm disparar um validate index (em modo dialog ou background) para analisar o nmero de nveis das folhas.
jluiz@cemig.com.br
Pgina 134
ACADEMIA
BASIS
Quinta Semana Top 10 Problems

Esta seo ir listar os 10 problemas mais comuns que podem ocorrer na administrao de uma base de dados Oracle com o R/3. O principal objetivo reconhecer, solucionar e principalmente prevenir a ocorrncia de tais fatos Uma utilizao criteriosa e diria do sapdba check ajuda a preveno dos principais erros no Oracle. necessrio ainda o monitoramento constante das transaes ST22, SM21 e dos traces e logs do R/3 e de suas ferramentas
Archive Stuck Situation

O travamento de uma instncia Oracle devido a incapacidade de gravao das offline redo log files ocorre principalmente quando a rea saparch atinge os 100% full. Quando o archiver stuck ocorre, o Oracle grava relata os error ORA-255 e ORA-272 no alert_<SID>.log A monitorao constante do filesystem saparch e uma metodologia consistente de arquivamento implantada evita a ocorrncia deste problema. Manter um dummy file na rea saparch para ser excludo em casos de stuck ajudam a ganhar um flego a mais enquanto se providencia um arquivamento emergencial.
The Incorrect Tape Size Drivers with Hardware Compression

Um dimensionamento incorre do parmetro tape_size do init<SID>.sap poder causar desde erros durante a gravao at, o que ainda mais grave, problemas quando se tenta recuperar a fita em um restore. Reserve sempre um espao de pelo menos 200MB quando especificar o tamanho da fita para eventuais erros no dimensionamento dos files durante o brbackup. Este valor do tape size especificado em MB ou GB e equivalem ao clculo do tape length * write density, que variar de modelo para modelo de fita e do processo utilizado na gravao, se comprimido ou no
A Missing End Backup

Quando um tablespace backupeado em modo online, necessrio que o mesmo seja colocado em backup mode atravs do comando begin backup antes de iniciar a cpia. Este modo permanecer at o final da cpia quando ento o tablespace retirado do backup mode atravs do comando end backup A tentativa de retirar um database com shutdown immediate pelo sapdba, o mesmo verifica antes e coloca qualquer tablespace que se encontre em backup mode para end backup antes de efetuar a operao. Se o shutdown immediate vier atravs do service manager (svrmgrl) ou do stopsap db, o comando falha retornando o erro ORA-1149 (missing end backup). Neste caso bastar alterar o tablespace para end backup (ALTER TABLESPACE xxx END BACKUP;). A ferramenta check database do sapdba efetua este check e, melhor ainda, pergunta ao operador se deseja retirar o end backup do tablespace e efetua a operao Caso a instncia DB caia mantendo algum tablespace em backup mode (seja por power fail ou shutdown abort), o startup ir falhar com a mensagem ORA-1113. Neste caso ser necessrio efetuar um partial restore and complete recovery dos tablespaces afetados
jluiz@cemig.com.br
Pgina 135
ACADEMIA
BASIS
A Tablespace Overflow
A necessidade de mais rea para uma tabela ou ndice no tablespace ocorrer quando o mesmo precisar de mais data blocks. Esta alocao se dar em rea contgua e no tamanho especificado pelo parmetro NEXT do objeto. Caso o tablespace no possua esta rea desejada, ocorrer o erro ORA-1653 (tabela) ou ORA-1654 (ndice) que ser emitido na syslog e no ABAP short dump. A monitorao constante do critical objects pela DB02 ou do sapdba check ajuda a prevenir esta ausncia de rea e a tomar as medidas necessrias antes que o erro ocorra. O erro ser corrigido pela alocao de um novo datafile para o tablespace (via sapdba) em um tamanho baseado no crescimento estimado do tablespace. importante que se efetue um backup do tablespace aps cada mudana estrutural dos arquivos.
A Table or Index Reaching the MAXEXTENTS Limit

Quando o nmero de extents de um objeto atinge o valor especificado no parmetro de storage MAXEXTENTS, o sistema no alocar mais extents e ocorrer o erro ORA-1631 (tabela) ou ORA1632 (ndice) que ser emitido na syslog e no ABAP short dump. Este problema poder ser evitado pelo acompanhamento constante do sistema e especificao correta do parmetro NEXT. O comando sapdba next efetua uma adaptao do parmetro NEXT das tabelas e ndices baseado em critrios bem estabelecidos no dicionrio do R/3. Este comando dever estar schedulado para rodar pelo menos uma vez por semana na instalao (utilize a DB13) ou ento esporadicamente quando se tem conscincia de crescimento anormal de tabelas (carga em batch, etc.) O problema pode ser contornado temporariamente atravs da especificao de novo limite para o parmetro MAXEXTENTS. Porm quando o sistema atingiu este limite j dever ter ocorrido um elevado volume de fragmentao da tabela, devendo ser planejado uma reorganizao para o objeto o mais cedo possvel. Nunca especifique um valor unlimited para o parmetro MAXEXTENTS nos objetos de um banco utilizado pelo R/3
Oracle Error ORA-1555, Snapshot Too Old

Para garantir a consistncia na leitura, o Oracle implementa um mecanismo que garante aos queries submetidos ao banco um nvel de pesquisa que permite obter todos os seus registros desejados no estado em que estavam no incio do SQL. Este mecanismo funciona atravs do fornecimento de eventuais valores alterados aps o incio do query com suas imagens before que se mantm armazenadas nos segmentos de rollback. Comandos de update que sofreram commit permanecero com seus pointers ainda alocados para a rea de rollback podendo porm ser sobre escritos por novas transaes, dependendo da atividade do banco e do tempo que o query permanecer percorrendo a base de dados. Eventuais comandos que requisitem linhas que foram alteradas (e commitadas) e eventualmente j perderam sua imagem na rea de rollback, iro receber um erro ORA-1555 indicando snapshot too old, abortando o processo. Antes que se parta para uma alterao da configurao dos segmentos de rollback, vale identificar o comando que esteja provocando o erro e verificar alternativas para a sua execuo, inclusive planejando o seu schedule para horrios de menor atividade no banco
Net8 TCP/IP Delay

O Net8 a camada de comunicao entre os application servers e o banco de dados. Comunicaes na mesma mquina utilizaro IPC (inter process call) e remotamente o protocolo TCP/IP. jluiz@cemig.com.br Pgina 136
ACADEMIA
BASIS
A implementao default do Oracle utiliza o modo de configurao do Net8 em delay mode, o que introduz um ciclo de espera de aproximadamente 200ms nas comunicaes dos processos Este problema pode ser solucionado atravs do arquivo protocol.ora que pode ser obtido do sapservX. Em seguida copie este arquivo para o diretrio /oracle/<SID>/network/admin com read permissions para os usurios <sid>adm e ora<sid> em todos os applications e no db server. Para que o novo modo se torne operativo, necessrio parar todas as instncias (application, DB e o listener). Volte o listener, ativ o DB e retorne os applications A nota 72638 descreve melhor este processo.
Oracle Error ORA-1578, Data Block Corruption

O erro ORA-1578 indica uma corrupo de estrutura dos blocos Oracle. Este erro pode ocorrer por uma falha de hardware e permanecer despercebido at o momento que o bloco seja requisitado, o que pode ocorrer muito tempo aps a ocorrncia do erro. Se o problema ocorrer em um bloco de ndice, basta reconstruir o ndice danificado. Table blocks danificados somente podero ser solucionados atravs de um restore e recover parcial at a momento do crash, se conhecido. A demora em perceber o bloco danificado pode gerar consequencias graves, j que muitas vezes fica difcil voltar um backup antigo sem afetar seriamente o negcio de uma empresa. Alm disso o prprio backup j poderia estar danificado. Para garantir que os blocos danificados sejam detectados no momento do backup, schedule o brbackup com a opo use_dbv, como visto anteriormente. Um processo constante de verificao do banco atravs de ferramentas Oracle (DB verify e dbv) tambm garantem a monitorao constante da base de dados, minimizando as consequncias de qualquer ocorrncia de blocos danificados.
Oracle Error ORA-600, Internal Database Error

O erro ORA-600 indica um erro interno Oracle. Procure identificar o primeiro argumento da mensagem de erro e procure no OSS por ocorrncias do erro.
Poor Performance of the Cost-Based Optimizer

O CBO determina a maneira mais eficiente de acessar uma determinada tabela baseado em estatsticas armazenadas no dicionrio Oracle. Qualquer incoerncia nestas estatsticas causada pela no atualizao dos dados poder direcionar o otimizador para decises que causaro srios problemas de performance. Garanta que estas estatsticas sejam atualizadas regularmente atravs do shedule das duas fases (check e analyse) na DB13.
jluiz@cemig.com.br
Pgina 137
ACADEMIA
BASIS
Introduction to Workload Analysis

Performance Problems
A workload analysis consiste em aplicar mtodos especficos de anlise dos tempos de resposta em um sistema R/3 para que se encontre gargalos e programas problemas no ambiente conseguindo com isto efetuar ajustes finos de performance que consigam diminuir o tempo de resposta das transaes e aumentar o throughput do sistema. Tempos de resposta ruins devero ser analisados localizadamente (por transao) ou no sistema como um todo (mdia geral dos tempos de resposta), dependendo da forma como o problema se manifesta.
Basis Tuning
Uma anlise geral do ambiente tem por finalidade distribuir corretamente a carga do ambiente entre os servidores de um sistema R/3. Isto significa dimensionar corretamente o hardware, distribuir os discos e otimizar as definies dos work processes e dos buffer das instncias
Application Tuning
Um tuning localizado de uma aplicao tem por finalidade evitar que programas mal especificados produzam uma carga desnecessria no ambiente. Esta anlise vai desde a localizao e aplicao de notas do OSS at a otimizao dos cdigos dos programas desenvolvidos na instalao (programas Z). Eventualmente esta anlise chega a concluso de que necessrio criar novos ndices ou bufferizar algumas tabelas do sistema.
Response Times
O tempo de resposta (response time) de uma transao no R/3 o tempo entre a requisio do usurio ao sistema e vai at o retorno da prxima tela, podendo ser dividido em vrios componentes individuais que permitem uma anlise mais profunda no componente causador da m performance. O tempo de transmisso (rede) no computado pelos monitores do R/3: Wait time: o tempo de permanencia do request na fila do dispatcher desde o momento que a request chega at a sua atribuio ao work process Roll in time: o tempo necessrio para efetuar o roll in dos dados de contexto do usurio para dentro do work process Load time: o tempo necessrio para carregar os objetos (e eventualmente gera-los) do dicionrio ABAP para os buffers da instncia Processing time: o tempo gasto para processamento dentro do work process, equivalendo a diferena entre o response time e a soma dos demais tempos Database request time: tempo de processamento dos SQL, que comea quando a requisio encaminhado ao database interface e termina quando este retorna com o resultado CPU time: tempo de CPU consumido por todo o processo (consumido pelo roll, load, enq, processing e db)
Wait time
Os requests encaminhados pelo SAPGUI so colocados em uma fila de espera FIFO pelo dispatcher. Um elevado tempo de permanncia nesta fila indica indisponibilidade de work process. Esta indisponibilidade pode entretanto vir de uma pequena definio de nmero de work processes como tambm pode significar que os work processes no esto sendo liberados com a rapidez esperada. Elevados wait times merecem uma anlise menos simplista e esta normalmente associado a problemas generalizados no sistema.
jluiz@cemig.com.br
Pgina 138
ACADEMIA Roll in time
BASIS
Roll in a transferncia dos dados do contexto do usurio (autorizaes e ponteiros para as reas de trabalho) do roll buffer para a roll memory do work process. Ao efetuar esta transferncia tem-se incio ao processamento do dialog step. Tempos elevados de roll time podem indicar problemas no gerenciamento de memria do R/3 ou ainda gargalos de CPU para efetuar a operao.
Database time
Quando um dado requisitado via um open SQL, a requisio enviada para o database interface do work process que efetua o request localmente nos database buffers da instncia ou envia a requisio para ser processada pelo servidor de bancos de dados. Ou seja, o database time compreende o tempo desde a passagem do sql para o database interface at a disponibilizao dos blocos de dados ao work process. Tempos elevados no componente database podem indicar gargalos na instncia DB, problemas de rede (se outra instncia), comandos SQL caros, falta de ndices, enfim uma srie de problemas relacionados ao tuning do banco.
Processing time
O processing time definido como o tempo de resposta total menos o wait, database, load, roll e enqueue time. Pode ser entendido como o tempo gasto dentro do work process para realizar o processamento ABAP demandado pela aplicao. Tempos elevados normalmente significam loops no programa eu erro na construo da aplicao.
CPU time
O tempo de CPU consumido pelo work process durante um dialog step computado no CPU time. Entretanto no s este, no cpu time esto computados todos os tempos gastos por cada um dos componentes na cpu onde est sendo executado o application. Tempos elevados de CPU indicam problemas na lgica do programa ABAP, tais como processamento de tabelas muito extensas ou sobrecarga da cpu em funo de outros processamentos que esto concorrendo na mquina.
Workload Statistics
O Performance Monitor (transao ST03) d informaes detalhadas e estratificadas dos tempos de resposta em em sistema R/3 A proporo apresentada entre o nmero de database calls e os database requests d uma noo exata da eficincia da buferizao de tabelas, indicando o nmero de requests que tiveram que ser encaminhadas ao DB server pelo database interface. As chamadas externas de funes RFC podem provocar roll out do user context para liberao do work processes. A espera pelo retorno (roll wait) e posterior roll in, todos estes tempos ficam embutidos no roll time do dialog step. Transaes com elevado nmero de chamadas RFC tendem a ter um roll time mais elevado que as demais.
Workload Analysis
O workload analysis feito atravs da transao ST03. Esta transao viabiliza a analise da carga no sistema em qualquer momento no tempo (passado agrupado por periodo ou um snapshot dos ultimos minutos) Uma anlise geral (a partir da seleo de um perodo de tempo que seja conveniente para a anlise) pode indicar se existem problemas de performance gerais na instalao, como por exemplo : Wait time maior que 10% do response time Main menu () com tempo de execuo superior a 100 ms jluiz@cemig.com.br Pgina 139
ACADEMIA
BASIS
Atravs da ST03, alguns valores indicam boa performance: Average roll in time < 20 ms Average roll out time < 20 ms Average load time < 10% response time e sempre inferior a 50 ms Average database time < 40% do (response time wait time) Average CPU time < 40% do (response time wait time) Average CPU time no pode ser muito inferior ao processing time De qualquer forma temos que ter em mente que os sintomas abaixo normalmente esto associados a tipos padres de problemas, a saber : Large roll time problemas com o gerenciamento de memoria do R/3 Large load time - buffers de programas, cua, ou screen esto pequenos Large database request time gargalo na cpu ou memria na mquina de banco de dados, problemas de rede, comandos sql caros, locks, ausencia de indices ou estatisticas desatualizados Large CPU time comandos sql muito caros em funo de processamento pesado ou acessos frequentes aos buffers Processing time muito maior que o CPU time gargalo de cpu, problemas de redes e/ou de comunicao
Analysis Roadmap using workload monitor (ST03)

ST03 Wait time > 10% response time Problema generaliza de performance Database time > 40% (response time wait time) Analise detalhada do banco de dados Processing time > CPU time * 2 Analise detalhada do gargalo de hardware Load time > 50ms Analise detalhada da configurao de memoria do R/3 Buffer de programas muito pequeno Roll-in time > 20ms ou roll-out time > 20ms Analise detalhada da configurao de memoria do R/3 Problemas com memoria extendida ou roll buffer Perfil de transao (st03 classificado por temo de resposta) Programa com cpu alta : cpu time > 40% (response time wait time) Analise detalhada do trace do abap em questo Programa com db alto : database time > 40% (response time wait time) Analise detalhada do sql em questo Processing times muito superiores ao CPU time indicam gargalos de CPU ou problemas de comunicao. A opo de transaction profile da ST03 exibe a distribuio dos tempos por transao, permitindo anlises individualizadas, permitindo efetuar esforos de tuning nas transaes mais utilizadas. Podemos utilizar a transao STAT exibe estatsticas individualizadas por uma srie de fatores. Para auxiliar a anlise devemos utilizar as transaes : ST03 work load monitor SM50 / SM66 work process overview ST06 operating system monitor ST04 database monitor ST02 setups buffers STAT statistical records ST05 trace de sql ST07 application monitors SE30 abap trace
jluiz@cemig.com.br
Pgina 140
ACADEMIA
BASIS
Performance Analysis Monitors

Work Process Overview
A transao SM50 permite a monitorao dos work processes de uma instncia R/3. A monitorao dever se ater aos processos com status running e aqueles com status stopped, que indicam work process em modo PRIV. SM50 ou SM66 (work process overview) Work process com status running Ao Dir. Read, Seq Read, Insert, Update, Delete, Commit Analise detalhado do banco de dados Ao Load Report Analise detalhada da configurao de memoria do R/3 Buffer de programas muito pequeno Ao Roll-in ou Roll-out Analise detalhada da configurao de memoria do R/3 Problemas com buffer de memoria extendida ou de roll Work process com status stopped Reason PRIV Analise detalhada da configurao da memoria do R/3 Problemas com buffer de memoria extendida ou de roll buffer Reason CPIC Problemas com conexo CPIC como todos work process bloqueados
ST06 - Operating System Monitor

A transao que permite a monitorao do sistema operacional no R/3 a ST06, que exibe informaes sobre utilizao de CPU, swaps, utilizao de discos e configurao do sistema operacional. Gargalos de CPU aparecem quando temos menos de 10% idle ou quando o Load Average indica um valor superior a 2 vezes o nmero total de CPUs disponveis Problemas de alto consumo de CPU podem ser identificados atravs da anlise dos topCPU processes, no detail analysis. disp+work so os processos R/3 e ORACLE80 um processo de banco de dados. Nesta janela devemos observar os percentuais de utilizao da cpu (devem estar com pelo menos 10% de idle), o load average (indica quantos processos ficaram aguardando por cpu), paginao (sempre inferior a 10% da memria fsica) ou swap alocado em arquivos e no liberados pelos work process.
ST02 - Buffer Monitor

A transao ST02 o monitor dos buffers do R/3, indicando tamanhos, qualidades e percentuais de ocupao de cada um deles. Devmos observar que o percentual de utilizao dos buffers devem estar sempre acima de 95% alm do cuidado especial com swaps excessivos e com os possvies gaps no buffer de programas. Quando detectamos que a extended memory atingiu 100% de utilizao ( Max use = In memory), comearo a aparecer contenes de memria para os work processes. Roll area com valores de Max use superiores ao In memory indicam que a utilizao de roll area teve que ser expandida para disco, o que ruim
jluiz@cemig.com.br
Pgina 141
ACADEMIA
BASIS
R/3 Memory Management

R/3 Memory Areas
A memria fsica a memria em RAM instalada na mquina. A rea de swap uma rea em disco pelo sistema operacional para paginar a memria utilizada pelos processos. quando alocamos uma memria em um sistema operacional, estamos efetuando uma alocao de memria virtual. O sistema operacional quem decide se a memria alocada estar em disco ou em memria fsica. Dependendo do sistema operacional utilizado, a memria virtual ter um valor entre o swap especificado e a soma do swap com a memria real. Uma instncia possui duas reas bsicas de memria: local memory e shared memory
Local Memory
a memria associada com cada work process. Esta memria utilizada para: Executveis Dados, stack Buffer para transferncia de dados Local roll area Local paging area
Heap
Fazendo parte da memria local mas no diretamente temos a heap area. A heap memory alocada pelo work process diretamente na rea de swap. Work processes que comeam a utilizar heap area entram em PRIV mode, desta forma no efetuando mais roll out/roll in, ficando desta forma dedicado ao usurio.
Shared Memory
A shared memory o agrupamento das reas globais que sero compartilhadas pelos work process. Ela subdivida em buffers, roll area, paging area e extended area.
Buffers
Memria alocada na shared memory e que contm objetos globais de todos os usurios e work processes, tais como programas e tabelas de customizao.
Extended
A extended memory contm dados de contexto associados com a transao de um determinado usurio, tais como variveis, listas, tabelas internas, etc. Ela alocada a medida do necessrio em pequenos blocos e preservada de um dialog step para o outro.
Roll
A roll memory alocada no roll buffer e contm a parte inicial do contexto do usurio. Ela contm ainda os ponteiros para a extended memory que est sendo utilizada pela transao corrente.
Paging
uma rea utilizada pelos work processes na paging area (shared memory) para determinadas operaes de abap. Ela normalmente est associada a dados relacionados a subfunes abap.
jluiz@cemig.com.br
Pgina 142
ACADEMIA
BASIS
Allocation Concepts
Os work processes so compartilhados pelos vrios usurios que se conectam a uma instncia. Este compartilhamento efetuado a cada dialog step (ou chamada RFC) fora o R/3 a manter um mecanismo que salve os dados do usurio e permita o reinicio do processamento quando solicitado pelo usurio no prximo dialog step. Estes dados referentes a um determinado usurio denominado user context area. Este conceito permite por exemplo que um determinado cdigo de material que o usurio trabalhou em uma transao seja lembrado como default na prxima transao. O conceito de roll out salva a user context area garantindo assim que os dados de um usurio no sejam sobrescritos pelos usurios que utilizam o mesmo work process posteriormente. Os dados so movidos (rolled out) para disco. O prximo dialog step provoca o retorno da user context area para o work process que ir processa-lo. Este processo denominado roll in. Existem duas reas no R/3 que sofrem este processo de roll out/roll in. A roll area propriamente dita contm os dados de contexto do usurio associados a autorizaes, internal tables e report lists. A paging area contm a memria associada a alguns comandos especficos de ABAP. A extended memory alocada na shared memria e disponibilizada para os work processes que podem requisitar pedaos de memria que ficam mapeados nos work process atravs de pointers armazenados na respectiva roll area. Isto permite diminuir o contexto de roll out/in apenas para referncias (pointers) extended memory alocada.
Allocation Sequence
A fim de minimizar o volume de dados necessrios para as operaes de roll in/out, o sistema R/3 procura otimizar a alocao de memria atravs de uma metodologia nesta operao. Inicialmente apenas uma poo mnima da roll area alocada, definida pelo parmetro ztta/roll_first. Quando este parmetro setado para 1, um mnimo de 100K ser alocado para o processo. Quando o processo necessitar de rea para trabalho, o sistema alocar memria na extended memory da shared memory e grava na roll area do work processes apenas um pointer para a rea alocada. Esta aquisio de memria na extended memory vai sendo permitida at que no haja mais memria disponvel ou ento quando o work process atinge a sua cota de alocao, definida pelo parmetro ztta/roll_extension. Esta rea no ser copiada durante o processo de rolagem, mas sim mapeada, ou seja apenas as referncias (pointers) sero copiados. Quando se esgota a alocao de extended memory o work process comea a alocar o restante da roll area disponvel, o que acaba aumentando a quantidade de area sujeita a roll out/in. O limite a ser utilizado para alocao definido no parmetro ztta/roll_area. O ltimo passo quando se esgota a roll area alocar memria na heap memory, Quando este passo acontece, o work process entra em PRIV mode e para de efetuar rolagem da rea de contexto, o que significa que ele permanecer alocado para o usurio at o trmino da transao. A quantidade mxima de rea que pode ser alocada na heap area para cada work process definida pelo parmetro ztta/heap_area_dia. A partir do release 4.0 do SAP os demais work processes, como batch work process, tambm utilizam este mesmo critrio para alocao de memria.
Heap Memory Management

Quando heap area alocada por um work process o mesmo entra em PRIV mode, o que significa que ele ir parar de efetuar a rolagem para efetuar multitasking, permanecendo alocado (private) para o usurio. Esta rea heap liberada no trmino da transao porm no ser liberada na swap area do sistema operacional. Esta rea somente ser liberada se matarmos (kill) o processo (disp+work) a nvel de sistema operacional. Existe um parmetro (abap/heaplimit) que quando atingido pelo total de heap area alocado por um determinado work process, ele ser flagado para automatic restart, ou seja, o sistema efetua um refresh (kill/start) do work process ao trmino da transao.
jluiz@cemig.com.br
Pgina 143
ACADEMIA
BASIS
R/3 Extended Memory

Quando se utiliza um novo parmetro do R/3, o PHYS_MEMSIZE, ele permitir que o prprio R/3 gerencie a sua alocao de extended memory at um limite definido por em/max_size_MB. Este procedimento simplifica a administrao de memria (no necessrio definir mais nenhum outro parmetro) e denominado Zero Administration Memory Management. Para limitar, neste caso, a utilizao da extended memory por um usurio utilize o parmetro em/address_space_MB. Para maiores detalhes veja a nota 88416. O tamanho mximo da memria alocada para extended memory (parmetro em/initial_size_MB) em UNIX depende da arquitetura utilizada. Em plataformas 32 bits o limite de 2G, j para sistemas 64 bits, este limite sobe para 108TB. Para maiores informaes pequise notas associadas ao sistema operacional. Dever sempre haver uma quantidade suficiente de memria real compatvel com a parametrizao do R/3 para evitar paginao excessiva de sistema operacional.
Analysis Roadmap: R/3 Memory Configuration (ST02)

ST02 Esta acontecendo muitos swaps Se existe memria fsica disponvel, aumente o tamanho do buffer em questo A extended memory est cheia : Max used > 80% in memory ST02 analise detalhadamente a memoria atravs do Mode List Existe algum usurio com alto consumo de memria extendida Identifique e analise os respectivos relatrios e transaes Se existe memria fsica disponvel, aumente o tamanho da memria extendida ztta/roll_first > 1024 ? ztta/roll_first = 1 Roll buffer est cheio ou Max. used maior que 80% Se existir memria fsica disponvel, aumente o parmetro rdisp/roll_SHM.
jluiz@cemig.com.br
Pgina 144
ACADEMIA
BASIS
Hardware Capacity Verification

Hardware Bottlenecks
Um gargalo causado por hardware no R/3 reflete em um elevado tempo de resposta das transaes. No sistema operacional este problema se manifestar atravs de um elevado consumo de CPU (prximo a 100%), altas taxas de paginao, baixo desempenho da rede ou ainda por elevados tempos de acesso aos discos. A quantidade ideal de CPU idle dever se situar acima dos 35%. Taxas abaixo de 20% indicam gargalos de CPU. ndices de paginao (ST06 double click Paged in [Kb/h]) por hora acima de 20% da memria RAM indicam problemas de memria.
Analysis Roadmap: Hardware consuption (ST06)
Operating System Monitor (ST06) CPU Idle < 20% CPU contention Other servers available Work process and users redistribution Top CPU process (ST06 Detail analysis) R/3 process with high CPU detail analysis using SM50 DB process wit high CPU detail analysis using ST04 External process with high CPU stop or redistribute High paging rate > 20% of RAM per hour memory contention Other servers available Work process and users redistribution File system cache > 10% RAM reduce file system cache Buffers monitor (ST06 Mode list) Programs with high memory detail analysis of transaction Workload Monitor (ST03) Wait time > 10% General performance problem Database time > 40% (response time wait time) database detail analysis Processing time > cpu time * 2 hardware bottleneck Load time > 50 ms program buffer too small Roll in/out > 20ms problem with extended memory or roll buffer
Contenes de CPU podem ser resolvidas atravs da distribuio da carga entre os demais applications, quando possvel. Processing time > CPU time x 2 geralmente indica problemas gerais de performance associados a hardware, sendo necessrio pesquisar mais fundo a causa do gargalo. A causa do elevado consumo de CPU pode muito bem estar associado a processos rodando na mquina que consomem muito ciclo. Se houver gargalo de memria, veja a nota 78498 para avaliar a possibilidade de utilizar o cache de file system.
Optimizing the Configuration Memory configuration

Separe para o banco de dados 20% da memria de todos os servers. Defina os buffers do R/3 entre 200MB e 500MB por instncia. Em unix cada work process consumir aproximadamente 11.5 MB (7.5MB no NT). Cada usurio logado consumir de 5 a 10MB de extended memory. A RAM fsica dever ser aproximadamente 2/3 da memria usada. A memria virtual alocada pode ser visualizada atravs da ST02 Detail analysis Storage. O swap dever ser de 3 x RAM (no mnimo 2GB). Considere nos clculos o nmero de usurios ativos e o peso dos aplicativos que sero utilizados
CPU configuration
Utilize para o banco de dados de 10 a 30% da CPU de todos os servers. Garanta que nunca haja gargalos no servidor de banco de dados. Utilize de 10 a 20% do total de CPU para o processamento dos updates. A demanda dos application servers depender do perfil dos usurios/aplicativos utilizados
jluiz@cemig.com.br
Pgina 145
ACADEMIA
BASIS
Expensive SQL Statements

Detecting Expensive SQL Statements
Comandos caros de SQL podem aumentar o database time das transaes afetando por consequencia o tempo de resposta de todo o sistema. Estes comandos provocam elevadas taxas de leitura de data blocks que provocam I/Os elevados e alto consumo de CPU. Na prtica os expensive sql statements provocam um grande impacto na performance geral do sistema pois o work process fica muito tempo ocupado aguardando o retorno dos dados. Dados estes que esto sendo trabalhados em buffers e/ou disco gerando novas contenes de IO e CPU. Resultado, o wait time acaba por ser o sintoma mais caracteristico apesar de no estar associado diretamente ao problema.
Monitors to Analyse
Devemos procurar por programas com elevados database times e posteriormente por SQLs com altos valores de buffer gets. As transaes utilizadas nestas anlises sero: ST03, SM50/SM66, ST04, ST05 e SE12. Devemos focar a pesquisa para identificar o nome da tabela em questo, a clausa where utilizada, os indices envolvidos e principalmente o report ou a transao que contm o statement que est provocando o gargalo. Como visto anteriormente, atravs da ST03 Transaction profile, transaes com database time e/ou cpu time superiores a 40% do response time wait time devero ser analisados com enfoque para os acessos ao banco de dados: Analysis Roadmap using transaction profile (ST03 Transaction profile) Transaction profile, sorted by response time total CPU time > 40% (response time wait time) detail SQL analysis ABAP trace (SE30) Detail analysis of ABAP program DB time > 40% (response time wait time) detail SQL analysis SQL trace (ST05) Detail analysis of SQL statement Atravs da SM50 e SM66 tambm possvel efetuar anlise de programas com elevados tempos de resposta, alm da identificao direta de quem o causador (usurio e cdigo abap). Para isto veja o roadmap abaixo : Analysis Roadmap using work process overview (SM50 ou SM66) WP in status running Long processing: analyse status field Dir. Read, Seq. Read, Insert, Update, Delete, Commit DB analysis Database Lock Monitor (DB01) Wait due database locks Analyse lock holder Database Process Monitor (ST04 Oracle session) Look for SQL statements and identify the transaction SQL Trace (ST05) Identify and analyse specific SQL statement Comandos caros tambm podem ser identificados atravs da monitorao dos buffer gets (ST04 Detail analysis SQL statement) com elevadas taxas. Alm dos buffer gets devemos observar os gets/execution, records/execution e disk reads.
jluiz@cemig.com.br
Pgina 146
ACADEMIA
BASIS
Detail Analysis and Tuning

Expensive sql statement sempre efetuam elevados volumes de buffer gets durante a sua execuo. Dependendo do resultado obtido, podem ser classificados em dois tipos: aqueles que trazem um alto volume de linhas selecionadas (tipo 1) e aqueles que trazem poucas linhas como resultado (tipo 2). Os comandos tipo 1 normalmente indicam programas ABAP mal escritos, devendo ser reanalisados. Os comandos tipo 2 so resultado de estratgias ineficientes de acesso ao banco de dados, seja pela ausncia de ndices ou pela ausncia de estatsticas atualizadas. Eventualmente a ineficiencia provocada por comandos SQL complexos que devem ser reescritos Para verificar como o otimizador est resolvendo o sql devemos utliizar o explain (detalhe de como o sql foi resolvido). Nele podemos perceber o mtodo de acesso (table access full, index range scan, index unique scan, concatenation, sort, index used, etc) e o custo que o comando teve para ser executado. Atravs de um explain no comando SQL podemos decidir pela criao ou no de um novo ndice secundrio. Ao criar ndices posicione os campos mais seletivos no incio do ndice e no especifique mais do que 5 campos. Evite definir mais do que 5 ndices por tabela, principalmente naquelas que sofrem muita atualizao, como o caso das tabelas que armazenam dados transacionais. Atravs do explain possvel verificar a estratgia de acesso que o otimizador est utilizando para executar o comando SQL. Caso a estratgia esteja saindo cara, verifique se existe caminho mais otimizado, se a causa no seria desatualizao das estatsticas ou ausncia real de ndice secundrio. Eventualmente analise a possibilidade de reescrever o comando SQL.
Table Statistics for Optimizer

O otimizador do oracle, algoritmo que decide qual a melhor forma de acessar um determinado dado em uma tabela, para tomar a melhor deciso precisa que as estatisticas das tabelas e dos indices estejam atualizadas. Basicamente ele precisa saber qual a distribuio estatistica de cada campo no indice, quantos nveis compe o indice e qual a quantidade de registros da tabela. Se estes valores no existirem ou se estiverem desatualizados o otimizador certamente no far a opo correta e o tempo de acesso ao dado tende a ser ruim. Para evitar que isto ocorra sempre tenha os programas que fazem refresh destas estatisticas agendados semanalmente na transao DB13.
Tips for Optimizing ABAP

Uma boa opo para a otimizao dos programas abaps o uso to Tips&Tricks (transao ). Atravs dessa transao podemos construir comandos sql e testar a sua efetividade. Nessa transao ainda temos uma srie de sugestes e opes de implementaes com os respectivos tempos de resposta.
Analysis Roadmap for sql statement Many records transferred ? Optimize abap code Use EXPLAIN Is the optimal index used ? Special database tuning methods Na optimal index exists but is not used by the optimizer ? Are table statistics up-to-date ? Refresh statistics Where clause of sql statement too complex ? Rewrite where clause Are there missing indexes ? Recreate missing indexes Are the new indexes reasonable ? Create new indexes
jluiz@cemig.com.br
Pgina 147
ACADEMIA
BASIS
Table Buffering
Concepts
A instancia R/3 possui uma srie de buffers para otimizar o processamento e a manipulao dos dados. Os principais buffers que so utilizados so os de objetos do repositrio, de tabelas, de programas, de janelas, de roll e paging, calendarios, number range, etc. A principal vantagem dos buffers a otimizao e minimizao do acesso a base de dados com a manuteno dos dados mais acessados na memria do sistema. As tabelas de um banco de dados relacional so as principais beneficiadas com esta estratgia. O tempo mdio de acesso a um dado buferizado reduzido drasticamente. Este um sofisticado mecanismo e especializado categorizando a formas de buferizao. As trs formas possiveis so : Full buffering, onde a tabela completamente buferizada e todas as suas linhas vo para a memria no primeiro acesso Generic buffering, onde um nmero de campos identificadores declarado e toda a fatia de dados acessada e relacionada a esta fatia carregada na memria. Tipicamente esta estratgia utilizada para as tabelas dependentes de mandante pois necessrio declarar o numero de campos (normalmente 2 ou 3) que compe a chave de buferizao Single record buffering ou partial buffering, onde apenas a linha acessada no banco de dados carregada na tabela e a partir da sempre acessada a cpia que est no buffer.
Synchronization
claro que temos que ter um tratamento especial se o dado que est no buffer for alterado por outro usurio. A regra simples e se baseia em alterar o dado na base de dados e o buffer da instncia de forma a garantir a completa consistencia do dado na instncia que provocou a alterao. Para as demais instncias temos que ter um mecanismo mais complexo. Esse mecanismo baseia na definio feita no parmetro rdisp/buffrefmode e na manipulao da tabela DDLOG. Esse parmetro que define o comportamento do sistema quando um dado que est em buffer alterado. Os valores possveis so : Sendon, sempre que um dado que est no buffer alterado feita uma marca na DDLOG indicando que este dado deve ser invalidado em todos os buffers Sendoff, evita que o mecanismo manipule a tabela DDLOG ignorando a sincronizao de outras instncias (se elas existirem) Execauto, garante que de tempos em tempos (definido pelo parmetro rdisp/bufreftime) a instncia varre a tabela DDLOG para invalidar os dados que esto no buffer garantindo assim que na prxima leitura o dado ser obtido no banco de dados Execoff, evita que a tabela pesquise a tabela DDLOG de tempos em tempos para invalidar os dados que esto no buffer A regra geral para o rdisp/bufrefmode a seguinte : Single system (sistema com apenas uma instncia) devemos preencher o parmetro com sendoff,execauto que significa que toda alterao em um dado que est no buffer atualizada na base de dados e no buffer mas no registrada na DDLOG Distributed system (sistema com mais de uma instncia) devemos preencher o parmetro com sendon,execauto que garante que toda alterao no dado propagada para o buffer local, para a base de dados e registrada na DDLOG para garantir a sincronizao
jluiz@cemig.com.br
Pgina 148
ACADEMIA
BASIS
Granularity of invalidation
Durante o processo de invalidao do dado quando ele alterado (marca feita na DDLOG) os demais buffers so afetados da seguinte forma : Full buffering, qualquer alterao invalida toda a tabela Generic buffering e single record buffering, alteraes feitas por um abap invalidam o conjunto de dados relacionado ao mesmo conjunto (mesma chave de buferizao). Devemos tomar cuidado com alteraes que no so executadas na work area mode pois elas invalidam todos os dados da tabela (independente da forma de buferizao) Todo esse mecanismo de definio se uma tabela deve ser buferizada feito pela transao SE13.
Bypassing the Buffer

Alguns comandos abaps ignoram os dados que esto no buffer. Isto acaba por evitar a otimizao que o buffer realiza. Os comandos so : Select bypassing buffer Select from view Select for update Select com funo de agregao (count, max, sum, avg, etc) Select distinct Where com is null Order by (se no for chave primria) Sql nativo Non single Select em tabelas com single buffer Select que no usa os campos corretos em tabelas com generic buffer
Strategy for Technical Criteria

Devemos buferizar tabelas que : So relativamente pequenas (normalmente menores que 1 Mb) ou em casos especiais com tamano mdio (menores que 10 Mb) No sofrem alteraes (alteraes < 1% das leituras) No precisam estar imediatamente consistentes em todo o ambiente Podem ser acessadas pela chave primria Contm dados de customizao Tabelas condicionais da SAP com sufixo de 000 a 499 (Annn, Bnnn, Cnnn, Dnnn, KOTEnnn, KOTFnnn e KOTGnnn) No devemos buferizar tabelas que : Tem tamanho superior a 10 Mb A pesquisa por dados feita pelo indice secundrio Contm dados transacionais Contm dados mestres (tabelas grandes e acessadas por uma srie de indices secundrios) Tabelas condicionais da SAP com sufixo de 500 a 999 (Annn, Bnnn, Cnnn, Dnnn, KOTEnnn, KOTFnnn e KOTGnnn) Devemos sempre lembrar de verificar se o buffer vai comportar a nova tabela que est sendo buferizada.
jluiz@cemig.com.br
Pgina 149
ACADEMIA Optimization
BASIS
Para otimizar os buffers de tabelas devemos ter em mente duas tarefas bsica : pesquisar por tabelas que deverio estar buferizadas e no esto e pesquisar pelas tabelas que esto buferizadas e no deverio estar. Para o primeiro caso, devemos procurar pelas tabelas desenvolvidas pelo cliente (iniciadas por Z) e tabelas de customizao que normalmente no so buferizadas (sufixadas por 500 a 999). Para a segunda tarefa devemos verificar o tamanho e a frequencia de alteraes que possveis tabelas possam estar sofrendo. Para essa tarefa usaremos a transao ST10 (Table Call Statistics) e seguir o roadmap : Pesquisar por alto numero de invalidaes Verificar se esta tabela no deve ser desbuferizada. Para isso use a ST05 e ST10 Pesquise por tabelas com buffer muito grande Verificar se esta tabela no deve ser desbuferizada. Para isso use a ST05 e ST10 Pesquisar por tabelas com alto numero de rows affected Verificar se esta tabela no deve ser desbuferizada. Para isso use a ST05 e ST10 Pesquisar por tabelas com muitas leituras feitas por programas abaps Verificar se a tabela no deve ser buferizada. Para isso verifique as estatisticas, a frequencia de alterao, o tamanho, a viabilidade em funo da chave primria (transao DB05) e a mdia de consumo de processamento (ST03, database time > 40% (response time wait time)
jluiz@cemig.com.br
Pgina 150
ACADEMIA
BASIS
Others aspects about ORACLE

Cache Analysis
Uma boa anlise do cache est relacionada a permanente pesquisa por comandos SQL caros e por problemas de performance que no esto relacionados ao hardware ou a parametrizao do banco de dados. Outro ponto interessante a completa compreeno da arquitetura do Oracle. Isso garante uma viso abrangente do problema, a compreeno de como um statement passado, processado e devolvido pelo banco de dados, dos impactos que comandos SQL podem causar na shared sql area e da falta de estatsticas atualizadas
Shared SQL Area

Para compreendermos a shared sql area temos que ter os conceitos do uso que o Oracle faz dela, do impacto que comandos SQL caros podem causar no consumo de cpu, de memria e de I/O aos datafiles. A maior parte das anlises devem ser feitas utilizando a ST04 (Database Overview Monitor). A primeira delas a identificao do data buffer hit rate que significa o percentual de acerto na leitura do dado que est no data buffer da shared sql area. O tamanho da shared sql area considerado correto se esse percentual estiver sempre acima de 94%. Entretanto no devemos analisar somente este numero. Um exemplo disso o resultado da diviso entre buffers gets por user calls. Se ele for maior que 15, o data buffer hit rate deixa de ser significativo em funo do alto volume de dados que est sendo tratado. Outra analise a ser feita a reduo do numero de buffer gets. Eles indicam que, provavelmente, esse alto volume de dados que esto sendo manipulados por erro do comando abap ou por erro do comando sql. Para diferenciamos quais comandos devemos analisar na ST10 (ST04 -> detail menu -> sql command) seguiremos o seguinte padro : Abap open sql, comando em letras maiusculas e com aspas delimitando os nomes dos campos Recursive call, comando em letras minusculas Sap statement ou exec sql statement, comando em letras maiusculas sem aspas como delimitadores Third party statement, comandos com letras maiusculas e minusculas
Analyzing SQL Statements

Para analisarmos um comando sql devemos estar apto a reconhecer um comando caro, analisar o impacto causado na shared sql area, entender o explain e a distribuio estatstica. Um comando sql caro pode ser de dois tipos. O primeiro tipo aquele que acessa um grande volume de dados (buffer gets) mas retorna poucos registros. Tipicamente o problema deste comando esta relacionado a m escrita da clausula where ou ao uso erro de indice pelo otimizador. O segundo tipo aquele que tambm acessa um grande volume de dados e retorna todo ele para o emissor do comando sql. Esse problema est relacionado a uma m construo do abap que desloca o processamento que deveria ser feito pelo banco de dados para o processador onde o abap est sendo executado gerando um grande trafego de dados na rede. Para identificarmos estes comandos pesquisaremos na ST10 por altos volumes em buffer gets, disk reads e records (cada um desses itens possui seu prprio hit ratio). Devemos estar atentos a alguns indices que indicam uma m performance, como : Nmero de buffer gets maior que 5% do total de reads Alto nmero de buffer gets Alto nmero de buffer gets por registro Alto nmero de registros por execuo
jluiz@cemig.com.br
Pgina 151
ACADEMIA
BASIS
Comandos que lem mais que 2% do total de leituras fsicas
De posse de um comando aparentemente pesado para o sistema podemos analisar detalhes de como o sql foi processado atravs do explain. Podemos tambm verificar se a estatistica est atualizada e eventualmente atualiza-la especificamente para uma tabela atravs da transao DB20 ou criar indices mais adequados atravs da SE11 ou SE12
Update Statistics
A estatstica da distribuio de valores de tabelas no R/3 sempre feita em dois passos. O primeiro a verificao de quais tabelas esto com as estatsticas desatualizadas e a marcao na DBSTATC das quais devem ser refeitas. Se for necessrio podemos utilizar a transao DB21 para dar manuteno na DBSTATC. O segundo passo a atualizao propriamente dita. A processo de atualizao pode ser feito seguindo dois algoritmos distintos : compute (onde toda a tabela analisada para determinar a distribuio) e estimate (onde uma amostragem feita para determinar a distribuio). A Sap recomenda que este procedimento seja feita pelo menos uma vez por semana ou sempre que houver um grande volume de dados incluidos ou excluidos no banco de dados. Para esse agendamento devemos utilizar a DB13. Se for necessrio atualizar uma tabela especfica utilizaremos a DB20.
Identify Coding
Um grande problema na anlise da performance do sistema a identificao de um comando sql que produz efeitos danosos ao sistema. Para localizarmos o comando utilizamos a transao ST04 (shared sql area) como j foi visto no item anterior de analise de sql. O passo seguinte a identificao de qual cdigo abap provavelmente contm este comando. Esse processo consiste em pegarmos o nome da tabela e listarmos, atravs da SE11 e where-used, onde ela utilizada. Depois disso entramos em programa a programa para tentar localizar a origem do comando. Esse sem dvida um trabalho muito arduo. Outra boa opo a identificao do comando no momento que ele acontece atravs das transaes SM50 e SM66. Nesse caso temos a vantagem de saber quem e qual a transao esta provocando os efeitos indesejveis. Para facilitar, podemos selecionar os processo que manipulam a respectiva tabela atrves da SM66 -> select process. Sempre que tentamos identificar o cdigo abap que produziu o sql devemos ter em mente as diferenas entre o open sql e o sql nativo. Devemos analisar as facilidades que o open sql permite e como elas so convertidas para o sql nativo, como por exemplo as tabelas internas (in itab) ou a clausula for all entries. Alm disso temos que lembrar que o abap pode estar fazendo referencia a uma view e o sql nativo provavelmente vai estar referenciando a tabela. Para esse caso, lembre de pesquisar o where-used para a tabela em questo. Outra opo descobrir a rea funcional atravs do programa RSSTATUS ou os componentes relacionados a tabela atravs da DB15 e acionar o time funcional responsvel para ajudar na pesquisa do respectivo cdigo abap.
Workflow and Reporting

Com a ativao do workflow no sistema podemos ter algumas facilidades de comunicao de documentos e a respectiva aprovao destes pelos responsveis. Basicamente temos que definir a atribuio de cada um (por exemplo, o administrador do sistema responsvel por analisar as queries e recomendar alteraes de design; o desenvolvedor responsvel por construir e otimizar os cdigos e as definies de banco de dados; e o usurio final responsvel por utilizar de forma otimizada o sistema) e estabelecer quais documentos devem transitar entre estes grupos funcionais. Com isso alguem pode solicitar uma determinada tarefa e encaminha-la para o executor. O executor aps realizar a tarefa passa o documento para que valida a qualidade e esse responde ao gerador do trabalho a resposta que o ciclo foi completado. Com isso passamos a utilizar a ferramenta de workflow do R/3 nas atividades de basis e de abap integrando a atividades de todos.
jluiz@cemig.com.br
Pgina 152
ACADEMIA
BASIS
Um bom exemplo desse recurso a ferramenta de abrir chamados na SAP atravs do OSS. Essa ferramenta que garante o bom encaminhamento das demandas dos usurios para a SAP e viabiliza a acumulao de uma base de conhecimento.
Index Utilization
Devemos associar a utilizao de ndices no banco de dados com as estatsticas atualizadas e com o otimizador de acesso baseado em custo. Sempre que utilizarmos uma clausula where (e em alguns outros casos tambm) o otimizador entra em ao para decidir qual a melhor forma de obter os dados na base de dados. Para que isso seja feito temos que ter os indices bem contruidos e planejados para as atividades que sero executadas, alm das estatisticas atualizadas. Basicamente temos que preocupar com a efetividade dos indices que existem e da seleo que ele permite. ndices que no permitem a seleo de uma quantidade inferior a 4% da quantidade total de linhas no so efetivos e normalmente no so necessrios. Alm disso devemos estar atentos as indicaes do explain do sql dos caminhos e mecanismos que esto sendo tomados em um determinado sql. Os mais importantes e que devem ser entendidos so : Index unique scan, o melhor caso pois permite a obteno de uma ou nenhuma linha com a leitura de cerca de quatro blocos (tres no indice e dois na base de dados) Index range scan, esse no muito bom pois no conseguimos saber quantos blocos sero lidos para a obteno da informao desejada Full table scan, a leitura simples e inteira da tabela e a quantidade de blocos afetadas diretamente proporcional ao tamanho da tabela Concatenation, onde o indice acessado vrias vezes em funo de opes OR ou IN com a concatenao dos resultados de cada um dos acessos feitos Nested loop, o conhecido join entre os dados de duas tabelas e seus respectivos indices
Creating na Index
Antes de criarmos um indice devemos verificar a sua efetividade atravs da simulao da criao na DB05 e da verificao da distribuio estatsticas dos valores. Durante a anlis dos dados produzidos pela DB05 devemos ter em mente que um bom indice aquele que permite que dado uma chave ele nos retorne uma pequena quantidade de registros. Outros fatores relacionadas aos indices no podem ser esquecidos, a saber : verificar se algum indice standard no est faltando; executar sempre a atualizao de estatisticas das tabelas e dos indices; alterar o cdigo para poder reaproveitar os indices j existentes; alterar os indices j existentes para garantir uma boa performance na maior variedade possivel de situaes e eventualmente criar um indice para atender especificamente um determinado tipo de pesquisa. Tudo isso pode e deve ser feito, quando o indice for standard, sempre com a aprovao ou com o aconselhamento da SAP.
Similar Statements
Tente garantir sempre que statements com a mesma funo sejam escritos de forma identica. Isso garante um bom aproveitamento da shared sql area (ela sempre maximiza os recursos para reaproveitar os cursores para o mesmo comando sql). Tente induzir o time de abap a criar convenes para garantir que os comandos sejam escritos da mesma forma em programas diferentes. Uma boa conveno a ser adotada combinar a ordem dos campos no comando sql igual a ordem na declarao da tabela. Para identificarmos se um mesmo comando foi escrito de formas diferentes procure comandos com o mesmo numero de buffers gets/execution ou buffer gets/records. Isso pode ser um bom comeo para detectar esses comandos mas lembrando sempre que isto um ajuste finssimo no sistema.
jluiz@cemig.com.br
Pgina 153
ACADEMIA
BASIS
View Processing
View um objeto lgico que simula a existencia de uma tabela, virtual, que na verdade a juno de uma ou mais tabelas. Na prtica o gerenciador do banco de dados executa um sql previamente montado, que imagem da definio da view, sempre que algum dado solicitado da view. Ou seja, um dado que acessado atravs da view no est previamente alocado a ela, ele descoberto e acessado no momento da execuo. Os principais tipos de view so : Nested loop, onde ordem de acesso as tabelas decida pelo otimizador com a identificao da driven table que normalmente possui a menor quantidade de registros, seguido do acesso a inner table para obteno dos demais dados Sort Merge Join, onde os dados das diferentes tabelas so acessados, classificados e finalmente mergeados aconselhvel que monitoremos as novas views em busca de possveis problemas de performances. Os mecanismos a serem utilizados so os mesmos mencionados anteriormente neste captulo.
Pooled and Clustered Tables

Tabelas pooled e clustered so tabelas que esto contidas em outras tabelas. Essa estrutura herdada do ambiente mainframe e da poca em que os bancos de dados relacionais ainda no existiam. Com essa estrutura podiamos viabilizar que um mesmo arquivo indexado poderia representar uma srie de outros arquivos indexados. Provavelmente esse tipo de estrutura j havia sido utilizado no R/2 e foi migrada para o R/3 com o respectivo reaproveitamento de cdigo. Os dois tipos implementados no R/3 so : Pooled e Clustered. Para diferenciarmos uma tabela normal dessas tabelas passaremos a chamar uma tabela normal de transparente table.
Pooled
Uma pool table uma transparent table que encapsula uma srie de outras tabelas conhecidas como pooled tables. Isto possivel pela definio de uma tabela pool com a seguinte estrutura : uma chave especifica que contem o nome da tabela pooled (TABNAME), um campo contendo a chave genrica (VARKEY) e um campo contendo todo o conteudo a ser acessado atravs da chave genrica (VARDATA). Com isso, utilizando apenas uma transparent table, podemos ter incontveis tabelas dentro desta tabela.
Clustered
No R/3, a clustered table a implementao fsica de um banco de dados hierarquico em uma estrutura de arquivo indexado. Essa estrutura tambm oriunda do mainframe e deve ter sido mantida para garantir tambm o reaproveitamento. A clustered table na prtica o encapsulamento de dados de tabelas diferentes em uma mesma linha. Ou seja, a juno de dados dependentes, mesmo que oriundos de tabelas diferentes, da mesma chave primria. A estrutura de uma clustered table um conjunto de campos que representam a chave primria que comum ao conjunto de dados e o DATA que um conjunto de informaes no documentadas constituidas pelas tabelas que compe a cluster table.
Common Mistake
Nunca tente manipular na clausula where de um sql os dados que vo estar ou na vardata de uma pool table ou no data de uma cluster table. Ou seja, sempre e somente utilize na clausula where os campos que compe a chave primria, tanto da pooled quanto da clustered tables.
jluiz@cemig.com.br
Pgina 154
ACADEMIA
BASIS
Workload Analysis Guide
Uma anlise geral pode indicar se existem problemas de performance gerais na instalao: Wait time dever ser < 10% response time Main menu dever estar < 100 ms Atravs da ST03, alguns valores indicam boa performance: Average roll in time < 20 ms Average roll out time < 20 ms Average load time < 10% response time e sempre inferior a 50 ms Average database time < 40% do (response time wait time) Average CPU time < 40% do (response time wait time) Average CPU time no pode ser muito inferior ao processing time
Road Maps Summary

Work Process Overview (SM50/SM66)
WP in status running Long processing: analyse status field Dir. Read, Seq. Read, Insert, Update, Delete, Commit DB analysis Database Lock Monitor (DB01) Wait due database locks Analyse lock holder Database Process Monitor (ST04 Oracle session) Look for SQL statements and identify the transaction SQL Trace (ST05) Identify and analyse specific SQL statement Load Report mem. config. analysis (small buffer) Roll in/out mem. Config. analysis (extended mem. & roll buffer) WP in status stopped Heap area allocation: analyse reason PRIV mem. Config. analysis (extended mem. & roll buffer) CPIC CPIC connection problem
Analysis Roadmap using workload monitor (ST03)

Workload Monitor (ST03) Wait time > 10% response time general performance problem DB time > 40% (response time wait time) detail SQL analysis SQL trace (ST05) Detail analysis of SQL statement Processing time > CPU time x 2 detail hardware bottleneck analysis Load time > 50 ms mem. config. analysis (small buffer) Roll time > 20 ms mem. Config. analysis (extended mem. & roll buffer) Transaction profile, sorted by response time total CPU time > 40% (response time wait time) detail ABAP analysis DB time > 40% (response time wait time) detail SQL analysis
Analysis Roadmap: R/3 Memory Configuration (ST02)

Buffer Monitor (ST02) Many swaps increase buffer size Extended memory: Max used > 80% In memory Extended mem. Full Detail analysis using Mode List Sigle users with high extended mem particular report analysis Ztta/roll_first > 1024 ztta/roll_first = 1 Roll buffer full: Max used > 80% In memory Increase roll buffer
Analysis Roadmap: Hardware consuption (ST06)

Operating System Monitor (ST06) CPU Idle < 20% CPU contention Other servers available Work process and users redistribution Top CPU process (ST06 Detail analysis) R/3 process with high CPU detail analysis using SM50 DB process wit high CPU detail analysis using ST04 External process with high CPU stop or redistribute
jluiz@cemig.com.br
Pgina 155
ACADEMIA
BASIS
High paging rate > 20% of RAM per hour memory contention Other servers available Work process and users redistribution File system cache > 10% RAM reduce file system cache Buffers monitor (ST06 Mode list) Programs with high memory detail analysis of transaction
Directory Summary
/usr/sap/trans
bin, contm basicamente os arquivos de parmetros TPPARAM e CONFIG.CFG actlog, onde so gravados cada action em um request ou task. Contm files com nomes <source SID>Z<6 digits> sapnames, com arquivos associados ao id dos usurios que efetuam release em changes buffer, com um import buffer para cada sistema R/3. Quando um change request liberado, o file correspondente ao sistema target atualizado data, contendo arquivos do tipo R9<5 digits>.<source SID> que contm os dados que foram exportados no transporte cofiles, com command files do tipo K9<5digits>.<source SID> contendo por exemplo os import steps que sero executados log, com todas as logs de transportes, como por exemplo ULOGs, ALOGs, SLOGs e as demais logs que descrevem as operaes executadas nos steps individuais ou coletivos
/oracle/<SID>
dbs: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora, init<SID>.sap, etc.). bin: executveis Oracle sapdata1,2,...: onde se localizam os data files origlogA, origlogB: online redo log files mirrlogA, mirrlogB: mirror online redo log files saptrace/background: Oracle alert files saptrace/usertrace: trace files dos shadow oracle processes sapereorg: rea de trabalho para reorganizaes, compress de backup files, etc. saparch: offline redo log area e logs do BRARCHIVE sapbackup: BRBACKUP e BRRESTORE logs sapcheck: sapdba logs (-next, -check, -analyze) /network/admin: arquivos de configurao do NET8
To be Known
R/3 profiles (/usr/sap/<SID>/SYS/profile)
Start profile: START_<instance>_<host>, que contm a relao dos componentes que sero ativados pelo sapstart na instncia Default profile: DEFAULT.PFL, que contm alguns parmetros globais do sistema Instance profile: <SID>_<instance>_<host>, que contm parmetros especficos da instncia
Startup sequence (startsap)

1. 2. 3. Ativa o programa sapstart O sapstart l a start profile para ativar os servios disponveis na instncia Em uma central instance, o sapstart ativa o message server, o dispatcher, o collector e o sender. Em uma dialog instance apenas o sender e o dispatcher sero ativados. Os processos sender e collector so utilizados para implementar o system log central do R/3 O dispatcher forka e cria processos child, tais como work processes e o gateway reader. Os work pocesses so criados de acordo com as informaes da instance e da default profile. O gateway reader independe de parmetros de profile, sendo sempre ativado Os work processes se conectam com a base de dados, que j se encontra rodando
4.
5.
Databse logs

Durante o processo de start, quando requerido, o startsap chama o script startdb que grava uma log apropriada no startdb.log Eventos significantes (start, stop, errors) /oracle/<SID>/saptrace/background/alert_<SID>_.log so logados pelo no Oracle alert file:
jluiz@cemig.com.br
Pgina 156
ACADEMIA

BASIS
Informaes detalhadas de erro so logadas no Oracle trace file: /oracle/<SID>/usertrace/ora_<pid>.trc Quando se utiliza o sapdba para start e stop do banco de dados, o sapdba grava uma log no diretrio /oracle/<SID>/sapreorg, .../sapcheck, .../sapbackup, dependendo da ao que foi executada
SAP/Oracle parameter files (/oracle/SID/dbs)

init<SID>.ora: parametrizaes da instncia Oracle init<SID>.dba: parametrizao do sapdba init<SID>.sap: parametrizao das ferramentas BRBACKUP e BRARCHIVE
Environment variables
ORACLE_SID=<SID>: nome da instncia DBS_ORA_TNSNAME: seta o <SID> do banco que ser conectado atravs do tnsnames.ora ORACLE_HOME: o diretrio home do oracle (/oracle/<SID>) SAPDATA_HOME e SAPDATAn: aponta para diretrios especficos contendo dados
jluiz@cemig.com.br
Pgina 157
ACADEMIA
BASIS
Anexos
Glossrio
Termo ABAP Descrio ABAP significa Advanced Business Application Programming e uma linguagem interpretada e de quarta gerao utilizada para desenvolver no ambiente SAP. Tanto seus fontes quanto seus p-code so guardados no banco de dados o dicionrio que contm todas as informaes sobre as estruturas lgicas dos objetos de aplicao e de banco de dados relacionais bem como os fontes ativos e verses antigas dos programas. O dicionrio trabalha como um dicionrio ativo e integrado com as ferramentas de desenvolvimento. uma das ferramentas do ABAP Workbench e destinada ao desenvolvimento e manuteno dos programas, funes, lgica de fluxo de janelas, etc. Alm das funes normais de editor de programas a ferramenta dispe de uma srie de acessrios para auxiliar no desenvolvimento. um conjunto de cdigo que processado seqencialmente atravs de um mdulo interpretador de comando. Existem dois tipos de programas, os relatrios e os dilogos um ambiente integrado com uma srie de ferramentas para o desenvolvedor produzir programas para o ambiente R/3 Processo que torna um objeto disponvel para uso. O efeito direto da ativao a gerao de um objeto runtime correspondente ao que foi ativado. Este runtime que efetivamente interpretado pelo kernel Estrutura especial criada pela SAP e serve para adicionar elementos a uma estrutura j existente. O objetivo desta estrutura alterar um standard sem efetivamente provocar impacto nos controles de verses dos objetos desenvolvidos pela SAP Dados especficos de um client e composto dos dados mestres e dos dados transacionais do negcio Mquina que prov servios como : dialog, update, enqueue, background processing, print formating e gateway. Um application server contm um dispatcher e um ou mais work process. O dispatcher recebe a solicitao do servio a ser executado e atribui-o ao work process disponvel. Um application server possui pelo menos um dialog e gateway. Client change option que significa que a qualquer customizao do sistema, o R/3 solicitar uma request para guardar tudo o que ser feito. Um sistema R/3 que assume as funes de gerenciamento do domnio de transportes se o primary domain controller ficar indisponvel. ativado manualmente. Todas as ferramentas disponibilizadas pelo R/3 para o gerenciar e transportar todas customizaes e desenvolvimentos entre os sistemas R/3 dentro do landscape Significa o gerenciamento das alteraes feitas no ambiente R/3 bem como a propagao destas para os demais ambientes com as respectivas verificaes e consistncia seguido da ativao nos ambientes destino. Pacote contendo as informaes registradas e acumuladas pelas alteraes feitas no ambiente durante o trabalho de um desenvolvedor ou configurador. O principal uso de uma change request encapsular e propagar uma determinada alterao feita. a caracterstica que significa se a change request transportable, customizing, local ou not assigned. Comercial, organizacional e tecnicamente termo que significa unidades de dados contidas e organizadas dentro de tabelas Durante a manuteno de um client a opo que determina se alteraes
ABAP dictionary
ABAP editor
ABAP program
ABAP workbench Activation
Append structure
Application data Application server
Automatic recording of changes Backup domain controller Change and transport organizers CTO Change management Change request
Change request attribute Client Client change
jluiz@cemig.com.br
Pgina 158
ACADEMIA
Termo options
BASIS
Descrio dependentes ou independentes de mandante podem ocorrer e se sero armazenadas automaticamente.
Ainda no terminado
jluiz@cemig.com.br
Pgina 159
ACADEMIA Transactions
Transaction
BASIS
Description Alerts Users Logged On Display SAP Directories Display table buffer (Exp. session) Database Analyze exclusive lockwaits Analyze tables and indexes Analysis of a table acc. to index Overview of Backup Logs Database administration calendar Show SAPDBA Action Logs CCMS - Document archiving DB system check (trigger/browse) DB system check (configure) No.of table tupels acc. to stat. Maintenance control table DBSTATC Table view of DBMSGORA CCMS Set up CCMS Computing Center Management System Job Scheduling Monitor Network Graphics for SAP Instances Presentation, Control SAP Instances Maintain SAP Instances Alerts Thresholds Maintenance Maintenance of profile parameters Profile parameter maintenance Maintain RFC server group assignment Read XMI log CCMS MT standard monitor CCMS Customizing of the mon. infra. Gateway Monitor Maintain Logon Group ABAP Workbench Execute program ABAP/4 Dictionary Maintenance ABAP/4 Dictionary Display Maintain Technical Settings (Tables) Utilities for Dictionary Tables ABAP/4 Repository Information System Data Browser General Table Display ABAP Objects Class Library Application packet ABAP Runtime Analysis ABAP/4 Text Element Maintenance Context Builder ABAP/4 Dialog Modules ABAP/4: Logical Databases ABAP Function Modules ABAP Editor Splitscreen Editor: Program Compare MP: Standards Maint. and Translation Menu Painter Maintain Area Menu
AL08 AL11 AL12
* * *
DB01 DB02 DB05 DB12 DB13 DB14 DB15 DB16 DB17 DB20 DB21 DB31
* * * * * * * * * * * *
SRZL RZ01 RZ02 RZ03 RZ04 RZ06 RZ10 RZ11 RZ12 RZ15 RZ20 RZ21 SMGW SMLG
* * * * * * * * * * * * * *
SA38 SE11 SE12 SE13 SE14 SE15 SE16 SE17 SE24 SE29 SE30 SE32 SE33 SE35 SE36 SE37 SE38 SE39 SE40 SE41 SE43
* * *
* *
jluiz@cemig.com.br
Pgina 160
ACADEMIA
Transaction SE48 SE49 SE51 SE52 SE54 SE55 SE56 SE57 SE61 SE62 SE63 SE64 SE65 SE66 SE71 SE72 SE73 SE74 SE75 SE76 SE77 SE80 SE81 SE82 SE84 SE85 SE86 SE87 SE88 SE89 SE90 SE91 SE92 SE93 SE94 SE95 SMOD
BASIS
Description Program Analysis: Call Hierarchy Program Analysis: Table Manipulation Screen Painter Parameterized screenpainter call Generate table view Internal table view maintenance call internal call: display table view internal delete table view call R/3 Documentation Industry Utilities Translation: Initial Screen Terminology R/3 Docu.: Short Text Statistics R/3 Documentation Statistics SAPscript form SAPscript styles SAPscript font maintenance (revised) SAPscript format conversion SAPscript Settings SAPscript: Form Translation SAPscript Translation Styles Repository Browser Application Hierarchy Application Hierarchy R/3 Repository Information System ABAP/4 Repository Information System ABAP/4 Repository Information System Data Modeler Information System Development Coordination Info System Maintain Trees in Information System Process Model Information System Maintain Messages Maintain System Log Messages Maintain Transaction Codes Customer enhancement simulation Customer Enhancements to AEW Objects SAP Enhancement Management System Monitoring Work Process Overview Lock transactions System Messages User Overview Display and Delete Locks Display Update Records System Log Installation Check Call View Maintenance Table Maintenance Batch Input Monitoring Define Background Job Background Job Overview Job Analysis Execute external OS commands Work Process Overview List of SAP Servers TXCOM maintenance THOST Maintenance Number Range Buffer Asynchronous RFC Error Log RFC Destinations (Display/Maintain) Maintain table BTCCTL (background processing) Pgina 161
* * *
SM0 SM01 SM02 SM04 SM12 SM13 SM21 SM28 SM30 SM31 SM35 SM36 SM37 SM39 SM49 SM50 SM51 SM54 SM55 SM56 SM58 SM59 SM61 jluiz@cemig.com.br
* * * * * * * * * * * * * * * * * * * * * *
ACADEMIA
Transaction SM62 SM63 SM64 SM65 SM66 SM69 SMX
BASIS
Description Display/Edit Events Display/Maintain Operating Mode Sets Release of an Event Background Processing Analysis Tool Systemwide Work Process Overview Maintain external OS commands Display Own Jobs System Tuning System Trace Setups/Tune Buffers Performance,SAP Statistics, Workload Select DB activities Trace for SQL, Enqueue, RFC, Memory Operating System Monitor Application monitor Network Monitor Network Alert Monitor Table call statistics Display Developer Traces Application Monitor Application Analysis ABAP/4 Runtime Error Analysis Local transaction statistics Transports Transport Organizer Workbench Organizer: Tools Set Up Workbench Organizer Workbench Organizer Customizing Organizer Transport Management System User Master Administration User Maintenance User Display Maintain Authorization Profiles Maintain Authorizations Maintain user parameter Maintain Authorization Fields Maintain Authorization Objects Maintain Users Own Data Display Check Values Analyze User Buffer Client Administration Client Copy - Special Selections Client Copy Log Client Administration Client Delete Client import Client import - postprocessing Client export Remote client copy Client import - postprocessing Customizing comparison Archive Archive Management Archiving object definition Archive Information System Archive Information System (Customizing) Pgina 162
* * * * * * *
ST01 ST02 ST03 ST04 ST05 ST06 ST07 ST08 ST09 ST10 ST11 ST12 ST14 ST22 STAT
* * * * * * *
* * *
SE01 SE03 SE06 SE09 SE10 STMS
* * * * * *
SU01 SU01D SU02 SU03 SU2 SU20 SU21 SU3 SU53 SU56
* * * * * * * * * *
SCC1 SCC3 SCC4 SCC5 SCC6 SCC7 SCC8 SCC9 SCCL SCU0
* * * * * * * * * *
SARA AOBJ SARI SARJ jluiz@cemig.com.br
* *
ACADEMIA
Transaction SARL
BASIS
Description Call of ArchiveLink Monitor ALE ALE Application menu ALE Development ALE Distribution menu ALE Master Data IMG Application Link Enabling Spool management Output managment Spool administration Others Archive logical file paths Table History Customizing objects : selection for compare Archive logical file names Data transfer workbench Not classified Archiving - Delete program Archiving - Reload Archiving - Management Archiving class definition SAP Alert Monitor Database alert monitor Operating system alert monitor Monitor call distribution Monitor current workload Performance: Upload/Download EarlyWatch Report Data for database expertise Download to Early Watch Display Shared Memory (Expert mode) Customize SAPOSCOL destination Local Alert Monitor for Operat.Syst. Remote Alert Monitor f.Operat. Syst. Local File System Monitor Remote File System Monitor EarlyWatch Data Collector List ABAP Program analysis Dependent objects display Parameter changes in database ADABAS D: Diagnostic monitor Early Watch Profile Maintenance Manage JCL jobs for OS390 DB syst. check (ORA): Configuration DB System check (configure, IFMX) SAP Alert Monitor Maintain Transaction Codes Display Standard Reporting Tree Start Report (Remote) CATT utilities Factory Calendar with GUI CATT management Record CATT procedures Computer Aided Test Tool Change Documents for Utilities Change Documents: Number Ranges Display Change Document Objects Menu for Control Enabling Technology Pgina 163
BALA BALD BALE BALM SALE
SP01 SPAD
* *
FILE OY18 OY19 SF01 SXDA
* * * * *
AARD AARR AARV ACLA AL01 AL02 AL03 AL04 AL05 AL06 AL07 AL09 AL10 AL13 AL15 AL16 AL17 AL18 AL19 AL20 AL21 AL22 DB03 DB07 DB11 DB2J DB32 DB33 RZ08 SAR SAR0 SC38 SC80 SCAL SCAM SCAR SCAT SCD0 SCDN SCDO SCET jluiz@cemig.com.br
ACADEMIA
Transaction SCMP SCOM SCOR SCOT SCPF SCPR1 SCPR2 SCT1 SCU1 SCU2 SCU3 SCUI SE07 SECR SEPS SERP SES0 SESA SESE SESS SEU SEWA SM18 SM19 SM20 SM29 SM32 SM33 SM34 SM38 SM67 SM68 SMEN SMET SMETDELBUFF SMETDELPROG SMLI SMLT SMME SMO1 SMO2 SMO3 SMO4 SMO5 SMT1 SMT2 SMW0 SMW2 ST4A ST62 STDA STDC STDR STDU STFB STI1 STI2 STI3 STMP STP4 STPC STPD jluiz@cemig.com.br
BASIS
Description View/Table compare SAPcomm: Configuration SAPconnect - Send Attempts SAPconnect - Administration Generate enterprise IMG Customizing Profiles: Maintce tool Compare Customizing profiles Logical imports - overview Table Comparison - Export to Tape Table Comparison Against Tape Table History Communicate system status to SAP Transport System Status Display Audit Info System SAP Electronic Parcel Service Reporting: Change Tree Structure Maintain favorites Switching off the menu tree display Switching off the menu tree display Starting the R/3 menu Repository Browser Earlywatch Alert Reorganize audit Basis Audit Configuration System Audit Log Model Transfer for Tables Maintain Table Parameter ID TAB Display Table Parameter ID TAB Viewcluster maintenance call Queue Maintenance Transaction Job Scheduling Job Administration Session Manager Menus Display frequency of function calls Del. Measurement data in shared bfr Delete programs in shared buffer Language Import Utility Language Transport Utility Output control Message Block Table Repository Information System: SMOD Repository Information System: SMOD Repository Information System: SMOD Repository Information System: SMOD Repository Information System: SMOD Trusted Systems (Display <-> Maint.) Trusting systems (Display <->Maint.) SAP Web Repository Test multipart MIME interface Database: Shared cursor cache (ST04) Create industry short texts Debugger display/control (server) Debugger output/control TADIR consistency check Debugger display/control (user) CATT function module test Change Documents Payment Details Change Docs Correspondence Chg. Docs Transaction Authoriz. Proposal pool: Selection Select DB activities Test Workbench, Start test package Test Workbench Pgina 164
ACADEMIA
Transaction STSN STVR STW1 STW2 STW3 STW4 STW5 SU01_NAV SU05 SU10 SU12 SU22 SU23 SU24 SU25 SU26 SU52 SU54 SU55 SU80 SU81 SU82 SU83 SU84 SU85 SU86 SU87 SU96 SU97 SU98 SU99 SUCH SUCU SUIM SUPC SUPN SUPO SUSE TU01 TU02 TUTT
BASIS
Description Customizing Number Ranges Time Strm WB: Transport Utility R/3 > R/2 Test Workbench: Test catalog Test workbench: Test plan Test workbench: Test package Test Workbench: Edit test package C maintenance table TTPLA User maint. to include in navigation Maintain Internet users Mass Changes to User Master Records Mass Changes to User Master Records Auth. Object Usage in Transactions Load Tables in TAUTL Auth. obj. check under transactions Upgrade Tool for Profile Generator Upgrade tool for Profile Generator Maintain User Parameters Session Manager Call the Session Manager menus Archive user change documents Archive user password change doc. Archive profile documents Archive authorization docs. Read archived user change documents Read archived password change doc. Read profile change documents Read authorization change documents Table maint.: Change SUKRIA Table maint.: Display SUKRIA Call report RSUSR008 Call report RSUSR008 Translatability CHECKs Table authorizations: Customizing all AUTH reporting tree (info sys.) Profiles for activity groups Number range maint.: PROF_VARIS Maintain org. levels Maint. for Self Upgrading Software Call Statistics Parameter changes Workbench Tutorial
Reports
Report RSTMSC0L RDDNEWPP RDDIMPDP RDDDICOL RDDMASGL RDDTACOL RDDDIS0L RDDGEN0L RDDMASGL RDDDIC1L RDDVERSL RDDEXECL RDDDIC3L jluiz@cemig.com.br Description Read Import Queues in Local Buffer
Pgina 165
ACADEMIA
Report RSPO0041 RSPO0043 RADDBDIF RHAUTUPD RSBDCREO RSBPCOLL RSBPSTDE RSBTCDEL RSCOLL00 RSM13002 RSORA811 RSORASNP RSPARAM RSPFPAR RSPO0041 RSPO0043 RSSNAPDL RSSTAT15 RSSTAT60 RSTBHIST RSUSR040 RSUSU000
BASIS
Description Delete old spool print Check TemSe consistency
User Master Data Reconciliation Reorganize BI folders and logs Collector for Background Job Run-time Statistics Delete Statistics Data from the Job Run-time Statistics Delete batch jobs Delete OS collector logs Update request analysis and processing tool Delete old brbackup/brarchive Reorganize the snap & stats logs Display profile parameter Display profile parameter Delete old spool request Check consistency of spool database Delete ABAP short dumps Display/change of workload parameters Reorganize table MONI Table History List authorization objects by complex selection criteria Current active users
OSS Notes
Number 001916 004108 004326 008541 008707 011796 012103 013202 015606 016083 016466 019909 022514 023345 023611 024092 026171 026317 026966 027928 028175 029276 030724 031395 031503 031557 032050 033525 033630 035493 036280 037104 Description Securing a production system How do I assign a password to sap* How do I delete the user sap* Secure the host hardware and OS unix Explanation about init<SID>.sap parameter tape_size Authorization profile P_BAS_ALL and table display Contents of table TCOLL Security aspects in ABAP Overflow of dispatcher request queue Standard jobs, reorganization jobs Customer namespace for SAP objects Setting compress_cmd for compress = only Error analysis for client copy Consistency check of ORACLE database FAQs about authorizations Distribution of background jobs on application server Possible entry values for command fields Set up for LOGON group for autom. load balancing Background jobs do not start when transporting Consequences in transport during password change Questions regarding the authorization concept SAPCPIC: Where are passwords visible ? Data protection and security in R/3 System parameters: Defined where? Displayed how? FAQ: Background jobs The multi-client concept of R/3 - Oveview RSCOLL00: report runs infinitely, incomplete data Important information about SAP patches Deleting old BRBACKUP, BRARCHIVE entries Secrecy and data security obligations Background Work Processes Reserved for Job Class A Error analysis: Background processing system Pgina 166
jluiz@cemig.com.br
ACADEMIA
Number 039267 039412 040689 041732 042268 047502 048018 050088 051222 051789 052505 053030 053062 053064 062431 062739 063480 064015 065761 066533 066612 066687 067074 068048 068544 069444 070085 070128 070547 070639 071058 077429 077462 080210 083327 083699 084052 086895 088416 089324 091096 096896 099088 099284 099502 099962 100400 101146 109515 118823 122718 127773 182592
BASIS
Description Availability of the R/3 security guide How many work processes to configure New reports for the user informations system Deletion of data in transport directory Operating SAPLPD as a service under Windows NT Messages of the Remote Clientcopy Third party products Operation modes and overflow of dispatcher queue Poor user distribution in logon distribution Support offered by SAP after end of maintenance Online archiving versus data integrity Database reorganization and R/3 archiving What is important when reloading from archives ? SAPoffice: Connection over MAPI interface Configuring a central transport host R/3 and MS Exchange linking Test tool for message servers: lgtst Determine configuration problems under Windows NT Automatic unlocking after incorrect logon Network security products Secude and Kerberos Transporting original objects using se01 Deactivating the automatic user SAP* Error messages/terminations in client copy Re-processing failed update records via SM13 Docu/Help for copying clients Client transport How are batch jobs scheduled? Innovations in BRBACKUP and BRARCHIVE Version 3.1G 'SAPgui in Java': scope of functions & availabilit C/2 certification of R/3 Profile generator: composite note Setting up transport system in heterogeneous system R3trans: Table logging Additional Info: Upgrading to 4.0x PC inst Zero administration memory management from 4.0A/NT Archiving: revised adk versions Table Compare: Info about Cust. Cross System Check Improvements for BRBACKUP/BRARCHVIE/BRRESTORE 4.0 RFC exception: RESOURCE_FAILURE SCC1 in Release 4.0B Error messages when you use DB_VERIFY dbv reports corrupt blocks in SYSTEM and PSAPTEMP Batch:authorization object S_BTCH_JOB, S_BITCH_NAM Update groups for asynchronous updates Size of client CBO: Tables with special processing Several enqueue work processes Delete/change transactions codes in command field
RZ10 Parameters
Parameter Rspo/store_location Rspo/files/root/G jluiz@cemig.com.br Default db $(DIR_GLOBAL) Pgina 167 Description Controls where TemSe stores the spool data rule to build file names for TemSe
ACADEMIA
BASIS
Default 300s 0 Description Active authorization for limit page printing
Parameter Rsisp/max_wprun_time Rspo/auth/pagelimit
Auth/auth_number_in_userbuffer Auth/no_check_on_tcode eu/iwb/help_type eu/iwb/installed_languages eu/iwb/path_win32 eu/iwb/server_win32 Login/min_password_lng Login/password_expiration_time Rdisp/btcname Rdisp/btctime Rdisp/mshost Rdisp/trace Rdisp/wp_no_btc Rsdb/reco_sleep_time Rsdb/reco_trials
2000 N
Maximum number of authorizations in user buffer No authorization check on object S_TCODE Type of Extended Help (format/access) Installed Help Languages File path for Help on Win32 platforms HTTP server for help on Win32 platforms
60
5s 3
Name of application server that processes events Start Interval for Background Scheduler Hostname where message server is located Trace level for startup log Number of background work processes quantidade de tempo de espera para uma nova tentativa de reconexo ao banco Quantidade de tentativas de reconexo
jluiz@cemig.com.br
Pgina 168
This document was created with Win2PDF available at http://www.daneprairie.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only.

Academia Basis

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Academia Basis

Enviado por

Direitos autorais:

Formatos disponíveis

ACADEMIA

Joo Luiz Barbosa

DIRECTORY SUMMARY................................................................................................................ 156

TO BE KNOWN ................................................................................................................................. 156

SAP SAP SAP

erika.quiros@sap.com luiz.mestrinel@sap.com rinaldo.morais@sap.com e rinaldomorais@yahoo.com

Solangol Skyline SAP CEMIG CEMIG SAP SPEC SAP

Demais colaboradores : Mrcio Cicarelli CEMIG

Primeira Semana R/3 Basis Technology

Business Framework Architecture

R/3 as an Open System

Scalability and the Client/Server Concept

R/3 System Client/Server Configurations

The Middleware Basis

Portability and System Plataforms for the R/3 System

System Plataforms for the R/3 systems

R/3 Menu Structure

R/3 Database Interface

Work Processes and Dispatcher

R/3 Application Services

Rules for the Type and Number of Processes in the Application

R/3 Transaction and LUW

Lock Concept and Asynchronous Update

R/3 Printer Services

R/3 Gateway Service

Communication with CPI-C

Remote Function Call

Business Objects and BAPIs

R/3 System as an OLE Server or an OLE Client

Distribution of Business Processes with ALE

Data Transfer and Batch Input

R/3 Graphical User Interface

Configurao desejvel Pentium 133 32MB Winsock.dll

Configurao desejvel Pentium 133 48MB TCP/IP

Types of Online Help

SAPLOGON Options e traces

SAP MAPI and SAPGUI for java

SAP Online Service System (OSS)

Starting and Stoping R/3 NT Version

Process Startup Sequence

Parameter Read Sequence

Logs and Traces Logs and Traces for Database Startup

Startup logs and traces in Windows NT

Startup logs and traces in R/3

Reasons for R/3 Downtime

Before stopping the R/3 system

Stopping the R/3 system

Database Error Stopping

Backup off-line: database reconnect

Starting and Stoping R/3 Unix Version

Database Startup and Logs

R/3 Startup and Logs

Stopping R/3 Systems

RZ10: Profile Maintenance

Starting and Stopping Instances with the CCMS

Operation Modes and Scheduling

Events in Job Scheduling

Changing or Monitoring background Jobs Changing background job

Job API, XBP-API and XMI-API

Authorization for Background Jobs

Authorization for External Commands

Authorization for External Management Interfaces

Dicas sobre jobs

Advanced Background Processing