Academia Basis Old

ACADEMIA BASIS CEMIG
Academia Basis
Junho/200
João Luiz Barbosa
João Luiz Barbosa Junho/2000 Página 1

Í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

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

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

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

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

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

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

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

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

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

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 (cicareli@cemig.com.br), durante a academia de Unix/Oracle de 1999. Na
prática eu (jluiz@cemig.com.br) 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 Empresa Alguns e ½
Instrutores :
Erika Quirós SAP erika.quiros@sap.com
Luiz Mestrinel SAP luiz.mestrinel@sap.com
Rinaldo Morais SAP rinaldo.morais@sap.com e rinaldomorais@yahoo.com
Vera SAP vera@sap.com
Acadêmicos :
Ana Maria Solangol nonomaria@hotmail.com
Aroldo Higashi Skyline ahigashi@dmc-2.com.br e aroudo.higashi@zipmail.com
Cláudio Milos SAP claudio.milos@sap.com e milos27@hotmail.com
Joao Luiz Barbosa CEMIG jluiz@cemig.com.br e jluizsb@zaz.com.br
Marcelo Silva CEMIG mvsilva@cemig.com.br
Priscila Silva SAP priscila.silva@sap.com
Renan Guedes SPEC renan.guedes@spec.com.br
Ricardo Magalhães SAP ricardo.magalhaes@sap.com
Demais colaboradores :
Márcio Cicarelli CEMIG cicareli@cemig.com.br

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.

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;

• 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,

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-to-
program 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).

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

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.

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.

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

(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 R/3, System-wide For each R/3 Instance

Dialog >= 2 >= 2
Update >= 1 >= 0
Enqueue 1 0 ou 1
Background >= 2 >= 0
Message 1 0 ou 1
Gateway >= 1 1
Spool >= 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

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

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.

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.

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.

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

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

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.

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 Configuração desejável
Processador 486 Pentium 133
RAM 16MB 32MB
Net connection Winsocket API Winsock.dll
Configuração para Windows NT

Item Configuração Mínima Configuração desejável
Processador Pentium 90 Pentium 133
RAM 32MB 48MB
Net connection TCP/IP 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

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

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 ()

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.

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.

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.

• 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.

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

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.

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:

• 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.

• 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.

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

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.

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 background-
job-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)

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

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

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

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.

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.

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

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.

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, amarelo-
warning, 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

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.

• 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.

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

semânticas associadas as autorizações aplicadas a cada função a ser desempenhada pelos

usuários.
Authorization as ER
Classes Objects Fields
1-n na task e Authoriz. Values

n-n no código abap
Transaction Profiles 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

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.

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.

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

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

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 de-
para, 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.

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

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.

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

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

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

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.

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).

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

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

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.

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

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

• 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

é 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

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

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.

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.

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.

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

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.

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.

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.

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-SID-
KTnnn 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

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)

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)

• 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)


• 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.

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.

É 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.

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.

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 off-
line 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.

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

• 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.

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

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.

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.

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*).

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.

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.

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)

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

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.

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

• 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

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

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 R/3, System-wide For each R/3 Instance

Dialog >= 2 >= 2
Update >= 1 >= 0
Enqueue 1 0 ou 1
Background >= 2 >= 0
Message 1 0 ou 1
Gateway >= 1 1
Spool >= 1 e <= 3 >= 1 e <= 3

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.

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

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

• 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 Owner
SYSTEM Oracle DDIC Oracle rdbms
PSAP ROLL D ou I Segmentos de rollback Oracle rdbms

PSAP TEMP D ou I Area temporaria normalmente utilizada para sort Oracle rdbms
PSAP EL<release> D ou I Módulos do ambiente de desenvolvimento Basis
PSAP ES<release> D ou I Fontes do ambiente de desenvolvimento Basis
PSAP LOAD D ou I Módulos das janelas e relatórios Basis
PSAP SOURCE D ou I Fontes das janelas e relatórios Basis
PSAP DDIC D ou I Dicionário abap Basis
PSAP PROT D ou I Tabelas do tipo log Aplicações
PSAP CLU D ou I Tabelas cluster Aplicações
PSAP POOL D ou I Tabelas pool Aplicações
PSAP STAB D ou I Tabelas de dados mestres ou transparentes Aplicações
PSAP BTAB D ou I Tabelas de dados transacionais ou transparente Aplicações
PSAP DOCU D ou I Documentações, sapscripts e sapfind Aplicações
PSAP USER1 D ou I Tabelas do cliente Aplicações
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)

• 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

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.

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.

Backup and Recover Diagram
Backup
ArchiveLog NoArchiveLog
On-Line Off-Line
Complete Incomplete Reset

Recover Recover
with
reset log
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,

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.

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

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)

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

• 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

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.

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
• 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>.
• Menor janela de backup
• 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

• Diminui o volume de dados que serão backupeados
• 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.
• 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
• É 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.
• Diminui a janela de backup (disco para disco) e agiliza um possível restore
• 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
• Baixíssimo downtime
• Não há impacto no database server, já que o backup é realizado a partir de outro servidor
onde o espelho é montado
• Preço elevado da solução

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
• Não há downtime no ambiente produtivo
• 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
• Muito depende da ferramenta utilizada, que pode inclusive oferecer maiores facilidades de
gerenciamento de fitas que as oferecidas pela SAP
• Investimento normalmente elevado em hardware e software

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.

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

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.

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 e

PCTINCREASE) não devem ser alterados exceto sob recomendação explícita da SAP.
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

(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.

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

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

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.

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 rule-
based 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%

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)

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:

• 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.

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

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 ORA-
1632 (í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.

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.

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.

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

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
• 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

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”
• Buffer de programas muito pequeno
• Ação “Roll-in” ou “Roll-out”
• 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

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.

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.

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.

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

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.

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

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

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.

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
• Pesquisar por tabelas com alto numero de rows affected
• 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)

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

• 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.

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.

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.

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

ü 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 bin, contém basicamente os arquivos de parâmetros TPPARAM e CONFIG.CFG
q actlog, onde são gravados cada action em um request ou task. Contém files com nomes <source SID>Z<6 digits>
q sapnames, com arquivos associados ao id dos usuários que efetuam release em changes
q buffer, com um import buffer para cada sistema R/3. Quando um change request é liberado, o file correspondente ao
sistema target é atualizado
q data, contendo arquivos do tipo R9<5 digits>.<source SID> que contém os dados que foram exportados no transporte
q cofiles, com command files do tipo K9<5digits>.<source SID> contendo por exemplo os import steps que serão
executados
q 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 dbs: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora, init<SID>.sap, etc.).
q bin: executáveis Oracle
q sapdata1,2,...: onde se localizam os data files
q origlogA, origlogB: online redo log files
q mirrlogA, mirrlogB: mirror online redo log files
q saptrace/background: Oracle alert files
q saptrace/usertrace: trace files dos shadow oracle processes
q sapereorg: área de trabalho para reorganizações, compress de backup files, etc.
q saparch: offline redo log area e logs do BRARCHIVE
q sapbackup: BRBACKUP e BRRESTORE logs
q sapcheck: sapdba logs (-next, -check, -analyze)
q /network/admin: arquivos de configuração do NET8
To be Known
R/3 profiles (/usr/sap/<SID>/SYS/profile)

q Start profile: START_<instance>_<host>, que contém a relação dos componentes que serão ativados pelo sapstart na
instância
q Default profile: DEFAULT.PFL, que contém alguns parâmetros globais do sistema
q Instance profile: <SID>_<instance>_<host>, que contém parâmetros específicos da instância
Startup sequence (startsap)

1. Ativa o programa sapstart
2. O sapstart lê a start profile para ativar os serviços disponíveis na instância
3. 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
4. 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
5. 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) 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
SAP/Oracle parameter files (/oracle/SID/dbs)

q init<SID>.ora: parametrizações da instância Oracle
q init<SID>.dba: parametrização do sapdba
q init<SID>.sap: parametrização das ferramentas BRBACKUP e BRARCHIVE
Environment variables
q ORACLE_SID=<SID>: nome da instância
q DBS_ORA_TNSNAME: seta o <SID> do banco que será conectado através do tnsnames.ora
q ORACLE_HOME: o diretório home do oracle (/oracle/<SID>)
q SAPDATA_HOME e SAPDATAn: aponta para diretórios específicos contendo dados

Anexos
Glossário
Termo Descrição
ABAP 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
ABAP dictionary É 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.
ABAP editor É 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.
ABAP program É 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
ABAP workbench É um ambiente integrado com uma série de ferramentas para o
desenvolvedor produzir programas para o ambiente R/3
Activation 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
Append structure 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
Application data Dados específicos de um client e é composto dos dados mestres e dos
dados transacionais do negócio
Application server 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.
Automatic Client change option que significa que a qualquer customização do sistema,
recording of o R/3 solicitará uma request para guardar tudo o que será feito.
changes
Backup domain Um sistema R/3 que assume as funções de gerenciamento do domínio de
controller transportes se o primary domain controller ficar indisponível. É ativado
manualmente.
Change and Todas as ferramentas disponibilizadas pelo R/3 para o gerenciar e
transport transportar todas customizações e desenvolvimentos entre os sistemas R/3
organizers CTO dentro do landscape
Change Significa o gerenciamento das alterações feitas no ambiente R/3 bem como a
management propagação destas para os demais ambientes com as respectivas
verificações e consistência seguido da ativação nos ambientes destino.
Change request 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.
Change request É a característica que significa se a change request é transportable,
attribute customizing, local ou not assigned.
Client Comercial, organizacional e tecnicamente é termo que significa unidades de
dados contidas e organizadas dentro de tabelas
Client change Durante a manutenção de um client é a opção que determina se alterações

Termo Descrição
options dependentes ou independentes de mandante podem ocorrer e se serão
armazenadas automaticamente.
Ainda não terminado

Transactions
Transaction Description
Alerts
AL08 * Users Logged On
AL11 * Display SAP Directories
AL12 * Display table buffer (Exp. session)
Database
DB01 * Analyze exclusive lockwaits
DB02 * Analyze tables and indexes
DB05 * Analysis of a table acc. to index
DB12 * Overview of Backup Logs
DB13 * Database administration calendar
DB14 * Show SAPDBA Action Logs
DB15 * CCMS - Document archiving
DB16 * DB system check (trigger/browse)
DB17 * DB system check (configure)
DB20 * No.of table tupels acc. to stat.
DB21 * Maintenance control table DBSTATC
DB31 * Table view of DBMSGORA
CCMS Set up
SRZL * CCMS Computing Center Management System
RZ01 * Job Scheduling Monitor
RZ02 * Network Graphics for SAP Instances
RZ03 * Presentation, Control SAP Instances
RZ04 * Maintain SAP Instances
RZ06 * Alerts Thresholds Maintenance
RZ10 * Maintenance of profile parameters
RZ11 * Profile parameter maintenance
RZ12 * Maintain RFC server group assignment
RZ15 * Read XMI log
RZ20 * CCMS MT standard monitor
RZ21 * CCMS Customizing of the mon. infra.
SMGW * Gateway Monitor
SMLG * Maintain Logon Group
ABAP Workbench
SA38 * Execute program
SE11 * ABAP/4 Dictionary Maintenance
SE12 * ABAP/4 Dictionary Display
SE13 Maintain Technical Settings (Tables)
SE14 Utilities for Dictionary Tables
SE15 ABAP/4 Repository Information System
SE16 * Data Browser
SE17 General Table Display
SE24 ABAP Objects Class Library
SE29 Application packet
SE30 * ABAP Runtime Analysis
SE32 ABAP/4 Text Element Maintenance
SE33 Context Builder
SE35 ABAP/4 Dialog Modules
SE36 ABAP/4: Logical Databases
SE37 * ABAP Function Modules
SE38 * ABAP Editor
SE39 Splitscreen Editor: Program Compare
SE40 MP: Standards Maint. and Translation
SE41 Menu Painter
SE43 Maintain Area Menu

SE48 Program Analysis: Call Hierarchy
SE49 Program Analysis: Table Manipulation
SE51 Screen Painter
SE52 Parameterized screenpainter call
SE54 Generate table view
SE55 Internal table view maintenance call
SE56 internal call: display table view
SE57 internal delete table view call
SE61 R/3 Documentation
SE62 Industry Utilities
SE63 Translation: Initial Screen
SE64 Terminology
SE65 R/3 Docu.: Short Text Statistics
SE66 R/3 Documentation Statistics
SE71 SAPscript form
SE72 SAPscript styles
SE73 SAPscript font maintenance (revised)
SE74 SAPscript format conversion
SE75 SAPscript Settings
SE76 SAPscript: Form Translation
SE77 SAPscript Translation Styles
SE80 * Repository Browser
SE81 Application Hierarchy
SE82 Application Hierarchy
SE84 R/3 Repository Information System
SE87 Data Modeler Information System
SE88 Development Coordination Info System
SE89 Maintain Trees in Information System
SE90 Process Model Information System
SE91 * Maintain Messages
SE92 * Maintain System Log Messages
SE93 * Maintain Transaction Codes
SE94 Customer enhancement simulation
SE95 Customer Enhancements to AEW Objects
SMOD * SAP Enhancement Management
System Monitoring
SM0 Work Process Overview
SM01 * Lock transactions
SM02 * System Messages
SM04 * User Overview
SM12 * Display and Delete Locks
SM13 * Display Update Records
SM21 * System Log
SM28 * Installation Check
SM30 * Call View Maintenance
SM31 * Table Maintenance
SM35 * Batch Input Monitoring
SM36 * Define Background Job
SM37 * Background Job Overview
SM39 * Job Analysis
SM49 * Execute external OS commands
SM50 * Work Process Overview
SM51 * List of SAP Servers
SM54 * TXCOM maintenance
SM55 * THOST Maintenance
SM56 * Number Range Buffer
SM58 * Asynchronous RFC Error Log
SM59 * RFC Destinations (Display/Maintain)
SM61 * Maintain table BTCCTL (background processing)

SM62 * Display/Edit Events
SM63 * Display/Maintain Operating Mode Sets
SM64 * Release of an Event
SM65 * Background Processing Analysis Tool
SM66 * Systemwide Work Process Overview
SM69 * Maintain external OS commands
SMX * Display Own Jobs
System Tuning
ST01 * System Trace
ST02 * Setups/Tune Buffers
ST03 * Performance,SAP Statistics, Workload
ST04 * Select DB activities
ST05 * Trace for SQL, Enqueue, RFC, Memory
ST06 * Operating System Monitor
ST07 * Application monitor
ST08 Network Monitor
ST09 Network Alert Monitor
ST10 Table call statistics
ST11 Display Developer Traces
ST12 Application Monitor
ST14 * Application Analysis
ST22 * ABAP/4 Runtime Error Analysis
STAT * Local transaction statistics
Transports
SE01 * Transport Organizer
SE03 * Workbench Organizer: Tools
SE06 * Set Up Workbench Organizer
SE09 * Workbench Organizer
SE10 * Customizing Organizer
STMS * Transport Management System
User Master Administration

SU01 * User Maintenance
SU01D * User Display
SU02 * Maintain Authorization Profiles
SU03 * Maintain Authorizations
SU2 * Maintain user parameter
SU20 * Maintain Authorization Fields
SU21 * Maintain Authorization Objects
SU3 * Maintain Users Own Data
SU53 * Display Check Values
SU56 * Analyze User Buffer
Client Administration
SCC1 * Client Copy - Special Selections
SCC3 * Client Copy Log
SCC4 * Client Administration
SCC5 * Client Delete
SCC6 * Client import
SCC7 * Client import - postprocessing
SCC8 * Client export
SCC9 * Remote client copy
SCCL * Client import - postprocessing
SCU0 * Customizing comparison
Archive
SARA * Archive Management
AOBJ * Archiving object definition
SARI Archive Information System
SARJ Archive Information System (Customizing)

SARL Call of ArchiveLink Monitor
ALE
BALA ALE Application menu
BALD ALE Development
BALE ALE Distribution menu
BALM ALE Master Data
SALE IMG Application Link Enabling
Spool management
SP01 * Output managment
SPAD * Spool administration
Others
FILE * Archive logical file paths
OY18 * Table History
OY19 * Customizing objects : selection for compare
SF01 * Archive logical file names
SXDA * Data transfer workbench
Not classified
AARD Archiving - Delete program
AARR Archiving - Reload
AARV Archiving - Management
ACLA Archiving class definition
AL01 SAP Alert Monitor
AL02 Database alert monitor
AL03 Operating system alert monitor
AL04 Monitor call distribution
AL05 Monitor current workload
AL06 Performance: Upload/Download
AL07 EarlyWatch Report
AL09 Data for database expertise
AL10 Download to Early Watch
AL13 Display Shared Memory (Expert mode)
AL15 Customize SAPOSCOL destination
AL16 Local Alert Monitor for Operat.Syst.
AL17 Remote Alert Monitor f.Operat. Syst.
AL18 Local File System Monitor
AL19 Remote File System Monitor
AL20 EarlyWatch Data Collector List
AL21 ABAP Program analysis
AL22 Dependent objects display
DB03 Parameter changes in database
DB07 ADABAS D: Diagnostic monitor
DB11 Early Watch Profile Maintenance
DB2J Manage JCL jobs for OS390
DB32 DB syst. check (ORA): Configuration
DB33 DB System check (configure, IFMX)
RZ08 SAP Alert Monitor
SAR Maintain Transaction Codes
SAR0 Display Standard Reporting Tree
SC38 Start Report (Remote)
SC80 CATT utilities
SCAL Factory Calendar with GUI
SCAM CATT management
SCAR Record CATT procedures
SCAT Computer Aided Test Tool
SCD0 Change Documents for Utilities
SCDN Change Documents: Number Ranges
SCDO Display Change Document Objects
SCET Menu for Control Enabling Technology

SCMP View/Table compare
SCOM SAPcomm: Configuration
SCOR SAPconnect - Send Attempts
SCOT SAPconnect - Administration
SCPF Generate enterprise IMG
SCPR1 Customizing Profiles: Maintce tool
SCPR2 Compare Customizing profiles
SCT1 Logical imports - overview
SCU1 Table Comparison - Export to Tape
SCU2 Table Comparison Against Tape
SCU3 Table History
SCUI Communicate system status to SAP
SE07 Transport System Status Display
SECR Audit Info System
SEPS SAP Electronic Parcel Service
SERP Reporting: Change Tree Structure
SES0 Maintain favorites
SESA Switching off the menu tree display
SESE Switching off the menu tree display
SESS Starting the R/3 menu
SEU Repository Browser
SEWA Earlywatch Alert
SM18 Reorganize audit
SM19 Basis Audit Configuration
SM20 System Audit Log
SM29 Model Transfer for Tables
SM32 Maintain Table Parameter ID TAB
SM33 Display Table Parameter ID TAB
SM34 Viewcluster maintenance call
SM38 Queue Maintenance Transaction
SM67 Job Scheduling
SM68 Job Administration
SMEN Session Manager Menus
SMET Display frequency of function calls
SMETDELBUFF Del. Measurement data in shared bfr
SMETDELPROG Delete programs in shared buffer
SMLI Language Import Utility
SMLT Language Transport Utility
SMME Output control Message Block Table
SMO1 Repository Information System: SMOD
SMT1 Trusted Systems (Display <-> Maint.)
SMT2 Trusting systems (Display <->Maint.)
SMW0 SAP Web Repository
SMW2 Test multipart MIME interface
ST4A Database: Shared cursor cache (ST04)
ST62 Create industry short texts
STDA Debugger display/control (server)
STDC Debugger output/control
STDR TADIR consistency check
STDU Debugger display/control (user)
STFB CATT function module test
STI1 Change Documents Payment Details
STI2 Change Docs Correspondence
STI3 Chg. Docs Transaction Authoriz.
STMP Proposal pool: Selection
STP4 Select DB activities
STPC Test Workbench, Start test package
STPD Test Workbench

STSN Customizing Number Ranges Time Strm
STVR WB: Transport Utility R/3 > R/2
STW1 Test Workbench: Test catalog
STW2 Test workbench: Test plan
STW3 Test workbench: Test package
STW4 Test Workbench: Edit test package
STW5 C maintenance table TTPLA
SU01_NAV User maint. to include in navigation
SU05 Maintain Internet users
SU10 Mass Changes to User Master Records
SU12 Mass Changes to User Master Records
SU22 Auth. Object Usage in Transactions
SU23 Load Tables in TAUTL
SU24 Auth. obj. check under transactions
SU25 Upgrade Tool for Profile Generator
SU26 Upgrade tool for Profile Generator
SU52 Maintain User Parameters
SU54 Session Manager
SU55 Call the Session Manager menus
SU80 Archive user change documents
SU81 Archive user password change doc.
SU82 Archive profile documents
SU83 Archive authorization docs.
SU84 Read archived user change documents
SU85 Read archived password change doc.
SU86 Read profile change documents
SU87 Read authorization change documents
SU96 Table maint.: Change SUKRIA
SU97 Table maint.: Display SUKRIA
SU98 Call report RSUSR008
SU99 Call report RSUSR008
SUCH Translatability CHECKs
SUCU Table authorizations: Customizing
SUIM all AUTH reporting tree (info sys.)
SUPC Profiles for activity groups
SUPN Number range maint.: PROF_VARIS
SUPO Maintain org. levels
SUSE Maint. for Self Upgrading Software
TU01 Call Statistics
TU02 Parameter changes
TUTT Workbench Tutorial
Reports
Report Description
RSTMSC0L Read Import Queues in Local Buffer
RDDNEWPP
RDDIMPDP
RDDDICOL
RDDMASGL
RDDTACOL
RDDDIS0L
RDDGEN0L
RDDMASGL
RDDDIC1L
RDDVERSL
RDDEXECL
RDDDIC3L

Report Description
RSPO0041 Delete old spool print
RSPO0043 Check TemSe consistency
RADDBDIF
RHAUTUPD User Master Data Reconciliation

RSBDCREO Reorganize BI folders and logs
RSBPCOLL Collector for Background Job Run-time Statistics
RSBPSTDE Delete Statistics Data from the Job Run-time Statistics
RSBTCDEL Delete batch jobs
RSCOLL00 Delete OS collector logs
RSM13002 Update request analysis and processing tool
RSORA811 Delete old brbackup/brarchive
RSORASNP Reorganize the snap & stats logs
RSPARAM Display profile parameter
RSPFPAR Display profile parameter
RSPO0041 Delete old spool request
RSPO0043 Check consistency of spool database
RSSNAPDL Delete ABAP short dumps
RSSTAT15 Display/change of workload parameters
RSSTAT60 Reorganize table MONI
RSTBHIST Table History
RSUSR040 List authorization objects by complex selection criteria
RSUSU000 Current active users
OSS Notes
Number Description
001916 Securing a production system
004108 How do I assign a password to sap*
004326 How do I delete the user sap*
008541 Secure the host hardware and OS unix
008707 Explanation about init<SID>.sap parameter tape_size
011796 Authorization profile P_BAS_ALL and table display
012103 Contents of table TCOLL
013202 Security aspects in ABAP
015606 Overflow of dispatcher request queue
016083 Standard jobs, reorganization jobs
016466 Customer namespace for SAP objects
019909 Setting compress_cmd for compress = only
022514 Error analysis for client copy
023345 Consistency check of ORACLE database
023611 FAQs about authorizations
024092 Distribution of background jobs on application server
026171 Possible entry values for command fields
026317 Set up for LOGON group for autom. load balancing
026966 Background jobs do not start when transporting
027928 Consequences in transport during password change
028175 Questions regarding the authorization concept
029276 SAPCPIC: Where are passwords visible ?
030724 Data protection and security in R/3
031395 System parameters: Defined where? Displayed how?
031503 FAQ: Background jobs
031557 The multi-client concept of R/3 - Oveview
032050 RSCOLL00: report runs infinitely, incomplete data
033525 Important information about SAP patches
033630 Deleting old BRBACKUP, BRARCHIVE entries
035493 Secrecy and data security obligations
036280 Background Work Processes Reserved for Job Class A
037104 Error analysis: Background processing system

Number Description
039267 Availability of the R/3 security guide
039412 How many work processes to configure
040689 New reports for the user informations system
041732 Deletion of data in transport directory
042268 Operating SAPLPD as a service under Windows NT
047502 Messages of the Remote Clientcopy
048018 Third party products
050088
051222 Operation modes and overflow of dispatcher queue
051789 Poor user distribution in logon distribution
052505 Support offered by SAP after end of maintenance
053030 Online archiving versus data integrity
053062 Database reorganization and R/3 archiving
053064 What is important when reloading from archives ?
062431 SAPoffice: Connection over MAPI interface
062739 Configuring a central transport host
063480 R/3 and MS Exchange linking
064015 Test tool for message servers: lgtst
065761 Determine configuration problems under Windows NT
066533 Automatic unlocking after incorrect logon
066612
066687 Network security products Secude and Kerberos
067074 Transporting original objects using se01
068048 Deactivating the automatic user SAP*
068544
069444 Error messages/terminations in client copy
070085 Re-processing failed update records via SM13
070128 Docu/Help for copying clients
070547 Client transport
070639 How are batch jobs scheduled?
071058 Innovations in BRBACKUP and BRARCHIVE Version 3.1G
077429 'SAPgui in Java': scope of functions & availabilit
077462 C/2 certification of R/3
080210 Profile generator: composite note
083327 Setting up transport system in heterogeneous system
083699
084052 R3trans: Table logging
086895 Additional Info: Upgrading to 4.0x PC inst
088416 Zero administration memory management from 4.0A/NT
089324 Archiving: revised adk versions
091096 Table Compare: Info about Cust. Cross System Check
096896
099088 Improvements for BRBACKUP/BRARCHVIE/BRRESTORE 4.0
099284 RFC exception: RESOURCE_FAILURE
099502 SCC1 in Release 4.0B
099962 Error messages when you use DB_VERIFY
100400 dbv reports corrupt blocks in SYSTEM and PSAPTEMP
101146 Batch:authorization object S_BTCH_JOB, S_BITCH_NAM
109515 Update groups for asynchronous updates
118823 Size of client
122718 CBO: Tables with special processing
127773 Several enqueue work processes
182592 Delete/change transactions codes in command field
RZ10 Parameters
Parameter Default Description

Rspo/store_location db Controls where TemSe stores the spool data
Rspo/files/root/G $(DIR_GLOBAL) rule to build file names for TemSe

Parameter Default Description

Rsisp/max_wprun_time 300s
Rspo/auth/pagelimit 0 Active authorization for limit page printing
Auth/auth_number_in_userbuffer 2000 Maximum number of authorizations in user buffer

Auth/no_check_on_tcode N No authorization check on object S_TCODE
eu/iwb/help_type Type of Extended Help (format/access)
eu/iwb/installed_languages Installed Help Languages
eu/iwb/path_win32 File path for Help on Win32 platforms
eu/iwb/server_win32 HTTP server for help on Win32 platforms
Login/min_password_lng
Login/password_expiration_time
Rdisp/btcname Name of application server that processes events
Rdisp/btctime 60 Start Interval for Background Scheduler
Rdisp/mshost Hostname where message server is located
Rdisp/trace Trace level for startup log
Rdisp/wp_no_btc Number of background work processes
Rsdb/reco_sleep_time 5s quantidade de tempo de espera para uma nova
tentativa de reconexão ao banco
Rsdb/reco_trials 3 Quantidade de tentativas de reconexão

Academia Basis Old

Uploaded by

Copyright:

Available Formats

Academia Basis Old

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Academia Basis Old

Uploaded by

Copyright:

Available Formats

ACADEMIA BASIS CEMIG

João Luiz Barbosa

João Luiz Barbosa Junho/2000 Página 1

PLANO DE ESTUDO ............................................................................................................................... 12

PRIMEIRA SEMANA ........................................................................................................................ 13

R/3 BASIS TECHNOLOGY ............................................................................................................... 13

BASIS SYSTEM AND THE SYSTEM ENVIRONMENT .............................................................................. 13

LOGGING ONTO R/3 SYSTEM ............................................................................................................... 17

SYSTEM KERNEL ............................................................................................................................. 19

R/3 PRESENTATION INTERFACE .......................................................................................................... 19

João Luiz Barbosa Junho/2000 Página 2

R/3 AS AN OPEN SYSTEM ..................................................................................................................... 25

R/3 GRAPHICAL USER INTERFACE ............................................................................................ 29

FRONTEND ADMINISTRATION ............................................................................................................. 29

SAP ONLINE SERVICE SYSTEM (OSS) ........................................................................................ 32

OSS OVERVIEW .................................................................................................................................... 32

STARTING AND STOPING R/3 – NT VERSION .......................................................................... 33

OPERATING SYSTEM TASKS ................................................................................................................ 33

STARTING AND STOPING R/3 – UNIX VERSION ..................................................................... 36

OPERATING SYSTEM TASKS ................................................................................................................ 36

CCMS CONFIGURATION ................................................................................................................ 38

João Luiz Barbosa Junho/2000 Página 3

BACKGROUND PROCESSING ....................................................................................................... 41

BACKGROUND CONCEPTS AND FEATURES ......................................................................................... 41

ADVANCED BACKGROUND PROCESSING ............................................................................... 44

TYPES OF BACKGROUND JOBS ............................................................................................................ 44

DATA ARCHIVING ........................................................................................................................... 48

SYSTEM MONITORING .................................................................................................................. 51

WHAT, WHY, WHO AND WHEN ............................................................................................................. 51

USERS AND AUTHORIZATION IN THE R/3 SYSTEM .............................................................. 54

USERS IN THE R/3 ENVIRONMENT ....................................................................................................... 54

João Luiz Barbosa Junho/2000 Página 4

INFORMATION SYSTEM E AUTHORIZATION TRACES ......................................................................... 57

SOFTWARE LOGISTICS ................................................................................................................. 61

R/3 SYSTEM, SERVERS AND INSTANCES ............................................................................................. 61

CHANGE AND TRANSPORT SYSTEM PREREQUISITES ........................................................ 64

CONFIGURING THE SYSTEM LANDSCAPE ........................................................................................... 64

CHANGE MANAGEMENT FOR DEVELOPMENT ..................................................................... 67

CHANGE REQUESTS .............................................................................................................................. 67

CHANGE MANAGEMENT FOR CUSTOMIZING ....................................................................... 72

CUSTOMIZING CONCEPTS .................................................................................................................... 72

TRANSPORT PROCESS .......................................................................................................................... 76

João Luiz Barbosa Junho/2000 Página 5

ADVANCED TRANSPORT MANAGEMENT ................................................................................ 78

TRANSPORT DIRECTORY ..................................................................................................................... 78

CLIENT TOOLS ................................................................................................................................. 82

CLIENT TRANSPORT ............................................................................................................................. 82

CLIENT AND SYSTEM STRATEGIES .......................................................................................... 85

TYPES OF LANDSCAPES ........................................................................................................................ 85

R/3 UPGRADES AND OCS PATCHES ........................................................................................... 89

R/3 EVOLUTION AND RELEASE STRATEGY ........................................................................................ 89

TERCEIRA SEMANA ........................................................................................................................ 93

R/3 SPOOL AND PRINT .................................................................................................................... 93

R/3 SPOOL SYSTEM .............................................................................................................................. 93

João Luiz Barbosa Junho/2000 Página 6

R/3 OUTPUT MANAGEMENT......................................................................................................... 96

DEVICE POOLS ...................................................................................................................................... 96

INSTALLATION CHECK ................................................................................................................. 99

HARDWARE E SOFTWARE .................................................................................................................... 99

R/3 WORKLOAD DISTRIBUTION ............................................................................................... 102