ACADEMIA BASIS

Academia Basis

Junho/200

Joo Luiz Barbosa

Pgina 1
ACADEMIA BASIS

ndice

NDICE ............................................................................................................................................ 2

INTRODUO .............................................................................................................................. 12

PLANO DE ESTUDO.......................................................................................................................... 12
ADVERTNCIA................................................................................................................................. 12
DIREITO DE AUTORIA...................................................................................................................... 12
MARCAS REGISTRADAS................................................................................................................... 13
PARTICIPANTES DA ACADEMIA ...................................................................................................... 13

PRIMEIRA SEMANA ................................................................................................................... 14

R/3 BASIS TECHNOLOGY .......................................................................................................... 14

BASIS SYSTEM AND THE SYSTEM ENVIRONMENT .......................................................................... 14

BUSINESS FRAMEWORK ARCHITECTURE ....................................................................................... 14
R/3 SYSTEM CLIENT/SERVER CONFIGURATIONS........................................................................... 15
THE MIDDLEWARE BASIS ............................................................................................................... 16

NAVIGATION ............................................................................................................................... 18

LOGGING ONTO R/3 SYSTEM .......................................................................................................... 18

R/3 MENU STRUCTURE ................................................................................................................... 18

SYSTEM KERNEL ....................................................................................................................... 20

R/3 PRESENTATION INTERFACE ..................................................................................................... 20

R/3 DATABASE INTERFACE............................................................................................................. 20
WORK PROCESSES AND DISPATCHER............................................................................................. 21
R/3 APPLICATION SERVICES .......................................................................................................... 21
RULES FOR THE TYPE AND NUMBER OF PROCESSES IN THE APPLICATION ................................... 22
R/3 TRANSACTION AND LUW......................................................................................................... 22
LOCK CONCEPT AND ASYNCHRONOUS UPDATE ............................................................................ 22
BACKGROUND PROCESSING ........................................................................................................... 24
R/3 PRINTER SERVICES .................................................................................................................. 24
R/3 INSTANCE ................................................................................................................................. 24

Pgina 2
ACADEMIA BASIS

INTERFACES................................................................................................................................ 26

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

R/3 GATEWAY SERVICE ................................................................................................................. 26
COMMUNICATION WITH CPI-C ...................................................................................................... 26
REMOTE FUNCTION CALL .............................................................................................................. 26
BUSINESS OBJECTS AND BAPIS ...................................................................................................... 27
R/3 SYSTEM AS AN OLE SERVER OR AN OLE CLIENT .................................................................. 27
INTERNET ARCHITECTURE ............................................................................................................. 28
EDI ARCHITECTURE ...................................................................................................................... 28
DISTRIBUTION OF BUSINESS PROCESSES WITH ALE ..................................................................... 28
DATA TRANSFER AND BATCH INPUT .............................................................................................. 28

R/3 GRAPHICAL USER INTERFACE ........................................................................................ 30

FRONTEND ADMINISTRATION......................................................................................................... 30
SAPGUI INSTALLATION................................................................................................................. 30
TYPES OF ONLINE HELP ................................................................................................................. 30
SAPLOGON OPTIONS E TRACES ................................................................................................ 31
SAP MAPI AND SAPGUI FOR JAVA .............................................................................................. 32

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

OSS OVERVIEW .............................................................................................................................. 33

SAPNET .......................................................................................................................................... 33
SAP TECHNET ................................................................................................................................ 33

STARTING AND STOPING R/3 NT VERSION ....................................................................... 34

OPERATING SYSTEM TASKS ........................................................................................................... 34

ADMINISTRATOR TASKS ................................................................................................................. 34
PROCESS STARTUP SEQUENCE ....................................................................................................... 34
PARAMETER READ SEQUENCE ....................................................................................................... 35
LOGS AND TRACES.......................................................................................................................... 35
STARTUP DIAGNOSTICS .................................................................................................................. 35
BEFORE STOPPING THE R/3 SYSTEM .............................................................................................. 36
STOPPING THE R/3 SYSTEM ............................................................................................................ 36
BACKUP OFF-LINE: DATABASE RECONNECT................................................................................... 36

STARTING AND STOPING R/3 UNIX VERSION .................................................................. 37

OPERATING SYSTEM TASKS ........................................................................................................... 37

DATABASE STARTUP AND LOGS ..................................................................................................... 37
R/3 STARTUP AND LOGS ................................................................................................................. 37
STOPPING R/3 SYSTEMS ................................................................................................................. 38

CCMS CONFIGURATION ........................................................................................................... 39

OVERVIEW ...................................................................................................................................... 39
RZ10: PROFILE MAINTENANCE ..................................................................................................... 39
R/3 PROFILES ................................................................................................................................. 39
OPERATION MODES ........................................................................................................................ 40

Pgina 3
ACADEMIA BASIS

BACKGROUND PROCESSING .................................................................................................. 42

BACKGROUND CONCEPTS AND FEATURES ..................................................................................... 42

OPERATION MODES AND SCHEDULING .......................................................................................... 42
EVENTS IN JOB SCHEDULING.......................................................................................................... 43
CHANGING OR MONITORING BACKGROUND JOBS ......................................................................... 43
JOB API, XBP-API AND XMI-API ................................................................................................. 44
AUTHORIZATION FOR BACKGROUND JOBS .................................................................................... 44

ADVANCED BACKGROUND PROCESSING............................................................................ 45

TYPES OF BACKGROUND JOBS ....................................................................................................... 45

PARALLEL PROCESSING USING ASYNCHRONOUS RFC.................................................................. 45
XMI/XBP INTERFACE .................................................................................................................... 46
EVENTS IN JOB SCHEDULING.......................................................................................................... 46
EXTERNAL COMMANDS AND EXTERNAL PROGRAMS .................................................................... 47
AUTHORIZATIONS FOR BACKGROUND ........................................................................................... 47
ABAP API SCHEDULING ................................................................................................................ 47
BACKGROUND CHECK AND TROUBLESHOOTING ........................................................................... 48

DATA ARCHIVING ...................................................................................................................... 49

DEFINITION ..................................................................................................................................... 49
HOW ARCHIVE WORKS .................................................................................................................. 49
ARCHIVE ENVIRONMENT................................................................................................................ 49
ACESSING ARCHIVED DATA ........................................................................................................... 50
PREPARATIONS FOR DATA ARCHIVING .......................................................................................... 50
MONITORING AN ARCHIVING RUN ................................................................................................. 50

SYSTEM MONITORING ............................................................................................................. 52

WHAT, WHY, WHO AND WHEN ........................................................................................................ 52

MONITORING ARCHITECTURE ....................................................................................................... 52
PREPARING THE MONITOR ............................................................................................................. 52
MONITORING AND TOOLS .............................................................................................................. 53

SEGUNDA SEMANA .................................................................................................................... 55

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

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

AUTHORIZATION CONCEPTS .......................................................................................................... 55
AUTHORIZATION AS ER.................................................................................................................. 56
AUTHORIZATION CHECKS .............................................................................................................. 56
PROFILE GENERATOR .................................................................................................................... 56
USER MASTER RECORD .................................................................................................................. 58
SETTINGS FOR SYSTEM PROFILE PARAMETERS ............................................................................. 58
SECURITY ........................................................................................................................................ 58

Pgina 4
ACADEMIA BASIS

INFORMATION SYSTEM E AUTHORIZATION TRACES ..................................................................... 58

PASSWORD RULES .......................................................................................................................... 59
PROFILE GENERATOR SETUP ......................................................................................................... 59
TRANSPORTING AUTHORIZATIONS AND USERS ............................................................................. 59
SAPROUTER ................................................................................................................................... 60
SNC SECURE NETWORK COMMUNICATION ................................................................................... 60

SOFTWARE LOGISTICS ............................................................................................................ 62

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

R/3 DATA ........................................................................................................................................ 62
R/3 CLIENTS ................................................................................................................................... 62
STANDARD CLIENT ROLES ............................................................................................................. 63
R/3 LANDSCAPE .............................................................................................................................. 63
CHANGE REQUESTS AND TRANSPORTS .......................................................................................... 63

CHANGE AND TRANSPORT SYSTEM PREREQUISITES ..................................................... 65

CONFIGURING THE SYSTEM LANDSCAPE ....................................................................................... 65

INITIALIZING CTO ......................................................................................................................... 66
TMS - TRANSPORT MANAGEMENTA SYSTEM ................................................................................. 66

CHANGE MANAGEMENT FOR DEVELOPMENT .................................................................. 68

CHANGE REQUESTS ........................................................................................................................ 68

WBO - WORKBENCH ORGANIZER .................................................................................................. 68
DEVELOPMENT CLASS AND TRANSPORT LAYERS .......................................................................... 69
HANDLING REPOSITORY OBJECTS ................................................................................................. 70
THE REPOSITORY ........................................................................................................................... 70
R/3 UPGRADE.................................................................................................................................. 71
WORKBENCH ORGANIZER TOOLS.................................................................................................. 71
SETTINGS FOR WBO....................................................................................................................... 71
PLANNING CHANGE MANAGEMENT ............................................................................................... 72

CHANGE MANAGEMENT FOR CUSTOMIZING .................................................................... 73

CUSTOMIZING CONCEPTS .............................................................................................................. 73

CUSTOMIZING TOOLS IMPLEMENTATION GUIDE (IMG) ............................................................ 73
CUSTOMIZING CHANGE REQUESTS ................................................................................................ 74
CUSTOMIZING TESTS ...................................................................................................................... 75
CUSTOMIZING EXCEPTIONS ........................................................................................................... 75
CLIENT-INDEPENDENT CUSTOMIZING............................................................................................ 75
PLANNING CUSTOMIZING CHANGE MANAGEMENT ....................................................................... 75

TRANSPORT MANAGEMENT ................................................................................................... 77

TRANSPORT PROCESS ..................................................................................................................... 77

IMPORT QUEUES ............................................................................................................................. 77
TRANSPORTING BETWEEN TRANSPORT GROUPS ........................................................................... 78
TRANSPORT MONITORING.............................................................................................................. 78
TRANSPORT PROCESS ..................................................................................................................... 78

Pgina 5
ACADEMIA BASIS

ADVANCED TRANSPORT MANAGEMENT ............................................................................ 79

TRANSPORT DIRECTORY ................................................................................................................ 79

THE TP PROGRAM ........................................................................................................................... 79
THE R3TRANS PROGRAM ............................................................................................................... 80
THE IMPORT PROCESS.................................................................................................................... 80
TRANSPORT MONITORING.............................................................................................................. 82

CLIENT TOOLS ........................................................................................................................... 83

CLIENT TRANSPORT ....................................................................................................................... 83

CLIENT COMPARE .......................................................................................................................... 84
CLIENT MAINTENANCE SETTINGS.................................................................................................. 85
AUTHORIZATIONS FOR CLIENT TOOLS ........................................................................................... 85

CLIENT AND SYSTEM STRATEGIES ...................................................................................... 86

TYPES OF LANDSCAPES .................................................................................................................. 86

THREE-SYSTEM LANDSCAPES ........................................................................................................ 86
TWO-SYSTEM LANDSCAPES............................................................................................................ 86
ONE-SYSTEM LANDSCAPES ............................................................................................................ 86
LANDSCAPE REQUIREMENTS .......................................................................................................... 87
ASAP SYSTEM LANDSCAPE ............................................................................................................ 87
ASAP RECOMENDATIONS .............................................................................................................. 88
ALTERNATIVE LANDSCAPES ........................................................................................................... 88
TRANSPORT ORGANIZER ................................................................................................................ 89

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

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

R/3 UPGRADE.................................................................................................................................. 90
REPOSITORY SWITCH ..................................................................................................................... 91
MODIFICATION ADJUSTMENT ........................................................................................................ 92
AVOIDING MODIFICATIONS IN R/3 SYSTEMS ................................................................................. 92
ONLINE CORRECTION SERVICE (OCS) .......................................................................................... 93

TERCEIRA SEMANA................................................................................................................... 94

R/3 SPOOL AND PRINT............................................................................................................... 94

R/3 SPOOL SYSTEM......................................................................................................................... 94

SPOOL AND OUTPUT REQUESTS ..................................................................................................... 94
SPOOL WORK PROCESS .................................................................................................................. 94
LOCAL AND REMOTE PRINTING ..................................................................................................... 94
SPOOL ADMINISTRATION ............................................................................................................... 95
FRONTEND PRINTING ..................................................................................................................... 95
LOGICAL SPOOL SERVERS.............................................................................................................. 96
SPOOL REQUEST MANAGEMENT .................................................................................................... 96

Pgina 6
ACADEMIA BASIS

R/3 OUTPUT MANAGEMENT .................................................................................................... 97

DEVICE POOLS ................................................................................................................................ 97

EXTERNAL OUTPUT MANAGEMENT SYSTEMS (OMS) ................................................................... 97
SPOOL SERVER AND REQUESTS MANAGEMENT ............................................................................. 97
NON-STANDARD PRINTERS ............................................................................................................. 98
CHARACTER SET ............................................................................................................................. 98
FORMAT, PAGE FORMAT E FORMAT ACTIONS ............................................................................... 98
PRINT CONTROLS ............................................................................................................................ 98
MESSAGE CONTROL AND EDI ........................................................................................................ 98
SAPCONNECT ................................................................................................................................. 99

INSTALLATION CHECK .......................................................................................................... 100

HARDWARE E SOFTWARE ............................................................................................................. 100

ORACLE DATABASE ...................................................................................................................... 100
R/3 SYSTEM .................................................................................................................................. 101

R/3 WORKLOAD DISTRIBUTION ........................................................................................... 103

OVERVIEW .................................................................................................................................... 103

MECHANISM ................................................................................................................................. 103
LOGON LOAD BALANCING............................................................................................................ 103
BACKGROUND LOAD BALANCING ................................................................................................ 104
SPOOL LOAD BALANCING............................................................................................................. 104
UPDATE LOAD BALANCING .......................................................................................................... 104
CONFIGURATION SUMMARY......................................................................................................... 105

QUARTA SEMANA .................................................................................................................... 107

DATABASE FUNDAMENTALS ................................................................................................ 107

ORACLE OVERVIEW ..................................................................................................................... 107

STARTING AND STOPING THE DATABASE ..................................................................................... 109
ORACLE SHARED PROCESSES ....................................................................................................... 109
R/3 ORACLE STRUCTURE ............................................................................................................. 110
NET8 BASIS .................................................................................................................................. 111
DATABASE MONITORING .............................................................................................................. 112

BACKUP ESTRATEGY.............................................................................................................. 113

DATABASE BACKUP ...................................................................................................................... 113

BACKUP TYPES ............................................................................................................................. 113
BACKUP AND RECOVER DIAGRAM ............................................................................................... 114
DATA LOSS.................................................................................................................................... 114
BACKUP RECOMMENDATIONS ...................................................................................................... 114
FINAL RECOMMENDATIONS ......................................................................................................... 115

Pgina 7
ACADEMIA BASIS

TAPE MANAGEMENT .............................................................................................................. 116

TAPE POOLS.................................................................................................................................. 116

TAPE INITIALIZATION .................................................................................................................. 116
TAPE LOCKING ............................................................................................................................. 116
TAPE SELECTION .......................................................................................................................... 116
TAPE LAYOUT ............................................................................................................................... 117

SCHEDULING, PERFORMING AND MONITORING BACKUPS ........................................ 118

BACKUP TOOLS FEATURES ........................................................................................................... 118

BACKUP PROFILE PARAMETERS ................................................................................................... 118
PHASES OF DATABASE BACKUP .................................................................................................... 118
DATABASE BACKUP CHECK AND MONITORING ........................................................................... 119
OFFLINE REDO LOG FILES BACKUP............................................................................................. 119
LOG FILE CLEANUP ...................................................................................................................... 120
FREESPACE ADMINISTRATION ..................................................................................................... 120
ONE-RUN STRATEGY .................................................................................................................... 120
FURTHER DOCUMENTATION ........................................................................................................ 120

ADVANCED BACKUP TECHNIQUES ..................................................................................... 121

ONE-RUN STRATEGY .................................................................................................................... 121

CONSISTENT ONLINE BACKUP ..................................................................................................... 121
PARALLEL TAPE SUPPORT ........................................................................................................... 121
PARTIAL DATABASE BACKUPS ..................................................................................................... 121
BACKING UP DATA TABLESPACES ONLY ..................................................................................... 121
TWO-STEP DISK BACKUP ............................................................................................................. 122
STRUCTURES-RETAINING DATABASE COPY................................................................................. 122
SPLIT MIRROR DISK BACKUPS ..................................................................................................... 122
SAP TOOLS AND ORACLE STANDBY DATABASE .......................................................................... 123
EXTERNAL BACKUP TOOLS USING BC-BRI................................................................................. 123

RESTORE AND RECOVERY .................................................................................................... 124

DATABASE ERRORS ...................................................................................................................... 124

SCENARIO ..................................................................................................................................... 124
PARTIAL RESTORE AND COMPLETE RECOVERY.......................................................................... 124
DATABASE RESET ......................................................................................................................... 124
POINT IN TIME RECOVERY ........................................................................................................... 125
HOW TO PROCEED AND WHO SHOULD MANAGE THE PROBLEM ................................................ 125
PARTIAL RESTORE USING SAPDBA ............................................................................................ 125
DATABASE RESET USING SAPDBA .............................................................................................. 126
FULL RESTORE AND RECOVERY USING SAPDBA ....................................................................... 126

STORAGE MANAGEMENT ...................................................................................................... 127

SPACE MANAGEMENT................................................................................................................... 127

FRAGMENTATIONS........................................................................................................................ 127
DAILY MONITORING: SAPDBA -CHECK ..................................................................................... 127
TABLESPACE EXTENSION ............................................................................................................. 128
TABLES AND INDEXEX MONITORING ........................................................................................... 128
ANALYZING STORAGE ALLOCATION: SAPDBA -ANALYZE......................................................... 128

Pgina 8
ACADEMIA BASIS

REORGANIZATION ........................................................................................................................ 129

PERFORMANCE MONITOR .................................................................................................... 131

PERFORMANCE ISSUES ................................................................................................................. 131

COST-BASED OPTIMIZER.............................................................................................................. 131
MEMORY CONFIGURATION .......................................................................................................... 132
APPLICATION DESIGN................................................................................................................... 133
PHYSICAL AND LOGICAL LAYOUT ............................................................................................... 134

QUINTA SEMANA ..................................................................................................................... 136

TOP 10 PROBLEMS ................................................................................................................... 136

ARCHIVE STUCK SITUATION ........................................................................................................ 136

THE INCORRECT TAPE SIZE DRIVERS WITH HARDWARE COMPRESSION ................................... 136
A MISSING END BACKUP .......................................................................................................... 136
A TABLESPACE OVERFLOW ......................................................................................................... 137
A TABLE OR INDEX REACHING THE MAXEXTENTS LIMIT ...................................................... 137
ORACLE ERROR ORA-1555, SNAPSHOT TOO OLD ...................................................................... 137
NET8 TCP/IP DELAY.................................................................................................................... 137
ORACLE ERROR ORA-1578, DATA BLOCK CORRUPTION ........................................................... 138
ORACLE ERROR ORA-600, INTERNAL DATABASE ERROR .......................................................... 138
POOR PERFORMANCE OF THE COST-BASED OPTIMIZER ............................................................. 138

INTRODUCTION TO WORKLOAD ANALYSIS .................................................................... 139

PERFORMANCE PROBLEMS .......................................................................................................... 139

RESPONSE TIMES .......................................................................................................................... 139
WAIT TIME .................................................................................................................................... 139
ROLL IN TIME ............................................................................................................................... 140
DATABASE TIME............................................................................................................................ 140
PROCESSING TIME ........................................................................................................................ 140
CPU TIME ..................................................................................................................................... 140
WORKLOAD STATISTICS ............................................................................................................... 140
WORKLOAD ANALYSIS ................................................................................................................. 140
ANALYSIS ROADMAP USING WORKLOAD MONITOR (ST03) ......................................................... 141

PERFORMANCE ANALYSIS MONITORS.............................................................................. 142

WORK PROCESS OVERVIEW......................................................................................................... 142

ST06 - OPERATING SYSTEM MONITOR ........................................................................................ 142
ST02 - BUFFER MONITOR............................................................................................................. 142

R/3 MEMORY MANAGEMENT ............................................................................................... 143

R/3 MEMORY AREAS .................................................................................................................... 143

Pgina 9
ACADEMIA BASIS

LOCAL MEMORY .......................................................................................................................... 143

SHARED MEMORY ........................................................................................................................ 143
ALLOCATION CONCEPTS .............................................................................................................. 144
HEAP MEMORY MANAGEMENT.................................................................................................... 144
R/3 EXTENDED MEMORY ............................................................................................................. 145
ANALYSIS ROADMAP: R/3 MEMORY CONFIGURATION (ST02) ................................................... 145

HARDWARE CAPACITY VERIFICATION ............................................................................ 146

HARDWARE BOTTLENECKS .......................................................................................................... 146

ANALYSIS ROADMAP: HARDWARE CONSUPTION (ST06) ............................................................. 146
OPTIMIZING THE CONFIGURATION .............................................................................................. 146

EXPENSIVE SQL STATEMENTS ............................................................................................. 147

DETECTING EXPENSIVE SQL STATEMENTS ................................................................................. 147

MONITORS TO ANALYSE ............................................................................................................... 147
DETAIL ANALYSIS AND TUNING ................................................................................................... 148
TABLE STATISTICS FOR OPTIMIZER............................................................................................. 148
TIPS FOR OPTIMIZING ABAP ....................................................................................................... 148

TABLE BUFFERING .................................................................................................................. 149

CONCEPTS ..................................................................................................................................... 149

SYNCHRONIZATION ...................................................................................................................... 149
GRANULARITY OF INVALIDATION ................................................................................................ 150
BYPASSING THE BUFFER ............................................................................................................... 150
STRATEGY FOR TECHNICAL CRITERIA ........................................................................................ 150
OPTIMIZATION.............................................................................................................................. 151

OTHERS ASPECTS ABOUT ORACLE .................................................................................... 152

CACHE ANALYSIS ......................................................................................................................... 152

SHARED SQL AREA ...................................................................................................................... 152
ANALYZING SQL STATEMENTS ................................................................................................... 152
UPDATE STATISTICS ..................................................................................................................... 153
IDENTIFY CODING......................................................................................................................... 153
WORKFLOW AND REPORTING ...................................................................................................... 153
INDEX UTILIZATION ..................................................................................................................... 154
CREATING NA INDEX .................................................................................................................... 154
SIMILAR STATEMENTS.................................................................................................................. 154
VIEW PROCESSING........................................................................................................................ 155
POOLED AND CLUSTERED TABLES ............................................................................................... 155

WORKLOAD ANALYSIS GUIDE ............................................................................................. 156

DIRECTORY SUMMARY.......................................................................................................... 157

TO BE KNOWN .......................................................................................................................... 157

Pgina 10
ACADEMIA BASIS

ANEXOS ...................................................................................................................................... 159

GLOSSRIO ................................................................................................................................... 159

TRANSACTIONS ............................................................................................................................. 161
REPORTS ....................................................................................................................................... 166
OSS NOTES ................................................................................................................................... 167
RZ10 PARAMETERS ...................................................................................................................... 168

Pgina 11
ACADEMIA BASIS

Introduo

Plano de Estudo

A estratgia para o estudo durante a academia ser de sete horas durante o perodo de aulas na
SAP e de cerca de quatro horas dirias no hotel para rever a aula do dia. Idealmente a reviso da
sexta-feira deve ser feita no sbado e uma re-leitura de todo o texto da semana no domingo.

Este texto engloba e leva em conta o texto elaborado pelo meu grande amigo e colega de
empresa(cemig) Mrcio Cicarelli (cicareli@cemig.com.br), durante a academia de Unix/Oracle de
1999. Na prtica eu (jluiz@cemig.com.br) vou elaborando o meu prprio resumo e anexando as
partes elaboradas pelo Mrcio que acho relevantes. A ordem dos dois resumos um pouco diferente
e em alguns captulos os textos no tem nada a ver um com o outro, mas na maioria os textos so
bem parecidos ou com pequenas alteraes provocadas por um maior detalhamento ou comentrios.
S para ter uma idia at o momento este resumo tem 75 mil palavras e o do Mrcio tinha cerca de
44 mil. A minha previso que at o final ele tenha cerca de 80 mil palavras. Apesar deste alto
volume de palavras, o que interessa o contedo final (para eventualmente passarmos na prova).

Por enquanto, alm da reviso do texto, ainda no foi incluido os desenhos e figuras que acho
interessantes (para facilitar a compreeno dos conceitos). Elas sero disponibilizadas aps o aval da
SAP (elas so muito parecidas e funcionalmente identicas as que esto nas apostilas).

Advertncia

Todos os exemplos e conceitos apresentados nesse texto so meramente ilustrativos. Eles so

destinados apenas aos profissionais qualificados para as tarefas propostas, sendo extremamente
recomendados a anlise dos mesmos antes da sua execuo. No existe qualquer garantia, quer
implcita ou explcita, do perfeito funcionamento ou da aplicao dos conceitos aqui descritos. No
garantimos com relao ao uso, ou ao resultado do uso, das instrues aqui apresentadas, em
termos de correo, acurcia, confiabilidade, atualidade, ficando todos os riscos, tais como
resultados, por sua conta e total responsabilidade. Se os exemplos provocarem erros, perda de dados
ou quaisquer danos diretos, indiretos, decorrentes ou acidentais (incluindo danos por perda de
receita, interrupo dos negcios, perda de informaes e similares), voc e no o autor assume o
custo integral de todos os servios, reparos e correes necessrios.

A garantia acima descrita a nica de qualquer tipo, tanto explcita como implcita. Nenhuma
informao verbal ou escrita, ou anncio fornecido, pode contituir uma garantia ou de qualquer forma
aumenta o escopo dessa garantia.

Ao usar os exemplos e conceitos apresentados nesse texto, voc assume ter lido essa garantia
limitada, compreendido-a, e concorda em se submeter a seus termos e condies. Voc tambm
concorda que a garantia limitada o documento completo e exclusivo de acordo entre as partes e se
sobrepe a todos os acordos e propostas anteriores, verbais ou escritos, e qualquer outra
cominicao entre as partes com relao ao assunto termo de garantia limitada.

Alm disso, o texto esta na sua forma inicial e no recebeu nenhum tipo de reviso ortogrfica ou
gramatical, portanto voc certamente encontrar algumas frases com sentido duvidoso ou at mesmo
erros grosseiros de portugus. Isso ocorreu porque o texto foi sendo elaborado durante a academia.
Conto com a sua colaborao para corrigir o texto e agregar maiores detalhes ou informaes
relevantes. Desde j, muito obrigado pelas dicas que voc certamente enviar para o meu e-mail.

Direito de autoria

Lembre-se sempre, copiar no crime, ignorar o autor ou assumir todo o crdito .

Pgina 12
ACADEMIA BASIS

Marcas registradas.

DEC, DECNet, VAX e VMS so marcas registradas da Digital Equipment Corporation.

HP e HP-UX so marcas registradas da Hewlett-Packard.
Microsoft, WINDOWS, NT, EXCEL e SQL-Server so marcas registradas da Microsoft
Corporation.
IBM, MVS, OS/2, DB2/6000, AIX, OS/400 e AS/400 so marcas registradas da IBM
Corporation.
OSF/Motif uma marca registrada da Open Software Foundation.
ORACLE, Server manager, SQLPlus, Net8, SQL*Net so marcas registrada da
ORACLE Corporation, Califrnia, EUA.
INFORMIX-OnLine para SAP uma marca registrada da Informix Software Incorporated.
UNIX e X/Open so marcas registradas da SCO Santa Cruz Operation.
ADABAS uma marca registrada da Software AG.
SAP, R/2, R/3, RIVA, ABAP/4, SAPoffice, SAPmail, SAPaccess, SAP-EDI, SAP
ArchiveLink, SAP EarlyWatch, SAP Business Workflow e R/3 Retail so marcas
registradas da SAP AG.

Participantes da Academia

Participante Empresa Alguns e

Instrutores :
Erika Quirs SAP erika.quiros@sap.com
Luiz Mestrinel SAP luiz.mestrinel@sap.com
Rinaldo Morais SAP rinaldo.morais@sap.com e rinaldomorais@yahoo.com

Acadmicos :
Ana Maria Solangol asousa@sondist.ebonet.net
Aroldo Higashi Skyline ahigashi@dmc-2.com.br e aroudo.higashi@zipmail.com
Cludio Milos SAP claudio.milos@sap.com e milos27@hotmail.com
Joao Luiz Barbosa CEMIG jluiz@cemig.com.br e jluiz_barbosa@yahoo.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 Magalhes SAP ricardo.magalhaes@sap.com

Demais colaboradores :
Mrcio Cicarelli CEMIG cicareli@cemig.com.br

Pgina 13
ACADEMIA BASIS

Primeira Semana

R/3 Basis Technology

Basis System and the System Environment

The Integration Model

Sistema R/3 composto dos seguintes mdulos:

Logstica
SD Sales & Distribution
MM Materials Management
PP Production Planing
QM Quality Management
PM Plant Maintenance
Human Resources
HR Human Resources
Accounting
FI Financial Accounting
CO Controlling
TR Treasury
PS Project System
Industry and Cross-Application
WF Workflow
IS Industry Solutions (no vem no standard)

A camada Basis integra todos estes mdulos. a parte central do diamante do diagrama do R/3
e as demais so os mdulos funcionais. Estes mdulos se interconectam e interagem para garantir
que o sistema todo integrado, tanto na parte de processos quanto em relao a base de dados que

Business Framework Architecture

O Business Framework Architecture (BFA) a arquitetura estratgica do produto R/3. Ela trabalha
com business components que so os mdulos funcionais (FI, CO, etc.) configurveis para se adaptar
a cada empresa. Esta arquitetura fornece agilidade para se adaptar a um novo negcio, alm da
facilidade de se integrar com pacotes externos e fcil integrao com a internet e intranet, permitindo
desta forma uma fcil evoluo sem a interrupo da operao do negcio da empresa. O princpio
da arquitetura que cada componente possui vida prpria e sua complexidade esta restrita a ele
mesmo. Para o mundo externo somente os mtodos de interfaceamento so visveis e acessveis,
fato que garante a total conexo deste com os demais sem causar grandes impactos ou interferncias

O Business Framework se mostra no R/3 como uma famlia de componentes separados porm

Business Components: so os mdulos funcionais (FI, CO, etc.) so formalmente

conhecidos como componentes relativos ao negcio;
Business Objects: Ordem, Empregado, Material, etc. So o prximo nvel de hierarquia do
R/3. Pertencem a um Business component e podem ser considerados como objetos bsicos
do sistema;
BAPI Interfaces: So os mtodos com que os objetos de negcio so implementados dentro
do R/3 (criar uma ordem, alterar o endereo de um empregado, etc.) e eventualmente podem
ter mais de uma verso para o mesmo interfaceamento.

A forma bsica de distribuir as informaes o ALE e este ser detalhado mais a frente.

Pgina 14
ACADEMIA BASIS

R/3 as an Open System

O R/3 utiliza protocolos standard da industria para garantir a integrao com outras aplicaes:
TCP/IP: o protocolo de comunicao difundido mundialmente;
EDI: Electronic Data Interchange, o mecanismo utilizado para trocar informaes de negcio
com diferentes sistemas; muito utilizado pelos bancos;
OLE: Object Linking and Embendding, integra aplicaes PC com o R/3 (padro microsoft);
Open Interfaces, tais como arquivamento tico, dispositivos de cdigos de barras, etc.

Alm de standard da indstria, o R/3 tambm utiliza

RFC: Remote Function Call, que utiliza o protocolo copiado do CPI-C da IBM para
comunicao e processamento das aplicaes e tasks dentro do sistema R/3 ou com o
sistema R/2 ou outros sistemas;
ALE: Application Link Enabling permite o processamento distribudo dentro do R/3. Na prtica
est associado a distribuio de informaes a partir de um modelo de divulgao
preestabelecido;

Scalability and the Client/Server Concept

O R/3 possui uma arquitetura modular de software seguindo o princpio da arquitetura

cliente/servidor com enfoque na distribuio da fora de processamento entre as vrias plataformas
envolvidas.

Esta arquitetura permite que se separe a lgica da aplicao da base de dados e da camada de
apresentao. Esta configurao permite ainda otimizar os custos e distribuir a carga atravs de
configuraes variadas de hardware. Com isto possvel dimensionar os servidores de acordo com a
carga, permitindo a fcil escalabilidade do ambiente.

Os ganhos nesta arquitetura na implementao R/3 so muitos:

Simples instalao de novos servidores para eliminar eventuais gargalos de processamento;
Servidores trabalham em paralelo, com carga homognea e execuo local dos programas;
Baixo trfego de rede com a localizao dos buffers de dados e programas prximo de onde

Balanceamento de carga, seja para o processamento online (logon) seja para o

processamento batch.

Ou seja, o ponto alto da arquitetura a facilidade para escalar e aumentar o poder de

processamento

Client/Serve Principles

Na implementao R/3, a arquitetura client/server orientada para o software, e no para o

hardware como estamos acostumados a ver. Desta forma, Client quem requisita e utiliza o servio e

Um servidor de aplicao por exemplo server de alguns servios das estaes clients, porm
client dos servios fornecidos pelo servidor de banco de dados. Ou seja, o conceito do papel de quem
o cliente e de quem o servidor o que prevalece no importando quem tem mais hardware ou
quem normalmente executa a atividade.

R/3 System Client/Server Configurations

Os servios (ou camadas) fundamentais de uma aplicao so trs: Presentation, Application e

Database services e existem vrias formas de se implementar um sistema R/3, a saber :

Pgina 15
ACADEMIA BASIS

Central, onde todos os componentes esto implementados em um mesmo host. Esta

implementao corresponde a clssica implementao mainframe e no comum de ser
implementada;
Two-tier, onde uma camada normalmente executa as funes de presentation (usualmente
um PC) e a outra camada executa os servios de application e database. Uma outra
implementao two-tier poderia ser uma camada executando os servios de database e a
outra composta por PCs mais potentes que executariam as funes de presentation e
application. A primeira implementao comum em ambientes pequenos e com pouca
disponibilidade de hardware para os servidores. A ltima implementao normalmente
utilizada em simulaes ou desenvolvimento de software.
Three-tier, onde cada servio tem o seu prprio host. Nesta configurao possvel ainda
assegurar uma diviso de carga na camada de aplicao, garantindo que determinados hosts
fiquem dedicados para aplicaes especficas. Por exemplo dedicar um host para servidor de
aplicao dos usurios de MM, ganhando com isto performance na distribuio dos servios.

A configurao three-tier a mais recomendada em R/3 por garantir a melhor distribuio de

carga e escalabilidade nos grandes sistemas. Todos os servidores em uma configurao R/3 devem

Um sistema R/3 agrupa todos os componentes que esto associados com um banco de dados. Se
utilizamos uma implementao em 3 camadas, os componentes do R/3 estaro presentes em todas
as camadas da hierarquia:
Database Server, instalado em um host central, onde todos os servios de bancos de dados

Um ou mais Application Servers conectados ao servidos de banco de dados. Nestes

servidores estaro sendo processados a lgica da aplicao, ou seja, os programas.
Vrios Presentation Servers conectados aos servidores de aplicao. Estas mquinas so
tambm chamadas de frontends ou workstations. Nestas mquinas os usurios iro interagir
com o sistema R/3 utilizando uma interface que prover os servios de presentation.

The Middleware Basis

O software Basis do R/3 (tambm chamado de middleware) roda em diferentes plataformas e

tambm pode ser adaptado para atender as necessidades individuais das empresas. So vrios os

Prov o ambiente de runtime para as aplicaes R/3

Cuida da perfeita interao das aplicaes com o sistema
Define uma arquitetura estvel para as melhorias do sistema
Contm todas as ferramentas necessrias para a administrao do ambiente
Permite a distribuio eqitativa dos recursos e componentes do sistema
Prov as interfaces necessrias para os sistemas descentralizados e os produtos externos ao
R/3

As principais caractersticas da tecnologia Basis so:

uma arquitetura voltada para a configurao client/server
Trabalha com bancos de dados relacionais
Possui interface grfica com o usurio (GUI)

Basis o responsvel ainda pela integrao dos aplicativos e do ABAP workbench com o software

Portability and System Plataforms for the R/3 System

Para garantir uma alta portabilidade, as interfaces com o software bsico so divididas em suas
prprias camadas que variam de sistema para sistema (NT ou UNIX, Oracle ou Informix, etc.). Acima
destas camadas as funcionalidades dos componentes R/3 so basicamente as mesmas,
independentemente do hardware, software ou sistema operacional.

Pgina 16
ACADEMIA BASIS

A System Interface responsvel pelo interfaceamento do R/3 com as diversas plataformas em

que ele pode ser implementado. A Flow Control fica logo acima das interfaces com o software bsico
(System Interfaces). Ele o responsvel por tarefas tipo scheduling ou gerenciamento de memria,
tarefas estas muito prximas ainda do sistema operacional e que so parcialmente efetuadas por ele,
mas so gerenciadas pelo R/3 por razes de portabilidade e performance. A User Interface prov as
opes de apresentao dos aplicativos. A Communication Interface o canal para a troca de
informaes, seja pela transferncia de dados com o legado, seja pela comunicao program-to-
program provida pelo protocolo CPI-C ou ainda atravs da troca de informaes pelo protocolo EDI.
Todos os programas no R/3 so escritos na linguagem ABAP, proprietria do sistema. O DYNPRO
o screen interpreter e o sistema possui ainda um ABAP interpreter. A interao entre estes dois
componentes forma a tecnologia Basis das aplicaes R/3. O funcionamento destes dois
interpretadores (tela e programa) se baseia em informaes armazenadas no dicionrio do sistema, o
ABAP Dictionary.

System Plataforms for the R/3 systems

O R/3 roda nos mais diversos hardwares, sejam plataformas Intel, Risc ou Unix Systems. Os
sistemas operacionais so tambm os mais diversos, de acordo com as plataformas utilizadas (AIX,
Solaris, HP-UX, Windows NT, OS/400,etc.). Os bancos de dados utilizados pelo R/3, todos relacionais
so: Oracle, Informix, MS SQL Server ou ainda o DB2 para as diversas plataformas. O SAPGUI que
faz a camada de apresentao possui verses para Windows (3.1, 95, NT), OS/2 e Java. As
linguagens utilizadas no R/3 so ABAP (aplicaes com entendemos no R/3), C e C++ (para
construo do kernel) e HTML e Java (para a parte de intranet e internet).

Pgina 17
ACADEMIA BASIS

Navigation

Logging onto R/3 System

O R/3 um sistema voltado para clients. Com este conceito possvel controlar vrias empresas
em nico sistema, separando-as por client (ou mandante). As chaves para se logar no sistema
tambm so separadas por client. Para efetuar um logon preciso ter chave no client especfico.
Alm disso o sistema exige uma password e por ser multilngue, deve-se ainda especificar a lngua
desejada no momento do logon.

Um client pode ser visto como uma entidade organizacional separada dentro do R/3, com seus
prprios dados (master data, transaction data), user master records e parmetros especficos de
customizao. Apesar dos dados serem armazanados em tabelas nicas, os dados dos diferentes
clients coexistem separados pela diferenciao do campo MANDT que faz parte da chave da maioria
das tabelas (client dependents). A nica exceo a tabela T000 (definio dos clients no sistema)
que independent apesar de ter como primeiro o campo MANDT.

O conceito de customizao a adaptao do sistema R/3 para as necessidades especficas de

um usurio. Ao instalar um sistema R/3, ele vem basicamente com 3 clients default:
000 definido como um SAP standard no dever ser alterado pelos clientes, devendo ser
utilizado como um template para a criao de novos clients
001 uma cpia do 000 com algumas configuraes j feitas para facilitar o trabalho (vale
somente para os Estados Unidos). A partir da verso 4.0 este cliente j pode ser apagado e foi
mantido apenas para compatibilidade com as verses anteriores.
066 utilizado pela SAP para se logar no ambiente do usurio para a execuo de
determinadas tarefas

Um client identificado pelos trs dgitos numricos e, com exceo dos 3 citados acima, cada
instalao pode definir quantos clients se desejar (ou a sua base de dados suportar).

R/3 Menu Structure

Uma vez logado no sistema R/3 o sistema exibe um menu principal, onde temos as principais
reas do R/3 (Logistic, Accounting, Human Resources) entre outras entradas. Ao se escolher uma
determinada entrada o sistema exibe um menu pull-down com opes de cascading em algumas
entradas. As opes System e Help so comuns a todas as telas do sistema. Um nvel abaixo fica o
menu especfico de cada aplicao, que exibe as funes bsicas disponveis para aquele sistema
(criar um registro, por exemplo). Dynamic Menu disponvel na tela inicial d a opo de navegar em
todas as opes disponveis no formato de rvore do explorer, podendo selecionar a funo
desejada. uma ferramenta que permite efetuar searchs por palavras chave.

Uma tela tpica do sistema R/3 possui as seguintes partes:

Title Bar, exibe o ttulo da task que est sendo executada

Command Field, onde se pode escolher uma task diretamente sem a necessidade de
navegar no menu
Options, (tres bolas coloridas no canto superior direito), onde se pode configurar a interface
SAPGUI de acordo com necessidades individuais dos usurios
Standard Toolbar, onde se encontram os cones mais freqentemente usados para
navegao no sistema, bem como cones para salvar dados e ativar o online help
Checkboxes, Radio buttons, Text boxes e outras interfaces comuns no ambiente windows
para a exibio de dados
Status bar, exibe informaes referentes ao status atual do sistema (session number, system
name, application server, worksations time, alm de mensagens de interao com o usurio.
Text box inicializados com interrogao (?) so de preenchimento obrigatrio

Pgina 18
ACADEMIA BASIS

Uma tela no R/3 pode ser acessada de 3 maneiras distintas:

Selecionando a opo no menu
Atravs de teclas de atalho (ALT + tecla)
Atravs do cdigo da transao diretamente digitado no command field

O command field aceita vrios comandos que funcionam em conjunto com o cdigo da transao
/n para encerrar a transao atual
/o para abrir uma nova sesso
/i para encerrar a sesso corrente
/nend e /nex para efetuar logoff no sistema com e sem prompt, respectivamente

Veja as notas 26171 (Possible entry values for command fields) e 182592 (Delete/change
transactions codes in command fields) para saber mais a respeito do command field.

A tecla F1 ativa o help de campos, menus, funes e mensagens. Help tambm exibe informaes
tcnicas referentes aos campos de uma tela, como por exemplo o parameter ID do campo que pode

Own Data do menu System permite ao usurio especificar

valores defaults para seus campos, baseado no ID do campo (ver technical info). Na opo System
possvel ainda configurar a lista de favoritos de cada usurio (User Profile Favorite maint)

Session Manager uma ferramenta que permite ao usurio gerenciar todo o ambiente e at
mesmo vrios sistemas de uma nica interface. No release 4.0 esta ferramenta ainda no se encontra
em um estgio muito til, mas cresceu muito no release 4.6. De qualquer forma esta ferramenta no
parece ser muito adequada ao ambiente windows pois ela simula a funcionalidade da barra de tarefa
e a cada nova janela ela tenta fazer um novo login, ou seja, ela um pouco lenta. Ele tambm pode
ser acessado a partir do R/3. Ele o boto dynamic menu e monta toda a arvore de menus do R/3.
muito til para descobrir a transaction e o caminho de menu associado a ela.

Pgina 19
ACADEMIA BASIS

System Kernel

R/3 Presentation Interface

A interface de apresentao do R/3 o SAPGUI que apresenta uma funcionalidade muito parecida
entre as diversas plataformas do R/3. Um usurio treinado em uma determinada plataforma, salvo
pequenas excees est apto a operar o sistema nas suas mais diversas implementaes. O fluxo de
informao entre o SAPGUI e o servidor de aplicao no consiste de telas preformatadas, mas sim
de strings lgicos contendo dados e caracteres de controle, o que faz com que o trfego de dados se
mantenha na casa de 1 a 2K por tela (cada enter). Estes strings so na verdade um protocolo de
comunicao que sempre utilizado para conversar com o dispatcher e chamado de DIAG
(dynamic information and action gateway) 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 so compostas de tabelas bidimensionais e
interagem com os sistemas atravs da linguagem padronizada SQL (Structured Query Language) que
comum a todas as implementaes de bases relacionais, embora cada fabricante implemente
algumas extenses no seu produto.

O DB Interface um mdulo dentro do R/3 que converte os comandos SQL codificados nos
programas ABAP para o SQL nativo do banco implementado em cada ambiente R/3. Ou seja, cada
implementao (Oracle, Informix, SQL Server) possui um mdulo de DB Interface particular para
aquela implementao, o que torna os programas ABAP independentes da implementao do banco.

Estes comandos SQL escritos no ABAP so denominados OPEN SQL e o DB Interface

responsvel pela sua correta transcrio para o SQL nativo do banco. Alm disso, um programa
ABAP pode codificar o comando diretamente em Native SQL. Neste caso o comando no passar
pelo DB Interface, indo diretamente para a DB machine. Estes comandos podero no ser
independentes do banco utilizado, se utilizarem extenses particulares de um determinado RDBMS.

Os comandos SQL escritos em OPEN SQL tem sua sintaxe verificada pelo DB Interface que
inicialmente faz um acesso no buffer interno do application server para evitar acessos desnecessrios
ao DB server. Comandos escritos em native SQL no fazem uso deste buffer interno, uma vez que o

Normalmente as tabelas que vemos no R/3 so armazenadas no DB. Estas tabelas so

conhecidas com tabelas transparentes. Elas so implementadas no DB exatamente como vemos no
dicionrio do R/3. Existem outros tipos de tabelas que so declaradas no dicionrios mas no so
implementadas exatamente como aparecem. As tabelas do tipo Pool so declaradas no banco como
uma s mas para o R/3, aparentemente, so tabelas como outras quaisquer. Este recurso utilizado
para tabelas de poucas ocorrncias e para evitar um grande nmero de tabelas. Existem tambm as
tabelas tipo Cluster. Essas so uma desnormalizao do dado dentro do modelo relacional. Mais
precisamente como se tivssemos o conceito de campos mltiplos dentro de um registro (que
infringe a primeira regra normal).

O DB Interface no o processo que acessa e mantm a conexo com o banco. Este processo
conhecido como shadow process e roda na mquina onde est o banco de dados fazendo a ligao
do db interface, que est na maquina onde est a instance, e o banco de dados.

Pgina 20
ACADEMIA BASIS

Work Processes and Dispatcher

Os principais componentes de um application server so:

Um dispatcher como o controle central da instance
Dispatcher queues para enfileirar as requisies (FIFO)
Um nmero configurvel de work processes para processar os programas ABAP
Buffers e shared memory.

Os work processes so servios dentro de um sistema R/3 especializados em determinadas

tarefas.

O centro de um sistema R/3, a nvel de controle de aplicao, o Dispatcher. Ele, juntamente com
o sistema operacional, o responsvel pelo controle e disponibilizao dos recursos do sistema.
Suas principais tarefas so o controle da comunicao, a conexo com o presentation e a distribuio
de carga entre os work processes. O dispatcher distribui os servios requisitados entre os WP
disponveis e se encarrega de enviar o dado processado para o SAPGUI, que dever interpret-lo e
exibir para o usurio. No existe um WP fixo para um determinado usurio, cuidando o dispatcher de
ir utilizando-os conforme as requisies vo chegando, em um processo de fila FIFO.

Quando um sistema R/3 inicializado, o dispatcher o responsvel por lr os parmetros de

configurao (profiles), gerar as rol areas, inicializar os work processes e se conectar com o message
server da central instance.

Cada dialog work process coordenado por um componente interno denominado Task Handler.
Ele ativa o screen processor ou o ABAP processor e ainda o responsvel pelo roll in e roll out das
reas de usurio. Existem memrias de uso exclusivo de um determinado work process e memrias
que podem ser compartilhadas por todos eles. Esta diferenciao gerenciada pelo memory
management. A memria utilizada exclusivamente por um work process possui duas reas
reservadas para dados especficos de uma determinada sesso de usurio (user context area) e
devem ser mantidas entre as pseudo conversas do dialog. Estas reas so denominadas roll e
paging areas. A roll area contm dados que ficam imediatamente disponvel para o processamento no
incio do dialog step (roll in) e salva novamente no final do dialog step (roll out).

Este mecanismo de roll in e roll out que permite o share dos work process permitindo o
compartilhamento do recurso entre todos os usurios. Nesta rea so salvos os dados referentes ao
usurio (user context) tais como suas autorizaes, informaes administrativas alm de dados
adicionais para o ABAP e dialog processors, que so dados que j foram coletados por dialog steps
anteriores.Na shared memory existem dados disponveis para todos os work processes, tais como o
calendar, screen, table e program buffers.

R/3 Application Services

Um sistema R/3 composto de uma srie de work processes que funcionam em paralelo
cooperativamente. Cada application server possui um dispatcher e um nmero configurvel destes
processos, que depende dos recursos disponveis no host (basicamente memria e processamento).
Work processes podem ser instalados para efetuar servios de dialog, update, background e spool.

Uma central instance possui ainda servios de enqueue (que tambm um work process) para
gerenciamento de lock e dois outros servios prprios:
Message Server responsvel pelo servio de comunicao entre os vrios dispatchers que
compem um sistema R/3, que portanto um pr requisito para a escalabilidade de vrios
servidores de aplicao trabalhando em paralelo. Ele muito usado para a troca de dados de
controle.
Gateway Server, tambm chamado de CPI-C handler, que permite a comunicao entre R/3,
R/2 e aplicativos externos. muito utilizado para trocar dados da camada da aplicao,
incluindo ai dados da mesma instncia.

Resumindo, uma instncia nomeada pelos servios que ela presta. Um bom exemplo disto a
instncia DVEBMGS00 que possui dialog, update, enqueue, batch, message, gateway e spool e
todos respondendo pelo system number 00 que significa que a porta 3200 ser utilizada pelo sapdp00

Pgina 21
ACADEMIA BASIS

(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

Transaes so unidades de processamento agrupadas em funes que executam alteraes

consistentes na base de dados, de acordo com a funcionalidade a que se propem. Um exemplo
tpico seria o dbito em uma conta para crdito em outra, que somente fazem sentido consistente
quando executadas como um todo.

Uma transao SAP implementada atravs de uma srie de dialog steps consistentes e
conectados de forma coerente. Uma transao SAP no executa necessariamente em um nico work
process, uma vez que cada um dos seus dialog steps podero estar sendo atendidos por WP
diferentes que o dispatcher encontrou disponvel em cada momento. Alm disso, quando se utiliza o
asynchronous update para processar as atualizaes da base de dados, estes processos estaro
sendo atendidos por outros work process que podero inclusive se encontrar em outros hosts.

No R/3 cada dialog step composto de um processamento que inicia aps o usurio entrar o dado
(PAI Process After Input) e pelo processamento e envio da prxima tela (PBO Process Before
Output). Do ponto de vista do usurio, cada dialog step comea com o preenchimento de uma tela e o
posterior processamento at o envio da prxima tela. Para o sistema apenas as partes referentes ao
processamento (PAI e PBO) compem o dialog step j que durante o preenchimento da tela nenhum

Este conceito de transao, que pode compor de um ou vrios dialog steps, chamado de LUW,
ou Logical Unit od Work. Como os bancos de dados no suportam o conceito de transao para
todos os processos conversacionais (begin/end transaction commands), necessrio saber
diferenciar uma transao do ponto de vista SAP (SAP-LUW) de uma transao de banco de dados
(DB-LUW) que totalmente executada ou totalmente desfeita. No existe meio termo numa DB-LUW.
Enquanto uma SAP-LUW garante a integridade lgica do banco de dados (um determinado
lanamento dever existir nas tabelas x, y e z), uma DB-LUW garante a integridade fsica do DB e
executado necessariamente pelo gerenciador do banco. Uma transao SAP inicia uma SAP-LUW
que somente termina ao encontrar um comando COMMIT WORK no programa ABAP ou ento no
final do asynchronous update.

Lock Concept and Asynchronous Update

A tcnica principal utilizada numa SAP-LUW a atualizao assncrona, onde as requisies de

update na base de dados so coletadas separadamente e iniciam aps o COMMIT WORK, onde so
executadas em uma nica DB-LUW para garantir a integridade do banco.

Os mecanismos de lock existentes nos gerenciadores de bancos de dados no so suficientes

para garantir a correta manipulao dos objetos de negcio, que muitas vezes envolvem uma srie de
tabelas em um nico lanamento. Com o seu prprio mecanismo, O R/3 assegura que determinados

Pgina 22
ACADEMIA BASIS

dados permaneam protegidos durante todo o processo de atualizao do objeto. Esta tarefa
executada pelo Enqueue Work Process que utiliza uma tabela armazenada na memria principal (de
onde o enqueue work process est rodando, tambm conhecido como enqueue server e
normalmente a central instance) para este gerenciamento.

Sempre que um lock requisitado o sistema verifica (atravs do enqueue wp) se a requisio no
fere outro lock j postado na tabela. Havendo coliso de interesses, o processo informado atravs
de uma mensagem de erro, o que permite ao programa ABAP informar ao usurio que a sua
operao no poder ser executada no momento. Caso o enqueue work process no se encontre na
mesma instance em que o processo est correndo, o que normal em uma sistema R/3 de tres
camadas, esta comunicao efetuada pelo message server.

Para que este mecanismo de requisio de lock funcione no sistema R/3, necessrio que um
objeto de lock seja definido no dicionrio ABAP especificamente para aquele objeto que se deseja
travar. J existem objetos definidos em uma tabela primria no dicionrio do R/3, porm o usurio
pode definir seus prprios objetos em tabelas secundrias (estes objetos do usurio precisam ter

Os locks podem ser do tipo S (read) ou E (write). Um lock do tipo E somente poder ser
postado se no existe nenhum outro lock j definido sobre o registro. Quando um objeto de lock
ativado, o sistema gera duas funcion modules, uma para ENQUEUE_<object> e outra para
DEQUEUE_<object>. Os lock postados por um programa permanecem at que sejam retirados pelo
prprio programa ou ainda pelo procedimento de update (segunda parte da SAP-LUW).

Work processes podem gerar atualizaes diretamente na base de dados mesmo que o banco
no se encontre no mesmo host. Quando o programa ABAP utiliza os comandos CALL FUNCTION
... IN UPDATE TASK, criado no R/3 o mecanismo de asynchronous update. Neste caso a
requisio direcionada para uma tabela (a VBLOG) existente fisicamente no banco de dados que
age como um buffer intermedirio onde as requisies de atualizao so enfileiradas.

Esta tabela contm basicamente o nome da rotina que ser disparada para efetuar a atualizao e
os dados (parmetros) para a rotina efetuar as atualizaes necessrias. Transaes que so
canceladas pelo usurio no tem o seu registro de header completado na VBLOG e portanto suas
atualizaes no so efetuadas. Os registros de atualizao podem ser divididos em componentes V1
e V2. Basicamente processos que so crticos so armazenados em componentes V1 e processos
secundrios que so menos time-criticals so armazenados nos componentes V2. Informaes de

O processo assncrono de update disparado pelo comando COMMIT WORK especificado no

ltimo dialog step de uma SAP transaction. Nesta fase que ocorre na segunda parte da SAP-LUW, os
registros escritos na VBLOG so recuperados e atualizados fisicamente na base de dados. Caso
ocorram erros nesta fase em processos V1, as alteraes no DB daquela DB-LUW so desfeitas por
rollback e os registros permanecem na VBLOG assinalados com um flag de erro. Caso ocorram erros
em processos V2, apenas aquele registro ser setado com erro e as demais atualizaes V2
continuam sendo executadas.

Quando ocorrem os erros descritos acima, o usurio notificado atravs de mail e medidas
corretivas precisam ser avaliadas. Ao trmino da SAP-LUW, a task de update remove os locks
postados pelos dialog steps anteriores. Caso ocorram erros durante o update os locks tambm sero
removidos.

Updates pendentes com erro podem ser restartados pelo administrador do sistema. A SAP no
recomenda que updates V1 sejam restartados, devendo este procedimento somente ser efetuado
para updates dos tipo V2. Processos V1 devero ser regerados processando novamente a transao
(veja a nota 16083)

Quando um sistema R/3 sai, as entradas que esto com status INIT na VBLOG so processadas
to logo o sistema retorne ao ar. Esta funcionalidade pode ser parametrizada pela profile do sistema.

Resumindo uma SAP-LUW, onde cada tpico um dialog step :

usurio abre uma transao para atualizar uma determinada informao; Na prtica o SAPGUI do
usurio entra em contato com o dispatcher da instncia em questo e aciona o PAI da janela
corrente e providencia a exibio da janela desejada;

Pgina 23
ACADEMIA BASIS

usurio preenche os dados chave para a identificao da informao e o PAI novamente

acionado. Neste momento o work process selecionado pelo dispatcher para tratar deste dialog
step localiza a informao desejada atravs do DB Interface e solicita ao Enqueue que a
respectiva informao seja locada. Isto feito pela funo call function enqueue e pela incluso
da lock table que fica na memria da onde esta sendo executado o enqueue.
usurio, de posse da janela com os dados a serem atualizados, atualiza a informao e inicia um
novo dialog step. Este o dialog step da nossa transao. Ele vai chamar a funo call function in
update task que incluir as informaes a serem atualizadas na tabela vblog. Para o dialog work
process a atividade encerra quando o commit work realizado. Mas na verdade para o R/3 o
assunto ainda no est terminado pois o work process de update, a partir da tabela vblog, vai
providenciar que a atualizao seja feita nas tabelas que possuem as informaes reais e
call function dequeue. Esta parte da transao, que feita pelo
update work process conhecida como a segunda parte da SAP-LUW.

Background Processing

Processos que so schedulados para processamento pelos background work processes so

tratados no sistema da mesma forma que os processos online. Processos background so
schedulados na forma de jobs. Cada job possui um ou mais steps (que podem ser external ou ABAP
programs) que so processados seqncialmente.

Atravs das classes de processamento (A, B ou C) possvel setar prioridades entre os jobs. Os
jobs batch normalmente no so schedulados para processamento imediato, mas so especificados
para uma data/hora futura podendo ainda, quando necessrio, serem definidos como peridicos.

O batch scheduler o responsvel pelo disparo automtico dos jobs configurados no sistema.
Este mdulo um programa ABAP que roda em um dialog work process por instncia do sistema
R/3. Ele varre a tabela de scheduling e encontrar um job candidato o encaminha para processamento
pelos background work processes. O sistema efetua balanceamento de carga para distribuir os jobs
batch entre os diversos servers que possuem work processes disponveis (do tipo B). Jobs batch
podem ainda ser schedulados para processamento em servers especficos. Na escala de prioridade,
para os jobs com mesmo horrio de inicio, os Jobs classe A tem maior prioridade que os classe B e
por ltimo os jobs classe C. Dentro de um mesmo servidor e jobs schedulados com a mesma classe,
tem prioridade aquele schedulado com especificao explcita de server (sem balanceamento). A
partir da a ordem de inicializao definida pela ordem de criao do job. Se for necessrio saber a
ordem em que os jobs sero executados basta abrir a SM37, listar os jobs e classifica-los pela ordem
cronologica. Se houver alguns jobs no mesmo horrio devemos entrar em um a um para ver a data de
criao e descobrir qual a ordem exata de execuo.

Se for necessrio bloquear a execuo de jobs, basta setar o parmetro rdisp/btctime = 0

R/3 Printer Services

Spooling a transferncia bufferizada de dados para dispositivos de sada do tipo printers, fax,
etc. O R/3 suporta spooling para dispositivos locais ou em rede. As requisies de spool so geradas
tanto pelo processamento online (dialog) quanto pelo processamento batch (background). Os dados a
serem impressos ficam armazenados nos TemSe (Temporary Sequential Objects). Quando o sistema
necessita de impresso, gerado um output request que encaminhado para um spool work
process. Uma vez formatado o dado para impresso, a requisio de impresso encaminhada para
o spool do sistema operacional, que fica responsvel pelo encaminhamento do output request para o

R/3 Instance

Uma instncia R/3 uma unidade administrativa que combina componentes de um sistema R/3
para prover um ou mais servios. Todos os servios providos por uma instncia so iniciados (start da
instncia) e parados (stop da instncia) ao mesmo tempo. Uma instncia parametrizada atravs de
parmetros que descrevem todas as suas caractersticas.

Pgina 24
ACADEMIA BASIS

Cada instncia possui seus prprios buffers e um sistema R/3 central composto de uma nica
instncia que possui todos os servios (DVEBMSGnn). O message server o responsvel pela
comunicao entre os application servers e um central message service para prover servios de
update trigger, enqueue e dequeue, background requests, e outras pequenas trocas de informaes
(normalmente dados de controle e pequenas quantidades de dados da camada de aplicao)

Cada dispatcher de um application server se comunica com um nico message server em cada
ambiente R/3, que portanto s instalado uma nica vez na central instance. ele quem atribui qual
work process vai processar o dialog step que est iniciando. O controle desta fila armazenada na
dispatcher queue, tambm conhecida como request queue. Alm dos dispatcher, os presentation
(SAPGUI) podero se logar nos application server atravs do message server para desta forma
efetuar balancemento automtico de carga (load balancing). O gateway o responsvel pela troca de
dados (normalmente com bom volume de dados) entre as instncias de um sistema R/3, entre
sistemas R/3 e entre um sistema R/3 e outros sistemas

So as profiles que configuram as diversas instncias e desta forma definem quem executa quais
servios que estaro disponveis. Por nomeclatura costumamos chamar os dialogs, background,
enqueue, update e spool de work process e o gateway e message de servios.

Pgina 25
ACADEMIA BASIS

Interfaces

R/3 as an Open System

R/3 um sistema aberto que permite a comunicao com vrias outras plataformas, quer seja
entre as instncias de um sistema R/3 ou com outros sistemas R/3, R/2 ou sistemas no SAP atravs
de rede. A Comunicao em rede pode ser dividida em 7 camadas, onde cada camada serve de
interface entre a camada de baixo e camada de cima. Do ponto de vista da programao,
desenvolver uma comunicao entre sistemas mais fcil a medida que esta conversa
implementada nas camadas mais superiores.

A SAP suporta os protocolos TCP/IP e SNA LU6.2. A comunicao entre sistemas R/3 se d em
TCP/IP e a comunicao LU6.2 utilizada para a comunicao com sistemas R/2 baseados em
mainframe. A programao R/3 suporta ainda CPI-C, RFC e OLE Automation como interfaces de
comunicao. Os dois primeiros protocolos so proprietrios da SAP e o OLE um protocolo da
Microsoft para a comunicao entre aplicativos na plataforma windows

R/3 Gateway Service

SAP Gateway o CPI-C handler, responsvel pela conexo entre os protocolos TCP/IP e LU6.2,
utilizado para a conexo entre sistemas R/3 e sistemas R/2 baseados em mainframe. O Gateway
pode rodar tanto em um application server quanto em um database server. Pequenas mensagens,
como visto anteriormente, fluem entre os application e a central instance em um sistema R/3 atravs
do message server. J os volumes mais elevados de dados, tais como os dados da aplicao fluem

Com isto podemos ver que a comunicao atravs do gateway tanto pode se dar dentro de um
sistema R/3 quanto entre um sistema R/3 e um sistema R/2 ou com programas externos. O gateway
utiliza o protocolo TCP/IP, atravs de RFC, para comunicao com os clients e LU6.2 apenas para a

Communication with CPI-C

CPI-C um protocolo utilizado para a comunicao elementar program-to-program. utilizada

basicamente para a comunicao entre sistemas R/2 e outros aplicativos mainframe. a
implementao SAP da LU6.2. A comunicao faz uso dos verbos bsicos da comunicao LU6.2
(INIT, ALLOCATE, ACCEPT, SEND, RECEIVE e DEALLOCATE). Como no padro IBM, um
protocolo de comunicao que exige que enquanto um parceiro esteja transmitindo o outro se
encontre em modo de escuta, e vice versa (sempre funciona na modalidade sincrona). Lembrar que
se for o caso de estabelecer uma conexo com ambiente IBM ser necessrio usar funes feitas
pela SAP para converter o conjunto de caracter de ascii para ebcdic.

Os parmetros enviados pelo comando INIT so definidos atravs da tabela TXCOM e mantidos

Remote Function Call

RFC uma interface de comunicao baseada em CPI-C mas que possui mais funes alm de
ser mais simples de se utilizar. Pode ser utilizada para a comunicao entre sistemas R/3, R/3 com
R/2 bem como aplicaes externas. O RFC permite a chamada de subrotinas remotamente pela rede.
Estas subrotinas so chamadas de function modules. Estas funes possuem parmetros e retornam
valores como qualquer outra funo e so gerenciadas dentro do R/3 atravs de sua prpria function
library, denominada Function Builder.

Pgina 26
ACADEMIA BASIS

Function Builder (transao SE37) d ao programador uma excelente ferramenta para programar,
documentar e testar as function modules, que tanto podem ser chamadas em modo local quanto
remotamente. O Sistema R/3 gera automaticamente todo o protocolo necessrio para a comunicao
RFC entre os sistemas.

Os requerimentos para o RFC so os mesmos para o CPI-C. Os parmetros para a comunicao

RFC so mantidos travs da transao SM59. O R/3 vem ainda acompanhado de uma biblioteca de
funes C para comunicao externa via RFC com o R/3, o RFC-SDK (Software Development
System), sendo que o que diferencia uma chamada RFC local de uma remota apenas o parmetro
(destination) que especifica onde o comando ser executado

chamadas RFC :
Synchronous RFC call, onde o programa que emitiu a chamada suspende a execuo at o
retorno da chamada
Asynchronous RFC call, onde a funo chamada roda em paralelo e independente do
programa que emitiu o comando. O programador fica responsvel pela conexo lgica dos
resultados obtidos
Transactional RFC call, onde vrias funes so agrupadas em uma nica transao que
executada no sistema remoto como uma nica LUW na seqncia com que elas foram
codificadas. Caso ocorra um erro, o sistema que emitiu o comando recebe um cdigo de
retorno que pode ser consultado pela transao SM58. Ainda neste caso o sistema destino
no precisa estar disponvel no momento em que o comando emitido, podendo ainda ser
parametrizado o intervalo entre os queries.

Business Objects and BAPIs

Os business objects formam a base para a comunicao em alto nvel no sistema R/3, tornando
possvel por exemplo implementaes R/3 na internet e tem as seguintes caractersticas:
Formam a base para uma bem sucedida comunicao em sistemas client/servers
So orientados ao negcio. Existem BAPIs chamados Customer, Order, etc.
Possui mtodos, que so os business functions que facilitam e padronizam a utilizao destes
objetos
So gerenciados internamente pelo R/3 em uma biblioteca central, a Business Object
Repository, ou BOR

As BAPIs (Business Application Programming Interfaces) so interfaces funcionais que utilizam

business methods para executar funes de negcio. Elas podem ser chamadas tanto pelos
programas R/3 quanto encapsuladas e instnciadas por programas externos.

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

OLE (Object Linking and Embedding) uma forma de comunicao entre programas orientada
para objeto. Com isto possvel conectar aplicaes desktop que utilizam OLE2 (Word, Excell, etc.)
com o sistema R/3. Quando o sistema R/3 est agindo como um client OLE, o usurio chama o
programa (word, excell) de dentro do programa ABAP. Os comandos OLE so transferidos para o PC

Os objetos OLE aos quais o R/3 pode se conectar como client so definidos internamente no R/3
(atravs de type informations) onde se definem os mtodos, atributos e parmetros do objeto. A
(CREATE OBJECT, CALL METHOD, GET/SET
PROPERTY e FREE OBJECT) que permitem instnciar e manipular o objeto. Quando o R/3 funciona
como um OLE server, suas funes podem ser chamadas de dentro das aplicaes que rodam no
desktop. Estas chamadas so enviadas ao SAP Automation Server que converte os calls para RFCs
que so enviados ao sistema R/3. Estas chamadas ativam BAPIs ou function modules dentro do
sistema R/3 que processam as informaes que so ento enviadas de volta para o Automation
Server que a repassa para o aplicativo no desktop.

Do ponto de vista da programao, usurios podem utilizar as function modules do R/3 em uma
programao orientada para objeto, como por exemplo utilizando C++ ou Visual Basic. Isto vlido

Pgina 27
ACADEMIA BASIS

para todos os objetos que so gerenciados centralizadamente pelo R/3 atravs da BOR (Business
Object Repository). Como os BOR e function modules se encontram no R/3, para utiliza-los
necessrio antes efetuar um logon, que pode ser feito de forma automatizada pelo programa.

Internet Architecture

ITS (Internet Transaction Server) forma o componente principal da arquitetura Internet da SAP. Ele
composto de dois componentes, o Application Gate (A Gate) e o Web Gate (W Gate). Do ponto de
vista do R/3, o A Gate age como um usurio comum, uma vez que o IST converte toda a conversa
com o sistema para protocolos utilizados pelo SAPGUI. O A Gate mescla os dados recebidos com
templates HTML e os envia atravs do W Gate para o HTTP server, onde so finalmente exibidos
para o usurio atravs dos browsers padro (explorer ou netscape).

A SAP fornece o IAC (Internet Application Component) que possui Web Transactions que nada
mais so que mapeamentos Web de transaes standard R/3. Assim como qualquer pgina HTML, o
usurio pode customizar o lay out de acordo com suas necessidades. Para permitir uma boa
performance a SAP est rescrevendo algumas transaes para que essas funcionem de forma
integrada com a internet.

EDI Architecture

Electronic Data Interchange uma forma estruturada e eletrnica para trocar informaes entre
diversos sistemas. Esta arquitetura tem as seguintes caractersticas:
EDI-enabled applications, que permite que transaes de negcio sejam processadas
automaticamente
A interface IDOC, que foi criada como uma interface aberta e consiste de documentos
intermedirios e seus respectivos function modules
subsystem EDI, que converte os documentos intermedirios em mensagens EDI e vice versa.
O SAP no implementa esta facilidade

O componente principal desta interface o Idoc, que um SAP standard que especifica a
estrutura e o formato do dado que est sendo transferido.

Distribution of Business Processes with ALE

Por razes tcnicas ou de negcio pode ser necessrio fazer uma implementao descentralizada
do R/3. O conceito ALE (Application Link Enabling) permite configurar e operar aplicaes distribudas
em SAP.

ALE consiste de uma troca controlada de mensagens de negcio, mais especificamente os dados
do negcio, que permitem a integrao consistente de sistemas distribudos. Os aplicativos so
integrados atravs de comunicaes tanto sncronas quanto assncronas e por TRFC (transactional
RFC). Para especificar um sistema distribudo necessrio especificar o modelo lgico de
distribuio de dados para definir em que sistema rodar e ainda entre quais e como os dados
devero ser intercambiados. Os dados tambm so transferidos atravs de Idocs (Intermediate
Documents) para possveis aplicaes de EDI.

Data Transfer and Batch Input

Quando se transfere dados entre sistemas R/3 ou entre o legado e o R/3, importante garantir
que estes dados entrem de forma consistente dentro do sistema destino. Desde que se utilize as
mesmas transaes conversacionais utilizadas pelos usurios para entrar com os dados no sistema,
fica assegurado que os dados passaro pelas mesmas consistncias que se efetuam nas entradas

O mtodo comumente utilizado para entrada de dados do legado conhecido como batch input. A
SAP prov uma srie de mtodos implementados atravs de tcnicas de batch input para a

Pgina 28
ACADEMIA BASIS

transferncia de dados do legado. Estes mtodos standard so controlados atravs do Data Transfer
Workbench (transao SXDA). Caso no existam SAP standard disponvel, possvel definir e criar
seus prprios mtodos. O mtodo consiste na bufferizao das operaes em uma BDC table (Batch
Data Communication) que fica organizada em uma fila (batch input session). No passo seguinte esta
fila processada e os dados so transferidos para a base de dados. O mtodo funciona como uma
screencam mergeado com um pacote de dados onde cada registro submetido ao screencam
simulando um usurio processando a transao.

Um outro mtodo para entrada de dados o CALL TRANSACTION que fora a chamada de uma
transao para processar os dados armazenados na BDC table. Tanto o batch input quanto o mtodo
de call transaction chamam os mesmos programas que so processados em dialog mode pelos
usurios, o que garante desta forma que as mesmas consistencias sejam efetuadas sobre a massa
de dados.

Outra forma de atualizao o Direct Input, onde os dados so lidos diretamente do arquivo de
entrada, consistidos e transferidos para a base de dados sem passar pelas funes de aplicao
normais. Dado a natureza atpica desta operao, ela efetuada apenas por algumas poucas
funes R/3 e reservadas apenas para programas desenvolvidos pela prpria SAP.

Devemos sempre ter em mente que a principal diferena entre o batch input e o call transaction
a existencia de um arquivo intermedirio (conhecido como sesso) que viabiliza o reprecessamento.
J no call transaction, quem deve possuir ou permitir este tipo de controle ou recurso o proprio
programa abap que esta preparando os dados para serem inseridos no sistema.

No vem ao caso para a academia, mas uma outra boa forma de fazer a integrao de dados do
legado para o R/3 a LSMW ou DLSM que agiliza na gerao das pastas de BDC e na eliminao da

Pgina 29
ACADEMIA BASIS

R/3 Graphical User Interface

Frontend Administration

Usurios no necessitam da mesma configurao em seus PCs, embora uma

workstation simplifica o trabalho de administrao. Considere a facilidade e a dificuldade para
atualizar os softwares da estao

Frontend Requirements: A nota 86895 descreve detalhadamente a configurao da estao

Item Configurao Mnima Configurao desejvel

Processador 486 Pentium 133
RAM 16MB 32MB
Net connection Winsocket API Winsock.dll

Configurao para Windows NT

Item Configurao Mnima Configurao desejvel
Processador Pentium 90 Pentium 133
RAM 32MB 48MB
Net connection TCP/IP TCP/IP

Para testar o funcionamento da rede entre a estao e o host basta efetuar um ping ou telnet. As
configuraes no windows ficam nos arquivos host e services.

Para testar o funcionamento do SAPGUI utilize o comando sapgui <appserver> <nn> ou sapgui
/H/appserver/S/32nn

SAPGUI Installation

Sempre que for instalar uma nova verso do SAPGUI necessrio deletar a verso anterior. O
programa sappurge.exe pode ser utilizado para esta finalidade. A instalao feita individualmente
em cada PC. Programe a melhor forma para otimizar o trabalho. O arquivo SAPSETUP.INI pode ser
editado para parametrizar a instalao. Nele se configura quais os componentes a serem instalados e

O sapsetup.exe permite uma instalao dialog free startada a partir da linha de comando (veja o
R/3 Installation Guide) o que assegura uma distribuio automtica do software e a manuteno do
frontend utilizando logon scripts. A vantagem neste tipo de instalao que a configurao das
estaes feita a partir de uma localizao central atravs de um logon script, que faz todas as
checagens necessrias (hardware e network) e executa as operaes necessrias para instalar e
manter o frontend. A desvantagem deste mtodo que se tem mais trabalho para implementar o
check de verso no logon script e para analisar os resultados da instalao no arquivo sapsetup.log.
A SAP recomenda que sob windows 95 e NT primeiro se faa uma instalao em um servidor
(installation server) utilizando o installation wizard e posteriormente se instale os clients a partir dele.
O programa utilizado na instalao o \Gui\Windows\Win32\Sapsetup.exe

Types of Online Help

Existem diversos tipos de implementao do online help no R/3:

PlainHtmlHelp converte documentos para HTML standard. Pode ser instalado em todas as
plataformas de frontends e exibida atravs dos browsers convencionais. Pode ser utilizado
tanto com Windows 95, NT ou ainda quando um Web server disponvel na instalao
(intranet)
PlainHtmlFile converte documentos para HTML standard. Pode ser instalado em todas as
plataformas de frontends e os documentos so acessados atravs de um file server que

Pgina 30
ACADEMIA BASIS

disponibiliza os dados de um diretrio por compartilhamento onde so exibidos atravs dos

browsers convencionais nas estaes. Pode ser utilizado tanto com Windows 95, NT ou ainda
quando um Web server disponvel na instalao (intranet)
HtmlHelpFile converte documentos armazenados no formato HTML comprimido para Html
convencional. Pode ser utilizado apenas em estaes Windows 95 ou NT. instalado em um
file server compartilhado, como o anterior, mas sua principal vantagem que o espao
necessrio no file server cerca de 90% menor, j que os arquivos se encontram
compactados. O nico pr requisito que o browser j esteja instalado na estao antes da
instalao do SAPGUI, j que o browser que contm todos os HTML controls necessrios.

O tipo de help e sua localizao so especificados como parmetros nas profiles do R/3. A
configurao do arquivo SAPDOCCD.INI no frontend sobrepe a definio genrica das profiles do
R/3 e deve ser utilizada como complementao a definio do sistema central.

Os parmetros importantes e relevantes para a configurao do help so o eu/iwb/help_type, o

eu/iwb/installed_language e o eu/iwb/path_win32.

SAPLOGON Options e traces

O programa saplogon.exe se encontra no diretrio drive:\<target>\sapgui, conforme foi definido no

momento da instalao. O saplogon utiliza o programa sapgui.exe para se conectar com o application
server. O arquivo saplogon.ini configura as entradas disponveis na janela do saplogon e mantido
quando se atualiza as entradas disponveis do usurio. As informaes l contidas so utilizadas para
montar o string de conexo ao application server. Para evitar que o usurio edite as entradas deste

Ao se clicar no canto esquerdo da janela do saplogon possvel obter informaes about que
descrevem a localizao dos dois arquivos (sapgui.exe e saplogon.ini). O boto do canto superior
esquerdo da janela permite ainda que se configure as opes de trace do saplogon e as
funcionalidades de edio. Estas definies ficam armazenadas na seo [Configuration] do
saplogon.ini

Assim como o saplogon.ini, os arquivos sapmsg.ini e saproute.ini so mantidos implicitamente

quando edita as entradas do saplogon. O primeiro contm a relao dos message servers e seus
respectivos servios (logical service names) que ser lido sempre que se efetua uma requisio de
logon a um logon group atravs do saplogon. O segundo arquivo (saproute.msg) lista os saprouters
que podem ser selecionados no saplogon.

J o arquivo services do windows no editado pelo saplogon embora possua entradas

fundamentais para o seu funcionamento, devendo portanto ser editado em separado. Nele so
especificadas entradas para os message servers definidos no sapmsg.ini, como por exemplo:
sapms<SID> 36nn/tcp.

O saplogon utiliza o programa sapgui.exe para se conectar com o sistema R/3 e o string de
conexo depende do target escolhido:
Para conexo com uma instncia R/3: sapgui /H/<appserver>/S/32nn
Para conexo com um message server: sapgui /M/<host name>/S/36nn/G/<logon group>
Para conexo saprouter: sapgui /H/<host1>/S/3299/H/<host2>/S/3299/H/<oss
host>/S/36nn/G/Public

Os nmeros dos servios podero ser substitudos pelas respectivas entradas colocadas no
services: sapdp<nn> para o dispatcher e sapms<SID> para o message server. S para constar, as
portas do gateway (sapgw00) so as 3300.

Se for necessrio, o log de start do sapgui pode ser ativado. Ele recebera o nome dev_9999.TDW
(ascii) e dev_9999.log (binrio) e sero gravados na area de work do sapgui. Eles possuem a log de
tudo que aconteceu.

Resumindo os arquivos ini. O saplogin.ini possui a configurao das instncias e seus respectivos
system numbers. No sapmsg.ini teremos a indicao de quais so os messages de cada um dos
sistema R/3. No saproute.ini teremos as strings de roteamento do R/3 e no arquivo services teremos

Pgina 31
ACADEMIA BASIS

as portas que sero utilizadas pelo dispatcher, gateway, message e etc. Devemos sempre tomar
cuidado ao alterar o service pois ele no segue um padro entre maquinas diferentes e
principalmente com usos diferentes. Em relao a localizao dos arquivos, os sap*.ini esto no
diretrio do windows e o service ou est no diretrio do win9x ou no system32/drivers/etc do winnt.

SAP MAPI and SAPGUI for java

O SAP MAPI permite a integrao dos softwares de correio eletronico e o R/3. Especificamente o
MAPI permite que o ambiente de troca de mensagens do R/3, conhecido como Office, passe a ser
acessado como se fosse uma pasta do Outlook ou do exchange da microsoft.

Uma outra evoluo da SAP a disponibilizaro do sapgui na linguagem java. Isto, pelo menos a
princpio, facilitaria a distribuio de softwares para as estaes mas ainda possui o inconveniente do
ambiente ser mais complexo. Outra desvantagem a tecnologia estar no inicio do vida e portanto
ainda sem contar com uma boa performance e estabilidade de ambiente. O arquivo que
corresponderia ao saplogon.ini neste ambiente o IDES.html.

Durante a ativao de um sapgui java devemos lembrar que at o aparecimento da janela para o

identificao do template (ides.html) que identifica o servidor a ser acessado;

carga das classes java que sero processadas no lado do cliente;
troca de mensagens entre os servidores para a montagem da pgina atravs do orbixd (object
requeste broker daemon).

Se for necessrio saber mais sobre o assunto, procure pela nota 42268 ()

Pgina 32
ACADEMIA BASIS

SAP Online Service System (OSS)

OSS Overview

OSS um servio 24 x 7 disponibilizado pela SAP que permite acesso ao banco de dados de
Notas, que provm solues para problemas no sistema R/3. Atravs do OSS os clientes abrem
chamados ao suporte relatando problemas que so analisados pela equipe da SAP. Atualmente a
SAP est migrando estes servios para a internet. Isto faz parte da nova estratgia mysap.com.
Aparentemente todo o OSS ser disponibilizado no site http:/service.sap.com que faz parte do market
place.

OSS Functionality

A tela de pesquisa permite entrar com palavras chave relacionadas ao problema e incluir filtros na
pesquisa, tais como release, database, verso de Hot Package, etc. Ao abrir chamados, o OSS j
configurado com dados gerais da sua instalao requisita informaes sobre rea do problema,
transao, descrio do problema e severidade.

O SSCR uma funcionalidade do OSS que permite ao cliente obter key para desenvolvedores e
para os objetos SAP que iro sofrer modifications. O SSCR exibe uma lista de todos os objetos e
desenvolvedores registrados para o cliente na SAP. O OSS permite listar os Hot Packages e Legal
change patches disponveis bem como as datas dos treinamentos oferecidos pela SAP.

OSS Access

O acesso ao OSS efetuado atravs da transao OSS1, que abre uma nova conexo SAPGUI
no frontend do usurio. O acesso ao OSS preciso ser configurado atravs de um SAPRouter
gateway que abre uma conexo segura entre a instalao do cliente e a rede mundial da SAP atravs
dos roteadores que ligam as duas redes. O saprouter tambm controla e filtra quem pode e quem no
pode acessar a partir de cada um dos lados envolvidos na conexo.

SAPNet

A SAPNet uma ferramenta que prov informaes e servios via internet. O acesso a SAPNet
feito atravs da rea CUSTOMER PARTNER da pgina pblica da SAP (WWW.SAP-AG.DE). Dentro
da SAPNet existem reas de Assistncia, Informao, Comunicao e Servios. Cada dia mais esta
ferramenta est se aproximando do OSS e hoje em dia j dispomos da maioria dos recursos via
browser. Alm disto dispomos de mecanismos para perquisar em todo o site da SAP incluindo ai
muitos documentos no disponveis no OSS. Outro bom recursos j disponvel o download de hot
packages e legal changes patches alm dos patches de kernel (executveis do R/3).

No sapnet encontramos um bom recurso para um sizing inicial. A ferramenta se chama quick
sizing e a partir de alguns dados funcionais e indicao da preferencia do ambiente operacional a
ferramenta consegue um bom resultado no dimensionamento do ambiente de hardware.

SAP TechNet

A SAP TechNet uma ferramenta focada mais para o lado tcnico, acessada atravs de endereo
www.sap.com/technet ou atravs da rea de communication da SAPNet. Os assuntos na SAP
TechNet esto divididos por reas de interesse e podem ser navegados para encontrar uma grande
diversidade de documentos e pdfs. Para facilitar a organizao a maior parte dos documentos esto
na knowledge base e ainda existe uma rea conhecida como forum com um conjunto de perguntas
feitas por outros clientes.

Pgina 33
ACADEMIA BASIS

Starting and Stoping R/3 NT Version

Operating System Tasks

Durante o startup do NT todos os servios relacionados podero ser inicializados automaticamente

(desde que configurados atravs do control panel -> services). Em relao ao R/3 neste momento
SAP<SID>_<SystemNumber>, SAPOSCOL e
OracleService<SID> devem ser inicializado. A seqncia de inicializao no relevante pois um
no depende do outro, mas para o start do R/3 todos j devem estar ativos.

O SAP<SID>_<SystemNumber> o responsvel por coordenar o start/stop do message e do

gateway. O usurio utilizado para inicializar o servio o SAPService<SID> com a senha informada

O SAPOSCOL o responsvel por coletar as informaes sobre os recursos do sistema

operacional e suas respectivas cargas e disponibilizar estas informaes para o R/3. O usurio
utilizado para inicializao tambm o SAPService<SID>.

O OracleService<SID> responsvel pelo controle da instncia oracle e no necessita de usurio

para ser inicializado.

Administrator Tasks

Para inicializar o R/3 devemos sempre seguir a seguinte seqncia :

Os servios bsicos devem estar ativos (saposcol, sapSID_## e OracleServiceSAP)
Abrir a conta SIDadm na console do NT
Ativar a instncia do Oracle (pode ser feito pelo instance manager da oracle)
Ativar a instncia do R/3 (pode ser feito atravs do sap service manager)

O Sap Service Manager usa as cores para indicar a fase em que est cada servio, a saber :
verde (processo sendo executado), vermelho (processo terminado anormalmente), amarelo (processo
sendo inicializado) e branco (servio no est ativo ou com situao desconhecida)

Process Startup Sequence

Seqncia bsica do start do SAP Service Manager :

Na camada de servios
Verifica se os servios bsicos esto no ar (SAP<SID>_<SystemNumber> e
OracleService<SID>)
Aciona o SAP<SID>_<##>, que a Start Profile do sistema R/3 do qual o SIDadm o
administrador e executa-a.
Verifica e se necessrio executa o script strdbs.cmd de inicializao do banco de dados
Verifica e se necessrio executa o script msg_server.exe que coloca no ar o message
Verifica e se necessrio executa o script disp+work que coloca no ar o dispatcher
Na camada de processos
Com as informaes da default profile e a instance profile o dispatcher (disp+work)
inicializa o R/3 criando os work process necessrios e o servio de gateway

As profiles esto no compartilhamento \\<sapGlobalHost>\sapmnt\<SID>\SYS\profile conhecido

tambm como \usr\sap\SID\SYS\profile (se ignorarmos o disco onde est a instalao). Para o acesso
remoto o compartilhamento a ser utilizado ser o sapmnt, para o acesso local o compartilhamento a
ser utilizado o saploc.

Se for necessrio iniciar a instncia atravs da linha de comando utilize o comando startsap que
tambm possui seu inverso, o stopsap.

Pgina 34
ACADEMIA BASIS

Parameter Read Sequence

A seqncia para a leitura dos parmetros a seguinte :

NT register
Ambiente do NT
Declaradas no start profile
Default profile
Instance profile
O valor que ser utilizado ser o que aparecer por ultimo nesta lista. Para certificar qual o valor
assumido para um determinado parmetro utilize o relatrio RSPFPAR.

Resumindo, o SAP service l as variveis de ambiente, a start profile e a default profile; o R/3
kernel (conhecido com dispatcher) l a default e a instance profile. Se algum parmetro for alterado,
para ele passar a valer, tudo que for afetado deve ser reinicializado.

Logs and Traces

Logs and Traces for Database Startup

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

Startup logs and traces in Windows NT

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

Startup logs and traces in R/3

O diretrio de work contm todos os arquivos de trace e de mensagens de erros da instncia R/3..

Arquivos de erros gravados pelo executvel sapntstartb.exe que acionado pelo SAP service
manager ou pelo startsap :
Stderr1 contm as logs do banco de dados
Stderr2 contm as logs do message server
Stderr3 contm as logs do dispatcher
Sapstart.trc contm o trace do programa sapntstartb. Vale lembrar que o nvel do trace a
ser logado pode ser alterado pelo parmetro rdisp/trace e este varia de 0 (no trace) at 3
(todas as mensagens e trace completo)
Arquivos de trace :
Sapstart.log contm, de forma um pouco menos detalhada, a toda a log da inicializao
Dev_ms contm o trace do message server
Dev_disp contm o trace do dispatcher
Dev_w0 n contm o trace de um work process especifico

Uma boa transao para ver as logs a transao RZ03 e menu utility. Outra boa transao para
ver mensagens de log a SM21, mas esta mostra as mensagens de log de R/3.

Startup Diagnostics

As principais razes de falha durante o processo de inicializao so :

SAP Service Manager no consegue conectar com o SAP service. Normalmente ou ele no
est ativo ou no esta configurado corretamente.

Pgina 35
ACADEMIA BASIS

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

Reasons for R/3 Downtime

Eventualmente podemos parar o sistema para alterar a configurao e parametrizao, para
manuteno de hardware ou sistema operacional ou para fazer algum tipo de upgrade.

Before stopping the R/3 system

Sempre que o sistema tiver que ser paralisado, certifique-se que :

Nenhum job est sendo executado ou perto de ser executado. Para isso use a SM37 para
verificar o schedule do R/3. Verifique se outros sistemas no podem estar prximos de
disparar jobs no R/3, via sapevt ou rfc
Nenhuma atualizao est em andamento. Para isso use a SM13;
Nenhum usurio est trabalhando no sistema. Para isso use a SM04;
No existe atividade para o gateway. Para isso use a SMGW.

bastante conveniente enviar mensagem para os usurios do que ser feito. Para isso use a
SM02.

Stopping the R/3 system

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

Para o banco de dados podemos utilizar o sapdba ou alguma ferramenta do oracle, como Oracle
Instance Manager ou o Oracle Server Manager

Database Error Stopping

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

Backup off-line: database reconnect

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

Pgina 36
ACADEMIA BASIS

Starting and Stoping R/3 Unix Version

Operating System Tasks

O usurio <sid>adm utilizado para administrao do sistema R/3. O start do R/3 efetuado
startsap_<host>_<instance nbr>, que fica no diretrio home do usurio. Este
script tem um alias: startsap. O startsap verifica se o processo saposcol est rodando e o ativa, se
necessrio. O scipt pode ainda chamar o script startdb caso o banco se encontre em shut down. Em
seguida o script starta a instncia R/3. O script aceita 3 tipos de parmetros:
startsap R3, ativa apenas a instncia R/3, desde que o banco esteja rodando
startsap DB, ativa apenas o banco de dados
startsap all, ativa o banco e a instncia ( o default quando nenhum parmetro especificado

Um sistema R/3 possui basicamente 3 profiles que se encontram no diretrio

/usr/sap/<SID>/SYS/profile:
Start profile: START_<instance>_<host>, que contm a relao dos componentes que
sero ativados pelo sapstart na instncia
Default profile: DEFAULT.PFL, que contm alguns parmetros globais do sistema
Instance profile: <SID>_<instance>_<host>, que contm parmetros especficos da

Ao ativar o script startsap_<host>_<nn>, o seguinte processo executado para levantar uma

Ativa o programa sapstart

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

Durante o processo de start, o sapstart grava no diretrio de work um arquivo kill.sap que contm
o comando kill 2 <sapstart process nbr>, que ser executado pelo script de stop da instncia. Para
garantir um start consistente, a seqncia dos parmetros lidos pelos work processes seguem um
padro definido, conhecido como parameter replace sequence:
So lidos os parmetros hard coded nos fontes C do kernel
Parmetros contidos na default profile sobrescrevem valores ja lidos no step anterior
Parmetros da instance profile sobrescrevem os anteriores
kernel do R/3 (disp+work) l os parmetros contidos nas default e instance profiles. Desta
forma, alteraes nelas executadas somente tero validade no prximo start.

Database Startup and Logs

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

R/3 Startup and Logs

O script startsap grava uma log de start no diretrio home do usurio <sid>adm. O diretrio de
work contm trace files e error files de mensagens relacionadas com o start dos work processes e

Pgina 37
ACADEMIA BASIS

demais servios. O nvel de informaes gravadas nos trace files definido pelo parmetro
rdisp/TRACE da instance profile. O default 1 (errors e warnings), aceitando valores 0, 1, 2 e 3. O
correto acompanhamento das logs permite identificar o ponto onde ocorreu um erro no processo de
start de uma instncia R/3

Stopping R/3 Systems

As razes para se parar uma instncia R/3 vo desde paradas planejadas (mudana na profile,
manuteno do sistema R/3 ou DB, upgrades) at quedas no planejadas, por exemplo por falha de
hardware. Antes de parar um sistema R/3 convm verificar os seguintes pontos no sistema. Havendo

Verifique jobs background e batch input (SM37)

Estado da fila de update (SM13)
Informe os usurios (SM02)
Verifique os usurios logados (SM04, AL08)
Verifique interfaces externas

A parada do sistema dever ocorrer primeiro nos dialog instances e posteriormente na central
instance e database. O comando utilizado o stopsap (alias do script stopsap_<host>_<nbr>) que
possui basicamente os mesmos parmetros e funcionalidades do startsap (R3, DB, all). A parada
apenas do database (stopsap db ou sapdba) faz com que os work processes do R/3 interrompam a
conexo com o Oracle. Estes processos tentaro uma reconexo (parametrizada por profile) e em
caso de insucesso, entraro em modo de reconnect e somente tentaro nova conexo sob demanda.

O processo de retirar apenas o database poder ser uma opo para efetuar o backup offline do
banco de dados preservando porm os buffers da instncia R/3 intactos durante o processo. Erros
durante a tentativa de parada do database podero ocorrer erros caso o Oracle esteja efetuando um
rollback, executando um online backup ou ainda por se encontrar travado devido a falta de rea para
o archive. Caso a causa no possa ser identificada facilmente, utilize a SM21 para tentar identificar
possveis mensagens. De qualquer forma, elimine a causa antes de fazer novas tentativas de
shutdown.

Pgina 38
ACADEMIA BASIS

CCMS Configuration

Overview

O Computing Center Management System, conhecido como CCMS e acionado pela transao
SRZL, a ferramenta que prove o gerenciamento de :
Performance, monitorao e anlise do R/3, sistema operacional e rede
Profiles, modos de operao e logon groups
Start/stop dos ambientes
Banco de dados e do archiving do banco de dados;
Carga de trabalho (workload)
Impresses
Segurana de acesso

Antes de utiliz-lo, em toda sua potencialidade, ele deve ser configurado. Para isto os principais

Importar as profiles e adequ-las ao ambiente disponvel para processamento

Definir os modos de operao do sistema. Normalmente definimos dois (diurno e noturno)
para balancear e distribuir a carga segundo o perfil de utilizao de cada horrio
Criar as definies dos perfis das instncias com os seus respectivos parmetros de

Associar cada um destes perfis aos modos de operaes

Definir a tabela de horrios de entrada e sada de cada um destes perfis definidos no modo de

RZ10: Profile Maintenance

Esta a ferramenta para manuteno das diversas profiles do R/3 (start, default e instance). Com
ela podemos editar e manter todos os parmetros. A manuteno pode ser feita de forma bsica ou
estendida, o que difere se os parmetros sero manipulados de forma individual ou de forma
coletiva. A transao ainda permite deletar, comparar e verificar as profiles e suas diferentes verses.

Lembrando, as profiles seguem o seguinte padro de nome :

Start : START_DVEBMGS00_hostname
Default : DEFAULT.PFL
Instance : SID_DVEBMGS00_hostname

Os passos para a manuteno inicial das profiles so : Importa-las a partir do sistema operacional;
Mante-las utilizando a RZ10; salva-las e ativa-las. Tomar cuidado com o boto import pois ele importa
apenas o servidor corrente. Para importar use o menu Utilities, Import profiles, of active servers.

R/3 Profiles

A incorreta configurao do CCMS no impede o funcionamento do R/3, porm impede que o

CCMS exiba dados teis. A transao RZ10 do CCMS permite que se d manuteno nas profiles
das instncias do R/3. Ela mantm os parmetros na base de dados do R/3 e a cada alterao
efetuada uma nova verso gerada nesta base de dados. Quando ativamos uma verso de profile
atravs desta interface, seus parmetros so copiados e transferidos para a profile ativa, que fica em
diretrio prprio do sistema operacional. Desta forma a base de dados do R/3 pode conter vrias
verses de uma mesma profile, um histrico das alteraes alm de documentao dos parmetros.

Em ambientes distribudos com vrias instncias R/3, o diretrio de profiles compartilhado entre
todas as instncias e permanece como repositrio central de todas as profiles. Para cada sistema
R/3 existem vrias profiles. Uma DEFAULT profile e, para cada instncia do ambiente, uma instance
e uma start profile. Atravs da ferramenta RZ10, existem dois modos de exibio/edio das profiles:

Pgina 39
ACADEMIA BASIS

Em basic mode, os parmetros que so alterados mais freqentemente so agrupados de

acordo com suas interdependncias de modo que a alterao em um deles se reflita
automaticamente nos demais. Nesta interface basic os parmetros aparecem sem os seus
nomes tcnicos, mas apenas como campos em screen.
Em extended mode, os parmetros aparecem e so editados em uma interface tipo editor de
texto, onde cada parmetro listado com o seu nome tcnico e respectivo valor. O
administrador aqui dever conhecer os seus nomes tcnicos e claro suas interdependncias.

O programa de instalao, R3SETUP, cria a primeira verso das profiles no sistema operacional
de acordo com os recursos do sistema (memria e CPU). Durante o processo de configurao inicial
do CCMS, importamos estas profiles para a base de dados R/3 utilizando a RZ10 e efetuamos as
nossas customizaes. Isto permite uma gerncia centralizada de todas as profiles de um ambiente.

As profiles utilizadas pelo R/3 para configurao da instncia durante o startup sempre a profile
ativa, ou seja, aquela que se encontra copiada no sistema operacional. A partir do momento que
importamos as profiles pela RZ10, todas as manutenes sempre devero se dar atravs desta
interface nunca diretamente no sistema operacional para evitar que haja dessincronizao das
ferramentas. Qualquer dvida quanto ao sincronismo poder ser verificado atravs de seus
mecanismos de check e da comparao de verses.

Do ponto de vista do R/3, uma profile consiste de duas partes lgicas: entradas nas tabelas da
base de dados do R/3 e um arquivo no sistema operacional. Como a verso utilizada pelo startup a
do OS (profile ativa), alteraes efetuadas nos parmetros devero ser salvas no sistema operacional
e somente tero efeito no prximo start da instncia. Somente a verso mais recente de uma profile
pode ser ativada pela ferramenta RZ10. Na prtica isto significa que a tentativa de ativar uma verso
mais antiga faz com que a profile seja copiada com uma nova verso e ativada. Qualquer
manuteno vai sempre gerando novas verses na base de dados que ficam documentadas como
comentrios e headers no file do sistema operacional.

Dynamic Switching na RZ10. O procedimento de

check de profiles oferece vrios mecanismos de aferio de suas integridades:
Comparar a profile da base de dados com a profile ativa no sistema operacional
Verificar a sintaxe dos parmetros codificados
Verificar se os valores especificados nos parmetros so vlidos ou ainda se no esto muito
discrepantes (por exemplo 10 vezes maior que o default, etc.)
Efetuar comparaes entre todas as profiles definidas para encontrar inconsistncias de
definio. Com isto possvel encontrar erros na definio de mais de um message server,
por exemplo.
sistema efetua um check automtico de consistncia entre a profile ativa e a base de dados
sempre que efetua um startup. Caso encontre alguma discrepncia um alert ativado no Alert
Monitor

Operation Modes

Operation mode uma facilidade do R/3 que permite que se configure diferentes combinaes nos
tipos de work processes que podem ser ativados ao longo do dia sem a necessidade de stop/start da
instncia. Isto permite que possamos ter por exemplo uma maior disponibilizao de background work
processes durante perodos de maior demanda desta funcionalidade, como perodos noturnos. J os
perodos diurnos so caracterizados por uma demanda muito maior de processamento dialog.

Operation mode permite portanto maximizar a utilizao dos recursos do sistema sem a
necessidade de stop/start das instncias para que as configuraes tomem efeito.

Uma configurao bsica de operation mode especifica os servios ou tipos dos work processes e
os perodos escolhidos para cada intervalo. atravs desta funcionalidade que conseguimos
configurar background work processes para processamento exclusivo de jobs classe A. Operation
mode pode ser configurado baseado em alguns conceitos bsicos:
nmero total de work processes deve permanecer o mesmo entre os operation modes de uma
instncia, j que nenhum novo servio ser startado, apenas os processos tero suas
funcionalidades reconfiguradas.

Pgina 40
ACADEMIA BASIS

Cada instncia dever permanecer com o requisito mnimo de dois dialog processes
Cada sistema dever permanecer com um processo de enqueue e pelo menos um update.

RZ10, atravs de seus mecanismos de check, oferece recursos para efetuar estas
verificaes das profiles e dos operation modes configurados. A mudana de configurao entre
operation modes pode ocorrer manualmente sob demanda do administrador do sistema atravs da
RZ04 ou ento de forma automtica atravs da definio de um schedule de horrios chamado de
timetable, que configura um ciclo completo de 24 horas. Este schedule de horrios mantido atravs
SM63. A timetable nica para todas as instncias de um sistema. Isto significa
que todas devero possuir a mesma configurao de operation modes, porm cada uma poder ter a
sua configurao individual de work processes.

Alm da timetable normal que configura o ciclo de 24 horas do operation mode, possvel definir
uma timetable excepcional para ser ativada em uma data especfica. Enquanto uma timetable normal
deve possuir entradas que cobrem todas as 24 horas do dia, uma timetable excepcional poder
possuir entradas apenas para um determinado perodo do dia. Nos demais perodos continuariam

Quando a mudana entre modos de operao ocorre, os work processes so distribudos

automaticamente, sem necessidade de parada e restart das instncias. Nenhum tempo perdido por
indisponibilidade do sistema, apenas o tipo dos work processes alterado, permanecendo porm o

possvel simular o switch de um operation mode em test mode e desta forma analisar possveis
falhas atravs da log de switch. Discrepncias existentes na configurao das profiles ou na definio
dos operation mode podero ser identificadas e eliminadas.

Starting and Stopping Instances with the CCMS

Atravs do CCMS, transao RZ03, possvel startar e parar as instncias R/3 de um sistema. A
instncia de banco de dados e pelo menos uma instncia do ambiente precisam porm ter sido
startadas atravs das ferramentas do sistema operacional. Em plataformas UNIX utilizada a
facilidade de rexec para esta operao remota. J no NT esta facilidade (rexec) no padro e deve
ser startada se precisarmos que uma instncia NT manipule uma instncia Unix. Alm de permitir a
parada de uma instncia a RZ03 tambm permite o switch de operation mode manualmente.

Pgina 41
ACADEMIA BASIS

Background Processing

Background Concepts and Features

Um job background um ou mais programas ABAB, external programs ou external commands que
rodam seqencialmente (steps) sem a interveno do usurio, baseados em eventos (event-based)
ou horrios (time-based) pr estabelecidos. So utilizados principalmente para:
Processar automaticamente tarefas rotineiras
Processar informaes vindas de sistemas legados
Processar tarefas baseado na ocorrncia de determinados eventos
Processar uma carga em massa no ambiente em horrios de baixa atividade online

Podem ser schedulados para serem disparados baseados em determinados eventos que ocorram
tanto dentro quanto fora do R/3 (event-based jobs). Podem ser arranjados em classes (A, B ou C)
que possuem uma hierarquia de prioridade na execuo. O sistema permite que se reserve work
process livres para execuo exclusiva de jobs classe A. O mecanismo de funcionamento o
seguinte: pelo menos x (configurado pela RZ04) work processes ficam reservados para classe A
independente de quais sero eles.

Os jobs so disparados atravs de um servio, o batch scheduler, que roda no sistema R/3. Este
servio um programa ABAP que roda em um dialog work process no servidor parametrizado nas
profiles do ambiente atravs do parmetro rdisp/bcttime. Neste parmetro especificado o tempo
em segundos com que este programa roda, normalmente 60 segundos. Quando se especifica um
valor igual a 0, o batch scheduler fica inibido naquele server. Um outro parmetro, o rdisp/bctname,
define o nome do server onde os events sero checados para o disparo de jobs atravs desta
facilidade, os event-based jobs. A definio de quantos batch work process estaro disponveis, sem
levar em conta o modo de operao, est no parmetro rdisp/wp_no_btc. Por definio um sistema
R/3 deve ter pelo menos 2 batch work process, independente de qual instncia eles vo estar, para
atender o sistema de transporte. Se o sistema R/3 no for trabalhar com transportes no necessrio
ter batch work process (mas isto meio absurdo se pensarmos no dia-a-dia prtico).

O mecanismo do batch scheduler, aps a ativao, segue o seguintes passos :

Verifica a job-scheduling table ordenado por data de start, classe, servidor de destino e data
da criao do job;
Se o job for para ser executado na prpria instncia o dispatcher acionado para alocar um
BTC, se o job for para ser executado em qualquer instncia o message acionado para
determinar qual o servidor com menor carga.

Operation Modes and Scheduling

O sistema efetua balanceamento de carga automtica entre os servidores, a menos que se

especifique o server target do job. A especificao do server durante o schedule faz com que o job
tenha prioridade sobre outros da mesma classe sem a especificao explcita do server. possvel
configurar operation modes (atravs da transao RZ04) para efetuar um switch entre work
processes de dialog e batch em horrios pr determinados sem a necessidade de um stop/start
do R/3 para reconfigurao dos work processes

A gerncia dos jobs feita a partir do CCMS e os jobs so schedulados a partir da transao
SM36. Ao efetuar o schedule do job possvel especificar o nome de quem ir receber o spool
request (opo Spool list recipient) que tanto pode ser um usurio R/3 quanto um mail do SAPOffice
ou mail externo. Os Programas ABAP que requerem um determinada entrada de dados para
execuo podero ser schedulados em background bastando que se informe uma variant (lista de
parmetros) para processamento. Eventualmente o schedule pode ser acessado pela transao
RZ01 que um visualizador grfico dos jobs que esto schedulados.

Quando um job background executa comandos ou programas externos, o R/3 starta o programa
server SAPXPG no host target atravs de chamadas RFC. Programas externos somente podem ser
executados por usurios com autorizao para background administrator. Comandos externos podem

Pgina 42
ACADEMIA BASIS

ser executados por usurios com autorizaes R/3 apropriadas. Os programas externos somente
rodam em modo sncrono e os comandos externos rodam tanto em modo sncrono quanto
assncrono, dependendo das necessidades do usurio.

Os jobs podem ser schedulados para rodar de diferentes maneiras:

Imediatamente,
Com data e hora programada,
Aps a ocorrncia de um evento
Aps a execuo de um outro job
Em um modo de operao especifica
Com periodicidade, etc

Events in Job Scheduling

Os eventos com que os jobs podero estar dependentes so eventos internos do R/3 (system
start, opmode switch, etc) ou eventos definidos pelo usurio, como por exemplo o trmino de uma
transferncia de dados

Atravs da transao SM62 podemos definir os user events e a transao SM64 utilizada para
disparar os eventos. O programa sapevt (Unix ou NT) utilizado para disparar um determinado
evento a partir de uma linha de comando no sistema operacional. A sintaxe do comando SAPEVT
<event> [-p <parameter>] [-t] [pf=<profile_path>] [name=<SID>] [nr=<instance]. O sapevt se conecta
ao message server da instncia via tcp/ip para disparar o trigger no R/3. Internamente em um
programa ABAP possvel ainda disparar um evento a partir da , a
BP_EVENT_RAISE.

Da mesma forma que o R/3 utiliza o SAPXPG para startar programas no sistema operacional o
SAPEVT tambm utiliza o SAPXPG para startar eventos no R/3. Com isto possvel concatenar os
steps e schedular os jobs de forma a atender praticamente qualquer necessidade de schedule.

Changing or Monitoring background Jobs

Changing background job

Um job que esteja com o status de scheduled ou released pode ser alterado atravs da SM37.
Estas alteraes podero ser desde a incluso de novos steps quanto a alterao de seu scheduling.
Uma alterao tpica a classe de submisso, por exemplo para alterar a fila de prioridades. Jobs
que esto rodando ou que j foram processados no podem ser alterado. Os jobs que esto rodando
podem ser capturados, ou seja, debugados e eventualmente cancelados. Os jobs que j terminaram,

Job Monitoring

Atravs da SM37 se monitora tanto os jobs que j rodaram quanto aqueles que se encontram
schedulados. O job log pode ser pesquisado para verificar as mensagens do sistema para aquela
execuo. A Spool list exibe a sada da execuo. A lista exibida na SM37 depende dos critrios
marcados na tela inicial. necessrio uma especial ateno para a seleo dos jobs que no
possuem uma data de start e para aqueles que dependem de algum evento (colocar * no evento e
clicar nas opes de jobs sem data e com predecessores). Outro ponto a ser observado a diferena
entre um job released e um job ready. O released j pode ser rodado, em funo da marcao do
horrio e das autorizaes, mas no est na hora de ser executado. O ready j pode ser rodado mas
ainda no foi atribudo para o work process que est disponvel (provavelmente o dispatcher est
muito ocupado). De qualquer forma o tempo na situao de ready mnimo.

Pgina 43
ACADEMIA BASIS

Para ver os jobs existe tambm o Job Scheduling Monitor (RZ01) que exibe em modo grfico o
schedule nos vrios servidores que compem o sistema ao longo do tempo. Esta transao tambm
pode ser ativada a partir do Control/Monitoring do CCMS.

Job API, XBP-API and XMI-API

Atravs de programas ABAP possvel gerenciar e schedular jobs utilizando o Job Application
Programming Interface, ou Job API. Atravs do Job API possvel por exemplo rodar jobs
seqencialmente ou ainda incorporar lgica de deciso no ambiente de processamento ( O R/3 no
consegue tratar schedule de jobs muito complexos. Um exemplo disto um job que precisaria de dois
predecessores). As funes ABAP para o Job API se encontram no ABAP workbench com o nome
BP_*. O XMI ou External Monitoring Interface um conjunto de mdulos de funes que agregam
todas as funcionalidades para interface externas de gerenciamento do CCMS

O XBP ou External Interface for Background Processing a interface externa para background-
job-scheduling. Estes mdulos possuem o nome comum SXMI_* e no devem ser confundidos com
os Job APIs. Ferramentas externas de job scheduling (XBP) permitem que se integre em um nico
ambiente o gerenciamento do schedule de jobs R/3 e no R/3 atravs de uma nica interface

Authorization for Background Jobs

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

Authorization for External Commands

Os objetos de autorizao envolvidos so:

S_RZL_ADM que atravs de seus activity codes d autorizao para administrao do CCMS
(01 equivale a all e 03 a display)
S_LOG_COM que possui fields que autorizam a execuo de external commands
S_TCODE que d autorizao para as transaes SM49 e SM69

Authorization for External Management Interfaces

Os objetos de autorizao envolvidos so:

S_XMI_PROD define atravs de seus fields quais interfaces XMI e quais ferramentas externas

S_XMI_LOG define se o usurio pode acessar interfaces XMI e como este acesso ser feito

Dicas sobre jobs

Ao executar um comando do sistema operacional utilize cmd /c dir
Quando o resultado de um comando externo no aparecer verifique os flags (aguardar o
retorno)

Pgina 44
ACADEMIA BASIS

Advanced Background Processing

Types of Background Jobs

Os background jobs em um sistema R/3 podem ser divididos em duas categorias:

Basis background jobs, que efetuam tarefas necessrias dentro do ambiente R/3, seja na
coleta e armazenamento de estatsticas ou na tarefa de housekeeping da instncia, onde so
normalmente schedulados como jobs peridicos
Application background jobs, que so os jobs disparados pelos usurios em suas tarefas
funcionais dentro do sistema.

Os jobs de housekeeping efetuam tarefas tais como limpeza do spool, jobs antigos, sesses de
batch input j processadas, limpeza de estatsticas, etc. Alguns possuem caractersticas de serem
client independentes, outros j precisam ser schedulados em todos os clients do sistema e outros
ainda possuem a caracterstica de que devem ser schedulados atravs de usurios especficos ou
nota 16083 define esta sistemtica e descreve
detalhadamente os jobs de housekeeping, inclusive quanto a periodicidade aconselhada.

Os outros jobs que se enquadram na categoria dos jobs Basis so aqueles utilizados para coleta e
organizao de estatsticas de utilizao do R/3. Nesta categoria, o
SAP_COLLECTOR_FOR_PERFMONITOR (conhecido tambm como PERFORMANCE_MONITOR)
executa de hora em hora o programa RSCOLL00 que, baseado em uma tabela (TCOLL) do sistema,
dispara uma srie de outros programas a cada execuo para efetuar as mais diversas tarefas
relacionadas ao recolhimento e consolidao de estatsticas.

Os jobs que executam na categoria dos aplicativos efetuando tarefas funcionais dos mdulos do
R/3 necessitam de monitorao constante, j que muitas vezes manipulam grandes quantidades de
dados e so elevados consumidores de recursos, podendo portanto interferir com a performance do
sistema online. Os jobs de aplicao devem ter uma programao estudada e ser cuidadosamente
parametrizados pelas variantes para no trabalhar volumes muito elevados de informao. Em um
ambiente R/3 produtivo, deve-se inclusive montar uma planilha de execuo para evitar gargalos de

Para uma maior compreenso veja as notas 24092 (distribuio de jobs em background),
70639 (agendando jobs em background), 16083 (limpeza de jobs do sistema), 12103, 32050 e
127642.

Os principais programas a serem agendados para o basis so :

RSBTCDEL: elimina as logs de job antigos
RSPO0041: elimina os spools antigos
RSBDCREO: elimina as pastas de batch input antigas
RSSNAPDL: elimina os shortdumps antigos
RSBPSTDE: elimina os jobs de estatsticas
RSM13002: elimina updates antigos e pendentes. Este job s deve ser agendado se
alguns dos seguintes parmetros for alterados: rdisp/vb_delete_after_execution,
rdisp/vb_reorg, rdisp/vb_v2_start
RSSTAT15:
RSCOLL00
RSBPCOLL

Parallel Processing Using Asynchronous RFC

interessante que se verifique se programas batch problemticos e que no utilizam a facilidade

de processamento paralelo atravs do uso de RFC assncrono possam ser reanalisados para
incorporar esta facilidade. Uma chamada do tipo Asynchronous RFC permite uma otimizao no
compartilhamento dos work processes por splitar o programa ABAP em vrias partes menores que
so disparadas paralelamente entre os vrios dialog work process disponveis que compem um
determinado grupo RFC, onde os resultados so coletados mais tarde. Esta tcnica foi desenvolvida

Pgina 45
ACADEMIA BASIS

para suprir o problema de que longos background jobs no encontravam janela noturna suficiente ou
ainda quando no se encontra background work process em nmero suficiente para processar os
jobs. Esta sistemtica exige alguns pr requisitos de ordem tcnica e conceitual para que seja
implementada corretamente. preciso garantir que:
comando ABAP que dispara RFC assncrono o CALL FUNCTION STARTING NEW TASK
DESTINATION IN GROUP. Outras tcnicas de processamento RFC assncrono podem levar a
um impacto negativo na performance do sistema
Existam pelo menos trs dialog work processes disponveis alm dos dois que so
necessrios para o processamento dos dialogs
job possa ser dividido em unidades lgicas independentes, uma vez que sero processadas
paralelamente
A dispatcher queue dever estar com menos de 10% ocupada para garantir que o critrio de
balanceamento da carga seja feito corretamente

Este critrio portanto no se adapta a programas que devem ser processados seqencialmente
onde as unidades lgicas dependem do resultado da anterior. Da mesma forma no existe uma
garantia da seqncia com que as partes sero processadas individualmente. Os resultados de todas
as partes separadas devero ser coletadas, sincronizadas e analisadas no final. Para maiores
detalhes veja as notas 66612 e 99284. Para ver quais so os servidores disponveis no RFC group

XMI/XBP Interface

A nota 69352 descreve a forma como external programs devem se comunicar com o R/3 utilizando
a external monitoring interface (XMI) ou o external background processing interface (XBP)
Atravs da transao SE37 pode-se ter acesso aos functions groups que implementam estas
facilidades:
External job management: Function group SXJI cujos function modules possuem o prefixo
SXMI_XBP
External monitoring basics: Function group SXMB cujos function modules possuem o prefixo
SXMI_XMB
Connecting to esternal tools: Function group SXMI cujos function modules possuem o prefixo
SXMI

Existem sistemas de terceiros certificados pela SAP que permitem a administrao e gerncia do
schedule de jobs no R/3 atravs de um ambiente externo ao sistema. Estes sistemas se comunicam
com o R/3 efetuando um logon via RFC e posteriormente atravs dos function modules da interface
XMI.

A principal vantagem neste sistema a possibilidade de gerenciar diversas plataformas, inclusive

diversos sistemas R/3 a partir de uma nica interface centralizada. A desvantagem que se trata de
um produto externo ao R/3 que deve portanto ser homologado e de fornecedor idneo e confivel
para possibilitar possveis upgrades em novos releases do R/3. Do lado do R/3 podemos monitorar a
utilizao da interface XMI atravs da transao RZ15.

Events in Job Scheduling

Os eventos utilizados para disparar jobs no R/3 podem ser:

System events, que so definidos pela SAP e disparados a partir de determinadas aes
definidas no ambiente, tais como um switch de operation mode
User events, que so definidas pelo prprio usurio atravs da transao SM62 para permitir
uma administrao mais personalizada de operao

Os eventos podem possuir argumentos que sero verificados no momento do disparo e neste
caso o job s ser executado se o parmetro for igual ao que foi definido no evento. Este argumento
especificado tanto quando se schedula o job quanto no momento em que se dispara o evento,
permitindo desta forma uma perfeita sincronizao de tarefas. Um bom exemplo para este uso o
evento END_OF_DATA_TRANSFER que deve ser associado a uma parmetro para disparar um job
especifico. Com isto no necessrio especificar vrios eventos para a mesma funcionalidade

Pgina 46
ACADEMIA BASIS

conceitual. Outro exemplo o uso do evento SAP_OPMODE_SWITCH com um parametro NOITE e

que vai significar que o job s deve ser disparado quando o switch for para o perodo noturno. Jobs
schedulados sem argumentos so disparados tanto quando o evento ocorre com argumento quanto
sem argumentos.

Os user events podem ser disparados por trs formas distintas: manualmente atravs da
transao SM64, dentro de um programa ABAP atravs de chamada prpria de funo
(BP_EVENT_RAISE) ou ainda atravs de chamada a um programa externo, o sapevt. Neste ltimo
caso a chamada poderia estar contida em um script ou at mesmo como um step de um job R/3
(external program step)

External Commands and External Programs

External commands podem ser executados tanto pelos administradores do sistema quantos por
usurios que possuam autorizao especfica. A transao SM69 utilizada para criar e dar
manuteno em external comands, que posteriormente podem ser executados atravs da transao
SM49 ou inseridos em steps dos background jobs. Atravs de chamadas de funes especficas
tambm possvel executar external commands de dentro de programas ABAP. Alm destas
transaes podemos utilizar tambm a AL11 para listar os comandos.

External commands somente podem ser executados em modo sncrono e para garantir a correta
execuo dos programas e comandos, especifique sempre o seu path completo. Para rodar um
external program os seguintes requisitos so necessrios:
Gateway server do R/3 dever estar ativo para estabelecer a comunicao entre o servidor host
do processo e o target system, j que o processo startado utilizando o CPI-C. Para ter certeza
que no havera problema utilize o parmetro gw/remsh como /bin/rsh para solaris e rsh para NT.
Se o comando/programa no se encontra no path do CPI-C user, o path completo dever ser
especificado, que quem ser utilizado para executar o comando. Normalmente este usurio o
<SID>adm
diretrio de executveis do R/3 (/usr/sap/SID/SYS/exe/run) dever estar no path do CPI-C user,
uma vez que o comando executado atravs de um programa de controle do R/3 que gerencia o
cdigo de retorno do sistema operacional.

Um external program pode apresentar problemas para ser utilizado, ou por no poder ser startado
ou ainda por no conseguir retornar um resultado para o job background. Estes problemas devero
ser identificados e corrigidos atravs da analise da log de erro do job ou ligando o trace de analise de
external programs

O SAPXPG, ou trace de programas externos, pode ser ligado atravs da execuo do comando
pela SM69 e pela especificao de uma varivel de ambiente, a sapxpg_trace, no sistema target
onde o comando ir rodar. O trace mais detalhado obtido quando esta varivel setada com o valor
3 (levels 1, 2 e 3) que possui o maior nvel de detalhe.

Authorizations for Background

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

ABAP API scheduling

A Application Programming Interface (API) permite que se gerencie e schedule jobs a partir de
programas ABAP ou external programs. Com isto possvel alm da total gerencia sobre o job
(display, copy, delete), exibir a log gerada ou ainda disparar eventos. A API oferece duas funes de
uso simplificado que, apesar de no oferecerem muitos recursos, so extremamente simples de se

Pgina 47
ACADEMIA BASIS

usar: A BP_JOBVARIANT_SCHEDULE que schedula um report ABAP passando apenas a sua

variante para execuo e o BP_JOBVARIANT_OVERVIEW para gerencia simplificada de jobs Para a
programao normal, utiliza-se as funes JOB_OPEN, JOB_SUBMIT e JOB_END. Atravs destas
facilidades possvel dar ao usurio a capacidade de schedular e gerenciar jobs sem contudo ter
acesso a transao SM36 e SM37. Com isto possvel implementar uma maior segurana e
implementar uma padronizao no nome dos jobs no ambiente atravs de uma interface bem mais

Background Check and Troubleshooting

Alm da SM37, existem outras transaes no sistema que permitem ao usurio analisar a sua
pasta particular de jobs. A transao SMX oferece uma forma simplificada para o usurio analisar
seus prprios jobs atravs de listas mais compactas e campos sumariados. J a SM39 exibe uma
analise bem mais detalhada, inclusive com informaes estatsticas. Caso um usurio no esteja
conseguindo administrar seus jobs, a causa mais provvel ser autorizaes incorretas pois
eventualmente o job pode ficar release mas por falta de autorizao ele no inicializa. Caso os jobs
no estejam rodando, alm de verificar a existncia de work process disponveis (SM50), verifique se
os batch schedulers (time-based e event-based) esto rodando corretamente atravs da transaes
SM61 e SM65. Lembre-se da configurao dos parmetros de profile vistos anteriormente.

Pgina 48
ACADEMIA BASIS

Data Archiving

Definition

Archiving uma sistemtica que permite transferir dados das bases de dados R/3 para arquivos,
do tipo texto estruturado, armazenados fora do ambiente R/3, seja meio magntico ou tico, em
formato compactado. implementado no R/3 atravs da transao SARA. Vrias razes podem
justificar um projeto de archive:
Falta de espao fsico no database
Problemas com backup e recovery devido ao tamanho do banco
Performance baixa devido a tabelas muito extensas
Banco de dados possui grandes volumes de dados que raramente so utilizados
Devido a razes legais ou motivado pelo negcio da empresa, uma srie de informaes
precisam ser mantidas disponveis para consulta ao longo do tempo

A freqncia e a necessidade de efetuar archiving varia portanto de empresa para empresa,

baseado nos seus recursos de hardware disponveis e no seu objeto de negcio. Em relao ao
negcio s faz sentido fazer archive de informaes que realmente podem ir para o arquivo morto.

How Archive Works

O processo consiste de duas etapas: na primeira os dados so lidos na base de dados R/3,
marcados e copiados para arquivos externos a partir das orientaes do archiving objects (conjunto
de tabelas que estipula quais dados deve transitar de forma conjunta). Na segunda etapa os dados
marcados so consistidos e deletados da base de dados. Este processamento em duas fases existe
exatamente para garantir a mxima segurana desta sistemtica.

A arquitetura de archiving baseada em objetos de archiving que definem os processos e contm

Informao sobre as tabelas que contm os dados que sero arquivados

programa que extrai os dados e armazena em files externos
programa de deleo, que compara os dados armazenados com a base e efetua o delete se
ambos esto idnticos, garantindo a integridade dos dados extrados
Documentao do processo (visualizado atravs da opo Info na SARA)

A compresso dos dados nos files gerados da ordem de 5, embora cluster tables no possam
ser compactadas. O processo pode demandar muito processamento e I/O sendo recomendado rodar
em horrios fora do pico no sistema. O processo de delete (segunda fase do arquive) pode ser
selecionado para rodar imediatamente aps o extact ou para processamento posterior, comandado
pelo usurio. Apesar do processo de deleo somente ocorrer aps um verificao dos dados
armazenados, interessante que durante a implantao e testes de um ambiente de archive garantir
que esta facilidade no seja disparada automaticamente.

Archive Environment

Existem uma srie de objetos de archive j desenvolvidos pela SAP para operacionalizar o archive
em diversas reas e tabelas standard do SAP. A cada nova verso do R/3, uma tendncia que
novos objetos sejam introduzidos. A ferramenta ADK (Archive Development Kit) a interface
disponibilizada pela SAP entre os ABAP archiving programs e os archive files. Ela consiste de uma
srie de function modules. Desta forma a leitura dos dados arquivados efetuada atravs de
chamada a funes do ADK. Durante o processo de gravao, o ADK pode splitar os dados que
sero arquivados em vrios files. Esta interface nica atravs do ADK garante que o dado
armazenado seja visto pelos programas ABAP na forma exata com que foram arquivados. possvel
utilizar o ADK para desenvolver objetos de archiving para tabelas Z, definidas pelo usurio. Nunca a
utilize para acessar tabelas SAP standard, mesmo que no exista um objeto desenvolvido para
determinada tarefa. O SAP ArchiveLink uma interface para gerencia dos files arquivados.

Pgina 49
ACADEMIA BASIS

Acessing Archived Data

Quase todos os objetos de archive possuem programas de leitura prprios que lem o arquivo
seqencial gerado e emitem relatrios. Alguns objetos nos do ainda a facilidade de emitir relatrios
que mesclam informaes arquivadas com informaes do banco, como comum em quase todas as
anlises de relatrios FI. Algumas telas R/3 podem consultar dados diretamente dos archive files,

Apesar de alguns objetos de archive possurem a facilidade de reload dos dados (operao
inversa do archive), recomendado que esta operao somente seja efetuada para corrigir erros de
operao, como por exemplo archive disparado antes da hora. A SAP recomenda inclusive que esta
operao seja efetuada somente nestes casos e imediatamente aps a operao mal feita, nunca
alguns dias depois. S para lembrar, SD no pode sofrer o reload a partir da verso 4.0a.

Preparations for Data Archiving

Archiving um projeto que envolve de forma cooperativa a rea de Basis, analistas e usurios das
reas funcionais alm de uma assessoria jurdica para um amparo legal dos documentos gerados. Do
ponto de vista dos aplicativos, o archive se justifica j que alguns dados se tornam obsoletos e no
mais se fazem necessrios para consulta online. o conhecido arquivo morto das empresas. Do
ponto de vista da administrao do sistema, o archive se faz necessrios para esvaziar o banco, seja
por questes de tempo de backup/restore, performance ou ainda por falta de espao em disco.

Os administradores de sistemas acessam as funes de archiving normalmente atravs da

transao SARA. Os usurios dos aplicativos ativam a interface atravs de entradas nos seus menus
funcionais. necessrio uma identificao cuidadosa das tabelas com alto ndice de crescimento e
objetos que se justificam pelas necessidades do negcio. A transao DB15 um excelente auxlio
nesta anlise por fornecer uma referncia cruzada entre tabelas e objetos de archiving. Identifique e
estude todas as notas no OSS que se referem aos archive objects que sero implementados

Para cada objeto de archiving preciso definir suas parametrizaes que configuram os dados
que sero arquivados e a forma como esta operao ser efetuada (tamanho dos datafiles gerados,
nmero de registros em cada file, etc.). A transao SF01 utilizada para customizar o logical file e
paths. O objeto de archive possui duas variantes para o programa de deleo. O archive run possui
uma outra variante onde voc define os dados que sero arquivados Durante todo o processo deve
ser garantido a existencia de recursos computacionais para o processo como pelo menos dois work
process livres para o archive e disco disponvel para a movimentao de dados.

Monitoring an Archiving Run

Um archive roda em background e pode ser monitorado atravs da SM37. Dependendo da

configurao efetuada (tamanho dos files), o sistema pode gerar mais de um job de write, um para
cada file. Para cada file gravado o sistema gera ainda um respectivo job para efetuar a segunda parte
do archive, a fase do check e delete. Atravs da transao SARA (funcionalidade management)
possvel monitorar o tamanho, localizao dos files e nmero de registros arquivados.

Caso o processo de archive no seja completado com sucesso, diversas opes tero que ser
tomadas, dependendo do caso:
Caso ocorra um erro durante um dos jobs da primeira fase (write), preciso fazer um backup
dos files que foram gerados com sucesso, excluir o que estava sendo gerado no momento do
erro e aps isto restartar o processo para que os demais files sejam gerados e os registros
deletados
Se o erro ocorrer durante a fase do delete, ou seja, todos os files foram gerados com sucesso
e um dos jobs da segunda fase abendou, basta startar os jobs de delete manualmente.
Se ocorreu um erro durante a primeira fase e os jobs de delete no esto com start automtico,
preciso deletar os files que foram gerados at o momento e recomear o processo

Pgina 50
ACADEMIA BASIS

Para efetuar operaes de archive preciso possuir a autorizao especfica (S_ARCHIVE). A

transao SARA possui uma funcionalidade de Info que descreve para cada objeto de archive as
autorizaes necessrias para percorrer as tabelas do R/3 e recolher os dados. Alm disso no se
deve esquecer que o archive roda em background, significando que o usurio envolvido no processo
alm de possuir autorizao para a area funcional precisa possuir as autorizaes suficientes para
esta tarefa de rodar os jobs de archives.

Dicas prticas :
Veja a tabela arch* para entender a relao entre os objetos de archives e as tabelas
envolvidas
Sempre que for fazer um archive faa o ciclo completo para evitar perda de controle, tanto do
operacional quanto do R/3
Sempre procure notas sobre o objeto que ser arquivado pois como esta area est sendo
desenvolvida podem ter novas verses e atualizaes
Utilize o objeto bc_archive para arquivar os documentos de archive.

Pgina 51
ACADEMIA BASIS

System Monitoring

What, why, who and when

Os principais focos de monitorao so :

R/3 (application servers, buffers, )
Database (performance, buffers, backups, )
Operationg system (cpu, file system, hardware contention, )

A monitorao no R/3 4.0 feita de uma forma simplificada atravs de uma grande arvore que ira
mostrar, atravs de suas folhas, os diversos item que devemos estar atentos em todo o ambiente. A
grande vantagem desta arvore a hierarquizao e categorizao de todos os elementos (tree
elements e objects) que so relevantes, seus parmetros de valores (Attributes) e a captura
automtica e centralizada de todas as informaes e um ponto de acesso unico para a tarefa de

Monitoring Architecture

O Alert Monitor uma ferramenta configurvel que existe no R/3 e permite a monitorao de todo
o ambiente a partir de uma nica interface que exibe mensagens e sinais de alerta no sistema. A
monitorao dos diversos componentes e ferramentas do ambiente R/3 uma operao necessria
executada pelos administradores do sistema para melhorar a performance, garantir a disponibilidade
do sistema e identificar, analisar e corrigir erros que aparecerem no ambiente. Esta monitorao
uma tarefa peridica que abrange desde o sistema operacional, passando pelos componentes do
kernel R/3 e indo at a base de dados do sistema.

Os objetos passveis de monitorao no ambiente R/3 so arranjados em uma rvore que

sumariza em seus ns as diversas reas de atuao. Esta monitoring tree agrega atributos em seus
ns que podem ir sendo detalhados at chegar a granularidade mnima da entidade monitorada. Um
alert identificado em um destes atributos se reflete visualmente atravs de cores (verde-ok, amarelo-
warning, vermelho-alert) nos ns da rvore e hierarquicamente so transferidos para os galhos mais
elevados. necessrio portanto ir efetuando operaes de drill down no Alert monitor at identificar o
atributo que gerou a mensagem. previsto para releases futuros do R/3 que a funcionalidade do
monitor se estenda para anlise do transport system e das transaes de aplicao

O monitor do R/3 concebido com uma arquitetura aberta que permite inclusive que ferramentas
de terceiros sejam incorporadas a sua rvore de monitorao. Cada n da rvore denominado MTE
(monitoring tree element), que podem ser agrupados em classes de monitorao. Os objetos
fsicos ou lgicos que so passveis de monitorao so denominados Monitoring Objects.

Preparing the Monitor

O Alert Monitor precisa ser customizado e configurado para funcionar corretamente. Cada MTE
class pode ser configurada baseado em quesitos tipo nvel de visibilidade (operador, administrador,
etc.), prioridade do alerta e descries. Estas configuraes ficam vlidas para todos os objetos
pertencentes a uma determinada classe, evitando assim redundncia de definies. Os atributos
comuns tambm podem ser agrupados em customizing groups aos quais so associados thresholds
para os alerts e textos de alerta. Uma vez configurados os alerts, possvel ento associar tools aos

Coletar dados
Analisar os alerts
Reagir aos alerts (OnAlert tool)

As ferramentas podem ser associadas aos MTE classes ou a um MTE individualmente. Estas
ferramentas tanto podero ser ferramentas standard da SAP quanto ferramentas definidas e criadas

Pgina 52
ACADEMIA BASIS

pelo usurio. A rvore bsica de monitorao contm o Basic monitor, porm o usurio pode criar
suas prprias rvores customizadas de monitorao.

Tool Assignment

Para adicionar uma ferramenta ou uma classe na MTE devemos seguir os seguintes passos :
Definir a ferramenta e especificar o tipo da ferramenta (relatrio, funo, mdulo, transao,
programa, etc), a localizao (servidor, banco de dados, etc) e modus operandis (background,
foreground, manual)
Liberar a transao para a finalidade
Associar a ferramenta a classe ou ao no MTE. Isto facilita o acesso a ferramenta pois voce vai
aciona-la diretamente. Eventualmente voce pode herdar esta definio de outra arvore ou at

Monitoring and Tools

Na estrutura do Alert monitor cada server exibido separadamente. Cada server tem sua prpria
rvore que contm as seguintes estruturas: Operating system, Database, R/3 services, R/3 basis
system, R/3 ABAP e R/3 system log.

As principais transaes e mtodos para monitorar o sistema so :

A system log (transao SM21) contm informaes referentes ao sistema R/3 e suas
instncias e exibe mensagens categorizadas por classes: S (R/3 start/stop/operation mode
switches), W (rollback perfomed), K (kernel program error) e T (ABAP transaction error). No
NT a transao mostra o log (/usr/sap/SID/dvebmgs00/log/slog00.log) apenas da instncia
corrente. No Unix ela pode mostrar as logs de todas as instncias
n R/3 services prov informaes sobre os work processes do sistema. A transao SM51
nos d um overview (incluindo a queue do dispatcher, system log, remote logon, etc) das
instncias disponveis enquanto a SM50 analisa os work process de uma instncia especfica.
A SM66 oferece um overview de todos os work processes ativos (se for necessrio o default
pode ser alterado para ver todos ou em um status especifico) em todos as instncias do
sistema.
A SM04 e AL08 nos d um overview dos usurios logados no ambiente R/3. A SM04 mostra
os usurios de uma determinada instncia e a AL08 de todas as instncias ativas.
processo de update no R/3 usualmente executado em modo assncrono, onde os dados so
escritos em tabelas intermedirias (VB* tables) e posteriormente transferidas para a base de
dados pelos work processes de update V1 e V2. A transao SM13 permite a monitorao da
fila e dos processos de update. A fila de update poder conter processos que terminaram com
erro. Apesar de ser possvel em alguns casos restartar estes processos, a SAP no
recomenda que se proceda ao restart da transao pelo usurio.
R/3 possui seu prprio mecanismo de lock que fica residente em uma tabela na memria da
instncia que contm o processo de enqueue. Os locks podem ser monitorados atravs da
SM12. Os locks que permanecem no sistema podero ser eliminados manualmente
aps exaustiva verificao das causas, uma vez que o procedimento normal quando os
locks postados so eliminados automaticamente pelo update das tabelas ou cancelamento da

A transao ST22 permite que se analise os dumps de programas ABAP. Atravs desta
anlise possvel identificar o erro pela anlise dos campos e variveis envolvidos e
eventualmente procurar no OSS por notas que corrijam o problema.
A ST03 o workload monitor que permite analisar os tempos de resposta. As estatsticas dos
tempos de resposta das transaes so apresentados de forma detalhada e estratificadas por
componentes (rolltime, wait time, DB time, processing time e load time) permitindo a rpida
identificao de possveis gargalos no ambiente R/3. As estatsticas apresentadas pela ST03
permanecem em um arquivo do sistema operacional (file stat no diretrio data da instncia) e
so recolhidas e consolidadas de tempos em tempos pelo programa RSCOLL00 schedulado
no ambiente. Este programa se baseia na tabela TCOLL para disparar uma srie de outros
programas satlites que efetuam as mais diversas tarefas de consolidao por nveis de
tempo/data.

Pgina 53
ACADEMIA BASIS

A SMLG permite definir e monitorar logon groups. Com esta facilidade possvel fazer
balanceamento de carga atravs da distribuio inteligente dos usurios das diversas reas
pelos servidores de aplicao da rede.
A transao ST02 prov informaes referentes aos status dos buffers e o gerenciamento de

A transao ST04 permite monitorar a base de dados do ambiente deforma detalhada, seja
atravs de anlise de buffers ou da anlise fsica de discos e locks.
A ST06 exibe informaes referentes ao sistema operacional recolhidas pelo programa
saposcoll. A anlise pode ser tanto um retrato do instante quanto uma comparao evolutiva

Os work processes alocam reas na memria para trabalhar os processos. Um dialog work
process trabalha em modo multiplexado para otimizar a sua utilizao entre os diversos dialog steps
que compem um transao R/3. Para permitir esta multiplexao, os dialog work processes efetuam
roll out e roll in da user context area dos processos. Quando um processo rolled out
por um work process e posteriormente rolled in por outro dialog da instncia ocorre o que chamamos
de work process dispatch

Diferentes tipos de memria so alocados pelos dialog work processes. Inicialmente o sistema
aloca uma pequena poro da roll area (definido no parmetro ztta/roll_first) onde estabelece
ponteiros para os diversos pedaos de memria que vo sendo alocados na extended memory do
sistema. Uma vez esgotado o limite de memria obtido na extended memory, o dialog passa a utilizar
o restante da roll area disponvel. Note que ao entrar em multiplexao, o processo de roll out/roll in
efetua rolagem apenas da poro de memria alocada na roll area, j que a extended memory
permanece alocada mas tem os seus ponteiros salvos no processo. Quando toda esta rea esgota, o
dialog lana ento mo da memria local, ou heap area. Como esta memria no pode ser rolled out
(por ser grande), o dialog entra em modo PRIV (private) e para de fazer multiplexao,
permanecendo alocado para o usurio mesmo durante os dialog steps.

Como os background work processes no necessitam fazer roll in/roll out por no serem
conversacionais, a seqncia de alocao de memria varia em relao aos dialog. O sistema aloca
a roll area, posteriormente a privaty memory (heap) e somente ento faz uso da extended memory,
que fica desta forma mais dedicada para os dialog process.

Quando se trabalha com vrios application servers em um ambiente R/3, necessrio que os
servers permaneam sincronizados para garantir a integridade dos insert e updates que ocorrem no
ambiente. Os dados que necessitam de sincronizao so escritos em uma tabela (DDLOG) que de
tempos em tempos consultada e os dados l presentes sofrem refresh na memria das instncias,
sendo desta forma sincronizados. O parmetro rdisp/buffrefmode especifica como a escrita e leitura
desta tabela ocorre e o parmetro rdisp/buffreftime especifica a frequencia do refresh.

O parmetro rdisp/buffrefmode possui um valor dividido em duas partes. O primeiro campo

especifica se o sistema ir (sendon) ou no (sendoff) escrever valores na DDLOG. O segundo campo
especifica se o sistema ir (exeauto) ou no (exeoff) efetuar leitura e consequentemente refresh dos

Sistemas distribudos com vrias instncias devero ter o

exeauto especificado em cada uma de suas instance profiles. At mesmo sistemas que possuem
apenas uma instncia devero especificar este parmetro para sendoff/exeauto j que durante o
processo de transporte o tp grava entradas nesta tabela para posterior refresh.

Pgina 54
ACADEMIA BASIS

Segunda Semana

Users and Authorization in the R/3 System

Users in the R/3 environment

O Ambiente R/3 possui vrias formas de controle de acesso mas devemos lembrar que o R/3 est
sendo executando em um sistema operacional e utiliza um banco de dados como repositrio e
portanto devemos observar os aspectos de segurana nestes ambientes e na inter-relao entre o
R/3 e eles.

Devemos tomar cuidado com os usurios do sistema operacional (normalmente SIDadm) e do

banco de dados (sys/change_on_install e system/manager) tanto na central instance quanta nos
applications. Com estas chaves podemos acionar utilitrios no sistema operacional, como sapevt, e
acessar o banco de dados diretamente a partir de utilitrios do oracle. Do lado do R/3 temos que ter
os mesmos cuidados pois uma brecha na autorizao pode permitir que uma chave no R/3 acabe por
ter acesso ao sistema operacional e aos mesmos utilitrios mencionados anteriormente.

Uma das primeiras atividades aps a instalao do sistema a troca das senhas dos usurios
(SIDadm, sys, system, sap, sap*, ddic e earlywatch).
.

Authorization Concepts

As autorizaes existem para limitar o acesso a transaes e objetos do sistema R/3 que
necessitam de proteo. As autorizaes so agrupadas em profiles e estas profiles so associadas
ao master record do usurio. Autorizaes podem ser no nvel da transao ou nos mais diversos
nveis, como por exemplo em operaes na transao ou ainda em range de valores de campos

As autorizaes sempre pertencem a authorization objects. Estes objetos de autorizao so

agrupados em object classes que por sua vez so organizados ou categorizados por business area
(FI, SD, etc.). As autorizaes so mantidas atravs da especificao de valores para determinados
fields dentro de cada objeto de autorizao (que pode ter at 10 fields). Todas as autorizaes so do
tipo positivas, ou seja, efetuam grants para o usurio e no revokes, ou seja, se duas autorizaes
forem dadas, uma mais restritiva e outra mais ampla, vale a mais ampla. Um user master record pode
possuir uma ou mais profiles, que podem ter sido geradas atravs da definio de activity groups
PFCG) ou manualmente. Uma profile pode ainda ser composta de mais de uma
profile (composite profile) mas limitada a um mximo de 150 profiles. As profiles so associadas ao
usurio tanto manualmente atravs da SU01 quanto durante o processo de gerao e manuteno
das activity groups.

Eventualmente pode ser necessrio criar objetos de autorizaes alm do standard. Para isso
usamos a transao SU21 para manter objetos de autorizaes e a SU20 para manter os campos

Em relao aos papis dos administradores de segurana no sistema poderamos dividir a

administrao em trs nveis, a saber :
Administrador de usurio: responsvel por manter os dados dos usurios, por associar os
grupos de atividades e as profiles aos usurios e atender aos chamados dos usurios
Administrador de profiles: responsvel por manter os grupos de atividades e as profiles de
forma genrica sem entrar no mrito dos valores atribudos as responsabilidades e atendo-se

Administrador dos dados da autorizao: responsvel por manter os valores dentro das
responsabilidades dos grupos de atividades

Desta forma o superuser poderia delegar grande parte das tarefas para se dedicar as demais
atividades de basis e os demais administradores poderiam entender bem mais das questes

Pgina 55
ACADEMIA BASIS

semnticas associadas as autorizaes aplicadas a cada funo a ser desempenhada pelos

Authorization as ER

Classes Objects Fields

1-n na task e Authoriz. Values

n-n no cdigo abap

Transaction Profiles Users

Authorization Checks

Quando o usurio efetua o logon no sistema suas autorizaes so carregadas para a user
context area (que fica na roll area da instncia) e so verificadas a cada transao ou atividade
executada pelo usurio. Antes que uma determinada transao ou operao ocorra, os fields do
authorization object so checados contra os fields do usurio para aquele mesmo objeto de
autorizao. Esta operao do tipo AND, ou seja, todos os n fields do objeto tem que ser atendidos.
Caso a verificao falhe, o usurio recebe uma mensagem de erro e a operao no executada.
Caso o usurio possua duas autorizaes contrastantes, vale aquela que libera o acesso, j que

Para simplificar, podemos entender que a verificao de segurana ocorre nos seguintes em
passos :
Para ganhar acesso a transao
Verifica se o usurio est autorizado a acessar a transao atravs da verificao do objeto
s_tcode
Verifica o objeto associado a transao em questo e se o usurio tem autorizao para este
objeto e quais so elas. Ex. O usurio possui o s_tcode para mm01, mas possui o valor 03
para o campo actvt do objeto m_mate_sta
Durante o processamento do cdigo abap
Verificao das autorizaes verificadas pelo comando abap authority-check

Algumas outras dicas isoladas de autorizaes :

Durante um call transaction os dois primeiros passos, relacionados a segurana da transao,

Se o buffer do usurio for pequeno demais (veja parmetro auth/auth_number_in_userbuffer)

algumas autorizaes podem ser perdidas
Se for necessrio cancelar a verificao do s_tcode utilize o parmetro
auth/no_check_on_tcode
Se for necessrio saber quais autorizaes esto carregadas no buffer utilize a transao
SU56 e se for necessrio saber qual autorizao est faltando utilize a SU53

Dicas de tabelas: Tabela TACT contm todos as atividades possveis no r/3 e a TACTZ contm o
relacionamento das atividades possveis para um objeto

Profile Generator

O profile generator (PFCG) uma ferramenta que simplifica a administrao de segurana atravs
de uma viso voltada para o menu de transaes da empresa permitindo que de forma mais interativa
se crie e associe profiles para usurio ou grupo de usurios que executam determinada funo. Este

Pgina 56
ACADEMIA BASIS

grupo lgico de funes comuns que possuem profiles comuns so denominados Activity Groups. Um
usurio pode estar associado a um ou mais activity groups. Ao se associar uma transao a um
determinado activity group, o profile generator automaticamente identifica os authorization objects
necessrios para aquela atividade e os associa a profile que ser gerada. Caso os fields sejam
customer-independents, o sistema j prov os valores necessrios para a atividade, caso contrrio os
valores precisam ser completados pelo administrador durante o processo de gerao. Ao gerar um
activity group o administrador de segurana dever checar os valores propostos pelo sistema para os
diversos field e altera-los ou prov-los conforme o caso, antes de salvar o processo

O R/3 permite ainda que se crie os activity group com responsabilities, o que permite que uma
mesma descrio funcional (activity group) seja associada para diferentes grupos de usurios,
provendo assim diferentes nveis de autorizao dentro de uma mesma funcionalidade. Isto simplifica
a administrao de segurana. Neste caso os usurios so associados a responsabilitie e no mais
ao activity group. Isto significa que caso grupos distintos de usurios que efetuam as mesmas
transaes em um sistema R/3 diferindo apenas nas autorizaes para operaes permitidas dentro
destas transaes no mais precisam ser administrados a partir de activity groups distintos, mas sim
atravs de responsabilities distintas dentro do mesmo activity group. Neste tipo de administrao, as
autorizaes para transao so associadas apenas uma vez no activity group para os diversos
usurios, o que simplifica caso uma nova transao comece a fazer parte de suas atividades.

Ao exibir a lista de autorizaes no profile generator, o sistema divide a exibio em 3 nveis:

primeiro nvel contm as object class, por exemplo Standard Finantial Accounting - FI
segundo nvel contm os authorization objects, por exemplo Customer: Authorization for

No terceiro nvel contm authorizations, por exemplo Customer: Authorization for company
codes T..... e abaixo dele o sistema lista todos os fields com seus respectivos valores

Nesta lista possvel dar manuteno nos valores (clicando no lpis) ou ainda obter
documentao detalhada de um authorization object s dar um duplo click na sua descrio
(segundo nvel). Ao se clicar no item da montanha (authorization object) possvel obter uma lista
das transaes daquele activity group que necessitam deste objeto de autorizao.

O profile generator possui outra caracterstica. Nele possvel fazer o apontamento para os
usurios que iro possuir um determinado perfil. Neste caso devemos executar o programa
RHAUTUPD para rever as profiles e task profiles dos usurios. Na prtica o programa varre o
cadastro de usurios removendo todas entradas relacionadas ao grupo de atividade que esta sendo
trabalhado e depois insere-as novamente. Se for necessrio fazer isto para todos os grupos de
atividades devemos utilizar a transao PFUD, que aciona o programa RHAUTUP1. recomendado
que este programa esteja agendado para rodar diariamente durante o periodo noturno. Com isto
temos a garantia que os apontamentos sempre estaro corretos.

Os principais passos para a criao de um perfil, tambm conhecido como activity group, so :
Especificar as atividades que sero desenvolvidas a partir dos caminhos de menu
Criar as responsabilidades (opcional)
Criar a authorization profile
Associar os usurios ao activity group
Atualizar, utilizando o rhautupd, o mestre de usurios

Devemos procurar sempre alterar o nome gerado pelo standard para facilitar o compreendimento
e a localizao. A SAP sugere que o nome sempre comee por S_.

O profile utiliza as cpias de algumas tabelas standard (USOBT e USOBX) para trabalhar. A
USOBT_C contm os objetos que precisam ser verificados e a USOBX_C os valores necessrios aos
objetos. Estas tabelas podem ter seus contedos mantidos pela transao SU25. J a transao
SU24 pode ser utilizada para ajustar os checks dos objetos. Como ilustrao, a transao SU24
mantm o tipo de check que ser feito, a saber : U no mantido; N no checked; C
checkado mas os valores no so mostrados no profile generator e CM o check feito e o profile

Pgina 57
ACADEMIA BASIS

User Master Record

Atravs da transao SU01 possvel dar manuteno nos usurios. As informaes esto
agrupadas por identificao e localizao, dados de logon, defaults, task profiles, profiles e
SU3 (ou System User profile Own data) permite que o prprio
usurio altere seus dados, tais como Address, Defaults e Parameters, sem violar a segurana de
acesso estabelecida pelo administrador.

Lembrar sempre que se for associar uma task ou responsibility (profiles geradas por profile
generator) a um usurio, o correto faze-lo pela pasta de task profiles. Se a incluso for feita pela
pasta de profiles a autorizao vai funcionar mas na prxima reconciliao (execuo do rhautupd)
este dado ser perdido pois vai prevalecer apenas as profiles adicionadas na task profiles.

Settings for System Profile Parameters

Diversos parmetros configuram o funcionalidade de segurana no R/3, a saber :

Configurar o tamanho mnimo da senha, login/min_password_lng com default 8
Marcar de quanto em quanto tempo a senha deve ser alterada,
login/password_expiration_time
Bloqueio de usurios aps logons incorretos, login/fails_to_user_lock com default 12
Fechar a sesso aps logons incorretos, login/fails_to_session_end com default 3
Desbloqueio de logons incorretos, login/failed_user_auto_unlock com default 1 (desbloqueia),
a meia noite
Bloquear o sap* de logar no sistema, login/no_automatic_user_sapstar com default 0
Existem diversos outros parmetros para configurar o sistema de segurana de login do R/3.

Para maiores informaes pesquise a nota 66533 e a 68048. Outra boa dica a remoo do sap*
na tabela usr02. Com isto, e a alterao do parmetro que impede do sap* logar, voce pode utilizar o
sap* com a senha pass.

A transao SUIM exibe, atravs da SARP ou SU01->information, a lista de todos os usurios

bloqueados no sistema e mais uma dezena de relatrios de usurios, profiles e outros relacionados
ao tema.

Security

Os clients 000 e 001 possuem os users SAP* (pwd 06071992) e DDIC (pwd 19920706) com, por
default, autorizaes SAP_ALL, devendo o administrador alterar suas senhas na instalao. O client
066 utilizado pela SAP para consultoria remota possui o usurio EARLYWATCH (pwd support) que

O SAP possui um usurio SAP* com password PASS e autorizao SAP_ALL hard-coded em
todos os seus sistemas. Isto significa que quando no existe um usurio SAP* na user master table
(USR02) do sistema, este usurio pode ser usado para efetuar logon como SAP_ALL. Por razes de
segurana portanto interessante que sempre tenhamos um usurio SAP* definido em cada client. A
nota 68048 sugere um parmetro (login/no_automatic_user_sapstar) que quando especificado
suprime a possibilidade de utilizao deste SAP* hard-coded. Porm sempre que se for criar um novo
client necessrio permitir a existncia desta feature hard-coded para que se possa logar no novo

Information System e Authorization Traces

O R/3 permite que se check quais verificaes de segurana esto sendo efetuadas em uma
determinada execuo de programa atravs de traces, que so ativados atravs do caminho Tools
Administration Monitor Traces System trace (veja nota 66056 para detalhes de utilizao) ou
ST01. O log gravado no diretrio \usr\sap\SID\DVEBMGS00\log\trace*.log.

Pgina 58
ACADEMIA BASIS

Para uma analise localizada de falha de segurana pode-se utilizar a transao SU53, que exibe
quais authorizations so requeridas em determinada task. A transao SU56 exibe o buffer de
autorizao do usurio. Se uma determinada autorizao no est aparecendo, verifique:
Se no houve uma manuteno de profile ou activity group enquanto o usurio estava logado.
Neste caso necessrio um novo logon
Se as autorizaes foram alteradas atravs de um transporte, preciso emitir um reset dos
user buffers para que os novos dados sejam carregados (SU01 Environment Mass
changes Reset all user buffs)
Se o buffer no est muito pequeno. O parmetro auth/auth_number_in_userbuffer define o
nmero de entradas reservada nesta rea para cada usurio, devendo ser aumentado se for o
caso

Ao se criar um usurio pela SU01 deve-se especificar a sua categoria, se Dialog, BDC (batch
input), Background (batch jobs) ou CPIC (para conexo remota). Algumas destas categorias tem
caractersticas prprias, como dialog ou background, mas servem tambm como informao
documentacional.

Password Rules

Existem uma srie de parmetros para configurar o tratamento que o R/3 vai dar a senha do
usurio. Alm da lista abaixo ainda podemos fazer uso da tabela USR40, atravs da SM30, para
inserir palavras ou seqncias de caracter que no poderam ser utilizadas na senha. As entradas na
USR40 podem tambm fazer uso de wildcards como *. Alm disso temos as seguintes regras :
Tamanho mnimo da password (login/min_password_lng) com default 3
Primeiro caracter diferente de ! e ?
Os tres primeiros caracteres no podem ser o mesmo nem ser iguais a parte do user name
No pode ser sap* ou pass
Nmero mximo de erros na senha para fechar a sesso (login/fails_to_session_end) com
default 3
Nmero mximo de erros na senha para bloqueio da chave (login/fails_to_user_lock) com
default 12
Libera os usurios que esto bloqueados por logon incorreto a meia-noite
(login/failed_user_auto_unlock)
Nmero de dias para que a senha expire (login/password_expiration_time) com default igual a
0, que significa que nunca expira

O R/3 tambm j vem preparado (hard coded) para impedir uma srie de outras senhas, a saber :

Profile Generator Setup

Para ativarmos o profile generator devemos seguir alguns passos, a saber :

Gerar o enterprise IMG atravs da SPRO, se ningum tiver feito. Provavelmente o time

Ativar o profile generator atravs da incluso do parmetro auth/no_check_in_some_cases =

Y
Desativar a solicitao a todo instante de chance request pelo profile generator atravs da

Criar a classe de desenvolvimento utilizando a transao OY08

Criar as cpias das tabelas standard (USOBX e USOBT) que o profile generator necessita
para gerar os grupos de atividades, utilizando a transao SU25
Alterar os check indicators e os valores dos campos dos objetos de autorizaes
Criar o menu da companhia para o profile generator utilizar

Transporting Authorizations and Users

Devemos sempre ter em mente que os grupos de atividades podem ser transportados mas o
cadastro de usurios no. Com isto temos um inconveniente que quando transportamos o grupo de

Pgina 59
ACADEMIA BASIS

atividades perdemos o link com os usurios que possuem este grupo no ambiente de destino. Por
outro lado, podemos levar todo o cadastro de usurios de um mandante para o outro. Isto pode
resolver problemas pontuais mas no resolve o problema da manuteno das profiles que esto na
produo e nem do ciclo normal de trabalho com os grupos de atividades.

Para transportamos um grupo de atividade, lembre-se ele foi desativado pela transao OOCR,
devemos clicar no icone do caminho na transao PFCG para transportarmos um grupo de atividade
especifico. Para transportamos um conjunto de grupos de atividades devemos utilizar o programa
RHMOVE30 que possui diversas formas de seleo. Aps importarmos a change que foi gerada no
ambiente de destino devemos executar a transao SUPC para regerarmos a profile. Neste caso,
quando geramos um grupo de atividade que veio do ambiente de desenvolvimento, precisamos
atualizar a tabela T77TR (utilizando a SM31) para que o transporte fique configurado para no perder
a associao com os usurios no ambiente de destino nos prximos transportes deste grupo de
atividades.

SAPRouter

O SAPRouter um componente de software que vem com o R/3 ( no unix um script que pode
ser adicionado no startsap e no NT um servio que deve estar ativo) para viabilizar a ligao de
duas redes com a garantia de segurana e proteo de acesso em cada uma delas pelo proprio
parceiro.

Com o SAPRouter voce pode :

Controlar e logar as conexes com o sistema R/3
Permitir que outros saprouters tenha acesso a uma rede especfica
Proteger o sistema contra conexes e envio de dados de usurios no autorizados
Encripitar senhas e outros dados por parceiros certificados pela SAP
Controlar o acesso ao servio de OSS da sap

Para utilizar o SAPRouter precisamos criar o diretrio saprouter debaixo da arvore \usr\sap; obter
a verso mais nova disponvel no OSS e criar a tabela de rotas permitidas no arquivo
\usr\sap\saprouter\saprouttab. Esta tabela que contm a definio de quem poder ou no passar
de um lado para o outro. Ela um arquivo texto com cinco campos, a saber : Permit/Deny/Secure,
endereo de origem, endereo de destino, servio e password. Os endereos podem tanto ser
hostnames com ip e neste ultimo caso podemos utilizar tambm os wildcards para selecionarmos
uma rede inteira (Ex. 123.45.*). J o servio e a password so opcionais, sendo que o servio
assume o defalt de 3299 que a porta padro utilizada normalmente para saprouter. A grande dica
na construo da routtab a definio do que proibido no inicio do arquivo e do que permitido no
final. Isto necessrio por que a leitura e deciso feita do primeiro para o ultimo.

Para especificarmos uma rota para o saprouter devemos utilizar o mesmo padro utilizado no
SAPGUI. A nica novidade a chave /W/ para conter uma eventual password a ser passada a um
saprouter. Para testar a rota podemos utilizar a dobradinha niping s no host origem e niping c H
<host_origem> no host destino ou simplismente niping c H /H/<saprouter>/H/<host_destino>. O
saprouter possui uma srie de variaes de parmetros. Elas podem ser obtidas simplismente
acionando o saprouter na linha de comando sem parmetros. Algumas delas so importantes como
R para dizem onde esta a routtab, -r para startar o servio, -s para parar o servio, -r V3 para
selecionar o nvel mais alto de trace, -t para ativar o trace, -T para dizer onde vai ser gravado o
arquivo de trace e G para dizer onde ser gravado o arquivo de log.

SNC secure Network communication

A SNC interface permite que o sistema R/3 passe a utilizar algoritmos de criptografia para os
dados que iro transitar na rede e para autenticar as senhas de usurios. Normalmente o R/3 no faz
criptografia de dados e a senha transita pela rede como caracter.

O SNC uma camada na arquitetura R/3 que estabelece um padro de interface para os
softwares de segurana e autenticao de usurio disponveis no mercado. Atualmente os softwares
certificados pela SAP so o Kerberos 5 do MIT e o Secude 5. Para maiores detalhes veja a nota

Pgina 60
ACADEMIA BASIS

66687. O padro SNC prove trs nveis de segurana, a saber : A autenticao da comunicao entre
os parceiros sem a proteo do dados que ser trocado; Integridade que garante a autenticao e
mais uma assinatura digital da informao que est trafegando para garantir sua autenticidade; e
Confidencialidade que garante a autenticao a integridade e a confidencialidade que o dado no
pode ser interpretado por outro que no sejam os parceiros da comunicao.

Para ativarmos o SNC temos que definir qual ser o padro de nome dos usurios. Podemos
escolher entre X.500 (que distingue o nome pela formao de diversos elementos), nome@dominio
(que usa uma concatenao simples do nome do usurio e de seu domnio) e o padro de nome
externo do R/3. Alm de definirmos o padro de nomes temos que incluir o parmetro snc/enable = 1
na default profile para ativar efetivamente o SNC. Com isto a SU01 passa a possuir mais uma pasta
que contm o nome SNC do usurio. Podemos ainda alimentar a tabela USRACL, que contm o de-
para, diretamente com o nome interno e o nome externo dos usurios. Para os usurios RFC e CPIC
podemos definir apenas um usurio interno para vrios usurios externos atravs da tabela
USRACLEXT. Podemos tambm ativar nveis de insegurana para alguns casos. Por exemplo,
aceitar sesses no seguras atravs do parmetro snc/accept_insecure_gui =1 ou
snc/accept_insecure_cpic = 1. Alm da SU01, outras transaes passam a possuir maiores detalhes
sobre o SNC, a saber : SM59 que controla as chaves RFC; a SM54 que controla as chaves CPIC e a
SNC0 que controla a lista de acesso entre sistemas R/3.

A utilizao do SNC pressupe a instalao de uma dll (secure.dll) junto com o SAPGUI alm do
cliente do software de segurana que ser utilizado. Para o saplpd temos que incluir na cliente uma
entrada no win.ini que habilita o uso do SNC pelo saplpd e indica a dll que ir interfacear com o

No geral devemos seguir algumas recomendaes para implementar o SNC. A primeira nunca
misturar applications que utilizam SNC com outros que no utilizam. A seguinte ter certeza que o
produto de segurana est apto a trabalhar com os padres de nomes estabelecidos pelo R/3; E por
fim garantir as definies do nvel de proteo desejado, dos parceiros e protocolos que sero
implementados, quais conexes sero protegidas e as respectivas portas a serem bloqueadas pelo

Pgina 61
ACADEMIA BASIS

Software Logistics

R/3 System, Servers and Instances

Uma instncia R/3 um grupo de servios que so inicializados e parados simultaneamente

por um dispatcher, possuindo em comum uma profile de instncia. O nome de uma instncia
composto pelos nomes que identificam os servios (Dialog Update (Verburren em alemo)
Enqueue Background Message Gateway) por ela executados. Uma central instance contm
tipicamente todos os servios R/3 instalados, da o seu nome ser DVEBMGSnn, j uma dialog
instance possui o nome Dnn, onde nn o system number utilizado para compor o nmero das portas
que efetuaro as chamadas ao dispatcher (32nn) e ao message server (36nn) na camada TCP/IP.
Um server pode conter uma ou mais instncias R/3 configuradas. Um PC com o frontend SAPGUI
instalado tambm considerado um server da camada presentation na arquitetura R/3. O database
server um hardware que possui o RDBMS relacional instalado. comum em R/3 instalarmos o
database server no mesmo host que contm a central instance. O conjunto de todos estes
servidores com suas respectivas instncias R/3 compem um R/3 System. Um sistema agrega uma
nica central instance que aloja o message server e normalmente um ou mais application servers.

R/3 Data

Os dados no R/3 podem ser divididos em duas categorias:

Client dependents data, que so os dados pertencentes a apenas um client de um sistema
R/3, como por exemplo os master, os transactional, customizing e user master data.
Client independent data, que so as informaes pertencentes a todo o sistema, como
algumas configuraes ou o repositrio de objetos

O dicionrio ABAP um dicionrio de dados que faz parte do repositrio ABAP de um sistema
R/3. Seus dados so client independents. Os programas ABAP armazenados no dicionrio so
compilados uma vez no primeiro acesso (early binding) e ficam armazenados em um outro
repositrio de executveis (tabelas D010*). Cada alterao em um programa fora a sua
posterior. Este procedimento denominado late binding
possvel atravs de um mecanismo de comparao de timestamp. Este mecanismo de early binding e
late binding garante que a integridade das informaes contidas no dicionrio ABAP no afete a
performance do sistema, uma vez que os executveis de telas e programas so mantidos atualizados
automaticamente em uma rea separada dos respectivos fontes.

R/3 Clients

Um client em R/3 uma unidade independente em termos organizacionais, tcnicos e

comerciais. Um client possui seus prprios usurios e seus prprios dados nas tabelas do R/3. Isto
permite que um nico sistema R/3 administre vrios clients diferentes, cada um com seus
prprios dados.

Como a base de dados (consequentemente as tabelas) em um sistema R/3 os dados dos

diferentes clients ficam armazenados no mesmo local e so diferenciados pelo kernel do R/3. Na
prtica o R/3 implementa esta separao atravs de um campo MANDT (de mandante, ou client em
alemo) que participa da chave primria das tabelas client dependents do R/3. Em qualquer chamada
a estas tabelas o sistema incorpora na clausula WHERE do SQL o campo MANDT = nnn. A nica
excesso a tabela T000 que defini quais so os clientes existentes na instncia e uma tabela com

Este campo que identifica um client composto de

que sempre que efetuamos um logon informemos o nmero do client. Este campo
tela de login inicial do R/3, juntamente com a chave e a password do usurio. Como os dados de
clients diferentes funcionam no R/3 como bases de dados diferentes (separao por kernel), as
empresas quando desejam implementar uma administrao coorporativa de suas subsidirias, o
controle centralizado possvel atravs de uma outra facilidade que o campo configurvel

Pgina 62
ACADEMIA BASIS

denominado company code. Este campo define a menor unidade administrativa com que os
relatrios externos podem varrer para uma viso centralizada.

O conceito de authorities do R/3 sobre este campo company code permite ainda que uma
companhia matriz acesse as suas filiais com finalidades de consultas ou auditoria impedindo que as
diversas subordinadas tenham acesso aos dados umas da outras.

Standard Client Roles

recomendado que um ambiente R/3 de uma empresa tenha no mnimo os seguintes clients:
Client CUST, como o ambiente central onde o desenvolvimento e as customizaes so
efetuadas pelos times funcionais e de abap. Neste client podemos fazer alteraes no
ambiente e gerar change request
Client QTST, utilizado para o teste de novas customizaes
Client PROD, que a produo da empresa

Em um ambiente ideal, os seguintes clients adicionais so recomendados:

Client SAND, que um sandbox onde novas customizaes so experimentadas antes de
efetivamente efetuadas no ambiente CUST. Neste client podemos fazer alteraes mas no
podemos gerar change request
Client TEST, para teste de customizaes com uma massa reduzida de dados
Client TRNG, como um ambiente de treinamento

R/3 Landscape

O conceito de Landscape no R/3 refere-se a um grupo de sistemas R/3 compreendendo

normalmente um desenvolvimento, uma qualidade e uma produo que compartilham change
requests e rotas de transporte com o propsito de manter um sistema de desenvolvimento e
customizao consistente. Por questes de segurana, aconselhado proteger o sistema utilizando o
conceito de clients, implementando a segurana atravs do conceito de autorizaes garantindo a
separao dos dados entre clients. aconselhvel ainda separar fisicamente os ambientes de
implementao do desenvolvimento, qualidade e produo. Alm das questes bvias de segurana
e performance do ambiente produtivo, tal implementao protege o sistema evitando que
configuraes client independents do ambiente de desenvolvimento sejam implementadas na

Uma implementao em dois ambientes tambm no aconselhvel porque todos os objetos

transportados para o ambiente de consolidao ficam imediatamente valendo no ambiente de
produo. A implementao mais recomendada pela SAP um landscape de trs ambientes que
implementam clients e rotas prprias de transporte, consistindo dos 3 clients bsicos e os 3
adicionais:
Um host composto de trs clients (SAND, TEST, CUST) onde fica o ambiente de
desenvolvimento
Um host de quality assurance (com dois clients QTST e TRNG) onde os novos
desenvolvimentos so testados antes de serem migrados para o ambiente produtivo
Um host para o ambiente de produo com o client PROD

Os sistemas R/3 que compem um mesmo landscape devem possuir system IDs diferentes para a
correta identificao das rotas de transporte

Change Requests and Transports

O sistema R/3 integra mais de 800 processos de negcio que precisam ser customizados e
configurados de acordo com as necessidades de cada empresa para atender e se adequar ao seu
ramo de negcio. Atravs de customizaes e desenvolvimentos especficos o sistema R/3
adaptado ao processo de negcio da empresa e estas alteraes precisam ser distribudas entre
todos os clients que compem o landscape da empresa, garantindo assim a consistncia do sistema.

Pgina 63
ACADEMIA BASIS

Transporte o processo no R/3 que permite a distribuio destas alteraes ao longo do

landscape. O R/3 fornece todas as ferramentas necessrias para a criao, documentao e
distribuio das alteraes no landscape. A correta configurao do ambiente de transporte
fundamental para o sucesso desta administrao:
Todas as alteraes devem ser bem documentadas
Um nico client recomendvel para todas as customizaes
Todo o trabalho de desenvolvimento dever ocorrer em um nico sistema R/3, garantindo uma
origem nica de todos os change requests
Os desenvolvedores e customizadores devero ter profiles de autorizaes de acordo com
suas necessidades de criao e release de change requests

O CTS (Change and Transport System) uma facilidade introduzida pela SAP no release 4.0 do
R/3 e composta das seguintes ferramentas:
CTO, Change and Transport Organizer que prov funes para gerenciar o desenvolvimento
de projetos que ocorram centralizados ou distribudos no ambiente. Ele composto das
seguintes ferramentas: Workbench organizer (transao SE09), Customizing organizer (SE10)
e Transport organizer (SE01)
TMS, Transport Management System que organiza, monitora e executa os transporte ao longo
de um landscape definido. O TMS utilizado ainda para as rotas de transporte ao longo do
landscape e acionado pela transao STMS
Ferramentas a nvel do sistema operacional (TP e R3Trans) que executam a comunicao
com o sistema R/3, o banco de dados e os arquivos gerados no processo de export dos
transportes

Pgina 64
ACADEMIA BASIS

Change and Transport System Prerequisites

Configuring the System Landscape

Antes de iniciar a instalao de um sistema R/3, defina a estrutura de rede necessria para
comportar o ambiente. Inicie a instalao pelo ambiente de desenvolvimento. nele normalmente
que residir o Transport Management System. Durante a instalao do sistema defina um diretrio
para o transport system. Este diretrio ser posteriormente compartilhado pelos demais ambientes
que comporo o landscape. Aps a instalao do R/3, configure o arquivo TPPARAM que
parametriza o sistema de transporte (informando qual o banco de dados e a onde ele est),
inicialize o Change Transport Organizer (CTO) utilizando a transao SE06 e configure o system
landscape utilizando o Transport Management System (transao STMS).

As change requests que permitem sincronizar as customizaes e desenvolvimentos entre os

sistemas R/3 fluem no landscape atravs de rotas pr definidas
denominadas transport routes. O sistema de transporte utiliza um diretrio prprio para onde os
change requests liberados so exportados da base de dados. Neste diretrio o sistema armazena
alm de data files, arquivos de comandos e logs de transporte.

Fisicamente em um landscape de trs sistemas, o transporte de um change request ocorre em

Todos os objetos encapsulados em um change request que liberado (released) so

exportados da base de dados do sistema fonte para o diretrio de transporte
Em um segundo passo, os objetos sero importados do diretrio de transporte para a base de
dados do ambiente de quality assurance.
Finalmente aps o teste e verificao das alteraes, os objetos so importados para a base
de dados do ambiente de produo (deliverya system) definido

(\usr\sap\trans) e todos os seus subdiretrios so exportados pelo

ambiente onde foi originalmente definido (normalmente o desenvolvimento) e montado via NFS nos
demais hosts dos sistemas que compem o landscape. Este compartilhamento de uma rea nica
pr requisito para o correto funcionamento do sistema de transporte.

No ambiente NT o diretrio exportado pelo compartilhamento sapmnt e montado nos outros

hosts como um disco e acessado por \\hostdev\sapmnt\trans que deve ser setado no parmetro
DIRTRANS. A configurao deste parmetro necessrio pois o diretrio \usr\sap\trans existe em
todas as mquinas mas devemos utilizar uma rea nica para todo o landscape. Para maiores
detalhes sobre sistemas heterogeneous veja a nota 83327.

O arquivo TPPARAM contm informaes que parametrizam o funcionamento do programa de

transporte, o tp. O TPPARAM reside no subdiretrio bin do transport directory e deve ser configurado
aps a primeira instalao a partir do arquivo template fornecido durante a instalao. A cada novo
sistema introduzido posteriormente no landscape, este arquivo precisa ser editado para incorporar os
parmetros dbname e dbhost e transdir do novo ambiente. Para o parmetro transdir, e outros
relacionados a diretrios, sempre utilize o nome da mquina e o respectivo compartilhamento (Ex.
\\host\sapmnt\trans). Para checar se o programa tp est disponvel em todos os ambientes do
landscape, utilize o comando R/3 system -> Check -> Transport tool. possvel ainda testar todo o
diretrio de transporte atravs do check de transport directory. Para consultar os parmetros definidos
no arquivo TPPARAM, utilize o caminho de menu Goto -> TP parameter.

Na verso 4.0b temos alguns problemas com os mecanismos de transporte pois o conjunto do
STMS ainda no est finalizado (j est mais bem acabado na verso 4.6). O primeiro problema a
seqncia de importao das changes request: ele sempre segue a seqncia de export, ou seja,
uma vez exportada o usurio no vai conseguir alterar a seqncia para uma seqncia mais lgica.
O segundo problema que uma change que foi importada no sistema de qualidade j pode ser
importada no ambiente produtivo independente se ela j foi verificada e confirmada pelo
desenvolvedor. Podemos criar um mecanismo para tentar minimizar erros onde o diretrio
\usr\sap\trans do ambiente produtivo seria separado. Com isto o analista basis passa a ter que

Pgina 65
ACADEMIA BASIS

controlar as changes que devem ser importadas na produo atravs da manipulao do arquivo de
buffer por um editor de texto. Desta forma passamos a in foreign group import no sistema R/3.

Initializing CTO

A transao SE06 utilizada para configurar o change and transport organizer. Ela deve ser
executada uma vez a cada nova instalao de um sistema R/3, independentemente de ser uma
instalao standard ou um database copy. Estas configuraes so globais no sistema R/3 e tem
prioridade inclusive sobre as configuraes dos clients (SCC4). A transao SE06 estabelece o valor
inicial para os change request e configura as opes iniciais do sistema definindo se o repositrio de
objetos e os objetos de customizao client independents sero globalmente modificveis.

Para os ambientes de produo e de qualidade no faz sentido permitir modificaes no sistema.

J no sistema de desenvolvimento tudo pode ser permitido. Eventualmente podemos bloquear os
objetos locais para garantir que o time de abap no vai criar objetos sem encapsula-los em change
requests.

TMS - transport managementa system

Atravs da transao STMS possvel definir as regras de transporte no landscape e os

respectivos papis de cada um dos sistemas R/3, definindo assim a estratgia de transporte
baseadas em rotas pr definidas. As rotas podem ser definidas de forma
da STMS, onde possvel ainda visualizar as filas de transporte e importar objetos.

Transport Domain

Um transport domain compreende todos os sistemas R/3 administrados centralizadamente

atravs do TMS. Quando se configura uma definio no TMS, o sistema cuida de distribuir via RFC
a definio entre todos os sistemas que compem o domnio. Isto garante que as configuraes de
transporte sejam consistentes em todos os sistemas pois todas as configuraes so feitas apenas
no Domain Controler (sistema R/3 que ira controlar todos os outros sistemas R/3 do landscape). Por
segurana podemos eleger um backup domain controler que entra em ao se o domain controler
sair do ar. Este switch feito na mo e depois deve ser desfeito quando o domain controler estiver de
volta. A SAP sugere que o Domain Controler seja o sistema R/3 dedicado a qualidade pois ele o
que tem o menor volume de trabalho. Na prtica o Domain Controler o sistema R/3 de
desenvolvimento pois ela normalmente a primeira a ser instalada.

O TMS suporta vrios diretrios de transporte em um transport domain. Os sistemas R/3 que
compartilham um mesmo diretrio compem um transport group. Atravs do TMS podemos executar
transportes entre sistemas que pertenam a transport groups distintos mas ela no suportam
transportes entre domnios diferentes. Devemos lembrar que se fizermos o tp import entre domnios
diferentes o processo ser bem sucedido. O mesmo no pode ser garantido entre sistemas R/3 de
verses diferentes pois podem existir diferenas na estrutura e na utilizao nos objetos
encapsulados pela change.

O Landscape pode ser definido como todos os sistemas R/3 que compartilham change
requests com o propsito de manter ambientes consistentes de desenvolvimento e customizao.
Por este motivo um system landscape normalmente sinnimo de um transport domain, embora um
transport domain possa conter mais de um system landscape apenas para fazer uso da vantagem de
um ambiente TMS centralizado.

A configurao do TMS executada atravs da transao STMS no client 000 e com o usurio
DDIC, ou um equivalente com a profile S_CTS_ADMIN, e passa pelos seguintes passos:
Configurao do transport domain atravs da especificao dos sistemas R/3 e dos transport
groups alm da definio de um deles como sendo o controlador do domnio.
Configurao das rotas de transporte atravs da definio do sistema onde as changes sero
consolidadas e do sistema onde a change ser finalmente delivered aps os testes
Check e verificao das configuraes atravs das ferramentas do TMS

Pgina 66
ACADEMIA BASIS

O sistema escolhido como controlador do domnio dever ser um sistema com alto grau de
segurana e disponibilidade, normalmente o production system ou o QAS. Esta tarefa no oferece
nenhuma carga adicional ao sistema mas a SAP sugere que seja instalado no QAS que
supostamente o sistema R/3 com menor carga de trabalho.

A transao STMS, no momento da configurao inicial, ir criar um transport domain

(DOMAIN_<SID>), um transport group (GROUP_<SID>), user CPIC no client 000 (user TMSADM
para acesso de leitura), os destinos RFC requeridos pelo TMS (tmsADM@ para leitura e tmsSUP@
para leitura/gravao) e um arquivo DOMAIN.CFG no subdiretrio bin do diretrio de transporte que

recomendado que se tenha um servidor configurado como backup controler para o TMS, em
caso de falha do principal. Como comum, no momento da configurao do TMS nem todos os
sistemas existem, o R/3 permite que se defina todo o ambiente atravs da especificao de sistemas
virtuais, permitindo com isto que se configure antecipadamente todas as rotas de transporte.

A SAP prov o TMS com configuraes standard default que j prove rotas para landscape de um,
dois ou trs sistemas, agilizando desta forma o trabalho de configurao inicial. As rotas de transporte
so de dois tipos: de consolidao, do desenvolvimento (integration system) para o sistema de quality
assurance (consolidation system) atravs de uma transporte layer (Z<SID>), e de delivery, onde os
transportes consolidados so finalmente transportados do sistema de qualidade (consolidation

Aps configurar o transport domain e definir as rotas de transporte, o TMS utilizado para
distribuir esta configurao entre os sistemas e ativar a nova configurao. As alteraes efetuadas
em objetos SAP so transportadas atravs da consolidation route SAP. Atravs do hierarchical list
editor possvel visualizar e editar a configurao do TMS. O sistema aceita ainda a configurao
atravs de ferramenta grfica drag-and-drop. O TMS prov ainda ferramentas para testar as
conexes RFC, checar o diretrio de transporte e verificar o funcionamento do programa tp.

Pgina 67
ACADEMIA BASIS

Change Management for Development

Change Requests

As alteraes no software R/3 podem ser divididas em cinco categorias:

Customizing: a configurao dos processos de negcio e funes de menu atravs do
IMG
Personalization: so as mudanas globais das caractersticas das telas e definio de
valores default para determinados campos (SM3)
Modification: so mudanas efetuadas pelo cliente no repositrio de objetos do R/3 (os
SAP objects). estas alteraes precisam ser cuidadosamente avaliadas quando do upgrade
de verses do sistema. A partir do release 4.5A a SAP introduziu o Modification Assistent
para auxiliar a gerenciar e automatizar estas mudanas
Enhancement: criao pelo cliente de objetos no repositrio que so referenciados pelos
objetos standard do R/3 atravs de user exits. Estes desenvolvimentos so os ideais por
reduzirem as necessidades de modification adjustments durante o processo de upgrade
Customer Development: criao pelo cliente de objetos no repositrio atravs do ABAP
Workbench (programas, etc.)

Uma change request um pacote contendo os objetos que sero transportados de um sistema
R/3 para outro. Por exemplo, no caso de um abap ser encapsulado o source, no caso de uma
configurao ser encapsulado as entradas nas tabela e sua respectiva ao (cria/deleta/altera). Uma
change request pode ser atribuida a vrios usurios atravs do conceito de tarefa. Apesar do nome
tarefa ela no representa o que vai ser feito, ela representa a associao da change request com o
usurio e a respectiva documentao (que no obrigatoria) do que foi feito.

Todas as alteraes efetuadas nos objetos do repositrio so criadas e mantidas atravs do

ABAP Workbench e gravadas em change requests. As demais alteraes de customizing e
personalizations so criadas e mantidas pelas ferramentas de business engineer e tambm gravadas
em change requests. Estes mecanismos permitem que estas alteraes sejam posteriormente
propagadas pelo landscape para consistncia do ambiente.

O workbench organizer oferece mecanismos que permite que os change requests sejam
documentados atravs de uma descrio do seu propsito. Os change requests devem ser criados
por gerentes de projeto que associam os objetos do repositrio que sero trabalhados, onde
permanecem lockados com acesso permitido apenas aos desenvolvedores que foram autorizados
ao change. As alteraes nos objetos do repositrio so criadas como tasks associadas ao change
request e quando liberadas so transferidas como um todo atravs das rotas que definem o
landscape, j que a unidade de transporte o change request. A liberao de um change request faz
com que uma nova verso dos objetos nele contidos seja gravado no database de verses (somente
no sistema R/3 que foi utilizado para o desenvolvimento).

WBO - workbench organizer

O Workbench Organizer (transao SE09) permite gerar, gerenciar e liberar as tasks e os

change requests. Os change requests podem ser pesquisados por vrios critrios, tais como
desenvolvedor, status, tipo do request ou ainda por data. O frame Global Information da tela SE09
d uma viso grfica do status dos change requests transportados e repairs. O Workbench
Organizer exibe os change requests de um determinado usurio atravs de uma
que permite a visualizao hierarquizada da estrutura. Esta rvore organizada entre change
requests com status Transportable (que poder ser transportada para outro sistema), Local (no
poder ser transportada) e Unclassified. (No confunda uma local change request com local object.
Um local object est preso a development class $tmp e nunca poder ser transportado. No caso de
um objeto, com uma development class vlida, associado a uma change request local significa que
esta change no ser transportada mas eventualmente em outra change o objeto pode ser
transportado).

Pgina 68
ACADEMIA BASIS

Quando o lder de um projeto cria um change request, o sistema associa a ele um nmero
(<SID>K9nnnnn como por exemplo DEVK900736) e ao associar os desenvolvedores, cada um
recebe uma task cujo cdigo estruturado no mesmo critrio. A medida que os desenvolvedores vo
terminando suas tasks elas vo sendo liberadas individualmente. Quando todas estiverem liberados o
gerente do projeto libera o change request que pode ento ser transportado para outros sistemas.

As autorizaes do Change Management so usualmente gerenciadas em quatro grupos distintos

S_CTS_SHOW, que permite apenas visualizar os change requests e ver suas logs
S_CTS_DEVELO, mais abrangente que a anterior, fornecida aos desenvolvedores que
passam a ter gerencia sobre suas tasks
S_CTS_PROJECT, que a autorizao dos gerentes de projeto, que podem criar e
gerenciar os change requests
S_CTS_ADMIN, a autorizao do administrador do CTS e tem acesso mais abrangente a
todas as suas ferramentas

Para o dia-a-dia do projeto utilizaremos esta lista abaixo de profiles para os principais papeis a
serem desempenhado durante o projeto :
S_A.SYSTEM, normalmente utilizada pelos administradores do sistemas e inclui todas as
autorizaes relativas ao CTS e STMS. Esta profile contm a autorizao s_cts_admin
S_A.CUSTOMIZ, normalmente utilizada pelo lider da equipe e inclui autorizao para todas
as atividades de configurao do ambiente. Esta profile contm a autorizao s_cts_project
S_A.DEVELOP, normalmente utilizada para os abapers e configuradores e no permite a
criao de change request. Esta profile contm a autorizao s_cts_develo
S_A.SHOW, este perfil utilizado como curinga pois ele possui todas as autorizaes de
basis mas todas elas somente para display. Esta profile contm a autorizao s_cts_show

Todos os desenvolvedores ABAP precisam ter um registro composto de 20 dgitos obtido junto ao
OSS e denominado SSCR, SAP Software Change Registration. Sem esta chave no possvel
efetuar alteraes no repositrio de objetos. Cada access key associada com o logon ID do
desenvolvedor e ao license number do sistema R/3. Esta chave requisitada no primeiro acesso ao
repositrio e no mais requisitada nos acessos posteriores. Os objetos criados pelos
desenvolvedores no repositrio devero
SAP para os objetos dos clientes, evitando assim conflito de nomes com objetos standard do
repositrio. A nota 16466 descreve em detalhes a nomenclatura a ser adotada na criao dos nomes.
Da mesma forma que temos que registrar um desenvolvedor, temos que registrar no SSCR a
modifio em um determinado objeto standard.

O conceito de name ranges permite que se adote critrios de nomenclatura associados a classes
de desenvolvimento. A SAP adota ainda o critrio de reservar namespaces para objetos
desenvolvidos pelos seus parceiros de desenvolvimento. O comportamento do repositrio no que
diz respeito aos namespaces e name ranges determinado em cada sistema R/3 atravs de global
settings que determinam se os critrios sero modificveis ou no. Escolha a opo Tools ->
Administration -> Transports -> Installation follow-up work -> Goto -> System change options. Para
manter estes name rangers use a view v_tresn atravs da transao sm30.

Development Class and Transport Layers

Todos os objetos do repositrio so associados a development classes

agrupamento lgico de objetos que coordenam os esforos de desenvolvimento. Development
classes no SAP devero comear com Z, Y, $ ou T. $ define development classes para objetos
temporrios que no sero transportados e T development classes para objetos locais. Quando
associamos transport layers a development classes, todos os objetos pertencentes ao determinado
development class tero a mesma rota de consolidao pr definida pela transport layer. Os objetos
SAP pertencem a uma transport layer pr instalada denominada SAP. Para definirmos a development
classes podemos utilizar o repository browser (transao SE80) ou simplesmente utilizar a SM30 para
manter a view V_TDEVC. Se for necessrio podemos manter a view v_tresn para associar os
namespaces com as development classes.

Esta associao de development classes e transport layers utilizada para definir as rotas de
transporte de consolidao que podem ser gerenciadas atravs do TMS. Objetos que no possuem

Pgina 69
ACADEMIA BASIS

esta associao ou no possuem transport layers configurados no podero ser transportados

Handling Repository Objects

O sistema possui dois mecanismos de lock para proteo dos objetos do repositrio. No primeiro
mecanismo baseado na gerencia do change request que garante que os objetos nele contidos
somente sejam alterados pelos usurios autorizados pelo gerente do change request que
consequentemente estejam trabalhando no projeto. Um segundo mecanismo no editor de programa
no permite que dois desenvolvedores abram o mesmo objeto simultaneamente pois quando o
primeiro desenvolvedor pegar o objeto o lock permanecer at o release da task. Objetos que tenham
sido associados manualmente ao change request no so lockados pelo sistema, mas podem ter lock
explcito tanto para a change quanto para a task atravs da SE09 ao selecionar Request/task ->
Object list -> Lock objects

Uma task s pode ser liberada pelo correspondente desenvolvedor associado a ele ou pelo dono
da change. J a change s pode ser liberada pelo seu dono e aps todas as task terem sido
liberadas. Ao trmino das tasks e liberao do change request (release), as alteraes ficam
disponveis para transporte (se a change for do tipo transportable). Este processo somente poder ser
executado pelo owner do change request e tenha as autorizaes corretas. Tasks liberadas no
podem mais ser alteradas porm tasks adicionais podero ser criadas para corrigir eventuais
problemas. Tasks vazias no podem ser deletadas mas so automaticamente eliminadas quando se
libera o change request.

O processo de release do change request grava uma nova verso dos objetos no repositrio e
exporta as alteraes para arquivos no sistema operacional (diretrio de transporte). Change requests
locais quando liberados gravam novas verses no repositrio porm no geram arquivos no sistema

As verses dos objetos geradas quando da liberao dos change requests ficam
armazenadas no version database, que reside no sistema de desenvolvimento. Os objetos ativos
ou suas verses temporrias (sob manuteno) residem em outro local, no development database.
As verses dos objetos podem ser comparadas ou restauradas atravs de ferramentas do sistema,
seja pela SE80 ou pela SE09. O nico sistema que contm o histrico de todas as verses o
sistema de desenvolvimento. Na produo no teremos este histrico o que significa se perdermos o
sistema de desenvolvimento perderemos toda a histria da evoluo dos abaps.

Quando um change request liberado o sistema exporta seus dados para o sistema operacional e
este processo pode ser acompanhado atravs da SE09 que exibe o return code da operao e uma
log do export para possvel anlise. A lgica do nome do arquivo de log do export <SID>E9xxxxx.
Tambm produzido uma log do test import no sistema de consolidao seguindo o padro
<SID>P9xxxxx para o nome do arquivo. Ento, a partir do release da change request, ela passa a ser

The Repository

O Object Directory um catlogo de todos os objetos standard SAP e dos objetos desenvolvidos
pelo usurio na sua instalao e pode ser acessado pela SM30 tabela TADIR. Durante o processo de
customizing o sistema pode gerar automaticamente objetos dentro do repositrio como parte do
processo. Objetos que so alterados fora do seu ponto de origem, por exemplo a alterao no
ambiente de QAS de um objeto originrio do sistema de desenvolvimento denominado um repair.
Os objetos do repositrio possuem como chave primria o program identification (PGMID), o object
type e o object name. O campo PGMID normalmente R3TR, embora existam outros ids: R3OB e
LIMU. Object types podem ser por exemplo PROG (ABAPs), DEVC (development class), VIEW,
FORM, COMM (command file) e CHD0 (change document).

O sistema R/3 trabalha com o conceito de objetos originais e cpias. Um objeto criado no
ambiente de desenvolvimento e transportado para os demais ambientes do landscape possuir
nestes locais apenas uma cpia do objeto original. Este mecanismo garante que os objetos sejam
alterados apenas nos locais onde foram criados. Excepcionalmente possvel alterar uma cpia

Pgina 70
ACADEMIA BASIS

de um objeto, que neste caso denominado de um repair, ou seja: uma alterao executada em um
ambiente diferente daquele onde o objeto foi desenvolvido.

Diferentemente dos developments e corrections, que so manutenes de objetos originais, os

repairs quando associados a tasks de um change request no permitem que outros
desenvolvedores do mesmo time tenham acesso ao objeto, mas que so, assim como os objetos das
demais tasks, protegidos por mecanismo de lock. Quando um repair liberado o sistema requisita
uma confirmao que retira o lock de proteo do objeto e permite que o mesmo seja posteriormente
sobrescrito por transportes futuros. Repairs liberados sem confirmao podem entretanto ser
confirmados a posteriori atravs da opo Request/task -> Confirm repair

Diferentemente das alteraes e desenvolvimentos de objetos criados pelo usurio, Modifications

so na realidade repairs executados em nossa instalao sobre as cpias dos objetos originais
SAP. Estes objetos para serem alterados ser necessrio informar um access key (obtido no OSS)
que associado ao objeto em uma determinada instalao. Este procedimento de registro fica
gravado na SAP que uma determinada instalao efetuou alteraes sobre objetos standard SAP.
Uma vez definido o access key, o objeto associado a uma task do change request como um repair,
sendo tratado como tal da para a frente. Nem todos os objetos SAP do repositrio so controlados
por este mecanismo rgido de SSCR (access key): matchcodes, database indexes, buffer settings,
customer objects, precorrections e objetos gerados pelo customizing. Este mecanismo vai permitir
que a SAP procure inicialmente por alteraes introduzidas pelo usurio no seu ambiente
diferenciando potenciais erros de programa de manutenes indevidas de objetos, alm do que o
registro facilita os processos de upgrade de verses

R/3 Upgrade

Quando de um upgrade, objetos originais SAP so reintroduzidos na instalao o que fora a uma
anlise obrigatria dos objetos que sofreram repairs para que as antigas alteraes sejam
confirmadas e refeitas quando necessrio. Para isto importante uma documentao detalhada
destas modifications e a deciso de que se vale a pena o esforo para reintroduzir as alteraes que
muito possivelmente j esto incorporadas no novo release

Durante a fase de PREPARE do processo de upgrade, o sistema pede que todos os repairs sejam
confirmados e liberados. A transao SPDD dever ser utilizada para ajustar o dicionrio ABAP
durante o processo de upgrade. A transao SPAU utilizada para efetuar um merge de todos os
objetos do repositrio

Workbench Organizer Tools

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

Settings for WBO

O workbench organizer possui uma facilidade para verificao das logs de transportes e para
verificao dos objetos incluidos nas change requests. Isto pode ser feito para todo o sistema ou
especificamente para um usurio. Quem controla isso so os object checks que permitem verificar a
integridade (normalmente syntax check) das alteraes efetuadas pelo change request antes que ele
seja liberado e exportado para files do sistema operacional. Eles permitem tambm que sempre que
for feito uma operao de import/export o usurio recebe uma mensagem no prximo logon.

Pgina 71
ACADEMIA BASIS

Para configurar este recurso para todo o sistema utilize a transao SE01 -> settings -> organizer
e para configurar este recurso para um usurio especifico use a SE03 -> global customizing
workbench organizer.

Planning Change Management

Um sistema R/3 necessita de uma soluo de procedimento para controlar o processo de

alterao e propagao destas alteraes por todo o landscape. Para isto no podemos esquecer de

Restringir as alteraes no repositrio do R/3 atravs de uma poltica bem definida de

autorizaes, pela proteo dos clients atravs da especificao correta de seus change
options (SCC4) e ainda centralizando todo o desenvolvimento em um nico sistema R/3.
A definio de times de projetos bem definidos com a especificao de um lder
responsvel que deve organizar o mecanismo de gerncia de tasks e change requests e
controlar a qualidade do processo dos desenvolvedores.
A definio de padres de desenvolvimentos, seja atravs da especificao de classes de
desenvolvimento, da padronizao e cobrana de uma correta documentao e a
manuteno de verses para simplificar os futuros esforos de upgrade do sistema R/3 ou
da aplicao de correes via Hot Packages

Pgina 72
ACADEMIA BASIS

Change Management for Customizing

Customizing Concepts

Customizing o processo de parametrizao do R/3 de acordo com o processo de negcio que

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

Customizing Tools Implementation Guide (IMG)

A SAP prov diferentes ferramentas para a implementao das customizaes e para o

desenvolvimento no R/3. Comparativamente:
Workbench Organizer (SE09) utilizado pelos desenvolvedores ABAP para criar e
gerenciar seus change requests do tipo SYST que podem ser liberados para transporte no
landscape.
Customizing Organizer (SE10) a transao utilizada pelos customizadores para criar e
gerenciar seus change requests do tipo CUST SYST que podem ser liberados para transporte
no landscape. Esta ferramenta mais ampla que a SE09 pois ela pode englobar as change
requests dos dois tipos.
ABAP Development Workbench (SE38) utilizado pelos desenvolvedores para acessar as
ferramentas necessrias para todo o ciclo de desenvolvimento de enhancements,
modifications e developments. Outra boa ferramenta que pode ser utilizada ao invs desta a
SE80 (Repository browser)
Implementation Guide ou IMG (SPRO) a transao da principal ferramenta de
customizao disponvel no R/3, onde apresentada uma lista hierrquica dos passos que
devero ser implementados no processo de customizao e implantao de um sistema R/3.

Enquanto um processo tpico de desenvolvimento requer a alterao e criao de objetos no

dicionrio, um processo de customizao implementado pela entrada e alterao de valores em
campos de tabelas do R/3. Os dois processos geram change requests, porm de categorias
diferentes (SYST e CUST respectivamente). Tecnicamente o processo de desenvolvimento mais
complexo que o de customizao, j que existe a necessidade de um gerenciamento mais rgido
atravs do registro de desenvolvedores no SSCR, do conceito de version dos objetos e da utilizao
de classes de desenvolvimento.

O R/3 disponibilizado com o set completo das atividades de customizao para todos os seus
mdulos no IMG, denominado SAP Reference IMG. Os clientes definem os mdulos que sero
implementados na empresa bem como as funes especficas que sero utilizadas dentro destes
mdulos, com isto teremos o Enterprise IMG. Todas as transaes de customizao relevantes,
documentao necessria e informaes para gerenciamento dos projetos so definidos dentro do
IMG atravs de subsets conhecidos como Project IMGs. Estes projects so levantados a partir das
definies iniciais de implementao do cliente.

O IMG e seus respectivos projects so definies client independents em um sistema R/3. O IMG
no apenas uma ferramenta de implementao da customizao no R/3. Atravs documentaes,
conceitos e gerenciamento de projetos o IMG a metodologia para customizao do R/3. A
implementao incorpora as seguintes partes:
acesso as Activities de implementao executado atravs de transaes prprias

Pgina 73
ACADEMIA BASIS

IMG Description descreve os conceitos, recomendaes, requerimentos e as atividades

necessrias para executar as tarefas
Project Management permite o acompanhamento do processo atravs do controle de status,
scheduling e gerncia dos recursos
Project Documentation para a documentao de todo o processo

Customizing Change Requests

As customizaes executadas no IMG podem ser gravadas em change requests o que permite
distribuir posteriormente um processo centralizado de customizao para os demais clients e
sistemas do landscape. Durante o processo de customizao, o client pode ser configurado para
requisitar ao customizador um change request para onde todas as alteraes sero gravadas
automaticamente para posterior transporte. Quando esta opo est desligada, as configuraes
executadas so gravadas no R/3 porm no so gravadas em change requests. Alm dos controles
globais de changes que os sistemas R/3 possuem implementados e configurados atravs da SE09,
os chamados global settings, um sistema R/3 possui a facilidade de se configurar individualmente
seus clients atravs da especificao detalhada de seus atributos client dependents e independents.

SCC4) permite a definio de dois subsets de

atributos que so gravados na tabela T000 e fornece a diretriz maior para o funcionamento dos
clients. No subset das client dependents, as change options determinam e protegem o sistema das
customizaes client dependents:
1. Changes without automatic recording, permite customizaes client dependents mas
no as inclui em change requests. Se desejado pelo customizador, as alteraes devero
ser includas manualmente em change requests para posterior transport
2. Automatic recording of changes, permite customizaes nas tabelas que so
automaticamente gravadas em change requests
3. No changes allowed, bloqueia as customizaes no client
4. No transport allowed, permite as alteraes nas tabelas mas impede que as changes
sejam transportadas, seja manual ou automaticamente

No subset das client independents, as change options protegem o repositrio e as customizaes

client dependents:
A. Changes to repository and client-independent, permite o desenvolvimento e
customizaes client independents
B. No changes to client-independent customizing objects, permite desenvolvimento mas
bloqueia as customizaes client independents
C. No changes to repository objects, bloqueia o desenvolvimento mas permite as
customizaes client independents
D. No changes to repository and client-independent custom. obj., impede o
desenvolvimento e customizaes client independents

A combinao destas opes permite que se configure diversos perfis de clients em uma

3.D. para um client de produo

2.B. para um client de desenvolvimento ABAP
2.C. para um client de customizao
2.A. para um client de desenvolvimento ABAP e customizao
3.D. para um client de teste
4.D. para um client sandbox

Quando a opo de automatic recording no est ligada, as customizaes podero ser gravadas
manualmente no change request. Ao entrar na transao de customizao deve-se usar a opo de
menu (Table/view -> Transport) para fornecer o change request. Aps selecionar todas as entradas
de customizao que desejam inclur, click em Include in Transport e depois basta salvar a
alterao e sair do IMG.

O processo de liberao de um change request de customizing pela SE10 pode ser efetuado de
duas maneiras distintas: no primeiro mtodo (release and export) a change liberada e seus dados
transferidos para os files do diretrio de transporte. No segundo mtodo (release to request) a change

Pgina 74
ACADEMIA BASIS

liberada porm seus dados so transferidos para um outro change request transportvel porm
seus dados no so transportados para o OS.

Customizing Tests

Antes de distribuir as customizaes, elas devero ser testadas em separado e dentro do contexto
do sistema, em um client de consolidao. preciso abrir o change request e verificar se o seu
contedo est completo com todas as alteraes. A transao SCC1 utilizada para transferir as
alteraes contidas em um change request ou mesmo em uma task individual para outro client do
sistema. No caso de ser necessrio levar objetos que esto apenas nas task o flag Incl tasks for
request deve estar marcado. Como apenas um change request pode ser transferido por vez, as
change podem ser agrupadas em um nico change atravs da opo Include Objects da SE10, o que

IMPORTANTE: a opo de cpia atravs da SCC1 somente funciona para dados client
dependents. Se a change contiver objetos client independents os mesmos no sero transportados. A
transao SCC1 deve ser sempre acionada no client de destino.

Customizing Exceptions

Certos tipos de customizaes, conhecidas como Data-only Customizing Changes, precisam ser
executadas diretamente no ambiente de produo sem passar por processo de change request,
como por exemplo: taxas de cmbio, regras de penso, etc. Estes tipos de alteraes no tem efeito
sobre o negcio da empresa no necessitando portanto de testes extensivos em ambiente separado.
Como so passveis de alteraes constantes e para evitar necessidades de controle por change
requests, a SAP introduziu o conceito de funes de Update Settings. Os Update Settings podem ser
utilizados diretamente no ambiente de produo sem impacto para o negcio da empresa. A tabela
CUSAMEN mantm a lista dos objetos aprovados pela SAP para esta funcionalidade. No se
recomenda que o cliente faa alteraes nesta tabela sem a autorizao expressa da SAP.

Client-independent Customizing

Uma tarefa difcil no proceso de customizao do R/3 identificar quais tasks so client
independents e quais so dependents. Customizaes client independents podem ser:
Em objetos client independents, que so objetos do repositrio gerados pelo processo
de customizao, como por exemplo matchcodes, condition tables e hierarquias. Para
garantir que sejam corretamente transportados, devero ser associados a uma
development class
Global customizings, que so configuraes standard globais do ambiente em tabelas
que no possuem o campo MANDT, como por exemplo calendrios, impressoras, etc.

Enquanto customizaes client dependents so gravadas em change requests da SE10, as

customizaes client independents precisam ser associadas a change requests do workbench
organizer (SE09). Uma boa forma de descobrir se a configurao dependent ou independent ou
transportada automaticamente, manualmente ou no transportada utilize a SPRO -> IMG ->
Information -> Title and IMG info.

Planning Customizing Change Management

importante restringir as alteraes no Enterprise IMG atravs de uma poltica bem definida de
autorizaes, pela proteo dos clients atravs da especificao correta de seus change options
(SCC4) e ainda centralizando todo o desenvolvimento (abap e customizaes) em um nico client.

A definio de times de projetos bem definidos com a especificao de um lder responsvel

organiza o mecanismo de gerncia de tasks e change requests

Pgina 75
ACADEMIA BASIS

A definio de padres de desenvolvimentos seja atravs da especificao de classes de

desenvolvimento ou da padronizao e cobrana de uma correta documentao e a manuteno de
verses simplifica os futuros esforos de upgrade do sistema R/3 ou da aplicao de correes via
Hot Packages

Pgina 76
ACADEMIA BASIS

Transport Management

Transport Process

O TMS a ferramenta existente no R/3 onde esto centralizados todos os recursos para efetuar e
gerenciar os transportes no ambiente. At o release 3.1H os transportes eram efetuados atravs de
ferramentas no sistema operacional e baseava-se nas configuraes das tabelas TSYST, TWSYS,
TASYS e DEVL principalmente.

O primeiro passo no processo de transporte o release dos change requests que so

exportados para files do diretrio comum de transporte (\\hostgroup\sapmnt\trans). Para cada
change liberado, arquivos so gerados nos subdiretrios data (dados exportados) e cofiles (control
files). Este diretrio de transporte tambm possui um subdiretrio buffer que contm um import buffer
file para cada sistema que compartilha aquele transport group. Cada change liberado acrescenta uma
entrada neste file de forma que ele conter informaes sobre os transportes que esto disponveis
para import e a seqncia de importao. Esta informao acessada no TMS atravs da facilidade
das import queues

A rota de consolidao nas quais os transportes so liberados normalmente especifica um sistema

de quality assurance para validao das changes. Quando se efetua o import do transporte para este
sistema QAS, o sistema coloca as entradas no import buffer do sistema de delivery, normalmente o
PRD, ou algum outro especificado no TMS. O processo de validao no sistema QAS poder detectar
erros que sero corrigidos no DEV e novamente transportados para consolidao. A fila de import do
sistema PRD poder ento conter mais um import que dever ser efetuado.

Um ciclo de alterao poder conter um ou mais change requests, dependendo da necessidade

de correo aps os testes no QAS. Quando finalmente o processo estiver pronto para import no
delivery (PRD), o TMS permite que toda a fila de import seja efetuada carregando o sistema de
produo com a verso final do objeto. Para o correto funcionamento deste mecanismo
imprescindvel garantir que os transports sejam importados na correta seqncia.

Import Queues

A ferramenta mais importante para o mecanismo de import do TMS so as import queues que
refletem a situao dos import buffers de um determinado sistema. Ela lista os change requests
disponveis para import bem como a ordem com que foram liberados. Os dados exibidos no TMS so
lidos no momento em que a transao chamada. A opo de refresh permite atualizar as
informaes exibidas na tela. O programa RSTMSCOL pode ser schedulado para rodar de hora em
hora e efetuar este refresh em background. Isto normalmente utilizado durante a fase de
desenvolvimento do projeto onde o numero de change requests muito grande. Durante a
manuteno do sistema normalmente no utilizado pois o nmero de changes provavelmente ser
bem menor.

Atravs da administrao da fila de imports possvel excluir change requests, efetuar forwards
para outros sistemas, estabelecer dead lines e end marks, etc. A administrao do TMS permite muita
liberdade no tratamento das filas, porm recomendvel que estas manipulaes sejam bastante
conscientes para garantir a integridade e consistncia dos transportes. A SAP um pouco mais forte
que a vida real, ela recomenda que nenhuma change seja deletada ou manipulada na fila para evitar
qualquer tipo de consistncia. Para estabelecer end marks nas filas de import necessrio fechar
(close) nas filas. Este processo eqivale a estabelecer stopmarks nos files do sistema operacional (tp
setstopmark <SID>). A diferena bsica que enquanto no sistema operacional possvel
acrescentar uma stopmark apenas no final da fila, atravs do TMS possvel colocar o end mark
onde for mais conveniente. Este processo muito til quando desejado disparar um import em
bloco porm at um determinado ponto apenas. O import all (caminho) efetua o import at encontrar
a marca postada na fila. Operacionalmente recomendvel que sempre se feche a fila (end mark)
antes de iniciar um import, evitando que requests liberados durante o processo tambm sejam
transportados inadvertidamente.

Pgina 77
ACADEMIA BASIS

Para evitar inconsistncias entre change requests, somente efetue imports de changes isolados
quando, com completa certeza, conhecer o seu contedo e sua dos demais requests.
Estes imports so denominados Preliminary imports. Como garantia, o TMS mantm os preliminary
imports na fila para que sejam retransportados quando se efetuar o import padro (all). Em condies
especiais possvel especificar parmetros diferentes quando do import. So as
comando tp no sistema operacional. Este processo chamado expert mode. Existem uma srie de
opes nos expert modes e elas sero detalhadas mas adiante.

Transporting Between Transport Groups

Transporte so gravados nas import queues de um determinado transport group que compartilha o
mesmo diretrio de transporte. A opo In foreign groups (Extras -> Other requests -> In foreign
groups) permite que se efetue transporte entre sistemas que possuem diferentes diretrios de
transporte. Esta opo til quando o compartilhamento NFS dos sistemas no permitido por
alguma razo tcnica (conexo ruim, segurana, compatibilidade, etc.). Neste caso o TMS cuida de
sincronizar as informaes entre os buffers do grupo de origem e do o grupo de destino.

Transport Monitoring

possvel monitorar o processo de transporte atravs de uma srie de ferramentas do Import

Monitor do TMS. O sistema permite ainda que se verifique a consistncia dos arquivos no sistema
operacional (Consistency check) e o return code produzido por cada transporte atravs da
visualizao da ALOG. O TMS tem ainda ferramentas para testar as funcionalidades do tp program e
ainda verificar a configurao do diretrio de transporte (System check) alm do funcionamento das
conexes RFC com os sistemas que compem o landscape.

Atravs do Alert Monitor do CCMS possvel integrar algumas funes de monitorao com o
TMS permitindo a gerncia centralizada do sistema R/3.

Transport Process

O processo de transporte pode ser descrito nos seguintes passos:

O lder do projeto libera o change request aps verificar o trmino das tasks com os
integrantes do grupo de trabalho
O lder verifica ainda se o export foi realizado com sucesso informando ao administrador do
sistema qualquer anormalidade
O administrador importa o change request no sistema de consolidao e garante a execuo
correta do processo com return codes aceitaveis.
O time funcional garante os testes exaustivos no ambiente de consolidao. Qualquer
problema detectado dever ser informado ao lder do projeto para que se inicie a correo e
repita o export de uma nova correo para o sistema de consolidao
O administrador do sistema efetua o import para o ambiente de delivery e demais sistemas
configurados do conjunto consistente de change requests no landscape e garante a execuo
correta do processo com a devida verificao dos return codes.

Durante o processo de testes de uma funcionalidade pode ser necessrio congelar o trabalho no
ambiente de desenvolvimento para garantir a estabilidade dos testes. Isto facilita a correo de
possveis problemas encontrados nos objetos, que seria mais difcil de ser corrigido se o processo de
desenvolvimento tivesse continuado no objeto durante os testes.

Uma estratgia peridica para a importao dos transportes dever ser implementada e negociada
com as equipes de desenvolvimento. Import all devero ocorrer mensalmente, semanalmente ou
diariamente. Imports mais freqentes no so recomendados no ambiente R/3. O processo de import
deve ser feito durante a baixa atividade do sistema e logo aps um backup da base. A SAP
recomenda que o transporte de um projeto seja efetuado apenas quando todos os seus componentes
estiverem totalmente desenvolvidos evitando a estratgia de enviar objetos individualmente a medida

Pgina 78
ACADEMIA BASIS

Advanced Transport Management

Transport Directory

Os change requests so gerados obedecendo a nomenclatura <source SID>K9nnnnn onde nnnnn

um seqencial de 5 dgitos controlado pelo sistema source (tambm conhecido como sistema
integrador ou sistema de desenvolvimento e configurao).

O file system do diretrio de transporte fica montado na rea compartilhada /usr/sap/trans de uma
das mquinas (normalmente aquela de onde os transportes se originam) e atravs de NFS, o file
system compartilhado com os demais sistemas que compartilham o mesmo transport group. No
ambiente do NT o compartilhamento feito atravs do sapmnt que contm, entre outros, o diretrio
trans contm os seguintes subdiretrios, entre outros:
actlog, onde so gravados cada action em um request ou task. Contm files com nomes
<source SID>Z<6 digits>
sapnames, com arquivos com o nome do usurio que efetuam release em changes. Com
este arquivo podemos saber exatamente que gerou a request (no sistema operacional)
buffer, com arquivo com nome <SID> contendo o import buffer para cada sistema R/3.
Quando um change request liberado, o file correspondente ao sistema target atualizado
data, contendo arquivos do tipo R9<5 digits>.<source SID> que contm os dados que
foram exportados no transporte. Eventualmente neste diretrio podemos ter arquivos no
formato D9<5 digits>.<source SID> que tambm contm dados a serem importados.
cofiles, com command files do tipo K9<5digits>.<source SID> contendo por exemplo os
import steps que sero executados
log, com todas as logs de transportes, como por exemplo ULOGs, ALOGs, SLOGs e as
demais logs que descrevem as operaes executadas nos steps individuais ou coletivos
bin, com os arquivos de configurao do funcionamento do mecanismo de transportes
(TPPARAM e DOMAIN.CFG)
tmp, com os arquivos de log que esto sendo gerados durante o processo. Aps o trmino
de um transporte os arquivos so movimentados para o diretrio LOG.

The tp Program

O transport control program uma ferramenta executada a nvel de sistema operacional que
controla todas as operaes de transporte no sistema R/3 usando programas especiais (por exemplo
em C), comandos de sistema operacional e programas ABAP no R/3. O TP opera as operaes de
export e import separadamente, extraindo/atualizando as informaes de controle na base de dados
do R/3 e levando para files (buffer, log e cofiles) no diretrio de transporte e posteriormente, atravs
de comando explcito, importa os dados no sistema destino. Ele no faz a manipulao dos dados
que sero transportados (o responsvel por isso o R3trans que ser visto a seguir).

Apesar de ser uma ferramenta no sistema operacional (diretrio de exes), o tp deve ser utilizado
atravs da interface do TMS que efetua as chamadas apropriadas para cada tarefa. Sua utilizao
uma chamada tp <command> [argumento] [option(s)] como pode ser visto abaixo :
tp help, exibe o help do tp
tp <command>, exibe o help de um comando especfico
tp go <SID>, checa o database de um sistema destino
tp connect <SID>, checa a conexo
tp showinfo <request>, exibe informaes de um determinado change request
tp count <SID>, numera os requests para import em um sistema
tp checkimpdp <SID>, exibe como o RDDIMPDP est schedulado em um determinado
sistema
tp showparams <SID>, exibe a parametrizao atual de um sistema
tp status <SID>, exibe o status de serializao de um sistema
O comando tp import all <SID> client=nnn executa o import de toda a fila de transporte do
sistema <SID> no client nnn. Este o comando normalmente emitido pelo TMS.

Pgina 79
ACADEMIA BASIS

O comando tp import <request> <SID> client=nnn u0 executa o import de um request especfico

e o mantm na fila, eqivalendo ao preliminary import do TMS. Quando se suprime a opo u0 o
request retirado da fila de import. preciso tomar cuidado com imports individuais para garantir a
manuteno da seqncia correta com que os mesmo foram exportados.

O import mode incondicional (com especificao da opo ) tem os seguintes modos:

u0, importa o buffer sem deletar o request da fila
u1, ignora se o request j havia sido importado
u2, sobrescreve os originais
u3, sobrescreve objetos especficos do sistema
u6, sobrescreve objetos em modo unconfirmed
u8, ignora restries estabelecidas na tabela de classificaes
u9, ignora o fato do sistema estar lockado para este tipo de transporte

O buffer de um determinado <SID> manipulado pelos comandos tp especficos, como por

exemplo addtobuffer, showbuffer, delfrombuffer, cleanbuffer, setstopmark e delstopmark. Estes
comandos manipulam as linhas do arquivo especfico de cada sistema existente no subdiretrio buffer

The R3trans Program

O R3trans a ferramenta de transporte que efetivamente efetua os transportes no sistema R/3,

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

The ABAP Programs

Durante os steps de um processo de import de um transporte alguns programas ABAP so

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

The Import Process

O processo de import composto de uma srie de steps que executam tarefas distintas e,
dependendo do tipo do transporte, so ativados ou no. A organizao da fila de import no buffer file
uma espcie de tabela onde para cada entrada referente aos requests, colocado um flag 0 ou 1
na posio referente a cada step. O programa tp no l esta fila individualmente, mas sim
coletivamente. Desta forma o processo de import ocorre de forma seqencial no pelos requests, mas
sim pelos steps. Desta forma o sistema executa o step 1 para todos os requests que o requisitaram,
depois o step 2 e assim sucessivamente. Este processo garante por exemplo que caso exista na fila
de transporte mais de uma referncia a um determinado objeto (por exemplo a segunda corrigindo um
erro detectado em uma primeira consolidao) o step de ativao (posterior ao de importao) ocorra

Pgina 80
ACADEMIA BASIS

somente quando a verso correta esteja importada no sistema, evitando desta forma que a verso
com erro seja ativada temporariamente como ocorreria se o processo fosse seqencial por request.

Para garantir a consistncia do tratamento da fila de import, o programa tp coloca

automaticamente um setstopmark na fila no incio do processo e a retira no final. Cada operao
efetuada durante o processo logada pelo tp com o respectivo return code nos arquivos de log do
sistema de transporte. Ocorrendo erros no processo o programa tp interrompe e aps a correo pelo
administrador, um restart faz com que o tp encontre o ponto de parada e recomece o processo a
partir daquele ponto. Qualquer return code maior que 8 interrompe o programa tp. Este valor
entretanto pode ser configurado no arquivo TPPARAM (atravs do parmetro stoponerror)

Os passos durante o import so (os passos com * so genricos e feitos em todas as requests) :
DDIC
Abap dictionary import
ACTIV
Abap dictionary activation
Distribution
Structure conversion (*)
Move nametabs (*)
MAIN
Main import
MC ACT
Activation of the enqueue definitions
MC CONV
Enqueue conversion (*)
ADO
Import of application defined objects ADOs
LOG
Logical import (esta fase ainda no foi implementada e ser utilizada para a importao
em um shadow client antes de fazer em um target client)
VERS
Versioning
XPRA
Execution of user defined activities
GENERA
Generation of abap prograns and screens

Communication During Imports

O programa R3trans, que chamado durante as fases de ABAP dictionary e main import) se
comunica com o programa tp utilizando o subdiretrio tmp. Um control file passado pelo tp para
cada step do processo de import e por sua vez o R3trans grava a log do transporte no tmp para que
posteriormente seja transferido pelo tp para o subdiretrio log. A comunicao entre o programa tp e
os jobs background no sistema se d atravs da tabela TRBAT que contm dados temporrios. O tp
grava nesta tabela os steps que devero ser executados durante o import e ento dispara o evento
que ativa o RDDIMPDP. Este programa por sua vez l a tabela e atravs das informaes recolhidas
dispara programas RDD* que efetuam tarefas especficas requisitadas pelo tp. Cada um dos jobs
RDDs disparados pelo RDDIMPDP registrado na tabela TRJOB atravs de uma entrada onde so
gravados seus return codes que desta forma podem ser acompanhados pelo programa tp. As logs
geradas pelos programas RDD* so gravadas no subdiretrio tmp e posteriormente transferidas para
o log pelo programa tp.

Qualquer problema detectado pelo tp durante a monitorao das tabelas TRBAT e TRJOB faz
com que o tp reative o RDDIMPDP atravs da emisso de novo evento pelo sapevt. O RDDIMPDP
analisa estas tabelas e verifica se o processo anterior ainda est ativo ou se necessrio,
processo no step cancelado. Por este motivo que pelo menos dois background process
precisam estar disponveis para o sistema de transporte.

Pgina 81
ACADEMIA BASIS

Transport Monitoring

Todas as logs do processo de transporte so gravadas no subdiretrio de log. So logs criadas

pelo tp program (ULOG, SLOGs e ALOG) e pelas demais ferramentas de transporte. A ULOG contm
todos os comandos tp sem erros de sintaxe. Cada linha representa um comando. Existe um arquivo
SLOG<YY><WW>.<SID> para cada sistema R/3 do landscape e usado para monitorar as
atividades de transporte de um sistema especfico. Contm uma viso geral dos imports efetuados
indicando os respectivos return codes e consequentemente o sucesso de cada import. O
ALOG<YY><WW> contm todos os return codes de cada um dos steps executados nos processos de
import efetuados no seu transport group.

Alm destes arquivos de log, o diretrio de logs possui uma log por change request. Estes
arquivos possuem o formato <source SID><action>9<5digits>.<target SID> onde o action pode ser :
E de main export feito pelo R3trans
P de test import feito pelo R3trans
H de dd import objects feito pelo R3trans
A de dd activiation object feito pelo RDDMASGL
S de dd distribution object feito pelo RDDGENBB
N de dd conversion object feito pelo RDDGENBB
6 de dd move nametabs
I de main import feito pelo R3trans
T de import of table entries feito pelo R3trans
M de enqueue activation feito pelo RDDGENBB
G de repository object generation feito pelo RDDIC03L
V de version update feito pelo RDDIC

As diversas ferramentas envolvidas no transporte envia return codes que so consolidados pelo
programa tp da seguinte forma:
0 a 16, indica os valores mximos de todos os return codes das ferramentas
17 a 99, que um valor calculado a partir daqueles retornados pelas ferramentas de
transporte e so warnings indicando problemas detectados pelo tp, como por exemplo a
no permisso de write no diretrio buffer
100 a 149, so warnings indicando que alguma coisa vai mal e nem todas as tarefas
puderam ser completadas
150 a 199, so erros (raros de acontecer) indicando uma operao ilegal solicitada pelo
operador
200 ou mais, indica erros no tp
Para obter uma descrio de um return code, utilize o comando tp explainrc <rc>.

Para acompanhar todo o processo verifique as logs dos transportes que foram feitos. As logs de
transporte podem ser visualizadas atravs do Alert Monitor sob a forma de uma estrutura em rvore
que pode sofrer drill down.

O diretrio de transporte deve ser limpo de tempos em tempos para eliminar transportes antigos e
tp check all varre os diretrios de transporte e os
arquivos referentes a transportes j executados so gravados em um arquivo denominado
ALL_OLD.LIS no tmp. O comando tp clearold all l o arquivo gerado pelo comando tp check all e
percorre os arquivos referentes as suas entradas e elimina aqueles que aparentemente no sero
mais necessrios e se tornaram obsoletos baseados em timestamps definidos pelos
datalifetime, olddatalifetime, filelifetime e loglifetime do TPPARAM. Antes de efetuar esta
operao recomendado que se efetue uma cpia backup por segurana.

Pgina 82
ACADEMIA BASIS

Client Tools
As ferramentas de client copy e client transport foram criadas para executar a transferncia de
dados entre clients. Estes dados sobrepem os dados do client destino. As ferramentas de client no
foram concebidas para combinar dados de vrios clients. Os dados so categorizados como dados de
customizao, dados mestre de usurio ou ainda application data. Dentre estes somente o mestre de
usurios pode ser manipulado mais livremente e combinado com outros de outras fontes. No lado
oposto est o application data que no pode ser manipulado de forma alguma sem o correspondente

Os mecanismos de cpia permitem a cpia local, remot ou atravs de transporte. Cada um destes
possui uma caracterstica diferente. A cpia local utilizada para copiar clients dentro da mesma
instncia e no consegue copiar as customizaes client-independents e os objetos de repositrio. J
a cpia remota permite faz exatamente a mesma coisa s que entre sistemas R/3 diferentes e
utilizando conexes RFC. O transporte de client o mais abrangente, com ele podemos levar um
client de um sistema R/3 para outro, mesmo que o destino no esteja ativo no momento, e podemos

As ferramentas de transferncia de dado entre clients so definidas por profiles que definem o
escopo dos dados que sero transferidos. Por exemplo:
SAP_ALL, todos os dados do client
SAP_CUST, customizing data
SAP_CUSV, customizing e variantes de relatrio
SAP_UAPP, user master e reports
SAP_UCSV, user master, customizing e variantes
SAP_UCUS, user master e customizing
SAP_USER, user master

Quando a inteno a criao de um client novo, uma entrada dever ser criada inicialmente
atravs da transao SCC4. Clients recm criados possuem apenas o user SAP* hard coded
(password PASS) e atravs dele que efetuaremos a cpia

Clients protegidos contra cpia no podem ser sobrescritos. Esta proteo especificada na
SCC4. Por questes de integridade, recomendado que no se log no client destino durante a cpia.
Pela mesma razo recomendado que no se utilize o client source durante o processo

Local Client Copy

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

Remote Client Copy

A cpia remota permite a transferncia dos dados entre clients de diferentes sistemas R/3 e, assim
como a local client copy, deve ser disparada estando-se logado no client destino e utiliza-se a
transao SCC9, especificando o sistema e client source e a profile de cpia. A cpia exatamente
igual a local, apenas que os dados so enviados atravs de uma conexo RFC. Para garantir o
sucesso da cpia, ambos os sistemas devero possuir a mesma estrutura de database. Qualquer
inconsistncia causa o trmino do processo com erro

Client Transport

Diferentemente do processo de cpia remota, a transferncia no executada por RFC, embora

este processo tambm permita a transferncia de dados entre sistemas distintos. O processo consiste
de dois steps: no primeiro os dados so exportados para files no sistema operacional e no segundo
estes dados so importados para o client destino.

Pgina 83
ACADEMIA BASIS

Diferentemente tambm dos dois outros processos, necessrio logar no client source e efetuar
atravs da transao SCC8 o export dos dados. Durante este processo necessrio especificar o
sistema target que dever compartilhar o mesmo transport domain. Por ser um processo demorado
dever ser schedulado em batckground. O processo de export de um client utiliza chamadas ao
programa tp e cria at 3 arquivos no sistema operacional: RTnnn com dados client dependent, ROnnn
com dados client independent e finalmente SXnnn contendo SAPscripts. Alm destes files o processo
cria arquivos na import queue (buffer) do sistema target (S-SID-KOnnn para independent e S-SID-
KTnnn para dependent data).

A segunda parte do processo, que a fase de import executada atravs da transao SCC7 que
comanda o import. Primeiro deve-se importar os dados client independent e posteriormente os client
dependent. Em seguida necessrio se logar no sistema target e executar o Post-process import
para efetuar atividades requeridas pelo SAPscript e possveis steps de gerao de objetos ainda
pendentes.

Copy Process
Durante o processo de cpia de client, o sistema inicialmente limpa os dados com a key do client
no sistema destino. Number ranges so copiados do cliente source. Se o dado de aplicao no for
copiado, o number range ser resetado. No possvel copiar dados de aplicao sem copiar junto
os dados de customizao e os number ranges. A cpia apenas dos dados de customizao pode
causar inconsistncias no momento do merge no client destino

A profile SAP_USER a nica que no possui a opo de Initialize and Recreate

O processo pode ser bastante demorado (dependendo do profile utilizado e volume de dados no
source) devendo o processo rodar em background process. Durante o processo de cpia o logon fica
inibido no client target exceto para os users SAP* e DDIC. ainda recomendado que no se trabalhe

O processo de cpia ir gerar entradas nas tabelas do banco de dados e consequentemente

exigir a disponibilidade de rea suficiente nos tablespaces do banco. As logs dos processos de
cpia visualizada atravs da transao SCC3 e exibe informaes sobre estatsticas das tabelas,
informaes de controle e informaes detalhadas sobre cada tabela copiada e suas interaes com
os objetos do IMG. Cpias de client pelo processo de client transport so monitoradas atravs da
SE01 (transport organizer)

A monitorao do processo de cpia permite, em caso de abend do processo, o restart a partir do

ponto em que ocorreu o problema. Esta opo pode ser utilizada aps uma anlise do problema
ocorrido, sendo mais eficiente que a opo de um new start.

Objetos do repositrio associadas a classe de desenvolvimento local ($TMP) no so copiadas

durante o processo de client copy.

Client Delete
Clients so deletados atravs da transao SCC5. O processo de cpia poder inclusive ser
agilizado se o client tiver sido anteriormente excludo do ambiente destino. No processo de delete os
dados, SAPscripts e batch inputs

Client Compare

Quando vrios sistemas R/3 com clients distintos esto sendo implementados, pode ser
necessrio comparar e ajustar as customizaes entre os diferentes sistemas e clents. A funo
Compare. Esta funo compare permite comparar e ajustar o contedo de tabelas ou vises entre
dois clients distintos. A transao SCUO utilizada para selecionar os tipos de objetos que sero
comparados e ainda especificar se a comparao ser de dados clint dependents ou independents. A
sada da comparao exibida de forma tabular e torna fcil a anlise das eventuais diferenas

Pgina 84
ACADEMIA BASIS

Eventuais ajustes podero ser efetuados atravs da transao SM30, que permite a manuteno
da maioria dos objetos de customizao. Objetos que no podem ser ajustados pela SM30 podero
apenas ser comparados.

Client Maintenance Settings

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

Authorizations for client tools

Para manipular as ferramentas de movimentao e manuteno de clients dispomos dos

seguintes objetos de autorizao :
S_TABU_CLI para manter a tabela de dados dependentes de um client
S_TABU_DIS para manter qualquer tipo de tabela
S_CLNT_IMP para fazer import de dados durante uma cpia
S_DATASET para acessar arquivos do sistema operacional
S_USER_PRO para manter as profiles de cpia
S_USER_GRP para manter os dados mestres de usurios
S_TRANSPRT para manipular o CTO (change and transporte organizer)

Pgina 85
ACADEMIA BASIS

Client and System Strategies

Types of Landscapes

Uma implementao R/3 pode ser executada de diversas maneiras distintas. As implementaes
mais comuns so sistemas R/3 em hardware diferentes e os possveis landscapes so os com 3, 2 ou
1 sistemas R/3:

Three-System Landscapes

No landscape com 3 sistemas temos os seguintes ambientes:

Development, contendo um client de customizao e desenvolvimento (CUST), e um client

Quality Assurance, contendo um client de consolidao e teste sistmico (QTST)

Production, contendo um client de produo (PROD)

Esta implementao apresenta as seguintes vantagens:

Desenvolvimento, qualidade e produo so implementados em ambientes distintos
Maior segurana dos dados no ambiente de produo
A performance do ambiente de produo no afetada pelos demais sistemas
Ambiente de teste separado
Consolidao dos transportes antes do envio para a produo
A principal desvantagem desta opo o alto custo do hardware em funo da quantidade de

Two-System Landscapes

No landscape com 2 sistemas temos os seguintes ambientes:

Development, contendo um client de customizao e desenvolvimento (CUST), um client
para testes unitrio (TEST) e um client de consolidao e teste sistmico (QTST)
Production, contendo um client de produo (PROD)

Esta implementao apresenta as seguintes vantagens:

Desenvolvimento e produo so implementados em ambientes distintos
Maior segurana dos dados no ambiente de produo
A performance do ambiente de produo no afetada pelos demais sistemas
Ambiente de teste separado
Administrao simplificada em funo da diminuio do hardware

Esta implementao apresenta as seguintes desvantagens:

Desenvolvimento e qualidade so implementados em um nico ambiente, ou seja, um
ambiente pode impactar o outro.
No possvel fazer um teste completo dos objetos do repositrio nem customizaes
client independents antes que sejam transportados para a produo, que age aqui como o

No possvel consolidar os transportes antes de envia-los para a produo

One-System Landscapes

No landscape com 1 sistema temos os seguintes clients:

Ambiente nico, contendo um client de customizao e desenvolvimento (CUST), um client
para testes unitrios (TEST) , um client de consolidao e teste sistmico (QTST) e um

Pgina 86
ACADEMIA BASIS

Esta implementao apresenta as seguintes vantagens:

Toda a implementao em apenas um hardware
Menor esforo de administrao, sem transporte de objetos do repositrio e customizaes
client independents

Esta implementao apresenta as seguintes desvantagens:

Desenvolvimento de objetos e customizaes client independent afetam imediatamente o

Um ambiente impacta todos os outros ambientes tanto em performance, quanto integridade

e segurana
Upgrade da produo realizado sem um teste das funcionalidades
Produo compartilha recursos de hardware com os demais ambientes com conseqncias
ruins para a performance

Como esta opo a mais precria e sucetivel a grandes impactos aps a entrada em produo
ela s aceitvel se os desenvolvimentos parassem antes da entrada em produo. Se for
necessrio fazer alguma correo no ambiente deve ser feito durante o perodo sem atividade
produtiva.

Landscape Requirements

preciso que se tenha uma estratgia consistente para configurao dos sistemas no landscape
para proteo dos repositrios e dos transportes consistentes entre os sistemas. Atravs de uma
configurao correta de clients para os ambientes de produo e qualidade, possvel bloquear
customizaes e desenvolvimentos fora do ambiente reservado para esta finalidade. A estratgia bem
montada de distribuio de transportes, atravs da especificao cuidadosa de rotas de consolidao
e distribio, e a definio de um ponto nico de alterao do ambiente (client de desenvolvimento)
garante assim que todos os clients do landscape tenham configuraes consistentes.

A configurao correta dos clients na SCC4 poder proteger produo e qualidade de

configuraes e desenvolvimento e ao mesmo tempo fora a gravao automtica em change
requests dos esforos de customizao e desenvolvimento ABAP. Alm disto um bom procedimento
e agendamento dos mecanismos de transportes junto com padres de nomeclatura ajudam a garantir
a estabilidade do ambiente.

ASAP System Landscape

A ASAP recomenda um roteiro passo a passo para configurao de um landscape de 3 sistemas,

dentro do ASAP Roadmap, que consolida as experincias tanto da SAP quanto dos seus parceiros

Passo 1: Aps a primeira instalao do sistema no ambiente de Desenvolvimento, utilizar o client

000 para, atravs de client copy, criar os clients de TEST e CUST.
TEST configurado como uma produo, com no changes allowed e No changes to
repository and client independent customizing.
CUST configurado para gravao automtica de change requests e permisso para
alterao do repositrio e client independent customizing

Passo 2: Estabelea uma estratgia de manter o CUST sem dados e qualquer teste dever ser
efetuado atravs do transporte das customizaes nele executadas para o client TEST atravs da
transao SCC1. Os transportes gerados no sistema CUST sero liberados para o diretrio de
transporte

Passo 3: Quando chegar a hora de criar o ambiente de consolidao, instale um sistema R/3 no
ambiente de qualidade e, a partir do client 000, crie os clients TRNG para treinamento e QTST para
qualidade. Ambos os sistemas estaro protegidos atravs das opes No changes allowed e No
changes to Repository and client independent customizing.

Pgina 87
ACADEMIA BASIS

Passo 4: Os transportes liberados no ambiente CUST e que se encontram na fila de import

devero ser importados para a o client QTST. Atravs da SCC1 os change requests podero
transferidos para a TRNG. Volumes muito grandes de change requests podem ser agrupados em um
nico change request ou simplismente podemos importar a fila no TRNG.

Passo 5: Instale um sistema R/3 no ambiente de produo e, a partir do client 000, faa um client
copy para criar o client PROD, que dever ser configurado para No changes allowed e No changes to
repository and client independent customizing. Em seguida import toda a fila de requests para o novo
client configurado.

A partir deste momento, qualquer change request liberado na CUST dever ser copiado para a
TEST utilizando a SCC1. Uma vez testado, o change ser importado para consolidao na QTST e
eventualmente transferido atravs da SCC1 para a TRNG. Changes consolidadas sero finalmente
importadas no ambiente de produo.

ASAP Recomendations

As change requestes e seus histricos devero estar muito bem documentadas no ambiente e
nenhuma alterao pode ser feita sem estar contida em uma change request. Documente o que
contm a request, o que resolvido, quem fez a alterao e quando foi transportada para cada um
dos ambientes. Tenha estabelecido desde o incio critrios bem definidos para regulamentar as
change e seus transportes entre as instncias com as respectivas rotas e a periodicidade do
transporte em cada uma das rotas. Distribua os transportes apenas quando eles contiverem uma
unidade completa de desenvolvimento ou customizao.

Evite fazer upgrade durante o processo de desenvolvimento. Se for impossvel, tenha certeza que
requests geradas em uma verso/nvel de hot package s sero transportadas para um ambiente
com a mesma verso/nvel de hot package.

Alternative Landscapes

Alternativamente, apenas o client CUST poder ser criado inicialmente com as opes de gerao
de change request desligadas. Quando se decide criar o sistema TEST no mesmo sistema, ele ser
gerado a partir de um client copy do CUST e a partir deste momento deveremos ligar a gerao
automtica de change requests, uma vez que a nica forma de sincronizar os dados client
independents daqui para a frente ser atravs da movimentao dos changes via SCC1. A criao do
client de qualidade (QTST) feita atravs de um client export/import, assim como o produo. A
principal vantagem deste mtodo alternativo que a gerao de transportes somente precisa ser
ativada e gerenciada quando acrescentamos um segundo client no landscape. A desvantagem que
no possuiremos o histrico completo das change e, principalmente, quando do momento dos client
export dados de customizao ainda no totalmente consolidados estaro sendo movimentados para
os demais ambientes. Alm disto devemos ter cuidado em relao a objetos do repositrio pois eles
no estaro presentes na cpia do client. Para solucionar isto temos que ter todos os objetos
alterados documentados para ser possvel gerar uma request que dever ser transportada antes do
client import.

Uma terceira opo a criao dos ambientes de QAS e PRD a partir de homogeneous system
copy, embora esta estratgia no seja recomendada pela SAP. As principais desvantagens esto
associadas a falta de controle das request e a eventual presena de configuraes e
desenvolvimentos no acabados no ambiente produtivo.

Atravs da configurao do TMS e suas rotas de consolidao e distribuio possvel definir os

mais complexos cenrios que possamos necessitar na instalao. As rotas de distribuio (delivery)
podem ser paralelas para vrias instncias ou ainda em cascata, dependendo da configurao TMS.

Uma implementao Phased Development necessria em algumas situaes especiais, como

por exemplo em um upgrade ou implementao de novo mdulo SAP. Neste caso, as customizaes
efetuadas no seu ambiente de produo precisaro ser replicadas manualmente para o ambiente
original para manter a integridade do sistema.

Pgina 88
ACADEMIA BASIS

possvel ainda manter um cenrio de desenvolvimento multi-layered com vrios ambientes de

integrao com suas prprias rotas de consolidao e distribuio. A maior dificuldade neste cenrio
a manipulao das customizaes que no possuem o conceito de proprietrio. O
desenvolvimento mais simples de gerenciar atravs da criao de classes de desenvolvimento
distintas.

Transport Organizer

O Transport Organizer (SE01) uma ferramenta que fornece solues para a manipulao de
cenrios mais complexos que no podem ser gerenciados pelas ferramentas normalmente utilizadas.
As funes de transportes e realocaes permite transportar cpias de objetos ou realocaes de
originais. possvel manipular Object Lists, que so colees de objetos que podero servir para
template da funo Include Object List conseguindo desta forma incluir object lists em change
requests.

Pgina 89
ACADEMIA BASIS

R/3 Upgrades and OCS Patches

R/3 Evolution and Release Strategy

Um sistema R/3 tpico, uma vez instalado, passa por evolues sejam devido a customizaes ou
novos desenvolvimentos, como tambm pela aplicao de patches do OCS (Online Correcton
Service) ou ainda por upgrade de novos releases.

Novos releases no R/3 podem ser de dois tipos:

Functional Releases, que trazem novas funcionalidades e so enviados para os clientes
apenas sob demanda (3.1G e 4.0A, por exemplo)
Correction Releases, trazem apenas correes e so enviadas automaticamente para
todos os clientes. Estes so os releases recomendados para serem instalados em
produo, j que possuem suporte total do OCS (3.1H ou 4.0B, por exemplo)

R/3 Upgrade

Em um tpico landscape de 3 sistemas, cada ambiente (partindo do desenvolvimento) passa por

uma seqncia de transportes standard. So tarefas tais como customizaes, patches, e ajustes no
sistema. Estas alteraes so executadas no ambiente de desenvolvimento e transportadas para os
demais ambientes.

Uma das tarefas mais importantes durante a preparao para o upgrade rodar o script
PREPARE (integrante da ferramenta retrofit que integra a localizao que existia na verso 3.0 com o
correspondente standard que vem na verso 4.0) e que responsvel por fazer uma srie de checks,
a saber :
Quais so as verses do banco de dados, do sistema operacional, e do R/3
Quais abaps preciso ser realterados
Existe espao suficiente no banco de dados
Existe alguma reparao em andamento
Quais so as lnguas suportadas
Qual o nvel de hot package e se todos esto confirmados
usurio tem as devidas permisses no sistema operacional
Aps todo este processo o prepare gera um arquivo chamado \usr\sap\put\log\checks.log) no
sistema com as aes necessrias para viabilizar o upgrade. A execuo deste script no faz parte
do upgrade em si que feito utilizando o programa R3up que tem funcionamento semelhante ao

Durante o processo de upgrade, so efetuadas alteraes de ajuste usando as transaes SPDD

e SPAU. O processo de upgrade passa por passos que so efetuados com o sistema ativo ainda no
release antigo, a retirada do sistema para que o dicionrio seja atualizado e posteriormente mais
tarefas novamente com o sistema ativo, agora j no novo release.

Antes de fazermos o upgrade do R/3 j temos que ter cumprido alguns passos obvieis como a
execuo do script prepare, upgrade do sistema operacional, eventual upgrade do hardware, upgrade
do banco de dados e outros fatores que possam ser pr-requisitos para o R/3.

O primeiro passo efetivo do upgrade a transferncia para o repositrio do R/3 dos novos objetos
enviados em um CD. Este processo passa pela comparao dos objetos para identificar possveis
modifications efetuadas pelo usurio nos objetos SAP standard. Todas as modificaes que o cliente
desejar manter e cujos objetos SAP no novo release tambm foram alterados, precisam ser casados
com os objetos SAP. Este processo executado atravs das transaes SPDD e SPAU e
conhecido como Modification Adjustment.

Existem diversos tipos de modification adjustment que so executados antes (atravs da SPDD) e
depois (atravs da SPAU) da fase do Data Dictionary Activation. Durante esta fase de activation o
sistema desativado, que pode durar vrias horas. Aps esta fase o sistema reativado j no novo
release.

Pgina 90
ACADEMIA BASIS

Repository Switch

O corao de um processo de upgrade o Repository switch. Inicialmente um repositrio inteiro

na nova verso colocado no sistema e permanece inativo. Este processo requer uma rea adicional
em disco que somente ser liberada quando o novo repositrio for ativado e o antigo deletado.

Para preservar as modifications introduzidas pelo usurio, durante o processo de switch do

repositrio as alteraes introduzidas pelo usurio so transferidas para o novo repositrio atravs da
modificao dos correspondentes objetos SAP do novo release.

A fase de modification adjustment somente ser necessrio quando o objeto alterado pelo cliente
tambm foi modificado pela SAP (seno ele ser movido integralmente) e quando questionado, o
cliente decide continuar com suas alteraes por achar que o novo release no incorpora
devidamente suas necessidades. Caso o cliente aceite o novo objeto, suas antigas alteraes sero
descartadas.

No processo de preparao do repository switch acontecem as seguintes operaes:

Transfere para o novo repositrio modifications introduzidas pelo cliente cujos objetos SAP
no sofreram mudana no novo release
Salva no version database todas as modifications que foram efetuadas em objetos que
sofreram mudana no novo release. Isto permitir efetuar os ajustes posteriormente
Copia os objetos que foram gerados atravs do processo de customizing para o novo

Transfere para o novo repositrio todas as documentaes, verses inativas de objetos e

desenvolvimentos executados pelo cliente, alm dos objetos locais

Uma vez que as operaes acima foram efetuadas, o repository switch poder ser efetuado. Caso
no existam objetos que necessitam de adjustment, o switch uma simples questo de reativar o
novo repositrio. simples e rpido, sendo portanto sempre desejvel que os objetos SAP
permaneam o mais standard possvel.

Switch log during repository upgrade

Durante o processo de upgrade podemos escolher trs estratgias diferentes para o uso da log de
alterao. Independente de cada uma destas estratgias evidente que devemos ter backup full off-
line de cada ponto do processo para que em caso de pane ou necessidade de retorno a situao
anterior tenhamos backup para retornar a situao anterior. As principais fases do upgrade so :
Inicializao do processo
Importe do repositrio
Anlise e copia dos novos objetos
Switch, ativao do novo dicionrio e ajuste dos objetos impactados
Importe dos dados de controle
Importe da lingua portuguesa
Fase final e backup aps todo o processo

As estratgias disponveis para o upgrade so :

A_OFF: neste caso durante todo o processo no teremos redo log do que foi feito, ou seja,
se precisarmos retornar a um ponto temos que faze-lo no momento do backup full sem a
possibilidade de fazer um log-foward. A grande vantagem desta opo a no
necessidade de rea para o archive. A grande desvantagem um maior tempo de
downtime acrescido de um backup offline no final do processo.
A_ON: neste caso manteremos o log do banco ativado. O inconveniente deste mecanismo
o consumo de rea de at 6 Gb para a rea de archive. A grande vantagem o menor
tempo de downtime e a possibilidade de um backup online.
A_SWITCH: uma mescla dos dois processo e a log desativada no momento do da fase
de ativao do novo dicionrio. O consumo de disco menor que na opo A_ON mais
ainda considervel. O downtime tambm pequeno mas seguido de um backup offline.

Pgina 91
ACADEMIA BASIS

Ou seja, ela possui um pouca do lado bom das outras duas e por isto que esta opo a
recomendada pela SAP e j o default.

Modification Adjustment

O processo de modification adjustment consiste na transferncia para os novos objetos SAP

das modifications introduzidas pelo usurio no release anterior.

SPDD utilizada para efetuar esta transferncia em certos objetos do

ABAP, tais como domains, data elements, table structures, transparent tables, pooled tables, cluster
tables e table technical settings. A no execuo desta tarefa causaria a perda de dados

Aps a ativao do novo dicionrio, a transao SPAU utilizada para ajustar alguns objetos que
se no ajustados no causariam perda de dados, apenas perda de funcionalidade. Estes objetos
seriam objetos de lock, matchcodes e views, alm de objetos do repositrio, tais como ABAP
programs, function modules, menus, screens ou module pools

Ao trmino da execuo destas duas tasks (SPDD e SPAU), todas as modifications estaro
incorporadas no novo release. No release 4.0 o processo de pre-upgrade PREPARE (script
mencionado anteriormente e integranda retrofit tool) para o upgrade efetua um check geral do
sistema e lista todos os objetos que sofreram modifications e consequentemente necessitaro de
passar pelas SPDD e SPAU, podendo desta forma haver um melhor planejamento do esforo a
ser gasto no processo.

O processo de modification adjustment executa um comparao entre as duas verses do objeto.

Para cada objeto, as transaes SPDD e SPAU guiam o usurio atravs dos processos de ajuste,
oferecendo ainda a opo de aceitar a nova verso ou executar os ajustes necessrios. Estes
ajustes, quando efetuados, sero salvos em change requests (um para a SPDD e outro para a SPAU)
permitindo que o processo de upgrade nos demais sistemas possam ser efetuados de forma mais
simples pela aplicao destes transports.

Este procedimento de transporte simples e poupa esforos de efetuar os adjustments em cada

somente possvel apenas se todos os sistemas do ambiente estiverem nos
no momento dos upgrades. Um landscape bem planejado e bem
gerenciado torna este processo vivel e diminui sensivelmente os esforos no upgrade.

Em relao as responsabilidades do processo de upgrade, temos que ter em mente que os

administradores do sistema so responsveis pelo upgrade mas os times funcionais e de abap so
responsveis pelos ajustes e testes das funcionalidades que sero afetadas pelo upgrade.

Avoiding Modifications in R/3 Systems

Para simplificar os processos de upgrade (minimizando ou at mesmo eliminando a necessidade

de efetuar modification adjustments), a SAP recomenda que se evite modifications tanto quanto
possvel. Alm de demandarem mais esforos durante upgrades, estas alteraes no standard core
do R/3 podem introduzir erros graves no ambiente R/3. Dependendo do nvel destas modificaes e
seus reflexos no negcio da empresa, um processo de upgrade poder ser difcil, demorado ou at
mesmo impossvel de ser implementado em verses mais recentes do R/3.

Em substituio s modifications, a SAP disponibiliza o conceito de enhancements, atravs da

user exits e appended structures que tornam o processo de upgrade totalmente
transparente para a instalao

O conceito de user exits consiste na introduo em determinados pontos mais susceptveis a

modifications dos objetos SAP de chamadas a rotinas externas que podem ser desenvolvidas pelo
cliente em sua instalao. Novos releases traro estas chamadas nos mesmos pontos no
necessitando o cliente de efetuar nenhuma alterao no novo objeto. Os objetos que possuem exit

Program exits, que permitem includes no cdigo atravs de chamadas externas

Pgina 92
ACADEMIA BASIS

Menu exits, podendo o cliente introduzir novas opes no menu

Screen exits, que so telas adicionais
Field exits, que so programas ou function modules conectados a um campo de tela para
executar funes por exemplo de consistncia personalizada de preenchimento. Ao
contrrio dos demais tipos de exits, field exits no precisam ser criadas para um
determinado campo, podendo o cliente decidir pela sua colocao em qualquer campo.

As append structures permite que se acrescente campos em tabelas SAP sem a necessidade de
alterao dos objetos standard do sistema. Os campos includos ocupam fisicamente uma outra rea
e apenas sero incorporados a nova verso do objeto no novo release. Estas estruturas devero
possuir nomes no customer range (Z) para evitar que sejam sobrescritas no momento do upgrade. A
incluso destas estruturas entretando no so permitidas a pool tables, cluster tables ou tables que
possuam campos LONG RAW.

Online Correction Service (OCS)

O OCS oferece patches para correo de um sistema R/3 atravs da disponibilizao de Hot
Packages, LCPs, SPAM updates e Conflit Resolution Transport (CRTs). Estes patches reduzem a
necessidade de correes manuais no sistema atravs da aplicao de notas que, diferentemente
destas correes, no sero reconhecidas por um processo de upgrade como modifications.
portanto extremamente aconselhvel que um sistema R/3 esteja up to date no momento de um
upgrade para minimizar a necessidade de anlise de modifications que no passam de notas
aplicadas.

Os tipos de patches na verso 4.0 so :

Hot Packages so grupos de vrios patches e devem ser aplicados na ordem em que so
disponibilizados pela SAP. Tecnicamente durante a sua aplicao requerem modification
adjustments atravs da transao SPAU.
LCPs ou Legal Change Patches, so os Hot Packages para o ambiente HR
SPAM update uma atualizao para a transao SPAM (utilizada durante a aplicao
dos Hot Packages)
CRTs ou Conflit Resolution Transports suprem objetos adaptados para resolver conflitos
entre o R/3 e alguns SAP add-ons
Estes patches ficam disponveis para download no sapnet (ou atravs de download via OSS a
partir da SPAM). Para simplificar a sua implementao, a SAP empacota umas 3 vezes ao ano os Hot
Packages, SPAM updates e LCPs em um CD que enviado para o cliente.

O SAP Patch Manager (transao SPAM) a ferramenta utilizada para aplicar os patches no
ambiente R/3 e dever ser executada no client 000 por um usurio que possua todos os privilgios
(SAP_ALL) porm no dever ser o DDIC ou o SAP*. A SPAM fora a aplicao dos patches na
ordem correta e obriga a um aceite em cada aplicao antes de aceitar a seguinte, forando desta
forma a uma verificao da aplicao pelo cliente. O processo de aplicao dos patches deve ser
efetuado em todos os sistemas do landscape. Caso se efetuem adjustments pela SPAU durante a
aplicao, os mesmos podero ser salvos em change requests para posterior import nos demais
sistemas, evitando a utilizao da SPAU mais de uma vez.

Ao longo da utilizao e conseqente identificao de problemas nas funcionalidades do sistema,

pode ser necessrio aplicar manualmente no R/3 correes disponibilizadas em notas no OSS. Estas
notas (porm nem todas) sero posteriormente agrupadas em Hot Packages. Qualquer nota dever

Pgina 93
ACADEMIA BASIS

Terceira Semana

R/3 Spool and Print

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

R/3 Spool System

O R/3 possui diferentes formas de enviar documentos atravs de seus sistemas de spool. Um
documento formatado, que pode ser uma impresso, um fax ou um EDI, representa uma message no
sistema R/3 e, uma vez criada, estar liberada para impresso ou transmisso. As impresses no
R/3 podem ser imediatas ou adiadas para sada posterior. Alm do message control, o R/3 possui
uma combinao de programas de impresso e SAPScripts para produzir os documentos de
impresso. Enquanto o programa de impresso obtm os dados a serem impressos, o SAPscripts
especifica o layout do documento a ser impresso.

Como o sistema R/3 um ambiente multiplataforma, foi criado um sistema interno de spool para
interfacear com os diversos hosts nos quais o R/3 pode rodar. Atravs deste princpio o R/3 formata
os documentos e requisita ao spool do sistema operacional que apenas repassa o documento para o
dispositivo fsico de impresso que est alocado na porta paralela ou serial.

Spool and Output Requests

Um spool request criado quando um documento R/3 requisitado para impresso mas ainda
no foi enviado para o dispositivo de sada. Os dados ficam armazenados em um
interno do R/3. Um spool request formatado pelo spool work process e passa a ter um determinado
formato para um dispositivo especfico, este formato nos chamamos de output request. Vrios output
requests podem ser gerados a partir de um nico spool request, contendo cada um os atributos ou
comandos especficos de um determinado hardware de impresso.

Os spool requests gerados ficam armazenados em um repositrio denominado Temporary

Sequential Database, ou TemSe. Este repositrio poder estar no banco de dados do R/3 ou em
arquivos do global directory do sistema operacional (determinado pelo parmetro de profile
rspo/store_location = db ou G e direcionado pelo parmetro rspo/files/root/G = $(DIR_GLOBAL) ). Os
output requests so armazenados apenas como registros de controle. Os formatos de impresso uma
vez gerados so repassados diretamente para o gerenciador de impresso do sistema operacional
sem serem armazenados na base de dados.

Spool Work Process

Quando uma requisio de impresso de um spool request efetuada, um output request

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

Local and Remote Printing

Os output requests formatados so repassados para os dispositivos atravs de strings de

impresso. Quando se utiliza o mtodo Local, os dados so repassados diretamente para o spooler

Pgina 94
ACADEMIA BASIS

do sistema operacional da mquina onde o spool work process que cuida de envia-los, seja para uma
impressora conectada diretamente ao host ou atravs da rede. o mtodo mais rpido, uma vez que
a tarefa de gerenciamento do string at o dispositivo de sada fica a cargo do sistema operacional,
liberando o work process desta tarefa. Evite utilizar o host onde o sistema R/3 est rodando como o
host que controla esta fila de impresso e possui uma impressora ligada fisicamente pois isto vai
consumir recurso do sistema operacional. Existem cinco mtodos de acessos, a saber :
L, utilizado onde o output request passado para o gerenciador de impresso do sistema
operacional (do tipo line command). O mais comum ser utilizado no ambiente unix mas
tambm pode ser utilizado no ambiente Windows NT. Os comandos a serem utilizados para
imprimir e para verificar a fila podem ser redefinidos atravs dos parametros
rspo/host_spool/print e rspo/host_spool/query, respectivamente
C, utilizado onde o output request passado para o gerenciador atravs de call a bibliotecas
especficas do sistema operacional. Deve ser utilizado com Windows NT e AS/400
E, utilizado para enviar o output request para um OMS (ser detalhado logo a seguir)
P, utilizado para enviar o output request para um device pool
F, utilizado para impresso no front-end e quem formata o output device o dialog work
process

Remote printing consiste na transferncia dos output requests diretamente para os dispositivos
remotos. Neste caso o spool work process fica responsvel pela negociao com o dispositivo
atravs da rede. Este mtodo de acesso remoto menos otimizado por onerar o work process
gerando possveis contenes na impresso. O spool work process fica preso at que ele consiga
passar todas as informaes para o spooler remoto (ou saplpd) que eventualmente fica esperando o
buffer da impressora, ou seja, o spool work process fica preso at que a maior parte da impresso
fsica seja feita. A transmisso remota feita atravs de lpd (line printer daemon) e a SAP prov o
programa SAPLPD para as plataformas que no possuem este protocolo standard. Devemos utilizar
este mtodo somente quando a rede for muito rpida e muito confivel. Os mtodos de acesso so :
U para os ambientes baseados no unix e impressoras de rede
S para ambientes windows 9x com saplpd

Spool Administration

A transao SPAD utilizada no R/3 para a administrao de spool. As impressoras (output

devices) so definidas especificando o mtodo de acesso (local L ou C - ou remoto U ou S para
unix e windows respectivamente ) e suas caractersticas (device type, spool server, print server,
atributos documentacionais, etc.). Para impressora remota devemos sempre utilizar o nome do print
server no formato UNC //<host_name>/<printer_share_name>. Na verso bsica da SPAD podemos
definir output devices, spool servers, access methods e destination hosts. Podemos tambm verificar
a instalao, deletar spools antigos, verificar a TemSe e acionar SP01.

Frontend Printing

A impresso frontend no R/3 permite que usurios enviem output requests para impressoras que
no foram definidas como output devices no R/3. o denominado mtodo de acesso F. Caso a
estao do usurio seja um PC windows, o request enviado para um SAPLPD rodando na estao
do usurios. Se o SAPLPD no estiver rodando, ele iniciado e manipula os requests e os envia para
Neste mtodo de acesso o processamento do spool efetuado pelos
prprios dialog work processes, no havendo necessidade de encaminhar o request para os spool
work processes. Para definir uma impressora frontend para as estaes windows, alm de especificar
o mtodo de acesso F, necessrio definir o device type SWIN (qualquer impressora com device
instalado no windows) e o host printer dever ser __DEFAULT. Este mtodo dever ser evitado em
sistemas produtivos por utilizar os work processes para tarefas que deveriam estar reservadas para
os spool work processes alm de prender o dialog work process at que todos os dados da
impresso sejam passados para a estao onde est o frontend e o saplpd.

Pgina 95
ACADEMIA BASIS

Logical Spool Servers

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

Spool Request Management

O spool requests gerados no sistema devem ser gerenciados pelo administrador para garantir a
disponibilidade do ambiente. O programa RSPO0041 deve ser schedulado em todos os sistemas para
efetuar o trabalho de housekeeping e eliminar spools antigos do sistema.

A transao SP01 o spool request viewer, que permite aos usurios ver seus requests e
requisitar outputs ou eliminar spools. Administradores com autorizaes apropriadas podem ver todo
SPAD ou o programa RSPO0043 pode ser utilizado para
checar a consistncia entre os spool requests, output requests e output datas so consistentes cada
um por si e as referencias cruzadas entre eles. A verificao de problemas associados com os spool
requests pode ser efetuada tanto pela SP01 quanto pela SM21 ou ST22.

Existem objetos de autorizao especficos para diversas operaes de spool no R/3, seja
protegendo determinados dispositivos de sada (S_SPO_DEV) ou limitando o poder de
gerenciamento (S_SPO_ACT e S_ADMI_FCD) . O objeto S_SPO_PAGE limita o nmero mximo de
pginas que um usurio pode imprimir em um determinado dispositivo. Para que esta autorizao
tenha efeito necessrio ativar o parmetro de profile rspo/auth/pagelimit=1.

Pgina 96
ACADEMIA BASIS

R/3 Output Management

Atravs da opo de administrao estendida na SPAD, uma srie de funes avanadas podem
ser escolhidas tais como : definio de device types, print controls, formats, page formats, OMS e
character set.

Device Pools

O conceito de device pools permitir que se defina um pool de dispositivos de sada que podem
ser referenciados atravs de um nico nome. Device pools so definidos especificando mtodo de
acesso P e a lista dos dispositivos que o compem. Output requests podem ser enviados para todos
os dispositivos que compem o pool simultaneamente ou pode-se requisitar que o sistema efetue o
balanceamento de carga entre os dispositivos de sada da lista. Os dispositivos que compem a lista
de um device pool podem ainda ser acessados individualmente como devices independentes.

Para o caso de utilizarmos o balanceamento de carga temos que ter certeza que a rede e o
gerenciador de impresso do sistema operacional tem bom tempo de resposta pois para balancear a
carga o R/3 vai fazer query para saber o status do device.

External Output Management Systems (OMS)

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

Spool Server and Requests Management

Qualquer instncia R/3 que possui spool work processes denominada um spool server. O R/3
permite a definio de um alternate spool server que pode assumir as tarefas de um spool server
principal. Quando se assinala o campo non-exclusive spool server no atributo de um spool server o
sistema R/3 efetua o balanceamento de carga dos requests de impresso.

O sistema R/3 permite que se classifique os servidores e os dispositivos em categorias (High

volume, Production, Desktop e Test) o que faz com que o sistema envie uma mensagem de warning
quando se efetua o assign de um determinado dispositivo com um server incompatvel. Os requests
enviados para um determinado spool server caem em uma fila de spool e so processados
sequencialmente. Quando o server possui mais de um spool work process, os requests so
manipulados paralelamente de forma que determinado request da fila poder ser enviado para um
dispositivo antes de outro documento pesado que ainda esteja sendo formatado. Caso se defina um
dispositivo com a opo de sequential request procesing, os output request para o dispositivos
sero serializados. Esta definio pode causar impacto em todo o sistema de impresso, j que
durante a presena de requests para o device, um determinado spool work process fica reservado
para processar a fila do device que possui a caracterstica de processar os requests
sequencialmente.

Para permitir que os usurios acompanhem o andamento de seus requests, os spool work process
questionam os devices sobre o sucesso das operaes. Uma vez que durante este tracking o spool
permanece aguardando uma resposta, isto pode ser particularmente problemtico para
impressoras remotas ou com baixa performance na rede. Esta opo pode ser desabilitada para um
dispositivo de sada especificando a opo no longer ask for print requests in host spool.

Ao se especificar o atributo monitoring using monitoring infrastructure, o device pode ser

monitorado atrvs da rvore de MTEs do CCMS. Alm das opes da jenela de manuteno do
device temos ainda os parametros para controle de time-out e retries (rspo/tcp*).

Pgina 97
ACADEMIA BASIS

Non-Standard Printers

Quando um determinado dispositivo de sada no possui device padro no R/3, possvel criar
um driver personalizado para o dispositivo atravs da especificao de alguns objetos. A transao
SPAD, em extended admin, fornece todos os mecanismos para formatar e testar o drive a ser
utilizado pelo novo dispositivo. Antes de definir um novo dispositivo, verifique no OSS se j no existe
disponvel o novo driver para ser baixado do sapservX. Se for necessrio criar realmente um novo
driver cpie um j existente e altere o que for necessrio, sempre tentando manter o mais prximo do

Character set

O character set especifica os cdigos internos armazenados no spool request e seus respectivos
ASCII que sero impressos. um de para. Cada caracter tem um cdigo interno no R/3 (nenhuma
relao com o ASCII), cuja lista pode ser visualizada atravs da SPAD (Full Administration SAP
characters). possvel acrescentar caracteres nesta lista, utilizando os cdigos 9000 a 9999.

Cada tabela de character set disponvel transcreve este cdigo interno R/3 para um determinado
ASCII. Para adapter uma determinada tabela, necessrio inicialmente copia-la e ento efetuar as
alteraes na cpia e salvando posteriormente as alteraes em um character set identificado por

Format, Page format e Format actions

Format identifica o papel utilizado pelo R/3 (letter, A4, etc.). Quando utilizamos formulrios que
no so padres necessrio definir novos formatos pela SPAD. Os Page formats prov a interface
entre o format e o SAPscripts, permitindo que os programas R/3 possam determinar o nmero de
linhas por pgina, entre outros dados. Para definir format actions, ou seja, como determinado
dispositivo manipula um determinado formato de impresso, necessrio editar o dispositivo de sada
e acrescentar na sua opo de format as sequencias de caracteres para efetuar as operaes de
impresso (printer initialization, new line, skip page, 12 char/inch, etc.)

Print controls

Os print controls determinam como um determinado dispositivo efetua determinadas operaes,

como por exemplo imprimir em bold. Print controls so especficos de cada device e durante a
formatao so convertidos para determinadas sequencias de caracteres. A sequencia correta deve
ser obtida no manual da impressora, aps ter certeza que a SAP no disponibilizou driver para este
device.

Message Control and EDI

O message control utilizado no R/3 para troca de informaes entre parceiros envolvidos em
uma determinada regra de negcio. Os documentos gerados (EDI, fax, impresses, etc.) so
normalmente gerados atravs de exits especficas dentro programas R/3 que so chamadas para
formatar a sada desejada. Dependendo da customizao efetuada, o documento gerado enviado
como parte da transao ou fica pendente para posterior envio. O EDI, Electronic Data Interchange,
a troca de mensagens de negcio entre dois sistemas atravs de interfaces standard. A SAP no
fornece um subsistema EDI no R/3, mas prov uma interface aberta para estes sistemas se
conectarem. Esta interface baseada em Intermediate Documents, ou IDOCs. No R/3 todos os dados
transferidos por EDI so transferidos atravs de RFCs entre os sistemas envolvidos.

Pgina 98
ACADEMIA BASIS

SAPconnect

O SAPconnect uma camada que permite a comunicao do R/3 com outros sistemas externos,
tipo fax ou mail servers. A conexo do R/3 com sistemas externos normalmente requer a
especificao de interfaces externas, porm a conexo entre dois sistemas R/3 via SAPconnect pode
ser feita diretamente. Estes adapters externos devem ser fornecidos por cada fornecedor interessado
em se conectar com o sistema R/3. A SAP fornece um adapter para o Microsoft Exchange Server que
pode ser configurado para integrar as duas ferramentas. Para configurar o SapConnect utilize a
transao SC0T. Para maiores informaes sobre o SapConnect utilize as notas 34705 e 92950.

Pgina 99
ACADEMIA BASIS

Installation Check

Hardware e Software

Antes de comear uma instalao necessrio garantir que os requisitos mnimos do checklist de
instalao sejam atendidos. No pacote de instalao existe um checklist completo que deve ser
seguido. Para o hardware, certificar-se de que seja um hardware homologado pela SAP e de alta
disponibilidade, alm de verificar ainda o nmero de processadores, memria RAM e disco
disponveis. Para o software, verificar se a verso do sistema operacional se encontra atualizada e
suportada pelo R/3, checar os utilitrios make do compilador C e a configurao do kernel.

Na camada de rede, checar a configurao TCP/IP, o hostname em minuscula e com at 8 dgitos.

A estrutura de rede dever prover IP fixo para os hosts dedicados ao R/3 e uma boa proteo de
segurana. Quando se usam mais de um servidores interessante ainda ter uma rede privada de
conexo entre eles de alta capacidade para garantir velocidade na comunicao dos application com
a central instance, alm do compartilhamento das mquinas que compem o landscape.Para maiores
detalhes veja a nota 23538.

O sizing do hardware normalmente especificado pelos fabricantes baseado nas recomendaes

da SAP e de suas prprias configuraes. Alm disto necessrio garantir uma boa distribuio de
discos alm de uma proteo poe espelhamento e sistemtica de backup do sistema operacional.

Oracle Database

A verso do banco de dados dever ser compatvel com R/3 e com o sistema operacional. O
database name ser o mesmo system id do R/3. Alteraes posteriores no nome do database no
so simples de serem efetuadas. Para garantir a comunicao entre os processos atravs da rede, as
profiles Oracle referentes a configuraes de network so requeridas: listener.ora, tnsnames.ora,
sqlnet.ora e protocol.ora.

O oracle ser instalado em uma configurao prpria de sua rvore de diretrios e diversas
variveis de ambiente so setadas para apontar para os caminhos corretos. A distribuio dos discos
no ambiente de banco de dados tem influncia direta sobre a performance do banco, devendo desta
forma dedicar um cuidado especial a esta parte. Os redo log files devem ser espelhados (RAID I) por
hardware e por software (oracle). Os arquivos sapdata devem, preferencialmente estar isolados entre
si e de todo resto. Alm disto e havendo disponibilidade, distribua os tablespaces PSAPSTABD e
PSAPBTABD em filesystem nicos. Filesystems crticos (online redo logs, archive, paginao do OS)
no devem ser instalados nos mesmos discos dos datafiles, que por sua vez devem estar em discos
distintos. Evite utilizar RAID 5 para online redo log, saparch e o tablespace PSAPROLL. Estes pontos
tem influncia direta sobre a performance.

Aps a instalao, por questes de segurana, a password dos contas oracle SYS, SYSTEM e

Durante a instalao do Oracle sero gerados alguns arquivos importantes, a saber :

%oracle_home%\net80\database
initSID.ora contm todas as informaes da instncia oracle
initSID.sap contm todas as informaes para permitir o backup da instncia oracle
initSID.dba contm todas as informaes para o SAPDBA conseguir administrar o oracle
%oracle_home%\net80\admin
listener.ora que contm informaes para o listener (no lado do servidor do banco de
dados) saber onde encontrar uma determinada instncia
tnsnames.ora contm os parmetros para um processo cliente do oracle (que no est
no servidor do banco de dados) conseguir conectar com uma instncia
sqlnet.ora contm informaes administrativas para os processos clientes do oracle
protocol.ora contm o switch para o tcp.nodelay (opcional)

Pgina 100
ACADEMIA BASIS

A estrutura de diretrio do oracle baseada em duas variveis. O oracle_home normalmente o

\orant e o sapdata_home normalmente o \oracle\SID. Alm destas variveis temos que diferenciar
as rvores do lado oracle server e do lado oracle.

Server site

\%oracle_home%
\ rdbms80
\ bin
\ net80 \ database
\%sapdata_home%
\ sapdata1
...
\ origlogA

Client site

\%oracle_home%
\ rdbms80
\ net80 \ admin
\ nlsrtl31 \ data
\ nlsrtl32 \ data
\ nlsrtl33 \ data

R/3 System

O system id (SID) de uma instncia R/3 dever ser nica no landscape e composto de 3
caracteres alfanumricos, sendo o primeiro alfabtico. Alguns nomes so reservados, devendo ser
escolhidos cuidadosamente, j que qualquer alterao exigir a reinstalao do R/3. Alguns
parmetros do kernel Unix so relevantes para a instalao e funcionamento do R/3. Verifique a sua
configurao e efetue as alteraes necessrias de acordo com o manual de instalao OS
Dependencies. O programa memlimits disponibilizado no CD de instalao pode ser utilizado para

A instalao do R/3 dever ser executada em uma mquina que no deve possuir outro servio
como pdc, bdc, etc. A estrutura de diretrio a ser utilizada j pr determinada pela SAP. Esta rvore
contm dois ramos bsicos, os diretrios globais que sero compartilhados entre sistemas e os

\usr\sap (compartilhado como sapmnt e saploc)

\ put
\ tmp
\ trans
\ <SID>
\ SYS
\ profile
\ exe
\ run
\ dbg
\ opt
\ global
\ <instance_name>
\ work
\ data
\ log

Uma instncia R/3 possui um nmero (2 dgitos) informado pelo administrador no momento da
instalao e ser utilizado pelo R/3 para compor os nmeros das portas para diversos servios

Pgina 101
ACADEMIA BASIS

TCP/IP que sero utilizados pelos processos. Estes servios sero registrados pelo programa de
instalao no %windir%\system32\drivers\etc\Services do host:
Porta para o dispatcher da instncia: sapdpnn 32nn/tcp
Porta para o servio de gateway: sapgwnn 33nn/tcp
Porta para o message server: sapms<SID> 36nn/tcp

Os gateways 97, 98 e 99 alm do dispatcher 99 so reservados para a SAP para os R/3 service
programs (OSS, SapConnect, EPS e SapRouter respectivamente). Para verificar o ambiente TCP/IP
utilize os programas sapntchk (command line) ou sapsychk (win32). Para maiores informaes sobre
a analise do log produzido veja a nota 65761

O TMS dever ser configurado corretamente em um landscape para permitir o transporte entre os
vrios sistemas R/3 que o compem. Cada transport domain possuir um suas rotas de transporte e
um dos sistemas receber atribuio de domain controller. Se por questes de performance, os
frontend no devero se conectar ao host do database, utilizando para isto application servers. Se o
message server for instalado em outro host que no o do database, a DEFAULT.PFL dever informar
esta nova configurao atravs dos parmetros SAPDBHOST e rdisp/mshost.

Aps a instalao, a transao SICK (ou SM28) utilizada para efetuar um check completo de
consistncias entre verses do kernel e database, garantindo assim que no existiro inconsistncias
na instalao. Alm disso bom configurarmos o saprouter, importarmos os hotpackages atravs da

Quando se utilizam vrios application servers, necessrio garantir a sincronizao correta do

buffer atravs de parmetro da instance profile (sendon,exeauto).

Configure corretamente o mecanismo para backup do ambiente, seja do database como tambm
do sistema operacional e diretrios do R/3 e faa o backup de tudo.

Pgina 102
ACADEMIA BASIS

R/3 Workload Distribution

Overview

A ferramenta de instalao R3SETUP utilizada tanto para a criao de central instances

(DVEBMGSnn) quanto de dialog instances (Dnn) no ambiente R/3. O sistema configura profiles
iniciais que podem ser editadas seguindo a vontade do administrador para configurar novos servios.
Atravs da definio de operation modes podemos distribuir os work processes (dialog, background,
update) entre os diversos servidores que compem um sistema R/3. Os work processes de spool so
distribudos atravs da definio das profiles pela RZ10. Uma vez que o usurio se logou a um
determinado servidor do sistema, todos os seus dialog steps so despachados dentro daquela
mesma instncia at o prximo logon. J as suas requisies de servios de spool, update e
background podero ser atendidos por qualquer um dos servidores distribudos na rede.

Mechanism

Cada instncia R/3 possui seu prprio dispatcher e sua prpria queue de requisies organizada
de forma FIFO first in first out, mantida na shared memory da instncia. Qualquer chamada de
servio (outbound request) que no seja uma comunicao com o frontend e nem uma chamada RFC
encaminhada pelo dispatcher para o message server. Isto aconter com os outbound requests para
spool, update, enqueue e batch processamentos que a instncia no possuir work process para
atender.

A fila do dispatcher pode ser visualizada atravs do programa dpmon (nvel do sistema
RZ03, Edit -> Other views -> Dispatcher queues. Cada dispatcher
organiza sua fila criando queues para cada tipo de work process: DIA, BTC, UPD, UP2, SPO, ENQ e
uma fila NOWP para outgoing requests vindos destes vrios work processes. O tamanho default para
cada uma destas filas 2.000. Caso a instncia no possua um determinado servio (por exemplo
UP2), sua fila ter um tamanho de 5 requests apenas. O tamanho da fila do dispatcher mantida
atravs do parmetro de profile rdisp/elem_per_queue. Caso ocorra um overflow na queue, ser
gerada uma mensagem na SYSLOG. A monitorao das filas pode ser executada atravs da SM51,
selecionando um servidor e requisitando Goto -> Queue information

Para comparar a distribuio de carga entre os diversos servidores, a transao ST03. Atravs do
Detail analysis menu possvel inclusive requisitar que as comparaes sejam exibidas em modo
grfico: Compare all servers -> Graphics -> Avg response time/Dialog steps.

Uma anlise do CPU time dos work process pela SM50 permite efetuar uma anlise para cada tipo
de servio se o nmero de work process foi definido suficientemente. Como a distribuio dos
servios pelo dispatcher feita de forma sequencial, os ltimos work processes de um determinado
tipo com valores elevados de CPU indicam ocupao constante e portanto uma possvel espera
excessiva de processos na queue deste tipo de work process. O incremento do nmero de work
process, antes de ser feito, precisa ser analisado visando identificar se o recurso de hardware
(principalmente memria mas sem esquecer a cpu) disponvel na instncia comporta mais work
process.

Evite o logon de usurios na central instance para evitar sobrecarga, j que normalmente esta
instncia estar oferendo os servios de DB. Distribua os logons de usurios entre as instncias de
dialog e faa o mesmo com a carga de spool e background.

Logon Load Balancing

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

Pgina 103
ACADEMIA BASIS

Possibilidade de agrupar usurios de reas afins em servidores especficos com isto

otimizando a utilizao dos buffers das instncias que somente contero dados e programas
relacionados com aqueles usurios
Utilizao racional de code pages especficas quando houver necessidade deste tipo de
configurao (por exemplo japanese)

Para termos isto precisamos categorizar os usurios em grupos e configurar os frontends para um
logon especfico em um grupo especfico e no mais um servidor especfico. A conexo neste caso
feita com o message server (servio sapmsSID 36##/tcp) e no mais diretamente com os dispatcher

O dispatcher inicialmente procurar avaliar entre os servidores disponveis no grupo aquele mais
indicado para receber a conexo de logon e a ento encaminha o usurio para o dispatcher
selecionado. O programa RSRZLLG0 utilizado para efetuar o balance baseado em critrios como
tempo de resposta e nmero de usurios logados em cada server. Este programa roda a cada 5
minutos ou a cada 4 usurios que se logam e determina o server favorito para o logon a cada
instante. Este balanceamento baseado em pesos que so dados aos itens. A nota 51789 descreve
o critrio e como altera-lo para melhor se adaptar as suas necessidades. O default do sistema o
tempo de resposta ter um peso cinco vezes maior que a quantidades de usurios.

SMLG pode ser utilizada para monitorar a lista global dos usurios logados (Goto ->
User list), a distribuio de carga entre os servers (Goto -> Load distribution) ou ainda ver qual o
server favorito para logon (Goto -> System diagnosis -> Msg. Server status area).

Procure sempre especificar logon groups com mais de um server provendo assim uma maior
disponibilidade para o sistema. Entretanto, no adianta colocar todos os servidores em todos os
grupos pois estariamos prejudicando os buffers. Devemos sempre monitorar e procurar um ponto de
equilibrio. Preferencialmente faa um agrupamento baseado nas reas funcionais como FI com CO,
SD com MM, PP separado dos demais, etc. Em casos extremos podemos criar uma user exit para
impedir que um usurio entre em um ou mais grupos.

Background Load Balancing

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

Spool Load Balancing

Considere a possibilidade de acrescentar as impressoras mais crticas ao Alert monitor. Na SM66

dever ser utilizada para identificar spool work processes super ou sub utilizados. A utilizao dos
spool lgicos melhora distribuio de carga.

Quando especificando um device, no utilize a opo Sequential Request Processing e habilite

a opo Do not ask for print requests on host spool. Utilize preferencialmente os access spool
methods do tipo local (L ou C) evitando utilizar os remotos (U).

Update Load Balancing

Cada sistema R/3 precisa ter definido pelo menos um update work process. recomendado ainda
que pelo menos um update tipo 2 seja definido no ambiente para tratar as atualizaes que no so
time criticals. O Dynamic Update Assignment cuida de distribuir os updates V1 e V2 entre os diversos

Pgina 104
ACADEMIA BASIS

servidores de update disponveis. Apesar de processado em work processes separado (quando

disponvel), os updates V2 somente sero processados aps a poro V1 do processo tiver sido
executada com sucesso.

Quando um request de update disparado por um dialog server, o sistema verifica uma rea da
shared memory denominada Update Dispatcher Information, para descobrir em qual server o update
dever ser executado. Ele se baseia em algoritmos internos de balanceamento de carga (o dynamic
update assignment) e a partir da o update request colocado na NOWP queue do dispatcher onde o
update foi gerado. Os updates so distribudos em um processo cclico sequencial entre os servers
disponveis obedecendo ao nmero de update work processes disponveis em cada um. Quando um
ciclo completo de distribuio se fecha, o sistema inicia outro baseado no mesmo critrio. Este
processo faz com que os updates sejam distribudos ao acaso fazendo com que updates pesados
sejam distribudos aleatoriamente entre os servidores disponveis. Quando o algoritmo enderea um
update para um determinado server, o message server entra em ao e movimenta o request da
NOWP queue do server que gerou o request para a UPD queue do server que executar o servio

Ao analisar os update work processes pela SM66, observe se o ltimo update de cada instncia
mostra pouca ou nenhuma CPU. Alm disso o primeiro work process dever apresentar muito mais
CPU que os demais. Se o sistema no apresentar este perfil, possivelmente estar havendo um
gargalo no ambiente causado pela definio de poucos work processes de update. Use ainda a
transao SM51 para exibir o maximum request wait. Este valor dever ser muito prximo de zero.
Por outro lado caso existam muitos work processes com zero de CPU, certamente est havendo um
excesso de recurso alocado.

Para verificar a fila dos processos de update no dispatcher, utilize transao RZ03 (Edit -> Other
view -> Dispatcher queue). A transao SM13 exibe o status do update. Nesta transao, atravs da
opo Goto -> Server, podemos ainda verificar o nmero de updates enviados para cada server bem
como informaes do dispatching. Por questes de performance, ao analisar o CPU time dos update
processes em cada server, mantenha pelo menos um com 0 de CPU. Isto garante que no haver

Existe uma relao de custo benefcio em se manter os updates centralizados na central instance
ou distribudos pelos servidores:
Central instance: a vantagem que as instncias no precisaro manter programas de
update de todos os mdulos otimizando assim a alocao dos buffers dos servidores do logon
group. A desvantagem que no se faz uso do balanceamento de carga do update, que se
encontra centralizado
Distribudo pelas instncias: a principal vantagem o balanceamento distribudo do
processamento de update, conforme descrito acima. A contrapartida que todas as instncias
tero em seus buffers programas de update de todos os mdulos, j que quem distribui os
processos o automatic load balancing de update.

A configurao do update executada pelos seguintes parmetros de profile:

rdisp/vbname: especifica o nome do servidor de update quando o automatic dispatching
desabilitado
rdisp/vb_dispatching: habilita o automatic dispatching. Este parmetro somente dever ser
alterado quando explicitamente recomendado pela SAP
rdisp/vb_context: seletor para partes do contexto de update
rdisp/vb_included_server: lista dos servers que participam do dispatching. Quando no
especificado o sistema assume todos os servidores que possuem updates configurados
rdisp/vb_refresh_info: especifica o tempo em segundo com que haver um refresh da lista de
dispatching
rdisp/max_vb_server: mximo nmero de VB servers
rdisp/wp_no_vb e rdisp/wp_no_up2: especificam os nmeros de update work processes (tipo 1

Configuration Summary

No existe uma regra especfica para o nmero de work processes configurados em cada
instncia, devendo o nmero ser ajustado por observao da demanda. Recomenda-se apenas que
se deixe sempre um work process de cada tipo com 0 de CPU garantindo a tima distribuio da

Pgina 105
ACADEMIA BASIS

carga. Existe uma recomendao informal da SAP que se configure 3 spool work processes por
servidor de spool para que se tenha sempre um livre enquanto os outros dois estejam efetuando job
quering e connection checking.

Utililize a seguinte regra para definir a quantidade de work processes :

Service 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

Pgina 106
ACADEMIA BASIS

Quarta Semana

Database Fundamentals

Oracle Overview

Uma instncia oracle o conjunto voltil de processos e estruturas de memria. Um banco de

dados oracle um conjunto de arquivos de dados que so manipulados pela instncia oracle.
Podemos dividir o Oracle em uma srie de estruturas de memria. A mais famosa entre elas a SGA
(system global area) e ela um grande grupo de buffers de memria compartilhados, a saber : shared
pool, database buffer cache e redo log buffer. Para acessar estas estruturas existem os processos
que executam uma srie de tarefas de manuteno da instncia. Cada processo distinto, possui
uma funo especfica, executado em background e assincronamente. Os principais processos so
: pmon, smon, dbwr, lgwr, reco, lck ckpt, snp e arch.

A shared pool uma poro de memria compatilhada que contm as reas chamadas de shared
sql, library cache, data dictionary cache e sequence cache. Todas participam do processo e so as
estruturas que contm os sqls que esto sendo execudados pelos mltiplos usurios. Essas reas
contm ainda os comandos na forma interpretada e texto, a anlise dos comandos com os
respectivos planos de execuo, informaes de dicionrios e geradores de nmeros sequenciais. O
principal objetivo da shared pool viabilizar que um comando sql seja utilizado por diversos
processos distintos. Uma nica shared sql area pode ser compartilhada por diversas aplicaes que
usam o mesmo comando deixando mais reas em memria disponvel para os outros usurios e
melhorando a performance de execuo de um comando, j que o plano de execuo estar definido

Pgina 107
ACADEMIA BASIS

O database buffer cache organizado em duas listas: a lista de blocos alterados e a lista dos
blocos menos recentemente utilizados (LRU least recently used). Essa segunda lista contm os
blocos livres, aqueles que esto em uso e inclusive blocos alterados. Quando um processo servidor
precisa ler dados de um bloco do disco para o database buffer cache, ele pesquisa a LRU para
localizar o bloco livre. Se encontrar um bloco alterado, movimenta-o para a lista de blocos alterados.
Esse processo termina quando um bloco livre localizado ou quando um nmero especfico de
blocos so pesquisados sem encontrar um bloco livre.

O redo log buffer armazena todas as alteraes feitas em um banco de dados em memria. Todas
as entradas de redo log neste buffer so escritas nos arquivos de redo log, que so usados para a

O Oracle cria um conjunto de processos que rodam em background para cada instncia, Esses
processos executam diversas tarefas. Entre eles podemos destacar :
DBWR O processo database writer escreve os blocos modificveis do database buffer cache
para os arquivos de dados. Os dados mais antigos so escritos em primeiro lugar. O dbwr adia
ao mximo a escrita dos blocos alterados para otimizao de I/O em disco para evitar aquela
que uma das principais causas de queda de performance de um banco de dados.
LGWR O processo log writer escreve todas as entradas de redo log para o disco. Os dados
de redo log so armazenados em memria no redo log buffer, e no momento em que uma
transao for efetivada ou o redo log estiver com preenchimento de pelo menos um tero, o
lgwr escreve as entradas de redo log para os arquivos online redo log files.
CKPT O processo de check point envia um sinal para o dbwr no momento do check point.
Ele ento atualiza os headers dos control files e dos datafiles.
SMON O processo de system monitoring efetua a recuperao da instncia em caso de
falhas, durante a uma inicializao. Ele tambm limpa os segmentos temporrios que no
esto sendo usados, liberando memria e recupera qualquer transao pendente no caso de
uma falha fsica. Simplificando, o smon um monitor das aes do sistema detectando e
corrigindo possveis falhas no sistema
PMON O processo monitor executa a recuperao do processo de um usurio em caso de
falhas. Ele limpa a rea de memria e libera os recursos que o processo usurio estava
usando. Simplificando, o pmon um monitor das aes dos usurios detectando e corrigindo
possveis falhas nos processos dos usurios
ARCH O processo de archiver copia os arquivos redo log para fita ou mesmo outro disco, no
momento em que um deles torna-se completo. Este processo geralmente est presente
quando o banco de dados esta sendo utilizado no modo archivelog.
RECO O processo de recover usado para resolver transaes distribuidas e pendentes.
LCKn Os processos de lock (lckn) so usuados para controlar o lock entre instncias em
uma configurao oracle parallel server.

Dentro de uma instncia Oracle existem vrios processos que so criados quando a instncia
entra em funcionamento. Eles se dividem em dois grupos :
Dedicated shadow processes: que so os processos criados no Oracle para as conexes
dos work processes. Existe uma relao de 1 para 1 entre estes processos e os work
processes da instncia R/3 e eles s aparecem quando o R/3 est no ar
Shared processes: so os processos criados no Oracle para gerenciamento e funcionamento
da instncia que ir controlar o banco de dados. Eles tem atividades especificas e trabalham
para a manuteno da instncia como um todo.

Os dados so armazenados em datafiles organizados em blocos de 8k (8192 bytes). Estes blocos

so carregados para uma rea comum da memria principal denominada database buffer pool.
Sempre que uma leitura feita pelo menos dois blocos so carregados, um para header e outro para
dados. Cada bloco do DB buffer pool contm um header com os dados das transaes que podero
compartilhar o mesmo bloco. O nmero de entradas no header configurado pelo parmetro
INIT<SID> do .ora.

As alteraes efetuadas nos dados do banco de dados so feitas inicialmente no database buffer
com a imagem anterior copiada para a rea de rollback e refletidas na redo log files garantindo com
isso a segurana transacional dos dados. Estes redo log files so espelhados por questes de
segurana. Os control files no so espelhados mas deve possuir mais de uma cpia, tambm por
motivos de segurana. Para verificar quantos control files existe utilizem a view v$controlfile atravs

Pgina 108
ACADEMIA BASIS

de sql ou da ST04. Para criar mais uma cpia do control file, copie o arquivo para o local desejado e
altere o parametro control_file no initSID.ora acrescentando o novo caminho, tudo isto com o oracle
no estado NoMounted. Se for necessrio acessar o controlfile com o banco for a do ar o estado do
banco deve ser Mounted.

Os comandos SQL executveis ficam armazenados em outra rea da memria denominada

Shared SQL area que tambm parte do shared pool. Nesta rea temos ainda Library cache com os
cursores de execuo dos comandos SQL e a Row cache, com informaes dos objetos no dicionrio
Oracle.

Os work processes do R/3 se conectam com os shadow processes no Oracle com o usurio
SAPR3. Caso esta conexo caia, os work processes tentam reconexo com o Oracle seguindo a
parametrizao feita nas profiles (default ou instance) atravs das variveis rsdb/reco_trials e
rsdb/reco_sleep_time. Uma instncia Oracle aceita 3 tipos de conexes de seus clients: dedicated,
que a utilizada pelo R/3, Combined e Multi-thread.

Os principais problemas de performance esto associados a shared pool (shared sql area e row
cache), ao uso dos data buffers e a redo log. Outro ponto de preocupao o acesso a disco, sua
estruturao de alocao e a possvel conteno causada pelo acesso ao disco.

Obs: Conceito Importante - O check point uma marca de sincronismo entre todos os datafiles e
a online redo logfiles. Sempre que ocorrer um switch no online redo logfiles gravado um check point
para garantir a segurana e sincronismo. Se o banco estiver em archivelog mode, a offline redo logfile
archivada no diretrio saparch logo aps o switch.

Starting and Stoping the Database

O banco de dados Oracle passa por trs fases distintas ao ser inicializado:
Nomount phase: a instncia Oracle construda (shared pool) a partir das informaes
parametrizadas no arquivo init<SID>.ora
Mount phase: o control file aberto e suas informaes referentes aos logs e datafiles so
obtidas mas no podemos acessar os datafiles atravs de um sql.
Open phase: todos os files so abertos. Se o ltimo shutdown no foi realizado com sucesso,
o sistema efetua um rollback das transaes inflight e retorna todos os arquivos ao ultimo
ponto de sincronismo (check point). Os processos podem ento comear a submeter requests
ao banco de dados aberto.

O shutdown pode ser realizado em trs formas distintas tambm, a crittio do administrador:
Shutdown Normal: O sistema para de aceitar novas conexes e aps o encerramento de
todas as conexes j efetuadas os datafiles so fechados, o database desmontado e a
instncia finalmente sai (shutdown)
Shutdown Immediate: Apenas os comandos j em andamento so terminados. Todas as
conexes so derrubadas atravs do PMON e caso exista alguma transao inflight, feito
um rollback antes da instncia sair atravs de um shutdown consistente, ou seja, um check
point gravado. No sapdba ainda temos shutdown immediate force que retira o R/3 antes de
derubar o oracle.
Shutdown Abort: Em casos de emergncia apenas, este comando derruba todas as
conexes e retira a instncia do ar colocando o banco de dados em um estado de
inconsistencia. O prximo startup precisar efetuar um recovery das transies que
permanecero inflight, at que a base volte a ser consistente (roll foward)

Oracle Shared Processes

Uma instncia Oracle possui trs processos cuja finalidade gravar os dados da SGA (shared
global area) para os datafiles
Database writer (DBWR): que assincronamente grava os blocos alterados do data buffer para
os database data files.
Checkpoint process (CKPT): que acelera o processo de gravao dos checkpoints na

Pgina 109
ACADEMIA BASIS

Logwriter (LGWR): que grava em modo sncrono as alteraes efetuadas nos data buffer e
logadas na redo log buffer para os online redo log files

Um banco de dados em produo deve sempre rodar em ARCHIVELOG mode. Neste caso um
quarto processo, o archive (ARCH), grava os online redo log files para a rea de archive da instncia.
Os arquivos do online redo log files funcionam de forma cclica e a cada switch, o file que estava
sendo usado transferido para a rea de archive. O parmetro da init<SID>.ora,
log_archive_start=TRUE ativa o processo de archive na instncia. O processo ARCH se baseia nos
parmetros log_archive_dest (default $ORACLE_HOME/saparch) e log_archive_format para gerar o
archive na offline redo log area. Quando o online redo log file foi transferido com sucesso, o
respectivo file fica disponvel para ser sobrescrito no processo cclico de utilizao dos files.

Caso no haja espao disponvel na offline redo log area para a gravao do novo file, o online
redo log file no liberado e consequentemente ir travar a instncia quando o ciclo requisitar
novamente o online redo log file, devendo a rea ser liberada para que o Oracle continua com o seu
funcionamento normal.

R/3 Oracle Structure

A estrutura de tablespaces do R/3 no Oracle obedece a um padro especfico de nomes:

PSAP<name>[D para data e I para index]. Por exemplo, se uma rea de dicionrio do R/3 ficar
armazenada nos tablespaces PSAPDDICD (dados) e PSAPDDIC (ndices). Esta nomenclatura
obrigatria para o uso do R/3 e suas ferramentas.

As tablespaces que normalmente so criadas nas instalaes so :

Prefix Tablespace Ext. Meaning 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 Mdulos do ambiente de desenvolvimento Basis
PSAP ES<release> D ou I Fontes do ambiente de desenvolvimento Basis
PSAP LOAD D ou I Mdulos das janelas e relatrios Basis
PSAP SOURCE D ou I Fontes das janelas e relatrios Basis
PSAP DDIC D ou I Dicionrio abap Basis
PSAP PROT D ou I Tabelas do tipo log Aplicaes
PSAP CLU D ou I Tabelas cluster Aplicaes
PSAP POOL D ou I Tabelas pool Aplicaes
PSAP STAB D ou I Tabelas de dados mestres ou transparentes Aplicaes
PSAP BTAB D ou I Tabelas de dados transacionais ou transparente Aplicaes
PSAP DOCU D ou I Documentaes, sapscripts e sapfind
PSAP USER1 D ou I Tabelas do cliente Aplicaes

Os datafiles que compem o tablespace tambm devero possuir uma estrutura prpria de
$ORACLE_HOME / sapdatan / <name>[d/i]_n / <name>[d/i].datan. O sapdatan
normalmente um mount point (sapdata1, sapdata2, etc.). Caso o tablespace do exemplo acima
tivesse dois datafiles e alocado no sapdata5, os arquivos teriam o seguinte nome:
/oracle/<SID>/sapdata5/ddicd_1/ddicd.data1 e .../ddicd_2/ddicd.data2. Os data files de ndices
obedeceriam o mesmo critrio, apenas o nome seria ddici, e no ddicd (.../ddici_1/ddici.data1)

Todos os objetos alocados nos tablespaces PSAP... pertencem ao usurio SAPR3. Os

tablespaces SYSTEM, PSAPROLL e PSAPTEMP possuem objetos que pertencem aos usurios SYS
ou ao SYSTEM. O usurios que se logam em um sistema R/3 no possuem objetos nas tabelas do
Oracle, apenas armazenam linhas nas tabelas do banco de dados atravs da conexo efetuada com
o user SAPR3

A estrutura de diretrio do Oracle com o R/3 obedece a seguinte hierarquia :

/orant (oracle home)

Pgina 110
ACADEMIA BASIS

database: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora,

init<SID>.sap, etc.).
bin: executveis Oracle (no NT ele est no /orant/bin)
/net80/admin: arquivos de configurao do NET8
/oracle/<SID> (sapdata home)
sapdata1,2,...: onde se localizam os data files
origlogA, origlogB: online redo log files
mirrlogA, mirrlogB: mirror online redo log files
saptrace/background: Oracle alert files
saptrace/usertrace: trace files dos shadow oracle processes
sapereorg: rea de trabalho para reorganizaes, compress de backup files, etc.
saparch: offline redo log area e logs do BRARCHIVE
sapbackup: BRBACKUP e BRRESTORE logs
sapcheck: sapdba logs (-next, -check, -analyze)

Dentro do database, existem basicamente trs arquivos de parametrizao:

init<SID>.ora: parametrizaes da instncia Oracle
init<SID>.dba: parametrizao do sapdba
init<SID>.sap: parametrizao das ferramentas BRBACKUP e BRARCHIVE

Vrias variveis de ambiente parametrizam o usurio <sid>adm :

ORACLE_SID=<SID>: nome da instncia
DBS_ORA_TNSNAME: seta o <SID> do banco que ser conectado atravs do
tnsnames.ora
ORACLE_HOME: o diretrio home do oracle (/oracle/<SID>)
SAPDATA_HOME e SAPDATAn: aponta para diretrios especficos contendo dados

Alm dos usurios Oracle SYS e SYSTEM, existem os seguintes usurios no unix :
ora<sid>: usurio unix pertencente aos grupos dba e oper
<sid>adm: usurio unix pertencente ao grupo oper
OPS$<sid>adm: usurio definido no oracle como identified externally

<sid>adm: usurio NT pertencente ao grupo ora_SID_dba

sapservice<sid>: usurio NT pertencente ao grupo ora_SID_oper
OPS$<sid>adm: usurio definido no oracle como identified externally

Quando o parmetro OS_AUTHENT_PREFIX=OPS$ codificado no init<SID>.ora, isto indicar

que o usurio <sid>adm (OPS$<sid>adm) poder se conectar ao oracle sem autenticao. Isto
ser necessrio para determinadas tarefas restritas de administrao. Neste caso a autenticao do
fica a cargo do sistema operacional.

O mecanismo de conexo dos work processes com o shadow process no Oracle funciona da
seguinte forma: o work processes tenta a conexo atravs do usurio SAPR3/SAP. Caso a senha
tenha sido alterada, o que aconselhvel, a conexo recusada e o work process tentar uma
conexo atravs do usurio OPS$<sid>adm (que no exige autenticao) e acessa a tabela
SAPUSER (cujo owner o prprio user OPS$<sid>adm) e atravs dela possui a senha para o

O programa chdbpass (no unix) quando utilizado para alterar a senha do usurio SAPR3 j grava
nesta tabela OPS$<sid>adm.SAPUSER a nova senha. O NT que no possui este programa
disponvel o que torna necessrio a incluso manual da senha na tabela quando se altera o usurio
via alter user. A conexo remota dos work processes entretanto com o banco R/3 atravs do user
OPS$ somente se dar se o parmetro REMOTE_OS_AUTHEN estiver setado para TRUE.

NET8 Basis

A comunicao dos work processes com o Oracle se d atravs de comunicao TCP/IP atravs
da rede. A camada Oracle que interpreta e aceita estas conexes o NET8. Para que o NET8 aceite

Pgina 111
ACADEMIA BASIS

conexes atravs da rede, o listener do Oracle precisa estar ativo. O utilitrio lsnrctl80 utilizado no
database server para dar start e stop no processo tnslsnr que executar o servio.

.../net80/admin do oracle configuraro o servio NET8:

tnsnames.ora: contm a lista dos servios para todos os bancos de dados acessados na rede
sqlnet.ora: contm, no lado client, informaes do default domain alm de parmetros
opcionais de diagnsticos usados para trace e logs do client
listener.ora: usado no database server e contm Oracle system Ids com o quais o Oracle
poder receber conexes e parametrizaes do listener

Database Monitoring

Vrias transaes so utilizadas no R/3 para monitorar a base de dados: A DB16 um system
check monitor, a DB12 o monitor de backup, a DB02 a transao utilizada para monitorar os objetos
(tableas, ndices, tablespaces) do banco. Alm destas, a ST04 o monitor de performance e a DB14
o monitor das logs das atividades administrativas do banco.

Pgina 112
ACADEMIA BASIS

Backup Estrategy

Database Backup

A estratgia de backup da base de dados necessria para garantir a recuperao de uma base
de dados que pode falhar por diversos fatores, sejam fsicos (crash de disco), lgicos (operao
indevida nos aplicativos) ou fatores externos (fogo, agua, greve, etc). Atravs de cenrios que iremos
estudar, possvel fazer full recoveries (recuperao total) dos data bases ou ainda recuperaes
point in time (recuperao total em um ponto do tempo passado) a partir de uma boa estratgia de
backup.

Operaes de recovery, por serem crticas, exigem documentao detalhada, estratgia estudada
alm de skill especfico dos administradores de banco de dados. Ou seja, antes de tomar qualquer
ao aps um problema, tenha certeza do que est sendo feito e de que a ao a melhor opo
entre outras analisadas.

Os files que compem uma base de dados Oracle podem ser divididos em cinco grupos:
Os data files so os arquivos que contm os dados da aplicao propriamente ditos.
aconselhvel que sejam protegidos por espelhamento (RAID V ou superior)
Os online redo log files so os arquivos onde so gravadas as logs de transaes no banco
de dados e so espelhadas por definio atravs das mirrlogs
Os control files so os arquivos que possuem as informaes de controles referentes aos
datafiles e a base de dados. O Oracle mantm cpias deste file em mais de um filesystem do
ambiente, definido por parmetro na initSID.ora
Profiles so os arquivos de configurao da instncia oracle
Offline redo log files so as cpias das online redo efetuadas pelo ARCH no momento dos
switch. recomendado que estes files sejam espelhados e, quando transferidos para fita,
sejam replicados em fitas distintas

Um processo de backup de banco de dados copia para outro dispositivo os data files, os online
redo log files, os control files e as profiles. Um processo de backup do offline redo log file copia os
offline redo log files e as profiles para outro dispositivos. Para garantir a integridade fsica da base
de dados ou seja, garantir que as tabelas e blocos estejam fisicamente ntegros necessrio efetuar
logical data checks atravs de ferramentas oracle como o utilitrio dbv (database verify). Temos
integridade das fitas backupeadas necessrio efetuar um physical data
check, que verifica a integridade fsica das fitas gravadas atravs da leitura dos dados backupeados
na fita.

Backup Types

Um processo de backup offline executado com a instncia em shutdown e os seguintes

arquivos so copiados: data files, online redo log files, control file e profiles (init<SID>.ora, .sap e
.dba). Um processo de backup online executado com a instncia ativa e os seguintes arquivos so
copiados: data files, control file e profiles. Estas cpias online no so consistentes, j que o processo
de update no banco continua sendo efetuado pelos usurios. Um recovery a partir de um online
backup somente tem sentido com o cruzamento das logs (redo logs) geradas no decorrer do
processo. Um processo de partial backup pode ser utilizado para diminuir o tempo gasto no
processo. Neste caso apenas alguns tablespaces sero copiados em cada dia at fechar um ciclo.
Independente do processo utilizado (offline ou online) este backup inconsistente e precisa das
offline redo log de todo o ciclo para permitir um recovery do database.

Outro processo para diminuir a janela de backup atravs do paralelismo do backup com a
utilizao de vrios drives de fita. Este processo reduz significantemente o tempo de backup e
restore, sendo porm caro pelo hardware envolvido.

Pgina 113
ACADEMIA BASIS

Backup and Recover Diagram

Backup

ArchiveLog NoArchiveLog

On-Line Off-Line

Complete Incomplete Reset

Recover Recover
with
reset log

Data Loss

Vrias so as causas que podem causar a perda de dados em uma base de dados.
podem ocorrer pela deleo indevida de objetos do banco de dados (um data file), um drop em uma
tabela ou ainda por erro de aplicativo que provoca a perda de dados. Erros lgicos so recuperados
um full database restore seguido de um point in time recovery at o momento
imediatamente anterior a causa da perda da informao.

A ausncia de um offline redo log file durante um processo de recovery causar a perda de
todas as informaes subsequentes, j que o processo no permite a aplicao dos offline seguintes
ao que foi perdido. Por este motivo importante a manuteno de pelo menos
redo log files em dispositivos diferentes para garantir uma recuperao com uma salva-guarda de
contingencia.

Uma outra causa de necessidade de recuperao o chamado disaster recovery, efetuado por
causas fsicas, como por exemplo um crash de disco. A manuteno de cpias de backup em cofres
garantem inclusive a possibilidade de recuperao de todo o ambiente computacional em caso de
perda total das instalaes fsicas do cpd.

Backup Recommendations

Alteraes nas estruturas dos arquivos afetaro os restores subsequentes, como ocorre por
exemplo quando um data file acrescentado a base de dados. Processos como este que causam a
backup adicional imediato do banco de dados
para que o processo de recuperao, se houver, no seja afetado pelo diferente estado do banco de
dados. O ponto crtico de uma alterao estrutural do banco de dados a necessidade de ter ao
menos uma cpia do novo datafile e a estrutura gerada no control file. Sem isto impossvel
recuperar o banco na nova estrutura ou fazer um log-foward aps este evento.

Backup Cycle

A SAP recomenda um ciclo de backup de 4 semanas. Isto significa que os offline redo log files
sero backupeados diariamente e mantidos por 28 dias. O backup online deve seguir a mesma regra,

Pgina 114
ACADEMIA BASIS

ou seja uma cpia a cada dia til do ciclo. importante ainda que tenhamos em cada ciclo pelo
menos um backup offline, um check de consistncia do backup e check dos datafiles do banco de
dados. Esta recomendao bsica, sendo o ideal fazer tudo isso pelo menos uma vez a cada
semana. recomendvel tambm que os arquivos do backup online fiquem em fitas diferentes do
backup do offline redo log. Isso viabiliza novas alternativas para os planos de contingencias caso as
fitas tambm apresentem problemas.

Final Recommendations

Utilize as ferramentas providas pela SAP para efetuar o backup (BRBACKUP e BRARCHIVE) e
tenha certeza que elas esto configuradas corretamente. Para um evetunal restore do banco de
dados utilize a ferramenta BRRESTORE. Estas ferramentas que efetuam o backup e o restore
trabalham integradas ao sapdba e se baseiam em logs prprias gravadas no sistema operacional
para direcionar o seu funcionamento.

bom lembrar que alm do banco de dados, necessrio manter backup consistente de outros
objetos R/3, tais como archiving, interfaces, executveis e do sistema operacional. No adianta muito
ter o backup da base de dados se no tivermos o R/3 e o Oracle instalados e com os arquivos de

S a correta implementao de uma boa estratgia de backup a garantia para a recuperao do

sistema sem perda de informaes em caso de falhas.

Pgina 115
ACADEMIA BASIS

Tape Management

Tape Pools

Os utilitrios BRBACKUP e ao BRARCHIVE que permite a gerencia do pool de fitas utilizadas na

estratgia de backup, permitindo encontrar as fitas necessrias no momento do backup e do recovery
e garantindo a sua proteo contra utilizao das fitas antes do momento desejado. O sistema
trabalha com um pool separado para as fitas utilizadas pelo BRBACKUP e outro para o BRARCHIVE
evitando misturar as fitas destinadas aos backups de datafiles e dos offline redo log files. As fitas
inicializadas para um pool no podem ser utilizadas no outro pool

O nmero de fitas utilizadas no pool do BRBACKUP depender de vrios fatores, como tamanho
do banco, durao do ciclo, capacidade das fitas, frequencia e paralelismo dos processos de backup.
J o nmero de fitas do pool utilizado pelo BRARCHIVE depender do tamanho do ciclo, nmero de
redo logs criadas no ambiente (atualizaes), capacidade das fitas e frequencia dos offline redo
backups.

Tape Initialization

As fitas so inicializadas pelo brbackup ou brarchive atravs da opo (inicializa novas

fitas, fitas no utilizadas alteriormente pelo SAP ou fitas bloqueadas para gravao),
<tape_name> (renomea fitas que no esto bloqueadas para uso) ou (para fitas
scratch). Na prtica o processo de inicializao consiste na criao de um arquivo .tape.hdr0 no inicio
da fita para identifica-la no momento de uso. Dentro deste arquivo temos informaes do nome da
fita, do noma da instncia na qual ela est sendo utilizada, o timestamp da ultima utilizao e o
numero de utilizaes feitas at o momento. Os dois utilitrios sempre acessaro este arquivo para
decidir se a fita a esperada e se ela est disponvel para uso. Eles levaro em conta os parmetros
(expir_period com default de 28 e tape_use_count com default de 100) definidos na init<SID>.sap,
sendo que o tape_use_count excedido provoca apenas uma mensagem de warning.

O padro de nome a ser utilizado nas fitas <SID><B|A>99 onde o B|A representa o grupo onde
ela ser utilizada (backup ou archive) e 99 um nmero sequencial. O nome das fitas que esto
disponveis para utilizao esto nos parmetros volume_backup e volume_archive do init<SID>.sap.

Tape Locking

O mecanismo de lock protege a fita de sobre escrita. Este mecanismo funciona baseado no
parmetro expir_period que fornece o ciclo de proteo da fita baseado no timestamp do ltimo
backup l gravado (informao no label). Este mecanismo denominado

Um outro mecanismo de proteo denominado SDBAH e

SDBAD. Elas contm informaes das fitas gravadas no perodo e so mantidas pelo BRBACKUP e
BRARCHIVE. Baseado nas entradas desta tabela e no pool de fitas gravado nos parmetros
volume_backup e volume_archive, o sistema verifica se uma determinada fita est liberada para
gravao reforando o mecanismo de lock das fitas.

O BRARCHIVE pode se basear em informaes de suas logs para efetuar o lock lgico, podendo
desta forma ser executado mesmo quando o banco se encontra offline. A fita seguinte a ltima
utilizada no pool a selecionada para utilizao.

Tape Selection

As ferramentas SAP oferecem trs mecanismos para seleo das fitas:

mecanismo automtico permite que o BRBACKUP e BRARCHIVE selecione a fita baseado
em seus mecanismos de lock e no pool de fitas fornecido nos parmetros volume_backup e

Pgina 116
ACADEMIA BASIS

volume_archive. A chamada destes programas com a opo q permite verificar qual ser a
prxima fita selecionada para uso. Se for necessrio utilize a opo para verificar se
a fita que est montada a fita esperada pelos utilitrios.
mecanismo manual de seleo atravs da opo SCRATCH. Quando uma fita inicializada
com o nome SCRATCH inserido no sistema, o BRBACKUP e o BRARCHIVE a aceita em
substituio a fita requisitada e grava o novo label nela antes de comear a gravao. til
por exemplo para substituir uma fita do pool danificada. Alternativamente, possvel substituir
o pool de fitas informado no init<SID>.sap pelo parmetro SCRATCH. Neste caso o sistema
no sugere uma fita, apenas pede uma cujo operador fica responsvel pela manuteno do
seu schedule. Ainda neste caso os mecanismos de lock funcionam apenas para proteo de
uso indevido das fitas
mecanismo de seleo externa utilizado atravs da opo v e til quando um shell ou
produto externo utilizado para gerenciamento das fitas. O label neste caso tambm ser
checado pelos mecanismos de lock lgico. Todo este processo utiliza uma outra ferramenta de
interface com o mundo externo que o BACKINT.

Tape Layout

O layout bsico de gravao da fita praticamente o mesmo para o BRBACKUP e o BRARCHIVE

(as diferenas ento marcadas abaixo), a saber :
tape.hdr0
init<SID>.ora (configurao do oracle) e init<SID>.dba (configurao do sapdba)
init<SID>.sap (configurao do brbackup e brarchive)
diferenas
Para o BRBACKUP
DB files
Control files
Para o BRARCHIVE
Offline redo log files
reorg.log (informaes de reorganizaes, restore e recover) e struct.log (histrico das
alteraes de estruturas do banco)
detail.log (log do processamento)
summary.log (lista dos processamentos j realizados)

Pgina 117
ACADEMIA BASIS

Scheduling, Performing and Monitoring Backups

Backup Tools Features

Para fazer um backup podemos utilizar uma das ferramentas :

Transao DB13 - DBA Planning Calendar - onde possvel schedular backups peridicos em

Utilitrio SAPDBA onde possvel ativar backups espordicos de forma interativa por menus e
vrias outras operaes de administrao e operao do oracle
BRBACKUP e BRARCHIVE onde e possvel realizar backups a partir de linha de comando

Backup profile parameters

Alguns dos parmetros podem possuir valores default definidos na profile init<SID>.sap, como por
exemplo o tipo de compresso, comando para compresso, utilitrio para cpia, dispositivo a ser
utilizado, etc. Os utilitrios brbackup e brarchive atualizam as tabelas SDBAD e SDBAH, checa o lock
de fitas e gera logs especficas das atividades efetuadas sempre levando em conta a parametrizao
feita neste arquivo.

tape_size Parameter

O parmetro tape_size da init<SID>.sap define o volume de dados que cabe no modelo de fita
utilizado tanto para o BRBACKUP quanto o BRARCHIVE. Este parmetro importantssimo j que a
sua m especificao pode causar mal funcionamento do processo de backup. Atravs da
especificao do parmetro tape_size os utilitrios de backup (BRBACKUP e BRARCHIVE) calculam
o volume de dados que pode ser enviado para cada fita, dimensionando desta forma o nmero de
fitas que sero necessrias durante o processo. Quando mal dimensionado pode causar o
desperdcio de mdia ou, pior ainda, erro no processo de gravao. O utilitrio dd utilizado no
processo de cpia acusa erro quando atinge o end-of-tape. J o utilitrio cpio, desde que no esteja
trabalhando em modo parallel, consegue passar os dados para um volume subsequente, porm este
volume no ser reconhecido pelas ferramentas de gerencia de fitas por ter sido requisitado ao longo
do processo e no possuir o arquivo de identificao da fita (.tape.hdr0). O ideal portanto que este
10% menor que a capacidade real da fita, como margem de
segurana.

Quando utilizamos compresso por hardware, o valor do tape_size dever ser ainda um pouco
mais folgado, uma vez que a taxa de compresso varia dependendo do tipo de dado armazenado. A
nota 8707 d todos os detalhes sobre esta especificao de tape_size.

Para distribuir os files pelas fitas, o brbackup utiliza informao da dos files.
Este clculo da taxa de compresso dever ser efetuado uma vez a cada ciclo atravs do comando
. Quando utilizado tape stations com hardware compression, o parmetro
compress_cmd da init<SID>.sap dever ser setado para compress b 12 c $ > $ (em unix). A
compresso por software efetuada no diretrio especificado (compress_dir) e consumir ciclos de

Phases of Database Backup

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

Pgina 118
ACADEMIA BASIS

Faz um log file switch

Backup de logs (reorg.log, struct.log, detail.log, summary log)

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

Database Backup Check and Monitoring

Blocos de dados danificados no banco de dados somente so identificados quando o Oracle tentar
manipular este bloco. O utilitrio dbv da Oracle efetua o check de um datafile quanto a estas
integridades.

Esta verificao lgica da integridade dos dados pode ser realizada em tempo de backup atravs
. Este processo faz com que os files
sejam lidos da fita aps gravados e transferidos para o diretrio de compress (compress_dir) onde
so processados pelo utilitrio dbv da Oracle. O processo alm de detectar blocos corrompidos
garante a disponibilidade da fita. aconselhado que seja efetuado uma vez por semana ou no
mnimo uma vez no ciclo. Como este processo pelo menos duplica o tempo gasto no backup,
possvel adiar a execuo do verify atravs de uma execuo posterior de uma simulao de
BRRESTORE, que pode inclusive ser executado em outra mquina. (Para maiores informaes de
datafiles corrompidos veja a nota 99962).

A opo de verificao da integridade lgica (-verify use_dbv) verifica a integridade dos blocos
Oracle porm no garante que o file gravado na fita seja idntico ao file existente no disco. Esta
verificao da integridade fsica dever ser efetuada uma vez no ciclo, que ocorrer a nvel binrio
com a especificao do parmetro (-verify ou w). Este processo de verificao fsica somente pode
ser executado no processo de backup offline e tambm ir provocar a leitura da fita para que o file
seja transferido para a rea de compress. Este processo duplica o tempo de backup e,
diferentemente do anterior, no pode ser postergado para um posterior BRRESTORE.

O BRBACKUP grava logs em files no diretrio sapbackup e nas tabelas SDBAH e SDBAD que
devem ser checados constantemente. Os logs gravados obedecem a um padro prprio de
nomenclatura (b<timestamp>.<ext>) cuja extenso depende do tipo de backup selecionado. As
transaes DB12 e DB13 tambm permitem acompanhar a execuo dos backups

Offline Redo Log Files Backup

O processo Oracle ARCH responsvel pela movimentao as Online redo log files durante o
switch de log. Estas logs so transferidas para a rea saparch e devem ser transferidas para fitas de
tempos em tempos. Este processo denominado Offline redo log backup e efetuado pelo programa
BRARCHIVE. O BRARCHIVE loga o status dos offline redo log files em um arquivo denominado
arch<SID>.log, que se localiza na saparch e grava linhas referente s atividades executadas com os
redo log files :
ARCHIVED: estado indicando que o file foi arquivado
SAVED: indicando que uma gravao para fita foi efetuada
COPIED: indicando que uma segunda cpia foi efetuada
DELETED: indicando que o file foi deletado do diretrio

Pgina 119
ACADEMIA BASIS

O BRACHIVE possui uma serie de opes para o backup dos archive logs. A SAP aconcelha a
no BRARCHIVE que faz com que esta gerencia de backup duplo
de offline redo log files com posterior deleo seja efetuado automaticamente. Outra boa opo e
a opo f (fillup) onde o brarchive grava os files e continua verificando a saparch de tempos em
tempos. Qualquer offline que aparea ento gravado at que a fita esteja cheia.

Como no BRBACKUP, devemos utilizar a opo verify ou w para efetuar um check fsico dos
arquivos gravados e recomendado que seja efetuado uma vez no ciclo.

A monitorao do processo de offline backup dever ser efetuado atravs da transao DB12 e
atravs da monitorao do arch<SID>.log no diretrio saparch. Atravs da
forar a gravao de mais informaes na log.

Log File Cleanup

Os logs gerados tanto pelo BRBACKUP quanto pelo BRARCHIVE so utilizados posteriormente
pelo SAPDBA para tomar as aes corretivas e parametrizar o BRRESTORE. Estes files porm vo
se acumulando nos diretrios e precisam ser eliminados de tempos em tempos. O SAPDBA possui
clenup no s destes logs como tambm dos traces e logs geradas pelo
Oracle e pelo prprio sapdba. A limpeza dos logs de backup e archive se baseia nos parmetros
expir_period_* da init<SID>.dba. Estes parmetros devero ser adaptados de acordo com o ciclo de
backup adotado na empresa. A chamada a estas funes poder ser executado interativamente via
em linha de comando ou via algum utilitrio de
agendamento do sistema operacional.

Freespace Administration

Os offline redo log files so transferidos para a rea de archive saparch atravs do servio Oracle
ARCH. Se estes arquivos no forem backupeados para fita e deletados, a rea poder estourar, o
que causa a parada do Oracle conhecida como archiver stuck. Neste caso a instncia para por no
poder sobrescrever um online redo log file ainda no transferido para a rea de offline. Este problema
somente ocorre se o ARCHIVELOG mode estiver ativado, o que padro em ambientes produtivos.
Atravs da DB12 deve-se monitorar a rea livre no diretrio (ou atravs de df k) e tomar medidas
preventivas (archive) antes que o problema ocorra.

Outra soluo que pode ser adotada a definio de um arquivo dummy grande o suficiente para
que, em caso de archiver stuck, ele possa ser removido dando ao sistemas mais alguns minutos
enquanto se processa o archive. Caso o sapdba no mais responda a comandos, ative o brarchive
via linha de comando

One-Run Strategy

A estratgia One-Run backup consiste em efetuar o backup e o archive em uma nica chamada
ao brbackup atravs da especificao de parmetros prprios ( ).
Neste caso apenas uma fita do pool backup (volume_backup) utilizada para armazenar os dois
backups. Esta estratgia porm s pode ser utilizada se o backup dos datafiles e todos os offline
redo log files couberem em uma nica fita. A soluo neste caso o uso de paralelismo no backup
(mais de um drive) ou ento adotar outra estratgia para o backup.

Esta soluo possui o incoveniente dos datafiles e ds offline redo log files estarem na mesam fita.
Alm disso, em caso de um archiver stuck ocorrer, esta opo no poder ser usada, j que o
brbackup tentar se conectar com o banco que se encontra travado.

Further Documentation

Para maiores informaes sobre backup e recover, veja as notas 96896, 19909, 99088, 71058,
8707, 33630, 99962, 23345, 100400 e 83699.

Pgina 120
ACADEMIA BASIS

Advanced Backup Techniques

One-Run Strategy

Consiste em executar em uma nica chamada o backup dos datafiles e offline redo log files.

Principais vantagens:
Atende a maioria das instalaes, sendo portanto recomendada pela SAP
Efetua os dois processos em uma nica chamada, garantindo backups consistentes

Principais desvantagens:
backup e os offline redo devem caber em uma nica fita

Consistent Online Backup

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

Parallel Tape Support

Atravs do parmetro tape_address do init<SID>.sap, o brbackup permite a gravao de vrias

(at 4) devices em paralelo. Neste caso o parmetro exec_parallel deve ser setado para 0 e os
utilitrios vo disparar o processo de cpia (dd ou cpio) um por device fsico. O processo de offline
redo log file backup permite at 2 devices atravs da especificao do parmetro tape_address_arch.
O BRRESTORE tambm ir utilizar os vrios devices em paralelo

Principais vantagens:
Menor janela de backup e restore

Partial Database Backups

uma forma de executar o backup de um ou mais tablespaces por vez ou at parte dos
tablespaces de cada vez, de tal forma que em um intervalo menor que o ciclo adotado, todos os
tablespaces sejam copiados. Durante um recovery com este tipo de backup, todas as offline e online
redo log files geradas desde o incio do primeiro tablespace devem estar disponveis. . ativado
e completado por um brbackup m all f <periodo>.

Principais vantagens:
Menor janela de backup

Principais desvantagens:
Administrativamente mais complexo
Maior tempo de restore

Backing Up Data Tablespaces Only

Uma outra opo para diminuir a janela de backup atravs da especificao para copiar apenas
os tablespaces que contenham dados, ignorando os que contm apenas ndices ou estejam vazios. .
ativado atravs da chamada brbackup m all_data

Pgina 121
ACADEMIA BASIS

Principais vantagens:
Diminui o volume de dados que sero backupeados

Principais desvantagens:
Aumenta o tempo de restore j que ser necessrio reconstruir os ndices

Two-Step Disk Backup

Inicialmente o backup feito para uma rea em disco (direcionado pelo parametro
backup_root_dir), que um processo bem mais rpido. Em um segundo step, os arquivos so
transferidos do disco para a fita. ativado atravs da chamada que faz o
primeiro step e para o segundo step b last d tape. Nesta opo tambm podemos fazer o primeiro
step de forma paralela. Para isso basta utilizar o parametro exec_parallel e um conjunto de diretrios
destinos para o backup em disco.

Principais vantagens:
Diminui sensivelmente a janela de indisponibilidade ou concorrncia sobre o database
Um restore pode ter seu tempo sensivelmente diminudo, j que os dados do ltimo backup
permanecem no disco

Principais desvantagens:
necessrio um gasto maior com discos fsicos apenas para o backup

Structures-Retaining Database Copy

um processo que consiste em copiar toda a rvore do Oracle home para um novo diretrio.
um processo que pode ser utilizado por exemplo para transformar um data base de filesystem para
raw device, e vice versa. ativado atravs da chamada brbackup d disk_copy e parametrizado
pelo parmetro new_db_home da init<SID>.sap.

Principais vantagens:
Diminui a janela de backup (disco para disco) e agiliza um possvel restore

Principais desvantagens:
Investimento em hardware (disco) alm da complexidade administrativa maior

Split Mirror Disk Backups

Consiste em abrir o espelho (split mirror) e efetuar o backup a partir de outro host no qual o
espelho ser montado. um processo que reduz drasticamente o downtime durante o backup que
dever estar em backup mode ou offline apenas durante o processo de quebra (split) dos espelhos,
que dura apenas alguns poucos minutos. . ativado atravs da chamada

Principais vantagens:
Baixssimo downtime
No h impacto no database server, j que o backup realizado a partir de outro servidor

Principais desvantagens:
Preo elevado da soluo

Pgina 122
ACADEMIA BASIS

SAP Tools and Oracle Standby Database

um mecanismo que consiste em um outro server com configurao idntica ao database que
se deseja backupear, permanecendo porm em estado de mount. A partir de um sincronismo inicial,
apenas os offline redo log files so responsveis por ir atualizando (via NFS) a verso do database
da instncia de standby, que possui ainda o diretrio sapbackup compartilhado via NFS. Os offline
backups sero transferidos para a nova instncia atravs do comando .
Na instncia de standby os offline so backupeados com a opo brarchive ssd f m <delay> e
os datafiles com a opo brbackup t offline_standby

Principais vantagens:
No h downtime no ambiente produtivo

Principais desvantagens:
Administrativamente mais complexo e exige investimento alto em hardware para replicar os
ambientes
Alteraes na estrutura do banco produtivo precisam ser replicadas manualmente para o
ambiente de standby

External Backup Tools Using BC-BRI

a utilizao de ferramentas externas para a execuo do backup que se comunicam com as

ferramentas da SAP atravs de uma interface SAP denominada BC-BRI. A ferramenta deve utilizar
as ferramentas brbackup e brarchive da SAP, mantendo desta forma a facilidade de monitoramento
via CCMS e permitindo a manuteno de todas as logs, o que permite o restore e recovery a partir do
sapdba. Esta opo configurada na init<SID>.sap pelos parmetros backup_dev_type =
util_file_online/offline e ainda util_par_file = init<SID>.utl, que parametriza a ferramenta backint

Principais vantagens:
Muito depende da ferramenta utilizada, que pode inclusive oferecer maiores facilidades de
gerenciamento de fitas que as oferecidas pela SAP

Principais desvantagens:
Investimento normalmente elevado em hardware e software

Pgina 123
ACADEMIA BASIS

Restore and Recovery

Database Errors

Os erros que podem ocorrer em aplicativos que utilizam bancos de dados so os seguintes:
Statement errors, que uma tentativa de entrada invlida em uma tabela. O oracle cuida de
abendar a transao e efetuar possveis rollback
Process errors, que uma falha na comunicao entre os processos client e os servios
oracle. Qualquer falha recuperada pelo oracle
Instance error, que pode causar um queda da instncia, mas que recuperada no prximo
startup pelos prprios mecanismos do oracle
User error, que provocado por uma ao acidental, como um drop table ou delete de linhas
indevidamente
Media errors, que so provocados por um crash de disco ou um delete datafile.

Os user e media errors devem ser recuperados atravs da ao do DBA, efetuando operaes
de restore e recovery. O sapdba oferece recursos para a maioria das recuperaes, porm
eventualmente pode ser necessrio utilizar ferramentas Oracle na recuperao

Scenario

Uma instncia R/3 com banco de dados Oracle tem todos os seus datafiles normalmente com o
status online e read/write. A sincronizao das alteraes efetuadas nestes files mantido atravs de
um mecanismo de tempo. O Oracle utiliza o conceito de timestamp para esta sincronizao, que um
inteiro que incrementado durante certas aes que so efetuadas no database. Este valor ento
gravado pelos processos DBWR e CKPT nos header dos datafiles e control files no checkpoint.

O Log Sequence Number (LSN) que incrementado por 1 a cada log switch um exemplo de
dado de sincronizao. O Oracle mantm tambm um nvel mais sofisticado de sincronizao das
transaes atravs so System Change Number (SCN) que incrementado pelo commit ou pelo
processo de checkpoint.

As anlises de cenrios seguintes assumiro que foi executado um full backup no LSN 10 e que
ocorreu um erro posteriormente no LSN 38

Partial Restore and Complete Recovery

O crash ocorrido no LSN 38 causou uma perda da funcionalidade do database, deixando o banco
inconsistente. O partial restore and complete recovery o processo de recuperar o banco de dados
at o momento imediatamente anterior a ocorrncia do erro. O conceito de partial restore consiste
em retornar apenas os datafiles que foram avariados. Aps este retorno o banco perde o
sincronismo e no mais poder ser startado.

Para ressincronizar o banco de dados, o oracle abre o banco em modo mount, avalia as
informaes gravadas no header dos files e comea o recovery requisitando os offline redo logs que
foram gerados desde o mais antigo database file, em sequencia, e reaplica as alteraes logadas
(before images) at sincronizar todos os files com o mesmo SCN. O prximo start do banco ir
efetuar um rollback das transaes que permaneceram inflight neste processo. O banco reaberto,
est operativo e apenas os dados no commitados no momento do crash sero perdidos

Database Reset

Um motivo qualquer, por exemplo um upgrade, deixa o banco em um estado inconsistente que se
percebe somente no LSN 38, e se deseja retornar o sistema para a posio do ultimo offline backup
efetuado(LSN 10). Este processo exige um full offline backup.

Pgina 124
ACADEMIA BASIS

O database reset esta operao de retornar o banco a situao exata do offline backup atravs
de uma operao de full restore. Este processo retorna os datafiles, online redo logs e control files
originais (LSN 10). Como estes files foram todos copiados a partir de um offline backup, o banco
retornado fica com o status consistente (mesmo LSN), no necessitando de nenhum processo de
recovery.

Quando o banco reaberto, ele recomea a criar redo log files a partir do LSN 10. Desta forma
sero regerados os offline redo logs 11, 12, ..., 38, etc. O perigo consiste em se necessitar de um full
restore posteriormente e se escolher os offline redo logs das duas diferentes direes. necessrio
um trabalho administrativo aqui, seja para eliminar as logs antigas manualmente ou providenciar um
novo backup offline to logo a LSN atinja o valor anterior, provendo o sistema de um novo ponto para
restore.

Este processo sempre resulta na perda dos dados gerados aps os backup offline, que so
sobrescritos no processo e suas offline redo logs ignoradas.

Point in Time Recovery

Esta uma situao em que se deseja retornar o banco at um ponto imediatamente antes de um
determinado fato ter acontecido (digamos na LSN 26), eliminando assim as suas consequncias
sobre a base de dados. O primeiro passo efetuar um full restore de todos os data files, seja a partir
de um offline ou de um online backup. Os control files neste caso devero especificar a situao
da estrutura do banco no ponto em que se deseja parar o recovery. Se o banco sofreu alteraes
estruturais durante este perodo, necessrio uma anlise e interferncia manual do DBA. O prximo
incomplete recovery. O banco de dados aberto em modo mount e todas as
offline redo log files necessrias at atingir o ponto especificado so requisitadas sequencialmente
e aplicadas na base de dados. Este point in time poder ser um timestamp (recover until time) ou
uma determinada offline redo log (recover until cancel), a critrio do DBA.

Aps um point in time recovery o banco de dados normalmente aberto com a opo de reset
logs (alter database open resetlogs), o que significa que o LSN reinicializado e as redo logs
comeam a ser geradas a partir do nmero 1 novamente. Isto somente no ocorrer se durante o
processo o DBA resolver aplicar todas as logs disponveis, efetuando assim um complete recovery. A
partir deste momento no mais possvel efetuar recovery da base de dados (logs foram
resetadas) e um full backup deve ser efetuado imediatamente.

How to Proceed and Who Should Manage the Problem

Qualquer necessidade de restore e recovery deve ser analisado com calma para decidir a melhor
estratgia a ser seguida. Em caso de dvida jamais se deve tomar decises e/ou aes aleatorias.
Decises/aes apressadas e erradas tendem a agravar o problema. Em caso de dvida, sempre
consulte DBAs com experincia em processos de recuperao de bases de dados.

Analise cuidadosamente a causa do problema, os backups disponveis, os offline redo log files
disponveis e comece a desenhar os possveis cenrios de recuperao, decidindo qual deles o
melhor a ser escolhido. Havendo tempo e disponibilidade, faa uma cpia full offline da base de
dados que possibilite retornar o problema se o cenrio de recuperao piorar a situao tomando

Caso o ciclo de backup tenha sido bem estruturado, o DBA tem sempre um grande nmero de
backups disponveis para proceder a recuperao. A opo inicial ser sempre pela mais recente,

Partial Restore Using SAPDBA

O SAPDBA executa o partial restore and complete recovery atravs de seis fases:
1. Check database: check do status dos files do banco

Pgina 125
ACADEMIA BASIS

2. Find backup files: a partir das logs de backup determina aquelas que podero ser utilizada,
sugerindo sempre a mais recente
3. Restore backup files: copia dos database files de volta para o disco
4. Find archive files: determina os offline redo log files necessrios para o recovery
5. Restore archive files: copia os offline redo logs necessrios de volta para o disco
6. Recover: cria recover scripts para efetuar a operao de recover

Este mtodo de recuperao simples e o mais seguro de ser efetuado, j que se aplica a maioria
dos casos de perda de dados. Se os control files ou os online redo log files foram perdidos, verifique o
help do R/3 (DBA Oracle) pois existem outros mecanismos mais rpidos para corrigir este problema
ao inves de voltar um backup.

Database Reset Using SAPDBA

O processo de reset database atravs do sapdba com um full offline backup ir sobrescrever os
datafiles, control files e online redo log files e permite que aps o restore o banco seja aberto em
mount e o DBA proceda um recover a partir do svrmgrl (server manager). Neste caso especifico,
operao manual do svrmgrl, no chamamos de database reset mas esta pode ser uma opo para

Quando se efetua um reset database a partir de um online consistent backup os data files e control
files so sobrescritos, assim como todas as offline redo log files, devendo portanto ser salvas
anteriormente pelo brarchive, conforme aconselhado pelo sapdba. Posteriormente o banco ser
aberto com a opo resetlogs.

Full Restore and Recovery Using SAPDBA

Esta a opo do sapdba que corresponde ao point in time recovery. Como este processo
envolve a perda de dados, um full offline backup recomendado antes de iniciar o procedimento,
alm de salvar todos os offline redo log files. Este processo poder partir de um full offline, full online
ou online consistente backup. Caso se tenha efetuado uma alterao na estrutura do banco,
recomendado que se faa um backup da estrutura alterada para que no caso de um restore e
recovery as alteraes possam ser reaplicadas a partir da sua log no sapreorg.

Pgina 126
ACADEMIA BASIS

Storage Management

Space Management

Todas as tabelas e ndices do Oracle so organizadas em data blocks armazenados nos

tablespaces. Estes data blocks com R/3 so de 8K. A necessidade de crescer um tablespace
efetuada atravs da incluso de datafiles ao tablespace. Esta operao quando efetuada pelo
sapdba, no final do processo o usurio direcionado para tirar um backup do tablespace alterado
garante que o tablespace poder ser recuperado em caso de um crash posterior . Quando uma tabela
ou ndice necessita de mais rea, alocado um segmento contguo (declarado no catlogo oracle) de
data blocks no tablespace com tamanho definido pelo parmetro NEXT de definio da table/index.
Caso o espao contguo no esteja disponvel ocorrer um erro ORA-1653 ou ORA-1654 (tabela ou
ndice). Uma tabela ou ndice inicialmente alocada baseado no parmetro INITIAL e posterior
extents de acordo com o parmetro NEXT at um limite MAXEXTENTS. Na tentativa de superar o
maxextents, ocorrer um erro ORA-1651 ou ORA-1652 (tabela ou ndice).

Os demais parmetros da clusula STORAGE do Oracle (PCTFREE, PCTUSED e

PCTINCREASE) no devem ser alterados exceto sob recomendao explcita da SAP.

Fragmentations

As linhas de dados das tabelas e ndices vo ocupando os data blocks e quando h necessidade
segmento NEXT. Estes segmentos no necessariamente estaro
contguos ao longo do tablespace, o que causar a denominada external fragmentation ou
fragmentao a nvel do tablespace.

Tabelas que contm raw fields, colunas opcionais ou registros de ndices so armazenados de
forma compactada. Com isto nem todas as linhas dentro de um data block possuem o mesmo
tamanho. A deleo de linhas destes objetos ir produzindo gaps internos nos data blocks
denominados internal fragmentation ou fragmentao a nvel da tabela.

Fragmentations in Data Blocks PCTFREE and PCTUSED

Os parmetros PCTFREE e PCTUSED determinam a forma como os objetos sero trabalhados

dentro dos data blocks. Enquanto o espao livre de um datablock no atinge o PCTFREE, ele
aceitar novas inseres. Quando este valor atingido, o data block para de aceitar inserts
assumindo que o espao livre restante ser utilizado para possveis crescimentos de linhas por
update. Qualquer insert subsequente ser direcionado para outro data block disponvel no segmento.
Somente quando aps deletes no data block causarem a disponibilidade de um espao livre inferior
ao PCTUSED, este data block retornar a aceitar inserts. Quando o update de uma linha no cabe na
rea reservada pelo PCTFREE, a linha migrada para outro data block. Apesar de ruim, no R/3 este

A gerencia dos data blocks que esto disponveis para inserts executada atravs de uma tabela
denominada free list. A m especificao destes parmetros para determinados objetos poder
causar uma grande movimentao dos data blocks nesta free list, o que ruim para a performance. A
Oracle recomenda que a diferena entre o PCTFREE e o PCTUSED seja de pelo menos de tamanho
suficiente para caber uma linha. Isto significa que basta um delete para que o data block retorne para
a free list. A SAP utiliza como padro os valores de 10% para o PCTFREE e 40% para o PCTUSED..

Daily Monitoring: SAPDBA -check

O check database efetuado pelo sapdba efetua uma srie de verificaes na base de dados e nas
configuraes do Oracle que cobrem a quase totalidade dos problemas comuns que podem ocorrer
no dia a dia de um DBA Oracle com o R/3. Atravs da DB13 deve-se schedular este check dirio

Pgina 127
ACADEMIA BASIS

(atravs do comando sapdba check) para monitorao da base de dados. Os dados analisados so
carregados na tabela DBMSGORA e podem ser monitorados atravs da DB16. Os parmetros
utilizados para comparao durante o check pdem ser configurados atravs da transao DB17.

Tablespace Extension

O critrio de alocao de data blocks dos objetos Oracle definido a partir dos parmetros
INITIAL, NEXT e MAXEXTENT. O INITIAL define a alocao inicial, NEXT o tamanho das alocaes
next que podero ocorrer MAXEXTENTS vezes. Devemos sempre lembrar que uma definio destes
parmetros que atendia uma determinada tabela/ndice, pode se tornar obsoleta a medida que uma
tabela comea a crescer. Por exemplo, um alocao NEXT de 16K faz sentido para uma tabela de
100K de tamanho, mas se torna completamente sem sentido quando esta tabela tem por exemplo
1G. O R/3 mantm uma tabela denominada TGORA (ou IGORA para ndices) que contm
especificao da parametrizao para diversos ranges de tamanho de tabelas/ndices. Estas tabelas
so organizadas por categorias de tabelas, de acordo com o atributo especificado para cada tabela
no dicionrio de dados (SE11). Estas tabelas com seus ranges limitados de valores STORAGE
colocam ordem nos valores dos extents alocados nos tablespaces permitindo que um database v
sempre gerando gaps de tamanhos mltiplos que podem ser reaproveitados de forma otimizada por

Para auxiliar a tarefa de adaptao contnua dos parmetros de storage dos objetos da base de
dados, o sapdba possui a opo next que percorre todos os objetos e, atravs de um algortmo
prprio adapta os parmetros de storage destes objetos para os valores encontrados nas faixas
destas tabelas. Esse processo fundamental para a gerencia de fragmentao dos tablespaces e
deve ser efetuado regularmente em uma base de dados.

Tables and Indexex Monitoring

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

Para maiores informaes verifique as notas 12103 e 16083.

Analyzing Storage Allocation: SAPDBA -analyze

O Oracle analyse utilizado para atualizar as estatsticas referentes as alocaes de storage, grau
de fragmentao e distribuio dos dados. Estas informaes sero utilizadas pelo CBO Cust
Based Optimizer. O utilitrio poder ser schedulado via sapdba atravs da opo analyze.
possvel ainda analisar tabelas individualmente pelo sapdba ou atravs da DB20.

O processo de anlise pode ser executado em modo ESTIMATE (amostragem) ou COMPUTE (full
anlise). Os ndices e seus dados so analisados por ANALYSE INDEX VALIDATE STRUCTURE,
porm este mtodo efetua um lock nos objetos durante a anlise.

Durante a anlise da fragmentao interna atravs dos relatrios gerados pelo mtodo analyze,
verifique sempre se a diferena entre EMPTY e NEVER_BEEN_USED. Diferenas grandes indicam
fragmentao. Grande diferena entre USED_BY_BTREE e USED tambm indicaro fragmentao

Pgina 128
ACADEMIA BASIS

Reorganization

Basics

O processo de reorganizao tem por finalidade eliminar os problemas de fragmentao

relacionados com as estruturas dos objetos. Atravs de uma poltica atenta de monitorao do
database e correta especificao dos segmentos NEXT (atravs do sapdba next), esta necessidade
ser naturalmente minimizada. O processo de reorganizao consiste na seguintes sequencia de
passos: export dos dados, drop dos ndices, drop da tabela, create da tabela, import dos dados,
create index. Atravs do sapdba, todos os scripts necessrios para executar estes passos so criados
e chamados na seqncia correta sem nenhuma interferencia no processo a ser executado.

Vrias so as causas que apontam para uma necessidade de reorganizao:

Fragmentao elevada nos ndices ou tabelas, apontado por elevado volume de extents
M distribuio das tabelas nos tablespaces ou ainda dos prprios tablespaces ao longo dos

Atravs do sapdba, a reorganizao efetuada em duas fases: na primeira cria os scripts que
executaro os passos a serem executados para aquele mtodo de reorganizao escolhido e verifica
se existe rea suficiente nos filesystems. Na segunda fase do processo estes scripts so iniciados em
uma sequncia por ele estabelecida e executam a reorganizao.

Entre estas duas fases o DBA pode determinar o start imediato (em foreground ou background),
ou se deseja postergar o start para mais tarde. Esta ltima opo pode ser utilizada por exemplo por
DBAs experientes que desejam alterar os scripts criados para manipulao dos parmetros de
storage dos objetos, por exemplo. Sempre que se efetua uma reorganizao de tabelas, os seus
respectivos ndices tambm sero reorganizados. O inverso no verdadeiro

Os erros a seguir so os mais comuns durante o processo de reorganizao :

Os datafiles onde os ser feita a reorganizao no comporta a segunda cpia do objeto ou a

diretrio sapreorg no comporta o export que ser feito durante a reorganizao

tablespace PSAPTEMP no comporta a recriao de um indice da tabela que esta sendo
reorganizada

Phases and Types

Existem vrios tipos de reorganizao que podem ser manipulados pelo sapdba:
Reorganizao de um nico objeto: utilizado para eliminar fragmentao interna, reduzir o
nmero de extents ou movimentar objetos entre tablespaces
Reorganizao de uma lista de objetos: reorganiza uma lista de objetos especificados em
um arquivo ASCII, localizado no diretrio de trabalho
Reorganizao de tablespace: reorganiza todos os objetos pertencentes ao tablespace,
mantendo a estrutura de datafiles
Reorganizao de tablespace com datafiles: reorganiza todos os objetos do tablespace
permitindo ainda a realocao dos seus datafiles.
Movimentao ou renaming de datafiles, que no encarado como um processo de

Pgina 129
ACADEMIA BASIS

Methods

O processo de reorganizao de tabelas dropa a tabela durante o processo, havendo portanto

perigo de se perder dados. Os mtodos utilizados so os seguintes:
Export/import: utiliza os comandos Oracle EXPORT e IMPORT para extrair e recarreagar os
dados.
SAPDBA unload/load e SQL loader: mais rpido que o anterior, porm exige um pouco mais

Os mtodos abaixo, quando utilizados, no exigem a exportao dos dados:

Create tableas select: gera uma tabela auxiliar, copia os dados e posteriormente dropa a
tabela original e da um rename na auxiliar
Alter index/rebuild: recria um novo ndice na PSAPTEMP utilizando o ndice existente e o
copia para o tablespace destino, dropa o ndice antigo e ativa o novo.
Recriate index: o ndice dropado e recriado

Options

Durante o processo de reorganizao podemos especificar vrias opes que, salvo algumas
excees, podem ser combinadas entre si:
Compress extents: a fragmentao ser reduzida para apenas 1 extent (INITIAL)
Reduce object size: o sapdba tenta analisar qual a quantidade real de memria necessria e
realoca o novo storage baseado neste valor
Chop = yes: o export dos dados se d atravs de um pipe file, permitindo splitar o dumpfile
em vrios arquivos menores, atendendo as limitaes do sistema operacional (2G em alguns
casos). Esta opo estar disponvel a partir do momento em que se especifica o parmetro
chop_util_name na init<SID>.dba
Compress = yes: um dumpfile do export comprimido
Parallel export/import: o export e import distribudo atravs de vrios processos paralelos
ORACLE parallel clause: utiliza a facilidade oracle para acelerar o processo de
reorganizao

Pgina 130
ACADEMIA BASIS

Performance Monitor

Performance Issues

A performance de um database Oracle est relacionada com quatro fatores bsicos:

No layout fsico e lgico do banco
No desempenho do aplicativo
Na configurao da memria
No CBO Cust Based Optimizer

Cost-Based Optimizer

Reasons for performance problems

O CBO um mecanismo introduzido no Oracle que determina a estratgia mais eficiente para
acessar um determinado dado, baseado nas tabelas especificadas, nos campos informados na
clusula WHERE e nos ndices disponveis nas tabelas. O CBO computa todas as estratgias
disponveis e escolhe aquela que sai mais barata em termo de acessos. Para ter parmetros de
comparao, o sistema precisa se basear em estatsticas atualizadas referentes s tabelas e ndices,
como por exemplo nmero de linhas, nmero de data blocks e nmeros de valores distintos em cada
coluna da tabela. Estas estatsticas ficam armazenadas no dicionrio do Oracle e so recolhidas

Informaes antigas ou inexistentes, assim como informaes incorretas sobre a distribuio dos
dados poder induzir o otimizador a tomar decises incorretas sobre o melhor caminho a seguir.

Refreshing the object statistics

Estes problemas porm so facilmente resolvidos atravs de um refresh das estatsticas ou ainda
atravs de um ajuste fino no procedimento SAP para as rotinas de analyse efetuadas atravs do
processo two-phase (check e analyze). Os processos mais crticos de performance podero
eventualmente ser ajustados atravs de mudana no critrio de cust-based para rule-based ou
finalmente por alteraes no aplicativo..

A SAP recomenda que somente se utilize as ferramentas SAP (SAPDBA e CCMS) para atualizar
as estatsticas da base R/3, j que existem regras particulares que quando no forem seguidas
podero introduzir srios problemas de performance. Com a finalidade de diminuir o tempo envolvido
no refresh das estatsticas, a SAP introduziu o conceito da estratgia two-phase. Este procedimento
consiste em uma primeira passada onde ser determinado quais objetos necessitaro de refresh e
numa segunda fase apenas os objetos selecionados sofrero o refresh. O comando a ser executado
. Ele determina quais tabelas precisam de
refresh e armazena sua deciso na tabela DBSTATC. Esta deciso tomada baseado no critrio de
que o nmero de linhas da tabela alterou em mais de 10% (para tabelas pequenas) ou 100% (para
tabelas grandes). A segunda passada feita pelo comando e
efetivamente atualiza os dados estatisticos que forem necessrios (normalmente para os objetos com
flag ativo na dbstatc).

Modifying the standard procedure

A tabela DBSTATC contm campos como o nome do objeto, o mtodo utilizado (se estimate ou
compute), o percentual ou nmero de linhas a ser analisado e ainda um tag indicando se a tabela
necessita de refresh. A transao DB21 permite efetuar alteraes e novas entradas nesta tabela. A
nota 122718 indica regras e tabelas crticas que devero ser observadas.

Pgina 131
ACADEMIA BASIS

Repetindo o processo :
A primeira fase (sapdba checkopt) grava uma log no diretrio sapcheck (<timestamp>.opt) e
deve ser monitorado aps a execuo pela transao DB14
A segunda fase (sapdba analize DBSTATCO) efetua um refresh apenas dos objetos que
estiverem flagados na DBSTATC. Aps a execuo, as linhas permanecero na tabela
DBSTATC porm o flag de refreshable retirado

O procedimento standard da SAP para tabelas pool e cluster

retirando inclusive qualquer estatstica porventura existente. Isto garante que o Rule-Based
optimizer seja utilizado no acesso a estas tabelas. Este procedimento do Oracle de selecionar o rule-
based quando no possui estatsticas disponveis setado pelo parmetro opmizer_mode = choose
da init<SID>.ora. A SAP recomenda que estas duas fases do procedimento de refresh das
estatsticas seja schedula atravs da transao DB13. O comando sapdba analyze grava uma log
no diretrio sapcheck (<timestamp>.aly) e deve ser monitorado aps a execuo pela transao
DB14. O CBO Control Panel (transao DB21) permite modificar o procedimento padro de refresh
das estatsticas, seja aumentando a preciso requerida para uma determinada tabela ou eliminando
suas estatsticas (para que se use o rule-based optimizer)

Memory Configuration

A System Global Area do Oracle (SGA) contm o data buffer e o shared pool (shared SQL area e
o row cache)

Data buffer

Quando um shadow process requisita um dado poder ocorrer um physical read (o dado trazido
do disco) ou um logical read (o dado j se encontra no data buffer). Um data block acessado no buffer
1000 vezes mais rpido que quando trazido do disco. O processo de atualizao altera o dado no
data buffer e a transferncia para o disco feita mais tarde, assincronamente. A transao ST04
exibe os dados referentes a performance do banco de dados e dever ser utilizada nas anlises
relativas ao banco.

O conceito de Hit Ratio (Quality) o percentual de logical reads sobre o total de reads (logical +
physicals). Este valor dever estar acima de 94%, ou seja, em 94% dos casos o dado j deve estar
no data buffer. Uma anlise deste valor somente tem validade algumas horas aps o statup do
database, quando o data buffer j atingiu uma estabilidade de runtime. Uma boa regra aguardar
pelo menos at o nmero de reads ultrapassar os 20.000.000. Um valor abaixo de 94% indica uma
necessidade de aumentar o nmero de blocos (parmetro DB_BLOCK_BUFFERS), o que poder
inclusive forar um incremento na memria RAM para no aumentar a paginao (analise a
paginao pela ST06). Antes porm de sair aumentando o valor do data buffer indiscriminadamente
interessante olhar os aplicativos para encontrar comandos SQL ineficientes. A R/3 possui ferramentas
de analise de performance que auxiliam esta tarefa.

Cada plataforma de hardware possui um valor mximo de memria que pode ser alocada na
shared memory, no devendo a soma do data buffer, log buffer e shared pool exceder este valor

Shared pool

A shared pool composta da Shared SQL Area onde os comandos SQL so armazenados para
serem compartilhados pelos shadow prcesses e da Row Cache, que armazena informaes do
dicionrio Oracle, incluindo aqui as informaes de estatsticas que sero utilizadas pelo CBO. O
conceito de user call so os acessos efetuados pelos shadow processes na shared SQL area.
Recursive calls so as leituras fsicas efetuadas pela row cache ao dicionrio Oracle. Os principais
pontos a serem observados em relao a shared pool so :
A relao entre os user calls e os recursive calls dever ser de pelo menos 2 para 1.
A Quality (logical/total reads) do data dictionary cache dever ser maior que 80%
A pinration dever ser maior que 95%
A relao reload/pins dever ficar abaixo de 1%

Pgina 132
ACADEMIA BASIS

Valores inferiores nestes parmetros indicam uma necessidade de aumentar a shared pool area.
Como no existe parmetros especficos para SQL area e row cache separadamente, o aumento
dever ser de toda a rea, utilizando o parmetro SHARED_POOL_SIZE. As mesmas
recomendaes descritas acima para o data buffer se aplicam ao incremento dos valores desta rea

Application Design

Lockwait situations

Um lockwait ocorrer quando diversos work processes requisitarem um lock sobre o mesmo
objeto. Para manter consistncia, o RDBMS colocar o lock para aquele que efetuou primeiramente o
request. Este procedimento poder causar gargalos na fila de queue do dispatcher do R/3 uma vez
que os demais work processes que se encontram em wait estaro com o work process ocupado,
apesar de no estarem processando nenhuma transao, mas em wait por um determinado dado.

A transao DB01 o Exclusive Lock Monitor do R/3 que permite monitorar o sistema e verificar
quem est postando locks e quem est em wait. Para diminuir a conteno por lockwait necessrio
muitas vezes reanalisar o aplicativo para emitir commits mais frequentes e garantindo que as
transaes segurem os objetos pelo menor tempo possvel. Locks podem tambm ser evitados se os
processos puderem ser schedulados para rodarem em diferentes horrios

Unnecessary SQL statements

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

Expensive SQL statements

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

Poorly qualified statements

Normalmente este problema ocorrer quando o SQL no utiliza os ndices corretamente. Estes
comandos aparecem sempre com um nmero elevado de bufgets/record. A causa deste problema
varia desde uma ausncia de ndices at em problema com as estatsticas da tabela que esto
direcionando o otimizador para um caminho errado. ndices standard do R/3 somente devero ser
alterados com o aval da SAP. O comando explain plan mostra se o ndice est sendo utilizado ou no
no comando SQL.

Uma das causas mais provveis deste problema o fato do ndice estar definido no dicionrio do
R/3 mas no est ativado, por exemplo devido a uma reorganizao que no foi at o final. Atravs
da DB02 possvel exibir os missing indexes. Esta informao fica disponibilizada a partir do report
RSORATDB que triggado pelo performance collector (RSCOLL00)

Pgina 133
ACADEMIA BASIS

Physical and Logical Layout

I/O contention

Ocorre quando numerosos shadow processes e o DBWR acessam o mesmo disco ao mesmo
tempo. Comandos SQL caros ou mal qualificados aumentam a probabilidade desta conteno por
produzirem volumes elevados de I/O. Aplicativos mal projetados frequentemente causam este
problema

A transao ST04 (Detail analysis File system requests I/O per path) permite analisar os
mount points separadamente e com isso identificar hot spots disks e planejar remanejamento de
datafiles. Com volumes elevados de I/O, necessrio certificar-se de que o read time no exceda 30
ms e o write time, 50 ms. Filesystems times que desviam mais que 20% da mdia sero possveis hot
spots. Estes valores podero variar entre as vrias plataformas e hardwares disponveis, cabendo
talvez uma anlise mais cuidadosa destes targets.

A conteno de I/O solucionada atravs da identificao dos hot spots e a posterior distribuio
dos datafiles entre os dispositivos e canais. A opo total per device um excelente auxlio nesta

Checkpoint not complete

O sistema Oracle efetua a gravao de checkpoints, que consiste na sincronizao dos SCN no
header de todos os seus arquivos (datafiles, redo e control files). Alguns eventos associados a carga
elevada no sistema podem causar erros neste processo, que so chamados Checkpoints Not
Complete. O erro ocorrer quando o checkpoint ainda se encontra em processamento e o switch de
log atinge uma log que ainda no conseguiu ser arquivada. O Oracle congela as atualizaes e
aguarda que o processo de checkpoint finalize, os archives sejam efetuados e consequentemente
exista online redo disponvel para gravao.

A mensagem de checkpoint not complete gravada no alerte do Oracle

(/saptrace/background/alert_<SID>.log). A ocorrncia muito constante deste problema pode sugerir
a criao de mais grupos de relo logs. A SAP no recomenda aumentar o tamanho das redo log,
exceto se o tempo de switch estiver abaixo dos 3 minutos

Rollback statement problems

Os rollback segments so utilizados no Oracle para gravar imagens before que podero ser teis
para desfazer transaes no commitadas. Outra funo destes rollback segments no Oracle
garantir consistncia na leitura de dados . Isto significa que se um determinado registro foi alterado
por uma transao depois que outro query iniciou um processamento, quando chegar o momento da
requisio do registro o Oracle entrega a imagem before e no a atual ou seja, aquela que estava
corrente no momento em que a transao iniciou e ficou armazenada no rollback segment.

Estas imagens permanecero no rollback segment mesmo aps o commit. O problema que pode
ocorrer um rollback segment commitado pode vir a ser reutilizado por outra transao posterior.
Caso o query chegue na linha alterada, ao verificar o rollback para buscar a imagem consistente para
leitura encontrar o bloco sujo e consequentemente no poder mais fornecer a imagem before.
Neste caso a transao que estava efetuando o query recebe o abend ORA-1555 (snapshot too old).

Para evitar a ocorrncia de ORA-1555, preciso tentar evitar que programas de query sejam
schedulados durante perodos de alto volume de atualizao, tentar otimizar o runtime dos programas
que abendam com 1555 ou, se nada mais funcionar, aumentar o nmero (preferencialmente) ou o
tamanho dos rollback segments

O dimensionamento correto dos private rollback segments (aqueles que so especificados no

init<SID>.ora) preciso partir de uma anlise dos rollback segments atuais atravs da viso
V$ROLLSTAT:

Pgina 134
ACADEMIA BASIS

Caso o somatrio dos WAITS de todos os rollback segments representem mais do que 1% do
somatrio dos GETS isto indica conteno, ou seja, necessrio definir mais rollback
segments
valor OPTIMAL representa a marca at onde os rollback segments que sofreram alocao de
extents iro encolher na operao de shrink
valor HWMARK a marca dgua do segmento. um bom indicativo de qual dever ser o
valor do parmetro OPTIMAL para eliminar os extend/shrinks, porm deve ser analisado com
cuidado pois pode se tratar de uma demanda isolada
Os campos EXTENDS e SHRINKS representam o nmero de alocaes/dealocaes acima
do valor OPTIMAL. Para calcular o valor do OPTIMAL ideal, utilize a frmula: new OPTIMAL
= OPTIMAL + (EXTENDS SHRINKS) * NEXT. Com isto ser especificado um valor para o
optimal que no causar mais os extends/shrinks.
volume ideal de alocao de extents dever ficar na casa dos 20. Com isto podemos calcular
os parmetros de storage: INITIAL = NEXT = OPTIMAL/20

Fragmented indexes

ndices fragmentados so caracterizados por um baixo volume de preenchimento dos blocos e,

pior ainda, por uma distribuio da rvore em mais de 3 nveis. Esta fragmentao normal e vai
acontecendo ao longo das operaes de atualizao que uma tabela vai sofrendo. Tabelas com alta
volatilidade ou volumes elevados de deleo, como acontece durante uma operao de archiving,
esta fragmentao se acelera. O resultado da fragmentao elevada dos ndices sobre a performance
que um volume muito mais elevado de index blocks ser percorrido do que em um ndice
organizado, gerando I/O e queda da qualidade do data buffer.

Para analisar os ndices, utilize a transao DB02, selecione o ndice desejado e em seguida
utilize o caminho: Detail analysis Analyse index Storage quality. O valor encontrado para a
qualidade do ndice dever ser superior a 50%. possvel tambm disparar um validate index (em
modo dialog ou background) para analisar o nmero de nveis das folhas.

Pgina 135
ACADEMIA BASIS

Quinta Semana

Top 10 Problems
Esta seo ir listar os 10 problemas mais comuns que podem ocorrer na administrao de uma
base de dados Oracle com o R/3. O principal objetivo reconhecer, solucionar e principalmente
prevenir a ocorrncia de tais fatos

Uma utilizao criteriosa e diria do sapdba check ajuda a preveno dos principais erros no
Oracle. necessrio ainda o monitoramento constante das transaes ST22, SM21 e dos traces e
logs do R/3 e de suas ferramentas

Archive Stuck Situation

O travamento de uma instncia Oracle devido a incapacidade de gravao das offline redo log files
ocorre principalmente quando a rea saparch atinge os 100% full. Quando o archiver stuck ocorre, o
Oracle grava relata os error ORA-255 e ORA-272 no alert_<SID>.log

A monitorao constante do filesystem saparch e uma metodologia consistente de arquivamento

implantada evita a ocorrncia deste problema. Manter um dummy file na rea saparch para ser
excludo em casos de stuck ajudam a ganhar um flego a mais enquanto se providencia um
arquivamento emergencial.

The Incorrect Tape Size Drivers with Hardware Compression

Um dimensionamento incorre do parmetro tape_size do init<SID>.sap poder causar desde erros

durante a gravao at, o que ainda mais grave, problemas quando se tenta recuperar a fita em um
restore.

Reserve sempre um espao de pelo menos 200MB quando especificar o tamanho da fita para
eventuais erros no dimensionamento dos files durante o brbackup. Este valor do tape size
especificado em MB ou GB e equivalem ao clculo do tape length * write density, que variar de
modelo para modelo de fita e do processo utilizado na gravao, se comprimido ou no

Quando um tablespace backupeado em modo online, necessrio que o mesmo seja colocado
em backup mode atravs do comando begin backup antes de iniciar a cpia. Este modo
permanecer at o final da cpia quando ento o tablespace retirado do backup mode atravs do
comando end backup

A tentativa de retirar um database com shutdown immediate pelo sapdba, o mesmo verifica
antes e coloca qualquer tablespace que se encontre em backup mode para end backup antes
de efetuar a operao.

Se o shutdown immediate vier atravs do service manager (svrmgrl) ou do stopsap db, o

comando falha retornando o erro ORA-1149 (missing end backup). Neste caso bastar alterar o
tablespace para end backup (ALTER TABLESPACE xxx END BACKUP;).

A ferramenta check database do sapdba efetua este check e, melhor ainda, pergunta ao
operador se deseja retirar o end backup do tablespace e efetua a operao

Caso a instncia DB caia mantendo algum tablespace em backup mode (seja por power fail
ou shutdown abort), o startup ir falhar com a mensagem ORA-1113. Neste caso ser necessrio
efetuar um partial restore and complete recovery dos tablespaces afetados

Pgina 136
ACADEMIA BASIS

A Tablespace Overflow

A necessidade de mais rea para uma tabela ou ndice no tablespace ocorrer quando o mesmo
precisar de mais data blocks. Esta alocao se dar em rea contgua e no tamanho especificado
pelo parmetro NEXT do objeto. Caso o tablespace no possua esta rea desejada, ocorrer o
erro ORA-1653 (tabela) ou ORA-1654 (ndice) que ser emitido na syslog e no ABAP short dump.

A monitorao constante do critical objects pela DB02 ou do sapdba check ajuda a prevenir
esta ausncia de rea e a tomar as medidas necessrias antes que o erro ocorra.

para o tablespace (via sapdba) em um

tamanho baseado no crescimento estimado do tablespace. importante que se efetue um backup
do tablespace aps cada mudana estrutural dos arquivos.

A Table or Index Reaching the MAXEXTENTS Limit

Quando o nmero de extents de um objeto atinge o valor especificado no parmetro de storage

MAXEXTENTS, o sistema no alocar mais extents e ocorrer o erro ORA-1631 (tabela) ou ORA-
1632 (ndice) que ser emitido na syslog e no ABAP short dump.

Este problema poder ser evitado pelo acompanhamento constante do sistema e

. O comando sapdba next efetua uma adaptao do parmetro NEXT
das tabelas e ndices baseado em critrios bem estabelecidos no dicionrio do R/3. Este comando
dever estar schedulado para rodar pelo menos uma vez por semana na instalao (utilize a DB13)
ou ento esporadicamente quando se tem conscincia de crescimento anormal de tabelas (carga
em batch, etc.)

O problema pode ser contornado temporariamente atravs da especificao de novo limite

para o parmetro MAXEXTENTS. Porm quando o sistema atingiu este limite j dever ter ocorrido
um elevado volume de fragmentao da tabela, devendo ser planejado uma para o
objeto o mais cedo possvel. Nunca especifique um valor unlimited para o parmetro MAXEXTENTS
nos objetos de um banco utilizado pelo R/3

Oracle Error ORA-1555, Snapshot Too Old

Para garantir a consistncia na leitura, o Oracle implementa um mecanismo que garante aos
queries submetidos ao banco um nvel de pesquisa que permite obter todos os seus registros
desejados no estado em que estavam no incio do SQL. Este mecanismo funciona atravs do
fornecimento de eventuais valores alterados aps o incio do query com suas imagens before que se
mantm armazenadas nos segmentos de rollback.

Comandos de update que sofreram commit permanecero com seus pointers ainda alocados para
a rea de rollback podendo porm ser sobre escritos por novas transaes, dependendo da
atividade do banco e do tempo que o query permanecer percorrendo a base de dados.

Eventuais comandos que requisitem linhas que foram alteradas (e commitadas) e eventualmente
j perderam sua imagem na rea de rollback, iro receber um erro ORA-1555 indicando snapshot
too old, abortando o processo.

Antes que se parta para uma alterao da configurao dos segmentos de rollback, vale identificar
o comando que esteja provocando o erro e verificar alternativas para a sua execuo, inclusive
planejando o seu schedule para horrios de menor atividade no banco

Net8 TCP/IP Delay

O Net8 a camada de comunicao entre os application servers e o banco de dados.

Comunicaes na mesma mquina utilizaro IPC (inter process call) e remotamente o protocolo
TCP/IP.

Pgina 137
ACADEMIA BASIS

A implementao default do Oracle utiliza o modo de configurao do Net8 em delay mode, o

que introduz um ciclo de espera de aproximadamente 200ms nas comunicaes dos processos

Este problema pode ser solucionado atravs do arquivo protocol.ora que pode ser obtido do
sapservX. Em seguida copie este arquivo para o diretrio /oracle/<SID>/network/admin com read
permissions para os usurios <sid>adm e ora<sid> em todos os applications e no db server.

Para que o novo modo se torne operativo, necessrio parar todas as instncias
(application, DB e o listener). Volte o listener, ativ o DB e retorne os applications

A nota 72638 descreve melhor este processo.

Oracle Error ORA-1578, Data Block Corruption

O erro ORA-1578 indica uma corrupo de estrutura dos blocos Oracle. Este erro pode ocorrer por
uma falha de hardware e permanecer despercebido at o momento que o bloco seja requisitado, o
que pode ocorrer muito tempo aps a ocorrncia do erro.

Se o problema ocorrer em um bloco de ndice, basta reconstruir o ndice danificado. Table blocks
danificados somente podero ser solucionados atravs de um restore e recover parcial at a
momento do crash, se conhecido.

A demora em perceber o bloco danificado pode gerar consequencias graves, j que muitas vezes
fica difcil voltar um backup antigo sem afetar seriamente o negcio de uma empresa. Alm disso o

Para garantir que os blocos danificados sejam detectados no momento do backup, schedule o
brbackup com a opo use_dbv, como visto anteriormente. Um processo constante de verificao do
banco atravs de ferramentas Oracle (DB verify e dbv) tambm garantem a monitorao constante da
base de dados, minimizando as consequncias de qualquer ocorrncia de blocos danificados.

Oracle Error ORA-600, Internal Database Error

O erro ORA-600 indica um erro interno Oracle. Procure identificar o primeiro argumento da
mensagem de erro e procure no OSS por ocorrncias do erro.

Poor Performance of the Cost-Based Optimizer

O CBO determina a maneira mais eficiente de acessar uma determinada tabela baseado em
estatsticas armazenadas no dicionrio Oracle.

Qualquer incoerncia nestas estatsticas causada pela no atualizao dos dados poder
direcionar o otimizador para decises que causaro srios problemas de performance.

Garanta que estas estatsticas sejam atualizadas regularmente atravs do shedule das duas fases
(check e analyse) na DB13.

Pgina 138
ACADEMIA BASIS

Introduction to Workload Analysis

Performance Problems

A workload analysis consiste em aplicar mtodos especficos de anlise dos tempos de resposta
em um sistema R/3 para que se encontre gargalos e programas problemas no ambiente conseguindo
com isto efetuar ajustes finos de performance que consigam diminuir o tempo de resposta das
transaes e aumentar o throughput do sistema.

Tempos de resposta ruins devero ser analisados localizadamente (por transao) ou no sistema
como um todo (mdia geral dos tempos de resposta), dependendo da forma como o problema se
manifesta.

Basis Tuning
Uma anlise geral do ambiente tem por finalidade distribuir corretamente a carga do ambiente
entre os servidores de um sistema R/3. Isto significa dimensionar corretamente o hardware, distribuir
os discos e otimizar as definies dos work processes e dos buffer das instncias

Application Tuning
Um tuning localizado de uma aplicao tem por finalidade evitar que programas mal especificados
produzam uma carga desnecessria no ambiente. Esta anlise vai desde a localizao e aplicao de
notas do OSS at a otimizao dos cdigos dos programas desenvolvidos na instalao (programas
Z). Eventualmente esta anlise chega a concluso de que necessrio criar novos ndices ou
bufferizar algumas tabelas do sistema.

Response Times

O tempo de resposta (response time) de uma transao no R/3 o tempo entre a requisio do
usurio ao sistema e vai at o retorno da prxima tela, podendo ser dividido em vrios componentes
individuais que permitem uma anlise mais profunda no componente causador da m performance. O
tempo de transmisso (rede) no computado pelos monitores do R/3:
Wait time: o tempo de permanencia do request na fila do dispatcher desde o momento que
a request chega at a sua atribuio ao work process
Roll in time: o tempo necessrio para efetuar o roll in dos dados de contexto do usurio para
dentro do work process
Load time: o tempo necessrio para carregar os objetos (e eventualmente gera-los) do
dicionrio ABAP para os buffers da instncia
Processing time: o tempo gasto para processamento dentro do work process, equivalendo
a diferena entre o response time e a soma dos demais tempos
Database request time: tempo de processamento dos SQL, que comea quando a requisio
encaminhado ao database interface e termina quando este retorna com o resultado
CPU time: tempo de CPU consumido por todo o processo (consumido pelo roll, load, enq,
processing e db)

Wait time

Os requests encaminhados pelo SAPGUI so colocados em uma fila de espera FIFO pelo
dispatcher. Um elevado tempo de permanncia nesta fila indica indisponibilidade de work process.
Esta indisponibilidade pode entretanto vir de uma pequena definio de nmero de work processes
como tambm pode significar que os work processes no esto sendo liberados com a rapidez
esperada. Elevados wait times merecem uma anlise menos simplista e esta normalmente associado
a problemas generalizados no sistema.

Pgina 139
ACADEMIA BASIS

Roll in time

Roll in a transferncia dos dados do contexto do usurio (autorizaes e ponteiros para as reas
de trabalho) do roll buffer para a roll memory do work process. Ao efetuar esta transferncia tem-se
incio ao processamento do dialog step. Tempos elevados de roll time podem indicar problemas no
gerenciamento de memria do R/3 ou ainda gargalos de CPU para efetuar a operao.

Database time

Quando um dado requisitado via um open SQL, a requisio enviada para o database interface
do work process que efetua o request localmente nos database buffers da instncia ou envia a
requisio para ser processada pelo servidor de bancos de dados. Ou seja, o database time
compreende o tempo desde a passagem do sql para o database interface at a disponibilizao dos
blocos de dados ao work process. Tempos elevados no componente database podem indicar
gargalos na instncia DB, problemas de rede (se outra instncia), comandos SQL caros, falta de
ndices, enfim uma srie de problemas relacionados ao tuning do banco.

Processing time

O processing time definido como o tempo de resposta total menos o wait, database, load, roll e
enqueue time. Pode ser entendido como o tempo gasto dentro do work process para realizar o
processamento ABAP demandado pela aplicao. Tempos elevados normalmente significam loops no
programa eu erro na construo da aplicao.

CPU time

O tempo de CPU consumido pelo work process durante um dialog step computado no CPU time.
Entretanto no s este, no cpu time esto computados todos os tempos gastos por cada um dos
componentes na cpu onde est sendo executado o application. Tempos elevados de CPU indicam
problemas na lgica do programa ABAP, tais como processamento de tabelas muito extensas ou
sobrecarga da cpu em funo de outros processamentos que esto concorrendo na mquina.

Workload Statistics

O Performance Monitor (transao ST03) d informaes detalhadas e estratificadas dos tempos

de resposta em em sistema R/3

A proporo apresentada entre o nmero de database calls e os database requests d uma noo
exata da eficincia da buferizao de tabelas, indicando o nmero de requests que tiveram que ser
encaminhadas ao DB server pelo database interface.

As chamadas externas de funes RFC podem provocar roll out do user context para liberao do
work processes. A espera pelo retorno (roll wait) e posterior roll in, todos estes tempos ficam
embutidos no roll time do dialog step. Transaes com elevado nmero de chamadas RFC tendem a
ter um roll time mais elevado que as demais.

Workload Analysis

O workload analysis feito atravs da transao ST03. Esta transao viabiliza a analise da carga
no sistema em qualquer momento no tempo (passado agrupado por periodo ou um snapshot dos
ultimos minutos) Uma anlise geral (a partir da seleo de um perodo de tempo que seja conveniente
para a anlise) pode indicar se existem problemas de performance gerais na instalao, como por
exemplo :
Wait time maior que 10% do response time
Main menu () com tempo de execuo superior a 100 ms

Pgina 140
ACADEMIA BASIS

Atravs da ST03, alguns valores indicam boa performance:

Average roll in time < 20 ms
Average roll out time < 20 ms
Average load time < 10% response time e sempre inferior a 50 ms
Average database time < 40% do (response time wait time)
Average CPU time < 40% do (response time wait time)
Average CPU time no pode ser muito inferior ao processing time

De qualquer forma temos que ter em mente que os sintomas abaixo normalmente esto
associados a tipos padres de problemas, a saber :
Large roll time problemas com o gerenciamento de memoria do R/3
Large load time - buffers de programas, cua, ou screen esto pequenos
Large database request time gargalo na cpu ou memria na mquina de banco de dados,
problemas de rede, comandos sql caros, locks, ausencia de indices ou estatisticas
desatualizados
Large CPU time comandos sql muito caros em funo de processamento pesado ou
acessos frequentes aos buffers
Processing time muito maior que o CPU time gargalo de cpu, problemas de redes e/ou de

Analysis Roadmap using workload monitor (ST03)

ST03
Wait time > 10% response time
Problema generaliza de performance
Database time > 40% (response time wait time)
Analise detalhada do banco de dados
Processing time > CPU time * 2
Analise detalhada do gargalo de hardware
Load time > 50ms
Analise detalhada da configurao de memoria do R/3
Buffer de programas muito pequeno
Roll-in time > 20ms ou roll-out time > 20ms
Analise detalhada da configurao de memoria do R/3
Problemas com memoria extendida ou roll buffer
Perfil de transao (st03 classificado por temo de resposta)
Programa com cpu alta : cpu time > 40% (response time wait time)
Analise detalhada do trace do abap em questo
Programa com db alto : database time > 40% (response time wait time)
Analise detalhada do sql em questo

Processing times muito superiores ao CPU time indicam gargalos de CPU ou problemas de
comunicao. A opo de transaction profile da ST03 exibe a distribuio dos tempos por transao,
permitindo anlises individualizadas, permitindo efetuar esforos de tuning nas transaes mais
utilizadas. Podemos utilizar a transao STAT exibe estatsticas individualizadas por uma srie de
fatores.

Para auxiliar a anlise devemos utilizar as transaes :

ST03 work load monitor
SM50 / SM66 work process overview
ST06 operating system monitor
ST04 database monitor
ST02 setups buffers
STAT statistical records
ST05 trace de sql
ST07 application monitors
SE30 abap trace

Pgina 141
ACADEMIA BASIS

Performance Analysis Monitors

Work Process Overview

A transao SM50 permite a monitorao dos work processes de uma instncia R/3. A
monitorao dever se ater aos processos com status running e aqueles com status stopped, que
indicam work process em modo PRIV.

SM50 ou SM66 (work process overview)

Work process com status running
Ao Dir. Read, Seq Read, Insert, Update, Delete, Commit
Analise detalhado do banco de dados
Ao Load Report
Analise detalhada da configurao de memoria do R/3
Buffer de programas muito pequeno
Ao Roll-in ou Roll-out
Analise detalhada da configurao de memoria do R/3
Problemas com buffer de memoria extendida ou de roll
Work process com status stopped
Reason PRIV
Analise detalhada da configurao da memoria do R/3
Problemas com buffer de memoria extendida ou de roll buffer
Reason CPIC
Problemas com conexo CPIC como todos work process bloqueados

ST06 - Operating System Monitor

A transao que permite a monitorao do sistema operacional no R/3 a ST06, que exibe
informaes sobre utilizao de CPU, swaps, utilizao de discos e configurao do sistema
operacional. Gargalos de CPU aparecem quando temos menos de 10% idle ou quando o Load
Average indica um valor superior a 2 vezes o nmero total de CPUs disponveis

Problemas de alto consumo de CPU podem ser identificados atravs da anlise dos topCPU
processes, no detail analysis. disp+work so os processos R/3 e ORACLE80 um processo de banco
de dados.

Nesta janela devemos observar os percentuais de utilizao da cpu (devem estar com pelo menos
10% de idle), o load average (indica quantos processos ficaram aguardando por cpu), paginao
(sempre inferior a 10% da memria fsica) ou swap alocado em arquivos e no liberados pelos work
process.

ST02 - Buffer Monitor

A transao ST02 o monitor dos buffers do R/3, indicando tamanhos, qualidades e percentuais
de ocupao de cada um deles. Devmos observar que o percentual de utilizao dos buffers devem
estar sempre acima de 95% alm do cuidado especial com swaps excessivos e com os possvies
gaps no buffer de programas.

Quando detectamos que a extended memory atingiu 100% de utilizao ( Max use = In memory),
comearo a aparecer contenes de memria para os work processes. Roll area com valores de
Max use superiores ao In memory indicam que a utilizao de roll area teve que ser expandida para

Pgina 142
ACADEMIA BASIS

R/3 Memory Management

R/3 Memory Areas

A memria fsica a memria em RAM instalada na mquina. A rea de swap uma rea em
disco pelo sistema operacional para paginar a memria utilizada pelos processos. quando alocamos
uma memria em um sistema operacional, estamos efetuando uma alocao de memria virtual. O
sistema operacional quem decide se a memria alocada estar em disco ou em memria fsica.
Dependendo do sistema operacional utilizado, a memria virtual ter um valor entre o swap
especificado e a soma do swap com a memria real.

Uma instncia possui duas reas bsicas de memria: local memory e shared memory

Local Memory

a memria associada com cada work process. Esta memria utilizada para:
Executveis
Dados, stack
Buffer para transferncia de dados
Local roll area
Local paging area

Heap
Fazendo parte da memria local mas no diretamente temos a heap area. A heap memory
alocada pelo work process diretamente na rea de swap. Work processes que comeam a utilizar
heap area entram em PRIV mode, desta forma no efetuando mais roll out/roll in, ficando desta forma

Shared Memory

A shared memory o agrupamento das reas globais que sero compartilhadas pelos work
process. Ela subdivida em buffers, roll area, paging area e extended area.

Buffers
Memria alocada na shared memory e que contm objetos globais de todos os usurios e work
processes, tais como programas e tabelas de customizao.

Extended
A extended memory contm dados de contexto associados com a transao de um determinado
usurio, tais como variveis, listas, tabelas internas, etc. Ela alocada a medida do necessrio em
pequenos blocos e preservada de um dialog step para o outro.

Roll
A roll memory alocada no roll buffer e contm a parte inicial do contexto do usurio. Ela contm
ainda os ponteiros para a extended memory que est sendo utilizada pela transao corrente.

Paging
uma rea utilizada pelos work processes na paging area (shared memory) para determinadas
operaes de abap. Ela normalmente est associada a dados relacionados a subfunes abap.

Pgina 143
ACADEMIA BASIS

Allocation Concepts

Os work processes so compartilhados pelos vrios usurios que se conectam a uma instncia.
Este compartilhamento efetuado a cada dialog step (ou chamada RFC) fora o R/3 a manter um
mecanismo que salve os dados do usurio e permita o reinicio do processamento quando solicitado
pelo usurio no prximo dialog step. Estes dados referentes a um determinado usurio denominado
user context area. Este conceito permite por exemplo que um determinado cdigo de material que o
usurio trabalhou em uma transao seja lembrado como default na prxima transao.

O conceito de roll out salva a user context area garantindo assim que os dados de um usurio no
sejam sobrescritos pelos usurios que utilizam o mesmo work process posteriormente. Os dados so
movidos (rolled out) para disco. O prximo dialog step provoca o retorno da user context area para o
work process que ir processa-lo. Este processo denominado roll in.

Existem duas reas no R/3 que sofrem este processo de roll out/roll in. A roll area propriamente
dita contm os dados de contexto do usurio associados a autorizaes, internal tables e report lists.
A paging area contm a memria associada a alguns comandos especficos de ABAP.

A extended memory alocada na shared memria e disponibilizada para os work processes que
podem requisitar pedaos de memria que ficam mapeados nos work process atravs de pointers
armazenados na respectiva roll area. Isto permite diminuir o contexto de roll out/in apenas para
referncias (pointers) extended memory alocada.

Allocation Sequence
A fim de minimizar o volume de dados necessrios para as operaes de roll in/out, o sistema R/3
procura otimizar a alocao de memria atravs de uma metodologia nesta operao. Inicialmente
apenas uma poo mnima da roll area alocada, definida pelo parmetro ztta/roll_first. Quando
este parmetro setado para 1, um mnimo de 100K ser alocado para o processo. Quando o
processo necessitar de rea para trabalho, o sistema alocar memria na extended memory da
shared memory e grava na roll area do work processes apenas um pointer para a rea alocada. Esta
aquisio de memria na extended memory vai sendo permitida at que no haja mais memria
disponvel ou ento quando o work process atinge a sua cota de alocao, definida pelo parmetro
ztta/roll_extension. Esta rea no ser copiada durante o processo de rolagem, mas sim mapeada,
ou seja apenas as referncias (pointers) sero copiados.

Quando se esgota a alocao de extended memory o work process comea a alocar o restante da
roll area disponvel, o que acaba aumentando a quantidade de area sujeita a roll out/in. O limite a ser
ztta/roll_area. O ltimo passo quando se esgota a
roll area alocar memria na heap memory, Quando este passo acontece, o work process entra em
PRIV mode e para de efetuar rolagem da rea de contexto, o que significa que ele permanecer
alocado para o usurio at o trmino da transao. A quantidade mxima de rea que pode ser
alocada na heap area para cada work process definida pelo parmetro ztta/heap_area_dia.

A partir do release 4.0 do SAP os demais work processes, como batch work process, tambm
utilizam este mesmo critrio para alocao de memria.

Heap Memory Management

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

Pgina 144
ACADEMIA BASIS

R/3 Extended Memory

Quando se utiliza um novo parmetro do R/3, o PHYS_MEMSIZE, ele permitir que o prprio R/3
gerencie a sua alocao de extended memory at um limite definido por em/max_size_MB. Este
procedimento simplifica a administrao de memria (no necessrio definir mais nenhum outro
Zero Administration Memory Management. Para limitar, neste caso, a
utilizao da extended memory por um usurio utilize o parmetro em/address_space_MB. Para
maiores detalhes veja a nota 88416.

O tamanho mximo da memria alocada para extended memory (parmetro em/initial_size_MB)

em UNIX depende da arquitetura utilizada. Em plataformas 32 bits o limite de 2G, j para sistemas
64 bits, este limite sobe para 108TB. Para maiores informaes pequise notas associadas ao sistema
operacional.

Dever sempre haver uma quantidade suficiente de memria real compatvel com a
parametrizao do R/3 para evitar paginao excessiva de sistema operacional.

Analysis Roadmap: R/3 Memory Configuration (ST02)

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

Pgina 145
ACADEMIA BASIS

Hardware Capacity Verification

Hardware Bottlenecks

Um gargalo causado por hardware no R/3 reflete em um elevado tempo de resposta das
transaes. No sistema operacional este problema se manifestar atravs de um elevado consumo
de CPU (prximo a 100%), altas taxas de paginao, baixo desempenho da rede ou ainda por
elevados tempos de acesso aos discos. A quantidade ideal de CPU idle dever se situar acima dos
35%. Taxas abaixo de 20% indicam gargalos de CPU. ndices de paginao (ST06 double click
Paged in [Kb/h]) por hora acima de 20% da memria RAM indicam problemas de memria.

Analysis Roadmap: Hardware consuption (ST06)

Operating System Monitor (ST06)

CPU Idle < 20% CPU contention
Other servers available Work process and users redistribution
Top CPU process (ST06 Detail analysis)
R/3 process with high CPU detail analysis using SM50
DB process wit high CPU detail analysis using ST04
External process with high CPU stop or redistribute
High paging rate > 20% of RAM per hour memory contention
Other servers available Work process and users redistribution
File system cache > 10% RAM reduce file system cache
Buffers monitor (ST06 Mode list)
Programs with high memory detail analysis of transaction
Workload Monitor (ST03)
Wait time > 10% General performance problem
Database time > 40% (response time wait time) database detail analysis
Processing time > cpu time * 2 hardware bottleneck
Load time > 50 ms program buffer too small
Roll in/out > 20ms problem with extended memory or roll buffer

Contenes de CPU podem ser resolvidas atravs da distribuio da carga entre os demais
applications, quando possvel. Processing time > CPU time x 2 geralmente indica problemas gerais de
performance associados a hardware, sendo necessrio pesquisar mais fundo a causa do gargalo. A
causa do elevado consumo de CPU pode muito bem estar associado a processos rodando na
mquina que consomem muito ciclo. Se houver gargalo de memria, veja a nota 78498 para avaliar a
possibilidade de utilizar o cache de file system.

Optimizing the Configuration

Memory configuration
Separe para o banco de dados 20% da memria de todos os servers. Defina os buffers do R/3
entre 200MB e 500MB por instncia. Em unix cada work process consumir aproximadamente 11.5
MB (7.5MB no NT). Cada usurio logado consumir de 5 a 10MB de extended memory. A RAM fsica
dever ser aproximadamente 2/3 da memria usada. A memria virtual alocada pode ser visualizada
Detail analysis Storage. O swap dever ser de 3 x RAM (no mnimo 2GB).
Considere nos clculos o nmero de usurios ativos e o peso dos aplicativos que sero utilizados

CPU configuration
Utilize para o banco de dados de 10 a 30% da CPU de todos os servers. Garanta que nunca haja
gargalos no servidor de banco de dados. Utilize de 10 a 20% do total de CPU para o processamento
dos updates. A demanda dos application servers depender do perfil dos usurios/aplicativos
utilizados

Pgina 146
ACADEMIA BASIS

Expensive SQL Statements

Detecting Expensive SQL Statements

Comandos caros de SQL podem aumentar o database time das transaes afetando por
consequencia o tempo de resposta de todo o sistema. Estes comandos provocam elevadas taxas de
leitura de data blocks que provocam I/Os elevados e alto consumo de CPU.

Na prtica os expensive sql statements provocam um grande impacto na performance geral do

sistema pois o work process fica muito tempo ocupado aguardando o retorno dos dados. Dados estes
que esto sendo trabalhados em buffers e/ou disco gerando novas contenes de IO e CPU.
Resultado, o wait time acaba por ser o sintoma mais caracteristico apesar de no estar associado
diretamente ao problema.

Monitors to Analyse

Devemos procurar por programas com elevados database times e posteriormente por SQLs com
altos valores de buffer gets. As transaes utilizadas nestas anlises sero: ST03, SM50/SM66,
ST04, ST05 e SE12. Devemos focar a pesquisa para identificar o nome da tabela em questo, a
clausa where utilizada, os indices envolvidos e principalmente o report ou a transao que contm o

Transaction profile, transaes com database time

e/ou cpu time superiores a 40% do response time wait time devero ser analisados com enfoque
para os acessos ao banco de dados:

Analysis Roadmap using transaction profile (ST03 Transaction profile)

Transaction profile, sorted by response time total
CPU time > 40% (response time wait time) detail SQL analysis
ABAP trace (SE30)
Detail analysis of ABAP program
DB time > 40% (response time wait time) detail SQL analysis
SQL trace (ST05)
Detail analysis of SQL statement

Atravs da SM50 e SM66 tambm possvel efetuar anlise de programas com elevados tempos
de resposta, alm da identificao direta de quem o causador (usurio e cdigo abap). Para isto
veja o roadmap abaixo :

Analysis Roadmap using work process overview (SM50 ou SM66)

WP in status running Long processing: analyse status field
Dir. Read, Seq. Read, Insert, Update, Delete, Commit DB analysis
Database Lock Monitor (DB01)
Wait due database locks Analyse lock holder
Database Process Monitor (ST04 Oracle session)
Look for SQL statements and identify the transaction
SQL Trace (ST05)
Identify and analyse specific SQL statement

Comandos caros tambm podem ser identificados atravs da monitorao dos buffer gets (ST04
Detail analysis SQL statement) com elevadas taxas. Alm dos buffer gets devemos observar os
gets/execution, records/execution e disk reads.

Pgina 147
ACADEMIA BASIS

Detail Analysis and Tuning

Expensive sql statement sempre efetuam elevados volumes de buffer gets durante a sua
execuo. Dependendo do resultado obtido, podem ser classificados em dois tipos: aqueles que
trazem um alto volume de linhas selecionadas (tipo 1) e aqueles que trazem poucas linhas como
resultado (tipo 2). Os comandos tipo 1 normalmente indicam programas ABAP mal escritos, devendo
ser reanalisados. Os comandos tipo 2 so resultado de estratgias ineficientes de acesso ao banco
de dados, seja pela ausncia de ndices ou pela ausncia de estatsticas atualizadas. Eventualmente
a ineficiencia provocada por comandos SQL complexos que devem ser reescritos

Para verificar como o otimizador est resolvendo o sql devemos utliizar o explain (detalhe de como
o sql foi resolvido). Nele podemos perceber o mtodo de acesso (table access full, index range scan,
index unique scan, concatenation, sort, index used, etc) e o custo que o comando teve para ser
executado. Atravs de um explain no comando SQL podemos decidir pela criao ou no de um novo
ndice secundrio. Ao criar ndices posicione os campos mais seletivos no incio do ndice e no
especifique mais do que 5 campos. Evite definir mais do que 5 ndices por tabela, principalmente
naquelas que sofrem muita atualizao, como o caso das tabelas que armazenam dados
transacionais. Atravs do explain possvel verificar a estratgia de acesso que o otimizador est
utilizando para executar o comando SQL. Caso a estratgia esteja saindo cara, verifique se existe
caminho mais otimizado, se a causa no seria desatualizao das estatsticas ou ausncia real de
ndice secundrio. Eventualmente analise a possibilidade de reescrever o comando SQL.

Table Statistics for Optimizer

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

Tips for Optimizing ABAP

Uma boa opo para a otimizao dos programas abaps o uso to Tips&Tricks (transao ).
Atravs dessa transao podemos construir comandos sql e testar a sua efetividade. Nessa
transao ainda temos uma srie de sugestes e opes de implementaes com os respectivos
tempos de resposta.

Analysis Roadmap for sql statement

Many records transferred ?
Optimize abap code
Use EXPLAIN
Is the optimal index used ?
Special database tuning methods
Na optimal index exists but is not used by the optimizer ?
Are table statistics up-to-date ?
Refresh statistics
Where clause of sql statement too complex ?
Rewrite where clause
Are there missing indexes ?
Recreate missing indexes
Are the new indexes reasonable ?
Create new indexes

Pgina 148
ACADEMIA BASIS

Table Buffering

Concepts

A instancia R/3 possui uma srie de buffers para otimizar o processamento e a manipulao dos
dados. Os principais buffers que so utilizados so os de objetos do repositrio, de tabelas, de
programas, de janelas, de roll e paging, calendarios, number range, etc. A principal vantagem dos
buffers a otimizao e minimizao do acesso a base de dados com a manuteno dos dados mais

As tabelas de um banco de dados relacional so as principais beneficiadas com esta estratgia. O

tempo mdio de acesso a um dado buferizado reduzido drasticamente. Este um sofisticado
mecanismo e especializado categorizando a formas de buferizao. As trs formas possiveis so :
Full buffering, onde a tabela completamente buferizada e todas as suas linhas vo para a

Generic buffering, onde um nmero de campos identificadores declarado e toda a fatia de

dados acessada e relacionada a esta fatia carregada na memria. Tipicamente esta
estratgia utilizada para as tabelas dependentes de mandante pois necessrio declarar o
numero de campos (normalmente 2 ou 3) que compe a chave de buferizao
Single record buffering ou partial buffering, onde apenas a linha acessada no banco de dados
carregada na tabela e a partir da sempre acessada a cpia que est no buffer.

Synchronization

claro que temos que ter um tratamento especial se o dado que est no buffer for alterado por
outro usurio. A regra simples e se baseia em alterar o dado na base de dados e o buffer da
instncia de forma a garantir a completa consistencia do dado na instncia que provocou a alterao.
Para as demais instncias temos que ter um mecanismo mais complexo. Esse mecanismo baseia na
rdisp/buffrefmode e na manipulao da tabela DDLOG. Esse parmetro
que define o comportamento do sistema quando um dado que est em buffer alterado. Os valores

Sendon, sempre que um dado que est no buffer alterado feita uma marca na DDLOG
indicando que este dado deve ser invalidado em todos os buffers
Sendoff, evita que o mecanismo manipule a tabela DDLOG ignorando a sincronizao de
outras instncias (se elas existirem)
Execauto, garante que de tempos em tempos (definido pelo parmetro rdisp/bufreftime) a
instncia varre a tabela DDLOG para invalidar os dados que esto no buffer garantindo assim
que na prxima leitura o dado ser obtido no banco de dados
Execoff, evita que a tabela pesquise a tabela DDLOG de tempos em tempos para invalidar os
dados que esto no buffer

A regra geral para o rdisp/bufrefmode a seguinte :

Single system (sistema com apenas uma instncia) devemos preencher o parmetro com
sendoff,execauto que significa que toda alterao em um dado que est no buffer
atualizada na base de dados e no buffer mas no registrada na DDLOG
Distributed system (sistema com mais de uma instncia) devemos preencher o parmetro
com sendon,execauto que garante que toda alterao no dado propagada para o buffer
local, para a base de dados e registrada na DDLOG para garantir a sincronizao

Pgina 149
ACADEMIA BASIS

Granularity of invalidation

Durante o processo de invalidao do dado quando ele alterado (marca feita na DDLOG) os
demais buffers so afetados da seguinte forma :
Full buffering, qualquer alterao invalida toda a tabela
Generic buffering e single record buffering, alteraes feitas por um abap invalidam o conjunto
de dados relacionado ao mesmo conjunto (mesma chave de buferizao). Devemos tomar
cuidado com alteraes que no so executadas na work area mode pois elas invalidam todos
os dados da tabela (independente da forma de buferizao)

Todo esse mecanismo de definio se uma tabela deve ser buferizada feito pela transao
SE13.

Bypassing the Buffer

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

Strategy for Technical Criteria

Devemos buferizar tabelas que :

So relativamente pequenas (normalmente menores que 1 Mb) ou em casos especiais com

No sofrem alteraes (alteraes < 1% das leituras)

No precisam estar imediatamente consistentes em todo o ambiente
Podem ser acessadas pela chave primria
Contm dados de customizao
Tabelas condicionais da SAP com sufixo de 000 a 499 (Annn, Bnnn, Cnnn, Dnnn, KOTEnnn,
KOTFnnn e KOTGnnn)

No devemos buferizar tabelas que :

Tem tamanho superior a 10 Mb
A pesquisa por dados feita pelo indice secundrio
Contm dados transacionais
Contm dados mestres (tabelas grandes e acessadas por uma srie de indices secundrios)
Tabelas condicionais da SAP com sufixo de 500 a 999 (Annn, Bnnn, Cnnn, Dnnn, KOTEnnn,
KOTFnnn e KOTGnnn)

Devemos sempre lembrar de verificar se o buffer vai comportar a nova tabela que est sendo
buferizada.

Pgina 150
ACADEMIA BASIS

Optimization

Para otimizar os buffers de tabelas devemos ter em mente duas tarefas bsica : pesquisar por
tabelas que deverio estar buferizadas e no esto e pesquisar pelas tabelas que esto buferizadas e
no deverio estar. Para o primeiro caso, devemos procurar pelas tabelas desenvolvidas pelo cliente
(iniciadas por Z) e tabelas de customizao que normalmente no so buferizadas (sufixadas por 500
a 999). Para a segunda tarefa devemos verificar o tamanho e a frequencia de alteraes que

Para essa tarefa usaremos a transao ST10 (Table Call Statistics) e seguir o roadmap :
Pesquisar por alto numero de invalidaes
Verificar se esta tabela no deve ser desbuferizada. Para isso use a ST05 e ST10
Pesquise por tabelas com buffer muito grande
Verificar se esta tabela no deve ser desbuferizada. Para isso use a ST05 e ST10
Pesquisar por tabelas com alto numero de rows affected
Verificar se esta tabela no deve ser desbuferizada. Para isso use a ST05 e ST10
Pesquisar por tabelas com muitas leituras feitas por programas abaps
Verificar se a tabela no deve ser buferizada. Para isso verifique as estatisticas, a
frequencia de alterao, o tamanho, a viabilidade em funo da chave primria (transao
DB05) e a mdia de consumo de processamento (ST03, database time > 40% (response

Pgina 151
ACADEMIA BASIS

Others aspects about ORACLE

Cache Analysis

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

Shared SQL Area

Para compreendermos a shared sql area temos que ter os conceitos do uso que o Oracle faz dela,
do impacto que comandos SQL caros podem causar no consumo de cpu, de memria e de I/O aos
datafiles. A maior parte das anlises devem ser feitas utilizando a ST04 (Database Overview Monitor).

data buffer hit rate que significa o percentual de acerto na

leitura do dado que est no data buffer da shared sql area. O tamanho da shared sql area
considerado correto se esse percentual estiver sempre acima de 94%. Entretanto no devemos
analisar somente este numero. Um exemplo disso o resultado da diviso entre buffers gets por user
calls. Se ele for maior que 15, o data buffer hit rate deixa de ser significativo em funo do alto volume

Outra analise a ser feita a reduo do numero de buffer gets. Eles indicam que, provavelmente,
esse alto volume de dados que esto sendo manipulados por erro do comando abap ou por erro do
comando sql.

Para diferenciamos quais comandos devemos analisar na ST10 (ST04 -> detail menu -> sql
command) seguiremos o seguinte padro :
Abap open sql, comando em letras maiusculas e com aspas delimitando os nomes dos campos
Recursive call, comando em letras minusculas
Sap statement ou exec sql statement, comando em letras maiusculas sem aspas como
delimitadores
Third party statement, comandos com letras maiusculas e minusculas

Analyzing SQL Statements

Para analisarmos um comando sql devemos estar apto a reconhecer um comando caro, analisar o
impacto causado na shared sql area, entender o explain e a distribuio estatstica.

Um comando sql caro pode ser de dois tipos. O primeiro tipo aquele que acessa um grande
volume de dados (buffer gets) mas retorna poucos registros. Tipicamente o problema deste comando
esta relacionado a m escrita da clausula where ou ao uso erro de indice pelo otimizador. O segundo
tipo aquele que tambm acessa um grande volume de dados e retorna todo ele para o emissor do
comando sql. Esse problema est relacionado a uma m construo do abap que desloca o
processamento que deveria ser feito pelo banco de dados para o processador onde o abap est
sendo executado gerando um grande trafego de dados na rede.

Para identificarmos estes comandos pesquisaremos na ST10 por altos volumes em buffer gets,
disk reads e records (cada um desses itens possui seu prprio hit ratio). Devemos estar atentos a
alguns indices que indicam uma m performance, como :
Nmero de buffer gets maior que 5% do total de reads
Alto nmero de buffer gets
Alto nmero de buffer gets por registro
Alto nmero de registros por execuo

Pgina 152
ACADEMIA BASIS

Comandos que lem mais que 2% do total de leituras fsicas

De posse de um comando aparentemente pesado para o sistema podemos analisar detalhes de

como o sql foi processado atravs do explain. Podemos tambm verificar se a estatistica est
atualizada e eventualmente atualiza-la especificamente para uma tabela atravs da transao DB20
ou criar indices mais adequados atravs da SE11 ou SE12

Update Statistics

A estatstica da distribuio de valores de tabelas no R/3 sempre feita em dois passos. O

primeiro a verificao de quais tabelas esto com as estatsticas desatualizadas e a marcao na
DBSTATC das quais devem ser refeitas. Se for necessrio podemos utilizar a transao DB21 para
dar manuteno na DBSTATC. O segundo passo a atualizao propriamente dita. A processo de
atualizao pode ser feito seguindo dois algoritmos distintos : compute (onde toda a tabela
analisada para determinar a distribuio) e estimate (onde uma amostragem feita para determinar a
distribuio). A Sap recomenda que este procedimento seja feita pelo menos uma vez por semana ou
sempre que houver um grande volume de dados incluidos ou excluidos no banco de dados. Para
esse agendamento devemos utilizar a DB13. Se for necessrio atualizar uma tabela especfica
utilizaremos a DB20.

Identify Coding

Um grande problema na anlise da performance do sistema a identificao de um comando sql

que produz efeitos danosos ao sistema. Para localizarmos o comando utilizamos a transao ST04
(shared sql area) como j foi visto no item anterior de analise de sql. O passo seguinte a
identificao de qual cdigo abap provavelmente contm este comando. Esse processo consiste em
pegarmos o nome da tabela e listarmos, atravs da SE11 e where-used, onde ela utilizada. Depois
disso entramos em programa a programa para tentar localizar a origem do comando. Esse sem
dvida um trabalho muito arduo.

Outra boa opo a identificao do comando no momento que ele acontece atravs das
transaes SM50 e SM66. Nesse caso temos a vantagem de saber quem e qual a transao esta
provocando os efeitos indesejveis. Para facilitar, podemos selecionar os processo que manipulam a
respectiva tabela atrves da SM66 -> select process.

Sempre que tentamos identificar o cdigo abap que produziu o sql devemos ter em mente as
diferenas entre o open sql e o sql nativo. Devemos analisar as facilidades que o open sql permite e
como elas so convertidas para o sql nativo, como por exemplo as tabelas internas (in itab) ou a
clausula for all entries. Alm disso temos que lembrar que o abap pode estar fazendo referencia a
uma view e o sql nativo provavelmente vai estar referenciando a tabela. Para esse caso, lembre de
pesquisar o where-used para a tabela em questo. Outra opo descobrir a rea funcional atravs
do programa RSSTATUS ou os componentes relacionados a tabela atravs da DB15 e acionar o time
funcional responsvel para ajudar na pesquisa do respectivo cdigo abap.

Workflow and Reporting

Com a ativao do workflow no sistema podemos ter algumas facilidades de comunicao de

documentos e a respectiva aprovao destes pelos responsveis. Basicamente temos que definir a
atribuio de cada um (por exemplo, o administrador do sistema responsvel por analisar as
queries e recomendar alteraes de design; o desenvolvedor responsvel por construir e otimizar
os cdigos e as definies de banco de dados; e o usurio final responsvel por utilizar de forma
otimizada o sistema) e estabelecer quais documentos devem transitar entre estes grupos funcionais.
Com isso alguem pode solicitar uma determinada tarefa e encaminha-la para o executor. O executor
aps realizar a tarefa passa o documento para que valida a qualidade e esse responde ao gerador do
trabalho a resposta que o ciclo foi completado. Com isso passamos a utilizar a ferramenta de
workflow do R/3 nas atividades de basis e de abap integrando a atividades de todos.

Pgina 153
ACADEMIA BASIS

Um bom exemplo desse recurso a ferramenta de abrir chamados na SAP atravs do OSS. Essa
ferramenta que garante o bom encaminhamento das demandas dos usurios para a SAP e viabiliza
a acumulao de uma base de conhecimento.

Index Utilization

Devemos associar a utilizao de ndices no banco de dados com as estatsticas atualizadas e

com o otimizador de acesso baseado em custo. Sempre que utilizarmos uma clausula where (e em
alguns outros casos tambm) o otimizador entra em ao para decidir qual a melhor forma de obter
os dados na base de dados. Para que isso seja feito temos que ter os indices bem contruidos e
planejados para as atividades que sero executadas, alm das estatisticas atualizadas. Basicamente
temos que preocupar com a efetividade dos indices que existem e da seleo que ele permite. ndices
que no permitem a seleo de uma quantidade inferior a 4% da quantidade total de linhas no so

Alm disso devemos estar atentos as indicaes do explain do sql dos caminhos e mecanismos
que esto sendo tomados em um determinado sql. Os mais importantes e que devem ser entendidos

Index unique scan, o melhor caso pois permite a obteno de uma ou nenhuma linha com a
leitura de cerca de quatro blocos (tres no indice e dois na base de dados)
Index range scan, esse no muito bom pois no conseguimos saber quantos blocos sero
lidos para a obteno da informao desejada
Full table scan, a leitura simples e inteira da tabela e a quantidade de blocos afetadas
diretamente proporcional ao tamanho da tabela
Concatenation, onde o indice acessado vrias vezes em funo de opes OR ou IN com
a concatenao dos resultados de cada um dos acessos feitos
Nested loop, o conhecido join entre os dados de duas tabelas e seus respectivos indices

Creating na Index

Antes de criarmos um indice devemos verificar a sua efetividade atravs da simulao da criao
na DB05 e da verificao da distribuio estatsticas dos valores. Durante a anlis dos dados
produzidos pela DB05 devemos ter em mente que um bom indice aquele que permite que dado
uma chave ele nos retorne uma pequena quantidade de registros.

Outros fatores relacionadas aos indices no podem ser esquecidos, a saber : verificar se algum
indice standard no est faltando; executar sempre a atualizao de estatisticas das tabelas e dos
indices; alterar o cdigo para poder reaproveitar os indices j existentes; alterar os indices j
existentes para garantir uma boa performance na maior variedade possivel de situaes e
eventualmente criar um indice para atender especificamente um determinado tipo de pesquisa. Tudo
isso pode e deve ser feito, quando o indice for standard, sempre com a aprovao ou com o
aconselhamento da SAP.

Similar Statements

Tente garantir sempre que statements com a mesma funo sejam escritos de forma identica. Isso
garante um bom aproveitamento da shared sql area (ela sempre maximiza os recursos para
reaproveitar os cursores para o mesmo comando sql). Tente induzir o time de abap a criar
convenes para garantir que os comandos sejam escritos da mesma forma em programas
diferentes. Uma boa conveno a ser adotada combinar a ordem dos campos no comando sql igual

Para identificarmos se um mesmo comando foi escrito de formas diferentes procure comandos
com o mesmo numero de buffers gets/execution ou buffer gets/records. Isso pode ser um bom
comeo para detectar esses comandos mas lembrando sempre que isto um ajuste finssimo no
sistema.

Pgina 154
ACADEMIA BASIS

View Processing

View um objeto lgico que simula a existencia de uma tabela, virtual, que na verdade a juno
de uma ou mais tabelas. Na prtica o gerenciador do banco de dados executa um sql previamente
montado, que imagem da definio da view, sempre que algum dado solicitado da view. Ou seja,
um dado que acessado atravs da view no est previamente alocado a ela, ele descoberto e
acessado no momento da execuo. Os principais tipos de view so :
Nested loop, onde ordem de acesso as tabelas decida pelo otimizador com a identificao
da driven table que normalmente possui a menor quantidade de registros, seguido do acesso
a inner table para obteno dos demais dados
Sort Merge Join, onde os dados das diferentes tabelas so acessados, classificados e
finalmente mergeados
aconselhvel que monitoremos as novas views em busca de possveis problemas de
performances. Os mecanismos a serem utilizados so os mesmos mencionados anteriormente neste

Pooled and Clustered Tables

Tabelas pooled e clustered so tabelas que esto contidas em outras tabelas. Essa estrutura
herdada do ambiente mainframe e da poca em que os bancos de dados relacionais ainda no
existiam. Com essa estrutura podiamos viabilizar que um mesmo arquivo indexado poderia
representar uma srie de outros arquivos indexados. Provavelmente esse tipo de estrutura j havia
sido utilizado no R/2 e foi migrada para o R/3 com o respectivo reaproveitamento de cdigo. Os dois
tipos implementados no R/3 so : Pooled e Clustered. Para diferenciarmos uma tabela normal dessas
tabelas passaremos a chamar uma tabela normal de transparente table.

Pooled
Uma pool table uma transparent table que encapsula uma srie de outras tabelas conhecidas
como pooled tables. Isto possivel pela definio de uma tabela pool com a seguinte estrutura : uma
chave especifica que contem o nome da tabela pooled (TABNAME), um campo contendo a chave
genrica (VARKEY) e um campo contendo todo o conteudo a ser acessado atravs da chave
genrica (VARDATA). Com isso, utilizando apenas uma transparent table, podemos ter incontveis
tabelas dentro desta tabela.

Clustered
No R/3, a clustered table a implementao fsica de um banco de dados hierarquico em uma
estrutura de arquivo indexado. Essa estrutura tambm oriunda do mainframe e deve ter sido
mantida para garantir tambm o reaproveitamento. A clustered table na prtica o encapsulamento
de dados de tabelas diferentes em uma mesma linha. Ou seja, a juno de dados dependentes,
mesmo que oriundos de tabelas diferentes, da mesma chave primria. A estrutura de uma clustered
table um conjunto de campos que representam a chave primria que comum ao conjunto de
dados e o DATA que um conjunto de informaes no documentadas constituidas pelas tabelas

Common Mistake
Nunca tente manipular na clausula where de um sql os dados que vo estar ou na vardata de uma
pool table ou no data de uma cluster table. Ou seja, sempre e somente utilize na clausula where os
campos que compe a chave primria, tanto da pooled quanto da clustered tables.

Pgina 155
ACADEMIA BASIS

Workload Analysis Guide

Uma anlise geral pode indicar se existem problemas de performance gerais na instalao:
q Wait time dever ser < 10% response time
q Main menu dever estar < 100 ms
Atravs 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 no 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

Pgina 156
ACADEMIA BASIS

High paging rate > 20% of RAM per hour memory contention
Other servers available Work process and users redistribution
File system cache > 10% RAM reduce file system cache
q Buffers monitor (ST06 Mode list)
Programs with high memory detail analysis of transaction

Directory Summary

/usr/sap/trans
q bin, contm basicamente os arquivos de parmetros TPPARAM e CONFIG.CFG
q actlog, onde so gravados cada action em um request ou task. Contm files com nomes <source SID>Z<6 digits>
q sapnames, com arquivos associados ao id dos usurios 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

q data, contendo arquivos do tipo R9<5 digits>.<source SID> que contm 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 sero
executados
q log, com todas as logs de transportes, como por exemplo ULOGs, ALOGs, SLOGs e as demais logs que descrevem as
operaes executadas nos steps individuais ou coletivos

/oracle/<SID>
q dbs: contendo as profiles utilizadas pelo Oracle e pelo SAP (init<SID>.ora, init<SID>.sap, etc.).
q bin: executveis 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 reorganizaes, 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 configurao do NET8

To be Known

R/3 profiles (/usr/sap/<SID>/SYS/profile)

q Start profile: START_<instance>_<host>, que contm a relao dos componentes que sero ativados pelo sapstart na

q Default profile: DEFAULT.PFL, que contm alguns parmetros globais do sistema

q Instance profile: <SID>_<instance>_<host>, que contm parmetros especficos da instncia

Startup sequence (startsap)

1. Ativa o programa sapstart
2. O sapstart l a start profile para ativar os servios disponveis na instncia
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 sero ativados. Os processos sender e collector so 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 so
criados de acordo com as informaes da instance e da default profile. O gateway reader independe de parmetros 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) so logados pelo no Oracle alert file:
/oracle/<SID>/saptrace/background/alert_<SID>_.log

Pgina 157
ACADEMIA BASIS

Informaes detalhadas de erro so logadas no Oracle trace file: /oracle/<SID>/usertrace/ora_<pid>.trc

Quando se utiliza o sapdba para start e stop do banco de dados, o sapdba grava uma log no diretrio
/oracle/<SID>/sapreorg, .../sapcheck, .../sapbackup, dependendo da ao que foi executada

SAP/Oracle parameter files (/oracle/SID/dbs)

q init<SID>.ora: parametrizaes da instncia Oracle
q init<SID>.dba: parametrizao do sapdba
q init<SID>.sap: parametrizao das ferramentas BRBACKUP e BRARCHIVE

Environment variables
q ORACLE_SID=<SID>: nome da instncia
q DBS_ORA_TNSNAME: seta o <SID> do banco que ser conectado atravs do tnsnames.ora
q ORACLE_HOME: o diretrio home do oracle (/oracle/<SID>)
q SAPDATA_HOME e SAPDATAn: aponta para diretrios especficos contendo dados

Pgina 158
ACADEMIA BASIS

Anexos

Glossrio

Termo Descrio
ABAP ABAP significa Advanced Business Application Programming e uma
linguagem interpretada e de quarta gerao utilizada para desenvolver no
ambiente SAP. Tanto seus fontes quanto seus p-code so guardados no
banco de dados
ABAP dictionary o dicionrio que contm todas as informaes sobre as estruturas lgicas
dos objetos de aplicao e de banco de dados relacionais bem como os
fontes ativos e verses antigas dos programas. O dicionrio trabalha como
um dicionrio ativo e integrado com as ferramentas de desenvolvimento.
ABAP editor uma das ferramentas do ABAP Workbench e destinada ao
desenvolvimento e manuteno dos programas, funes, lgica de fluxo de
janelas, etc. Alm das funes normais de editor de programas a ferramenta
dispe de uma srie de acessrios para auxiliar no desenvolvimento.
ABAP program um conjunto de cdigo que processado seqencialmente atravs de um
mdulo interpretador de comando. Existem dois tipos de programas, os

ABAP workbench um ambiente integrado com uma srie de ferramentas para o

desenvolvedor produzir programas para o ambiente R/3
Activation Processo que torna um objeto disponvel para uso. O efeito direto da
ativao a gerao de um objeto runtime correspondente ao que foi
ativado. Este runtime que efetivamente interpretado pelo kernel
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 verses dos objetos
desenvolvidos pela SAP
Application data Dados especficos de um client e composto dos dados mestres e dos

Application server Mquina que prov servios como : dialog, update, enqueue, background
processing, print formating e gateway. Um application server contm um
dispatcher e um ou mais work process. O dispatcher recebe a solicitao do
servio a ser executado e atribui-o ao work process disponvel. Um
application server possui pelo menos um dialog e gateway.
Automatic Client change option que significa que a qualquer customizao 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 funes de gerenciamento do domnio de
controller transportes se o primary domain controller ficar indisponvel. ativado
manualmente.
Change and Todas as ferramentas disponibilizadas pelo R/3 para o gerenciar e
transport transportar todas customizaes e desenvolvimentos entre os sistemas R/3
organizers CTO dentro do landscape
Change Significa o gerenciamento das alteraes feitas no ambiente R/3 bem como a
management propagao destas para os demais ambientes com as respectivas
verificaes e consistncia seguido da ativao nos ambientes destino.
Change request Pacote contendo as informaes registradas e acumuladas pelas alteraes
feitas no ambiente durante o trabalho de um desenvolvedor ou configurador.
O principal uso de uma change request encapsular e propagar uma

Change request a caracterstica 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 manuteno de um client a opo que determina se alteraes

Pgina 159
ACADEMIA BASIS

Termo Descrio
options dependentes ou independentes de mandante podem ocorrer e se sero
armazenadas automaticamente.

Ainda no terminado

Pgina 160
ACADEMIA BASIS

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

Pgina 161
ACADEMIA BASIS

Transaction Description
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
SE85 ABAP/4 Repository Information System
SE86 ABAP/4 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)

Pgina 162
ACADEMIA BASIS

Transaction Description
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)

Pgina 163
ACADEMIA BASIS

Transaction Description
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

Pgina 164
ACADEMIA BASIS

Transaction Description
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
SMO2 Repository Information System: SMOD
SMO3 Repository Information System: SMOD
SMO4 Repository Information System: SMOD
SMO5 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

Pgina 165
ACADEMIA BASIS

Transaction Description
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

Pgina 166
ACADEMIA BASIS

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

Pgina 167
ACADEMIA BASIS

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

Pgina 168
ACADEMIA BASIS
Parameter
Rsisp/max_wprun_time
Rspo/auth/pagelimit
Auth/auth_number_in_userbuffer
Auth/no_check_on_tcode
eu/iwb/help_type
eu/iwb/installed_languages
eu/iwb/path_win32
eu/iwb/server_win32
Login/min_password_lng
Login/password_expiration_time
Rdisp/btcname
Rdisp/btctime
Rdisp/mshost
Rdisp/trace
Rdisp/wp_no_btc
Rsdb/reco_sleep_time
Rsdb/reco_trials
Default Description
300s
0 Active authorization for limit page printing
2000 Maximum number of authorizations in user buffer
N No authorization check on object S_TCODE
Type of Extended Help (format/access)
Installed Help Languages
File path for Help on Win32 platforms
HTTP server for help on Win32 platforms
Name of application server that processes events
60 Start Interval for Background Scheduler
Hostname where message server is located
Trace level for startup log
Number of background work processes
5s quantidade de tempo de espera para uma nova
tentativa de reconexo ao banco
3 Quantidade de tentativas de reconexo
Pgina 169