docResumo da Academia BASIS
download 
Denúncia Transcrição
Resumo da Academia BASIS
ACADEMIA BASIS CEMIG Academia Basis Junho/200 João Luiz Barbosa João Luiz Barbosa Junho/2000 Página 1 ACADEMIA BASIS CEMIG Índice ÍNDICE ................................................................................................................................................... 2 INTRODUÇÃO.................................................................................................................................... 12 PLANO DE ESTUDO ............................................................................................................................... 12 DIREITO DE AUTORIA ........................................................................................................................... 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 ............................................................................................................... 20 RULES FOR THE TYPE AND NUMBER OF PROCESSES IN THE APPLICATION ..................................... 21 R/3 TRANSACTION AND LUW ............................................................................................................. 21 LOCK CONCEPT AND ASYNCHRONOUS UPDATE ................................................................................ 21 BACKGROUND PROCESSING ................................................................................................................ 23 R/3 PRINTER SERVICES........................................................................................................................ 23 R/3 INSTANCE ....................................................................................................................................... 23 João Luiz Barbosa Junho/2000 Página 2 ACADEMIA BASIS CEMIG INTERFACES...................................................................................................................................... 25 R/3 AS AN OPEN SYSTEM ..................................................................................................................... 25 R/3 GATEWAY SERVICE ....................................................................................................................... 25 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 João Luiz Barbosa Junho/2000 Página 3 ACADEMIA BASIS CEMIG BACKGROUND PROCESSING ....................................................................................................... 41 BACKGROUND CONCEPTS AND FEATURES ......................................................................................... 41 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 João Luiz Barbosa Junho/2000 Página 4 ACADEMIA BASIS CEMIG 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 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 João Luiz Barbosa Junho/2000 Página 5 ACADEMIA BASIS CEMIG ADVANCED TRANSPORT MANAGEMENT ................................................................................ 78 TRANSPORT DIRECTORY ..................................................................................................................... 78 THE TP PROGRAM ................................................................................................................................ 78 THE R3TRANS PROGRAM..................................................................................................................... 79 THE IMPORT PROCESS ......................................................................................................................... 79 TRANSPORT MONITORING ................................................................................................................... 81 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 João Luiz Barbosa Junho/2000 Página 6 ACADEMIA BASIS CEMIG 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 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 João Luiz Barbosa Junho/2000 Página 7 ACADEMIA BASIS CEMIG 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 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 João Luiz Barbosa Junho/2000 Página 8 ACADEMIA BASIS CEMIG 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 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 João Luiz Barbosa Junho/2000 Página 9 ACADEMIA BASIS CEMIG 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 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 João Luiz Barbosa Junho/2000 Página 10 ACADEMIA BASIS CEMIG WORKLOAD ANALYSIS GUIDE ................................................................................................. 155 DIRECTORY SUMMARY............................................................................................................... 156 TO BE KNOWN ................................................................................................................................ 156 ANEXOS............................................................................................................................................. 158 GLOSSÁRIO ......................................................................................................................................... 158 TRANSACTIONS ................................................................................................................................... 160 REPORTS ............................................................................................................................................. 165 OSS NOTES ......................................................................................................................................... 166 RZ10 PARAMETERS ........................................................................................................................... 167 João Luiz Barbosa Junho/2000 Página 11 ACADEMIA BASIS CEMIG Introdução Plano de Estudo A estratégia para o estudo durante a academia será de sete horas durante o período de aulas na SAP e de cerca de quatro horas diárias no hotel para rever a aula do dia. Idealmente a revisão da sexta-feira deve ser feita no sábado 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 Márcio Cicarelli ([email protected]), durante a academia de Unix/Oracle de 1999. Na prática eu ([email protected]) vou elaborando o meu próprio resumo e anexando as partes elaboradas pelo Márcio que acho relevantes. A ordem dos dois resumos é um pouco diferente e em alguns capítulos os textos não tem nada a ver um com o outro, mas na maioria os textos são bem parecidos ou com pequenas alterações provocadas por um maior detalhamento ou comentários. Só para ter uma idéia até o momento este resumo tem 75 mil palavras e o do Márcio tinha cerca de 52 mil. A minha previsão é que até o final ele tenha cerca de 80 mil palavras. Apesar deste alto volume de palavras, o que interessa é o conteúdo final (para eventualmente passarmos na prova). Em relação aos anexos : eles ainda não estão acabados, eles também contém somente o que foi dado até o momento. Até este ponto eu ainda não fiz nenhum tipo de revisão ortográfica ou gramatical, portanto você certamente encontrará algumas frases com sentido duvidoso ou até mesmo erros grosseiros de português. Conto com a sua colaboração para corrigir o texto e agregar maiores detalhes ou informações relevantes. Desde já, muito obrigado pelas dicas que você certamente enviará para o meu e-mail. Direito de autoria Lembre-se sempre, copiar não é crime, ignorar o autor ou assumir todo o crédito é. Participantes da Academia Participante Instrutores : Erika Quirós Luiz Mestrinel Rinaldo Morais Vera Acadêmicos : Ana Maria Aroldo Higashi Cláudio Milos Joao Luiz Barbosa Marcelo Silva Priscila Silva Renan Guedes Ricardo Magalhães Empresa SAP SAP SAP SAP Solangol Skyline SAP CEMIG CEMIG SAP SPEC SAP Demais colaboradores : Márcio Cicarelli CEMIG João Luiz Barbosa Alguns e ½ [email protected] [email protected] [email protected] e [email protected] [email protected] [email protected] [email protected] e [email protected] [email protected] e [email protected] [email protected] e [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Junho/2000 Página 12 ACADEMIA BASIS CEMIG Primeira Semana R/3 Basis Technology Basis System and the System Environment The Integration Model Sistema R/3 é composto dos seguintes módulos: • Logística • 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 (não vem no standard) A camada Basis integra todos estes módulos. É a parte central do “diamante” do diagrama do R/3 e as demais são os módulos funcionais. Estes módulos se interconectam e interagem para garantir que o sistema é todo integrado, tanto na parte de processos quanto em relação a base de dados que reside em um único local. Business Framework Architecture O Business Framework Architecture (BFA) é a arquitetura estratégica do produto R/3. Ela trabalha com business components que são os módulos funcionais (FI, CO, etc.) configuráveis para se adaptar a cada empresa. Esta arquitetura fornece agilidade para se adaptar a um novo negócio, além da facilidade de se integrar com pacotes externos e fácil integração com a internet e intranet, permitindo desta forma uma fácil evolução sem a interrupção da operação do negócio da empresa. O princípio da arquitetura é que cada componente possui vida própria e sua complexidade esta restrita a ele mesmo. Para o mundo externo somente os métodos de interfaceamento são visíveis e acessáveis, fato que garante a total conexão deste com os demais sem causar grandes impactos ou interferências O Business Framework se mostra no R/3 como uma família de componentes separados porém integrados entre si. Estes componentes são: • Business Components: são os módulos funcionais (FI, CO, etc.) é são formalmente conhecidos como componentes relativos ao negócio; • Business Objects: Ordem, Empregado, Material, etc. São o próximo nível de hierarquia do R/3. Pertencem a um Business component e podem ser considerados como objetos básicos do sistema; • BAPI Interfaces: São os métodos com que os objetos de negócio são implementados dentro do R/3 (criar uma ordem, alterar o endereço de um empregado, etc.) e eventualmente podem ter mais de uma versão para o mesmo interfaceamento. A forma básica de distribuir as informações é o ALE e este será detalhado mais a frente. João Luiz Barbosa Junho/2000 Página 13 ACADEMIA BASIS CEMIG R/3 as an Open System O R/3 utiliza protocolos standard da industria para garantir a integração com outras aplicações: • TCP/IP: é o protocolo de comunicação difundido mundialmente; • EDI: Electronic Data Interchange, é o mecanismo utilizado para trocar informações de negócio com diferentes sistemas; muito utilizado pelos bancos; • OLE: Object Linking and Embendding, integra aplicações PC com o R/3 (padrão microsoft); • Open Interfaces, tais como arquivamento ótico, dispositivos de códigos de barras, etc. Além de standard da indústria, o R/3 também utiliza protocolos proprietários para comunicação: • RFC: Remote Function Call, que utiliza o protocolo copiado do CPI-C da IBM para comunicação e processamento das aplicações e tasks dentro do sistema R/3 ou com o sistema R/2 ou outros sistemas; • ALE: Application Link Enabling permite o processamento distribuído dentro do R/3. Na prática está associado a distribuição de informações a partir de um modelo de divulgação preestabelecido; Scalability and the Client/Server Concept O R/3 possui uma arquitetura modular de software seguindo o princípio da arquitetura cliente/servidor com enfoque na distribuição da força de processamento entre as várias plataformas envolvidas. Esta arquitetura permite que se separe a lógica da aplicação da base de dados e da camada de apresentação. Esta configuração permite ainda otimizar os custos e distribuir a carga através de configurações variadas de hardware. Com isto é possível dimensionar os servidores de acordo com a carga, permitindo a fácil escalabilidade do ambiente. Os ganhos nesta arquitetura na implementação R/3 são muitos: • Simples instalação de novos servidores para eliminar eventuais gargalos de processamento; • Servidores trabalham em paralelo, com carga homogênea e execução local dos programas; • Baixo tráfego de rede com a localização dos buffers de dados e programas próximo de onde serão 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 implementação R/3, a arquitetura client/server é orientada para o software, e não para o hardware como estamos acostumados a ver. Desta forma, Client é quem requisita e utiliza o serviço e Server é quem vai fornecer determinado serviço. Um servidor de aplicação por exemplo é server de alguns serviços das estações clients, porém é client dos serviços 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 não importando quem tem mais hardware ou quem normalmente executa a atividade. R/3 System Client/Server Configurations Os serviços (ou camadas) fundamentais de uma aplicação são três: Presentation, Application e Database services e existem várias formas de se implementar um sistema R/3, a saber : • Central, onde todos os componentes estão implementados em um mesmo host. Esta implementação corresponde a clássica implementação mainframe e não é comum de ser implementada; João Luiz Barbosa Junho/2000 Página 14 ACADEMIA • • BASIS CEMIG Two-tier, onde uma camada normalmente executa as funções de presentation (usualmente um PC) e a outra camada executa os serviços de application e database. Uma outra implementação two-tier poderia ser uma camada executando os serviços de database e a outra composta por PCs mais potentes que executariam as funções de presentation e application. A primeira implementação é comum em ambientes pequenos e com pouca disponibilidade de hardware para os servidores. A última implementação é normalmente utilizada em simulações ou desenvolvimento de software. Three-tier, onde cada serviço tem o seu próprio host. Nesta configuração é possível ainda assegurar uma divisão de carga na camada de aplicação, garantindo que determinados hosts fiquem dedicados para aplicações específicas. Por exemplo dedicar um host para servidor de aplicação dos usuários de MM, ganhando com isto performance na distribuição dos serviços. A configuração three-tier é a mais recomendada em R/3 por garantir a melhor distribuição de carga e escalabilidade nos grandes sistemas. Todos os servidores em uma configuração R/3 devem possuir endereço de IP fixo. Um sistema R/3 agrupa todos os componentes que estão associados com um banco de dados. Se utilizamos uma implementação em 3 camadas, os componentes do R/3 estarão presentes em todas as camadas da hierarquia: • Database Server, é instalado em um host central, onde todos os serviços de bancos de dados serão executados. • Um ou mais Application Servers conectados ao servidos de banco de dados. Nestes servidores estarão sendo processados a lógica da aplicação, ou seja, os programas. • Vários Presentation Servers conectados aos servidores de aplicação. Estas máquinas são também chamadas de frontends ou workstations. Nestas máquinas os usuários irão interagir com o sistema R/3 utilizando uma interface que proverá os serviços de presentation. The Middleware Basis O software Basis do R/3 (também chamado de middleware) roda em diferentes plataformas e também pode ser adaptado para atender as necessidades individuais das empresas. São vários os serviços que ele presta: • Provê o ambiente de runtime para as aplicações R/3 • Cuida da perfeita interação das aplicações com o sistema • Define uma arquitetura estável para as melhorias do sistema • Contém todas as ferramentas necessárias para a administração do ambiente • Permite a distribuição eqüitativa dos recursos e componentes do sistema • Provê as interfaces necessárias para os sistemas descentralizados e os produtos externos ao R/3 As principais características da tecnologia Basis são: • É uma arquitetura voltada para a configuração client/server • Trabalha com bancos de dados relacionais • Possui interface gráfica com o usuário (GUI) Basis é o responsável ainda pela integração dos aplicativos e do ABAP workbench com o software básico. Portability and System Plataforms for the R/3 System Para garantir uma alta portabilidade, as interfaces com o software básico são divididas em suas próprias camadas que variam de sistema para sistema (NT ou UNIX, Oracle ou Informix, etc.). Acima destas camadas as funcionalidades dos componentes R/3 são basicamente as mesmas, independentemente do hardware, software ou sistema operacional. A System Interface é responsável 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 básico (System Interfaces). Ele é o responsável por tarefas tipo scheduling ou gerenciamento de memória, tarefas estas muito próximas ainda do sistema operacional e que são parcialmente efetuadas por ele, João Luiz Barbosa Junho/2000 Página 15 ACADEMIA BASIS CEMIG mas são gerenciadas pelo R/3 por razões de portabilidade e performance. A User Interface provê as opções de apresentação dos aplicativos. A Communication Interface é o canal para a troca de informações, seja pela transferência de dados com o legado, seja pela comunicação program-toprogram provida pelo protocolo CPI-C ou ainda através da troca de informações pelo protocolo EDI. Todos os programas no R/3 são escritos na linguagem ABAP, proprietária do sistema. O DYNPRO é o screen interpreter e o sistema possui ainda um ABAP interpreter. A interação entre estes dois componentes forma a tecnologia Basis das aplicações R/3. O funcionamento destes dois interpretadores (tela e programa) se baseia em informações armazenadas no dicionário 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 são também 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 são: Oracle, Informix, MS SQL Server ou ainda o DB2 para as diversas plataformas. O SAPGUI que faz a camada de apresentação possui versões para Windows (3.1, 95, NT), OS/2 e Java. As linguagens utilizadas no R/3 são ABAP (aplicações com entendemos no R/3), C e C++ (para construção do kernel) e HTML e Java (para a parte de intranet e internet). João Luiz Barbosa Junho/2000 Página 16 ACADEMIA BASIS CEMIG Navigation Logging onto R/3 System O R/3 é um sistema voltado para clients. Com este conceito é possível controlar várias empresas em único sistema, separando-as por client (ou mandante). As chaves para se logar no sistema também são separadas por client. Para efetuar um logon é preciso ter chave no client específico. Além disso o sistema exige uma password e por ser multilíngue, deve-se ainda especificar a língua desejada no momento do logon. Um client pode ser visto como uma entidade organizacional separada dentro do R/3, com seus próprios dados (master data, transaction data), user master records e parâmetros específicos de customização. Apesar dos dados serem armazanados em tabelas únicas, os dados dos diferentes clients coexistem separados pela diferenciação do campo MANDT que faz parte da chave da maioria das tabelas (client dependents). A única exceção é a tabela T000 (definição dos clients no sistema) que é independent apesar de ter como primeiro o campo MANDT. O conceito de customização é a adaptação do sistema R/3 para as necessidades específicas de um usuário. Ao instalar um sistema R/3, ele vem basicamente com 3 clients default: • 000 é definido como um SAP standard é não deverá ser alterado pelos clientes, devendo ser utilizado como um template para a criação de novos clients • 001 é uma cópia do 000 com algumas configurações já feitas para facilitar o trabalho (vale somente para os Estados Unidos). A partir da versão 4.0 este cliente já pode ser apagado e foi mantido apenas para compatibilidade com as versões anteriores. • 066 utilizado pela SAP para se logar no ambiente do usuário para a execução de determinadas tarefas Um client é identificado pelos três dígitos numéricos e, com exceção dos 3 citados acima, cada instalação 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 opções de cascading em algumas entradas. As opções System e Help são comuns a todas as telas do sistema. Um nível abaixo fica o menu específico de cada aplicação, que exibe as funções básicas disponíveis para aquele sistema (criar um registro, por exemplo). Dynamic Menu disponível na tela inicial dá a opção de navegar em todas as opções disponíveis no formato de árvore do explorer, podendo selecionar a função desejada. É uma ferramenta que permite efetuar searchs por palavras chave. Uma tela típica do sistema R/3 possui as seguintes partes: • Title Bar, exibe o título 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 usuários • Standard Toolbar, onde se encontram os ícones mais freqüentemente usados para navegação 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 exibição de dados • Status bar, exibe informações referentes ao status atual do sistema (session number, system name, application server, worksation’s time, além de mensagens de interação com o usuário. • Text box inicializados com interrogação (?) são de preenchimento obrigatório João Luiz Barbosa Junho/2000 Página 17 ACADEMIA BASIS CEMIG Uma tela no R/3 pode ser acessada de 3 maneiras distintas: • Selecionando a opção no menu • Através de teclas de atalho (ALT + tecla) • Através do código da transação diretamente digitado no command field O command field aceita vários comandos que funcionam em conjunto com o código da transação • /n para encerrar a transação atual • /o para abrir uma nova sessão • /i para encerrar a sessão 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, funções e mensagens. Help também exibe informações técnicas referentes aos campos de uma tela, como por exemplo o parameter ID do campo que pode ser utilizado para customizar a tela com parâmetros default do usuário. (F1 + F9 também exibe as technical infos). A tecla F4 exibe os valores possíveis em um campo, onde esta informação está disponível (combo boxes). A opção System do menu é utilizada para exibir as tarefas comuns aos usuários do R/3. A opção User profile à Own Data do menu System permite ao usuário especificar valores defaults para seus campos, baseado no ID do campo (ver technical info). Na opção System é possível ainda configurar a lista de favoritos de cada usuário (User Profile à Favorite maint) Session Manager é uma ferramenta que permite ao usuário gerenciar todo o ambiente e até mesmo vários sistemas de uma única interface. No release 4.0 esta ferramenta ainda não se encontra em um estágio muito útil, mas cresceu muito no release 4.6. De qualquer forma esta ferramenta não 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 também pode ser acessado a partir do R/3. Ele é o botão 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. João Luiz Barbosa Junho/2000 Página 18 ACADEMIA BASIS CEMIG System Kernel R/3 Presentation Interface A interface de apresentação do R/3 é o SAPGUI que apresenta uma funcionalidade muito parecida entre as diversas plataformas do R/3. Um usuário treinado em uma determinada plataforma, salvo pequenas exceções está apto a operar o sistema nas suas mais diversas implementações. O fluxo de informação entre o SAPGUI e o servidor de aplicação não consiste de telas preformatadas, mas sim de strings lógicos contendo dados e caracteres de controle, o que faz com que o tráfego de dados se mantenha na casa de 1 a 2K por tela (cada enter). Estes “strings” são na verdade um protocolo de comunicação que é sempre utilizado para conversar com o dispatcher e é chamado de DIAG (dynamic information and action gateway) O dispatcher é 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). R/3 Database Interface O R/3 trabalha com bases de dados relacionais, que são compostas de tabelas bidimensionais e interagem com os sistemas através da linguagem padronizada SQL (Structured Query Language) que é comum a todas as implementações de bases relacionais, embora cada fabricante implemente algumas extensões no seu produto. O DB Interface é um módulo 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 implementação (Oracle, Informix, SQL Server) possui um módulo de DB Interface particular para aquela implementação, o que torna os programas ABAP independentes da implementação do banco. Estes comandos SQL escritos no ABAP são denominados OPEN SQL e o DB Interface é responsável pela sua correta transcrição para o SQL nativo do banco. Além disso, um programa ABAP pode codificar o comando diretamente em Native SQL. Neste caso o comando não passará pelo DB Interface, indo diretamente para a DB machine. Estes comandos poderão não ser independentes do banco utilizado, se utilizarem extensões 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 desnecessários ao DB server. Comandos escritos em native SQL não fazem uso deste buffer interno, uma vez que o acesso não passa pelo DB Interface. Normalmente as tabelas que vemos no R/3 são armazenadas no DB. Estas tabelas são conhecidas com tabelas transparentes. Elas são implementadas no DB exatamente como vemos no dicionário do R/3. Existem outros tipos de tabelas que são declaradas no dicionários mas não são implementadas exatamente como aparecem. As tabelas do tipo Pool são declaradas no banco como uma só mas para o R/3, aparentemente, são tabelas como outras quaisquer. Este recurso é utilizado para tabelas de poucas ocorrências e para evitar um grande número de tabelas. Existem também as tabelas tipo Cluster. Essas são uma desnormalização do dado dentro do modelo relacional. Mais precisamente é como se tivéssemos o conceito de campos múltiplos dentro de um registro (que infringe a primeira regra normal). O DB Interface não é o processo que acessa e mantém a conexão com o banco. Este processo é conhecido como shadow process e roda na máquina onde está o banco de dados fazendo a ligação do db interface, que está na maquina onde está a instance, e o banco de dados. João Luiz Barbosa Junho/2000 Página 19 ACADEMIA BASIS CEMIG Work Processes and Dispatcher Os principais componentes de um application server são: • Um dispatcher como o controle central da instance • Dispatcher queues para enfileirar as requisições (FIFO) • Um número configurável de work processes para processar os programas ABAP • Buffers e shared memory. Os work processes são serviços dentro de um sistema R/3 especializados em determinadas tarefas. O centro de um sistema R/3, a nível de controle de aplicação, é o Dispatcher. Ele, juntamente com o sistema operacional, é o responsável pelo controle e disponibilização dos recursos do sistema. Suas principais tarefas são o controle da comunicação, a conexão com o presentation e a distribuição de carga entre os work processes. O dispatcher distribui os serviços requisitados entre os WP disponíveis e se encarrega de enviar o dado processado para o SAPGUI, que deverá interpretá-lo e exibir para o usuário. Não existe um WP fixo para um determinado usuário, cuidando o dispatcher de ir utilizando-os conforme as requisições vão chegando, em um processo de fila FIFO. Quando um sistema R/3 é inicializado, o dispatcher é o responsável por lêr os parâmetros de configuração (profiles), gerar as rol areas, inicializar os work processes e se conectar com o message server da central instance. Cada dialog work process é coordenado por um componente interno denominado Task Handler. Ele ativa o screen processor ou o ABAP processor e é ainda o responsável pelo roll in e roll out das áreas de usuário. Existem memórias de uso exclusivo de um determinado work process e memórias que podem ser compartilhadas por todos eles. Esta diferenciação é gerenciada pelo memory management. A memória utilizada exclusivamente por um work process possui duas áreas reservadas para dados específicos de uma determinada sessão de usuário (user context area) e devem ser mantidas entre as pseudo conversas do dialog. Estas áreas são denominadas roll e paging areas. A roll area contém dados que ficam imediatamente disponível para o processamento no início 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 usuários. Nesta área são salvos os dados referentes ao usuário (user context) tais como suas autorizações, informações administrativas além de dados adicionais para o ABAP e dialog processors, que são dados que já foram coletados por dialog steps anteriores.Na shared memory existem dados disponíveis para todos os work processes, tais como o calendar, screen, table e program buffers. R/3 Application Services Um sistema R/3 é composto de uma série de work processes que funcionam em paralelo cooperativamente. Cada application server possui um dispatcher e um número configurável destes processos, que depende dos recursos disponíveis no host (basicamente memória e processamento). Work processes podem ser instalados para efetuar serviços de dialog, update, background e spool. Uma central instance possui ainda serviços de enqueue (que também é um work process) para gerenciamento de lock e dois outros serviços próprios: • Message Server responsável pelo serviço de comunicação entre os vários dispatchers que compõem um sistema R/3, que é portanto um pré requisito para a escalabilidade de vários servidores de aplicação trabalhando em paralelo. Ele é muito usado para a troca de dados de controle. • Gateway Server, também chamado de CPI-C handler, que permite a comunicação entre R/3, R/2 e aplicativos externos. É muito utilizado para trocar dados da camada da aplicação, incluindo ai dados da mesma instância. Resumindo, uma instância é nomeada pelos serviços que ela presta. Um bom exemplo disto é a instância 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 João Luiz Barbosa Junho/2000 Página 20 ACADEMIA BASIS CEMIG (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 Transações são unidades de processamento agrupadas em funções que executam alterações consistentes na base de dados, de acordo com a funcionalidade a que se propõem. Um exemplo típico seria o débito em uma conta para crédito em outra, que somente fazem sentido consistente quando executadas como um todo. Uma transação SAP é implementada através de uma série de dialog steps consistentes e conectados de forma coerente. Uma transação SAP não executa necessariamente em um único work process, uma vez que cada um dos seus dialog steps poderão estar sendo atendidos por WP diferentes que o dispatcher encontrou disponível em cada momento. Além disso, quando se utiliza o asynchronous update para processar as atualizações da base de dados, estes processos estarão sendo atendidos por outros work process que poderão inclusive se encontrar em outros hosts. No R/3 cada dialog step é composto de um processamento que inicia após o usuário entrar o dado (PAI – Process After Input) e pelo processamento e envio da próxima tela (PBO – Process Before Output). Do ponto de vista do usuário, cada dialog step começa com o preenchimento de uma tela e o posterior processamento até o envio da próxima tela. Para o sistema apenas as partes referentes ao processamento (PAI e PBO) compõem o dialog step já que durante o preenchimento da tela nenhum processamento será requerido. Este conceito de transação, que pode compor de um ou vários dialog steps, é chamado de LUW, ou Logical Unit od Work. Como os bancos de dados não suportam o conceito de transação para todos os processos conversacionais (begin/end transaction commands), é necessário saber diferenciar uma transação do ponto de vista SAP (SAP-LUW) de uma transação de banco de dados (DB-LUW) que é totalmente executada ou totalmente desfeita. Não existe meio termo numa DB-LUW. Enquanto uma SAP-LUW garante a integridade lógica do banco de dados (um determinado lançamento deverá existir nas tabelas x, y e z), uma DB-LUW garante a integridade física do DB e é executado necessariamente pelo gerenciador do banco. Uma transação SAP inicia uma SAP-LUW que somente termina ao encontrar um comando COMMIT WORK no programa ABAP ou então no final do asynchronous update. Lock Concept and Asynchronous Update A técnica principal utilizada numa SAP-LUW é a atualização assíncrona, onde as requisições de update na base de dados são coletadas separadamente e iniciam após o COMMIT WORK, onde são executadas em uma única DB-LUW para garantir a integridade do banco. Os mecanismos de lock existentes nos gerenciadores de bancos de dados não são suficientes para garantir a correta manipulação dos objetos de negócio, que muitas vezes envolvem uma série de tabelas em um único lançamento. Com o seu próprio mecanismo, O R/3 assegura que determinados dados permaneçam protegidos durante todo o processo de atualização do objeto. Esta tarefa é executada pelo Enqueue Work Process que utiliza uma tabela armazenada na memória principal (de João Luiz Barbosa Junho/2000 Página 21 ACADEMIA BASIS CEMIG onde o enqueue work process está rodando, também conhecido como enqueue server e é normalmente a central instance) para este gerenciamento. Sempre que um lock é requisitado o sistema verifica (através do enqueue wp) se a requisição não fere outro lock já postado na tabela. Havendo colisão de interesses, o processo é informado através de uma mensagem de erro, o que permite ao programa ABAP informar ao usuário que a sua operação não poderá ser executada no momento. Caso o enqueue work process não se encontre na mesma instance em que o processo está correndo, o que é normal em uma sistema R/3 de tres camadas, esta comunicação é efetuada pelo message server. Para que este mecanismo de requisição de lock funcione no sistema R/3, é necessário que um objeto de lock seja definido no dicionário ABAP especificamente para aquele objeto que se deseja travar. Já existem objetos definidos em uma tabela primária no dicionário do R/3, porém o usuário pode definir seus próprios objetos em tabelas secundárias (estes objetos do usuário precisam ter seus nomes começados por “EY” ou “EZ”. Os locks podem ser do tipo “S” (read) ou “E” (write). Um lock do tipo E somente poderá ser postado se não 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 próprio programa ou ainda pelo procedimento de update (segunda parte da SAP-LUW). Work processes podem gerar atualizações diretamente na base de dados mesmo que o banco não 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 requisição é direcionada para uma tabela (a VBLOG) existente fisicamente no banco de dados que age como um buffer intermediário onde as requisições de atualização são enfileiradas. Esta tabela contém basicamente o nome da rotina que será disparada para efetuar a atualização e os dados (parâmetros) para a rotina efetuar as atualizações necessárias. Transações que são canceladas pelo usuário não tem o seu registro de header completado na VBLOG e portanto suas atualizações não são efetuadas. Os registros de atualização podem ser divididos em componentes V1 e V2. Basicamente processos que são críticos são armazenados em componentes V1 e processos secundários que são menos time-criticals são armazenados nos componentes V2. Informações de estatísticas caem nesta segunda categoria. O processo assíncrono 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 são recuperados e atualizados fisicamente na base de dados. Caso ocorram erros nesta fase em processos V1, as alterações no DB daquela DB-LUW são desfeitas por rollback e os registros permanecem na VBLOG assinalados com um flag de erro. Caso ocorram erros em processos V2, apenas aquele registro será setado com erro e as demais atualizações V2 continuam sendo executadas. Quando ocorrem os erros descritos acima, o usuário é notificado através de mail e medidas corretivas precisam ser avaliadas. Ao término da SAP-LUW, a task de update remove os locks postados pelos dialog steps anteriores. Caso ocorram erros durante o update os locks também serão removidos. Updates pendentes com erro podem ser restartados pelo administrador do sistema. A SAP não recomenda que updates V1 sejam restartados, devendo este procedimento somente ser efetuado para updates dos tipo V2. Processos V1 deverão ser regerados processando novamente a transação (veja a nota 16083) Quando um sistema R/3 sai, as entradas que estão com status INIT na VBLOG são processadas tão logo o sistema retorne ao ar. Esta funcionalidade pode ser parametrizada pela profile do sistema. Resumindo uma SAP-LUW, onde cada tópico é um dialog step : usuário abre uma transação para atualizar uma determinada informação; Na prática o SAPGUI do usuário entra em contato com o dispatcher da instância em questão e aciona o PAI da janela corrente e providencia a exibição da janela desejada; • usuário preenche os dados chave para a identificação da informação e o PAI é novamente acionado. Neste momento o work process selecionado pelo dispatcher para tratar deste dialog • João Luiz Barbosa Junho/2000 Página 22 ACADEMIA • BASIS CEMIG step localiza a informação desejada através do DB Interface e solicita ao Enqueue que a respectiva informação seja locada. Isto é feito pela função call function enqueue e pela inclusão da lock table que fica na memória da onde esta sendo executado o enqueue. usuário, de posse da janela com os dados a serem atualizados, atualiza a informação e inicia um novo dialog step. Este é o dialog step da nossa transação. Ele vai chamar a função call function in update task que incluirá as informações 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 não está terminado pois o work process de update, a partir da tabela vblog, vai providenciar que a atualização seja feita nas tabelas que possuem as informações reais e desfazer o lock através da call function dequeue. Esta parte da transação, que é feita pelo update work process é conhecida como a segunda parte da SAP-LUW. Background Processing Processos que são schedulados para processamento pelos background work processes são tratados no sistema da mesma forma que os processos online. Processos background são schedulados na forma de jobs. Cada job possui um ou mais steps (que podem ser external ou ABAP programs) que são processados seqüêncialmente. Através das classes de processamento (A, B ou C) é possível setar prioridades entre os jobs. Os jobs batch normalmente não são schedulados para processamento imediato, mas são especificados para uma data/hora futura podendo ainda, quando necessário, serem definidos como periódicos. O batch scheduler é o responsável pelo disparo automático dos jobs configurados no sistema. Este módulo é um programa ABAP que roda em um dialog work process por instância 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 disponíveis (do tipo B). Jobs batch podem ainda ser schedulados para processamento em servers específicos. Na escala de prioridade, para os jobs com mesmo horário 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 especificação explícita de server (sem balanceamento). A partir daí a ordem de inicialização é definida pela ordem de criação do job. Se for necessário saber a ordem em que os jobs serão executados basta abrir a SM37, listar os jobs e classifica-los pela ordem cronologica. Se houver alguns jobs no mesmo horário devemos entrar em um a um para ver a data de criação e descobrir qual a ordem exata de execução. Se for necessário bloquear a execução de jobs, basta setar o parâmetro rdisp/btctime = 0 R/3 Printer Services Spooling é a transferência bufferizada de dados para dispositivos de saída do tipo printers, fax, etc. O R/3 suporta spooling para dispositivos locais ou em rede. As requisições de spool são 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 impressão, é gerado um output request que é encaminhado para um spool work process. Uma vez formatado o dado para impressão, a requisição de impressão é encaminhada para o spool do sistema operacional, que fica responsável pelo encaminhamento do output request para o dispositivo de saída. R/3 Instance Uma instância R/3 é uma unidade administrativa que combina componentes de um sistema R/3 para prover um ou mais serviços. Todos os serviços providos por uma instância são iniciados (start da instância) e parados (stop da instância) ao mesmo tempo. Uma instância é parametrizada através de parâmetros que descrevem todas as suas características. João Luiz Barbosa Junho/2000 Página 23 ACADEMIA BASIS CEMIG Cada instância possui seus próprios buffers e um sistema R/3 central é composto de uma única instância que possui todos os serviços (DVEBMSGnn). O message server é o responsável pela comunicação entre os application servers e um central message service para prover serviços de update trigger, enqueue e dequeue, background requests, e outras pequenas trocas de informações (normalmente dados de controle e pequenas quantidades de dados da camada de aplicação) 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, também conhecida como request queue. Além dos dispatcher, os presentation (SAPGUI) poderão se logar nos application server através do message server para desta forma efetuar balancemento automático de carga (load balancing). O gateway é o responsável pela troca de dados (normalmente com bom volume de dados) entre as instâncias de um sistema R/3, entre sistemas R/3 e entre um sistema R/3 e outros sistemas São as profiles que configuram as diversas instâncias e desta forma definem quem executa quais serviços que estarão disponíveis. Por nomeclatura costumamos chamar os dialogs, background, enqueue, update e spool de work process e o gateway e message de serviços. João Luiz Barbosa Junho/2000 Página 24 ACADEMIA BASIS CEMIG Interfaces R/3 as an Open System R/3 é um sistema aberto que permite a comunicação com várias outras plataformas, quer seja entre as instâncias de um sistema R/3 ou com outros sistemas R/3, R/2 ou sistemas não SAP através de rede. A Comunicação 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 programação, desenvolver uma comunicação entre sistemas é mais fácil a medida que esta conversa é implementada nas camadas mais superiores. A SAP suporta os protocolos TCP/IP e SNA LU6.2. A comunicação entre sistemas R/3 se dá em TCP/IP e a comunicação LU6.2 é utilizada para a comunicação com sistemas R/2 baseados em mainframe. A programação R/3 suporta ainda CPI-C, RFC e OLE Automation como interfaces de comunicação. Os dois primeiros protocolos são proprietários da SAP e o OLE é um protocolo da Microsoft para a comunicação entre aplicativos na plataforma windows R/3 Gateway Service SAP Gateway é o CPI-C handler, responsável pela conexão entre os protocolos TCP/IP e LU6.2, utilizado para a conexão 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 através do message server. Já os volumes mais elevados de dados, tais como os dados da aplicação fluem através do gateway. Com isto podemos ver que a comunicação através 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, através de RFC, para comunicação com os clients e LU6.2 apenas para a comunicação com mainframes. Communication with CPI-C CPI-C é um protocolo utilizado para a comunicação elementar program-to-program. É utilizada basicamente para a comunicação entre sistemas R/2 e outros aplicativos mainframe. É a implementação SAP da LU6.2. A comunicação faz uso dos verbos básicos da comunicação LU6.2 (INIT, ALLOCATE, ACCEPT, SEND, RECEIVE e DEALLOCATE). Como no padrão IBM, é um protocolo de comunicação 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 conexão com ambiente IBM será necessário usar funções feitas pela SAP para converter o conjunto de caracter de ascii para ebcdic. Os parâmetros enviados pelo comando INIT são definidos através da tabela TXCOM e mantidos pela transação SM54. Remote Function Call RFC é uma interface de comunicação baseada em CPI-C mas que possui mais funções além de ser mais simples de se utilizar. Pode ser utilizada para a comunicação entre sistemas R/3, R/3 com R/2 bem como aplicações externas. O RFC permite a chamada de subrotinas remotamente pela rede. Estas subrotinas são chamadas de function modules. Estas funções possuem parâmetros e retornam valores como qualquer outra função e são gerenciadas dentro do R/3 através de sua própria function library, denominada Function Builder. João Luiz Barbosa Junho/2000 Página 25 ACADEMIA BASIS CEMIG Function Builder (transação 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 necessário para a comunicação RFC entre os sistemas. Os requerimentos para o RFC são os mesmos para o CPI-C. Os parâmetros para a comunicação RFC são mantidos través da transação SM59. O R/3 vem ainda acompanhado de uma biblioteca de funções C para comunicação 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 parâmetro (destination) que especifica onde o comando será executado Existem três tipos de chamadas RFC : • Synchronous RFC call, onde o programa que emitiu a chamada suspende a execução até o retorno da chamada • Asynchronous RFC call, onde a função chamada roda em paralelo e independente do programa que emitiu o comando. O programador fica responsável pela conexão lógica dos resultados obtidos • Transactional RFC call, onde várias funções são agrupadas em uma única transação que é executada no sistema remoto como uma única LUW na seqüência com que elas foram codificadas. Caso ocorra um erro, o sistema que emitiu o comando recebe um código de retorno que pode ser consultado pela transação SM58. Ainda neste caso o sistema destino não precisa estar disponível 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 comunicação em alto nível no sistema R/3, tornando possível por exemplo implementações R/3 na internet e tem as seguintes características: • Formam a base para uma bem sucedida comunicação em sistemas client/servers • São orientados ao negócio. Existem BAPIs chamados Customer, Order, etc. • Possui métodos, que são os business functions que facilitam e padronizam a utilização destes objetos • São gerenciados internamente pelo R/3 em uma biblioteca central, a Business Object Repository, ou BOR As BAPIs (Business Application Programming Interfaces) são interfaces funcionais que utilizam business methods para executar funções de negócio. Elas podem ser chamadas tanto pelos programas R/3 quanto encapsuladas e instânciadas por programas externos. R/3 System as an OLE Server or an OLE Client OLE (Object Linking and Embedding) é uma forma de comunicação entre programas orientada para objeto. Com isto é possível conectar aplicações desktop que utilizam OLE2 (Word, Excell, etc.) com o sistema R/3. Quando o sistema R/3 está agindo como um client OLE, o usuário chama o programa (word, excell) de dentro do programa ABAP. Os comandos OLE são transferidos para o PC através de chamadas RFC. Os objetos OLE aos quais o R/3 pode se conectar como client são definidos internamente no R/3 (através de type informations) onde se definem os métodos, atributos e parâmetros do objeto. A linguagem ABAP possui comandos próprios (CREATE OBJECT, CALL METHOD, GET/SET PROPERTY e FREE OBJECT) que permitem instânciar e manipular o objeto. Quando o R/3 funciona como um OLE server, suas funções podem ser chamadas de dentro das aplicações que rodam no desktop. Estas chamadas são enviadas ao SAP Automation Server que converte os calls para RFCs que são enviados ao sistema R/3. Estas chamadas ativam BAPIs ou function modules dentro do sistema R/3 que processam as informações que são então enviadas de volta para o Automation Server que a repassa para o aplicativo no desktop. Do ponto de vista da programação, usuários podem utilizar as function modules do R/3 em uma programação orientada para objeto, como por exemplo utilizando C++ ou Visual Basic. Isto é válido João Luiz Barbosa Junho/2000 Página 26 ACADEMIA BASIS CEMIG para todos os objetos que são gerenciados centralizadamente pelo R/3 através da BOR (Business Object Repository). Como os BOR e function modules se encontram no R/3, para utiliza-los é necessário 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 usuário 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 através do W Gate para o HTTP server, onde são finalmente exibidos para o usuário através dos browsers padrão (explorer ou netscape). A SAP fornece o IAC (Internet Application Component) que possui Web Transactions que nada mais são que mapeamentos Web de transações standard R/3. Assim como qualquer página HTML, o usuário pode customizar o lay out de acordo com suas necessidades. Para permitir uma boa performance a SAP está rescrevendo algumas transações para que essas funcionem de forma integrada com a internet. EDI Architecture Electronic Data Interchange é uma forma estruturada e eletrônica para trocar informações entre diversos sistemas. Esta arquitetura tem as seguintes características: • EDI-enabled applications, que permite que transações de negócio sejam processadas automaticamente • A interface IDOC, que foi criada como uma interface aberta e consiste de documentos intermediários e seus respectivos function modules • subsystem EDI, que converte os documentos intermediários em mensagens EDI e vice versa. O SAP não 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 razões técnicas ou de negócio pode ser necessário fazer uma implementação descentralizada do R/3. O conceito ALE (Application Link Enabling) permite configurar e operar aplicações distribuídas em SAP. ALE consiste de uma troca controlada de mensagens de negócio, mais especificamente os dados do negócio, que permitem a integração consistente de sistemas distribuídos. Os aplicativos são integrados através de comunicações tanto síncronas quanto assíncronas e por TRFC (transactional RFC). Para especificar um sistema distribuído é necessário especificar o modelo lógico de distribuição de dados para definir em que sistema rodará e ainda entre quais e como os dados deverão ser intercambiados. Os dados também são transferidos através de Idocs (Intermediate Documents) para possíveis aplicações 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 transações conversacionais utilizadas pelos usuários para entrar com os dados no sistema, fica assegurado que os dados passarão pelas mesmas consistências que se efetuam nas entradas online de informação. O método comumente utilizado para entrada de dados do legado é conhecido como batch input. A SAP provê uma série de métodos implementados através de técnicas de batch input para a João Luiz Barbosa Junho/2000 Página 27 ACADEMIA BASIS CEMIG transferência de dados do legado. Estes métodos standard são controlados através do Data Transfer Workbench (transação SXDA). Caso não existam SAP standard disponível, é possível definir e criar seus próprios métodos. O método consiste na bufferização das operações 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 são transferidos para a base de dados. O método funciona como uma screencam mergeado com um pacote de dados onde cada registro é submetido ao screencam simulando um usuário processando a transação. Um outro método para entrada de dados é o CALL TRANSACTION que força a chamada de uma transação para processar os dados armazenados na BDC table. Tanto o batch input quanto o método de call transaction chamam os mesmos programas que são processados em dialog mode pelos usuários, o que garante desta forma que as mesmas consistencias sejam efetuadas sobre a massa de dados. Outra forma de atualização é o Direct Input, onde os dados são lidos diretamente do arquivo de entrada, consistidos e transferidos para a base de dados sem passar pelas funções de aplicação normais. Dado a natureza atípica desta operação, ela é efetuada apenas por algumas poucas funções R/3 e reservadas apenas para programas desenvolvidos pela própria SAP. Devemos sempre ter em mente que a principal diferença entre o batch input e o call transaction é a existencia de um arquivo intermediário (conhecido como sessão) 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. Não vem ao caso para a academia, mas uma outra boa forma de fazer a integração de dados do legado para o R/3 é a LSMW ou DLSM que agiliza na geração das pastas de BDC e na eliminação da necessidade de codificação abap. João Luiz Barbosa Junho/2000 Página 28 ACADEMIA BASIS CEMIG R/3 Graphical User Interface Frontend Administration Usuários não necessitam da mesma configuração em seus PCs, embora uma padronização da workstation simplifica o trabalho de administração. Considere a facilidade e a dificuldade para atualizar os softwares da estação Frontend Requirements: A nota 86895 descreve detalhadamente a configuração da estação Configuração para Windows 95 Item Configuração Mínima Processador 486 RAM 16MB Net connection Winsocket API Configuração desejável Pentium 133 32MB Winsock.dll Configuração para Windows NT Item Configuração Mínima Processador Pentium 90 RAM 32MB Net connection TCP/IP Configuração desejável Pentium 133 48MB TCP/IP Para testar o funcionamento da rede entre a estação e o host basta efetuar um ping ou telnet. As configurações no windows ficam nos arquivos host e services. 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 versão do SAPGUI é necessário deletar a versão anterior. O programa sappurge.exe pode ser utilizado para esta finalidade. A instalação é feita individualmente em cada PC. Programe a melhor forma para otimizar o trabalho. O arquivo SAPSETUP.INI pode ser editado para parametrizar a instalação. Nele se configura quais os componentes a serem instalados e os diretórios target e de work. O sapsetup.exe permite uma instalação dialog free startada a partir da linha de comando (veja o R/3 Installation Guide) o que assegura uma distribuição automática do software e a manutenção do frontend utilizando logon scripts. A vantagem neste tipo de instalação é que a configuração das estações é feita a partir de uma localização central através de um logon script, que faz todas as checagens necessárias (hardware e network) e executa as operações necessárias para instalar e manter o frontend. A desvantagem deste método é que se tem mais trabalho para implementar o check de versão no logon script e para analisar os resultados da instalação no arquivo sapsetup.log. A SAP recomenda que sob windows 95 e NT primeiro se faça uma instalação em um servidor (installation server) utilizando o installation wizard e posteriormente se instale os clients a partir dele. O programa utilizado na instalação é o \Gui\Windows\Win32\Sapsetup.exe Types of Online Help Existem diversos tipos de implementação do online help no R/3: • PlainHtmlHelp converte documentos para HTML standard. Pode ser instalado em todas as plataformas de frontends e é exibida através dos browsers convencionais. Pode ser utilizado tanto com Windows 95, NT ou ainda quando um Web server é disponível na instalação (intranet) • PlainHtmlFile converte documentos para HTML standard. Pode ser instalado em todas as plataformas de frontends e os documentos são acessados através de um file server que João Luiz Barbosa Junho/2000 Página 29 ACADEMIA • BASIS CEMIG disponibiliza os dados de um diretório por compartilhamento onde são exibidos através dos browsers convencionais nas estações. Pode ser utilizado tanto com Windows 95, NT ou ainda quando um Web server é disponível na instalação (intranet) HtmlHelpFile converte documentos armazenados no formato HTML comprimido para Html convencional. Pode ser utilizado apenas em estações Windows 95 ou NT. É instalado em um file server compartilhado, como o anterior, mas sua principal vantagem é que o espaço necessário 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 estação antes da instalação do SAPGUI, já que é o browser que contém todos os HTML controls necessários. O tipo de help e sua localização são especificados como parâmetros nas profiles do R/3. A configuração do arquivo SAPDOCCD.INI no frontend sobrepõe a definição genérica das profiles do R/3 e deve ser utilizada como complementação a definição do sistema central. Os parâmetros importantes e relevantes para a configuração do help são 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 diretório drive:\<target>\sapgui, conforme foi definido no momento da instalação. O saplogon utiliza o programa sapgui.exe para se conectar com o application server. O arquivo saplogon.ini configura as entradas disponíveis na janela do saplogon e é mantido quando se atualiza as entradas disponíveis do usuário. As informações lá contidas são utilizadas para montar o string de conexão ao application server. Para evitar que o usuário edite as entradas deste arquivo é preciso defini-lo como readonly. Ao se clicar no canto esquerdo da janela do saplogon é possível obter informações about que descrevem a localização dos dois arquivos (sapgui.exe e saplogon.ini). O botão do canto superior esquerdo da janela permite ainda que se configure as opções de trace do saplogon e as funcionalidades de edição. Estas definições ficam armazenadas na seção [Configuration] do saplogon.ini Assim como o saplogon.ini, os arquivos sapmsg.ini e saproute.ini são mantidos implicitamente quando edita as entradas do saplogon. O primeiro contém a relação dos message servers e seus respectivos serviços (logical service names) que será lido sempre que se efetua uma requisição de logon a um logon group através do saplogon. O segundo arquivo (saproute.msg) lista os saprouters que podem ser selecionados no saplogon. Já o arquivo services do windows não é editado pelo saplogon embora possua entradas fundamentais para o seu funcionamento, devendo portanto ser editado em separado. Nele são 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 conexão depende do target escolhido: • Para conexão com uma instância R/3: sapgui /H/<appserver>/S/32nn • Para conexão com um message server: sapgui /M/<host name>/S/36nn/G/<logon group> • Para conexão saprouter: sapgui /H/<host1>/S/3299/H/<host2>/S/3299/H/<oss host>/S/36nn/G/Public Os números dos serviços poderão ser substituídos 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) são as 3300. Se for necessário, o log de start do sapgui pode ser ativado. Ele recebera o nome dev_9999.TDW (ascii) e dev_9999.log (binário) e serão gravados na area de work do sapgui. Eles possuem a log de tudo que aconteceu. Resumindo os arquivos ini. O saplogin.ini possui a configuração das instâncias e seus respectivos system numbers. No sapmsg.ini teremos a indicação de quais são 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 João Luiz Barbosa Junho/2000 Página 30 ACADEMIA BASIS CEMIG as portas que serão utilizadas pelo dispatcher, gateway, message e etc. Devemos sempre tomar cuidado ao alterar o service pois ele não segue um padrão entre maquinas diferentes e principalmente com usos diferentes. Em relação a localização dos arquivos, os sap*.ini estão no diretório do windows e o service ou está no diretório do win9x ou no system32/drivers/etc do winnt. SAP MAPI and SAPGUI for java O SAP MAPI permite a integração 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 evolução da SAP é a disponibilizarão do sapgui na linguagem java. Isto, pelo menos a princípio, facilitaria a distribuição de softwares para as estações 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 ativação de um sapgui java devemos lembrar que até o aparecimento da janela para o usuário houveram três momentos : • identificação do template (ides.html) que identifica o servidor a ser acessado; • carga das classes java que serão processadas no lado do cliente; • troca de mensagens entre os servidores para a montagem da página através do orbixd (object requeste broker daemon). Se for necessário saber mais sobre o assunto, procure pela nota 42268 () João Luiz Barbosa Junho/2000 Página 31 ACADEMIA BASIS CEMIG SAP Online Service System (OSS) OSS Overview OSS é um serviço 24 x 7 disponibilizado pela SAP que permite acesso ao banco de dados de Notas, que provêm soluções para problemas no sistema R/3. Através do OSS os clientes abrem chamados ao suporte relatando problemas que são analisados pela equipe da SAP. Atualmente a SAP está migrando estes serviços para a internet. Isto faz parte da nova estratégia mysap.com. Aparentemente todo o OSS será disponibilizado no site http:/service.sap.com que faz parte do market place. OSS Functionality A tela de pesquisa permite entrar com palavras chave relacionadas ao problema e incluir filtros na pesquisa, tais como release, database, versão de Hot Package, etc. Ao abrir chamados, o OSS já configurado com dados gerais da sua instalação requisita informações sobre área do problema, transação, descrição do problema e severidade. O SSCR é uma funcionalidade do OSS que permite ao cliente obter key para desenvolvedores e para os objetos SAP que irão 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 disponíveis bem como as datas dos treinamentos oferecidos pela SAP. OSS Access O acesso ao OSS é efetuado através da transação OSS1, que abre uma nova conexão SAPGUI no frontend do usuário. O acesso ao OSS é preciso ser configurado através de um SAPRouter gateway que abre uma conexão segura entre a instalação do cliente e a rede mundial da SAP através dos roteadores que ligam as duas redes. O saprouter também controla e filtra quem pode e quem não pode acessar a partir de cada um dos lados envolvidos na conexão. SAPNet A SAPNet é uma ferramenta que provê informações e serviços via internet. O acesso a SAPNet é feito através da área CUSTOMER PARTNER da página pública da SAP (WWW.SAP-AG.DE). Dentro da SAPNet existem áreas de Assistência, Informação, Comunicação e Serviços. Cada dia mais esta ferramenta está se aproximando do OSS e hoje em dia já dispomos da maioria dos recursos via browser. Além disto dispomos de mecanismos para perquisar em todo o site da SAP incluindo ai muitos documentos não disponíveis no OSS. Outro bom recursos já disponível é o download de hot packages e legal changes patches além dos patches de kernel (executáveis 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 indicação 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 técnico, acessada através de endereço www.sap.com/technet ou através da área de communication da SAPNet. Os assuntos na SAP TechNet estão divididos por áreas de interesse e podem ser navegados para encontrar uma grande diversidade de documentos e pdfs. Para facilitar a organização a maior parte dos documentos estão na knowledge base e ainda existe uma área conhecida como forum com um conjunto de perguntas feitas por outros clientes. João Luiz Barbosa Junho/2000 Página 32 ACADEMIA BASIS CEMIG Starting and Stoping R/3 – NT Version Operating System Tasks Durante o startup do NT todos os serviços relacionados poderão ser inicializados automaticamente (desde que configurados através do control panel -> services). Em relação ao R/3 neste momento temos que ter em mente que os serviços SAP<SID>_<SystemNumber>, SAPOSCOL e OracleService<SID> devem ser inicializado. A seqüência de inicialização não é relevante pois um não depende do outro, mas para o start do R/3 todos já devem estar ativos. O SAP<SID>_<SystemNumber> é o responsável por coordenar o start/stop do message e do gateway. O usuário utilizado para inicializar o serviço é o SAPService<SID> com a senha informada durante a instalação do R/3. O SAPOSCOL é o responsável por coletar as informações sobre os recursos do sistema operacional e suas respectivas cargas e disponibilizar estas informações para o R/3. O usuário utilizado para inicialização também é o SAPService<SID>. O OracleService<SID> é responsável pelo controle da instância oracle e não necessita de usuário para ser inicializado. Administrator Tasks Para inicializar o R/3 devemos sempre seguir a seguinte seqüência : • Os serviços básicos devem estar ativos (saposcol, sapSID_## e OracleServiceSAP) • Abrir a conta SIDadm na console do NT • Ativar a instância do Oracle (pode ser feito pelo instance manager da oracle) • Ativar a instância do R/3 (pode ser feito através do sap service manager) O Sap Service Manager usa as cores para indicar a fase em que está cada serviço, a saber : verde (processo sendo executado), vermelho (processo terminado anormalmente), amarelo (processo sendo inicializado) e branco (serviço não está ativo ou com situação desconhecida) Process Startup Sequence Seqüência básica do start do SAP Service Manager : • Na camada de serviços • Verifica se os serviços básicos estão 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 necessário executa o script strdbs.cmd de inicialização do banco de dados • Verifica e se necessário executa o script msg_server.exe que coloca no ar o message • Verifica e se necessário executa o script disp+work que coloca no ar o dispatcher • Na camada de processos • Com as informações da default profile e a instance profile o dispatcher (disp+work) inicializa o R/3 criando os work process necessários e o serviço de gateway As profiles estão no compartilhamento \\<sapGlobalHost>\sapmnt\<SID>\SYS\profile conhecido também como \usr\sap\SID\SYS\profile (se ignorarmos o disco onde está a instalação). 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 necessário iniciar a instância através da linha de comando utilize o comando startsap que também possui seu inverso, o stopsap. João Luiz Barbosa Junho/2000 Página 33 ACADEMIA BASIS CEMIG Parameter Read Sequence A seqüência para a leitura dos parâmetros é 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 parâmetro utilize o relatório RSPFPAR. Resumindo, o SAP service lê as variáveis 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 parâmetro 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, além 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 também é conhecido como oracle trace information. Em relação ao sapdba, as logs ficam nos diretórios sapcheck, sapreorg e sapbackup. Startup logs and traces in Windows NT Todas as mensagens geradas pelos serviços, SAP server manager ou outra aplicação do NT são logadas no Event Viewer (utilizar o caminho Menu iniciar, programas, aplicação administrative tools (common), event viewer – eventvwr) nas logs de sistema, de aplicação e de segurança. Startup logs and traces in R/3 O diretório de work contém todos os arquivos de trace e de mensagens de erros da instância R/3.. Os arquivos são: • Arquivos de erros gravados pelo executável sapntstartb.exe que é acionado pelo SAP service manager ou pelo startsap : • Stderr1 contém as logs do banco de dados • Stderr2 contém as logs do message server • Stderr3 contém as logs do dispatcher • Sapstart.trc contém o trace do programa sapntstartb. Vale lembrar que o nível do trace a ser logado pode ser alterado pelo parâmetro rdisp/trace e este varia de 0 (no trace) até 3 (todas as mensagens e trace completo) • Arquivos de trace : • Sapstart.log contém, de forma um pouco menos detalhada, a toda a log da inicialização • Dev_ms contém o trace do message server • Dev_disp contém o trace do dispatcher • Dev_w0 … n contém o trace de um work process especifico Uma boa transação para ver as logs é a transação RZ03 e menu utility. Outra boa transação para ver mensagens de log é a SM21, mas esta mostra as mensagens de log de R/3. Startup Diagnostics As principais razões de falha durante o processo de inicialização são : • SAP Service Manager não consegue conectar com o SAP service. Normalmente ou ele não está ativo ou não esta configurado corretamente. João Luiz Barbosa Junho/2000 Página 34 ACADEMIA • • • BASIS CEMIG SAP service não inicia. Ou as entradas no NT register estão erradas, ou tem algum problema de configuração ou a senha está errada Database não inicia. Verifique as variáveis de ambiente, se o db está em dba mode, se algum arquivo foi perdido ou corrompido ou se o listener está desativado R/3 não inicia. Pode ser os compartilhamentos de disco, a configuração do serviço (por exemplo, usuário errado ou sem autorização), problemas de permissão nos arquivos, erro de tcp (host, services, dns, etc) ou erro na conexão com o database. Reasons for R/3 Downtime Eventualmente podemos parar o sistema para alterar a configuração e parametrização, para manutenção 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 não podem estar próximos de disparar jobs no R/3, via sapevt ou rfc • Nenhuma atualização está em andamento. Para isso use a SM13; • Nenhum usuário está trabalhando no sistema. Para isso use a SM04; • Não existe atividade para o gateway. Para isso use a SMGW. É bastante conveniente enviar mensagem para os usuários do que será feito. Para isso use a SM02. Stopping the R/3 system Para parar uma instância R/3 podemos faze-lo através do CCMS (que na verdade é a transação SRZL) ou pelo SAP Service Manager (neste caso ele manda uma mensagem pelo named pipe para a instância). A grande diferença do NT para o Unix é que o stopsap não para o banco de dados, ou seja, a pesar do startsap inicializar o banco de dados o stopsap não 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 paralisação do R/3 e do oracle, o oracle não consegue parar. Isto pode ocorrer por que o banco de dados ainda está trabalhando na realização 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 solução para o problema é o aumento desta área. Backup off-line: database reconnect Quando do backup off-line o R/3 pode ser configurado para não ser paralisado junto com o banco de dados. Isto é feito através dos parâmetros rsdb/reco_trials e rsdb/reco_sleep_time que configuram a quantidade de tentativas de recuperar a conexão e o tempo de espera por esta conexão. Com isto conseguimos que os buffers sejam preservados e as aplicações que estavam sendo executadas naquele momento não são abortadas. Na prática esta política está associada a backups com recursos de split mirrow de discos que contém os arquivos de dados do oracle. João Luiz Barbosa Junho/2000 Página 35 ACADEMIA BASIS CEMIG Starting and Stoping R/3 – Unix Version Operating System Tasks O usuário <sid>adm é utilizado para administração do sistema R/3. O start do R/3 é efetuado através do script startsap_<host>_<instance nbr>, que fica no diretório home do usuário. Este script tem um alias: startsap. O startsap verifica se o processo saposcol está rodando e o ativa, se necessário. O scipt pode ainda chamar o script startdb caso o banco se encontre em shut down. Em seguida o script starta a instância R/3. O script aceita 3 tipos de parâmetros: • startsap R3, ativa apenas a instância R/3, desde que o banco esteja rodando • startsap DB, ativa apenas o banco de dados • startsap all, ativa o banco e a instância (é o default quando nenhum parâmetro é especificado Um sistema R/3 possui basicamente 3 profiles que se encontram no diretório /usr/sap/<SID>/SYS/profile: • Start profile: START_<instance>_<host>, que contém a relação dos componentes que serão ativados pelo sapstart na instância • Default profile: DEFAULT.PFL, que contém alguns parâmetros globais do sistema • Instance profile: <SID>_<instance>_<host>, que contém parâmetros específicos da instância Ao ativar o script startsap_<host>_<nn>, o seguinte processo é executado para levantar uma instância R/3: • Ativa o programa sapstart • sapstart lê a start profile para ativar os serviços disponíveis na instância • 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 serão ativados. Os processos sender e collector são 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 são criados de acordo com as informações da instance e da default profile. O gateway reader independe de parâmetros 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 diretório de work um arquivo kill.sap que contém o comando kill –2 <sapstart process nbr>, que será executado pelo script de stop da instância. Para garantir um start consistente, a seqüência dos parâmetros lidos pelos work processes seguem um padrão definido, conhecido como parameter replace sequence: • São lidos os parâmetros hard coded nos fontes C do kernel • Parâmetros contidos na default profile sobrescrevem valores ja lidos no step anterior • Parâmetros da instance profile sobrescrevem os anteriores • kernel do R/3 (disp+work) lê os parâmetros contidos nas default e instance profiles. Desta forma, alterações nelas executadas somente terão validade no próximo 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) são logados pelo no Oracle alert file: /oracle/<SID>/saptrace/background/alert_<SID>_.log. Informações detalhadas de erro são 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 diretório /oracle/<SID>/sapreorg, .../sapcheck, .../sapbackup, dependendo da ação que foi executada R/3 Startup and Logs O script startsap grava uma log de start no diretório home do usuário <sid>adm. O diretório de work contém trace files e error files de mensagens relacionadas com o start dos work processes e João Luiz Barbosa Junho/2000 Página 36 ACADEMIA BASIS CEMIG demais serviços. O nível de informações gravadas nos trace files é definido pelo parâmetro 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 instância R/3 Stopping R/3 Systems As razões para se parar uma instância R/3 vão desde paradas planejadas (mudança na profile, manutenção do sistema R/3 ou DB, upgrades) até quedas não planejadas, por exemplo por falha de hardware. Antes de parar um sistema R/3 convém 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 usuários (SM02) • Verifique os usuários 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 parâmetros 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 conexão com o Oracle. Estes processos tentarão uma reconexão (parametrizada por profile) e em caso de insucesso, entrarão em modo de reconnect e somente tentarão nova conexão sob demanda. O processo de retirar apenas o database poderá ser uma opção para efetuar o backup offline do banco de dados preservando porém os buffers da instância R/3 intactos durante o processo. Erros durante a tentativa de parada do database poderão 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 não possa ser identificada facilmente, utilize a SM21 para tentar identificar possíveis mensagens. De qualquer forma, elimine a causa antes de fazer novas tentativas de shutdown. João Luiz Barbosa Junho/2000 Página 37 ACADEMIA BASIS CEMIG CCMS Configuration Overview O Computing Center Management System, conhecido como CCMS e acionado pela transação SRZL, é a ferramenta que prove o gerenciamento de : • Performance, monitoração e análise do R/3, sistema operacional e rede • Profiles, modos de operação e logon groups • Start/stop dos ambientes • Banco de dados e do archiving do banco de dados; • Carga de trabalho (workload) • Impressões • Segurança de acesso Antes de utilizá-lo, em toda sua potencialidade, ele deve ser configurado. Para isto os principais passos são : • Importar as profiles e adequá-las ao ambiente disponível para processamento • Definir os modos de operação do sistema. Normalmente definimos dois (diurno e noturno) para balancear e distribuir a carga segundo o perfil de utilização de cada horário • Criar as definições dos perfis das instâncias com os seus respectivos parâmetros de inicialização • Associar cada um destes perfis aos modos de operações • Definir a tabela de horários de entrada e saída de cada um destes perfis definidos no modo de operações RZ10: Profile Maintenance Esta é a ferramenta para manutenção das diversas profiles do R/3 (start, default e instance). Com ela podemos editar e manter todos os parâmetros. A manutenção pode ser feita de forma básica ou estendida, o que difere é se os parâmetros serão manipulados de forma individual ou de forma coletiva. A transação ainda permite deletar, comparar e verificar as profiles e suas diferentes versões. Lembrando, as profiles seguem o seguinte padrão de nome : • Start : START_DVEBMGS00_hostname • Default : DEFAULT.PFL • Instance : SID_DVEBMGS00_hostname Os passos para a manutenção inicial das profiles são : Importa-las a partir do sistema operacional; Mante-las utilizando a RZ10; salva-las e ativa-las. Tomar cuidado com o botão import pois ele importa apenas o servidor corrente. Para importar use o menu Utilities, Import profiles, of active servers. R/3 Profiles A incorreta configuração do CCMS não impede o funcionamento do R/3, porém impede que o CCMS exiba dados úteis. A transação RZ10 do CCMS permite que se dê manutenção nas profiles das instâncias do R/3. Ela mantém os parâmetros na base de dados do R/3 e a cada alteração efetuada uma nova versão é gerada nesta base de dados. Quando ativamos uma versão de profile através desta interface, seus parâmetros são copiados e transferidos para a profile ativa, que fica em diretório próprio do sistema operacional. Desta forma a base de dados do R/3 pode conter várias versões de uma mesma profile, um histórico das alterações além de documentação dos parâmetros. Em ambientes distribuídos com várias instâncias R/3, o diretório de profiles é compartilhado entre todas as instâncias e permanece como repositório central de todas as profiles. Para cada sistema R/3 existem várias profiles. Uma DEFAULT profile e, para cada instância do ambiente, uma instance e uma start profile. Através da ferramenta RZ10, existem dois modos de exibição/edição das profiles: João Luiz Barbosa Junho/2000 Página 38 ACADEMIA • • BASIS CEMIG Em basic mode, os parâmetros que são alterados mais freqüentemente são agrupados de acordo com suas interdependências de modo que a alteração em um deles se reflita automaticamente nos demais. Nesta interface basic os parâmetros aparecem sem os seus nomes técnicos, mas apenas como campos em screen. Em extended mode, os parâmetros aparecem e são editados em uma interface tipo editor de texto, onde cada parâmetro é listado com o seu nome técnico e respectivo valor. O administrador aqui deverá conhecer os seus nomes técnicos e é claro suas interdependências. O programa de instalação, R3SETUP, cria a primeira versão das profiles no sistema operacional de acordo com os recursos do sistema (memória e CPU). Durante o processo de configuração inicial do CCMS, importamos estas profiles para a base de dados R/3 utilizando a RZ10 e efetuamos as nossas customizações. Isto permite uma gerência centralizada de todas as profiles de um ambiente. As profiles utilizadas pelo R/3 para configuração da instância 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 manutenções sempre deverão se dar através desta interface nunca diretamente no sistema operacional para evitar que haja dessincronização das ferramentas. Qualquer dúvida quanto ao sincronismo poderá ser verificado através de seus mecanismos de check e da comparação de versões. Do ponto de vista do R/3, uma profile consiste de duas partes lógicas: entradas nas tabelas da base de dados do R/3 e um arquivo no sistema operacional. Como a versão utilizada pelo startup é a do OS (profile ativa), alterações efetuadas nos parâmetros deverão ser salvas no sistema operacional e somente terão efeito no próximo start da instância. Somente a versão mais recente de uma profile pode ser ativada pela ferramenta RZ10. Na prática isto significa que a tentativa de ativar uma versão mais antiga faz com que a profile seja copiada com uma nova versão e ativada. Qualquer manutenção vai sempre gerando novas versões na base de dados que ficam documentadas como comentários e headers no file do sistema operacional. Alterações em parâmetros de configuração de memória do R/3 poderão ser ativados sem a necessidade de stop/start através da opção de Dynamic Switching na RZ10. O procedimento de check de profiles oferece vários mecanismos de aferição de suas integridades: • Comparar a profile da base de dados com a profile ativa no sistema operacional • Verificar a sintaxe dos parâmetros codificados • Verificar se os valores especificados nos parâmetros são válidos ou ainda se não estão muito discrepantes (por exemplo 10 vezes maior que o default, etc.) • Efetuar comparações entre todas as profiles definidas para encontrar inconsistências de definição. Com isto é possível encontrar erros na definição de mais de um message server, por exemplo. • sistema efetua um check automático de consistência entre a profile ativa e a base de dados sempre que efetua um startup. Caso encontre alguma discrepância um alert é ativado no Alert Monitor Operation Modes Operation mode é uma facilidade do R/3 que permite que se configure diferentes combinações nos tipos de work processes que podem ser ativados ao longo do dia sem a necessidade de stop/start da instância. Isto permite que possamos ter por exemplo uma maior disponibilização de background work processes durante períodos de maior demanda desta funcionalidade, como períodos noturnos. Já os períodos diurnos são caracterizados por uma demanda muito maior de processamento dialog. Operation mode permite portanto maximizar a utilização dos recursos do sistema sem a necessidade de stop/start das instâncias para que as configurações tomem efeito. Uma configuração básica de operation mode especifica os serviços ou tipos dos work processes e os períodos escolhidos para cada intervalo. É através desta funcionalidade que conseguimos configurar background work processes para processamento exclusivo de jobs classe A. Operation mode pode ser configurado baseado em alguns conceitos básicos: • número total de work processes deve permanecer o mesmo entre os operation modes de uma instância, já que nenhum novo serviço será startado, apenas os processos terão suas funcionalidades reconfiguradas. João Luiz Barbosa Junho/2000 Página 39 ACADEMIA • • BASIS CEMIG Cada instância deverá permanecer com o requisito mínimo de dois dialog processes Cada sistema deverá permanecer com um processo de enqueue e pelo menos um update. A transação RZ10, através de seus mecanismos de check, oferece recursos para efetuar estas verificações das profiles e dos operation modes configurados. A mudança de configuração entre operation modes pode ocorrer manualmente sob demanda do administrador do sistema através da RZ04 ou então de forma automática através da definição de um schedule de horários chamado de timetable, que configura um ciclo completo de 24 horas. Este schedule de horários é mantido através da transação SM63. A timetable é única para todas as instâncias de um sistema. Isto significa que todas deverão possuir a mesma configuração de operation modes, porém cada uma poderá ter a sua configuração individual de work processes. Além da timetable normal que configura o ciclo de 24 horas do operation mode, é possível definir uma timetable excepcional para ser ativada em uma data específica. 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 período do dia. Nos demais períodos continuariam valendo as definições da timetable normal. Quando a mudança entre modos de operação ocorre, os work processes são distribuídos automaticamente, sem necessidade de parada e restart das instâncias. Nenhum tempo é perdido por indisponibilidade do sistema, apenas o tipo dos work processes é alterado, permanecendo porém o número total inalterado. É possível simular o switch de um operation mode em test mode e desta forma analisar possíveis falhas através da log de switch. Discrepâncias existentes na configuração das profiles ou na definição dos operation mode poderão ser identificadas e eliminadas. Starting and Stopping Instances with the CCMS Através do CCMS, transação RZ03, é possível startar e parar as instâncias R/3 de um sistema. A instância de banco de dados e pelo menos uma instância do ambiente precisam porém ter sido startadas através das ferramentas do sistema operacional. Em plataformas UNIX é utilizada a facilidade de rexec para esta operação remota. Já no NT esta facilidade (rexec) não é padrão e deve ser startada se precisarmos que uma instância NT manipule uma instância Unix. Além de permitir a parada de uma instância a RZ03 também permite o switch de operation mode manualmente. João Luiz Barbosa Junho/2000 Página 40 ACADEMIA BASIS CEMIG Background Processing Background Concepts and Features Um job background é um ou mais programas ABAB, external programs ou external commands que rodam seqüencialmente (steps) sem a intervenção do usuário, baseados em eventos (event-based) ou horários (time-based) pré estabelecidos. São utilizados principalmente para: • Processar automaticamente tarefas rotineiras • Processar informações vindas de sistemas legados • Processar tarefas baseado na ocorrência de determinados eventos • Processar uma carga em massa no ambiente em horários 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 execução. O sistema permite que se reserve work process livres para execução 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 serão eles. Os jobs são disparados através de um serviço, o batch scheduler, que roda no sistema R/3. Este serviço é um programa ABAP que roda em um dialog work process no servidor parametrizado nas profiles do ambiente através do parâmetro rdisp/bcttime. Neste parâmetro é 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 parâmetro, o rdisp/bctname, define o nome do server onde os events serão checados para o disparo de jobs através desta facilidade, os event-based jobs. A definição de quantos batch work process estarão disponíveis, sem levar em conta o modo de operação, está no parâmetro rdisp/wp_no_btc. Por definição um sistema R/3 deve ter pelo menos 2 batch work process, independente de qual instância eles vão estar, para atender o sistema de transporte. Se o sistema R/3 não for trabalhar com transportes não é necessário ter batch work process (mas isto é meio absurdo se pensarmos no dia-a-dia prático). O mecanismo do batch scheduler, após a ativação, segue o seguintes passos : • Verifica a job-scheduling table ordenado por data de start, classe, servidor de destino e data da criação do job; • Se o job for para ser executado na própria instância o dispatcher é acionado para alocar um BTC, se o job for para ser executado em qualquer instância o message é acionado para determinar qual é o servidor com menor carga. Operation Modes and Scheduling O sistema efetua balanceamento de carga automática entre os servidores, a menos que se especifique o server target do job. A especificação do server durante o schedule faz com que o job tenha prioridade sobre outros da mesma classe sem a especificação explícita do server. É possível configurar operation modes (através da transação RZ04) para efetuar um switch entre work processes de dialog e batch em horários pré determinados sem a necessidade de um stop/start do R/3 para reconfiguração dos work processes A gerência dos jobs é feita a partir do CCMS e os jobs são schedulados a partir da transação SM36. Ao efetuar o schedule do job é possível especificar o nome de quem irá receber o spool request (opção Spool list recipient) que tanto pode ser um usuário R/3 quanto um mail do SAPOffice ou mail externo. Os Programas ABAP que requerem um determinada entrada de dados para execução poderão ser schedulados em background bastando que se informe uma variant (lista de parâmetros) para processamento. Eventualmente o schedule pode ser acessado pela transação RZ01 que é um visualizador gráfico dos jobs que estão schedulados. Quando um job background executa comandos ou programas externos, o R/3 starta o programa server SAPXPG no host target através de chamadas RFC. Programas externos somente podem ser executados por usuários com autorização para background administrator. Comandos externos podem João Luiz Barbosa Junho/2000 Página 41 ACADEMIA BASIS CEMIG ser executados por usuários com autorizações R/3 apropriadas. Os programas externos somente rodam em modo síncrono e os comandos externos rodam tanto em modo síncrono quanto assíncrono, dependendo das necessidades do usuário. Os jobs podem ser schedulados para rodar de diferentes maneiras: • Imediatamente, • Com data e hora programada, • Após a ocorrência de um evento • Após a execução de um outro job • Em um modo de operação especifica • Com periodicidade, etc Events in Job Scheduling Os eventos com que os jobs poderão estar dependentes são eventos internos do R/3 (system start, opmode switch, etc) ou eventos definidos pelo usuário, como por exemplo o término de uma transferência de dados Através da transação SM62 podemos definir os user events e a transação 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 instância via tcp/ip para disparar o trigger no R/3. Internamente em um programa ABAP é possível ainda disparar um evento a partir da chamada a uma função, a BP_EVENT_RAISE. Da mesma forma que o R/3 utiliza o SAPXPG para startar programas no sistema operacional o SAPEVT também utiliza o SAPXPG para startar eventos no R/3. Com isto é possível 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 através da SM37. Estas alterações poderão ser desde a inclusão de novos steps quanto a alteração de seu scheduling. Uma alteração típica é a classe de submissão, por exemplo para alterar a fila de prioridades. Jobs que estão rodando ou que já foram processados não podem ser alterado. Os jobs que estão rodando podem ser capturados, ou seja, debugados e eventualmente cancelados. Os jobs que já terminaram, com erro ou não, podem ser copiados. Job Monitoring Através 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 execução. A Spool list exibe a saída da execução. A lista exibida na SM37 depende dos critérios marcados na tela inicial. É necessário uma especial atenção para a seleção dos jobs que não possuem uma data de start e para aqueles que dependem de algum evento (colocar * no evento e clicar nas opções de jobs sem data e com predecessores). Outro ponto a ser observado é a diferença entre um job released e um job ready. O released já pode ser rodado, em função da marcação do horário e das autorizações, mas não está na hora de ser executado. O ready já pode ser rodado mas ainda não foi atribuído para o work process que está disponível (provavelmente o dispatcher está muito ocupado). De qualquer forma o tempo na situação de ready é mínimo. João Luiz Barbosa Junho/2000 Página 42 ACADEMIA BASIS CEMIG Para ver os jobs existe também o Job Scheduling Monitor (RZ01) que exibe em modo gráfico o schedule nos vários servidores que compõem o sistema ao longo do tempo. Esta transação também pode ser ativada a partir do Control/Monitoring do CCMS. Job API, XBP-API and XMI-API Através de programas ABAP é possível gerenciar e schedular jobs utilizando o Job Application Programming Interface, ou Job API. Através do Job API é possível por exemplo rodar jobs seqüencialmente ou ainda incorporar lógica de decisão no ambiente de processamento ( O R/3 não consegue tratar schedule de jobs muito complexos. Um exemplo disto é um job que precisaria de dois predecessores). As funções ABAP para o Job API se encontram no ABAP workbench com o nome BP_*. O XMI ou External Monitoring Interface é um conjunto de módulos de funções 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 módulos possuem o nome comum SXMI_* e não 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 não R/3 através de uma única interface Authorization for Background Jobs A utilização do job scheduling exige perfis especiais de autorização para as funções de schedule e administração. Os objetos de autorização envolvidos são: • S_BTCH_ADM que dá as autorizações para as funções administrativas. O usuário com esta autorização com field setado para “Y” pode administrar jobs em todos os clients do sistema e não apenas do client onde ele está definido. • S_BTCH_NAM dá aos usuários a autorização necessária para executar jobs em background. • S_BTCH_JOB: este objeto possui funções que dão aos usuários diversas facilidades na administração de seus jobs e de outros usuários (DELE, LIST, PROT, RELE, PLAN e SHOW) • S_ADMI_FCD: funções 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 autorização envolvidos são: • S_RZL_ADM que através de seus activity codes dá autorização para administração do CCMS (01 equivale a all e 03 a display) • S_LOG_COM que possui fields que autorizam a execução de external commands • S_TCODE que dá autorização para as transações SM49 e SM69 Authorization for External Management Interfaces Os objetos de autorização envolvidos são: • S_XMI_PROD define através de seus fields quais interfaces XMI e quais ferramentas externas poderão ser utilizadas • S_XMI_LOG define se o usuário 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 não aparecer verifique os flags (aguardar o retorno) João Luiz Barbosa Junho/2000 Página 43 ACADEMIA BASIS CEMIG 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 necessárias dentro do ambiente R/3, seja na coleta e armazenamento de estatísticas ou na tarefa de housekeeping da instância, onde são normalmente schedulados como jobs periódicos • Application background jobs, que são os jobs disparados pelos usuários em suas tarefas funcionais dentro do sistema. Os jobs de housekeeping efetuam tarefas tais como limpeza do spool, jobs antigos, sessões de batch input já processadas, limpeza de estatísticas, etc. Alguns possuem características de serem client independentes, outros já precisam ser schedulados em todos os clients do sistema e outros ainda possuem a característica de que devem ser schedulados através de usuários específicos ou ainda com autorizações específicas. A nota 16083 define esta sistemática e descreve detalhadamente os jobs de housekeeping, inclusive quanto a periodicidade aconselhada. Os outros jobs que se enquadram na categoria dos jobs Basis são aqueles utilizados para coleta e organização de estatísticas de utilização do R/3. Nesta categoria, o SAP_COLLECTOR_FOR_PERFMONITOR (conhecido também como PERFORMANCE_MONITOR) executa de hora em hora o programa RSCOLL00 que, baseado em uma tabela (TCOLL) do sistema, dispara uma série de outros programas a cada execução para efetuar as mais diversas tarefas relacionadas ao recolhimento e consolidação de estatísticas. Os jobs que executam na categoria dos aplicativos efetuando tarefas funcionais dos módulos do R/3 necessitam de monitoração constante, já que muitas vezes manipulam grandes quantidades de dados e são elevados consumidores de recursos, podendo portanto interferir com a performance do sistema online. Os jobs de aplicação devem ter uma programação estudada e ser cuidadosamente parametrizados pelas variantes para não trabalhar volumes muito elevados de informação. Em um ambiente R/3 produtivo, deve-se inclusive montar uma planilha de execução para evitar gargalos de elevados volumes de processamento simultâneos. Para uma maior compreensão veja as notas 24092 (distribuição 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 são : • 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 estatísticas • RSM13002: elimina updates antigos e pendentes. Este job só deve ser agendado se alguns dos seguintes parâmetros 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 problemáticos e que não utilizam a facilidade de processamento paralelo através do uso de RFC assíncrono possam ser reanalisados para incorporar esta facilidade. Uma chamada do tipo Asynchronous RFC permite uma otimização no compartilhamento dos work processes por splitar o programa ABAP em várias partes menores que são disparadas paralelamente entre os vários dialog work process disponíveis que compõem um determinado grupo RFC, onde os resultados são coletados mais tarde. Esta técnica foi desenvolvida João Luiz Barbosa Junho/2000 Página 44 ACADEMIA BASIS CEMIG para suprir o problema de que longos background jobs não encontravam janela noturna suficiente ou ainda quando não se encontra background work process em número suficiente para processar os jobs. Esta sistemática exige alguns pré requisitos de ordem técnica e conceitual para que seja implementada corretamente. É preciso garantir que: • comando ABAP que dispara RFC assíncrono é o CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP. Outras técnicas de processamento RFC assíncrono podem levar a um impacto negativo na performance do sistema • Existam pelo menos três dialog work processes disponíveis além dos dois que são necessários para o processamento dos dialogs • job possa ser dividido em unidades lógicas independentes, uma vez que serão processadas paralelamente • A dispatcher queue deverá estar com menos de 10% ocupada para garantir que o critério de balanceamento da carga seja feito corretamente Este critério portanto não se adapta a programas que devem ser processados seqüencialmente onde as unidades lógicas dependem do resultado da anterior. Da mesma forma não existe uma garantia da seqüência com que as partes serão processadas individualmente. Os resultados de todas as partes separadas deverão ser coletadas, sincronizadas e analisadas no final. Para maiores detalhes veja as notas 66612 e 99284. Para ver quais são os servidores disponíveis no RFC group utilize a transação 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) Através da transação 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 administração e gerência do schedule de jobs no R/3 através de um ambiente externo ao sistema. Estes sistemas se comunicam com o R/3 efetuando um logon via RFC e posteriormente através 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 idôneo e confiável para possibilitar possíveis upgrades em novos releases do R/3. Do lado do R/3 podemos monitorar a utilização da interface XMI através da transação RZ15. Events in Job Scheduling Os eventos utilizados para disparar jobs no R/3 podem ser: • System events, que são definidos pela SAP e disparados a partir de determinadas ações definidas no ambiente, tais como um switch de operation mode • User events, que são definidas pelo próprio usuário através da transação SM62 para permitir uma administração mais personalizada de operação Os eventos podem possuir argumentos que serão verificados no momento do disparo e neste caso o job só será executado se o parâmetro 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 sincronização de tarefas. Um bom exemplo para este uso é o evento END_OF_DATA_TRANSFER que deve ser associado a uma parâmetro para disparar um job especifico. Com isto não é necessário especificar vários eventos para a mesma funcionalidade João Luiz Barbosa Junho/2000 Página 45 ACADEMIA BASIS CEMIG 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 período noturno. Jobs schedulados sem argumentos são disparados tanto quando o evento ocorre com argumento quanto sem argumentos. Os user events podem ser disparados por três formas distintas: manualmente através da transação SM64, dentro de um programa ABAP através de chamada própria de função (BP_EVENT_RAISE) ou ainda através 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 usuários que possuam autorização específica. A transação SM69 é utilizada para criar e dar manutenção em external comands, que posteriormente podem ser executados através da transação SM49 ou inseridos em steps dos background jobs. Através de chamadas de funções específicas também é possível executar external commands de dentro de programas ABAP. Além destas transações podemos utilizar também a AL11 para listar os comandos. External commands somente podem ser executados em modo síncrono e para garantir a correta execução dos programas e comandos, especifique sempre o seu path completo. Para rodar um external program os seguintes requisitos são necessários: • Gateway server do R/3 deverá estar ativo para estabelecer a comunicação entre o servidor host do processo e o target system, já que o processo é startado utilizando o CPI-C. Para ter certeza que não havera problema utilize o parâmetro gw/remsh como /bin/rsh para solaris e rsh para NT. • Se o comando/programa não se encontra no path do CPI-C user, o path completo deverá ser especificado, que é quem será utilizado para executar o comando. Normalmente este usuário é o <SID>adm • diretório de executáveis do R/3 (/usr/sap/SID/SYS/exe/run) deverá estar no path do CPI-C user, uma vez que o comando é executado através de um programa de controle do R/3 que gerencia o código de retorno do sistema operacional. Um external program pode apresentar problemas para ser utilizado, ou por não poder ser startado ou ainda por não conseguir retornar um resultado para o job background. Estes problemas deverão ser identificados e corrigidos através 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 através da execução do comando pela SM69 e pela especificação de uma variável de ambiente, a sapxpg_trace, no sistema target onde o comando irá rodar. O trace mais detalhado é obtido quando esta variável é setada com o valor 3 (levels 1, 2 e 3) que possui o maior nível de detalhe. Authorizations for Background É muito importante que o usuário tenha acesso restrito a utilização de jobs. Preferencialmente permita que os usuários 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 segurança e libere para o usuário a submisão, deleção, liberação, alteração 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 é possível além da total gerencia sobre o job (display, copy, delete), exibir a log gerada ou ainda disparar eventos. A API oferece duas funções de uso simplificado que, apesar de não oferecerem muitos recursos, são extremamente simples de se João Luiz Barbosa Junho/2000 Página 46 ACADEMIA BASIS CEMIG usar: A BP_JOBVARIANT_SCHEDULE que schedula um report ABAP passando apenas a sua variante para execução e o BP_JOBVARIANT_OVERVIEW para gerencia simplificada de jobs Para a programação normal, utiliza-se as funções JOB_OPEN, JOB_SUBMIT e JOB_END. Através destas facilidades é possível dar ao usuário a capacidade de schedular e gerenciar jobs sem contudo ter acesso a transação SM36 e SM37. Com isto é possível implementar uma maior segurança e implementar uma padronização no nome dos jobs no ambiente através de uma interface bem mais simplificada para o usuário final. Background Check and Troubleshooting Além da SM37, existem outras transações no sistema que permitem ao usuário analisar a sua pasta particular de jobs. A transação SMX oferece uma forma simplificada para o usuário analisar seus próprios jobs através de listas mais compactas e campos sumariados. Já a SM39 exibe uma analise bem mais detalhada, inclusive com informações estatísticas. Caso um usuário não esteja conseguindo administrar seus jobs, a causa mais provável será autorizações incorretas pois eventualmente o job pode ficar release mas por falta de autorização ele não inicializa. Caso os jobs não estejam rodando, além de verificar a existência de work process disponíveis (SM50), verifique se os batch schedulers (time-based e event-based) estão rodando corretamente através da transações SM61 e SM65. Lembre-se da configuração dos parâmetros de profile vistos anteriormente. João Luiz Barbosa Junho/2000 Página 47 ACADEMIA BASIS CEMIG Data Archiving Definition Archiving é uma sistemática que permite transferir dados das bases de dados R/3 para arquivos, do tipo texto estruturado, armazenados fora do ambiente R/3, seja meio magnético ou ótico, em formato compactado. É implementado no R/3 através da transação SARA. Várias razões podem justificar um projeto de archive: • Falta de espaço físico 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 são utilizados • Devido a razões legais ou motivado pelo negócio da empresa, uma série de informações precisam ser mantidas disponíveis para consulta ao longo do tempo A freqüência e a necessidade de efetuar archiving varia portanto de empresa para empresa, baseado nos seus recursos de hardware disponíveis e no seu objeto de negócio. Em relação ao negócio só faz sentido fazer archive de informações que realmente podem ir para o “arquivo morto”. How Archive Works O processo consiste de duas etapas: na primeira os dados são lidos na base de dados R/3, marcados e copiados para arquivos externos a partir das orientações do archiving objects (conjunto de tabelas que estipula quais dados deve transitar de forma conjunta). Na segunda etapa os dados marcados são consistidos e deletados da base de dados. Este processamento em duas fases existe exatamente para garantir a máxima segurança desta sistemática. A arquitetura de archiving é baseada em objetos de archiving que definem os processos e contém informações sobre o processo: • Informação sobre as tabelas que contém os dados que serão arquivados • programa que extrai os dados e armazena em files externos • programa de deleção, que compara os dados armazenados com a base e efetua o delete se ambos estão idênticos, garantindo a integridade dos dados extraídos • Documentação do processo (visualizado através da opção Info na SARA) A compressão dos dados nos files gerados é da ordem de 5, embora cluster tables não possam ser compactadas. O processo pode demandar muito processamento e I/O sendo recomendado rodar em horários fora do pico no sistema. O processo de delete (segunda fase do arquive) pode ser selecionado para rodar imediatamente após o extact ou para processamento posterior, comandado pelo usuário. Apesar do processo de deleção somente ocorrer após um verificação dos dados armazenados, é interessante que durante a implantação e testes de um ambiente de archive garantir que esta facilidade não seja disparada automaticamente. Archive Environment Existem uma série de objetos de archive já desenvolvidos pela SAP para operacionalizar o archive em diversas áreas e tabelas standard do SAP. A cada nova versão do R/3, é uma tendência 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 série de function modules. Desta forma a leitura dos dados arquivados é efetuada através de chamada a funções do ADK. Durante o processo de gravação, o ADK pode splitar os dados que serão arquivados em vários files. Esta interface única através do ADK garante que o dado armazenado seja visto pelos programas ABAP na forma exata com que foram arquivados. É possível utilizar o ADK para desenvolver objetos de archiving para tabelas Z, definidas pelo usuário. Nunca a utilize para acessar tabelas SAP standard, mesmo que não exista um objeto desenvolvido para determinada tarefa. O SAP ArchiveLink é uma interface para gerencia dos files arquivados. João Luiz Barbosa Junho/2000 Página 48 ACADEMIA BASIS CEMIG Acessing Archived Data Quase todos os objetos de archive possuem programas de leitura próprios que lêem o arquivo seqüencial gerado e emitem relatórios. Alguns objetos nos dão ainda a facilidade de emitir relatórios que mesclam informações arquivadas com informações do banco, como é comum em quase todas as análises de relatórios 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 possuírem a facilidade de reload dos dados (operação inversa do archive), é recomendado que esta operação somente seja efetuada para corrigir erros de operação, como por exemplo archive disparado antes da hora. A SAP recomenda inclusive que esta operação seja efetuada somente nestes casos e imediatamente após a operação mal feita, nunca alguns dias depois. Só para lembrar, SD não pode sofrer o reload a partir da versão 4.0a. Preparations for Data Archiving Archiving é um projeto que envolve de forma cooperativa a área de Basis, analistas e usuários das áreas funcionais além de uma assessoria jurídica 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 não mais se fazem necessários para consulta online. É o conhecido arquivo morto das empresas. Do ponto de vista da administração do sistema, o archive se faz necessários para esvaziar o banco, seja por questões de tempo de backup/restore, performance ou ainda por falta de espaço em disco. Os administradores de sistemas acessam as funções de archiving normalmente através da transação SARA. Os usuários dos aplicativos ativam a interface através de entradas nos seus menus funcionais. É necessário uma identificação cuidadosa das tabelas com alto índice de crescimento e objetos que se justificam pelas necessidades do negócio. A transação DB15 é um excelente auxílio nesta análise por fornecer uma referência cruzada entre tabelas e objetos de archiving. Identifique e estude todas as notas no OSS que se referem aos archive objects que serão implementados Para cada objeto de archiving é preciso definir suas parametrizações que configuram os dados que serão arquivados e a forma como esta operação será efetuada (tamanho dos datafiles gerados, número de registros em cada file, etc.). A transação SF01 é utilizada para customizar o logical file e paths. O objeto de archive possui duas variantes para o programa de deleção. O archive run possui uma outra variante onde você define os dados que serão 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 disponível para a movimentação de dados. Monitoring an Archiving Run Um archive roda em background e pode ser monitorado através da SM37. Dependendo da configuração 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. Através da transação SARA (funcionalidade management) é possível monitorar o tamanho, localização dos files e número de registros arquivados. Caso o processo de archive não seja completado com sucesso, diversas opções terão 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 após 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 não estão com start automático, é preciso deletar os files que foram gerados até o momento e recomeçar o processo João Luiz Barbosa Junho/2000 Página 49 ACADEMIA BASIS CEMIG Para efetuar operações de archive é preciso possuir a autorização específica (S_ARCHIVE). A transação SARA possui uma funcionalidade de Info que descreve para cada objeto de archive as autorizações necessárias para percorrer as tabelas do R/3 e recolher os dados. Além disso não se deve esquecer que o archive roda em background, significando que o usuário envolvido no processo além de possuir autorização para a area funcional precisa possuir as autorizações suficientes para esta tarefa de rodar os jobs de archives. Dicas práticas : • Veja a tabela arch* para entender a relação entre os objetos de archives e as tabelas envolvidas • Sempre que for fazer um archive faça 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 versões e atualizações • Utilize o objeto bc_archive para arquivar os documentos de archive. João Luiz Barbosa Junho/2000 Página 50 ACADEMIA BASIS CEMIG System Monitoring What, why, who and when Os principais focos de monitoração são : • R/3 (application servers, buffers, …) • Database (performance, buffers, backups, …) • Operationg system (cpu, file system, hardware contention, …) A monitoração no R/3 4.0 é feita de uma forma simplificada através de uma grande arvore que ira mostrar, através de suas folhas, os diversos item que devemos estar atentos em todo o ambiente. A grande vantagem desta arvore é a hierarquização e categorização de todos os elementos (tree elements e objects) que são relevantes, seus parâmetros de valores (Attributes) e a captura automática e centralizada de todas as informações e um ponto de acesso unico para a tarefa de monitoração. Monitoring Architecture O Alert Monitor é uma ferramenta configurável que existe no R/3 e permite a monitoração de todo o ambiente a partir de uma única interface que exibe mensagens e sinais de alerta no sistema. A monitoração dos diversos componentes e ferramentas do ambiente R/3 é uma operação necessária 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 monitoração é uma tarefa periódica que abrange desde o sistema operacional, passando pelos componentes do kernel R/3 e indo até a base de dados do sistema. Os objetos passíveis de monitoração no ambiente R/3 são arranjados em uma árvore que sumariza em seus nós as diversas áreas de atuação. Esta monitoring tree agrega atributos em seus nós que podem ir sendo detalhados até chegar a granularidade mínima da entidade monitorada. Um alert identificado em um destes atributos se reflete visualmente através de cores (verde-ok, amarelowarning, vermelho-alert) nos nós da árvore e hierarquicamente são transferidos para os galhos mais elevados. É necessário portanto ir efetuando operações 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 análise do transport system e das transações de aplicação O monitor do R/3 é concebido com uma arquitetura aberta que permite inclusive que ferramentas de terceiros sejam incorporadas a sua árvore de monitoração. Cada nó da árvore é denominado MTE (monitoring tree element), que podem ser agrupados em classes de monitoração. Os objetos físicos ou lógicos que são passíveis de monitoração são 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 nível de visibilidade (operador, administrador, etc.), prioridade do alerta e descrições. Estas configurações ficam válidas para todos os objetos pertencentes a uma determinada classe, evitando assim redundância de definições. Os atributos comuns também podem ser agrupados em customizing groups aos quais são associados thresholds para os alerts e textos de alerta. Uma vez configurados os alerts, é possível então associar tools aos MTEs. Estas ferramentas permitirão: • 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 poderão ser ferramentas standard da SAP quanto ferramentas definidas e criadas João Luiz Barbosa Junho/2000 Página 51 ACADEMIA BASIS CEMIG pelo usuário. A árvore básica de monitoração contém o Basic monitor, porém o usuário pode criar suas próprias árvores customizadas de monitoração. 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 (relatório, função, módulo, transação, programa, etc), a localização (servidor, banco de dados, etc) e modus operandis (background, foreground, manual) • Liberar a transação 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 definição de outra arvore ou até não implementar a ferramenta Monitoring and Tools Na estrutura do Alert monitor cada server é exibido separadamente. Cada server tem sua própria árvore que contém as seguintes estruturas: Operating system, Database, R/3 services, R/3 basis system, R/3 ABAP e R/3 system log. As principais transações e métodos para monitorar o sistema são : • A system log (transação SM21) contém informações referentes ao sistema R/3 e suas instâncias 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 transação mostra o log (/usr/sap/SID/dvebmgs00/log/slog00.log) apenas da instância corrente. No Unix ela pode mostrar as logs de todas as instâncias • nó R/3 services provê informações sobre os work processes do sistema. A transação SM51 nos dá um overview (incluindo a queue do dispatcher, system log, remote logon, etc) das instâncias disponíveis enquanto a SM50 analisa os work process de uma instância específica. A SM66 oferece um overview de todos os work processes ativos (se for necessário o default pode ser alterado para ver todos ou em um status especifico) em todos as instâncias do sistema. • A SM04 e AL08 nos dá um overview dos usuários logados no ambiente R/3. A SM04 mostra os usuários de uma determinada instância e a AL08 de todas as instâncias ativas. • processo de update no R/3 é usualmente executado em modo assíncrono, onde os dados são escritos em tabelas intermediárias (VB* tables) e posteriormente transferidas para a base de dados pelos work processes de update V1 e V2. A transação SM13 permite a monitoração da fila e dos processos de update. A fila de update poderá conter processos que terminaram com erro. Apesar de ser possível em alguns casos restartar estes processos, a SAP não recomenda que se proceda ao restart da transação pelo usuário. • R/3 possui seu próprio mecanismo de lock que fica residente em uma tabela na memória da instância que contém o processo de enqueue. Os locks podem ser monitorados através da transação SM12. Os locks que permanecem no sistema poderão ser eliminados manualmente após exaustiva verificação das causas, uma vez que o procedimento normal é quando os locks postados são eliminados automaticamente pelo update das tabelas ou cancelamento da transação. • A transação ST22 permite que se analise os dumps de programas ABAP. Através desta análise é possível identificar o erro pela análise dos campos e variáveis 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 estatísticas dos tempos de resposta das transações são apresentados de forma detalhada e estratificadas por componentes (rolltime, wait time, DB time, processing time e load time) permitindo a rápida identificação de possíveis gargalos no ambiente R/3. As estatísticas apresentadas pela ST03 permanecem em um arquivo do sistema operacional (file stat no diretório data da instância) e são recolhidas e consolidadas de tempos em tempos pelo programa RSCOLL00 schedulado no ambiente. Este programa se baseia na tabela TCOLL para disparar uma série de outros programas satélites que efetuam as mais diversas tarefas de consolidação por níveis de tempo/data. João Luiz Barbosa Junho/2000 Página 52 ACADEMIA • • • • BASIS CEMIG A SMLG permite definir e monitorar logon groups. Com esta facilidade é possível fazer balanceamento de carga através da distribuição inteligente dos usuários das diversas áreas pelos servidores de aplicação da rede. A transação ST02 provê informações referentes aos status dos buffers e o gerenciamento de memória do ambiente. A transação ST04 permite monitorar a base de dados do ambiente deforma detalhada, seja através de análise de buffers ou da análise física de discos e locks. A ST06 exibe informações referentes ao sistema operacional recolhidas pelo programa saposcoll. A análise pode ser tanto um retrato do instante quanto uma comparação evolutiva das últimas 24 horas. Os work processes alocam áreas na memória para trabalhar os processos. Um dialog work process trabalha em modo multiplexado para otimizar a sua utilização entre os diversos dialog steps que compõem um transação R/3. Para permitir esta multiplexação, os dialog work processes efetuam operações 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 instância ocorre o que chamamos de work process dispatch Diferentes tipos de memória são alocados pelos dialog work processes. Inicialmente o sistema aloca uma pequena porção da roll area (definido no parâmetro ztta/roll_first) onde estabelece ponteiros para os diversos pedaços de memória que vão sendo alocados na extended memory do sistema. Uma vez esgotado o limite de memória obtido na extended memory, o dialog passa a utilizar o restante da roll area disponível. Note que ao entrar em multiplexação, o processo de roll out/roll in efetua rolagem apenas da porção de memória 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 lança então mão da memória local, ou heap area. Como esta memória não pode ser rolled out (por ser grande), o dialog entra em modo PRIV (private) e para de fazer multiplexação, permanecendo alocado para o usuário mesmo durante os dialog steps. Como os background work processes não necessitam fazer roll in/roll out por não serem conversacionais, a seqüência de alocação de memória varia em relação aos dialog. O sistema aloca a roll area, posteriormente a privaty memory (heap) e somente então faz uso da extended memory, que fica desta forma mais dedicada para os dialog process. Quando se trabalha com vários application servers em um ambiente R/3, é necessário que os servers permaneçam sincronizados para garantir a integridade dos insert e updates que ocorrem no ambiente. Os dados que necessitam de sincronização são escritos em uma tabela (DDLOG) que de tempos em tempos é consultada e os dados lá presentes sofrem refresh na memória das instâncias, sendo desta forma sincronizados. O parâmetro rdisp/buffrefmode especifica como a escrita e leitura desta tabela ocorre e o parâmetro rdisp/buffreftime especifica a frequencia do refresh. O parâmetro rdisp/buffrefmode possui um valor dividido em duas partes. O primeiro campo especifica se o sistema irá (sendon) ou não (sendoff) escrever valores na DDLOG. O segundo campo especifica se o sistema irá (exeauto) ou não (exeoff) efetuar leitura e consequentemente refresh dos dados lá gravados. Sistemas distribuídos com várias instâncias deverão ter o parâmetro rdisp/buffrefmode=sendon/ exeauto especificado em cada uma de suas instance profiles. Até mesmo sistemas que possuem apenas uma instância deverão especificar este parâmetro para sendoff/exeauto já que durante o processo de transporte o tp grava entradas nesta tabela para posterior refresh. João Luiz Barbosa Junho/2000 Página 53 ACADEMIA BASIS CEMIG Segunda Semana Users and Authorization in the R/3 System Users in the R/3 environment O Ambiente R/3 possui várias formas de controle de acesso mas devemos lembrar que o R/3 está sendo executando em um sistema operacional e utiliza um banco de dados como repositório e portanto devemos observar os aspectos de segurança nestes ambientes e na inter-relação entre o R/3 e eles. Devemos tomar cuidado com os usuários 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 utilitários no sistema operacional, como sapevt, e acessar o banco de dados diretamente a partir de utilitários do oracle. Do lado do R/3 temos que ter os mesmos cuidados pois uma brecha na autorização pode permitir que uma chave no R/3 acabe por ter acesso ao sistema operacional e aos mesmos utilitários mencionados anteriormente. Uma das primeiras atividades após a instalação do sistema é a troca das senhas dos usuários (SIDadm, sys, system, sap, sap*, ddic e earlywatch). . Authorization Concepts As autorizações existem para limitar o acesso a transações e objetos do sistema R/3 que necessitam de proteção. As autorizações são agrupadas em profiles e estas profiles são associadas ao master record do usuário. Autorizações podem ser no nível da transação ou nos mais diversos níveis, como por exemplo em operações na transação ou ainda em range de valores de campos As autorizações sempre pertencem a authorization objects. Estes objetos de autorização são agrupados em object classes que por sua vez são organizados ou categorizados por business area (FI, SD, etc.). As autorizações são mantidas através da especificação de valores para determinados fields dentro de cada objeto de autorização (que pode ter até 10 fields). Todas as autorizações são do tipo positivas, ou seja, efetuam grants para o usuário e não revokes, ou seja, se duas autorizações 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 através da definição 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 máximo de 150 profiles. As profiles são associadas ao usuário tanto manualmente através da SU01 quanto durante o processo de geração e manutenção das activity groups. Eventualmente pode ser necessário criar objetos de autorizações além do standard. Para isso usamos a transação SU21 para manter objetos de autorizações e a SU20 para manter os campos dos objetos de autorizações. Em relação aos papéis dos administradores de segurança no sistema poderíamos dividir a administração em três níveis, a saber : • Administrador de usuário: responsável por manter os dados dos usuários, por associar os grupos de atividades e as profiles aos usuários e atender aos chamados dos usuários • Administrador de profiles: responsável por manter os grupos de atividades e as profiles de forma genérica sem entrar no mérito dos valores atribuídos as responsabilidades e atendo-se apenas as transações do perfil • Administrador dos dados da autorização: responsável 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 questões João Luiz Barbosa Junho/2000 Página 54 ACADEMIA BASIS CEMIG semânticas associadas as autorizações aplicadas a cada função a ser desempenhada pelos usuários. Authorization as ER Classes Objects 1-n na task e n-n no código abap Transaction Fields Authoriz. Profiles Values Users Authorization Checks Quando o usuário efetua o logon no sistema suas autorizações são carregadas para a user context area (que fica na roll area da instância) e são verificadas a cada transação ou atividade executada pelo usuário. Antes que uma determinada transação ou operação ocorra, os fields do authorization object são checados contra os fields do usuário para aquele mesmo objeto de autorização. Esta operação é do tipo AND, ou seja, todos os n fields do objeto tem que ser atendidos. Caso a verificação falhe, o usuário recebe uma mensagem de erro e a operação não é executada. Caso o usuário possua duas autorizações contrastantes, vale aquela que libera o acesso, já que entre fields do mesmo tipo a operação é OR. Para simplificar, podemos entender que a verificação de segurança ocorre nos seguintes em passos : • Para ganhar acesso a transação • Verifica se o usuário está autorizado a acessar a transação através da verificação do objeto s_tcode • Verifica o objeto associado a transação em questão e se o usuário tem autorização para este objeto e quais são elas. Ex. O usuário possui o s_tcode para mm01, mas possui o valor 03 para o campo actvt do objeto m_mate_sta • Durante o processamento do código abap • Verificação das autorizações verificadas pelo comando abap authority-check Algumas outras dicas isoladas de autorizações : • Durante um call transaction os dois primeiros passos, relacionados a segurança da transação, não são verificados • Se o buffer do usuário for pequeno demais (veja parâmetro auth/auth_number_in_userbuffer) algumas autorizações podem ser perdidas • Se for necessário cancelar a verificação do s_tcode utilize o parâmetro auth/no_check_on_tcode • Se for necessário saber quais autorizações estão carregadas no buffer utilize a transação SU56 e se for necessário saber qual autorização está faltando utilize a SU53 Dicas de tabelas: Tabela TACT contém todos as atividades possíveis no r/3 e a TACTZ contém o relacionamento das atividades possíveis para um objeto Profile Generator O profile generator (PFCG) é uma ferramenta que simplifica a administração de segurança através de uma visão voltada para o menu de transações da empresa permitindo que de forma mais interativa se crie e associe profiles para usuário ou grupo de usuários que executam determinada função. Este João Luiz Barbosa Junho/2000 Página 55 ACADEMIA BASIS CEMIG grupo lógico de funções comuns que possuem profiles comuns são denominados Activity Groups. Um usuário pode estar associado a um ou mais activity groups. Ao se associar uma transação a um determinado activity group, o profile generator automaticamente identifica os authorization objects necessários para aquela atividade e os associa a profile que será gerada. Caso os fields sejam customer-independents, o sistema já provê os valores necessários para a atividade, caso contrário os valores precisam ser completados pelo administrador durante o processo de geração. Ao gerar um activity group o administrador de segurança 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 descrição funcional (activity group) seja associada para diferentes grupos de usuários, provendo assim diferentes níveis de autorização dentro de uma mesma funcionalidade. Isto simplifica a administração de segurança. Neste caso os usuários são associados a responsabilitie e não mais ao activity group. Isto significa que caso grupos distintos de usuários que efetuam as mesmas transações em um sistema R/3 diferindo apenas nas autorizações para operações permitidas dentro destas transações não mais precisam ser administrados a partir de activity groups distintos, mas sim através de responsabilities distintas dentro do mesmo activity group. Neste tipo de administração, as autorizações para transação são associadas apenas uma vez no activity group para os diversos usuários, o que simplifica caso uma nova transação comece a fazer parte de suas atividades. Ao exibir a lista de autorizações no profile generator, o sistema divide a exibição em 3 níveis: • primeiro nível contém as object class, por exemplo “Standard Finantial Accounting - FI” • segundo nível contém os authorization objects, por exemplo “Customer: Authorization for company codes – F_KNA1_BUK” • No terceiro nível contém authorizations, por exemplo “Customer: Authorization for company codes – T.....” e abaixo dele o sistema lista todos os fields com seus respectivos valores Nesta lista é possível dar manutenção nos valores (clicando no lápis) ou ainda obter documentação detalhada de um authorization object é só dar um duplo click na sua descrição (segundo nível). Ao se clicar no item da montanha (authorization object) é possível obter uma lista das transações daquele activity group que necessitam deste objeto de autorização. O profile generator possui outra característica. Nele é possível fazer o apontamento para os usuários que irão possuir um determinado perfil. Neste caso devemos executar o programa RHAUTUPD para rever as profiles e task profiles dos usuários. Na prática o programa varre o cadastro de usuários removendo todas entradas relacionadas ao grupo de atividade que esta sendo trabalhado e depois insere-as novamente. Se for necessário fazer isto para todos os grupos de atividades devemos utilizar a transação 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 estarão corretos. Os principais passos para a criação de um perfil, também conhecido como activity group, são : • Especificar as atividades que serão desenvolvidas a partir dos caminhos de menu • Criar as responsabilidades (opcional) • Criar a authorization profile • Associar os usuários ao activity group • Atualizar, utilizando o rhautupd, o mestre de usuários Devemos procurar sempre alterar o nome gerado pelo standard para facilitar o compreendimento e a localização. A SAP sugere que o nome sempre começe por S_. O profile utiliza as cópias de algumas tabelas standard (USOBT e USOBX) para trabalhar. A USOBT_C contém os objetos que precisam ser verificados e a USOBX_C os valores necessários aos objetos. Estas tabelas podem ter seus conteúdos mantidos pela transação SU25. Já a transação SU24 pode ser utilizada para ajustar os checks dos objetos. Como ilustração, a transação SU24 mantém o tipo de check que será feito, a saber : U – não é mantido; N – não é checked; C – é checkado mas os valores não são mostrados no profile generator e CM – o check é feito e o profile generator conhece os valores possíveis. João Luiz Barbosa Junho/2000 Página 56 ACADEMIA BASIS CEMIG User Master Record Através da transação SU01 é possível dar manutenção nos usuários. As informações estão agrupadas por identificação e localização, dados de logon, defaults, task profiles, profiles e parâmetros. Já a transação SU3 (ou System à User profile à Own data) permite que o próprio usuário altere seus dados, tais como Address, Defaults e Parameters, sem violar a segurança de acesso estabelecida pelo administrador. Lembrar sempre que se for associar uma task ou responsibility (profiles geradas por profile generator) a um usuário, o correto é faze-lo pela pasta de task profiles. Se a inclusão for feita pela pasta de profiles a autorização vai funcionar mas na próxima reconciliação (execução do rhautupd) este dado será perdido pois vai prevalecer apenas as profiles adicionadas na task profiles. Settings for System Profile Parameters Diversos parâmetros configuram o funcionalidade de segurança no R/3, a saber : • Configurar o tamanho mínimo 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 usuários após logons incorretos, login/fails_to_user_lock com default 12 • Fechar a sessão após 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 parâmetros para configurar o sistema de segurança de login do R/3. Para maiores informações pesquise a nota 66533 e a 68048. Outra boa dica é a remoção do sap* na tabela usr02. Com isto, e a alteração do parâmetro que impede do sap* logar, voce pode utilizar o sap* com a senha pass. A transação SUIM exibe, através da SARP ou SU01->information, a lista de todos os usuários bloqueados no sistema e mais uma dezena de relatórios de usuários, 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, autorizações SAP_ALL, devendo o administrador alterar suas senhas na instalação. O client 066 utilizado pela SAP para consultoria remota possui o usuário EARLYWATCH (pwd support) que também deverá ter a sua password alterada. O SAP possui um usuário SAP* com password PASS e autorização SAP_ALL hard-coded em todos os seus sistemas. Isto significa que quando não existe um usuário SAP* na user master table (USR02) do sistema, este usuário pode ser usado para efetuar logon como SAP_ALL. Por razões de segurança portanto é interessante que sempre tenhamos um usuário SAP* definido em cada client. A nota 68048 sugere um parâmetro (login/no_automatic_user_sapstar) que quando especificado suprime a possibilidade de utilização deste SAP* hard-coded. Porém sempre que se for criar um novo client é necessário permitir a existência desta feature hard-coded para que se possa logar no novo client que não possua nenhum user ainda criado. Information System e Authorization Traces O R/3 permite que se check quais verificações de segurança estão sendo efetuadas em uma determinada execução de programa através de traces, que são ativados através do caminho Tools à Administration à Monitor à Traces à System trace (veja nota 66056 para detalhes de utilização) ou transação ST01. O log é gravado no diretório \usr\sap\SID\DVEBMGS00\log\trace*.log. João Luiz Barbosa Junho/2000 Página 57 ACADEMIA BASIS CEMIG Para uma analise localizada de falha de segurança pode-se utilizar a transação SU53, que exibe quais authorizations são requeridas em determinada task. A transação SU56 exibe o buffer de autorização do usuário. Se uma determinada autorização não está aparecendo, verifique: • Se não houve uma manutenção de profile ou activity group enquanto o usuário estava logado. Neste caso é necessário um novo logon • Se as autorizações foram alteradas através 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 não está muito pequeno. O parâmetro auth/auth_number_in_userbuffer define o número de entradas reservada nesta área para cada usuário, devendo ser aumentado se for o caso Ao se criar um usuário pela SU01 deve-se especificar a sua categoria, se Dialog, BDC (batch input), Background (batch jobs) ou CPIC (para conexão remota). Algumas destas categorias tem características próprias, como dialog ou background, mas servem também como informação documentacional. Password Rules Existem uma série de parâmetros para configurar o tratamento que o R/3 vai dar a senha do usuário. Além da lista abaixo ainda podemos fazer uso da tabela USR40, através da SM30, para inserir palavras ou seqüências de caracter que não poderam ser utilizadas na senha. As entradas na USR40 podem também fazer uso de wildcards como *. Além disso temos as seguintes regras : • Tamanho mínimo da password (login/min_password_lng) com default 3 • Primeiro caracter diferente de ! e ? • Os tres primeiros caracteres não podem ser o mesmo nem ser iguais a parte do user name • Não pode ser sap* ou pass • Número máximo de erros na senha para fechar a sessão (login/fails_to_session_end) com default 3 • Número máximo de erros na senha para bloqueio da chave (login/fails_to_user_lock) com default 12 • Libera os usuários que estão bloqueados por logon incorreto a meia-noite (login/failed_user_auto_unlock) • Número de dias para que a senha expire (login/password_expiration_time) com default igual a 0, que significa que nunca expira O R/3 também já vem preparado (hard coded) para impedir uma série de outras senhas, a saber : Profile Generator Setup Para ativarmos o profile generator devemos seguir alguns passos, a saber : • Gerar o enterprise IMG através da SPRO, se ninguém tiver feito. Provavelmente o time funcional já fez • Ativar o profile generator através da inclusão do parâmetro auth/no_check_in_some_cases = Y • Desativar a solicitação a todo instante de chance request pelo profile generator através da transação OOCR • Criar a classe de desenvolvimento utilizando a transação OY08 • Criar as cópias das tabelas standard (USOBX e USOBT) que o profile generator necessita para gerar os grupos de atividades, utilizando a transação SU25 • Alterar os check indicators e os valores dos campos dos objetos de autorizações • 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 usuários não. Com isto temos um inconveniente que quando transportamos o grupo de João Luiz Barbosa Junho/2000 Página 58 ACADEMIA BASIS CEMIG atividades perdemos o link com os usuários que possuem este grupo no ambiente de destino. Por outro lado, podemos levar todo o cadastro de usuários de um mandante para o outro. Isto pode resolver problemas pontuais mas não resolve o problema da manutenção das profiles que estão na produção e nem do ciclo normal de trabalho com os grupos de atividades. Para transportamos um grupo de atividade, lembre-se ele foi desativado pela transação OOCR, devemos clicar no icone do caminhão na transação 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 seleção. Após importarmos a change que foi gerada no ambiente de destino devemos executar a transação 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 não perder a associação com os usuários no ambiente de destino nos próximos 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 serviço que deve estar ativo) para viabilizar a ligação de duas redes com a garantia de segurança e proteção de acesso em cada uma delas pelo proprio parceiro. Com o SAPRouter voce pode : • Controlar e logar as conexões com o sistema R/3 • Permitir que outros saprouters tenha acesso a uma rede específica • Proteger o sistema contra conexões e envio de dados de usuários não autorizados • Encripitar senhas e outros dados por parceiros certificados pela SAP • Controlar o acesso ao serviço de OSS da sap Para utilizar o SAPRouter precisamos criar o diretório saprouter debaixo da arvore \usr\sap; obter a versão mais nova disponível no OSS e criar a tabela de rotas permitidas no arquivo \usr\sap\saprouter\saprouttab. Esta tabela é que contém a definição de quem poderá ou não passar de um lado para o outro. Ela é um arquivo texto com cinco campos, a saber : Permit/Deny/Secure, endereço de origem, endereço de destino, serviço e password. Os endereços podem tanto ser hostnames com ip e neste ultimo caso podemos utilizar também os wildcards para selecionarmos uma rede inteira (Ex. 123.45.*). Já o serviço e a password são opcionais, sendo que o serviço assume o defalt de 3299 que é a porta padrão utilizada normalmente para saprouter. A grande dica na construção da routtab é a definição do que é proibido no inicio do arquivo e do que é permitido no final. Isto é necessário por que a leitura e decisão é feita do primeiro para o ultimo. Para especificarmos uma rota para o saprouter devemos utilizar o mesmo padrão 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 série de variações de parâmetros. Elas podem ser obtidas simplismente acionando o saprouter na linha de comando sem parâmetros. Algumas delas são importantes como – R para dizem onde esta a routtab, -r para startar o serviço, -s para parar o serviço, -r –V3 para selecionar o nível 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 irão transitar na rede e para autenticar as senhas de usuários. Normalmente o R/3 não faz criptografia de dados e a senha transita pela rede como caracter. O SNC é uma camada na arquitetura R/3 que estabelece um padrão de interface para os softwares de segurança e autenticação de usuário disponíveis no mercado. Atualmente os softwares certificados pela SAP são o Kerberos 5 do MIT e o Secude 5. Para maiores detalhes veja a nota João Luiz Barbosa Junho/2000 Página 59 ACADEMIA BASIS CEMIG 66687. O padrão SNC prove três níveis de segurança, a saber : A autenticação da comunicação entre os parceiros sem a proteção do dados que será trocado; Integridade que garante a autenticação e mais uma assinatura digital da informação que está trafegando para garantir sua autenticidade; e Confidencialidade que garante a autenticação a integridade e a confidencialidade que o dado não pode ser interpretado por outro que não sejam os parceiros da comunicação. Para ativarmos o SNC temos que definir qual será o padrão de nome dos usuários. Podemos escolher entre X.500 (que distingue o nome pela formação de diversos elementos), nome@dominio (que usa uma concatenação simples do nome do usuário e de seu domínio) e o padrão de nome externo do R/3. Além de definirmos o padrão de nomes temos que incluir o parâmetro snc/enable = 1 na default profile para ativar efetivamente o SNC. Com isto a SU01 passa a possuir mais uma pasta que contém o nome SNC do usuário. Podemos ainda alimentar a tabela USRACL, que contém o depara, diretamente com o nome interno e o nome externo dos usuários. Para os usuários RFC e CPIC podemos definir apenas um usuário interno para vários usuários externos através da tabela USRACLEXT. Podemos também ativar níveis de insegurança para alguns casos. Por exemplo, aceitar sessões não seguras através do parâmetro snc/accept_insecure_gui =1 ou snc/accept_insecure_cpic = 1. Além da SU01, outras transações 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 utilização do SNC pressupõe a instalação de uma dll (secure.dll) junto com o SAPGUI além do cliente do software de segurança 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 segurança. No geral devemos seguir algumas recomendações para implementar o SNC. A primeira é nunca misturar applications que utilizam SNC com outros que não utilizam. A seguinte é ter certeza que o produto de segurança está apto a trabalhar com os padrões de nomes estabelecidos pelo R/3; E por fim garantir as definições do nível de proteção desejado, dos parceiros e protocolos que serão implementados, quais conexões serão protegidas e as respectivas portas a serem bloqueadas pelo software de segurança. João Luiz Barbosa Junho/2000 Página 60 ACADEMIA BASIS CEMIG Software Logistics R/3 System, Servers and Instances Uma instância R/3 é um grupo de serviços que são inicializados e parados simultaneamente por um dispatcher, possuindo em comum uma profile de instância. O nome de uma instância é composto pelos nomes que identificam os serviços (Dialog Update (Verburren em alemão) Enqueue Background Message Gateway) por ela executados. Uma central instance contém tipicamente todos os serviços 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 número das portas que efetuarão as chamadas ao dispatcher (32nn) e ao message server (36nn) na camada TCP/IP. Um server pode conter uma ou mais instâncias R/3 configuradas. Um PC com o frontend SAPGUI instalado também é 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 contém a central instance. O conjunto de todos estes servidores com suas respectivas instâncias R/3 compõem 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 são 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 são as informações pertencentes a todo o sistema, como algumas configurações ou o repositório de objetos O dicionário ABAP é um dicionário de dados que faz parte do repositório ABAP de um sistema R/3. Seus dados são client independents. Os programas ABAP armazenados no dicionário são compilados uma vez no primeiro acesso (early binding) e ficam armazenados em um outro repositório de executáveis (tabelas D010*). Cada alteração em um programa força a sua recompilação no primeiro acesso posterior. Este procedimento denominado late binding é possível através de um mecanismo de comparação de timestamp. Este mecanismo de early binding e late binding garante que a integridade das informações contidas no dicionário ABAP não afete a performance do sistema, uma vez que os executáveis de telas e programas são mantidos atualizados automaticamente em uma área separada dos respectivos fontes. R/3 Clients Um client em R/3 é uma unidade independente em termos organizacionais, técnicos e comerciais. Um client possui seus próprios usuários e seus próprios dados nas tabelas do R/3. Isto permite que um único sistema R/3 administre vários clients diferentes, cada um com seus próprios 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 são diferenciados pelo kernel do R/3. Na prática o R/3 implementa esta separação através de um campo MANDT (de mandante, ou client em alemão) que participa da chave primária 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 excessão é a tabela T000 que defini quais são os clientes existentes na instância e é uma tabela com definição independente de client. Este campo que identifica um client é composto de 3 dígitos númericos. É portanto importante que sempre que efetuamos um logon informemos o número do client. Este campo é obrigatório na tela de login inicial do R/3, juntamente com a chave e a password do usuário. Como os dados de clients diferentes funcionam no R/3 como bases de dados diferentes (separação por kernel), as empresas quando desejam implementar uma administração coorporativa de suas subsidiárias, o controle centralizado é possível através de uma outra facilidade que é o campo configurável João Luiz Barbosa Junho/2000 Página 61 ACADEMIA BASIS CEMIG denominado company code. Este campo define a menor unidade administrativa com que os relatórios externos podem varrer para uma visão 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 mínimo os seguintes clients: • Client CUST, como o ambiente central onde o desenvolvimento e as customizações são efetuadas pelos times funcionais e de abap. Neste client podemos fazer alterações no ambiente e gerar change request • Client QTST, utilizado para o teste de novas customizações • Client PROD, que é a produção da empresa Em um ambiente ideal, os seguintes clients adicionais são recomendados: • Client SAND, que é um sandbox onde novas customizações são experimentadas antes de efetivamente efetuadas no ambiente CUST. Neste client podemos fazer alterações mas não podemos gerar change request • Client TEST, para teste de customizações 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 produção que compartilham change requests e rotas de transporte com o propósito de manter um sistema de desenvolvimento e customização consistente. Por questões de segurança, é aconselhado proteger o sistema utilizando o conceito de clients, implementando a segurança através do conceito de autorizações garantindo a separação dos dados entre clients. É aconselhável ainda separar fisicamente os ambientes de implementação do desenvolvimento, qualidade e produção. Além das questões óbvias de segurança e performance do ambiente produtivo, tal implementação protege o sistema evitando que configurações client independents do ambiente de desenvolvimento sejam implementadas na produção antes de um teste de validade. Uma implementação em dois ambientes também não é aconselhável porque todos os objetos transportados para o ambiente de consolidação ficam imediatamente valendo no ambiente de produção. A implementação mais recomendada pela SAP é um landscape de três ambientes que implementam clients e rotas próprias de transporte, consistindo dos 3 clients básicos e os 3 adicionais: • Um host composto de três 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 são testados antes de serem migrados para o ambiente produtivo • Um host para o ambiente de produção – com o client PROD Os sistemas R/3 que compõem um mesmo landscape devem possuir system IDs diferentes para a correta identificação das rotas de transporte Change Requests and Transports O sistema R/3 integra mais de 800 processos de negócio que precisam ser customizados e configurados de acordo com as necessidades de cada empresa para atender e se adequar ao seu ramo de negócio. Através de customizações e desenvolvimentos específicos o sistema R/3 é adaptado ao processo de negócio da empresa e estas alterações precisam ser distribuídas entre todos os clients que compõem o landscape da empresa, garantindo assim a consistência do sistema. João Luiz Barbosa Junho/2000 Página 62 ACADEMIA BASIS CEMIG Transporte é o processo no R/3 que permite a distribuição destas alterações ao longo do landscape. O R/3 fornece todas as ferramentas necessárias para a criação, documentação e distribuição das alterações no landscape. A correta configuração do ambiente de transporte é fundamental para o sucesso desta administração: • Todas as alterações devem ser bem documentadas • Um único client é recomendável para todas as customizações • 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 deverão ter profiles de autorizações de acordo com suas necessidades de criação 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ê funções para gerenciar o desenvolvimento de projetos que ocorram centralizados ou distribuídos no ambiente. Ele é composto das seguintes ferramentas: Workbench organizer (transação 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 transação STMS • Ferramentas a nível do sistema operacional (TP e R3Trans) que executam a comunicação com o sistema R/3, o banco de dados e os arquivos gerados no processo de export dos transportes João Luiz Barbosa Junho/2000 Página 63 ACADEMIA BASIS CEMIG Change and Transport System Prerequisites Configuring the System Landscape Antes de iniciar a instalação de um sistema R/3, defina a estrutura de rede necessária para comportar o ambiente. Inicie a instalação pelo ambiente de desenvolvimento. É nele normalmente que residirá o Transport Management System. Durante a instalação do sistema defina um diretório para o transport system. Este diretório será posteriormente compartilhado pelos demais ambientes que comporão o landscape. Após a instalação 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 transação SE06 e configure o system landscape utilizando o Transport Management System (transação STMS). As change requests que permitem sincronizar as customizações e desenvolvimentos entre os sistemas R/3 fluem no landscape através de rotas pré definidas em um único sentido. São as denominadas transport routes. O sistema de transporte utiliza um diretório próprio para onde os change requests liberados são exportados da base de dados. Neste diretório o sistema armazena além de data files, arquivos de comandos e logs de transporte. Fisicamente em um landscape de três sistemas, o transporte de um change request ocorre em três etapas: • Todos os objetos encapsulados em um change request que é liberado (released) são exportados da base de dados do sistema fonte para o diretório de transporte • Em um segundo passo, os objetos serão importados do diretório de transporte para a base de dados do ambiente de quality assurance. • Finalmente após o teste e verificação das alterações, os objetos são importados para a base de dados do ambiente de produção (deliverya system) definido O diretório de transporte (\usr\sap\trans) e todos os seus subdiretórios são exportados pelo ambiente onde foi originalmente definido (normalmente o desenvolvimento) e montado via NFS nos demais hosts dos sistemas que compõem o landscape. Este compartilhamento de uma área única é pré requisito para o correto funcionamento do sistema de transporte. No ambiente NT o diretório é exportado pelo compartilhamento sapmnt e montado nos outros hosts como um disco e acessado por \\hostdev\sapmnt\trans que deve ser setado no parâmetro DIRTRANS. A configuração deste parâmetro é necessário pois o diretório \usr\sap\trans existe em todas as máquinas mas devemos utilizar uma área única para todo o landscape. Para maiores detalhes sobre sistemas heterogeneous veja a nota 83327. O arquivo TPPARAM contém informações que parametrizam o funcionamento do programa de transporte, o tp. O TPPARAM reside no subdiretório bin do transport directory e deve ser configurado após a primeira instalação a partir do arquivo template fornecido durante a instalação. A cada novo sistema introduzido posteriormente no landscape, este arquivo precisa ser editado para incorporar os parâmetros dbname e dbhost e transdir do novo ambiente. Para o parâmetro transdir, e outros relacionados a diretórios, sempre utilize o nome da máquina e o respectivo compartilhamento (Ex. \\host\sapmnt\trans). Para checar se o programa tp está disponível em todos os ambientes do landscape, utilize o comando R/3 system -> Check -> Transport tool. É possível ainda testar todo o diretório de transporte através do check de transport directory. Para consultar os parâmetros definidos no arquivo TPPARAM, utilize o caminho de menu Goto -> TP parameter. Na versão 4.0b temos alguns problemas com os mecanismos de transporte pois o conjunto do STMS ainda não está finalizado (já está mais bem acabado na versão 4.6). O primeiro problema é a seqüência de importação das changes request: ele sempre segue a seqüência de export, ou seja, uma vez exportada o usuário não vai conseguir alterar a seqüência para uma seqüência mais lógica. 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 diretório \usr\sap\trans do ambiente produtivo seria separado. Com isto o analista basis passa a ter que João Luiz Barbosa Junho/2000 Página 64 ACADEMIA BASIS CEMIG controlar as changes que devem ser importadas na produção através da manipulação do arquivo de buffer por um editor de texto. Desta forma passamos a “in foreign group” “import” no sistema R/3. Initializing CTO A transação SE06 é utilizada para configurar o change and transport organizer. Ela deve ser executada uma vez a cada nova instalação de um sistema R/3, independentemente de ser uma instalação standard ou um database copy. Estas configurações são globais no sistema R/3 e tem prioridade inclusive sobre as configurações dos clients (SCC4). A transação SE06 estabelece o valor inicial para os change request e configura as opções iniciais do sistema definindo se o repositório de objetos e os objetos de customização client independents serão globalmente modificáveis. Para os ambientes de produção e de qualidade não faz sentido permitir modificações no sistema. Já no sistema de desenvolvimento tudo pode ser permitido. Eventualmente podemos bloquear os objetos locais para garantir que o time de abap não vai criar objetos sem encapsula-los em change requests. TMS - transport managementa system Através da transação STMS é possível definir as regras de transporte no landscape e os respectivos papéis de cada um dos sistemas R/3, definindo assim a estratégia de transporte baseadas em rotas pré definidas. As rotas podem ser definidas de forma gráfica ou no editor hierárquico da STMS, onde é possível ainda visualizar as filas de transporte e importar objetos. Transport Domain Um transport domain compreende todos os sistemas R/3 administrados centralizadamente através do TMS. Quando se configura uma definição no TMS, o sistema cuida de distribuir via RFC a definição entre todos os sistemas que compõem o domínio. Isto garante que as configurações de transporte sejam consistentes em todos os sistemas pois todas as configurações são feitas apenas no Domain Controler (sistema R/3 que ira controlar todos os outros sistemas R/3 do landscape). Por segurança podemos eleger um backup domain controler que entra em ação se o domain controler sair do ar. Este switch é feito na mão 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 prática o Domain Controler é o sistema R/3 de desenvolvimento pois ela normalmente é a primeira a ser instalada. O TMS suporta vários diretórios de transporte em um transport domain. Os sistemas R/3 que compartilham um mesmo diretório compõem um transport group. Através do TMS podemos executar transportes entre sistemas que pertençam a transport groups distintos mas ela não suportam transportes entre domínios diferentes. Devemos lembrar que se fizermos o tp import entre domínios diferentes o processo será bem sucedido. O mesmo não pode ser garantido entre sistemas R/3 de versões diferentes pois podem existir diferenças na estrutura e na utilização nos objetos encapsulados pela change. O Landscape pode ser definido como todos os sistemas R/3 que compartilham change requests com o propósito de manter ambientes consistentes de desenvolvimento e customização. Por este motivo um system landscape normalmente é sinônimo 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 configuração do TMS é executada através da transação STMS no client 000 e com o usuário DDIC, ou um equivalente com a profile S_CTS_ADMIN, e passa pelos seguintes passos: • Configuração do transport domain através da especificação dos sistemas R/3 e dos transport groups além da definição de um deles como sendo o controlador do domínio. • Configuração das rotas de transporte através da definição do sistema onde as changes serão consolidadas e do sistema onde a change será finalmente delivered após os testes • Check e verificação das configurações através das ferramentas do TMS João Luiz Barbosa Junho/2000 Página 65 ACADEMIA BASIS CEMIG O sistema escolhido como controlador do domínio deverá ser um sistema com alto grau de segurança e disponibilidade, normalmente o production system ou o QAS. Esta tarefa não 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 transação STMS, no momento da configuração 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/gravação) e um arquivo DOMAIN.CFG no subdiretório bin do diretório de transporte que conterá a configuração 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 configuração do TMS nem todos os sistemas existem, o R/3 permite que se defina todo o ambiente através da especificação de sistemas virtuais, permitindo com isto que se configure antecipadamente todas as rotas de transporte. A SAP provê o TMS com configurações standard default que já prove rotas para landscape de um, dois ou três sistemas, agilizando desta forma o trabalho de configuração inicial. As rotas de transporte são de dois tipos: de consolidação, do desenvolvimento (integration system) para o sistema de quality assurance (consolidation system) através de uma transporte layer (Z<SID>), e de delivery, onde os transportes consolidados são finalmente transportados do sistema de qualidade (consolidation system) para a produção (delivery system). Após configurar o transport domain e definir as rotas de transporte, o TMS é utilizado para distribuir esta configuração entre os sistemas e ativar a nova configuração. As alterações efetuadas em objetos SAP são transportadas através da consolidation route SAP. Através do hierarchical list editor é possível visualizar e editar a configuração do TMS. O sistema aceita ainda a configuração através de ferramenta gráfica drag-and-drop. O TMS provê ainda ferramentas para testar as conexões RFC, checar o diretório de transporte e verificar o funcionamento do programa tp. João Luiz Barbosa Junho/2000 Página 66 ACADEMIA BASIS CEMIG Change Management for Development Change Requests As alterações no software R/3 podem ser divididas em cinco categorias: • Customizing: é a configuração dos processos de negócio e funções de menu através do IMG • Personalization: são as mudanças globais das características das telas e definição de valores default para determinados campos (SM3) • Modification: são mudanças efetuadas pelo cliente no repositório de objetos do R/3 (os SAP objects). estas alterações precisam ser cuidadosamente avaliadas quando do upgrade A de versões do sistema. A partir do release 4.5 a SAP introduziu o Modification Assistent para auxiliar a gerenciar e automatizar estas mudanças • Enhancement: criação pelo cliente de objetos no repositório que são referenciados pelos objetos standard do R/3 através de user exits. Estes desenvolvimentos são os ideais por reduzirem as necessidades de modification adjustments durante o processo de upgrade • Customer Development: criação pelo cliente de objetos no repositório através do ABAP Workbench (programas, etc.) Uma change request é um “pacote” contendo os objetos que serão transportados de um sistema R/3 para outro. Por exemplo, no caso de um abap será encapsulado o source, no caso de uma configuração será encapsulado as entradas nas tabela e sua respectiva ação (cria/deleta/altera). Uma change request pode ser atribuida a vários usuários através do conceito de tarefa. Apesar do nome tarefa ela não representa o que vai ser feito, ela representa a associação da change request com o usuário e a respectiva documentação (que não é obrigatoria) do que foi feito. Todas as alterações efetuadas nos objetos do repositório são criadas e mantidas através do ABAP Workbench e gravadas em change requests. As demais alterações de customizing e personalizations são criadas e mantidas pelas ferramentas de business engineer e também gravadas em change requests. Estes mecanismos permitem que estas alterações sejam posteriormente propagadas pelo landscape para consistência do ambiente. O workbench organizer oferece mecanismos que permite que os change requests sejam documentados através de uma descrição do seu propósito. Os change requests devem ser criados por gerentes de projeto que associam os objetos do repositório que serão trabalhados, onde permanecem lockados com acesso permitido apenas aos desenvolvedores que foram autorizados ao change. As alterações nos objetos do repositório são criadas como tasks associadas ao change request e quando liberadas são transferidas como um todo através das rotas que definem o landscape, já que a unidade de transporte é o change request. A liberação de um change request faz com que uma nova versão dos objetos nele contidos seja gravado no database de versões (somente no sistema R/3 que foi utilizado para o desenvolvimento). WBO - workbench organizer O Workbench Organizer (transação SE09) permite gerar, gerenciar e liberar as tasks e os change requests. Os change requests podem ser pesquisados por vários critérios, tais como desenvolvedor, status, tipo do request ou ainda por data. O frame Global Information da tela SE09 dá uma visão gráfica do status dos change requests transportados e repairs. O Workbench Organizer exibe os change requests de um determinado usuário através de uma estrutura em árvore que permite a visualização hierarquizada da estrutura. Esta árvore é organizada entre change requests com status Transportable (que poderá ser transportada para outro sistema), Local (não poderá ser transportada) e Unclassified. (Não 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 válida, associado a uma change request local significa que esta change não será transportada mas eventualmente em outra change o objeto pode ser transportado). João Luiz Barbosa Junho/2000 Página 67 ACADEMIA BASIS CEMIG Quando o líder de um projeto cria um change request, o sistema associa a ele um número (<SID>K9nnnnn como por exemplo DEVK900736) e ao associar os desenvolvedores, cada um recebe uma task cujo código é estruturado no mesmo critério. A medida que os desenvolvedores vão terminando suas tasks elas vão sendo liberadas individualmente. Quando todas estiverem liberados o gerente do projeto libera o change request que pode então ser transportado para outros sistemas. As autorizações do Change Management são usualmente gerenciadas em quatro grupos distintos e com abrangência 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 autorização dos gerentes de projeto, que podem criar e gerenciar os change requests • S_CTS_ADMIN, é a autorização 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 autorizações relativas ao CTS e STMS. Esta profile contém a autorização s_cts_admin • S_A.CUSTOMIZ, normalmente utilizada pelo lider da equipe e inclui autorização para todas as atividades de configuração do ambiente. Esta profile contém a autorização s_cts_project • S_A.DEVELOP, normalmente utilizada para os abapers e configuradores e não permite a criação de change request. Esta profile contém a autorização s_cts_develo • S_A.SHOW, este perfil é utilizado como curinga pois ele possui todas as autorizações de basis mas todas elas somente para display. Esta profile contém a autorização s_cts_show Todos os desenvolvedores ABAP precisam ter um registro composto de 20 dígitos obtido junto ao OSS e denominado SSCR, SAP Software Change Registration. Sem esta chave não é possível efetuar alterações no repositório 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 repositório e não mais requisitada nos acessos posteriores. Os objetos criados pelos desenvolvedores no repositório deverão sempre começar com Z ou Y, que é o range reservado pela SAP para os objetos dos clientes, evitando assim conflito de nomes com objetos standard do repositório. A nota 16466 descreve em detalhes a nomenclatura a ser adotada na criação dos nomes. Da mesma forma que temos que registrar um desenvolvedor, temos que registrar no SSCR a modifição em um determinado objeto standard. O conceito de name ranges permite que se adote critérios de nomenclatura associados a classes de desenvolvimento. A SAP adota ainda o critério de reservar namespaces para objetos desenvolvidos pelos seus parceiros de desenvolvimento. O comportamento do repositório no que diz respeito aos namespaces e name ranges é determinado em cada sistema R/3 através de global settings que determinam se os critérios serão modificáveis ou não. Escolha a opção Tools -> Administration -> Transports -> Installation follow-up work -> Goto -> System change options. Para manter estes name rangers use a view v_tresn através da transação sm30. Development Class and Transport Layers Todos os objetos do repositório são associados a development classes que provêm um agrupamento lógico de objetos que coordenam os esforços de desenvolvimento. Development classes não SAP deverão começar com Z, Y, $ ou T. $ define development classes para objetos temporários que não serão transportados e T development classes para objetos locais. Quando associamos transport layers a development classes, todos os objetos pertencentes ao determinado development class terão a mesma rota de consolidação 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 (transação SE80) ou simplesmente utilizar a SM30 para manter a view V_TDEVC. Se for necessário podemos manter a view v_tresn para associar os namespaces com as development classes. Esta associação de development classes e transport layers é utilizada para definir as rotas de transporte de consolidação que podem ser gerenciadas através do TMS. Objetos que não possuem João Luiz Barbosa Junho/2000 Página 68 ACADEMIA BASIS CEMIG esta associação ou não possuem transport layers configurados não poderão ser transportados através desta ferramenta. Handling Repository Objects O sistema possui dois mecanismos de lock para proteção dos objetos do repositório. No primeiro mecanismo é baseado na gerencia do change request que garante que os objetos nele contidos somente sejam alterados pelos usuários autorizados pelo gerente do change request que consequentemente estejam trabalhando no projeto. Um segundo mecanismo no editor de programa não 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 não são lockados pelo sistema, mas podem ter lock explícito tanto para a change quanto para a task através 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 após todas as task terem sido liberadas. Ao término das tasks e liberação do change request (release), as alterações ficam disponíveis para transporte (se a change for do tipo transportable). Este processo somente poderá ser executado pelo owner do change request e tenha as autorizações corretas. Tasks liberadas não podem mais ser alteradas porém tasks adicionais poderão ser criadas para corrigir eventuais problemas. Tasks vazias não podem ser deletadas mas são automaticamente eliminadas quando se libera o change request. O processo de release do change request grava uma nova versão dos objetos no repositório e exporta as alterações para arquivos no sistema operacional (diretório de transporte). Change requests locais quando liberados gravam novas versões no repositório porém não geram arquivos no sistema operacional, não sendo portanto transportáveis. As versões dos objetos geradas quando da liberação dos change requests ficam armazenadas no version database, que reside no sistema de desenvolvimento. Os objetos ativos ou suas versões temporárias (sob manutenção) residem em outro local, no development database. As versões dos objetos podem ser comparadas ou restauradas através de ferramentas do sistema, seja pela SE80 ou pela SE09. O único sistema que contém o histórico de todas as versões é o sistema de desenvolvimento. Na produção não teremos este histórico o que significa se perdermos o sistema de desenvolvimento perderemos toda a história da evolução dos abaps. Quando um change request é liberado o sistema exporta seus dados para o sistema operacional e este processo pode ser acompanhado através da SE09 que exibe o return code da operação e uma log do export para possível análise. A lógica do nome do arquivo de log do export é <SID>E9xxxxx. Também é produzido uma log do test import no sistema de consolidação seguindo o padrão <SID>P9xxxxx para o nome do arquivo. Então, a partir do release da change request, ela passa a ser apenas um retrato da história. The Repository O Object Directory é um catálogo de todos os objetos standard SAP e dos objetos desenvolvidos pelo usuário na sua instalação e pode ser acessado pela SM30 tabela TADIR. Durante o processo de customizing o sistema pode gerar automaticamente objetos dentro do repositório como parte do processo. Objetos que são alterados fora do seu ponto de origem, por exemplo a alteração no ambiente de QAS de um objeto originário do sistema de desenvolvimento é denominado um repair. Os objetos do repositório possuem como chave primária 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 cópias. Um objeto criado no ambiente de desenvolvimento e transportado para os demais ambientes do landscape possuirá nestes locais apenas uma cópia do objeto original. Este mecanismo garante que os objetos sejam alterados apenas nos locais onde foram criados. Excepcionalmente é possível alterar uma cópia João Luiz Barbosa Junho/2000 Página 69 ACADEMIA BASIS CEMIG de um objeto, que neste caso é denominado de um repair, ou seja: uma alteração executada em um ambiente diferente daquele onde o objeto foi desenvolvido. Diferentemente dos developments e corrections, que são manutenções de objetos originais, os repairs quando associados a tasks de um change request não permitem que outros desenvolvedores do mesmo time tenham acesso ao objeto, mas que são, assim como os objetos das demais tasks, protegidos por mecanismo de lock. Quando um repair é liberado o sistema requisita uma confirmação que retira o lock de proteção do objeto e permite que o mesmo seja posteriormente sobrescrito por transportes futuros. Repairs liberados sem confirmação podem entretanto ser confirmados a posteriori através da opção Request/task -> Confirm repair Diferentemente das alterações e desenvolvimentos de objetos criados pelo usuário, Modifications são na realidade repairs executados em nossa instalação sobre as cópias dos objetos originais SAP. Estes objetos para serem alterados será necessário informar um access key (obtido no OSS) que é associado ao objeto em uma determinada instalação. Este procedimento de registro fica gravado na SAP que uma determinada instalação efetuou alterações 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 repositório são controlados por este mecanismo rígido 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 alterações introduzidas pelo usuário no seu ambiente diferenciando potenciais erros de programa de manutenções indevidas de objetos, além do que o registro facilita os processos de upgrade de versões R/3 Upgrade Quando de um upgrade, objetos originais SAP são reintroduzidos na instalação o que força a uma análise obrigatória dos objetos que sofreram repairs para que as antigas alterações sejam confirmadas e refeitas quando necessário. Para isto é importante uma documentação detalhada destas modifications e a decisão de que se vale a pena o esforço para reintroduzir as alterações que muito possivelmente já estão 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 transação SPDD deverá ser utilizada para ajustar o dicionário ABAP durante o processo de upgrade. A transação SPAU é utilizada para efetuar um merge de todos os objetos do repositório Workbench Organizer Tools O Workbench Organizer possui uma série de ferramentas que facilitam as tarefas administrativas, podendo ser acessadas através da opção Goto -> Tools: • Verificar relatórios, como por exemplo o Object in requests que oferece informações detalhadas sobre os change requests • Modification monitor que provê informações dos objetos que estão 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 opção 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 verificação das logs de transportes e para verificação dos objetos incluidos nas change requests. Isto pode ser feito para todo o sistema ou especificamente para um usuário. Quem controla isso são os object checks que permitem verificar a integridade (normalmente syntax check) das alterações efetuadas pelo change request antes que ele seja liberado e exportado para files do sistema operacional. Eles permitem também que sempre que for feito uma operação de import/export o usuário recebe uma mensagem no próximo logon. João Luiz Barbosa Junho/2000 Página 70 ACADEMIA BASIS CEMIG Para configurar este recurso para todo o sistema utilize a transação SE01 -> settings -> organizer e para configurar este recurso para um usuário especifico use a SE03 -> global customizing workbench organizer. Planning Change Management Um sistema R/3 necessita de uma solução de procedimento para controlar o processo de alteração e propagação destas alterações por todo o landscape. Para isto não podemos esquecer de algumas coisas que são muito importantes como : • Restringir as alterações no repositório do R/3 através de uma política bem definida de autorizações, pela proteção dos clients através da especificação correta de seus change options (SCC4) e ainda centralizando todo o desenvolvimento em um único sistema R/3. • A definição de times de projetos bem definidos com a especificação de um líder responsável que deve organizar o mecanismo de gerência de tasks e change requests e controlar a qualidade do processo dos desenvolvedores. • A definição de padrões de desenvolvimentos, seja através da especificação de classes de desenvolvimento, da padronização e cobrança de uma correta documentação e a manutenção de versões para simplificar os futuros esforços de upgrade do sistema R/3 ou da aplicação de correções via Hot Packages João Luiz Barbosa Junho/2000 Página 71 ACADEMIA BASIS CEMIG Change Management for Customizing Customizing Concepts Customizing é o processo de parametrização do R/3 de acordo com o processo de negócio que atende a empresa que o está implantando. Esta parametrização é realizada nas transações de negócio e provocarão alteração no comportamento do sistema para atenderão a uma empresa específica. Apesar de podemos implementar alguns módulos e não implementar outros temos que ter em mente que temos que fazer, eventualmente, configurações em todos os módulos. A maioria das customizações são client dependents e afetam portanto apenas um determinado client. Existem entretanto algumas customizações como por exemplo as pricing conditions que são client independents. As atividades de customização basicamente criam ou alteram entradas em views da base de dados. Views são visões pré definidas que podem agregar uma ou mais tabelas em tabelas virtuais e são facilidades implementadas pelos RDBMS. Estas entradas é que provocam a alteração 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 implementação das customizações 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 transação 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 necessárias para todo o ciclo de desenvolvimento de enhancements, modifications e developments. Outra boa ferramenta que pode ser utilizada ao invés desta é a SE80 (Repository browser) • Implementation Guide ou IMG (SPRO) é a transação da principal ferramenta de customização disponível no R/3, onde é apresentada uma lista hierárquica dos passos que deverão ser implementados no processo de customização e implantação de um sistema R/3. Enquanto um processo típico de desenvolvimento requer a alteração e criação de objetos no dicionário, um processo de customização é implementado pela entrada e alteração de valores em campos de tabelas do R/3. Os dois processos geram change requests, porém de categorias diferentes (SYST e CUST respectivamente). Tecnicamente o processo de desenvolvimento é mais complexo que o de customização, já que existe a necessidade de um gerenciamento mais rígido através do registro de desenvolvedores no SSCR, do conceito de version dos objetos e da utilização de classes de desenvolvimento. O R/3 é disponibilizado com o set completo das atividades de customização para todos os seus módulos no IMG, denominado SAP Reference IMG. Os clientes definem os módulos que serão implementados na empresa bem como as funções específicas que serão utilizadas dentro destes módulos, com isto teremos o Enterprise IMG. Todas as transações de customização relevantes, documentação necessária e informações para gerenciamento dos projetos são definidos dentro do IMG através de subsets conhecidos como Project IMGs. Estes projects são levantados a partir das definições iniciais de implementação do cliente. O IMG e seus respectivos projects são definições client independents em um sistema R/3. O IMG não é apenas uma ferramenta de implementação da customização no R/3. Através documentações, conceitos e gerenciamento de projetos o IMG é a metodologia para customização do R/3. A implementação incorpora as seguintes partes: • acesso as Activities de implementação é executado através de transações próprias João Luiz Barbosa Junho/2000 Página 72 ACADEMIA • • • BASIS CEMIG IMG Description descreve os conceitos, recomendações, requerimentos e as atividades necessárias para executar as tarefas Project Management permite o acompanhamento do processo através do controle de status, scheduling e gerência dos recursos Project Documentation para a documentação de todo o processo Customizing Change Requests As customizações executadas no IMG podem ser gravadas em change requests o que permite distribuir posteriormente um processo centralizado de customização para os demais clients e sistemas do landscape. Durante o processo de customização, o client pode ser configurado para requisitar ao customizador um change request para onde todas as alterações serão gravadas automaticamente para posterior transporte. Quando esta opção está desligada, as configurações executadas são gravadas no R/3 porém não são gravadas em change requests. Além dos controles globais de changes que os sistemas R/3 possuem implementados e configurados através da SE09, os chamados global settings, um sistema R/3 possui a facilidade de se configurar individualmente seus clients através da especificação detalhada de seus atributos client dependents e independents. A transação de criação e definição de clients (SCC4) permite a definição de dois subsets de atributos que são 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 customizações client dependents: 1. Changes without automatic recording, permite customizações client dependents mas não as inclui em change requests. Se desejado pelo customizador, as alterações deverão ser incluídas manualmente em change requests para posterior transport 2. Automatic recording of changes, permite customizações nas tabelas que são automaticamente gravadas em change requests 3. No changes allowed, bloqueia as customizações no client 4. No transport allowed, permite as alterações nas tabelas mas impede que as changes sejam transportadas, seja manual ou automaticamente No subset das client independents, as change options protegem o repositório e as customizações client dependents: A. Changes to repository and client-independent, permite o desenvolvimento e customizações client independents B. No changes to client-independent customizing objects, permite desenvolvimento mas bloqueia as customizações client independents C. No changes to repository objects, bloqueia o desenvolvimento mas permite as customizações client independents D. No changes to repository and client-independent custom. obj., impede o desenvolvimento e customizações client independents A combinação destas opções permite que se configure diversos perfis de clients em uma instalação R/3: • 3.D. para um client de produção • 2.B. para um client de desenvolvimento ABAP • 2.C. para um client de customização • 2.A. para um client de desenvolvimento ABAP e customização • 3.D. para um client de teste • 4.D. para um client sandbox Quando a opção de automatic recording não está ligada, as customizações poderão ser gravadas manualmente no change request. Ao entrar na transação de customização deve-se usar a opção de menu (Table/view -> Transport) para fornecer o change request. Após selecionar todas as entradas de customização que desejam incluír, click em Include in Transport e depois basta salvar a alteração e sair do IMG. O processo de liberação de um change request de customizing pela SE10 pode ser efetuado de duas maneiras distintas: no primeiro método (release and export) a change é liberada e seus dados transferidos para os files do diretório de transporte. No segundo método (release to request) a change João Luiz Barbosa Junho/2000 Página 73 ACADEMIA BASIS CEMIG é liberada porém seus dados são transferidos para um outro change request transportável porém seus dados não são transportados para o OS. Customizing Tests Antes de distribuir as customizações, elas deverão ser testadas em separado e dentro do contexto do sistema, em um client de consolidação. É preciso abrir o change request e verificar se o seu conteúdo está completo com todas as alterações. A transação SCC1 é utilizada para transferir as alterações contidas em um change request ou mesmo em uma task individual para outro client do sistema. No caso de ser necessário levar objetos que estão 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 através da opção Include Objects da SE10, o que poupará tempo do administrador. IMPORTANTE: a opção de cópia através da SCC1 somente funciona para dados client dependents. Se a change contiver objetos client independents os mesmos não serão transportados. A transação SCC1 deve ser sempre acionada no client de destino. Customizing Exceptions Certos tipos de customizações, conhecidas como Data-only Customizing Changes, precisam ser executadas diretamente no ambiente de produção sem passar por processo de change request, como por exemplo: taxas de câmbio, regras de pensão, etc. Estes tipos de alterações não tem efeito sobre o negócio da empresa não necessitando portanto de testes extensivos em ambiente separado. Como são passíveis de alterações constantes e para evitar necessidades de controle por change requests, a SAP introduziu o conceito de funções de Update Settings. Os Update Settings podem ser utilizados diretamente no ambiente de produção sem impacto para o negócio da empresa. A tabela CUSAMEN mantêm a lista dos objetos aprovados pela SAP para esta funcionalidade. Não se recomenda que o cliente faça alterações nesta tabela sem a autorização expressa da SAP. Client-independent Customizing Uma tarefa difícil no proceso de customização do R/3 é identificar quais tasks são client independents e quais são dependents. Customizações client independents podem ser: • Em objetos client independents, que são objetos do repositório gerados pelo processo de customização, como por exemplo matchcodes, condition tables e hierarquias. Para garantir que sejam corretamente transportados, deverão ser associados a uma development class • Global customizings, que são configurações standard globais do ambiente em tabelas que não possuem o campo MANDT, como por exemplo calendários, impressoras, etc. Enquanto customizações client dependents são gravadas em change requests da SE10, as customizações client independents precisam ser associadas a change requests do workbench organizer (SE09). Uma boa forma de descobrir se a configuração é dependent ou independent ou transportada automaticamente, manualmente ou não transportada utilize a SPRO -> IMG -> Information -> Title and IMG info. Planning Customizing Change Management É importante restringir as alterações no Enterprise IMG através de uma política bem definida de autorizações, pela proteção dos clients através da especificação correta de seus change options (SCC4) e ainda centralizando todo o desenvolvimento (abap e customizações) em um único client. A definição de times de projetos bem definidos com a especificação de um líder responsável organiza o mecanismo de gerência de tasks e change requests João Luiz Barbosa Junho/2000 Página 74 ACADEMIA BASIS CEMIG A definição de padrões de desenvolvimentos seja através da especificação de classes de desenvolvimento ou da padronização e cobrança de uma correta documentação e a manutenção de versões simplifica os futuros esforços de upgrade do sistema R/3 ou da aplicação de correções via Hot Packages João Luiz Barbosa Junho/2000 Página 75 ACADEMIA BASIS CEMIG Transport Management Transport Process O TMS é a ferramenta existente no R/3 onde estão centralizados todos os recursos para efetuar e gerenciar os transportes no ambiente. Até o release 3.1H os transportes eram efetuados através de ferramentas no sistema operacional e baseava-se nas configurações das tabelas TSYST, TWSYS, TASYS e DEVL principalmente. O primeiro passo no processo de transporte é o release dos change requests que são exportados para files do diretório comum de transporte (\\hostgroup\sapmnt\trans). Para cada change liberado, arquivos são gerados nos subdiretórios data (dados exportados) e cofiles (control files). Este diretório de transporte também possui um subdiretório buffer que contém 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á informações sobre os transportes que estão disponíveis para import e a seqüência de importação. Esta informação é acessada no TMS através da facilidade das import queues A rota de consolidação nas quais os transportes são liberados normalmente especifica um sistema de quality assurance para validação 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 validação no sistema QAS poderá detectar erros que serão corrigidos no DEV e novamente transportados para consolidação. A fila de import do sistema PRD poderá então conter mais um import que deverá ser efetuado. Um ciclo de alteração poderá conter um ou mais change requests, dependendo da necessidade de correção após 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 produção com a versão final do objeto. Para o correto funcionamento deste mecanismo é imprescindível garantir que os transports sejam importados na correta seqüência. Import Queues A ferramenta mais importante para o mecanismo de import do TMS são as import queues que refletem a situação dos import buffers de um determinado sistema. Ela lista os change requests disponíveis para import bem como a ordem com que foram liberados. Os dados exibidos no TMS são lidos no momento em que a transação é chamada. A opção de refresh permite atualizar as informações 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 manutenção do sistema normalmente não é utilizado pois o número de changes provavelmente será bem menor. Através da administração da fila de imports é possível excluir change requests, efetuar forwards para outros sistemas, estabelecer dead lines e end marks, etc. A administração do TMS permite muita liberdade no tratamento das filas, porém é recomendável que estas manipulações sejam bastante conscientes para garantir a integridade e consistência 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 consistência. Para estabelecer end marks nas filas de import é necessário fechar (close) nas filas. Este processo eqüivale a estabelecer stopmarks nos files do sistema operacional (tp setstopmark <SID>). A diferença básica é que enquanto no sistema operacional é possível acrescentar uma stopmark apenas no final da fila, através do TMS é possível colocar o end mark onde for mais conveniente. Este processo é muito útil quando é desejado disparar um import em bloco porém até um determinado ponto apenas. O import all (caminhão) efetua o import até encontrar a marca postada na fila. Operacionalmente é recomendável que sempre se feche a fila (end mark) antes de iniciar um import, evitando que requests liberados durante o processo também sejam transportados inadvertidamente. João Luiz Barbosa Junho/2000 Página 76 ACADEMIA BASIS CEMIG Para evitar inconsistências entre change requests, somente efetue imports de changes isolados quando, com completa certeza, conhecer o seu conteúdo e sua independência dos demais requests. Estes imports são denominados Preliminary imports. Como garantia, o TMS mantém os preliminary imports na fila para que sejam retransportados quando se efetuar o import padrão (all). Em condições especiais é possível especificar parâmetros diferentes quando do import. São as opções –u do comando tp no sistema operacional. Este processo é chamado expert mode. Existem uma série de opções nos expert modes e elas serão detalhadas mas adiante. Transporting Between Transport Groups Transporte são gravados nas import queues de um determinado transport group que compartilha o mesmo diretório de transporte. A opção In foreign groups (Extras -> Other requests -> In foreign groups) permite que se efetue transporte entre sistemas que possuem diferentes diretórios de transporte. Esta opção é útil quando o compartilhamento NFS dos sistemas não é permitido por alguma razão técnica (conexão ruim, segurança, compatibilidade, etc.). Neste caso o TMS cuida de sincronizar as informações entre os buffers do grupo de origem e do o grupo de destino. Transport Monitoring É possível monitorar o processo de transporte através de uma série de ferramentas do Import Monitor do TMS. O sistema permite ainda que se verifique a consistência dos arquivos no sistema operacional (Consistency check) e o return code produzido por cada transporte através da visualização da ALOG. O TMS tem ainda ferramentas para testar as funcionalidades do tp program e ainda verificar a configuração do diretório de transporte (System check) além do funcionamento das conexões RFC com os sistemas que compõem o landscape. Através do Alert Monitor do CCMS é possível integrar algumas funções de monitoração com o TMS permitindo a gerência centralizada do sistema R/3. Transport Process O processo de transporte pode ser descrito nos seguintes passos: • O líder do projeto libera o change request após verificar o término das tasks com os integrantes do grupo de trabalho • O líder 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 consolidação e garante a execução correta do processo com return codes aceitaveis. • O time funcional garante os testes exaustivos no ambiente de consolidação. Qualquer problema detectado deverá ser informado ao líder do projeto para que se inicie a correção e repita o export de uma nova correção para o sistema de consolidação • 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 execução correta do processo com a devida verificação dos return codes. Durante o processo de testes de uma funcionalidade pode ser necessário congelar o trabalho no ambiente de desenvolvimento para garantir a estabilidade dos testes. Isto facilita a correção de possíveis problemas encontrados nos objetos, que seria mais difícil de ser corrigido se o processo de desenvolvimento tivesse continuado no objeto durante os testes. Uma estratégia periódica para a importação dos transportes deverá ser implementada e negociada com as equipes de desenvolvimento. Import all deverão ocorrer mensalmente, semanalmente ou diariamente. Imports mais freqüentes não são recomendados no ambiente R/3. O processo de import deve ser feito durante a baixa atividade do sistema e logo após 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 estratégia de enviar objetos individualmente a medida que vão ficando prontos. João Luiz Barbosa Junho/2000 Página 77 ACADEMIA BASIS CEMIG Advanced Transport Management Transport Directory Os change requests são gerados obedecendo a nomenclatura <source SID>K9nnnnn onde nnnnn é um seqüencial de 5 dígitos controlado pelo sistema source (também conhecido como sistema integrador ou sistema de desenvolvimento e configuração). O file system do diretório de transporte fica montado na área compartilhada /usr/sap/trans de uma das máquinas (normalmente aquela de onde os transportes se originam) e através de NFS, o file system é compartilhado com os demais sistemas que compartilham o mesmo transport group. No ambiente do NT o compartilhamento é feito através do sapmnt que contém, entre outros, o diretório trans. O diretório trans contém os seguintes subdiretórios, entre outros: • actlog, onde são gravados cada action em um request ou task. Contém files com nomes <source SID>Z<6 digits> • sapnames, com arquivos com o nome do usuário 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 contém os dados que foram exportados no transporte. Eventualmente neste diretório podemos ter arquivos no formato D9<5 digits>.<source SID> que também contém dados a serem importados. • cofiles, com command files do tipo K9<5digits>.<source SID> contendo por exemplo os import steps que serão executados • log, com todas as logs de transportes, como por exemplo ULOGs, ALOGs, SLOGs e as demais logs que descrevem as operações executadas nos steps individuais ou coletivos • bin, com os arquivos de configuração do funcionamento do mecanismo de transportes (TPPARAM e DOMAIN.CFG) • tmp, com os arquivos de log que estão sendo gerados durante o processo. Após o término de um transporte os arquivos são movimentados para o diretório LOG. The tp Program O transport control program é uma ferramenta executada a nível de sistema operacional que controla todas as operações 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 operações de export e import separadamente, extraindo/atualizando as informações de controle na base de dados do R/3 e levando para files (buffer, log e cofiles) no diretório de transporte e posteriormente, através de comando explícito, importa os dados no sistema destino. Ele não faz a manipulação dos dados que serão transportados (o responsável por isso é o R3trans que será visto a seguir). Apesar de ser uma ferramenta no sistema operacional (diretório de exe’s), o tp deve ser utilizado através da interface do TMS que efetua as chamadas apropriadas para cada tarefa. Sua utilização é 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 específico • tp go <SID>, checa o database de um sistema destino • tp connect <SID>, checa a conexão • tp showinfo <request>, exibe informações 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 parametrização atual de um sistema • tp status <SID>, exibe o status de serialização 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. João Luiz Barbosa Junho/2000 Página 78 ACADEMIA BASIS CEMIG O comando tp import <request> <SID> client=nnn u0 executa o import de um request específico e o mantém na fila, eqüivalendo ao preliminary import do TMS. Quando se suprime a opção u0 o request é retirado da fila de import. É preciso tomar cuidado com imports individuais para garantir a manutenção da seqüência correta com que os mesmo foram exportados. O import mode incondicional (com especificação da opção u<dígito>) 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 específicos do sistema • u6, sobrescreve objetos em modo unconfirmed • u8, ignora restrições estabelecidas na tabela de classificações • u9, ignora o fato do sistema estar lockado para este tipo de transporte O buffer de um determinado <SID> é manipulado pelos comandos tp específicos, como por exemplo addtobuffer, showbuffer, delfrombuffer, cleanbuffer, setstopmark e delstopmark. Estes comandos manipulam as linhas do arquivo específico de cada sistema existente no subdiretório buffer do diretório 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 atualização dos dados da request em tabelas temporárias no banco de dados do sistema destino. O uso direto do programa R3trans não é suportado e somente utilizado em casos muito especiais. A SAP não 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 são 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 através 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 (é possível verificar isso utilizando o comando tp checimpdp SID). A execução do programa RDDNEWPP efetua este schedule no sistema, embora o sistema normalmente schedula este job automaticamente após um client copy. A verificação do schedule pode ser efetuada pela SM37. O programa RDDIMPDP se baseia em informações passadas pelo programa tp para ativar programas RDD* que efetuam tarefas específicas requisitadas pelo tp. As principais tarefas, a saber, são : mass activation (rddmasgl), convertion and generation (rddgendb) e versioning management (rddversl). The Import Process O processo de import é composto de uma série de steps que executam tarefas distintas e, dependendo do tipo do transporte, são ativados ou não. A organização da fila de import no buffer file é uma espécie de tabela onde para cada entrada referente aos requests, é colocado um flag 0 ou 1 na posição referente a cada step. O programa tp não lê esta fila individualmente, mas sim coletivamente. Desta forma o processo de import ocorre de forma seqüencial não 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 referência a um determinado objeto (por exemplo a segunda corrigindo um erro detectado em uma primeira consolidação) o step de ativação (posterior ao de importação) ocorra João Luiz Barbosa Junho/2000 Página 79 ACADEMIA BASIS CEMIG somente quando a versão correta esteja importada no sistema, evitando desta forma que a versão com erro seja ativada temporariamente como ocorreria se o processo fosse seqüencial por request. Para garantir a consistência do tratamento da fila de import, o programa tp coloca automaticamente um setstopmark na fila no início do processo e a retira no final. Cada operação 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 após a correção 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 (através do parâmetro stoponerror) Os passos durante o import são (os passos com * são genéricos 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 não foi implementada e será utilizada para a importação 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 subdiretório 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 subdiretório log. A comunicação entre o programa tp e os jobs background no sistema se dá através da tabela TRBAT que contém dados temporários. O tp grava nesta tabela os steps que deverão ser executados durante o import e então dispara o evento que ativa o RDDIMPDP. Este programa por sua vez lê a tabela e através das informações recolhidas dispara programas RDD* que efetuam tarefas específicas requisitadas pelo tp. Cada um dos jobs RDDs disparados pelo RDDIMPDP é registrado na tabela TRJOB através de uma entrada onde são gravados seus return codes que desta forma podem ser acompanhados pelo programa tp. As logs geradas pelos programas RDD* são gravadas no subdiretório tmp e posteriormente transferidas para o log pelo programa tp. Qualquer problema detectado pelo tp durante a monitoração das tabelas TRBAT e TRJOB faz com que o tp reative o RDDIMPDP através da emissão de novo evento pelo sapevt. O RDDIMPDP analisa estas tabelas e verifica se o processo anterior ainda está ativo ou se necessário, recomeça o processo no step cancelado. Por este motivo é que pelo menos dois background process precisam estar disponíveis para o sistema de transporte. João Luiz Barbosa Junho/2000 Página 80 ACADEMIA BASIS CEMIG Transport Monitoring Todas as logs do processo de transporte são gravadas no subdiretório de log. São logs criadas pelo tp program (ULOG, SLOGs e ALOG) e pelas demais ferramentas de transporte. A ULOG contém 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 específico. Contém uma visão geral dos imports efetuados indicando os respectivos return codes e consequentemente o sucesso de cada import. O ALOG<YY><WW> contém todos os return codes de cada um dos steps executados nos processos de import efetuados no seu transport group. Além destes arquivos de log, o diretório 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 são consolidados pelo programa tp da seguinte forma: • 0 a 16, indica os valores máximos de todos os return codes das ferramentas • 17 a 99, que é um valor calculado a partir daqueles retornados pelas ferramentas de transporte e são warnings indicando problemas detectados pelo tp, como por exemplo a não permissão de write no diretório buffer • 100 a 149, são warnings indicando que alguma coisa vai mal e nem todas as tarefas puderam ser completadas • 150 a 199, são erros (raros de acontecer) indicando uma operação ilegal solicitada pelo operador • 200 ou mais, indica erros no tp Para obter uma descrição 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 através do Alert Monitor sob a forma de uma estrutura em árvore que pode sofrer drill down. O diretório 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 diretórios de transporte e os arquivos referentes a transportes já executados são 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 não serão mais necessários e se tornaram obsoletos baseados em timestamps definidos pelos parâmetros datalifetime, olddatalifetime, filelifetime e loglifetime do TPPARAM. Antes de efetuar esta operação é recomendado que se efetue uma cópia backup por segurança. João Luiz Barbosa Junho/2000 Página 81 ACADEMIA BASIS CEMIG Client Tools As ferramentas de client copy e client transport foram criadas para executar a transferência de dados entre clients. Estes dados sobrepõem os dados do client destino. As ferramentas de client não foram concebidas para combinar dados de vários clients. Os dados são categorizados como dados de customização, dados mestre de usuário ou ainda application data. Dentre estes somente o mestre de usuários pode ser manipulado mais livremente e combinado com outros de outras fontes. No lado oposto está o application data que não pode ser manipulado de forma alguma sem o correspondente dado de customização. Os mecanismos de cópia permitem a cópia local, remot ou através de transporte. Cada um destes possui uma característica diferente. A cópia local é utilizada para copiar clients dentro da mesma instância e não consegue copiar as customizações client-independents e os objetos de repositório. Já a cópia remota permite faz exatamente a mesma coisa só que entre sistemas R/3 diferentes e utilizando conexões 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 não esteja ativo no momento, e podemos levar todo tipo de customizações. As ferramentas de transferência de dado entre clients são definidas por profiles que definem o escopo dos dados que serão transferidos. Por exemplo: • SAP_ALL, todos os dados do client • SAP_CUST, customizing data • SAP_CUSV, customizing e variantes de relatório • 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 intenção é a criação de um client novo, uma entrada deverá ser criada inicialmente através da transação SCC4. Clients recém criados possuem apenas o user SAP* hard coded (password PASS) e é através dele que efetuaremos a cópia Clients protegidos contra cópia não podem ser sobrescritos. Esta proteção é especificada na SCC4. Por questões de integridade, é recomendado que não se log no client destino durante a cópia. Pela mesma razão é recomendado que não se utilize o client source durante o processo Local Client Copy A cópia local permite a transferência dos dados entre clients de um mesmo sistema R/3 e deve ser disparada estando-se logado no client destino através da transação SCCL, especificando o client source e a profile de cópia. Em uma primeira implementação, a SAP recomenda que se utilize o client 000 como source para o primeiro client Remote Client Copy A cópia remota permite a transferência 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 transação SCC9, especificando o sistema e client source e a profile de cópia. A cópia é exatamente igual a local, apenas que os dados são enviados através de uma conexão RFC. Para garantir o sucesso da cópia, ambos os sistemas deverão possuir a mesma estrutura de database. Qualquer inconsistência causa o término do processo com erro Client Transport Diferentemente do processo de cópia remota, a transferência não é executada por RFC, embora este processo também permita a transferência de dados entre sistemas distintos. O processo consiste de dois steps: no primeiro os dados são exportados para files no sistema operacional e no segundo estes dados são importados para o client destino. João Luiz Barbosa Junho/2000 Página 82 ACADEMIA BASIS CEMIG Diferentemente também dos dois outros processos, é necessário logar no client source e efetuar através da transação SCC8 o export dos dados. Durante este processo é necessário 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. Além 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 através da transação SCC7 que comanda o import. Primeiro deve-se importar os dados client independent e posteriormente os client dependent. Em seguida é necessário se logar no sistema target e executar o Post-process import para efetuar atividades requeridas pelo SAPscript e possíveis steps de geração de objetos ainda pendentes. Copy Process Durante o processo de cópia de client, o sistema inicialmente limpa os dados com a key do client no sistema destino. Number ranges são copiados do cliente source. Se o dado de aplicação não for copiado, o number range será resetado. Não é possível copiar dados de aplicação sem copiar junto os dados de customização e os number ranges. A cópia apenas dos dados de customização pode causar inconsistências no momento do merge no client destino A profile SAP_USER é a única que não possui a opção 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 cópia o logon fica inibido no client target exceto para os users SAP* e DDIC. É ainda recomendado que não se trabalhe no client source durante a cópia. O processo de cópia 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 cópia é visualizada através da transação SCC3 e exibe informações sobre estatísticas das tabelas, informações de controle e informações detalhadas sobre cada tabela copiada e suas interações com os objetos do IMG. Cópias de client pelo processo de client transport são monitoradas através da SE01 (transport organizer) A monitoração do processo de cópia permite, em caso de abend do processo, o restart a partir do ponto em que ocorreu o problema. Esta opção pode ser utilizada após uma análise do problema ocorrido, sendo mais eficiente que a opção de um new start. Objetos do repositório associadas a classe de desenvolvimento local ($TMP) não são copiadas durante o processo de client copy. Client Delete Clients são deletados através da transação SCC5. O processo de cópia poderá inclusive ser agilizado se o client tiver sido anteriormente excluído do ambiente destino. No processo de delete os dados, SAPscripts e batch inputs Client Compare Quando vários sistemas R/3 com clients distintos estão sendo implementados, pode ser necessário comparar e ajustar as customizações entre os diferentes sistemas e clents. A função Compare. Esta função compare permite comparar e ajustar o conteúdo de tabelas ou visões entre dois clients distintos. A transação SCUO é utilizada para selecionar os tipos de objetos que serão comparados e ainda especificar se a comparação será de dados clint dependents ou independents. A saída da comparação é exibida de forma tabular e torna fácil a análise das eventuais diferenças João Luiz Barbosa Junho/2000 Página 83 ACADEMIA BASIS CEMIG Eventuais ajustes poderão ser efetuados através da transação SM30, que permite a manutenção da maioria dos objetos de customização. Objetos que não podem ser ajustados pela SM30 poderão apenas ser comparados. Client Maintenance Settings Além das opções de proteção dos dados client dependent e client independent, a transação SCC4 possui opção para proteger o client contra client copy, através de niveis de proteção 0 (sem proteção), 1 (não pode ser sobrescrito) ou 2 (não pode ser sobrescrito nem acessado externamente para comparação) Authorizations for client tools Para manipular as ferramentas de movimentação e manutenção de clients dispomos dos seguintes objetos de autorização : • 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 cópia • S_DATASET para acessar arquivos do sistema operacional • S_USER_PRO para manter as profiles de cópia • S_USER_GRP para manter os dados mestres de usuários • S_TRANSPRT para manipular o CTO (change and transporte organizer) João Luiz Barbosa Junho/2000 Página 84 ACADEMIA BASIS CEMIG Client and System Strategies Types of Landscapes Uma implementação R/3 pode ser executada de diversas maneiras distintas. As implementações mais comuns são sistemas R/3 em hardware diferentes e os possíveis landscapes são 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 customização e desenvolvimento (CUST), e um client para testes unitários (TEST) • Quality Assurance, contendo um client de consolidação e teste sistêmico (QTST) • Production, contendo um client de produção (PROD) Esta implementação apresenta as seguintes vantagens: • Desenvolvimento, qualidade e produção são implementados em ambientes distintos • Maior segurança dos dados no ambiente de produção • A performance do ambiente de produção não é afetada pelos demais sistemas • Ambiente de teste separado • Consolidação dos transportes antes do envio para a produção A principal desvantagem desta opção é o alto custo do hardware em função da quantidade de máquinas necessárias Two-System Landscapes No landscape com 2 sistemas temos os seguintes ambientes: • Development, contendo um client de customização e desenvolvimento (CUST), um client para testes unitário (TEST) e um client de consolidação e teste sistêmico (QTST) • Production, contendo um client de produção (PROD) Esta implementação apresenta as seguintes vantagens: • Desenvolvimento e produção são implementados em ambientes distintos • Maior segurança dos dados no ambiente de produção • A performance do ambiente de produção não é afetada pelos demais sistemas • Ambiente de teste separado • Administração simplificada em função da diminuição do hardware Esta implementação apresenta as seguintes desvantagens: • Desenvolvimento e qualidade são implementados em um único ambiente, ou seja, um ambiente pode impactar o outro. • Não é possível fazer um teste completo dos objetos do repositório nem customizações client independents antes que sejam transportados para a produção, que age aqui como o ambiente de consolidação • Não é possível consolidar os transportes antes de envia-los para a produção One-System Landscapes No landscape com 1 sistema temos os seguintes clients: • Ambiente único, contendo um client de customização e desenvolvimento (CUST), um client para testes unitários (TEST) , um client de consolidação e teste sistêmico (QTST) e um client de produção (PROD) João Luiz Barbosa Junho/2000 Página 85 ACADEMIA BASIS CEMIG Esta implementação apresenta as seguintes vantagens: • Toda a implementação em apenas um hardware • Menor esforço de administração, sem transporte de objetos do repositório e customizações client independents Esta implementação apresenta as seguintes desvantagens: • Desenvolvimento de objetos e customizações client independent afetam imediatamente o ambiente de produção • Um ambiente impacta todos os outros ambientes tanto em performance, quanto integridade e segurança • Upgrade da produção é realizado sem um teste das funcionalidades • Produção compartilha recursos de hardware com os demais ambientes com conseqüências ruins para a performance Como esta opção é a mais precária e sucetivel a grandes impactos após a entrada em produção ela só é aceitável se os desenvolvimentos parassem antes da entrada em produção. Se for necessário fazer alguma correção no ambiente deve ser feito durante o período sem atividade produtiva. Landscape Requirements É preciso que se tenha uma estratégia consistente para configuração dos sistemas no landscape para proteção dos repositórios e dos transportes consistentes entre os sistemas. Através de uma configuração correta de clients para os ambientes de produção e qualidade, é possível bloquear customizações e desenvolvimentos fora do ambiente reservado para esta finalidade. A estratégia bem montada de distribuição de transportes, através da especificação cuidadosa de rotas de consolidação e distribição, e a definição de um ponto único de alteração do ambiente (client de desenvolvimento) garante assim que todos os clients do landscape tenham configurações consistentes. A configuração correta dos clients na SCC4 poderá proteger produção e qualidade de configurações e desenvolvimento e ao mesmo tempo força a gravação automática em change requests dos esforços de customização e desenvolvimento ABAP. Além disto um bom procedimento e agendamento dos mecanismos de transportes junto com padrões de nomeclatura ajudam a garantir a estabilidade do ambiente. ASAP System Landscape A ASAP recomenda um roteiro passo a passo para configuração de um landscape de 3 sistemas, dentro do ASAP Roadmap, que consolida as experiências tanto da SAP quanto dos seus parceiros de implementação. Passo 1: Após a primeira instalação do sistema no ambiente de Desenvolvimento, utilizar o client 000 para, através de client copy, criar os clients de TEST e CUST. • TEST é configurado como uma produção, com no changes allowed e No changes to repository and client independent customizing. • CUST é configurado para gravação automática de change requests e permissão para alteração do repositório e client independent customizing Passo 2: Estabeleça uma estratégia de manter o CUST sem dados e qualquer teste deverá ser efetuado através do transporte das customizações nele executadas para o client TEST através da transação SCC1. Os transportes gerados no sistema CUST serão liberados para o diretório de transporte Passo 3: Quando chegar a hora de criar o ambiente de consolidação, 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 estarão protegidos através das opções No changes allowed e No changes to Repository and client independent customizing. João Luiz Barbosa Junho/2000 Página 86 ACADEMIA BASIS CEMIG Passo 4: Os transportes liberados no ambiente CUST e que se encontram na fila de import deverão ser importados para a o client QTST. Através da SCC1 os change requests poderão 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 produção e, a partir do client 000, faça 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 consolidação na QTST e eventualmente transferido através da SCC1 para a TRNG. Changes consolidadas serão finalmente importadas no ambiente de produção. ASAP Recomendations As change requestes e seus históricos deverão estar muito bem documentadas no ambiente e nenhuma alteração pode ser feita sem estar contida em uma change request. Documente o que contém a request, o que é resolvido, quem fez a alteração e quando foi transportada para cada um dos ambientes. Tenha estabelecido desde o início critérios bem definidos para regulamentar as change e seus transportes entre as instâncias 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 customização. Evite fazer upgrade durante o processo de desenvolvimento. Se for impossível, tenha certeza que requests geradas em uma versão/nível de hot package só serão transportadas para um ambiente com a mesma versão/nível de hot package. Alternative Landscapes Alternativamente, apenas o client CUST poderá ser criado inicialmente com as opções de geração 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 geração automática de change requests, uma vez que a única forma de sincronizar os dados client independents daqui para a frente será através da movimentação dos changes via SCC1. A criação do client de qualidade (QTST) é feita através de um client export/import, assim como o produção. A principal vantagem deste método alternativo é que a geração de transportes somente precisa ser ativada e gerenciada quando acrescentamos um segundo client no landscape. A desvantagem é que não possuiremos o histórico completo das change e, principalmente, quando do momento dos client export dados de customização ainda não totalmente consolidados estarão sendo movimentados para os demais ambientes. Além disto devemos ter cuidado em relação a objetos do repositório pois eles não estarão presentes na cópia do client. Para solucionar isto temos que ter todos os objetos alterados documentados para ser possível gerar uma request que deverá ser transportada antes do client import. Uma terceira opção é a criação dos ambientes de QAS e PRD a partir de homogeneous system copy, embora esta estratégia não seja recomendada pela SAP. As principais desvantagens estão associadas a falta de controle das request e a eventual presença de configurações e desenvolvimentos não acabados no ambiente produtivo. Através da configuração do TMS e suas rotas de consolidação e distribuição é possível definir os mais complexos cenários que possamos necessitar na instalação. As rotas de distribuição (delivery) podem ser paralelas para várias instâncias ou ainda em cascata, dependendo da configuração TMS. Uma implementação Phased Development é necessária em algumas situações especiais, como por exemplo em um upgrade ou implementação de novo módulo SAP. Neste caso, as customizações efetuadas no seu ambiente de produção precisarão ser replicadas manualmente para o ambiente original para manter a integridade do sistema. João Luiz Barbosa Junho/2000 Página 87 ACADEMIA BASIS CEMIG É possível ainda manter um cenário de desenvolvimento multi-layered com vários ambientes de integração com suas próprias rotas de consolidação e distribuição. A maior dificuldade neste cenário é a manipulação das customizações que não possuem o conceito de “proprietário”. O desenvolvimento é mais simples de gerenciar através da criação de classes de desenvolvimento distintas. Transport Organizer O Transport Organizer (SE01) é uma ferramenta que fornece soluções para a manipulação de cenários mais complexos que não podem ser gerenciados pelas ferramentas normalmente utilizadas. As funções de transportes e realocações permite transportar cópias de objetos ou realocações de originais. É possível manipular Object Lists, que são coleções de objetos que poderão servir para template da função Include Object List conseguindo desta forma incluir object lists em change requests. João Luiz Barbosa Junho/2000 Página 88 ACADEMIA BASIS CEMIG R/3 Upgrades and OCS Patches R/3 Evolution and Release Strategy Um sistema R/3 típico, uma vez instalado, passa por evoluções sejam devido a customizações ou novos desenvolvimentos, como também pela aplicação 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 são enviados para os clientes apenas sob demanda (3.1G e 4.0A, por exemplo) • Correction Releases, trazem apenas correções e são enviadas automaticamente para todos os clientes. Estes são os releases recomendados para serem instalados em produção, já que possuem suporte total do OCS (3.1H ou 4.0B, por exemplo) R/3 Upgrade Em um típico landscape de 3 sistemas, cada ambiente (partindo do desenvolvimento) passa por uma seqüência de transportes standard. São tarefas tais como customizações, patches, e ajustes no sistema. Estas alterações são executadas no ambiente de desenvolvimento e transportadas para os demais ambientes. Uma das tarefas mais importantes durante a preparação para o upgrade é rodar o script PREPARE (integrante da ferramenta retrofit que integra a localização que existia na versão 3.0 com o correspondente standard que vem na versão 4.0) e que é responsável por fazer uma série de checks, a saber : • Quais são as versões do banco de dados, do sistema operacional, e do R/3 • Quais abaps precisão ser realterados • Existe espaço suficiente no banco de dados • Existe alguma reparação em andamento • Quais são as línguas suportadas • Qual é o nível de hot package e se todos estão confirmados • usuário tem as devidas permissões no sistema operacional Após todo este processo o prepare gera um arquivo chamado \usr\sap\put\log\checks.log) no sistema com as ações necessárias para viabilizar o upgrade. A execução deste script não faz parte do upgrade em si que é feito utilizando o programa R3up que tem funcionamento semelhante ao R3setup que é utilizado na instalação. Durante o processo de upgrade, são efetuadas alterações de ajuste usando as transações SPDD e SPAU. O processo de upgrade passa por passos que são efetuados com o sistema ativo ainda no release antigo, a retirada do sistema para que o dicionário 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 execução 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 transferência para o repositório do R/3 dos novos objetos enviados em um CD. Este processo passa pela comparação dos objetos para identificar possíveis modifications efetuadas pelo usuário nos objetos SAP standard. Todas as modificações que o cliente desejar manter e cujos objetos SAP no novo release também foram alterados, precisam ser casados com os objetos SAP. Este processo é executado através das transações SPDD e SPAU e é conhecido como Modification Adjustment. Existem diversos tipos de modification adjustment que são executados antes (através da SPDD) e depois (através da SPAU) da fase do Data Dictionary Activation. Durante esta fase de activation o sistema é desativado, que pode durar várias horas. Após esta fase o sistema é reativado já no novo release. João Luiz Barbosa Junho/2000 Página 89 ACADEMIA BASIS CEMIG Repository Switch O coração de um processo de upgrade é o Repository switch. Inicialmente um repositório inteiro na nova versão é colocado no sistema e permanece inativo. Este processo requer uma área adicional em disco que somente será liberada quando o novo repositório for ativado e o antigo deletado. Para preservar as modifications introduzidas pelo usuário, durante o processo de switch do repositório as alterações introduzidas pelo usuário são transferidas para o novo repositório através da modificação dos correspondentes objetos SAP do novo release. A fase de modification adjustment somente será necessário quando o objeto alterado pelo cliente também foi modificado pela SAP (senão ele será movido integralmente) e quando questionado, o cliente decide continuar com suas alterações por achar que o novo release não incorpora devidamente suas necessidades. Caso o cliente aceite o novo objeto, suas antigas alterações serão descartadas. No processo de preparação do repository switch acontecem as seguintes operações: • Transfere para o novo repositório modifications introduzidas pelo cliente cujos objetos SAP não sofreram mudança no novo release • Salva no version database todas as modifications que foram efetuadas em objetos que sofreram mudança no novo release. Isto permitirá efetuar os ajustes posteriormente • Copia os objetos que foram gerados através do processo de customizing para o novo repositório • Transfere para o novo repositório todas as documentações, versões inativas de objetos e desenvolvimentos executados pelo cliente, além dos objetos locais Uma vez que as operações acima foram efetuadas, o repository switch poderá ser efetuado. Caso não existam objetos que necessitam de adjustment, o switch é uma simples questão de reativar o novo repositório. É simples e rápido, sendo portanto sempre desejável que os objetos SAP permaneçam o mais standard possível. Switch log during repository upgrade Durante o processo de upgrade podemos escolher três estratégias diferentes para o uso da log de alteração. Independente de cada uma destas estratégias é evidente que devemos ter backup full offline de cada ponto do processo para que em caso de pane ou necessidade de retorno a situação anterior tenhamos backup para retornar a situação anterior. As principais fases do upgrade são : • Inicialização do processo • Importe do repositório • Análise e copia dos novos objetos • Switch, ativação do novo dicionário e ajuste dos objetos impactados • Importe dos dados de controle • Importe da lingua portuguesa • Fase final e backup após todo o processo As estratégias disponíveis para o upgrade são : • A_OFF: neste caso durante todo o processo não 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 opção é a não 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 ativação do novo dicionário. O consumo de disco é menor que na opção A_ON mais ainda é considerável. O downtime também é pequeno mas é seguido de um backup offline. João Luiz Barbosa Junho/2000 Página 90 ACADEMIA BASIS CEMIG Ou seja, ela possui um pouca do lado bom das outras duas e é por isto que esta opção é a recomendada pela SAP e já é o default. Modification Adjustment O processo de modification adjustment consiste na transferência para os novos objetos SAP das modifications introduzidas pelo usuário no release anterior. A transação SPDD é utilizada para efetuar esta transferência em certos objetos do dicionário ABAP, tais como domains, data elements, table structures, transparent tables, pooled tables, cluster tables e table technical settings. A não execução desta tarefa causaria a perda de dados Após a ativação do novo dicionário, a transação SPAU é utilizada para ajustar alguns objetos que se não ajustados não causariam perda de dados, apenas perda de funcionalidade. Estes objetos seriam objetos de lock, matchcodes e views, além de objetos do repositório, tais como ABAP programs, function modules, menus, screens ou module pools Ao término da execução destas duas tasks (SPDD e SPAU), todas as modifications estarão 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 necessitarão de passar pelas SPDD e SPAU, podendo desta forma haver um melhor planejamento do esforço a ser gasto no processo. O processo de modification adjustment executa um comparação entre as duas versões do objeto. Para cada objeto, as transações SPDD e SPAU guiam o usuário através dos processos de ajuste, oferecendo ainda a opção de aceitar a nova versão ou executar os ajustes necessários. Estes ajustes, quando efetuados, serão 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 aplicação destes transports. Este procedimento de transporte é simples e poupa esforços de efetuar os adjustments em cada ambiente, porém somente é possível apenas se todos os sistemas do ambiente estiverem nos mesmos níveis de modification no momento dos upgrades. Um landscape bem planejado e bem gerenciado torna este processo viável e diminui sensivelmente os esforços no upgrade. Em relação as responsabilidades do processo de upgrade, temos que ter em mente que os administradores do sistema são responsáveis pelo upgrade mas os times funcionais e de abap são responsáveis pelos ajustes e testes das funcionalidades que serão 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 possível. Além de demandarem mais esforços durante upgrades, estas alterações no standard core do R/3 podem introduzir erros graves no ambiente R/3. Dependendo do nível destas modificações e seus reflexos no negócio da empresa, um processo de upgrade poderá ser difícil, demorado ou até mesmo impossível de ser implementado em versões mais recentes do R/3. Em substituição às modifications, a SAP disponibiliza o conceito de enhancements, através da utilização de user exits e appended structures que tornam o processo de upgrade totalmente transparente para a instalação O conceito de user exits consiste na introdução em determinados pontos mais susceptíveis a modifications dos objetos SAP de chamadas a rotinas externas que podem ser desenvolvidas pelo cliente em sua instalação. Novos releases trarão estas chamadas nos mesmos pontos não necessitando o cliente de efetuar nenhuma alteração no novo objeto. Os objetos que possuem exit são: • Program exits, que permitem includes no código através de chamadas externas João Luiz Barbosa Junho/2000 Página 91 ACADEMIA • • • BASIS CEMIG Menu exits, podendo o cliente introduzir novas opções no menu Screen exits, que são telas adicionais Field exits, que são programas ou function modules conectados a um campo de tela para executar funções por exemplo de consistência personalizada de preenchimento. Ao contrário dos demais tipos de exits, field exits não precisam ser criadas para um determinado campo, podendo o cliente decidir pela sua colocação em qualquer campo. As append structures permite que se acrescente campos em tabelas SAP sem a necessidade de alteração dos objetos standard do sistema. Os campos incluídos ocupam fisicamente uma outra área e apenas serão incorporados a nova versão do objeto no novo release. Estas estruturas deverão possuir nomes no customer range (Z) para evitar que sejam sobrescritas no momento do upgrade. A inclusão destas estruturas entretando não são permitidas a pool tables, cluster tables ou tables que possuam campos LONG RAW. Online Correction Service (OCS) O OCS oferece patches para correção de um sistema R/3 através da disponibilização de Hot Packages, LCPs, SPAM updates e Conflit Resolution Transport (CRTs). Estes patches reduzem a necessidade de correções manuais no sistema através da aplicação de notas que, diferentemente destas correções, não serão reconhecidas por um processo de upgrade como modifications. É portanto extremamente aconselhável que um sistema R/3 esteja up to date no momento de um upgrade para minimizar a necessidade de análise de modifications que não passam de notas aplicadas. Os tipos de patches na versão 4.0 são : • Hot Packages são grupos de vários patches e devem ser aplicados na ordem em que são disponibilizados pela SAP. Tecnicamente durante a sua aplicação requerem modification adjustments através da transação SPAU. • LCPs ou Legal Change Patches, são os Hot Packages para o ambiente HR • SPAM update é uma atualização para a transação SPAM (utilizada durante a aplicação 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 disponíveis para download no sapnet (ou através de download via OSS a partir da SPAM). Para simplificar a sua implementação, 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 (transação SPAM) é a ferramenta utilizada para aplicar os patches no ambiente R/3 e deverá ser executada no client 000 por um usuário que possua todos os privilégios (SAP_ALL) porém não deverá ser o DDIC ou o SAP*. A SPAM força a aplicação dos patches na ordem correta e obriga a um aceite em cada aplicação antes de aceitar a seguinte, forçando desta forma a uma verificação da aplicação pelo cliente. O processo de aplicação dos patches deve ser efetuado em todos os sistemas do landscape. Caso se efetuem adjustments pela SPAU durante a aplicação, os mesmos poderão ser salvos em change requests para posterior import nos demais sistemas, evitando a utilização da SPAU mais de uma vez. Ao longo da utilização e conseqüente identificação de problemas nas funcionalidades do sistema, pode ser necessário aplicar manualmente no R/3 correções disponibilizadas em notas no OSS. Estas notas (porém nem todas) serão posteriormente agrupadas em Hot Packages. Qualquer nota deverá ser muito bem avaliada antes de sua aplicação. João Luiz Barbosa Junho/2000 Página 92 ACADEMIA BASIS CEMIG Terceira Semana R/3 Spool and Print As definições de impressora são 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 transações deste capítulo são SP01 e SPAD. R/3 Spool System O R/3 possui diferentes formas de enviar documentos através de seus sistemas de spool. Um documento formatado, que pode ser uma impressão, um fax ou um EDI, representa uma message no sistema R/3 e, uma vez criada, estará liberada para impressão ou transmissão. As impressões no R/3 podem ser imediatas ou adiadas para saída posterior. Além do message control, o R/3 possui uma combinação de programas de impressão e SAPScripts para produzir os documentos de impressão. Enquanto o programa de impressão obtém 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. Através deste princípio o R/3 formata os documentos e requisita ao spool do sistema operacional que apenas repassa o documento para o dispositivo físico de impressão que está alocado na porta paralela ou serial. Spool and Output Requests Um spool request é criado quando um documento R/3 é requisitado para impressão mas ainda não foi enviado para o dispositivo de saída. Os dados ficam armazenados em um formato genérico interno do R/3. Um spool request é formatado pelo spool work process e passa a ter um determinado formato para um dispositivo específico, este formato nos chamamos de output request. Vários output requests podem ser gerados a partir de um único spool request, contendo cada um os atributos ou comandos específicos de um determinado hardware de impressão. Os spool requests gerados ficam armazenados em um repositório denominado Temporary Sequential Database, ou TemSe. Este repositório poderá estar no banco de dados do R/3 ou em arquivos do global directory do sistema operacional (determinado pelo parâmetro de profile rspo/store_location = db ou G e direcionado pelo parâmetro rspo/files/root/G = $(DIR_GLOBAL) ). Os output requests são armazenados apenas como registros de controle. Os formatos de impressão uma vez gerados são repassados diretamente para o gerenciador de impressão do sistema operacional sem serem armazenados na base de dados. Spool Work Process Quando uma requisição de impressão de um spool request é efetuada, um output request específico 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 endereçado. Para formatar corretamente a saída, além do driver específico do dispositivo o R/3 utiliza informações referentes ao character set utilizado e comandos específicos do dispositivo para formatação dos dados. Local and Remote Printing Os output requests formatados são repassados para os dispositivos através de strings de impressão. Quando se utiliza o método Local, os dados são repassados diretamente para o spooler João Luiz Barbosa Junho/2000 Página 93 ACADEMIA BASIS CEMIG do sistema operacional da máquina onde o spool work process que cuida de envia-los, seja para uma impressora conectada diretamente ao host ou através da rede. É o método mais rápido, uma vez que a tarefa de gerenciamento do string até o dispositivo de saída 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 impressão e possui uma impressora ligada fisicamente pois isto vai consumir recurso do sistema operacional. Existem cinco métodos de acessos, a saber : • L, utilizado onde o output request é passado para o gerenciador de impressão do sistema operacional (do tipo line command). O mais comum é ser utilizado no ambiente unix mas também pode ser utilizado no ambiente Windows NT. Os comandos a serem utilizados para imprimir e para verificar a fila podem ser redefinidos através dos parametros rspo/host_spool/print e rspo/host_spool/query, respectivamente • C, utilizado onde o output request é passado para o gerenciador através de call a bibliotecas específicas 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 impressão no front-end e quem formata o output device é o dialog work process Remote printing consiste na transferência dos output requests diretamente para os dispositivos remotos. Neste caso o spool work process fica responsável pela negociação com o dispositivo através da rede. Este método de acesso remoto é menos otimizado por onerar o work process gerando possíveis contenções na impressão. O spool work process fica preso até que ele consiga passar todas as informações 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 impressão física seja feita. A transmissão remota é feita através de lpd (line printer daemon) e a SAP provê o programa SAPLPD para as plataformas que não possuem este protocolo standard. Devemos utilizar este método somente quando a rede for muito rápida e muito confiável. Os métodos de acesso são : • U para os ambientes baseados no unix e impressoras de rede • S para ambientes windows 9x com saplpd Spool Administration A transação SPAD é utilizada no R/3 para a administração de spool. As impressoras (output devices) são definidas especificando o método de acesso (local – L ou C - ou remoto – U ou S para unix e windows respectivamente ) e suas características (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 versão básica da SPAD podemos definir output devices, spool servers, access methods e destination hosts. Podemos também verificar a instalação, deletar spools antigos, verificar a TemSe e acionar SP01. Frontend Printing A impressão frontend no R/3 permite que usuários enviem output requests para impressoras que não foram definidas como output devices no R/3. É o denominado método de acesso F. Caso a estação do usuário seja um PC windows, o request é enviado para um SAPLPD rodando na estação do usuários. Se o SAPLPD não estiver rodando, ele é iniciado e manipula os requests e os envia para a impressora default do usuário. Neste método de acesso o processamento do spool é efetuado pelos próprios dialog work processes, não havendo necessidade de encaminhar o request para os spool work processes. Para definir uma impressora frontend para as estações windows, além de especificar o método de acesso F, é necessário definir o device type SWIN (qualquer impressora com device instalado no windows) e o host printer deverá ser “__DEFAULT”. Este método deverá ser evitado em sistemas produtivos por utilizar os work processes para tarefas que deveriam estar reservadas para os spool work processes além de prender o dialog work process até que todos os dados da impressão sejam passados para a estação onde está o frontend e o saplpd. João Luiz Barbosa Junho/2000 Página 94 ACADEMIA BASIS CEMIG Logical Spool Servers Logical spool server é uma camada que permite mapear spools lógicos para físicos, permitindo efetuar o switch dinâmico e balanceamento dos servidores. Um real spool server no ambiente R/3 é uma instância com pelo menos um spool work processes definido. Este mecanismo de definição lógica permite efetuar o switch facilmente entre servers reais que estão indisponíveis sem interrupção do serviço de impressão para os usuários. Como estas definições são configurações do ambiente e portanto podemos utilizar o mecanismo de transportes de change requests do R/3 é possível definir toda uma arquitetura de impressão 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 transação SP01 é o spool request viewer, que permite aos usuários ver seus requests e requisitar outputs ou eliminar spools. Administradores com autorizações apropriadas podem ver todo o spool request do ambiente. A transação SPAD ou o programa RSPO0043 pode ser utilizado para checar a consistência entre os spool requests, output requests e output datas são consistentes cada um por si e as referencias cruzadas entre eles. A verificação de problemas associados com os spool requests pode ser efetuada tanto pela SP01 quanto pela SM21 ou ST22. Existem objetos de autorização específicos para diversas operações de spool no R/3, seja protegendo determinados dispositivos de saída (S_SPO_DEV) ou limitando o poder de gerenciamento (S_SPO_ACT e S_ADMI_FCD) . O objeto S_SPO_PAGE limita o número máximo de páginas que um usuário pode imprimir em um determinado dispositivo. Para que esta autorização tenha efeito é necessário ativar o parâmetro de profile rspo/auth/pagelimit=1. João Luiz Barbosa Junho/2000 Página 95 ACADEMIA BASIS CEMIG R/3 Output Management Através da opção de administração estendida na SPAD, uma série de funções avançadas podem ser escolhidas tais como : definição 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 saída que podem ser referenciados através de um único nome. Device pools são definidos especificando método de acesso P e a lista dos dispositivos que o compõem. Output requests podem ser enviados para todos os dispositivos que compõem o pool simultaneamente ou pode-se requisitar que o sistema efetue o balanceamento de carga entre os dispositivos de saída da lista. Os dispositivos que compõem 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 impressão 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 impressão que podem se fazer necessários em ambientes complexos. Esta comunicação é efetuada através do XOM-API. Através da definição de um objeto real de OMS (ROMS) e de pelo menos um objeto lógico OMS (LOMS), os spool requests de um sistema R/3 podem ser passados para o sistema externo. Os devices no ambiente R/3 que serão gerenciados pelo sistema externo OMS são definidos com o método de acesso E. Spool Server and Requests Management Qualquer instância R/3 que possui spool work processes é denominada um spool server. O R/3 permite a definição 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 impressão. 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 incompatível. Os requests enviados para um determinado spool server caem em uma fila de spool e são processados sequencialmente. Quando o server possui mais de um spool work process, os requests são 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 opção de sequential request procesing, os output request para o dispositivos serão serializados. Esta definição pode causar impacto em todo o sistema de impressão, já que durante a presença de requests para o device, um determinado spool work process fica reservado para processar a fila do device que possui a característica de processar os requests sequencialmente. Para permitir que os usuários acompanhem o andamento de seus requests, os spool work process questionam os devices sobre o sucesso das operações. Uma vez que durante este tracking o spool permanece aguardando uma resposta, isto pode ser particularmente problemático para impressoras remotas ou com baixa performance na rede. Esta opção pode ser desabilitada para um dispositivo de saída especificando a opção no longer ask for print requests in host spool. Ao se especificar o atributo monitoring using monitoring infrastructure, o device pode ser monitorado atrvés da árvore de MTEs do CCMS. Além das opções da jenela de manutenção do device temos ainda os parametros para controle de time-out e retries (rspo/tcp*). João Luiz Barbosa Junho/2000 Página 96 ACADEMIA BASIS CEMIG Non-Standard Printers Quando um determinado dispositivo de saída não possui device padrão no R/3, é possível criar um driver personalizado para o dispositivo através da especificação de alguns objetos. A transação 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á não existe disponível o novo driver para ser baixado do sapservX. Se for necessário criar realmente um novo driver cópie um já existente e altere o que for necessário, sempre tentando manter o mais próximo do standard possível (user references flag) Character set O character set especifica os códigos internos armazenados no spool request e seus respectivos ASCII que serão impressos. É um de para. Cada caracter tem um código interno no R/3 (nenhuma relação com o ASCII), cuja lista pode ser visualizada através da SPAD (Full Administration à SAP characters). É possível acrescentar caracteres nesta lista, utilizando os códigos 9000 a 9999. Cada tabela de character set disponível transcreve este código interno R/3 para um determinado ASCII. Para adapter uma determinada tabela, é necessário inicialmente copia-la e então efetuar as alterações na cópia e salvando posteriormente as alterações em um character set identificado por 9nnn (começa por 9) Format, Page format e Format actions Format identifica o papel utilizado pelo R/3 (letter, A4, etc.). Quando utilizamos formulários que não são padrões é necessário 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 número de linhas por página, entre outros dados. Para definir format actions, ou seja, como determinado dispositivo manipula um determinado formato de impressão, é necessário editar o dispositivo de saída e acrescentar na sua opção de format as sequencias de caracteres para efetuar as operações de impressão (printer initialization, new line, skip page, 12 char/inch, etc.) Print controls Os print controls determinam como um determinado dispositivo efetua determinadas operações, como por exemplo imprimir em bold. Print controls são específicos de cada device e durante a formatação são convertidos para determinadas sequencias de caracteres. A sequencia correta deve ser obtida no manual da impressora, após ter certeza que a SAP não disponibilizou driver para este device. Message Control and EDI O message control é utilizado no R/3 para troca de informações entre parceiros envolvidos em uma determinada regra de negócio. Os documentos gerados (EDI, fax, impressões, etc.) são normalmente gerados através de exits específicas dentro programas R/3 que são chamadas para formatar a saída desejada. Dependendo da customização efetuada, o documento gerado é enviado como parte da transação ou fica pendente para posterior envio. O EDI, Electronic Data Interchange, é a troca de mensagens de negócio entre dois sistemas através de interfaces standard. A SAP não 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 são transferidos através de RFCs entre os sistemas envolvidos. João Luiz Barbosa Junho/2000 Página 97 ACADEMIA BASIS CEMIG SAPconnect O SAPconnect é uma camada que permite a comunicação do R/3 com outros sistemas externos, tipo fax ou mail servers. A conexão do R/3 com sistemas externos normalmente requer a especificação de interfaces externas, porém a conexão 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 transação SC0T. Para maiores informações sobre o SapConnect utilize as notas 34705 e 92950. João Luiz Barbosa Junho/2000 Página 98 ACADEMIA BASIS CEMIG Installation Check Hardware e Software Antes de começar uma instalação é necessário garantir que os requisitos mínimos do checklist de instalação sejam atendidos. No pacote de instalação 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, além de verificar ainda o número de processadores, memória RAM e disco disponíveis. Para o software, verificar se a versão do sistema operacional se encontra atualizada e é suportada pelo R/3, checar os utilitários make do compilador C e a configuração do kernel. Na camada de rede, checar a configuração TCP/IP, o hostname em minuscula e com até 8 dígitos. A estrutura de rede deverá prover IP fixo para os hosts dedicados ao R/3 e uma boa proteção de segurança. Quando se usam mais de um servidores é interessante ainda ter uma rede privada de conexão entre eles de alta capacidade para garantir velocidade na comunicação dos application com a central instance, além do compartilhamento das máquinas que compõem o landscape.Para maiores detalhes veja a nota 23538. O sizing do hardware normalmente é especificado pelos fabricantes baseado nas recomendações da SAP e de suas próprias configurações. Além disto é necessário garantir uma boa distribuição de discos além de uma proteção poe espelhamento e sistemática de backup do sistema operacional. Oracle Database A versão do banco de dados deverá ser compatível com R/3 e com o sistema operacional. O database name será o mesmo system id do R/3. Alterações posteriores no nome do database não são simples de serem efetuadas. Para garantir a comunicação entre os processos através da rede, as profiles Oracle referentes a configurações de network são requeridas: listener.ora, tnsnames.ora, sqlnet.ora e protocol.ora. O oracle será instalado em uma configuração própria de sua árvore de diretórios e diversas variáveis de ambiente são setadas para apontar para os caminhos corretos. A distribuição dos discos no ambiente de banco de dados tem influência 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. Além disto e havendo disponibilidade, distribua os tablespaces PSAPSTABD e PSAPBTABD em filesystem únicos. Filesystems críticos (online redo logs, archive, paginação do OS) não 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 influência direta sobre a performance. Após a instalação, por questões de segurança, a password dos contas oracle SYS, SYSTEM e SAPR3 deverão ser alteradas. Durante a instalação do Oracle serão gerados alguns arquivos importantes, a saber : • %oracle_home%\net80\database • initSID.ora – contém todas as informações da instância oracle • initSID.sap – contém todas as informações para permitir o backup da instância oracle • initSID.dba – contém todas as informações para o SAPDBA conseguir administrar o oracle • %oracle_home%\net80\admin • listener.ora – que contém informações para o listener (no lado do servidor do banco de dados) saber onde encontrar uma determinada instância • tnsnames.ora – contém os parâmetros para um processo cliente do oracle (que não está no servidor do banco de dados) conseguir conectar com uma instância • sqlnet.ora – contém informações administrativas para os processos clientes do oracle • protocol.ora – contém o switch para o tcp.nodelay (opcional) João Luiz Barbosa Junho/2000 Página 99 ACADEMIA BASIS CEMIG A estrutura de diretório do oracle é baseada em duas variáveis. O oracle_home normalmente é o \orant e o sapdata_home normalmente é o \oracle\SID. Além destas variáveis temos que diferenciar as árvores do lado oracle server e do lado oracle. A estrutura básica 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 instância R/3 deverá ser única no landscape e é composto de 3 caracteres alfanuméricos, sendo o primeiro alfabético. Alguns nomes são reservados, devendo ser escolhidos cuidadosamente, já que qualquer alteração exigirá a reinstalação do R/3. Alguns parâmetros do kernel Unix são relevantes para a instalação e funcionamento do R/3. Verifique a sua configuração e efetue as alterações necessárias de acordo com o manual de instalação OS Dependencies. O programa memlimits disponibilizado no CD de instalação pode ser utilizado para checar alguns destes parâmetros. A instalação do R/3 deverá ser executada em uma máquina que não deve possuir outro serviço como pdc, bdc, etc. A estrutura de diretório a ser utilizada já é pré determinada pela SAP. Esta árvore contém dois ramos básicos, os diretórios globais que serão compartilhados entre sistemas e os diretórios locais da instância, 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 instância R/3 possui um número (2 dígitos) informado pelo administrador no momento da instalação e será utilizado pelo R/3 para compor os números das portas para diversos serviços João Luiz Barbosa Junho/2000 Página 100 ACADEMIA BASIS CEMIG TCP/IP que serão utilizados pelos processos. Estes serviços serão registrados pelo programa de instalação no %windir%\system32\drivers\etc\Services do host: • Porta para o dispatcher da instância: sapdpnn 32nn/tcp • Porta para o serviço de gateway: sapgwnn 33nn/tcp • Porta para o message server: sapms<SID> 36nn/tcp Os gateways 97, 98 e 99 além do dispatcher 99 são 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 informações 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 vários sistemas R/3 que o compõem. Cada transport domain possuirá um suas rotas de transporte e um dos sistemas receberá atribuição de domain controller. Se por questões de performance, os frontend não deverão se conectar ao host do database, utilizando para isto application servers. Se o message server for instalado em outro host que não o do database, a DEFAULT.PFL deverá informar esta nova configuração através dos parâmetros SAPDBHOST e rdisp/mshost. Após a instalação, a transação SICK (ou SM28) é utilizada para efetuar um check completo de consistências entre versões do kernel e database, garantindo assim que não existirão inconsistências na instalação. Além disso é bom configurarmos o saprouter, importarmos os hotpackages através da SPAM e a linguagem portugues através da SMLG. Quando se utilizam vários application servers, é necessário garantir a sincronização correta do buffer através de parâmetro da instance profile (sendon,exeauto). Configure corretamente o mecanismo para backup do ambiente, seja do database como também do sistema operacional e diretórios do R/3 e faça o backup de tudo. João Luiz Barbosa Junho/2000 Página 101 ACADEMIA BASIS CEMIG R/3 Workload Distribution Overview A ferramenta de instalação R3SETUP é utilizada tanto para a criação 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 serviços. Através da definição de operation modes podemos distribuir os work processes (dialog, background, update) entre os diversos servidores que compõem um sistema R/3. Os work processes de spool são distribuídos através da definição das profiles pela RZ10. Uma vez que o usuário se logou a um determinado servidor do sistema, todos os seus dialog steps são despachados dentro daquela mesma instância até o próximo logon. Já as suas requisições de serviços de spool, update e background poderão ser atendidos por qualquer um dos servidores distribuídos na rede. Mechanism Cada instância R/3 possui seu próprio dispatcher e sua própria queue de requisições organizada de forma FIFO – first in first out, mantida na shared memory da instância. Qualquer chamada de serviço (outbound request) que não seja uma comunicação 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 instância não possuir work process para atender. A fila do dispatcher pode ser visualizada através do programa dpmon (nível do sistema operacional) ou da transação 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 vários work processes. O tamanho default para cada uma destas filas é 2.000. Caso a instância não possua um determinado serviço (por exemplo UP2), sua fila terá um tamanho de 5 requests apenas. O tamanho da fila do dispatcher é mantida através do parâmetro de profile rdisp/elem_per_queue. Caso ocorra um overflow na queue, será gerada uma mensagem na SYSLOG. A monitoração das filas pode ser executada através da SM51, selecionando um servidor e requisitando Goto -> Queue information Para comparar a distribuição de carga entre os diversos servidores, a transação ST03. Através do Detail analysis menu é possível inclusive requisitar que as comparações sejam exibidas em modo gráfico: Compare all servers -> Graphics -> Avg response time/Dialog steps. Uma análise do CPU time dos work process pela SM50 permite efetuar uma análise para cada tipo de serviço se o número de work process foi definido suficientemente. Como a distribuição dos serviços pelo dispatcher é feita de forma sequencial, os últimos work processes de um determinado tipo com valores elevados de CPU indicam ocupação constante e portanto uma possível espera excessiva de processos na queue deste tipo de work process. O incremento do número de work process, antes de ser feito, precisa ser analisado visando identificar se o recurso de hardware (principalmente memória mas sem esquecer a cpu) disponível na instância comporta mais work process. Evite o logon de usuários na central instance para evitar sobrecarga, já que normalmente esta instância estará oferendo os serviços de DB. Distribua os logons de usuários entre as instâncias de dialog e faça o mesmo com a carga de spool e background. Logon Load Balancing O logon load balancing é utilizado para dinamicamente distribuir os usuários entre os diversos servidores de um sistema. Isto trás uma série de benefícios: • Caso um server caia, os usuários poderão continuar a se logar nos outros servers do sistema sem a necessidade de reconfiguração do saplogon João Luiz Barbosa Junho/2000 Página 102 ACADEMIA • • BASIS CEMIG Possibilidade de agrupar usuários de áreas afins em servidores específicos com isto otimizando a utilização dos buffers das instâncias que somente conterão dados e programas relacionados com aqueles usuários Utilização racional de code pages específicas quando houver necessidade deste tipo de configuração (por exemplo japanese) Para termos isto precisamos categorizar os usuários em grupos e configurar os frontends para um logon específico em um grupo específico e não mais um servidor específico. A conexão neste caso é feita com o message server (serviço sapmsSID 36##/tcp) e não mais diretamente com os dispatcher (serviço sapdp## 32##/tcp) O dispatcher inicialmente procurar avaliar entre os servidores disponíveis no grupo aquele mais indicado para receber a conexão de logon e aí então encaminha o usuário para o dispatcher selecionado. O programa RSRZLLG0 é utilizado para efetuar o balance baseado em critérios como tempo de resposta e número de usuários logados em cada server. Este programa roda a cada 5 minutos ou a cada 4 usuários que se logam e determina o server favorito para o logon a cada instante. Este balanceamento é baseado em pesos que são dados aos itens. A nota 51789 descreve o critério 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 usuários. A transação SMLG pode ser utilizada para monitorar a lista global dos usuários logados (Goto -> User list), a distribuição 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, não adianta colocar todos os servidores em todos os grupos pois estariamos prejudicando os buffers. Devemos sempre monitorar e procurar um ponto de equilibrio. Preferencialmente faça 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 usuário entre em um ou mais grupos. Background Load Balancing A tabela TBTCS exibe informações sobre os jobs schedulados no ambiente. Esta tabela é utilizada pelo batch scheduler para enfilerar os jobs. Através da transação RZ01 é possível monitorar os jobs que estão ultrapassando o tempo médio de tempo de execução e a transação RZ15 permite monitorar os interface-driven jobs. O global work process monitor (SM66) pode ser utilizado para analisar a distribuição de carga dos background jobs no sistema. Não 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 parâmetro rdisp/btctime, o batch scheduler, entre os vários servidores (por exemplo 61, 62, etc.). Com isto eles rodarão em tempos diferenties e efetuarão uma distribuição mais eficiente dos background jobs entre as instâncias. Spool Load Balancing Considere a possibilidade de acrescentar as impressoras mais críticas ao Alert monitor. Na SM66 deverá ser utilizada para identificar spool work processes super ou sub utilizados. A utilização dos spool lógicos melhora distribuição de carga. Quando especificando um device, não utilize a opção Sequential Request Processing e habilite a opção 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 atualizações que não são time criticals. O Dynamic Update Assignment cuida de distribuir os updates V1 e V2 entre os diversos João Luiz Barbosa Junho/2000 Página 103 ACADEMIA BASIS CEMIG servidores de update disponíveis. Apesar de processado em work processes separado (quando disponível), os updates V2 somente serão processados após a porção 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 são distribuídos em um processo cíclico sequencial entre os servers disponíveis obedecendo ao número de update work processes disponíveis em cada um. Quando um ciclo completo de distribuição se fecha, o sistema inicia outro baseado no mesmo critério. Este processo faz com que os updates sejam distribuídos ao acaso fazendo com que updates pesados sejam distribuídos aleatoriamente entre os servidores disponíveis. Quando o algoritmo endereça um update para um determinado server, o message server entra em ação e movimenta o request da NOWP queue do server que gerou o request para a UPD queue do server que executará o serviço Ao analisar os update work processes pela SM66, observe se o último update de cada instância mostra pouca ou nenhuma CPU. Além disso o primeiro work process deverá apresentar muito mais CPU que os demais. Se o sistema não apresentar este perfil, possivelmente estará havendo um gargalo no ambiente causado pela definição de poucos work processes de update. Use ainda a transação SM51 para exibir o maximum request wait. Este valor deverá ser muito próximo 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 transação RZ03 (Edit -> Other view -> Dispatcher queue). A transação SM13 exibe o status do update. Nesta transação, através da opção Goto -> Server, podemos ainda verificar o número de updates enviados para cada server bem como informações do dispatching. Por questões de performance, ao analisar o CPU time dos update processes em cada server, mantenha pelo menos um com 0 de CPU. Isto garante que não haverá gargalos neste serviço. Existe uma relação de custo benefício em se manter os updates centralizados na central instance ou distribuídos pelos servidores: • Central instance: a vantagem é que as instâncias não precisarão manter programas de update de todos os módulos otimizando assim a alocação dos buffers dos servidores do logon group. A desvantagem é que não se faz uso do balanceamento de carga do update, que se encontra centralizado • Distribuído pelas instâncias: a principal vantagem é o balanceamento distribuído do processamento de update, conforme descrito acima. A contrapartida é que todas as instâncias terão em seus buffers programas de update de todos os módulos, já que quem distribui os processos é o automatic load balancing de update. A configuração do update é executada pelos seguintes parâmetros de profile: • rdisp/vbname: especifica o nome do servidor de update quando o automatic dispatching é desabilitado • rdisp/vb_dispatching: habilita o automatic dispatching. Este parâmetro 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 não 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: máximo número de VB servers • rdisp/wp_no_vb e rdisp/wp_no_up2: especificam os números de update work processes (tipo 1 e 2) configurados na instância Configuration Summary Não existe uma regra específica para o número de work processes configurados em cada instância, devendo o número ser ajustado por observação da demanda. Recomenda-se apenas que se deixe sempre um work process de cada tipo com 0 de CPU garantindo a ótima distribuição da João Luiz Barbosa Junho/2000 Página 104 ACADEMIA BASIS CEMIG carga. Existe uma recomendação 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 João Luiz Barbosa 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 Junho/2000 Página 105 ACADEMIA BASIS CEMIG Quarta Semana Database Fundamentals Oracle Overview Uma instância oracle é o conjunto volátil de processos e estruturas de memória. Um banco de dados oracle é um conjunto de arquivos de dados que são manipulados pela instância oracle. Podemos dividir o Oracle em uma série de estruturas de memória. A mais famosa entre elas é a SGA (system global area) e ela é um grande grupo de buffers de memória compartilhados, a saber : shared pool, database buffer cache e redo log buffer. Para acessar estas estruturas existem os processos que executam uma série de tarefas de manutenção da instância. Cada processo é distinto, possui uma função específica, é executado em background e assincronamente. Os principais processos são : pmon, smon, dbwr, lgwr, reco, lck ckpt, snp e arch. A shared pool é uma porção de memória compatilhada que contém as áreas chamadas de shared sql, library cache, data dictionary cache e sequence cache. Todas participam do processo e são as estruturas que contém os sqls que estão sendo execudados pelos múltiplos usuários. Essas áreas contém ainda os comandos na forma interpretada e texto, a análise dos comandos com os respectivos planos de execução, informações de dicionários e geradores de números 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 aplicações que usam o mesmo comando deixando mais áreas em memória disponível para os outros usuários e melhorando a performance de execução de um comando, já que o plano de execução estará definido em memória. João Luiz Barbosa Junho/2000 Página 106 ACADEMIA BASIS CEMIG 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 contém os blocos livres, aqueles que estão 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 número específico de blocos são pesquisados sem encontrar um bloco livre. O redo log buffer armazena todas as alterações feitas em um banco de dados em memória. Todas as entradas de redo log neste buffer são escritas nos arquivos de redo log, que são usados para a recuperação do banco de dados, se necessário. O Oracle cria um conjunto de processos que rodam em background para cada instância, Esses processos executam diversas tarefas. Entre eles podemos destacar : • DBWR – O processo database writer escreve os blocos modificáveis do database buffer cache para os arquivos de dados. Os dados mais antigos são escritos em primeiro lugar. O dbwr adia ao máximo a escrita dos blocos alterados para otimização 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 são armazenados em memória no redo log buffer, e no momento em que uma transação for efetivada ou o redo log estiver com preenchimento de pelo menos um terço, 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 então atualiza os headers dos control files e dos datafiles. • SMON – O processo de system monitoring efetua a recuperação da instância em caso de falhas, durante a uma inicialização. Ele também limpa os segmentos temporários que não estão sendo usados, liberando memória e recupera qualquer transação pendente no caso de uma falha física. Simplificando, o smon é um monitor das ações do sistema detectando e corrigindo possíveis falhas no sistema • PMON – O processo monitor executa a recuperação do processo de um usuário em caso de falhas. Ele limpa a área de memória e libera os recursos que o processo usuário estava usando. Simplificando, o pmon é um monitor das ações dos usuários detectando e corrigindo possíveis falhas nos processos dos usuários • 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 transações distribuidas e pendentes. • LCKn – Os processos de lock (lckn) são usuados para controlar o lock entre instâncias em uma configuração oracle parallel server. Dentro de uma instância Oracle existem vários processos que são criados quando a instância entra em funcionamento. Eles se dividem em dois grupos : • Dedicated shadow processes: que são os processos criados no Oracle para as conexões dos work processes. Existe uma relação de 1 para 1 entre estes processos e os work processes da instância R/3 e eles só aparecem quando o R/3 está no ar • Shared processes: são os processos criados no Oracle para gerenciamento e funcionamento da instância que irá controlar o banco de dados. Eles tem atividades especificas e trabalham para a manutenção da instância como um todo. Os dados são armazenados em datafiles organizados em blocos de 8k (8192 bytes). Estes blocos são carregados para uma área comum da memória principal denominada database buffer pool. Sempre que uma leitura é feita pelo menos dois blocos são carregados, um para header e outro para dados. Cada bloco do DB buffer pool contém um header com os dados das transações que poderão compartilhar o mesmo bloco. O número de entradas no header é configurado pelo parâmetro INIT<SID> do .ora. As alterações efetuadas nos dados do banco de dados são 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 segurança transacional dos dados. Estes redo log files são espelhados por questões de segurança. Os control files não são espelhados mas deve possuir mais de uma cópia, também por motivos de segurança. Para verificar quantos control files existe utilizem a view v$controlfile através João Luiz Barbosa Junho/2000 Página 107 ACADEMIA BASIS CEMIG de sql ou da ST04. Para criar mais uma cópia 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 necessário acessar o controlfile com o banco for a do ar o estado do banco deve ser Mounted. Os comandos SQL executáveis ficam armazenados em outra área da memória denominada Shared SQL area que também é parte do shared pool. Nesta área temos ainda Library cache com os cursores de execução dos comandos SQL e a Row cache, com informações dos objetos no dicionário Oracle. Os work processes do R/3 se conectam com os shadow processes no Oracle com o usuário SAPR3. Caso esta conexão caia, os work processes tentam reconexão com o Oracle seguindo a parametrização feita nas profiles (default ou instance) através das variáveis rsdb/reco_trials e rsdb/reco_sleep_time. Uma instância Oracle aceita 3 tipos de conexões de seus clients: dedicated, que é a utilizada pelo R/3, Combined e Multi-thread. Os principais problemas de performance estão associados a shared pool (shared sql area e row cache), ao uso dos data buffers e a redo log. Outro ponto de preocupação é o acesso a disco, sua estruturação de alocação e a possível contenção 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 segurança e sincronismo. Se o banco estiver em archivelog mode, a offline redo logfile é archivada no diretório saparch logo após o switch. Starting and Stoping the Database O banco de dados Oracle passa por três fases distintas ao ser inicializado: • Nomount phase: a instância Oracle é construída (shared pool) a partir das informações parametrizadas no arquivo init<SID>.ora • Mount phase: o control file é aberto e suas informações referentes aos logs e datafiles são obtidas mas não podemos acessar os datafiles através de um sql. • Open phase: todos os files são abertos. Se o último shutdown não foi realizado com sucesso, o sistema efetua um rollback das transações inflight e retorna todos os arquivos ao ultimo ponto de sincronismo (check point). Os processos podem então começar a submeter requests ao banco de dados aberto. O shutdown pode ser realizado em três formas distintas também, a critétio do administrador: • Shutdown Normal: O sistema para de aceitar novas conexões e após o encerramento de todas as conexões já efetuadas os datafiles são fechados, o database desmontado e a instância finalmente sai (shutdown) • Shutdown Immediate: Apenas os comandos já em andamento são terminados. Todas as conexões são derrubadas através do PMON e caso exista alguma transação inflight, é feito um rollback antes da instância sair através 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 emergência apenas, este comando derruba todas as conexões e retira a instância do ar colocando o banco de dados em um estado de inconsistencia. O próximo startup precisará efetuar um recovery das transições que permanecerão inflight, até que a base volte a ser consistente (roll foward) Oracle Shared Processes Uma instância Oracle possui três 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 gravação dos checkpoints na instância Oracle João Luiz Barbosa Junho/2000 Página 108 ACADEMIA • BASIS CEMIG Logwriter (LGWR): que grava em modo síncrono as alterações efetuadas nos data buffer e logadas na redo log buffer para os online redo log files Um banco de dados em produção 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 instância. Os arquivos do online redo log files funcionam de forma cíclica e a cada switch, o file que estava sendo usado é transferido para a área de archive. O parâmetro da init<SID>.ora, log_archive_start=TRUE ativa o processo de archive na instância. O processo ARCH se baseia nos parâmetros 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 disponível para ser sobrescrito no processo cíclico de utilização dos files. Caso não haja espaço disponível na offline redo log area para a gravação do novo file, o online redo log file não é liberado e consequentemente irá travar a instância 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 padrão específico de nomes: PSAP<name>[D para data e I para index]. Por exemplo, se uma área de dicionário do R/3 ficará armazenada nos tablespaces PSAPDDICD (dados) e PSAPDDIC (índices). Esta nomenclatura é obrigatória para o uso do R/3 e suas ferramentas. As tablespaces que normalmente são criadas nas instalações são : Prefix Tablespace Ext. Meaning SYSTEM Oracle DDIC Owner Oracle rdbms PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP Oracle rdbms Oracle rdbms Basis Basis Basis Basis Basis Aplicações Aplicações Aplicações Aplicações Aplicações Aplicações Aplicações 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 Módulos do ambiente de desenvolvimento Fontes do ambiente de desenvolvimento Módulos das janelas e relatórios Fontes das janelas e relatórios Dicionário abap Tabelas do tipo log Tabelas cluster Tabelas pool Tabelas de dados mestres ou transparentes Tabelas de dados transacionais ou transparente Documentações, sapscripts e sapfind Tabelas do cliente Os datafiles que compõem o tablespace também deverão possuir uma estrutura própria de diretórios: $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 critério, apenas o nome seria ddici, e não ddicd (.../ddici_1/ddici.data1) Todos os objetos alocados nos tablespaces PSAP... pertencem ao usuário SAPR3. Os tablespaces SYSTEM, PSAPROLL e PSAPTEMP possuem objetos que pertencem aos usuários SYS ou ao SYSTEM. O usuários que se logam em um sistema R/3 não possuem objetos nas tabelas do Oracle, apenas armazenam linhas nas tabelas do banco de dados através da conexão efetuada com o user SAPR3 A estrutura de diretório do Oracle com o R/3 obedece a seguinte hierarquia : • /orant (oracle home) João Luiz Barbosa Junho/2000 Página 109 ACADEMIA BASIS CEMIG • • database: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora, init<SID>.sap, etc.). • bin: executáveis Oracle (no NT ele está no /orant/bin) • /net80/admin: arquivos de configuração 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 reorganizações, 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 três arquivos de parametrização: • init<SID>.ora: parametrizações da instância Oracle • init<SID>.dba: parametrização do sapdba • init<SID>.sap: parametrização das ferramentas BRBACKUP e BRARCHIVE Várias variáveis de ambiente parametrizam o usuário <sid>adm : • ORACLE_SID=<SID>: nome da instância • DBS_ORA_TNSNAME: seta o <SID> do banco que será conectado através do tnsnames.ora • ORACLE_HOME: o diretório home do oracle (/oracle/<SID>) • SAPDATA_HOME e SAPDATAn: aponta para diretórios específicos contendo dados Além dos usuários Oracle SYS e SYSTEM, existem os seguintes usuários no unix : • ora<sid>: usuário unix pertencente aos grupos dba e oper • <sid>adm: usuário unix pertencente ao grupo oper • OPS$<sid>adm: usuário definido no oracle como identified externally Já no NT temos : • <sid>adm: usuário NT pertencente ao grupo ora_SID_dba • sapservice<sid>: usuário NT pertencente ao grupo ora_SID_oper • OPS$<sid>adm: usuário definido no oracle como identified externally Quando o parâmetro OS_AUTHENT_PREFIX=OPS$ é codificado no init<SID>.ora, isto indicará que o usuário <sid>adm (OPS$<sid>adm) poderá se conectar ao oracle sem autenticação. Isto será necessário para determinadas tarefas restritas de administração. Neste caso a autenticação do usuário fica a cargo do sistema operacional. O mecanismo de conexão dos work processes com o shadow process no Oracle funciona da seguinte forma: o work processes tenta a conexão através do usuário SAPR3/SAP. Caso a senha tenha sido alterada, o que é aconselhável, a conexão é recusada e o work process tentará uma conexão através do usuário OPS$<sid>adm (que não exige autenticação) e acessa a tabela SAPUSER (cujo owner é o próprio user OPS$<sid>adm) e através dela possui a senha para o SAPR3 e refaz a conexão. O programa chdbpass (no unix) quando utilizado para alterar a senha do usuário SAPR3 já grava nesta tabela OPS$<sid>adm.SAPUSER a nova senha. O NT que não possui este programa disponível o que torna necessário a inclusão manual da senha na tabela quando se altera o usuário via alter user. A conexão remota dos work processes entretanto com o banco R/3 através do user OPS$ somente se dará se o parâmetro REMOTE_OS_AUTHEN estiver setado para TRUE. NET8 Basis A comunicação dos work processes com o Oracle se dá através de comunicação TCP/IP através da rede. A camada Oracle que interpreta e aceita estas conexões é o NET8. Para que o NET8 aceite João Luiz Barbosa Junho/2000 Página 110 ACADEMIA BASIS CEMIG conexões através da rede, o listener do Oracle precisa estar ativo. O utilitário lsnrctl80 é utilizado no database server para dar start e stop no processo tnslsnr que executará o serviço. Três arquivos configurados no .../net80/admin do oracle configurarão o serviço NET8: • tnsnames.ora: contém a lista dos serviços para todos os bancos de dados acessados na rede • sqlnet.ora: contém, no lado client, informações do default domain além de parâmetros opcionais de diagnósticos usados para trace e logs do client • listener.ora: usado no database server e contém Oracle system Ids com o quais o Oracle poderá receber conexões e parametrizações do listener Database Monitoring Várias transações são 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 transação utilizada para monitorar os objetos (tableas, índices, tablespaces) do banco. Além destas, a ST04 é o monitor de performance e a DB14 é o monitor das logs das atividades administrativas do banco. João Luiz Barbosa Junho/2000 Página 111 ACADEMIA BASIS CEMIG Backup Estrategy Database Backup A estratégia de backup da base de dados é necessária para garantir a recuperação de uma base de dados que pode falhar por diversos fatores, sejam físicos (crash de disco), lógicos (operação indevida nos aplicativos) ou fatores externos (fogo, agua, greve, etc). Através de cenários que iremos estudar, é possível fazer full recoveries (recuperação total) dos data bases ou ainda recuperações point in time (recuperação total em um ponto do tempo passado) a partir de uma boa estratégia de backup. Operações de recovery, por serem críticas, exigem documentação detalhada, estratégia estudada além de skill específico dos administradores de banco de dados. Ou seja, antes de tomar qualquer ação após um problema, tenha certeza do que está sendo feito e de que a ação é a melhor opção entre outras analisadas. Os files que compõem uma base de dados Oracle podem ser divididos em cinco grupos: • Os data files são os arquivos que contém os dados da aplicação propriamente ditos. É aconselhável que sejam protegidos por espelhamento (RAID V ou superior) • Os online redo log files são os arquivos onde são gravadas as logs de transações no banco de dados e são espelhadas por definição através das mirrlogs • Os control files são os arquivos que possuem as informações de controles referentes aos datafiles e a base de dados. O Oracle mantém cópias deste file em mais de um filesystem do ambiente, definido por parâmetro na initSID.ora • Profiles são os arquivos de configuração da instância oracle • Offline redo log files são as cópias 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 física da base de dados ou seja, garantir que as tabelas e blocos estejam fisicamente íntegros é necessário efetuar logical data checks através de ferramentas oracle como o utilitário dbv (database verify). Temos também que garantir a integridade das fitas backupeadas é necessário efetuar um physical data check, que verifica a integridade física das fitas gravadas através da leitura dos dados backupeados na fita. Backup Types Um processo de backup offline é executado com a instância em shutdown e os seguintes arquivos são 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 instância ativa e os seguintes arquivos são copiados: data files, control file e profiles. Estas cópias online não são consistentes, já que o processo de update no banco continua sendo efetuado pelos usuários. 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 serão 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 é através do paralelismo do backup com a utilização de vários drives de fita. Este processo reduz significantemente o tempo de backup e restore, sendo porém caro pelo hardware envolvido. João Luiz Barbosa Junho/2000 Página 112 ACADEMIA BASIS CEMIG Backup and Recover Diagram Backup ArchiveLog NoArchiveLog On-Line Complete Recover Off-Line Incomplete Recover with reset log Reset Data Loss Várias são as causas que podem causar a perda de dados em uma base de dados. Erros lógicos podem ocorrer pela deleção 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 lógicos são recuperados através de um full database restore seguido de um point in time recovery até o momento imediatamente anterior a causa da perda da informação. A ausência de um offline redo log file durante um processo de recovery causará a perda de todas as informações subsequentes, já que o processo não permite a aplicação dos offline seguintes ao que foi perdido. Por este motivo é importante a manutenção de pelo menos duas cópias dos offline redo log files em dispositivos diferentes para garantir uma recuperação com uma salva-guarda de contingencia. Uma outra causa de necessidade de recuperação é o chamado disaster recovery, efetuado por causas físicas, como por exemplo um crash de disco. A manutenção de cópias de backup em cofres garantem inclusive a possibilidade de recuperação de todo o ambiente computacional em caso de perda total das instalações físicas do cpd. Backup Recommendations Alterações nas estruturas dos arquivos afetarão os restores subsequentes, como ocorre por exemplo quando um data file é acrescentado a base de dados. Processos como este que causam a alteração dos control files deverão ser seguidos de um backup adicional imediato do banco de dados para que o processo de recuperação, se houver, não seja afetado pelo diferente estado do banco de dados. O ponto crítico de uma alteração estrutural do banco de dados é a necessidade de ter ao menos uma cópia do novo datafile e a estrutura gerada no control file. Sem isto é impossível recuperar o banco na nova estrutura ou fazer um log-foward após este evento. Backup Cycle A SAP recomenda um ciclo de backup de 4 semanas. Isto significa que os offline redo log files serão backupeados diariamente e mantidos por 28 dias. O backup online deve seguir a mesma regra, João Luiz Barbosa Junho/2000 Página 113 ACADEMIA BASIS CEMIG ou seja uma cópia a cada dia útil do ciclo. É importante ainda que tenhamos em cada ciclo pelo menos um backup offline, um check de consistência do backup e check dos datafiles do banco de dados. Esta recomendação é básica, sendo o ideal fazer tudo isso pelo menos uma vez a cada semana. É recomendável também 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 também apresentem problemas. Final Recommendations Utilize as ferramentas providas pela SAP para efetuar o backup (BRBACKUP e BRARCHIVE) e tenha certeza que elas estão 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 próprias gravadas no sistema operacional para direcionar o seu funcionamento. É bom lembrar que além do banco de dados, é necessário manter backup consistente de outros objetos R/3, tais como archiving, interfaces, executáveis e do sistema operacional. Não adianta muito ter o backup da base de dados se não tivermos o R/3 e o Oracle instalados e com os arquivos de controles que irão hospedar esta base de dados Só a correta implementação de uma boa estratégia de backup é a garantia para a recuperação do sistema sem perda de informações em caso de falhas. João Luiz Barbosa Junho/2000 Página 114 ACADEMIA BASIS CEMIG Tape Management Tape Pools Os utilitários BRBACKUP e ao BRARCHIVE que permite a gerencia do pool de fitas utilizadas na estratégia de backup, permitindo encontrar as fitas necessárias no momento do backup e do recovery e garantindo a sua proteção contra utilização 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 não podem ser utilizadas no outro pool O número de fitas utilizadas no pool do BRBACKUP dependerá de vários fatores, como tamanho do banco, duração do ciclo, capacidade das fitas, frequencia e paralelismo dos processos de backup. Já o número de fitas do pool utilizado pelo BRARCHIVE dependerá do tamanho do ciclo, número de redo logs criadas no ambiente (atualizações), capacidade das fitas e frequencia dos offline redo backups. Tape Initialization As fitas são inicializadas pelo brbackup ou brarchive através da opção –i force (inicializa novas fitas, fitas não utilizadas alteriormente pelo SAP ou fitas bloqueadas para gravação), –i –v <tape_name> (renomea fitas que não estão bloqueadas para uso) ou –i –v SCRATCH (para fitas scratch). Na prática o processo de inicialização consiste na criação de um arquivo .tape.hdr0 no inicio da fita para identifica-la no momento de uso. Dentro deste arquivo temos informações do nome da fita, do noma da instância na qual ela está sendo utilizada, o timestamp da ultima utilização e o numero de utilizações feitas até o momento. Os dois utilitários sempre acessarão este arquivo para decidir se a fita é a esperada e se ela está disponível para uso. Eles levarão em conta os parâmetros (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 padrão 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 número sequencial. O nome das fitas que estão disponíveis para utilização estão nos parâmetros 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 parâmetro expir_period que fornece o ciclo de proteção da fita baseado no timestamp do último backup lá gravado (informação no label). Este mecanismo é denominado lock físico. Um outro mecanismo de proteção é denominado lock lógico e é baseado nas tabelas SDBAH e SDBAD. Elas contém informações das fitas gravadas no período e são mantidas pelo BRBACKUP e BRARCHIVE. Baseado nas entradas desta tabela e no pool de fitas gravado nos parâmetros volume_backup e volume_archive, o sistema verifica se uma determinada fita está liberada para gravação reforçando o mecanismo de lock das fitas. O BRARCHIVE pode se basear em informações de suas logs para efetuar o lock lógico, podendo desta forma ser executado mesmo quando o banco se encontra offline. A fita seguinte a última utilizada no pool é a selecionada para utilização. Tape Selection As ferramentas SAP oferecem três mecanismos para seleção das fitas: • mecanismo automático permite que o BRBACKUP e BRARCHIVE selecione a fita baseado em seus mecanismos de lock e no pool de fitas fornecido nos parâmetros volume_backup e João Luiz Barbosa Junho/2000 Página 115 ACADEMIA • • BASIS CEMIG volume_archive. A chamada destes programas com a opção –q permite verificar qual será a próxima fita selecionada para uso. Se for necessário utilize a opção –q check para verificar se a fita que está montada é a fita esperada pelos utilitários. mecanismo manual de seleção é através da opção SCRATCH. Quando uma fita inicializada com o nome SCRATCH é inserido no sistema, o BRBACKUP e o BRARCHIVE a aceita em substituição a fita requisitada e grava o novo label nela antes de começar a gravação. É útil por exemplo para substituir uma fita do pool danificada. Alternativamente, é possível substituir o pool de fitas informado no init<SID>.sap pelo parâmetro SCRATCH. Neste caso o sistema não sugere uma fita, apenas pede uma cujo operador fica responsável pela manutenção do seu schedule. Ainda neste caso os mecanismos de lock funcionam apenas para proteção de uso indevido das fitas mecanismo de seleção externa é utilizado através da opção –v e é útil quando um shell ou produto externo é utilizado para gerenciamento das fitas. O label neste caso também será checado pelos mecanismos de lock lógico. Todo este processo utiliza uma outra ferramenta de interface com o mundo externo que é o BACKINT. Tape Layout O layout básico de gravação da fita é praticamente o mesmo para o BRBACKUP e o BRARCHIVE (as diferenças então marcadas abaixo), a saber : • tape.hdr0 • init<SID>.ora (configuração do oracle) e init<SID>.dba (configuração do sapdba) • init<SID>.sap (configuração do brbackup e brarchive) • diferenças • Para o BRBACKUP • DB files • Control files • Para o BRARCHIVE • Offline redo log files • reorg.log (informações de reorganizações, restore e recover) e struct.log (histórico das alterações de estruturas do banco) • detail.log (log do processamento) • summary.log (lista dos processamentos já realizados) João Luiz Barbosa Junho/2000 Página 116 ACADEMIA BASIS CEMIG Scheduling, Performing and Monitoring Backups Backup Tools Features Para fazer um backup podemos utilizar uma das ferramentas : • Transação DB13 - DBA Planning Calendar - onde é possível schedular backups periódicos em uma instalação R/3 • Utilitário SAPDBA onde é possível ativar backups esporádicos de forma interativa por menus e várias outras operações de administração e operação do oracle • BRBACKUP e BRARCHIVE onde –e possível realizar backups a partir de linha de comando Backup profile parameters Alguns dos parâmetros podem possuir valores default definidos na profile init<SID>.sap, como por exemplo o tipo de compressão, comando para compressão, utilitário para cópia, dispositivo a ser utilizado, etc. Os utilitários brbackup e brarchive atualizam as tabelas SDBAD e SDBAH, checa o lock de fitas e gera logs específicas das atividades efetuadas sempre levando em conta a parametrização feita neste arquivo. tape_size Parameter O parâmetro 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 parâmetro é importantíssimo já que a sua má especificação pode causar mal funcionamento do processo de backup. Através da especificação do parâmetro tape_size os utilitários de backup (BRBACKUP e BRARCHIVE) calculam o volume de dados que pode ser enviado para cada fita, dimensionando desta forma o número de fitas que serão necessárias durante o processo. Quando mal dimensionado pode causar o desperdício de mídia ou, pior ainda, erro no processo de gravação. O utilitário dd utilizado no processo de cópia acusa erro quando atinge o end-of-tape. Já o utilitário cpio, desde que não esteja trabalhando em modo parallel, consegue passar os dados para um volume subsequente, porém este volume não será reconhecido pelas ferramentas de gerencia de fitas por ter sido requisitado ao longo do processo e não possuir o arquivo de identificação da fita (.tape.hdr0). O ideal portanto é que este parâmetro especifique um valor 10% menor que a capacidade real da fita, como margem de segurança. Quando utilizamos compressão por hardware, o valor do tape_size deverá ser ainda um pouco mais folgado, uma vez que a taxa de compressão varia dependendo do tipo de dado armazenado. A nota 8707 dá todos os detalhes sobre esta especificação de tape_size. Para distribuir os files pelas fitas, o brbackup utiliza informação da taxa de compressão dos files. Este cálculo da taxa de compressão deverá ser efetuado uma vez a cada ciclo através do comando brbackup –k only […]. Quando utilizado tape stations com hardware compression, o parâmetro compress_cmd da init<SID>.sap deverá ser setado para “compress –b 12 –c $ > $” (em unix). A compressão por software é efetuada no diretório especificado (compress_dir) e consumirá ciclos de CPU da máquina 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 concorrência nos datafiles. Os seguintes processos são efetuados durante o processo. • Salva a saída de um backup control file em disco • Obtém os files names que serão 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 João Luiz Barbosa Junho/2000 Página 117 ACADEMIA • • BASIS CEMIG 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, porém o brbackup deixa a instância no estado exato em que se encontrava no início do processo (up ou down): • Start no database, se o mesmo se encontra em shutdown • Obtém os files names que serão 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 não for completo os online redo log não serão backupeados Database Backup Check and Monitoring Blocos de dados danificados no banco de dados somente são identificados quando o Oracle tentar manipular este bloco. O utilitário dbv da Oracle efetua o check de um datafile quanto a estas integridades. Esta verificação lógica da integridade dos dados pode ser realizada em tempo de backup através da especificação do parâmetro –verify use_dbv ou –w use_dbv. Este processo faz com que os files sejam lidos da fita após gravados e transferidos para o diretório de compress (compress_dir) onde são processados pelo utilitário dbv da Oracle. O processo além de detectar blocos corrompidos garante a disponibilidade da fita. È aconselhado que seja efetuado uma vez por semana ou no mínimo uma vez no ciclo. Como este processo pelo menos duplica o tempo gasto no backup, é possível adiar a execução do verify através de uma execução posterior de uma simulação de BRRESTORE, que pode inclusive ser executado em outra máquina. (Para maiores informações de datafiles corrompidos veja a nota 99962). A opção de verificação da integridade lógica (-verify use_dbv) verifica a integridade dos blocos Oracle porém não garante que o file gravado na fita seja idêntico ao file existente no disco. Esta verificação da integridade física deverá ser efetuada uma vez no ciclo, que ocorrerá a nível binário com a especificação do parâmetro (-verify ou –w). Este processo de verificação física somente pode ser executado no processo de backup offline e também 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, não pode ser postergado para um posterior BRRESTORE. O BRBACKUP grava logs em files no diretório sapbackup e nas tabelas SDBAH e SDBAD que devem ser checados constantemente. Os logs gravados obedecem a um padrão próprio de nomenclatura (b<timestamp>.<ext>) cuja extensão depende do tipo de backup selecionado. As transações DB12 e DB13 também permitem acompanhar a execução dos backups Offline Redo Log Files Backup O processo Oracle ARCH é responsável pela movimentação as Online redo log files durante o switch de log. Estas logs são 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 gravação para fita foi efetuada • COPIED: indicando que uma segunda cópia foi efetuada • DELETED: indicando que o file foi deletado do diretório João Luiz Barbosa Junho/2000 Página 118 ACADEMIA BASIS CEMIG O BRACHIVE possui uma serie de opções para o backup dos archive logs. A SAP aconcelha a especificação do parâmetro –cds no BRARCHIVE que faz com que esta gerencia de backup duplo de offline redo log files com posterior deleção seja efetuado automaticamente. Outra boa opção e a opção –f (fillup) onde o brarchive grava os files e continua verificando a saparch de tempos em tempos. Qualquer offline que apareça é então gravado até que a fita esteja cheia. Como no BRBACKUP, devemos utilizar a opção –verify ou –w para efetuar um check físico dos arquivos gravados e é recomendado que seja efetuado uma vez no ciclo. A monitoração do processo de offline backup deverá ser efetuado através da transação DB12 e através da monitoração do arch<SID>.log no diretório saparch. Através da opção –o é possível forçar a gravação de mais informações na log. Log File Cleanup Os logs gerados tanto pelo BRBACKUP quanto pelo BRARCHIVE são utilizados posteriormente pelo SAPDBA para tomar as ações corretivas e parametrizar o BRRESTORE. Estes files porém vão se acumulando nos diretórios e precisam ser eliminados de tempos em tempos. O SAPDBA possui funções administrativas de clenup não só destes logs como também dos traces e logs geradas pelo Oracle e pelo próprio sapdba. A limpeza dos logs de backup e archive se baseia nos parâmetros expir_period_* da init<SID>.dba. Estes parâmetros deverão ser adaptados de acordo com o ciclo de backup adotado na empresa. A chamada a estas funções poderá ser executado interativamente via sapdba ou através da chamada sapdba –cleanup em linha de comando ou via algum utilitário de agendamento do sistema operacional. Freespace Administration Os offline redo log files são transferidos para a área de archive saparch através do serviço Oracle ARCH. Se estes arquivos não forem backupeados para fita e deletados, a área poderá estourar, o que causa a parada do Oracle conhecida como archiver stuck. Neste caso a instância para por não poder sobrescrever um online redo log file ainda não transferido para a área de offline. Este problema somente ocorre se o ARCHIVELOG mode estiver ativado, o que é padrão em ambientes produtivos. Através da DB12 deve-se monitorar a área livre no diretório (ou através de df –k) e tomar medidas preventivas (archive) antes que o problema ocorra. Outra solução que pode ser adotada é a definição 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 não mais responda a comandos, ative o brarchive via linha de comando One-Run Strategy A estratégia One-Run backup consiste em efetuar o backup e o archive em uma única chamada ao brbackup através da especificação de parâmetros próprios (brbackup –m all –c –a –cds –c). Neste caso apenas uma fita do pool backup (volume_backup) é utilizada para armazenar os dois backups. Esta estratégia porém só pode ser utilizada se o backup dos datafiles e todos os offline redo log files couberem em uma única fita. A solução neste caso é o uso de paralelismo no backup (mais de um drive) ou então adotar outra estratégia para o backup. Esta solução possui o incoveniente dos datafiles e ds offline redo log files estarem na mesam fita. Além disso, em caso de um archiver stuck ocorrer, esta opção não poderá ser usada, já que o brbackup tentará se conectar com o banco que se encontra travado. Further Documentation Para maiores informações sobre backup e recover, veja as notas 96896, 19909, 99088, 71058, 8707, 33630, 99962, 23345, 100400 e 83699. João Luiz Barbosa Junho/2000 Página 119 ACADEMIA BASIS CEMIG Advanced Backup Techniques One-Run Strategy Consiste em executar em uma única chamada o backup dos datafiles e offline redo log files. É ativado através da chamada brbackup –m all –c –a –cds -c Principais vantagens: • Atende a maioria das instalações, 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 também serão salvos na mesma fita. Pode ser utilizado para realizar um point in time recovery. É ativado através da chamada brbackup –t online_cons. Os offline redo log files gravados neste processo não são documentados no arch<SID>.log, já que são processados pelo brbackup Parallel Tape Support Através do parâmetro tape_address do init<SID>.sap, o brbackup permite a gravação de várias (até 4) devices em paralelo. Neste caso o parâmetro exec_parallel deve ser setado para 0 e os utilitários vão disparar o processo de cópia (dd ou cpio) um por device físico. O processo de offline redo log file backup permite até 2 devices através da especificação do parâmetro tape_address_arch. O BRRESTORE também irá utilizar os vários 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 início do primeiro tablespace devem estar disponíveis. . É ativado através 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 opção para diminuir a janela de backup é através da especificação para copiar apenas os tablespaces que contenham dados, ignorando os que contém apenas índices ou estejam vazios. . É ativado através da chamada brbackup –m all_data João Luiz Barbosa Junho/2000 Página 120 ACADEMIA BASIS CEMIG Principais vantagens: • Diminui o volume de dados que serão backupeados Principais desvantagens: • Aumenta o tempo de restore já que será necessário 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 rápido. Em um segundo step, os arquivos são transferidos do disco para a fita. É ativado através da chamada brbackup –d disk –e 4 que faz o primeiro step e para o segundo step –b last –d tape. Nesta opção também podemos fazer o primeiro step de forma paralela. Para isso basta utilizar o parametro exec_parallel e um conjunto de diretórios destinos para o backup em disco. Principais vantagens: • Diminui sensivelmente a janela de indisponibilidade ou concorrência sobre o database • Um restore pode ter seu tempo sensivelmente diminuído, já que os dados do último backup permanecem no disco Principais desvantagens: • É necessário um gasto maior com discos físicos apenas para o backup Structures-Retaining Database Copy É um processo que consiste em copiar toda a árvore do Oracle home para um novo diretório. É um processo que pode ser utilizado por exemplo para transformar um data base de filesystem para raw device, e vice versa. É ativado através da chamada brbackup –d disk_copy e parametrizado pelo parâmetro new_db_home da init<SID>.sap. Principais vantagens: • Diminui a janela de backup (disco para disco) e agiliza um possível restore Principais desvantagens: • Investimento em hardware (disco) além 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 através da chamada brbackup –t online/offline_split –d tape Principais vantagens: • Baixíssimo downtime • Não há impacto no database server, já que o backup é realizado a partir de outro servidor onde o espelho é montado Principais desvantagens: • Preço elevado da solução João Luiz Barbosa Junho/2000 Página 121 ACADEMIA BASIS CEMIG SAP Tools and Oracle Standby Database É um mecanismo que consiste em um outro server com configuração idêntica ao database que se deseja backupear, permanecendo porém em estado de mount. A partir de um sincronismo inicial, apenas os offline redo log files são responsáveis por ir atualizando (via NFS) a versão do database da instância de standby, que possui ainda o diretório sapbackup compartilhado via NFS. Os offline backups serão transferidos para a nova instância através do comando brarchive –sd –d disk –f –w. Na instância de standby os offline são backupeados com a opção brarchive –ssd –f –m <delay> e os datafiles com a opção brbackup –t offline_standby Principais vantagens: • Não há downtime no ambiente produtivo Principais desvantagens: • Administrativamente mais complexo e exige investimento alto em hardware para replicar os ambientes • Alterações na estrutura do banco produtivo precisam ser replicadas manualmente para o ambiente de standby External Backup Tools Using BC-BRI É a utilização de ferramentas externas para a execução do backup que se comunicam com as ferramentas da SAP através 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 manutenção de todas as logs, o que permite o restore e recovery a partir do sapdba. Esta opção é configurada na init<SID>.sap pelos parâmetros 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 João Luiz Barbosa Junho/2000 Página 122 ACADEMIA BASIS CEMIG Restore and Recovery Database Errors Os erros que podem ocorrer em aplicativos que utilizam bancos de dados são os seguintes: • Statement errors, que é uma tentativa de entrada inválida em uma tabela. O oracle cuida de abendar a transação e efetuar possíveis rollback • Process errors, que é uma falha na comunicação entre os processos client e os serviços oracle. Qualquer falha é recuperada pelo oracle • Instance error, que pode causar um queda da instância, mas que é recuperada no próximo startup pelos próprios mecanismos do oracle • User error, que é provocado por uma ação acidental, como um drop table ou delete de linhas indevidamente • Media errors, que são provocados por um crash de disco ou um delete datafile. Os user e media errors devem ser recuperados através da ação do DBA, efetuando operações de restore e recovery. O sapdba oferece recursos para a maioria das recuperações, porém eventualmente pode ser necessário utilizar ferramentas Oracle na recuperação Scenario Uma instância R/3 com banco de dados Oracle tem todos os seus datafiles normalmente com o status online e read/write. A sincronização das alterações efetuadas nestes files é mantido através de um mecanismo de tempo. O Oracle utiliza o conceito de timestamp para esta sincronização, que é um inteiro que é incrementado durante certas ações que são efetuadas no database. Este valor é então 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 sincronização. O Oracle mantém também um nível mais sofisticado de sincronização das transações através so System Change Number (SCN) que é incrementado pelo commit ou pelo processo de checkpoint. As análises de cenários seguintes assumirão 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 ocorrência do erro. O conceito de partial restore consiste em retornar apenas os datafiles que foram avariados. Após este retorno o banco perde o sincronismo e não mais poderá ser startado. Para ressincronizar o banco de dados, o oracle abre o banco em modo mount, avalia as informações gravadas no header dos files e começa o recovery requisitando os offline redo logs que foram gerados desde o mais antigo database file, em sequencia, e reaplica as alterações logadas (before images) até sincronizar todos os files com o mesmo SCN. O próximo start do banco irá efetuar um rollback das transações que permaneceram inflight neste processo. O banco é reaberto, está operativo e apenas os dados não commitados no momento do crash serão 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 posição do ultimo offline backup efetuado(LSN 10). Este processo exige um full offline backup. João Luiz Barbosa Junho/2000 Página 123 ACADEMIA BASIS CEMIG O database reset é esta operação de retornar o banco a situação exata do offline backup através de uma operação 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), não necessitando de nenhum processo de recovery. Quando o banco é reaberto, ele recomeça a criar redo log files a partir do LSN 10. Desta forma serão 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 direções. É necessário um trabalho administrativo aqui, seja para eliminar as logs antigas manualmente ou providenciar um novo backup offline tão 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 após os backup offline, que são sobrescritos no processo e suas offline redo logs ignoradas. Point in Time Recovery Esta é uma situação 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 consequências 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 deverão especificar a situação da estrutura do banco no ponto em que se deseja parar o recovery. Se o banco sofreu alterações estruturais durante este período, é necessário uma análise e interferência manual do DBA. O próximo passo é o efetuar o incomplete recovery. O banco de dados é aberto em modo mount e todas as offline redo log files necessárias até atingir o ponto especificado são 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 critério do DBA. Após um point in time recovery o banco de dados normalmente é aberto com a opção de reset logs (alter database open resetlogs), o que significa que o LSN é reinicializado e as redo logs começam a ser geradas a partir do número 1 novamente. Isto somente não ocorrerá se durante o processo o DBA resolver aplicar todas as logs disponíveis, efetuando assim um complete recovery. A partir deste momento não é mais possível 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 estratégia a ser seguida. Em caso de dúvida jamais se deve tomar decisões e/ou ações aleatorias. Decisões/ações apressadas e erradas tendem a agravar o problema. Em caso de dúvida, sempre consulte DBAs com experiência em processos de recuperação de bases de dados. Analise cuidadosamente a causa do problema, os backups disponíveis, os offline redo log files disponíveis e comece a desenhar os possíveis cenários de recuperação, decidindo qual deles é o melhor a ser escolhido. Havendo tempo e disponibilidade, faça uma cópia full offline da base de dados que possibilite retornar o problema se o cenário de recuperação piorar a situação tomando rumos não previstos. Caso o ciclo de backup tenha sido bem estruturado, o DBA tem sempre um grande número de backups disponíveis para proceder a recuperação. A opção 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 através de seis fases: 1. Check database: check do status dos files do banco João Luiz Barbosa Junho/2000 Página 124 ACADEMIA BASIS CEMIG 2. Find backup files: a partir das logs de backup determina aquelas que poderão 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 necessários para o recovery 5. Restore archive files: copia os offline redo logs necessários de volta para o disco 6. Recover: cria recover scripts para efetuar a operação de recover Este método de recuperação é 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 rápidos para corrigir este problema ao inves de voltar um backup. Database Reset Using SAPDBA O processo de reset database através do sapdba com um full offline backup irá sobrescrever os datafiles, control files e online redo log files e permite que após o restore o banco seja aberto em mount e o DBA proceda um recover a partir do svrmgrl (server manager). Neste caso especifico, operação manual do svrmgrl, não chamamos de database reset mas esta pode ser uma opção para alguns cenários de recuperação. Quando se efetua um reset database a partir de um online consistent backup os data files e control files são 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 opção resetlogs. Full Restore and Recovery Using SAPDBA Esta é a opção 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, além 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 alteração na estrutura do banco, é recomendado que se faça um backup da estrutura alterada para que no caso de um restore e recovery as alterações possam ser reaplicadas a partir da sua log no sapreorg. João Luiz Barbosa Junho/2000 Página 125 ACADEMIA BASIS CEMIG Storage Management Space Management Todas as tabelas e índices do Oracle são organizadas em data blocks armazenados nos tablespaces. Estes data blocks com R/3 são de 8K. A necessidade de crescer um tablespace é efetuada através da inclusão de datafiles ao tablespace. Esta operação quando efetuada pelo sapdba, no final do processo o usuário é 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 contíguo (declarado no catálogo oracle) de data blocks no tablespace com tamanho definido pelo parâmetro NEXT de definição da table/index. Caso o espaço contíguo não esteja disponível ocorrerá um erro ORA-1653 ou ORA-1654 (tabela ou índice). Uma tabela ou índice é inicialmente alocada baseado no parâmetro INITIAL e posterior extents de acordo com o parâmetro NEXT até um limite MAXEXTENTS. Na tentativa de superar o maxextents, ocorrerá um erro ORA-1651 ou ORA-1652 (tabela ou índice). Os demais parâmetros da cláusula STORAGE do Oracle (PCTFREE, PCTUSED PCTINCREASE) não devem ser alterados exceto sob recomendação explícita da SAP. e Fragmentations As linhas de dados das tabelas e índices vão ocupando os data blocks e quando há necessidade de mais espaço e alocado um segmento NEXT. Estes segmentos não necessariamente estarão contíguos ao longo do tablespace, o que causará a denominada external fragmentation ou fragmentação a nível do tablespace. Tabelas que contém raw fields, colunas opcionais ou registros de índices são armazenados de forma compactada. Com isto nem todas as linhas dentro de um data block possuem o mesmo tamanho. A deleção de linhas destes objetos irá produzindo gaps internos nos data blocks denominados internal fragmentation ou fragmentação a nível da tabela. Fragmentations in Data Blocks – PCTFREE and PCTUSED Os parâmetros PCTFREE e PCTUSED determinam a forma como os objetos serão trabalhados dentro dos data blocks. Enquanto o espaço livre de um datablock não atinge o PCTFREE, ele aceitará novas inserções. Quando este valor é atingido, o data block para de aceitar inserts assumindo que o espaço livre restante será utilizado para possíveis crescimentos de linhas por update. Qualquer insert subsequente será direcionado para outro data block disponível no segmento. Somente quando após deletes no data block causarem a disponibilidade de um espaço livre inferior ao PCTUSED, este data block retornará a aceitar inserts. Quando o update de uma linha não cabe na área reservada pelo PCTFREE, a linha é migrada para outro data block. Apesar de ruim, no R/3 este fato não é tratado com relevância. A gerencia dos data blocks que estão disponíveis para inserts é executada através de uma tabela denominada free list. A má especificação destes parâmetros para determinados objetos poderá causar uma grande movimentação dos data blocks nesta free list, o que é ruim para a performance. A Oracle recomenda que a diferença 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 padrão os valores de 10% para o PCTFREE e 40% para o PCTUSED.. Daily Monitoring: SAPDBA -check O check database efetuado pelo sapdba efetua uma série de verificações na base de dados e nas configurações 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. Através da DB13 deve-se schedular este check diário João Luiz Barbosa Junho/2000 Página 126 ACADEMIA BASIS CEMIG (através do comando sapdba –check) para monitoração da base de dados. Os dados analisados são carregados na tabela DBMSGORA e podem ser monitorados através da DB16. Os parâmetros utilizados para comparação durante o check pdem ser configurados através da transação DB17. Tablespace Extension O critério de alocação de data blocks dos objetos Oracle é definido a partir dos parâmetros INITIAL, NEXT e MAXEXTENT. O INITIAL define a alocação inicial, NEXT o tamanho das alocações next que poderão ocorrer MAXEXTENTS vezes. Devemos sempre lembrar que uma definição destes parâmetros que atendia uma determinada tabela/índice, pode se tornar obsoleta a medida que uma tabela começa a crescer. Por exemplo, um alocação 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 mantém uma tabela denominada TGORA (ou IGORA para índices) que contém especificação da parametrização para diversos ranges de tamanho de tabelas/índices. Estas tabelas são organizadas por categorias de tabelas, de acordo com o atributo especificado para cada tabela no dicionário 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 múltiplos que podem ser reaproveitados de forma otimizada por posteriores alocações Para auxiliar a tarefa de adaptação contínua dos parâmetros de storage dos objetos da base de dados, o sapdba possui a opção –next que percorre todos os objetos e, através de um algorítmo próprio adapta os parâmetros de storage destes objetos para os valores encontrados nas faixas destas tabelas. Esse processo é fundamental para a gerencia de fragmentação dos tablespaces e deve ser efetuado regularmente em uma base de dados. Tables and Indexex Monitoring A transação DB02 permite a monitoração das tabelas e índices da base de dados do R/3. Os dados exibidos nesta transação são 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 vários reports e dispara-los conforme especificação. O RSORATDB normalmente tem schedule diário na TCOLL. Através da DB02 também podemos monitorar objetos críticos (cuja próxima alocação de extent não encontrará espaço disponível no tablespace), objetos com elevado volume de fragmentação (muitos extents), taxa de crescimento, entre outros dados. Para maiores informações verifique as notas 12103 e 16083. Analyzing Storage Allocation: SAPDBA -analyze O Oracle analyse é utilizado para atualizar as estatísticas referentes as alocações de storage, grau de fragmentação e distribuição dos dados. Estas informações serão utilizadas pelo CBO – Cust Based Optimizer. O utilitário poderá ser schedulado via sapdba através da opção –analyze. É possível ainda analisar tabelas individualmente pelo sapdba ou através da DB20. O processo de análise pode ser executado em modo ESTIMATE (amostragem) ou COMPUTE (full análise). Os índices e seus dados são analisados por ANALYSE INDEX VALIDATE STRUCTURE, porém este método efetua um lock nos objetos durante a análise. Durante a análise da fragmentação interna através dos relatórios gerados pelo método analyze, verifique sempre se a diferença entre EMPTY e NEVER_BEEN_USED. Diferenças grandes indicam fragmentação. Grande diferença entre USED_BY_BTREE e USED também indicarão fragmentação de índice. João Luiz Barbosa Junho/2000 Página 127 ACADEMIA BASIS CEMIG Reorganization Basics O processo de reorganização tem por finalidade eliminar os problemas de fragmentação relacionados com as estruturas dos objetos. Através de uma política atenta de monitoração do database e correta especificação dos segmentos NEXT (através do sapdba –next), esta necessidade será naturalmente minimizada. O processo de reorganização consiste na seguintes sequencia de passos: export dos dados, drop dos índices, drop da tabela, create da tabela, import dos dados, create index. Através do sapdba, todos os scripts necessários para executar estes passos são criados e chamados na seqüência correta sem nenhuma interferencia no processo a ser executado. Várias são as causas que apontam para uma necessidade de reorganização: • Fragmentação elevada nos índices ou tabelas, apontado por elevado volume de extents • Má distribuição das tabelas nos tablespaces ou ainda dos próprios tablespaces ao longo dos discos, gerando “hot spot” disks Através do sapdba, a reorganização é efetuada em duas fases: na primeira cria os scripts que executarão os passos a serem executados para aquele método de reorganização escolhido e verifica se existe área suficiente nos filesystems. Na segunda fase do processo estes scripts são iniciados em uma sequência por ele estabelecida e executam a reorganização. 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 opção pode ser utilizada por exemplo por DBAs experientes que desejam alterar os scripts criados para manipulação dos parâmetros de storage dos objetos, por exemplo. Sempre que se efetua uma reorganização de tabelas, os seus respectivos índices também serão reorganizados. O inverso não é verdadeiro Os erros a seguir são os mais comuns durante o processo de reorganização : • Os datafiles onde os será feita a reorganização não comporta a segunda cópia do objeto ou a nova alocação a ser implementada • diretório sapreorg não comporta o export que será feito durante a reorganização • tablespace PSAPTEMP não comporta a recriação de um indice da tabela que esta sendo reorganizada Phases and Types Existem vários tipos de reorganização que podem ser manipulados pelo sapdba: • Reorganização de um único objeto: utilizado para eliminar fragmentação interna, reduzir o número de extents ou movimentar objetos entre tablespaces • Reorganização de uma lista de objetos: reorganiza uma lista de objetos especificados em um arquivo ASCII, localizado no diretório de trabalho • Reorganização de tablespace: reorganiza todos os objetos pertencentes ao tablespace, mantendo a estrutura de datafiles • Reorganização de tablespace com datafiles: reorganiza todos os objetos do tablespace permitindo ainda a realocação dos seus datafiles. • Movimentação ou renaming de datafiles, que não é encarado como um processo de reorganização João Luiz Barbosa Junho/2000 Página 128 ACADEMIA BASIS CEMIG Methods O processo de reorganização de tabelas dropa a tabela durante o processo, havendo portanto perigo de se perder dados. Os métodos utilizados são os seguintes: • Export/import: utiliza os comandos Oracle EXPORT e IMPORT para extrair e recarreagar os dados. • SAPDBA unload/load e SQL loader: mais rápido que o anterior, porém exige um pouco mais de memória Os métodos abaixo, quando utilizados, não exigem a exportação dos dados: • Create table…as 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 reorganização podemos especificar várias opções que, salvo algumas exceções, podem ser combinadas entre si: • Compress extents: a fragmentação será reduzida para apenas 1 extent (INITIAL) • Reduce object size: o sapdba tenta analisar qual a quantidade real de memória necessária e realoca o novo storage baseado neste valor • Chop = yes: o export dos dados se dá através de um pipe file, permitindo splitar o dumpfile em vários arquivos menores, atendendo as limitações do sistema operacional (2G em alguns casos). Esta opção estará disponível a partir do momento em que se especifica o parâmetro chop_util_name na init<SID>.dba • Compress = yes: um dumpfile do export é comprimido • Parallel export/import: o export e import é distribuído através de vários processos paralelos • ORACLE parallel clause: utiliza a facilidade oracle para acelerar o processo de reorganização João Luiz Barbosa Junho/2000 Página 129 ACADEMIA BASIS CEMIG Performance Monitor Performance Issues A performance de um database Oracle está relacionada com quatro fatores básicos: • No layout físico e lógico do banco • No desempenho do aplicativo • Na configuração da memória • No CBO – Cust Based Optimizer Cost-Based Optimizer Reasons for performance problems O CBO é um mecanismo introduzido no Oracle que determina a estratégia mais eficiente para acessar um determinado dado, baseado nas tabelas especificadas, nos campos informados na cláusula WHERE e nos índices disponíveis nas tabelas. O CBO computa todas as estratégias disponíveis e escolhe aquela que sai mais barata em termo de acessos. Para ter parâmetros de comparação, o sistema precisa se basear em estatísticas atualizadas referentes às tabelas e índices, como por exemplo número de linhas, número de data blocks e números de valores distintos em cada coluna da tabela. Estas estatísticas ficam armazenadas no dicionário do Oracle e são recolhidas através do comando Oracle analize table. Informações antigas ou inexistentes, assim como informações incorretas sobre a distribuição dos dados poderá induzir o otimizador a tomar decisões incorretas sobre o melhor caminho a seguir. Refreshing the object statistics Estes problemas porém são facilmente resolvidos através de um refresh das estatísticas ou ainda através de um ajuste fino no procedimento SAP para as rotinas de analyse efetuadas através do processo two-phase (check e analyze). Os processos mais críticos de performance poderão eventualmente ser ajustados através de mudança no critério de cust-based para rule-based ou finalmente por alterações no aplicativo.. A SAP recomenda que somente se utilize as ferramentas SAP (SAPDBA e CCMS) para atualizar as estatísticas da base R/3, já que existem regras particulares que quando não forem seguidas poderão introduzir sérios problemas de performance. Com a finalidade de diminuir o tempo envolvido no refresh das estatísticas, a SAP introduziu o conceito da estratégia two-phase. Este procedimento consiste em uma primeira passada onde será determinado quais objetos necessitarão de refresh e numa segunda fase apenas os objetos selecionados sofrerão o refresh. O comando a ser executado na primeira passada é o sapdba –checkopt [options]. Ele determina quais tabelas precisam de refresh e armazena sua decisão na tabela DBSTATC. Esta decisão é tomada baseado no critério de que o número 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 necessários (normalmente para os objetos com flag ativo na dbstatc). Modifying the standard procedure A tabela DBSTATC contém campos como o nome do objeto, o método utilizado (se estimate ou compute), o percentual ou número de linhas a ser analisado e ainda um tag indicando se a tabela necessita de refresh. A transação DB21 permite efetuar alterações e novas entradas nesta tabela. A nota 122718 indica regras e tabelas críticas que deverão ser observadas. João Luiz Barbosa Junho/2000 Página 130 ACADEMIA BASIS CEMIG Repetindo o processo : • A primeira fase (sapdba –checkopt) grava uma log no diretório sapcheck (<timestamp>.opt) e deve ser monitorado após a execução pela transação DB14 • A segunda fase (sapdba –analize DBSTATCO) efetua um refresh apenas dos objetos que estiverem flagados na DBSTATC. Após a execução, as linhas permanecerão na tabela DBSTATC porém o flag de “refreshable” é retirado O procedimento standard da SAP é não criar nenhuma estatísticas para tabelas pool e cluster retirando inclusive qualquer estatística 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 não possui estatísticas disponíveis é setado pelo parâmetro opmizer_mode = choose da init<SID>.ora. A SAP recomenda que estas duas fases do procedimento de refresh das estatísticas seja schedula através da transação DB13. O comando sapdba –analyze grava uma log no diretório sapcheck (<timestamp>.aly) e deve ser monitorado após a execução pela transação DB14. O CBO Control Panel (transação DB21) permite modificar o procedimento padrão de refresh das estatísticas, seja aumentando a precisão requerida para uma determinada tabela ou eliminando suas estatísticas (para que se use o rule-based optimizer) Memory Configuration A System Global Area do Oracle (SGA) contém 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 rápido que quando trazido do disco. O processo de atualização altera o dado no data buffer e a transferência para o disco é feita mais tarde, assincronamente. A transação ST04 exibe os dados referentes a performance do banco de dados e deverá ser utilizada nas análises 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 análise deste valor somente tem validade algumas horas após o statup do database, quando o data buffer já atingiu uma estabilidade de runtime. Uma boa regra é aguardar pelo menos até o número de reads ultrapassar os 20.000.000. Um valor abaixo de 94% indica uma necessidade de aumentar o número de blocos (parâmetro DB_BLOCK_BUFFERS), o que poderá inclusive forçar um incremento na memória RAM para não aumentar a paginação (analise a paginação pela ST06). Antes porém 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 máximo de memória que pode ser alocada na shared memory, não 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 são armazenados para serem compartilhados pelos shadow prcesses e da Row Cache, que armazena informações do dicionário Oracle, incluindo aqui as informações de estatísticas que serão utilizadas pelo CBO. O conceito de user call são os acessos efetuados pelos shadow processes na shared SQL area. Recursive calls são as leituras físicas efetuadas pela row cache ao dicionário Oracle. Os principais pontos a serem observados em relação a shared pool são : • A relação 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 relação reload/pins deverá ficar abaixo de 1% João Luiz Barbosa Junho/2000 Página 131 ACADEMIA BASIS CEMIG Valores inferiores nestes parâmetros indicam uma necessidade de aumentar a shared pool area. Como não existe parâmetros específicos para SQL area e row cache separadamente, o aumento deverá ser de toda a área, utilizando o parâmetro SHARED_POOL_SIZE. As mesmas recomendações 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 consistência, 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 estarão com o work process ocupado, apesar de não estarem processando nenhuma transação, mas em wait por um determinado dado. A transação 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 contenção por lockwait é necessário muitas vezes reanalisar o aplicativo para emitir commits mais frequentes e garantindo que as transações segurem os objetos pelo menor tempo possível. Locks podem também ser evitados se os processos puderem ser schedulados para rodarem em diferentes horários Unnecessary SQL statements São comandos que poderiam ser evitados por uma reestruturação do programa evitando comandos dentro de loops WHILE. A opção detail analysis da ST04 permite listar os comandos SQL na shared SQL area. Procure por comandos que são muito executados e que possuam baixa taxa de buffer gets por record. Estes comandos deverão 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 proporção estar abaixo do 5%. Ou seja, qualquer comando que provocou mais do que 5% dos reads do data buffer deverá ser analisado. Esta análise passará certamente por um explain plan para verificar a estratégia adotada pelo otimizador para o acesso. Estando as estatísticas corretas, este comando precisará ser reanalisado, seja através da abertura de um chamado OSS (comando de programa standard SAP) ou pela verificação se o comando não foi mal especificado pelo ABAPer. O explain dá a opção de explain with hint, que permite analisar outras alternativas de acesso aos dados Poorly qualified statements Normalmente este problema ocorrerá quando o SQL não utiliza os índices corretamente. Estes comandos aparecem sempre com um número elevado de bufgets/record. A causa deste problema é varia desde uma ausência de índices até em problema com as estatísticas da tabela que estão direcionando o otimizador para um caminho errado. Índices standard do R/3 somente deverão ser alterados com o aval da SAP. O comando explain plan mostra se o índice está sendo utilizado ou não no comando SQL. Uma das causas mais prováveis deste problema é o fato do índice estar definido no dicionário do R/3 mas não está ativado, por exemplo devido a uma reorganização que não foi até o final. Através da DB02 é possível exibir os missing indexes. Esta informação fica disponibilizada a partir do report RSORATDB que é triggado pelo performance collector (RSCOLL00) João Luiz Barbosa Junho/2000 Página 132 ACADEMIA BASIS CEMIG 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 contenção por produzirem volumes elevados de I/O. Aplicativos mal projetados frequentemente causam este problema A transação 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, é necessário certificar-se de que o read time não exceda 30 ms e o write time, 50 ms. Filesystems times que desviam mais que 20% da média serão possíveis hot spots. Estes valores poderão variar entre as várias plataformas e hardwares disponíveis, cabendo talvez uma análise mais cuidadosa destes targets. A contenção de I/O é solucionada através da identificação dos hot spots e a posterior distribuição dos datafiles entre os dispositivos e canais. A opção total per device é um excelente auxílio nesta decisão Checkpoint not complete O sistema Oracle efetua a gravação de checkpoints, que consiste na sincronização 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 são 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 não conseguiu ser arquivada. O Oracle congela as atualizações e aguarda que o processo de checkpoint finalize, os archives sejam efetuados e consequentemente exista online redo disponível para gravação. A mensagem de checkpoint not complete é gravada no alerte do Oracle (…/saptrace/background/alert_<SID>.log). A ocorrência muito constante deste problema pode sugerir a criação de mais grupos de relo logs. A SAP não recomenda aumentar o tamanho das redo log, exceto se o tempo de switch estiver abaixo dos 3 minutos Rollback statement problems Os rollback segments são utilizados no Oracle para gravar imagens before que poderão ser úteis para desfazer transações não commitadas. Outra função destes rollback segments no Oracle é garantir consistência na leitura de dados . Isto significa que se um determinado registro foi alterado por uma transação depois que outro query iniciou um processamento, quando chegar o momento da requisição do registro o Oracle entrega a imagem before e não a atual ou seja, aquela que estava corrente no momento em que a transação iniciou e ficou armazenada no rollback segment. Estas imagens permanecerão no rollback segment mesmo após o commit. O problema que pode ocorrer é um rollback segment commitado pode vir a ser reutilizado por outra transação 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 não poderá mais fornecer a imagem before. Neste caso a transação que estava efetuando o query recebe o abend ORA-1555 (snapshot too old). Para evitar a ocorrência de ORA-1555, é preciso tentar evitar que programas de query sejam schedulados durante períodos de alto volume de atualização, tentar otimizar o runtime dos programas que abendam com 1555 ou, se nada mais funcionar, aumentar o número (preferencialmente) ou o tamanho dos rollback segments O dimensionamento correto dos private rollback segments (aqueles que são especificados no init<SID>.ora) é preciso partir de uma análise dos rollback segments atuais através da visão V$ROLLSTAT: João Luiz Barbosa Junho/2000 Página 133 ACADEMIA • • • • • BASIS CEMIG Caso o somatório dos WAITS de todos os rollback segments representem mais do que 1% do somatório dos GETS isto indica contenção, ou seja, é necessário definir mais rollback segments valor OPTIMAL representa a marca até onde os rollback segments que sofreram alocação de extents irão encolher na operação de shrink valor HWMARK é a marca d’água do segmento. É um bom indicativo de qual deverá ser o valor do parâmetro OPTIMAL para eliminar os extend/shrinks, porém deve ser analisado com cuidado pois pode se tratar de uma demanda isolada Os campos EXTENDS e SHRINKS representam o número de alocações/dealocações acima do valor OPTIMAL. Para calcular o valor do OPTIMAL ideal, utilize a fórmula: new OPTIMAL = OPTIMAL + (EXTENDS – SHRINKS) * NEXT. Com isto será especificado um valor para o optimal que não causará mais os extends/shrinks. volume ideal de alocação de extents deverá ficar na casa dos 20. Com isto podemos calcular os parâmetros de storage: INITIAL = NEXT = OPTIMAL/20 Fragmented indexes Índices fragmentados são caracterizados por um baixo volume de preenchimento dos blocos e, pior ainda, por uma distribuição da árvore em mais de 3 níveis. Esta fragmentação é normal e vai acontecendo ao longo das operações de atualização que uma tabela vai sofrendo. Tabelas com alta volatilidade ou volumes elevados de deleção, como acontece durante uma operação de archiving, esta fragmentação se acelera. O resultado da fragmentação 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 transação 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%. É possível também disparar um validate index (em modo dialog ou background) para analisar o número de níveis das folhas. João Luiz Barbosa Junho/2000 Página 134 ACADEMIA BASIS CEMIG Quinta Semana Top 10 Problems Esta seção irá listar os 10 problemas mais comuns que podem ocorrer na administração de uma base de dados Oracle com o R/3. O principal objetivo é reconhecer, solucionar e principalmente prevenir a ocorrência de tais fatos Uma utilização criteriosa e diária do sapdba –check ajuda a prevenção dos principais erros no Oracle. É necessário ainda o monitoramento constante das transações ST22, SM21 e dos traces e logs do R/3 e de suas ferramentas Archive Stuck Situation O travamento de uma instância Oracle devido a incapacidade de gravação 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 monitoração constante do filesystem saparch e uma metodologia consistente de arquivamento implantada evita a ocorrência deste problema. Manter um dummy file na área saparch para ser excluído em casos de stuck ajudam a ganhar um fôlego a mais enquanto se providencia um arquivamento emergencial. The Incorrect Tape Size Drivers with Hardware Compression Um dimensionamento incorre do parâmetro tape_size do init<SID>.sap poderá causar desde erros durante a gravação até, o que ainda mais grave, problemas quando se tenta recuperar a fita em um restore. Reserve sempre um espaço 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 cálculo do tape length * write density, que variará de modelo para modelo de fita e do processo utilizado na gravação, se comprimido ou não A Missing “End Backup” Quando um tablespace é backupeado em modo online, é necessário que o mesmo seja colocado em backup mode através do comando begin backup antes de iniciar a cópia. Este modo permanecerá até o final da cópia quando então o tablespace é retirado do backup mode através 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 operação. Se o shutdown immediate vier através 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 operação Caso a instância 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á necessário efetuar um partial restore and complete recovery dos tablespaces afetados João Luiz Barbosa Junho/2000 Página 135 ACADEMIA BASIS CEMIG 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 alocação se dará em área contígua e no tamanho especificado pelo parâmetro NEXT do objeto. Caso o tablespace não 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 monitoração constante do critical objects pela DB02 ou do sapdba –check ajuda a prevenir esta ausência de área e a tomar as medidas necessárias antes que o erro ocorra. O erro será corrigido pela alocação 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 após cada mudança estrutural dos arquivos. A Table or Index Reaching the MAXEXTENTS Limit Quando o número de extents de um objeto atinge o valor especificado no parâmetro de storage MAXEXTENTS, o sistema não 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 especificação correta do parâmetro NEXT. O comando sapdba –next efetua uma adaptação do parâmetro NEXT das tabelas e índices baseado em critérios bem estabelecidos no dicionário do R/3. Este comando deverá estar schedulado para rodar pelo menos uma vez por semana na instalação (utilize a DB13) ou então esporadicamente quando se tem consciência de crescimento anormal de tabelas (carga em batch, etc.) O problema pode ser contornado temporariamente através da especificação de novo limite para o parâmetro MAXEXTENTS. Porém quando o sistema atingiu este limite já deverá ter ocorrido um elevado volume de fragmentação da tabela, devendo ser planejado uma reorganização para o objeto o mais cedo possível. Nunca especifique um valor unlimited para o parâmetro MAXEXTENTS nos objetos de um banco utilizado pelo R/3 Oracle Error ORA-1555, Snapshot Too Old Para garantir a consistência na leitura, o Oracle implementa um mecanismo que garante aos queries submetidos ao banco um nível de pesquisa que permite obter todos os seus registros desejados no estado em que estavam no início do SQL. Este mecanismo funciona através do fornecimento de eventuais valores alterados após o início do query com suas imagens before que se mantém armazenadas nos segmentos de rollback. Comandos de update que sofreram commit permanecerão com seus pointers ainda alocados para a área de rollback podendo porém ser sobre escritos por novas transações, 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, irão receber um erro ORA-1555 indicando snapshot too old, abortando o processo. Antes que se parta para uma alteração da configuração dos segmentos de rollback, vale identificar o comando que esteja provocando o erro e verificar alternativas para a sua execução, inclusive planejando o seu schedule para horários de menor atividade no banco Net8 TCP/IP Delay O Net8 é a camada de comunicação entre os application servers e o banco de dados. Comunicações na mesma máquina utilizarão IPC (inter process call) e remotamente o protocolo TCP/IP. João Luiz Barbosa Junho/2000 Página 136 ACADEMIA BASIS CEMIG A implementação default do Oracle utiliza o modo de configuração do Net8 em delay mode, o que introduz um ciclo de espera de aproximadamente 200ms nas comunicações dos processos Este problema pode ser solucionado através do arquivo protocol.ora que pode ser obtido do sapservX. Em seguida copie este arquivo para o diretório /oracle/<SID>/network/admin com read permissions para os usuários <sid>adm e ora<sid> em todos os applications e no db server. Para que o novo modo se torne operativo, é necessário parar todas as instâncias (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 corrupção 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 após a ocorrência do erro. Se o problema ocorrer em um bloco de índice, basta reconstruir o índice danificado. Table blocks danificados somente poderão ser solucionados através 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 difícil voltar um backup antigo sem afetar seriamente o negócio de uma empresa. Além disso o próprio backup já poderia estar danificado. Para garantir que os blocos danificados sejam detectados no momento do backup, schedule o brbackup com a opção use_dbv, como visto anteriormente. Um processo constante de verificação do banco através de ferramentas Oracle (DB verify e dbv) também garantem a monitoração constante da base de dados, minimizando as consequências de qualquer ocorrência 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 ocorrências do erro. Poor Performance of the Cost-Based Optimizer O CBO determina a maneira mais eficiente de acessar uma determinada tabela baseado em estatísticas armazenadas no dicionário Oracle. Qualquer incoerência nestas estatísticas causada pela não atualização dos dados poderá direcionar o otimizador para decisões que causarão sérios problemas de performance. Garanta que estas estatísticas sejam atualizadas regularmente através do shedule das duas fases (check e analyse) na DB13. João Luiz Barbosa Junho/2000 Página 137 ACADEMIA BASIS CEMIG Introduction to Workload Analysis Performance Problems A workload analysis consiste em aplicar métodos específicos de análise 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 transações e aumentar o throughput do sistema. Tempos de resposta ruins deverão ser analisados localizadamente (por transação) ou no sistema como um todo (média geral dos tempos de resposta), dependendo da forma como o problema se manifesta. Basis Tuning Uma análise 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 definições dos work processes e dos buffer das instâncias Application Tuning Um tuning localizado de uma aplicação tem por finalidade evitar que programas mal especificados produzam uma carga desnecessária no ambiente. Esta análise vai desde a localização e aplicação de notas do OSS até a otimização dos códigos dos programas desenvolvidos na instalação (programas Z). Eventualmente esta análise chega a conclusão de que é necessário criar novos índices ou bufferizar algumas tabelas do sistema. Response Times O tempo de resposta (response time) de uma transação no R/3 é o tempo entre a requisição do usuário ao sistema e vai até o retorno da próxima tela, podendo ser dividido em vários componentes individuais que permitem uma análise mais profunda no componente causador da má performance. O tempo de transmissão (rede) não é 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 atribuição ao work process • Roll in time: o tempo necessário para efetuar o roll in dos dados de contexto do usuário para dentro do work process • Load time: o tempo necessário para carregar os objetos (e eventualmente gera-los) do dicionário ABAP para os buffers da instância • Processing time: é o tempo gasto para processamento dentro do work process, equivalendo a diferença entre o response time e a soma dos demais tempos • Database request time: tempo de processamento dos SQL, que começa quando a requisição é 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 são colocados em uma fila de espera FIFO pelo dispatcher. Um elevado tempo de permanência nesta fila indica indisponibilidade de work process. Esta indisponibilidade pode entretanto vir de uma pequena definição de número de work processes como também pode significar que os work processes não estão sendo liberados com a rapidez esperada. Elevados wait times merecem uma análise menos simplista e esta normalmente associado a problemas generalizados no sistema. João Luiz Barbosa Junho/2000 Página 138 ACADEMIA BASIS CEMIG Roll in time Roll in é a transferência dos dados do contexto do usuário (autorizações e ponteiros para as áreas de trabalho) do roll buffer para a roll memory do work process. Ao efetuar esta transferência tem-se início ao processamento do dialog step. Tempos elevados de roll time podem indicar problemas no gerenciamento de memória do R/3 ou ainda gargalos de CPU para efetuar a operação. Database time Quando um dado é requisitado via um open SQL, a requisição é enviada para o database interface do work process que efetua o request localmente nos database buffers da instância ou envia a requisição 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 disponibilização dos blocos de dados ao work process. Tempos elevados no componente database podem indicar gargalos na instância DB, problemas de rede (se outra instância), comandos SQL caros, falta de índices, enfim uma série 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 aplicação. Tempos elevados normalmente significam loops no programa eu erro na construção da aplicação. CPU time O tempo de CPU consumido pelo work process durante um dialog step é computado no CPU time. Entretanto não só este, no cpu time estão 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 lógica do programa ABAP, tais como processamento de tabelas muito extensas ou sobrecarga da cpu em função de outros processamentos que estão concorrendo na máquina. Workload Statistics O Performance Monitor (transação ST03) dá informações detalhadas e estratificadas dos tempos de resposta em em sistema R/3 A proporção apresentada entre o número de database calls e os database requests dá uma noção exata da eficiência da buferização de tabelas, indicando o número de requests que tiveram que ser encaminhadas ao DB server pelo database interface. As chamadas externas de funções RFC podem provocar roll out do user context para liberação do work processes. A espera pelo retorno (roll wait) e posterior roll in, todos estes tempos ficam embutidos no roll time do dialog step. Transações com elevado número de chamadas RFC tendem a ter um roll time mais elevado que as demais. Workload Analysis O workload analysis é feito através da transação ST03. Esta transação viabiliza a analise da carga no sistema em qualquer momento no tempo (passado agrupado por periodo ou um snapshot dos ultimos minutos) Uma análise geral (a partir da seleção de um período de tempo que seja conveniente para a análise) pode indicar se existem problemas de performance gerais na instalação, como por exemplo : • Wait time maior que 10% do response time • Main menu () com tempo de execução superior a 100 ms João Luiz Barbosa Junho/2000 Página 139 ACADEMIA BASIS CEMIG Através 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 não pode ser muito inferior ao processing time De qualquer forma temos que ter em mente que os sintomas abaixo normalmente estão associados a tipos padrões 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 estão pequenos • Large database request time – gargalo na cpu ou memória na máquina 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 função 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 comunicação 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 configuração de memoria do R/3 • Buffer de programas muito pequeno • Roll-in time > 20ms ou roll-out time > 20ms • Analise detalhada da configuração de memoria do R/3 • Problemas com memoria extendida ou roll buffer • Perfil de transação (st03 classificado por temo de resposta) • Programa com cpu alta : cpu time > 40% (response time – wait time) • Analise detalhada do trace do abap em questão • Programa com db alto : database time > 40% (response time – wait time) • Analise detalhada do sql em questão Processing times muito superiores ao CPU time indicam gargalos de CPU ou problemas de comunicação. A opção de transaction profile da ST03 exibe a distribuição dos tempos por transação, permitindo análises individualizadas, permitindo efetuar esforços de tuning nas transações mais utilizadas. Podemos utilizar a transação STAT exibe estatísticas individualizadas por uma série de fatores. Para auxiliar a análise devemos utilizar as transações : • 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 João Luiz Barbosa Junho/2000 Página 140 ACADEMIA BASIS CEMIG Performance Analysis Monitors Work Process Overview A transação SM50 permite a monitoração dos work processes de uma instância R/3. A monitoração 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 • Ação “Dir. Read”, “Seq Read”, “Insert”, “Update”, “Delete”, “Commit • Analise detalhado do banco de dados • Ação “Load Report” • Analise detalhada da configuração de memoria do R/3 • Buffer de programas muito pequeno • Ação “Roll-in” ou “Roll-out” • Analise detalhada da configuração de memoria do R/3 • Problemas com buffer de memoria extendida ou de roll • Work process com status stopped • Reason PRIV • Analise detalhada da configuração da memoria do R/3 • Problemas com buffer de memoria extendida ou de roll buffer • Reason CPIC • Problemas com conexão CPIC como “todos work process bloqueados” ST06 - Operating System Monitor A transação que permite a monitoração do sistema operacional no R/3 é a ST06, que exibe informações sobre utilização de CPU, swaps, utilização de discos e configuração 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 número total de CPUs disponíveis Problemas de alto consumo de CPU podem ser identificados através da análise dos topCPU processes, no detail analysis. disp+work são os processos R/3 e ORACLE80 é um processo de banco de dados. Nesta janela devemos observar os percentuais de utilização da cpu (devem estar com pelo menos 10% de idle), o load average (indica quantos processos ficaram aguardando por cpu), paginação (sempre inferior a 10% da memória física) ou swap alocado em arquivos e não liberados pelos work process. ST02 - Buffer Monitor A transação ST02 é o monitor dos buffers do R/3, indicando tamanhos, qualidades e percentuais de ocupação de cada um deles. Devmos observar que o percentual de utilização dos buffers devem estar sempre acima de 95% além do cuidado especial com swaps excessivos e com os possívies gaps no buffer de programas. Quando detectamos que a extended memory atingiu 100% de utilização ( Max use = In memory), começarão a aparecer contenções de memória para os work processes. Roll area com valores de Max use superiores ao In memory indicam que a utilização de roll area teve que ser expandida para disco, o que é ruim João Luiz Barbosa Junho/2000 Página 141 ACADEMIA BASIS CEMIG R/3 Memory Management R/3 Memory Areas A memória física é a memória em RAM instalada na máquina. A área de swap é uma área em disco pelo sistema operacional para paginar a memória utilizada pelos processos. quando alocamos uma memória em um sistema operacional, estamos efetuando uma alocação de memória virtual. O sistema operacional é quem decide se a memória alocada estará em disco ou em memória física. Dependendo do sistema operacional utilizado, a memória virtual terá um valor entre o swap especificado e a soma do swap com a memória real. Uma instância possui duas áreas básicas de memória: local memory e shared memory Local Memory É a memória associada com cada work process. Esta memória é utilizada para: • Executáveis • Dados, stack • Buffer para transferência de dados • Local roll area • Local paging area Heap Fazendo parte da memória local mas não diretamente temos a heap area. A heap memory é alocada pelo work process diretamente na área de swap. Work processes que começam a utilizar heap area entram em PRIV mode, desta forma não efetuando mais roll out/roll in, ficando desta forma dedicado ao usuário. Shared Memory A shared memory é o agrupamento das áreas globais que serão compartilhadas pelos work process. Ela é subdivida em buffers, roll area, paging area e extended area. Buffers Memória alocada na shared memory e que contém objetos globais de todos os usuários e work processes, tais como programas e tabelas de customização. Extended A extended memory contém dados de contexto associados com a transação de um determinado usuário, tais como variáveis, listas, tabelas internas, etc. Ela é alocada a medida do necessário em pequenos blocos e é preservada de um dialog step para o outro. Roll A roll memory é alocada no roll buffer e contém a parte inicial do contexto do usuário. Ela contém ainda os ponteiros para a extended memory que está sendo utilizada pela transação corrente. Paging É uma área utilizada pelos work processes na paging area (shared memory) para determinadas operações de abap. Ela normalmente está associada a dados relacionados a subfunções abap. João Luiz Barbosa Junho/2000 Página 142 ACADEMIA BASIS CEMIG Allocation Concepts Os work processes são compartilhados pelos vários usuários que se conectam a uma instância. Este compartilhamento efetuado a cada dialog step (ou chamada RFC) força o R/3 a manter um mecanismo que salve os dados do usuário e permita o reinicio do processamento quando solicitado pelo usuário no próximo dialog step. Estes dados referentes a um determinado usuário é denominado user context area. Este conceito permite por exemplo que um determinado código de material que o usuário trabalhou em uma transação seja “lembrado” como default na próxima transação. O conceito de roll out salva a user context area garantindo assim que os dados de um usuário não sejam sobrescritos pelos usuários que utilizam o mesmo work process posteriormente. Os dados são movidos (rolled out) para disco. O próximo 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 contém os dados de contexto do usuário associados a autorizações, internal tables e report lists. A paging area contém a memória associada a alguns comandos específicos de ABAP. A extended memory é alocada na shared memória e disponibilizada para os work processes que podem requisitar pedaços de memória que ficam mapeados nos work process através de pointers armazenados na respectiva roll area. Isto permite diminuir o contexto de roll out/in apenas para referências (pointers) à extended memory alocada. Allocation Sequence A fim de minimizar o volume de dados necessários para as operações de roll in/out, o sistema R/3 procura otimizar a alocação de memória através de uma metodologia nesta operação. Inicialmente apenas uma poção mínima da roll area é alocada, definida pelo parâmetro ztta/roll_first. Quando este parâmetro é setado para 1, um mínimo de 100K será alocado para o processo. Quando o processo necessitar de área para trabalho, o sistema alocará memória na extended memory da shared memory e grava na roll area do work processes apenas um pointer para a área alocada. Esta aquisição de memória na extended memory vai sendo permitida até que não haja mais memória disponível ou então quando o work process atinge a sua cota de alocação, definida pelo parâmetro ztta/roll_extension. Esta área não será copiada durante o processo de rolagem, mas sim mapeada, ou seja apenas as referências (pointers) serão copiados. Quando se esgota a alocação de extended memory o work process começa a alocar o restante da roll area disponível, o que acaba aumentando a quantidade de area sujeita a roll out/in. O limite a ser utilizado para alocação é definido no parâmetro ztta/roll_area. O último passo quando se esgota a roll area é alocar memória 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 usuário até o término da transação. A quantidade máxima de área que pode ser alocada na heap area para cada work process é definida pelo parâmetro ztta/heap_area_dia. A partir do release 4.0 do SAP os demais work processes, como batch work process, também utilizam este mesmo critério para alocação de memória. 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 usuário. Esta área heap é liberada no término da transação porém não será liberada na swap area do sistema operacional. Esta área somente será liberada se matarmos (kill) o processo (disp+work) a nível de sistema operacional. Existe um parâmetro (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 término da transação. João Luiz Barbosa Junho/2000 Página 143 ACADEMIA BASIS CEMIG R/3 Extended Memory Quando se utiliza um novo parâmetro do R/3, o PHYS_MEMSIZE, ele permitirá que o próprio R/3 gerencie a sua alocação de extended memory até um limite definido por em/max_size_MB. Este procedimento simplifica a administração de memória (não é necessário definir mais nenhum outro parâmetro) e é denominado Zero Administration Memory Management. Para limitar, neste caso, a utilização da extended memory por um usuário utilize o parâmetro em/address_space_MB. Para maiores detalhes veja a nota 88416. O tamanho máximo da memória alocada para extended memory (parâmetro 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 informações pequise notas associadas ao sistema operacional. Deverá sempre haver uma quantidade suficiente de memória real compatível com a parametrização do R/3 para evitar paginação excessiva de sistema operacional. Analysis Roadmap: R/3 Memory Configuration (ST02) ST02 • Esta acontecendo muitos swaps • Se existe memória física disponível, aumente o tamanho do buffer em questão • A extended memory está cheia : Max used > 80% in memory • ST02 – analise detalhadamente a memoria através do Mode List • Existe algum usuário com alto consumo de memória extendida • Identifique e analise os respectivos relatórios e transações • Se existe memória física disponível, aumente o tamanho da memória extendida • ztta/roll_first > 1024 ? • ztta/roll_first = 1 • Roll buffer está cheio ou Max. used é maior que 80% • Se existir memória física disponível, aumente o parâmetro rdisp/roll_SHM. João Luiz Barbosa Junho/2000 Página 144 ACADEMIA BASIS CEMIG Hardware Capacity Verification Hardware Bottlenecks Um gargalo causado por hardware no R/3 reflete em um elevado tempo de resposta das transações. No sistema operacional este problema se manifestará através de um elevado consumo de CPU (próximo a 100%), altas taxas de paginação, 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 paginação (ST06 à double click Paged in [Kb/h]) por hora acima de 20% da memória RAM indicam problemas de memória. 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 Contenções de CPU podem ser resolvidas através da distribuição da carga entre os demais applications, quando possível. Processing time > CPU time x 2 geralmente indica problemas gerais de performance associados a hardware, sendo necessário pesquisar mais fundo a causa do gargalo. A causa do elevado consumo de CPU pode muito bem estar associado a processos rodando na máquina que consomem muito ciclo. Se houver gargalo de memória, 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 memória de todos os servers. Defina os buffers do R/3 entre 200MB e 500MB por instância. Em unix cada work process consumirá aproximadamente 11.5 MB (7.5MB no NT). Cada usuário logado consumirá de 5 a 10MB de extended memory. A RAM física deverá ser aproximadamente 2/3 da memória usada. A memória virtual alocada pode ser visualizada através da ST02 à Detail analysis à Storage. O swap deverá ser de 3 x RAM (no mínimo 2GB). Considere nos cálculos o número de usuários ativos e o peso dos aplicativos que serão 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 usuários/aplicativos utilizados João Luiz Barbosa Junho/2000 Página 145 ACADEMIA BASIS CEMIG Expensive SQL Statements Detecting Expensive SQL Statements Comandos caros de SQL podem aumentar o database time das transações 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 prática 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 estão sendo trabalhados em buffers e/ou disco gerando novas contenções de IO e CPU. Resultado, o wait time acaba por ser o sintoma mais caracteristico apesar de não 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 transações utilizadas nestas análises serão: ST03, SM50/SM66, ST04, ST05 e SE12. Devemos focar a pesquisa para identificar o nome da tabela em questão, a clausa where utilizada, os indices envolvidos e principalmente o report ou a transação que contém o statement que está provocando o gargalo. Como visto anteriormente, através da ST03 à Transaction profile, transações com database time e/ou cpu time superiores a 40% do response time – wait time deverão 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 Através da SM50 e SM66 também é possível efetuar análise de programas com elevados tempos de resposta, além da identificação direta de quem é o causador (usuário e código 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 também podem ser identificados através da monitoração dos buffer gets (ST04 à Detail analysis à SQL statement) com elevadas taxas. Além dos buffer gets devemos observar os gets/execution, records/execution e disk reads. João Luiz Barbosa Junho/2000 Página 146 ACADEMIA BASIS CEMIG Detail Analysis and Tuning Expensive sql statement sempre efetuam elevados volumes de buffer gets durante a sua execução. 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 são resultado de estratégias ineficientes de acesso ao banco de dados, seja pela ausência de índices ou pela ausência de estatísticas 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 método 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. Através de um explain no comando SQL podemos decidir pela criação ou não de um novo índice secundário. Ao criar índices posicione os campos mais seletivos no início do índice e não especifique mais do que 5 campos. Evite definir mais do que 5 índices por tabela, principalmente naquelas que sofrem muita atualização, como é o caso das tabelas que armazenam dados transacionais. Através do explain é possível verificar a estratégia de acesso que o otimizador está utilizando para executar o comando SQL. Caso a estratégia esteja saindo cara, verifique se existe caminho mais otimizado, se a causa não seria desatualização das estatísticas ou ausência real de índice secundário. 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 decisão precisa que as estatisticas das tabelas e dos indices estejam atualizadas. Basicamente ele precisa saber qual é a distribuição estatistica de cada campo no indice, quantos níveis compõe o indice e qual a quantidade de registros da tabela. Se estes valores não existirem ou se estiverem desatualizados o otimizador certamente não fará a opção 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 transação DB13. Tips for Optimizing ABAP Uma boa opção para a otimização dos programas abaps é o uso to Tips&Tricks (transação ). Através dessa transação podemos construir comandos sql e testar a sua efetividade. Nessa transação ainda temos uma série de sugestões e opções de implementações 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 João Luiz Barbosa Junho/2000 Página 147 ACADEMIA BASIS CEMIG Table Buffering Concepts A instancia R/3 possui uma série de buffers para otimizar o processamento e a manipulação dos dados. Os principais buffers que são utilizados são os de objetos do repositório, de tabelas, de programas, de janelas, de roll e paging, calendarios, number range, etc. A principal vantagem dos buffers é a otimização e minimização do acesso a base de dados com a manutenção dos dados mais acessados na memória do sistema. As tabelas de um banco de dados relacional são as principais beneficiadas com esta estratégia. O tempo médio de acesso a um dado buferizado é reduzido drasticamente. Este é um sofisticado mecanismo e é especializado categorizando a formas de buferização. As três formas possiveis são : • Full buffering, onde a tabela é completamente buferizada e todas as suas linhas vão para a memória no primeiro acesso • Generic buffering, onde um número de campos identificadores é declarado e toda a fatia de dados acessada e relacionada a esta fatia é carregada na memória. Tipicamente esta estratégia é utilizada para as tabelas dependentes de mandante pois é necessário declarar o numero de campos (normalmente 2 ou 3) que compõe a chave de buferização • 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 cópia que está no buffer. Synchronization É claro que temos que ter um tratamento especial se o dado que está no buffer for alterado por outro usuário. A regra é simples e se baseia em alterar o dado na base de dados e o buffer da instância de forma a garantir a completa consistencia do dado na instância que provocou a alteração. Para as demais instâncias temos que ter um mecanismo mais complexo. Esse mecanismo baseia na definição feita no parâmetro rdisp/buffrefmode e na manipulação da tabela DDLOG. Esse parâmetro é que define o comportamento do sistema quando um dado que está em buffer é alterado. Os valores possíveis são : • 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 sincronização de outras instâncias (se elas existirem) • Execauto, garante que de tempos em tempos (definido pelo parâmetro rdisp/bufreftime) a instância varre a tabela DDLOG para invalidar os dados que estão no buffer garantindo assim que na próxima 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 estão no buffer A regra geral para o rdisp/bufrefmode é a seguinte : • Single system (sistema com apenas uma instância) – devemos preencher o parâmetro com sendoff,execauto que significa que toda alteração em um dado que está no buffer é atualizada na base de dados e no buffer mas não é registrada na DDLOG • Distributed system (sistema com mais de uma instância) – devemos preencher o parâmetro com sendon,execauto que garante que toda alteração no dado é propagada para o buffer local, para a base de dados e registrada na DDLOG para garantir a sincronização João Luiz Barbosa Junho/2000 Página 148 ACADEMIA BASIS CEMIG Granularity of invalidation Durante o processo de invalidação do dado quando ele é alterado (marca feita na DDLOG) os demais buffers são afetados da seguinte forma : • Full buffering, qualquer alteração invalida toda a tabela • Generic buffering e single record buffering, alterações feitas por um abap invalidam o conjunto de dados relacionado ao mesmo conjunto (mesma chave de buferização). Devemos tomar cuidado com alterações que não são executadas na work area mode pois elas invalidam todos os dados da tabela (independente da forma de buferização) Todo esse mecanismo de definição se uma tabela deve ser buferizada é feito pela transação SE13. Bypassing the Buffer Alguns comandos abaps ignoram os dados que estão no buffer. Isto acaba por evitar a otimização que o buffer realiza. Os comandos são : • Select bypassing buffer • Select from view • Select for update • Select com função de agregação (count, max, sum, avg, etc) • Select distinct • Where com is null • Order by (se não for chave primária) • Sql nativo • Non single Select em tabelas com single buffer • Select que não usa os campos corretos em tabelas com generic buffer Strategy for Technical Criteria Devemos buferizar tabelas que : • São relativamente pequenas (normalmente menores que 1 Mb) ou em casos especiais com tamano médio (menores que 10 Mb) • Não sofrem alterações (alterações < 1% das leituras) • Não precisam estar imediatamente consistentes em todo o ambiente • Podem ser acessadas pela chave primária • Contém dados de customização • Tabelas condicionais da SAP com sufixo de 000 a 499 (Annn, Bnnn, Cnnn, Dnnn, KOTEnnn, KOTFnnn e KOTGnnn) Não devemos buferizar tabelas que : • Tem tamanho superior a 10 Mb • A pesquisa por dados é feita pelo indice secundário • Contém dados transacionais • Contém dados mestres (tabelas grandes e acessadas por uma série de indices secundários) • 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. João Luiz Barbosa Junho/2000 Página 149 ACADEMIA BASIS CEMIG Optimization Para otimizar os buffers de tabelas devemos ter em mente duas tarefas básica : pesquisar por tabelas que deverião estar buferizadas e não estão e pesquisar pelas tabelas que estão buferizadas e não deverião estar. Para o primeiro caso, devemos procurar pelas tabelas desenvolvidas pelo cliente (iniciadas por Z) e tabelas de customização que normalmente não são buferizadas (sufixadas por 500 a 999). Para a segunda tarefa devemos verificar o tamanho e a frequencia de alterações que possíveis tabelas possam estar sofrendo. Para essa tarefa usaremos a transação ST10 (Table Call Statistics) e seguir o roadmap : • Pesquisar por alto numero de invalidações • Verificar se esta tabela não deve ser desbuferizada. Para isso use a ST05 e ST10 • Pesquise por tabelas com buffer muito grande • Verificar se esta tabela não deve ser desbuferizada. Para isso use a ST05 e ST10 • Pesquisar por tabelas com alto numero de rows affected • Verificar se esta tabela não deve ser desbuferizada. Para isso use a ST05 e ST10 • Pesquisar por tabelas com muitas leituras feitas por programas abaps • Verificar se a tabela não deve ser buferizada. Para isso verifique as estatisticas, a frequencia de alteração, o tamanho, a viabilidade em função da chave primária (transação DB05) e a média de consumo de processamento (ST03, database time > 40% (response time – wait time) João Luiz Barbosa Junho/2000 Página 150 ACADEMIA BASIS CEMIG Others aspects about ORACLE Cache Analysis Uma boa análise do cache está relacionada a permanente pesquisa por comandos SQL caros e por problemas de performance que não estão relacionados ao hardware ou a parametrização do banco de dados. Outro ponto interessante é a completa compreenção da arquitetura do Oracle. Isso garante uma visão abrangente do problema, a compreenção 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 estatísticas 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 memória e de I/O aos datafiles. A maior parte das análises devem ser feitas utilizando a ST04 (Database Overview Monitor). A primeira delas é a identificação 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 não devemos analisar somente este numero. Um exemplo disso é o resultado da divisão entre buffers gets por user calls. Se ele for maior que 15, o data buffer hit rate deixa de ser significativo em função do alto volume de dados que está sendo tratado. Outra analise a ser feita é a redução do numero de buffer gets. Eles indicam que, provavelmente, esse alto volume de dados que estão 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 padrão : • 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 distribuição estatística. 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 também acessa um grande volume de dados e retorna todo ele para o emissor do comando sql. Esse problema está relacionado a uma má construção 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 próprio hit ratio). Devemos estar atentos a alguns indices que indicam uma má performance, como : • Número de buffer gets maior que 5% do total de reads • Alto número de buffer gets • Alto número de buffer gets por registro • Alto número de registros por execução João Luiz Barbosa Junho/2000 Página 151 ACADEMIA • BASIS CEMIG Comandos que leêm mais que 2% do total de leituras físicas De posse de um comando aparentemente pesado para o sistema podemos analisar detalhes de como o sql foi processado através do explain. Podemos também verificar se a estatistica está atualizada e eventualmente atualiza-la especificamente para uma tabela através da transação DB20 ou criar indices mais adequados através da SE11 ou SE12 Update Statistics A estatística da distribuição de valores de tabelas no R/3 é sempre feita em dois passos. O primeiro é a verificação de quais tabelas estão com as estatísticas desatualizadas e a marcação na DBSTATC das quais devem ser refeitas. Se for necessário podemos utilizar a transação DB21 para dar manutenção na DBSTATC. O segundo passo é a atualização propriamente dita. A processo de atualização pode ser feito seguindo dois algoritmos distintos : compute (onde toda a tabela é analisada para determinar a distribuição) e estimate (onde uma amostragem é feita para determinar a distribuição). 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 necessário atualizar uma tabela específica utilizaremos a DB20. Identify Coding Um grande problema na análise da performance do sistema é a identificação de um comando sql que produz efeitos danosos ao sistema. Para localizarmos o comando utilizamos a transação ST04 (shared sql area) como já foi visto no item anterior de analise de sql. O passo seguinte é a identificação de qual código abap provavelmente contém este comando. Esse processo consiste em pegarmos o nome da tabela e listarmos, através da SE11 e where-used, onde ela é utilizada. Depois disso entramos em programa a programa para tentar localizar a origem do comando. Esse sem dúvida é um trabalho muito arduo. Outra boa opção é a identificação do comando no momento que ele acontece através das transações SM50 e SM66. Nesse caso temos a vantagem de saber quem e qual a transação esta provocando os efeitos indesejáveis. Para facilitar, podemos selecionar os processo que manipulam a respectiva tabela atráves da SM66 -> select process. Sempre que tentamos identificar o código abap que produziu o sql devemos ter em mente as diferenças entre o open sql e o sql nativo. Devemos analisar as facilidades que o open sql permite e como elas são convertidas para o sql nativo, como por exemplo as tabelas internas (in itab) ou a clausula “for all entries”. Além 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 questão. Outra opção é descobrir a área funcional através do programa RSSTATUS ou os componentes relacionados a tabela através da DB15 e acionar o time funcional responsável para ajudar na pesquisa do respectivo código abap. Workflow and Reporting Com a ativação do workflow no sistema podemos ter algumas facilidades de comunicação de documentos e a respectiva aprovação destes pelos responsáveis. Basicamente temos que definir a atribuição de cada um (por exemplo, o administrador do sistema é responsável por analisar as queries e recomendar alterações de design; o desenvolvedor é responsável por construir e otimizar os códigos e as definições de banco de dados; e o usuário final é responsável 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 após 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. João Luiz Barbosa Junho/2000 Página 152 ACADEMIA BASIS CEMIG Um bom exemplo desse recurso é a ferramenta de abrir chamados na SAP através do OSS. Essa ferramenta é que garante o bom encaminhamento das demandas dos usuários para a SAP e viabiliza a acumulação de uma base de conhecimento. Index Utilization Devemos associar a utilização de índices no banco de dados com as estatísticas atualizadas e com o otimizador de acesso baseado em custo. Sempre que utilizarmos uma clausula where (e em alguns outros casos também) o otimizador entra em ação 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 serão executadas, além das estatisticas atualizadas. Basicamente temos que preocupar com a efetividade dos indices que existem e da seleção que ele permite. Índices que não permitem a seleção de uma quantidade inferior a 4% da quantidade total de linhas não são efetivos e normalmente não são necessários. Além disso devemos estar atentos as indicações do explain do sql dos caminhos e mecanismos que estão sendo tomados em um determinado sql. Os mais importantes e que devem ser entendidos são : • Index unique scan, é o melhor caso pois permite a obtenção 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 não é muito bom pois não conseguimos saber quantos blocos serão lidos para a obtenção da informação 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 várias vezes em função de opções OR ou IN com a concatenação 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 através da simulação da criação na DB05 e da verificação da distribuição estatísticas dos valores. Durante a anális 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 não podem ser esquecidos, a saber : verificar se algum indice standard não está faltando; executar sempre a atualização de estatisticas das tabelas e dos indices; alterar o código para poder reaproveitar os indices já existentes; alterar os indices já existentes para garantir uma boa performance na maior variedade possivel de situações 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 aprovação ou com o aconselhamento da SAP. Similar Statements Tente garantir sempre que statements com a mesma função 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 convenções para garantir que os comandos sejam escritos da mesma forma em programas diferentes. Uma boa convenção a ser adotada é combinar a ordem dos campos no comando sql igual a ordem na declaração 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 começo para detectar esses comandos mas lembrando sempre que isto é um ajuste finíssimo no sistema. João Luiz Barbosa Junho/2000 Página 153 ACADEMIA BASIS CEMIG View Processing View é um objeto lógico que simula a existencia de uma tabela, virtual, que na verdade é a junção de uma ou mais tabelas. Na prática o gerenciador do banco de dados executa um sql previamente montado, que é imagem da definição da view, sempre que algum dado é solicitado da view. Ou seja, um dado que é acessado através da view não está previamente alocado a ela, ele é descoberto e acessado no momento da execução. Os principais tipos de view são : • Nested loop, onde ordem de acesso as tabelas é decida pelo otimizador com a identificação da driven table que normalmente possui a menor quantidade de registros, seguido do acesso a inner table para obtenção dos demais dados • Sort Merge Join, onde os dados das diferentes tabelas são acessados, classificados e finalmente mergeados É aconselhável que monitoremos as novas views em busca de possíveis problemas de performances. Os mecanismos a serem utilizados são os mesmos mencionados anteriormente neste capítulo. Pooled and Clustered Tables Tabelas pooled e clustered são tabelas que estão contidas em outras tabelas. Essa estrutura é herdada do ambiente mainframe e da época em que os bancos de dados relacionais ainda não existiam. Com essa estrutura podiamos viabilizar que um mesmo arquivo indexado poderia representar uma série 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 código. Os dois tipos implementados no R/3 são : 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 série de outras tabelas conhecidas como pooled tables. Isto é possivel pela definição de uma tabela pool com a seguinte estrutura : uma chave especifica que contem o nome da tabela pooled (TABNAME), um campo contendo a chave genérica (VARKEY) e um campo contendo todo o conteudo a ser acessado através da chave genérica (VARDATA). Com isso, utilizando apenas uma transparent table, podemos ter incontáveis tabelas dentro desta tabela. Clustered No R/3, a clustered table é a implementação física de um banco de dados hierarquico em uma estrutura de arquivo indexado. Essa estrutura também é oriunda do mainframe e deve ter sido mantida para garantir também o reaproveitamento. A clustered table é na prática o encapsulamento de dados de tabelas diferentes em uma mesma linha. Ou seja, é a junção de dados dependentes, mesmo que oriundos de tabelas diferentes, da mesma chave primária. A estrutura de uma clustered table é um conjunto de campos que representam a chave primária que é comum ao conjunto de dados e o DATA que é um conjunto de informações não documentadas constituidas pelas tabelas que compõe a cluster table. Common Mistake Nunca tente manipular na clausula where de um sql os dados que vão 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 compõe a chave primária, tanto da pooled quanto da clustered tables. João Luiz Barbosa Junho/2000 Página 154 ACADEMIA BASIS CEMIG Workload Analysis Guide • Uma análise geral pode indicar se existem problemas de performance gerais na instalação: q Wait time deverá ser < 10% response time q Main menu deverá estar < 100 ms • Através da ST03, alguns valores indicam boa performance: q Average roll in time < 20 ms q Average roll out time < 20 ms q Average load time < 10% response time e sempre inferior a 50 ms q Average database time < 40% do (response time – wait time) q Average CPU time < 40% do (response time – wait time) q Average CPU time não pode ser muito inferior ao processing time Road Maps Summary q Work Process Overview (SM50/SM66) ü WP in status running à Long processing: analyse status field ü Dir. Read, Seq. Read, Insert, Update, Delete, Commit à DB analysis q Database Lock Monitor (DB01) ü Wait due database locks à Analyse lock holder q Database Process Monitor (ST04 à Oracle session) ü Look for SQL statements and identify the transaction q 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) q Workload Monitor (ST03) ü Wait time > 10% response time à general performance problem ü DB time > 40% (response time – wait time) à detail SQL analysis q 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) q 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) q Buffer Monitor (ST02) ü Many swaps à increase buffer size ü Extended memory: Max used > 80% In memory à Extended mem. Full q 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) q Operating System Monitor (ST06) ü CPU Idle < 20% à CPU contention ü Other servers available à Work process and users redistribution q 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 João Luiz Barbosa Junho/2000 Página 155 ACADEMIA BASIS CEMIG ü 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 q Buffers monitor (ST06 à Mode list) ü Programs with high memory à detail analysis of transaction Directory Summary /usr/sap/trans q q q q q q q bin, contém basicamente os arquivos de parâmetros TPPARAM e CONFIG.CFG actlog, onde são gravados cada action em um request ou task. Contém files com nomes <source SID>Z<6 digits> sapnames, com arquivos associados ao id dos usuários 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 contém os dados que foram exportados no transporte cofiles, com command files do tipo K9<5digits>.<source SID> contendo por exemplo os import steps que serão executados log, com todas as logs de transportes, como por exemplo ULOGs, ALOGs, SLOGs e as demais logs que descrevem as operações executadas nos steps individuais ou coletivos /oracle/<SID> q q q q q q q q q q q q dbs: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora, init<SID>.sap, etc.). bin: executáveis 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 reorganizações, 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 configuração do NET8 To be Known R/3 profiles (/usr/sap/<SID>/SYS/profile) q q q Start profile: START_<instance>_<host>, que contém a relação dos componentes que serão ativados pelo sapstart na instância Default profile: DEFAULT.PFL, que contém alguns parâmetros globais do sistema Instance profile: <SID>_<instance>_<host>, que contém parâmetros específicos da instância Startup sequence (startsap) 1. 2. 3. 4. 5. Ativa o programa sapstart O sapstart lê a start profile para ativar os serviços disponíveis na instância 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 serão ativados. Os processos sender e collector são 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 são criados de acordo com as informações da instance e da default profile. O gateway reader independe de parâmetros de profile, sendo sempre ativado Os work processes se conectam com a base de dados, que já se encontra rodando 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 João Luiz Barbosa são Junho/2000 logados pelo no Oracle alert file: Página 156 ACADEMIA BASIS CEMIG • Informações detalhadas de erro são 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 diretório /oracle/<SID>/sapreorg, .../sapcheck, .../sapbackup, dependendo da ação que foi executada SAP/Oracle parameter files (/oracle/SID/dbs) q q q init<SID>.ora: parametrizações da instância Oracle init<SID>.dba: parametrização do sapdba init<SID>.sap: parametrização das ferramentas BRBACKUP e BRARCHIVE Environment variables q q q q ORACLE_SID=<SID>: nome da instância DBS_ORA_TNSNAME: seta o <SID> do banco que será conectado através do tnsnames.ora ORACLE_HOME: o diretório home do oracle (/oracle/<SID>) SAPDATA_HOME e SAPDATAn: aponta para diretórios específicos contendo dados João Luiz Barbosa Junho/2000 Página 157 ACADEMIA BASIS CEMIG Anexos Glossário Termo ABAP 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 João Luiz Barbosa Descrição ABAP significa Advanced Business Application Programming e é uma linguagem interpretada e de quarta geração utilizada para desenvolver no ambiente SAP. Tanto seus fontes quanto seus p-code são guardados no banco de dados É o dicionário que contém todas as informações sobre as estruturas lógicas dos objetos de aplicação e de banco de dados relacionais bem como os fontes ativos e versões antigas dos programas. O dicionário trabalha como um dicionário ativo e é integrado com as ferramentas de desenvolvimento. É uma das ferramentas do ABAP Workbench e é destinada ao desenvolvimento e manutenção dos programas, funções, lógica de fluxo de janelas, etc. Além das funções normais de editor de programas a ferramenta dispõe de uma série de acessórios para auxiliar no desenvolvimento. É um conjunto de código que é processado seqüencialmente através de um módulo interpretador de comando. Existem dois tipos de programas, os relatórios e os diálogos É um ambiente integrado com uma série de ferramentas para o desenvolvedor produzir programas para o ambiente R/3 Processo que torna um objeto disponível para uso. O efeito direto da ativação é a geração 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 versões dos objetos desenvolvidos pela SAP Dados específicos de um client e é composto dos dados mestres e dos dados transacionais do negócio Máquina que provê serviços como : dialog, update, enqueue, background processing, print formating e gateway. Um application server contêm um dispatcher e um ou mais work process. O dispatcher recebe a solicitação do serviço a ser executado e atribui-o ao work process disponível. Um application server possui pelo menos um dialog e gateway. Client change option que significa que a qualquer customização do sistema, o R/3 solicitará uma request para guardar tudo o que será feito. Um sistema R/3 que assume as funções de gerenciamento do domínio de transportes se o primary domain controller ficar indisponível. É ativado manualmente. Todas as ferramentas disponibilizadas pelo R/3 para o gerenciar e transportar todas customizações e desenvolvimentos entre os sistemas R/3 dentro do landscape Significa o gerenciamento das alterações feitas no ambiente R/3 bem como a propagação destas para os demais ambientes com as respectivas verificações e consistência seguido da ativação nos ambientes destino. Pacote contendo as informações registradas e acumuladas pelas alterações feitas no ambiente durante o trabalho de um desenvolvedor ou configurador. O principal uso de uma change request é encapsular e propagar uma determinada alteração feita. É a característica 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 manutenção de um client é a opção que determina se alterações Junho/2000 Página 158 ACADEMIA Termo options BASIS CEMIG Descrição dependentes ou independentes de mandante podem ocorrer e se serão armazenadas automaticamente. Ainda não terminado João Luiz Barbosa Junho/2000 Página 159 ACADEMIA BASIS CEMIG Transactions Transaction Description AL08 AL11 AL12 * * * Alerts Users Logged On Display SAP Directories Display table buffer (Exp. session) DB01 DB02 DB05 DB12 DB13 DB14 DB15 DB16 DB17 DB20 DB21 DB31 * * * * * * * * * * * * 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 SRZL RZ01 RZ02 RZ03 RZ04 RZ06 RZ10 RZ11 RZ12 RZ15 RZ20 RZ21 SMGW SMLG * * * * * * * * * * * * * * 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 SA38 SE11 SE12 SE13 SE14 SE15 SE16 SE17 SE24 SE29 SE30 SE32 SE33 SE35 SE36 SE37 SE38 SE39 SE40 SE41 SE43 * * * João Luiz Barbosa * * * * 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 Junho/2000 Página 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 SM0 SM01 SM02 SM04 SM12 SM13 SM21 SM28 SM30 SM31 SM35 SM36 SM37 SM39 SM49 SM50 SM51 SM54 SM55 SM56 SM58 SM59 SM61 João Luiz Barbosa BASIS CEMIG * 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) * * * * Junho/2000 Página 161 ACADEMIA Transaction SM62 SM63 SM64 SM65 SM66 SM69 SMX BASIS * * * * * * * CEMIG 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 ST01 ST02 ST03 ST04 ST05 ST06 ST07 ST08 ST09 ST10 ST11 ST12 ST14 ST22 STAT * * * * * * * * * * 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 SE01 SE03 SE06 SE09 SE10 STMS * * * * * * Transports Transport Organizer Workbench Organizer: Tools Set Up Workbench Organizer Workbench Organizer Customizing Organizer Transport Management System SU01 SU01D SU02 SU03 SU2 SU20 SU21 SU3 SU53 SU56 * * * * * * * * * * 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 SCC1 SCC3 SCC4 SCC5 SCC6 SCC7 SCC8 SCC9 SCCL SCU0 * * * * * * * * * * 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 SARA AOBJ SARI SARJ * * João Luiz Barbosa Archive Archive Management Archiving object definition Archive Information System Archive Information System (Customizing) Junho/2000 Página 162 ACADEMIA BASIS CEMIG Transaction SARL Description Call of ArchiveLink Monitor BALA BALD BALE BALM SALE ALE ALE Application menu ALE Development ALE Distribution menu ALE Master Data IMG Application Link Enabling SP01 SPAD * * Spool management Output managment Spool administration FILE OY18 OY19 SF01 SXDA * * * * * Others Archive logical file paths Table History Customizing objects : selection for compare Archive logical file names Data transfer workbench 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 João Luiz Barbosa 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 Junho/2000 Página 163 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 João Luiz Barbosa BASIS CEMIG 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 Junho/2000 Página 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 CEMIG 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 João Luiz Barbosa Description Read Import Queues in Local Buffer Junho/2000 Página 165 ACADEMIA BASIS CEMIG Report RSPO0041 RSPO0043 RADDBDIF Description Delete old spool print Check TemSe consistency RHAUTUPD RSBDCREO RSBPCOLL RSBPSTDE RSBTCDEL RSCOLL00 RSM13002 RSORA811 RSORASNP RSPARAM RSPFPAR RSPO0041 RSPO0043 RSSNAPDL RSSTAT15 RSSTAT60 RSTBHIST RSUSR040 RSUSU000 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 João Luiz Barbosa Junho/2000 Página 166 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 CEMIG 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 João Luiz Barbosa Default db $(DIR_GLOBAL) Junho/2000 Description Controls where TemSe stores the spool data rule to build file names for TemSe Página 167 ACADEMIA BASIS CEMIG Parameter Rsisp/max_wprun_time Rspo/auth/pagelimit Default 300s 0 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 2000 N Rsdb/reco_trials 3 João Luiz Barbosa Description Active authorization for limit page printing 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 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 reconexão ao banco Quantidade de tentativas de reconexão 60 5s Junho/2000 Página 168
