TADM10_1 ..................................................................................................................................................

7
Unit 1 – SAP Solutions ............................................................................................................................ 7
mySAP Business Suite and mySAP ERP ........................................................................................... 7
Definition of SAP NetWeaver ............................................................................................................ 7
The SAP Release Strategy .................................................................................................................. 7
Unit 2 - Navigation .................................................................................................................................. 8
Navigation in General ......................................................................................................................... 8
Advanced Navigation in the SAP GUI ............................................................................................... 8
Unit 3 – The System Kernel ..................................................................................................................... 9
Principal Architecture of the SAP Web Application Server ............................................................... 9
Dialog Processing in the SAP System ................................................................................................ 9
Communication with the Database ................................................................................................... 10
Appendix - The SAP Transaction ..................................................................................................... 10
Appendix - Lock Management in SAP Systems ............................................................................... 10
Appendix - Update Processing .......................................................................................................... 10
Unit 4 –Software development in SAP systems ...................................................................................... 10
Data Structure of an SAP System and Transports between SAP Systems (ABAP Stack) ................ 10
Accessing and Editing ABAP Repository Objects ........................................................................... 11
Appendix: Table Definition and the Two-Level Domain Concept ................................................... 11
Appendix: Modeling in the ABAP Dictionary .................................................................................. 11
Introduction to the SAP NetWeaver Java Development Infrastructure ............................................ 11
Unit 5 – Communication and Integration Tecnology ............................................................................ 12
Cross-System Business Processes ..................................................................................................... 12
Remote Function Calls and BAPIs ................................................................................................... 12
Web Services .................................................................................................................................... 12
SAP Business Workflow. .................................................................................................................. 12
Unit6 - Tools for SAP System Administration........................................................................................ 12
Daily Tasks in System Management ................................................................................................. 12
SAP Service Marketplace ................................................................................................................. 13
SAP Developer Network ................................................................................................................... 13
Unit 7 - SAP NetWeaver and Enterprise Services Architecture............................................................. 13
SAP NetWeaver: An Overview ........................................................................................................ 13
From SAP R/3 to mySAP ERP and the Enterprise Services Architecture ........................................ 13
Unit 8 - Basics ....................................................................................................................................... 13
What is a SAP System?..................................................................................................................... 13
Process of a System Logon ............................................................................................................... 13
Configuring SAP Logon ................................................................................................................... 13
Analysis Transactions ....................................................................................................................... 14
Unit 9 – Starting and Stopping the SAP System .................................................................................... 14
System Start: Process ........................................................................................................................ 14
System Start: Logs ............................................................................................................................ 14
System Shutdown: How and Why? .................................................................................................. 14
Appendix: Starting and Stopping Under Other Operating Systems .................................................. 14
Appendix: Database Logs ................................................................................................................. 14
Unit 10 – Introduction to System Configuration .................................................................................... 14
How the System Evaluates its Parameters ........................................................................................ 14
How to Set System Parameters ......................................................................................................... 15
Setting up Operation Modes ............................................................................................................. 15
Unit 11 – Fundamentals of Working with the Database ........................................................................ 15
Architeture of Database Systems ...................................................................................................... 15
Backing Up the Database Contents ................................................................................................... 15
Overview: Monitoring the database .................................................................................................. 15
Unit12 – Basics of User Administration ................................................................................................ 15
 User Administration Concept............................................................................................................ 15
Autorization Concept ........................................................................................................................ 15
Login Parameters and User Info ....................................................................................................... 15
Appendix: Adcanced User Administration Topics ........................................................................... 16
Unit 13 – Setting Up Remote Connections ............................................................................................ 16
Fundamentals and Types of RFC ...................................................................................................... 16
Setting Up RFC Connections ............................................................................................................ 16
Unit 14 – Working with the Transport System ....................................................................................... 16
Data Structure of SAP Systems and System Landscapes.................................................................. 16
Performing and Checking Transports ............................................................................................... 16
Unit 15 – Support Packages, Plugins and Add-nos ............................................................................... 17
Term Definition: Support Packages .................................................................................................. 17
Importing Support Packages ............................................................................................................. 17
Updating the Tools............................................................................................................................ 17
Importing SAP Notes ........................................................................................................................ 17
Unit 16 – Scheduling Background Tasks ............................................................................................... 17
Fundamentals of Background Processing ......................................................................................... 17
Time-Based Scheduling of Jobs ........................................................................................................ 18
Event-Based Scheduling of Jobs ....................................................................................................... 18
Background Processing: Other Topics .............................................................................................. 18
Job Scheduling: Extending the Standard........................................................................................... 18
Unit 17 – System Monitoring ................................................................................................................. 18
Monitoring Architecture ................................................................................................................... 18
Including Remote Systems ............................................................................................................... 18
Creating Your Own Monitors ........................................................................................................... 19
Properties Variants and Threshold Values ........................................................................................ 19
Concept of the SAP Solution Manager ............................................................................................. 19

TADM10_2 ................................................................................................................................................ 21
Unit 1 – Fundamentals .......................................................................................................................... 21
Fundamentals Concepts of Java ........................................................................................................ 21
The Architecture of SAP Web Application Server ........................................................................... 21
Java Cluster Architecture .................................................................................................................. 21
The Internal Structure of SAP Web AS Java .................................................................................... 22
Load Balancing in the SAP Web AS Java Environment................................................................... 23
Unit 2 – Starting and Stopping a SAP Web AS Java ............................................................................. 23
Overview of the Process of Starting and Stopping a SAP Web AS Java .......................................... 23
Java Startup and Control Framework ................................................................................................ 23
Starting under Microsoft Windows and UNIX ................................................................................. 23
Logs of the Start and Stop Processes of SAP Web AS Java ............................................................. 24
Unit 3 – Installation in the SAP Web Application Server Java Enviroment .......................................... 24
Installing an SAP Web AS Java ........................................................................................................ 24
Installation of SAP NetWeaver Developer Studio ............................................................................ 24
Unit 4 – Basic Configuration of SAP Web AS Java ............................................................................... 24
Administration and Configuration Tools for SAP Web AS Java ...................................................... 24
General Configuration of the SAP Web AS Java Cluster with Config Tool .................................... 25
General Configuration of the SAP Web AS Java Cluster with Visual Administration..................... 25
Other Administration Tools .............................................................................................................. 25
Selected Configurations .................................................................................................................... 25
Unit 5 – User Administration in Java Environment .............................................................................. 25
Overview of User Administration in Java ......................................................................................... 25
User Management Engine (UME) .................................................................................................... 25
User Administration Tools ................................................................................................................ 26
User Administration .......................................................................................................................... 26
The Java Authorization Concept ....................................................................................................... 26

2
 UME Parameters ............................................................................................................................... 27
Special Users and UME Log/Trace Files .......................................................................................... 27
Unit 6 – Monitoring SAP Web AS Java ................................................................................................. 27
Java Monitoring: Overview .............................................................................................................. 27
Monitoring SAP Web AS Java ......................................................................................................... 28
Appendix: Background Information About the Monitoring Service ................................................ 29
Connecting to a Central Monitoring Service; ................................................................................... 31
Log Viewer and Log Configuration .................................................................................................. 31
Availability Monitoring .................................................................................................................... 33
Statistics and the Performance Trace ................................................................................................ 33
Unit 7 – Change Management and Software Logistics in the SAP Web AS Java Environment ............ 34
Overview of the Standard J2EE Development Process..................................................................... 34
Introduction to the SAP NetWeaver Java Development Infraestructure (JDI) ................................. 35
Configuring the SAP NetWeaver Java Development Infraestructure ............................................... 36
Preparing for the Development of Java Applications ....................................................................... 37
Developing Java Objects in SAP NetWeaver Developer Studio ...................................................... 37
Transporting Java Developments ...................................................................................................... 38
Unit 8 – Importing Corrections ............................................................................................................. 39
Installing Corrections for SAP Web AS Java ................................................................................... 39
Installing Corrections for a Java Application .................................................................................... 39
Unit 9 – Backing Up SAP Web AS Java ................................................................................................ 40
Backing Up SAP Web AS Java ........................................................................................................ 40
Unit 10 – Technology Components for Browser-Based User Dialogs .................................................. 40
Internet Schenarios with SAP Systems ............................................................................................. 40
SAP Internet Transaction Server (Standalone) ................................................................................. 40
Internet Communication Manager .................................................................................................... 41
Internet Communication Framework ................................................................................................ 43
SAP Web Dispatcher ........................................................................................................................ 44

TADM12_1 ................................................................................................................................................ 46
Unit 1 – mySAP ERP Solution Architecture .......................................................................................... 46
Introducing to mySAP ERP Solution ................................................................................................ 46
New Features of SAP ERP Central Component and SAPinst........................................................... 46
Unit 2 – Planning the Installation of SAP Central Component ............................................................. 47
Planning the instalation ..................................................................................................................... 47
Unit 3 – Preparing for the Installation of SAP Central Component ...................................................... 47
General Preparation for Instalation ................................................................................................... 47
Futher preparation for Installation on Windows ............................................................................... 47
Futher preparation for Installation on Unix ...................................................................................... 48
Unit 4 – Installing SAP GUI .................................................................................................................. 48
Installation of SAP GUI for Windows .............................................................................................. 48
Installation of SAP GUI for Java ...................................................................................................... 48
Unit 5 – Installing the SAP ERP Central Component ........................................................................... 48
Introducing SAPInst ......................................................................................................................... 48
Installing and Patching Oracle Database Software ........................................................................... 49
Central Instance Installation ............................................................................................................. 49
Database Instance Installation ........................................................................................................... 49
Dialog Instance Installation .............................................................................................................. 49
SAP Web AS Java Central Instance Installation ............................................................................... 49
SAP Web AS Java Dialog Instance Installation................................................................................ 49
Appendix: SAP Gateway Installation ............................................................................................... 49
Unit 6 – Performing Post-Installation Activities ................................................................................... 50
Installation of SAP License and Other Components ......................................................................... 50
TMS and Basic Configuration .......................................................................................................... 50
Additional Tasks ............................................................................................................................... 50

3
 Appendix: Specific Post-Installation Activities ................................................................................ 51
Unit 7 – Implementing Patches .............................................................................................................. 51
Applying Patches .............................................................................................................................. 51
Unit 8 – Converting Non-Unicode to Unicode ...................................................................................... 51
Procedure for Converting Non-Unicode to Unicode......................................................................... 51
Unit9 – Troubleshooting Installations Problems ................................................................................... 51
Solving Problems During SAP ERP Central Component Installation .............................................. 51
Unit 10 – Introduction to Software Logistics ......................................................................................... 51
SAP System Landscape .................................................................................................................... 51
Client Concept .................................................................................................................................. 51
System and Client Change Options .................................................................................................. 52
Unit 11 – Setting Up an SAP System Landscape ................................................................................... 52
Setting Up the Transport Management System (TMS) ..................................................................... 52
Extended Transport Control .............................................................................................................. 53
Unit 12 – Customizing and Development in ABAP................................................................................ 54
Customizing and Customizing Projects ............................................................................................ 54
Customizing Tools ............................................................................................................................ 54
Customizing Procedure ..................................................................................................................... 55
Managing Workbench Change Requests .......................................................................................... 55
Prerequisites for development ........................................................................................................... 56
Handling Repairs and Modifications ................................................................................................ 57
Unit 13 – Transport Management in ABAP ........................................................................................... 57
The Transport Process....................................................................................................................... 57
Imports Using TMS .......................................................................................................................... 58
QA Approval Procedure and Transport Proposal ............................................................................. 59
Monitoring Tools .............................................................................................................................. 59
Transport Directory Structure and Files ............................................................................................ 60
tp, The Transport Protocol Program ................................................................................................. 60
Import Process .................................................................................................................................. 61
Troubleshooting transports ............................................................................................................... 62
Cleaning Up the Transport Directory ................................................................................................ 63
Unit 14 – Client tools............................................................................................................................. 63
Client Copy and Transport Tools ...................................................................................................... 63
Client Compare and Maintenance Tools ........................................................................................... 64
Unit 15 – Note Assistant, SAP Support Packages and Upgrades .......................................................... 64
SAP Note Assistant ........................................................................................................................... 64
SAP Support Packages ...................................................................................................................... 65
SAP System Upgrade ........................................................................................................................ 67

TADM12_2 ................................................................................................................................................ 69
Unit 1 – Introduction to Workload Analysis .......................................................................................... 69
Components of Dialog Step .............................................................................................................. 69
Statistical Records and the Workload Monitor ................................................................................. 69
Unit 2 – Performance Analysis Monitors .............................................................................................. 70
SAP Performance Monitors .............................................................................................................. 70
Analysing SAP Web AS Java Performance ...................................................................................... 72
Analysing ICM Performance ............................................................................................................ 72
Performance Analysis on Integrated ITS .......................................................................................... 72
Unit 3 - SAP Memory Management ....................................................................................................... 73
Memory Areas .................................................................................................................................. 73
SAP Memory Allocation ................................................................................................................... 74
Implementation Of SAP Extended Memory ..................................................................................... 75
Memory Usage for SAP Web AS Java ............................................................................................. 75
Unit 4 – Hardware Bottlenecks ............................................................................................................. 76

4
 Hardware Bottlenecks ....................................................................................................................... 76
Optimizing Hardware Utilization...................................................................................................... 77
Unit 5 – Expensive SQL Statements ....................................................................................................... 77
Detecting Expensive SQL Statements .............................................................................................. 77
Analysis and Tuning of Expensive SQL Statements ........................................................................ 78
Unit 6 – SAP Table Buffering ................................................................................................................ 78
Introduction to Table Buffering in SAP Systems.............................................................................. 78
Analyzing Table Buffering ............................................................................................................... 79
Unit 7 – RFC Monitoring ...................................................................................................................... 79
Remote Function Call Basics ............................................................................................................ 79
Monitoring RFC Load and Solving RFC Load Problems ................................................................. 80
Unit 8 – Acess to Help ........................................................................................................................... 81
Configuring the Online Documentation ............................................................................................ 81
Unit 9 – Introduction to System Security ............................................................................................... 82
Security in the SAP Environment ..................................................................................................... 82
Unit 10 – Archiving ............................................................................................................................... 83
Fundamentals of SAP Data Archiving .............................................................................................. 83
Performing Data Archiving ............................................................................................................... 83
Accessing Archived Data .................................................................................................................. 84
Unit 11 – Including Printers in SAP Systems ........................................................................................ 84
Configuring Printers in SAP Systems ............................................................................................... 84
Concept of Logical Spool Servers .................................................................................................... 85
Managing Spool Requests ................................................................................................................. 86
Unit 12 – Structured Troubleshooting ................................................................................................... 86
Trace options..................................................................................................................................... 86
Unit 13 - Advanced User Administration Topics ................................................................................... 88
Introduction to CUA ......................................................................................................................... 88
Setting UP a CUA ............................................................................................................................. 88
User Administration with the CUA .................................................................................................. 88
Introduction to Directory Services .................................................................................................... 88
Technical Connection of Directory Services .................................................................................... 89

TADM51 .................................................................................................................................................... 90
Unit 1 – Database Overview.................................................................................................................. 90
Database Architecture ....................................................................................................................... 90
Connecting to the Database .............................................................................................................. 93
Database Administration Tools ......................................................................................................... 95
Administration of Oracle Instances................................................................................................... 96
Unit 2 – Backup, Restore & Recovery ................................................................................................... 97
Backup Strategy ................................................................................................................................ 97
Backup Tools and Tape Management ............................................................................................... 98
Performing Backups........................................................................................................................ 103
Restore and Recovery ..................................................................................................................... 104
Advanced Backup Techniques ........................................................................................................ 106
Unit 3 – Monitors and Tools ................................................................................................................ 107
Introduction to Oracle Data Management ....................................................................................... 107
Database System Check .................................................................................................................. 110
CCMS Alert Monitor ...................................................................................................................... 112
Unit 4 – Storage Management ............................................................................................................. 112
Tablespace Administration ............................................................................................................. 112
Reorganization of Tables ................................................................................................................ 113
Housekeeping and Troubleshooting ................................................................................................ 115
Unit 5 – Introduction to Oracle cache management............................................................................ 116

5
 Oracle System Global Area ............................................................................................................ 116
Oracle Program Global Area........................................................................................................... 118
Unit 6 – Monitoring of the database instance ..................................................................................... 118
The New Oracle Database Monitor provided by SAP .................................................................... 118
Oracle Wait Interface ...................................................................................................................... 120
Unit 7 – Analysing Application Design ............................................................................................... 122
Consequences of Expesive SQL Statements ................................................................................... 122
Using SM50/SM66 to Find Expensive SQL Statements................................................................. 122
Using ST03N/STAD to Find Expensive SQL Statements .............................................................. 122
Using ST04N to Find Expensive SQL Statements .......................................................................... 122
Using the SQL Trace to Find Expensive SQL Statements .............................................................. 123
Exlusive Lockwaits ......................................................................................................................... 123
Unit 08 – Index Management and Optimization .................................................................................. 123
Index utilization .............................................................................................................................. 123
Creating an Index ............................................................................................................................ 124
Unit 09 – Cost Based Optimizer .......................................................................................................... 125
Update Statistics ............................................................................................................................. 125
Cost Evaluation ............................................................................................................................... 125
Unit 10 – Analysing Memory Configuration ....................................................................................... 126
Data Buffer Utilization ................................................................................................................... 126
Efficience Of Shared Pool .............................................................................................................. 126
Monitoring the Automatic Program Global Area ........................................................................... 126
Unit 11 Analyzing Physical and Logical Layout ................................................................................. 128
I/O contention ................................................................................................................................. 129

6
TADM10_1
Unit 1 – SAP Solutions
mySAP Business Suite and mySAP ERP
SAP NetWeaver: infra-estrutura tecnológica para todos os produtos SAP;
mySAP Business Suíte: produtos para as indústrias, baseadas no NetWeaver;
SAP Smart Business Solution: soluções para pequenas e médias empresas. SAP All-in-
one: comparado ao R/3. SAP Package Solution: pacotes de soluções do Business Suite
que podem ser combinados para atender um cliente. SAP Business One é para micro
empresas, compilado em C++, funciona em windows e possui funções como financeiro,
customer management, etc.
SAP xAPPS: Collaborative Cross Applications: integra soluções existentes, acessando
datasets e funções.
Industry Solutions: Add Ons para indústrias específicas. Instalado no R/3.
mySAP Business Suíte
mySAP ERP: baseado no SAP ECC System, mySAP HR e mySAP Financials;
Formas de integração: Aplication Link Enabling (ALE), Eletronic Data Interchange
(EDI), XML, Collaborative Cross Application (xAPPS) e Web Services.

Definition of SAP NetWeaver

Base técnica do mySAP Bussines Suíte, do xAPPS, do ESA (Enterprise Services
Achitecture) e o conceito para Web Service.
Níveis de integração:
- People Integration: garante que os funcionários terão informações e funções
necessárias ao trabalho. O Enterprise Portal é a peça chave;
- Information Integration: provê informações da empresa. O SAP Business Information
Warehouse é o core. Knowledge Management e Master Data Management são as
funções centrais para o armazenamento de dados máster;
- Process Integration: permite que processos possam correr entre sistemas. Peça chave é
o Exchange Infraestructure (SAP XI);
- Application Platform: SAP Web Application Server: J2EE e ABAP runtime. Suporta
Web Applications e Web Services.
SAP WEB AS:
- ambiente de execução testado e confiável;
- ambiente seguro para execução de complexos processos de negócio;
- ambiente de desenvolvimento amigável e confiável;
- suporta padrões abertos, como HTML, XML, etc.;
- alta escalabilidade;
- suporta vários SO e SGBDs.

The SAP Release Strategy

Ramp-up:
- novos produtos ou novas releases a serem lançadas;
- pode ser usado como sistema produtivo;
- liberado apenas para alguns poucos clientes, que concordam em usá-lo;
- serve para avaliação das funcionalidades antes do produto ser oficialmente lançado;
- contato direto com o desenvolvimento da SAP e possuem suporte na implementação.

7
Manutenção do sistema SAP:
- Usando Support Packages, Support Package Stack, Kernel Patches, etc. ou por novas
versões do produto;
- Upgrades são possíveis mesmo quando se muda o produto (de SAP R/3 para mySAP
ERP).
Estratégia de manutenção 5-1-2:
- 5 anos de manutenção “oficial”;
- 1 ano de manutenção com 2% de acréscimo;
- 2 anos de manutenção com 4% de acréscimo;
- Mais anos por conta do cliente.

Unit 2 - Navigation
Navigation in General
Tipos de GUI: for windows, for java, for HTML.
SAP GUI for HTML:
- consiste no ITS pelo lado do servidor e o browser pelo lado do cliente;
- ITS converte dados do WEB AS em HTML, enviando via WGate;
- Não é necessário instalar nada no browser;
- Nem todas funções estão disponíveis.
Seqüência: SAP GUI  SAP Logon (escolher os sistemas)  Logon.
Password pode ser trocado apenas 1x por dia.
Parâmetro rdisp/max_alt_modes: quantidade de sessões que podem ser abertas (2 a 8).
User Máster Record: dados de um usuário em um client.
Imagem da página inicial é carregada no GUI toda vez que faz logon. Recomendadas
imagens < 20Kb
Itens da tela:
- Command field: para ir diretamente a uma transação;
- Menu Bar
- Standard Toolbar: botões exibidos em todas as telas;
- Title bar
- Application Toolbar: botões referentes à tela local;
- Status bar: status do sistema;
/nend fecha todas as sessões perguntando, /nex fecha todas as sessões, sem perguntar. /i
fecha apenas a atual.

Advanced Navigation in the SAP GUI

2 tipos de menu: SAP Menu (original) e user menu (customizado via roles). Tabela
USERS_SSM define usuários que podem acessar qual tipo de menu.
Transações SEARCH_SAP_MENU e SEARCH_USER_MENU servem para procurar
por texto as transações desejadas (não são abertas via duplo clique).
Favoritos: salvos para um usuário em um sistema.
F1 – explica o conteúdo de campos, menus, funções e mensagens
F4 – mostra os últimos 15 comandos digitados naquele campo, ou os possíveis valores
para aquele campo.
F2 – ou edit  select options permite busca avançada.

8
Unit 3 – The System Kernel
Principal Architecture of the SAP Web Application Server
ABAP (Advanced Business Application Programming).
Web AS Java foi introduzido na versão 6.20.
Enterprise Java Beans (EJB): empacotamento da lógica da aplicação. Representa
componentes dos programas java.
Três camadas de processamento: presentation (telas), application e database.

Application server ABAP:

- ABAP Dispacher distribui as requisições dos usuários entre os Work Process;
- Dialog Work Process (D): processa os “dialog steps” disparadas pelo usuário. Mínimo
de 2 por dispacher. Parâmetro rdisp/wp_no_dia;
- Spool (S): gera as saídas para impressoras. Mínimo 1 por sistema, podem ter vários por
dispacher. Parâmetros: rdisp/wp_no_spo;
- Update (V): processa updates no banco. Mínimo 1 por sistema, podem ter vários por
dispacher. Separado em V e V2: updates não tempo-críticos. Parâmetros
rdisp/wp_no_vb e rdisp/wp_no_vb2;
- Background (B): processos em background. Mínimo 2 por sistema, podem ter vários
por dispacher. Parâmetro rdisp/wp_no_btc;
- Enqueue (E): administra a lock table na shared Memory. Apenas 1 por sistema.
Sistema: rdisp/wp_no_enq.
Adicionalmente:
- Message Server (MS): gerencia a fila de execução ABAP, entregando a vários
dispachers. 1 por sistema;
- Gateway (GW): gerencia comunicação entre sistemas SAP ou SAP com externos. 1
por dispacher;
- Internet Communicator Manager (ICM): conversação entre SAP e a internet.

Application Server Java:

- Java Dispacher distribui as requisições para os Java server process;
- Java Server Process: executa as aplicações em multi-threads;
- Java Message Service: gerencia comunicação com os dispachers e server processes e
com o JRE;
- Java Enqueue Service: gerencia os locks lógicos;
- SAP Java Conector (JCo): comunicação entre JAVA e ABAP.
- SDM (Software Development Manager): realiza instalação dos componentes Java no
sistema, e é sempre instalado como parte do central instance.

Instância = AS = serviços juntos (sob junto, desce junto, configura junto...).

Central Services: instância separada; possui o message service e o enqueue service.
Representa a base de comunicação e sincronização do JRE.

Dialog Processing in the SAP System

Work Process:
- task handler: coordena ações do work process;
- Screen processor: executa a lógica da tela, dividido em PBO (process before output)
que é o processamento antes da imagem ser enviada e PAI (process after input) que é o
processamento após interação do usuário;
- ABAP Interpreter: processa o código ABAP;

9
- Database interface: acessa o banco.

Communication with the Database

ABAP usa SAP Open SQL: AS verifica a sintaxe, transforma no SQL específico da
base, otimizando os buffers.
EXEC SQL executa a query direto no banco, sem buffers, etc.

Appendix - The SAP Transaction

Características (ACID):
- Atomic: executou totalmente com sucesso ou não fez nada;
- Consistent: obedece a regras de negócio;
- Isolated: outras operações só enxergam esta após o commit;
- Durable: no final das contas é gravada no banco.

Appendix - Lock Management in SAP Systems

Como uma transação lógica pode ser feita por vários dialogs (e cada um faz commit no
banco quando termina de processar), o SAP tem seu próprio lock management.
Tipos de lock:
- X: Write locks: se não há lock, ele é consedido e ninguém mais efetua locks nessa
entrada;
- E: Extended Write Lock: só é consedido se não houve lock antes. Somente o owner do
lock pode liberar futuros locks;
- S: Shared Locks: locks futuros (não de escrita) podem ser requisitados;
- O: Optimistic Lock: >= AS 6.40, dados foram abertos para edição, mas ela não
começou efetivamente. O lock é resolvido no salvamento.
Transação SM12 exibe os locks: em azul para os do update work process e preto para os
do dialog work process.

Appendix - Update Processing

D/B Work process pede lock  Enqueue WP faz o lock  o programa grava alterações
nas VB* tables  user salva dados (COMMIT WORK), WP chama o V WP  V WP
lê das VB* Tables e grava no banco.
V1: time critical e libera locks
V2: updates não time critical (ex.: criar uma alteração de documento).

Unit 4 –Software development in SAP systems

Data Structure of an SAP System and Transports between SAP
Systems (ABAP Stack)
Client é uma unidade independente em termos de negócio, organização e dados.
Customizing é o setup de dados por client. Cross-client customizing para todos os
clients.
Repository é o repositório ABAP. Objetos agrupados formam um package. As
modificações podem ser de 3 tipos:
- Customer Developments: adicionando objetos ao repositório;
- Customer Echancements: melhorias adicionadas pelo desenvolvedor, chamadas a
partir de user exits ou Business Add-Ins (BAdIs);
- Modifications: modificação no objeto original.
Three System Landscape.

10
Objetos do repositório são transportados e logados pelo Transport Organizer (SE09 e
SE10). Customizações são tratadas também pelo Transport Organizer:
- Workbench: alterações no repositório;
- Customizing: customizações.
Analista cria a request (transportável ou local) e associa a desenvolvedores  TMS cria
nome <SID>K9<nnnn>  desenvolvedores associam objetos e liberam a task (o que
transfere objetos da task para a change request)  todas tasks liberadas, o analista pode
liberar a request  objetos são gravados no file system  administrador importa no BD
de destino.
Cada desenvolvedor utiliza uma task.

Accessing and Editing ABAP Repository Objects

Características do ABAP:
- Começa com um comando, termina com um ponto;
- Possibilidade de desenvolvimento multi linguagem;
- desenvolvimento de telas de forma simplificada;
- permite programação orientada a objetos;
- Independente de BD;
- Acesso eficiente a estruturas de dados;
Ferramentas de desenvolvimento (ABAP Workbench):
- ABAP Editor (SE36);
- ABAP Dictionary (SE11): tabelas, elementos de dados, lock objects, etc.;
- Screen Painter (SE51);
- Function Builder (SE37): desenvolvimento de funções;
- Object Navigator (SE80): índice para demais itens.
Usuário cria programa  Especifica título e atributos  associa a request  trabalha no
código  ativa para poder usar (gerando nova versão).
Packages: agrupamento de objetos relacionados.
Transação SE80, abrir Web Application Builder para criar BSPs
ABAP Dictionary: definições técnicas e de negócios do SAP data. Outros tools acessam
essas informações. Dividido em:
- Database definition objects (tables, views, ...);
- type definitions (estrutura, tipos de tabela, ...);
- service definitions (F1 para ajuda, lock objects, etc.).

Appendix: Table Definition and the Two-Level Domain Concept

Quando se ativa a tabela no dicionário de dados, ela é criada no BD.
Data element: ex.: aeroporto de origem, aeroporto de destino.
Domain: ex.: aeroporto (que é usado nos dois campos acima).

Appendix: Modeling in the ABAP Dictionary

Modelos permitem reduzir a complexidade do sistema em componentes essenciais.
Documentam os relacionamentos orientados a negócio e os processos no dicionário
ABAP.

Introduction to the SAP NetWeaver Java Development Infrastructure

JRE:
- Class loader: lê as classes necessaries;
- Bytecode Verifier: verifica se as classes são compatíveis com a JVM;
- JVM.
11
J2EE (runtime environment):
- JVM;
- standard Java Interfaces;
- outros componentes para executar aplicações Java e applets.
SAP NetWeaver Developer Studio: ferramenta da SAP para desenvolvimento J2EE.
Desenvolvido no Developer Studio, guardado no Design Time Repository (DTR –
permite versionamento), build via Component Build Service (CBS – permite build
centralizado, ativação sob demanda), transporte via Change Management Service
(CMS).
4 System landscape: DEV  CONS  TEST  PROD

Unit 5 – Communication and Integration Tecnology

Cross-System Business Processes
Para aplicar Application Link Enabling (ALE):
- Identificar os processos de negócio e os objetos;
- Identificar informações a serem transmitidas;
- Especificar o formato de dados;
- Tipo de tecnologia usada;
- Tipo de transferência;
- Destino da transferência.
BAPI: Bussines Application Programming Interfaces: interface que comunica com um
objeto, através de métodos (ex.: alterar cadastro de algo).
Transferência síncrona: na hora q acontece. Assíncrona: agendada.

Remote Function Calls and BAPIs

RFC (remote function call): interface (não programa) executa funções em sistemas
remotos ou no próprio sistema. Baseado no CPI-C e TCP/IP controla o processo de
comunicação, parâmetros de transferência e controle de erros.
Usuário do destino pode ser configurado na RFC, ou digitado no código que usa a RFC.
Quando vários usuários usam uma RFC, é chamada Trusted RFC.

Web Services
Web Service: serviço acessado via internet.
Enterprise Service: conjunto de serviços que representam uma lógica de negócio.
Desenvolvedor publica o Web Service no diretório (UDDI), descrito na linguagem
WSDL. O cliente pode pesquisar nesse diretório via protocolo SOAP.

SAP Business Workflow.

Eventos do workflow chamam BAPIs.

Unit6 - Tools for SAP System Administration

Daily Tasks in System Management
SM37: background Jobs;
SM51: server ativos;
SM04: usuários logados na instância;
AL08: usuários logados em todas instânias;
SM50: detalhes dos work process na instancia;

12
SM66: detalhes dos work process global;
SM12: locks lógicos.
SM13: update work process (V1 e V2). Não reprocessar V1.
SM21: System log. Tamanho máximo especificado pelo parâmetro
rslg/max_diskspace/local (192Kb por entrada no log).
SM02: mensagens para usuários.
SU01: perfis de usuários
SU10: manutenção de profiles em massa.
RZ20: monitoramento do ambiente.
RZ21: configuração dos parâmetros da RZ20.

SAP Service Marketplace

Nenhum comentário.

SAP Developer Network

Nenhum comentário.

Unit 7 - SAP NetWeaver and Enterprise Services Architecture

SAP NetWeaver: An Overview
Portal e collaboration
Mobile Infraestructure: básico para “SAP Solution for Mobile Business”. Aplicativo que
converte em HTTPS conversação com o NetWeaver com SAP Móbile Infraestructure
server instalado.

From SAP R/3 to mySAP ERP and the Enterprise Services

Architecture
Características da ESA:
- geralmente implementada entre sistemas;
- ABAP ou Java;
- Não possui base própria;

Unit 8 - Basics
What is a SAP System?
Um banco de dados e uma ou mais instâncias.
O q é uma instância: unidade administrativa que provê serviços. Esses serviços são
iniciados ou parados juntos, e configurados (ABAP) através de parâmetros. Possui um
dispacher, 2 dialogs, etc...

Process of a System Logon

Saplogon passa uma série de informações para o SAPGui, que requer uma tela de logon
 dispacher devolve tela de logon  GUI manda dados de logon para dispacher (pode
ser outro)  manda para um dialog vazio  dialog verifica no banco se user e senha
estão ok  retorna para o user, que estará neste último dispacher até logoff.
Work Process Multiplexing: uma transação pode usar vários Work Processes.

Configuring SAP Logon

Nenhum comentário

13
Analysis Transactions
Idem unidade 6.

Unit 9 – Starting and Stopping the SAP System

System Start: Process
BD  SAPOSCOL  Central Instance  Outras instâncias.

System Start: Logs

Windows:
- System Log: mensagens do SO e da aplicação
- Application Log: lista de erros, warnings
- Security Log: logins e acessos a arquivos.
Logs no DIR_HOME:
- STDERR1: startup do banco de dados;
- STDERR2: startup do message server;
- STDERR3: startup do dispatcher.
Parâmetro rdisp/TRACE: granularidade do trace (de 0 a 3). Padrão 1.
Logs de work process:
- Dev_ms: message server;
- Dev_rd: gateway;
- Dev_disp: dispacher;
- Dev_w<n>: work process

System Shutdown: How and Why?

Verificar usuários logados (SM04);
Verificar batches (SM37) e batch input (SM35)
Update (SM13);
Conexões externas (RFC, SM50);
Enviar mensagem (SM02).
RZ03: control  Stop SAP instance;
Parar banco de dados.

Appendix: Starting and Stopping Under Other Operating Systems

Unix: startsap_host_instance ou startsap se só houver uma instância. Para parar stopsap.

Appendix: Database Logs

SAPDB: \sapdb\data\wrk\<SID>.
MSSQL: …\MSSQL\LOG\ERRORLOG.
Oracle: \oracle\<SID>\saptrace\background\alrt.log (error) ou
\oracle\<SID>\sa[trace\usertrace\Ora<n>.trc (erros em detalhes).
DB2: \db2\<SID>\db2dump\.

Unit 10 – Introduction to System Configuration

How the System Evaluates its Parameters
\usr\sap\<SID>\SYS\pofile
Start Profile: processos que serão inicializados;
Default Profile: parâmetros para todas as instâncias;

14
Instance Profile: parâmetros para uma instância.
Para exibir parâmeros: RZ11 ou relatório RSPFPAR. Via SO: sappfpar.

How to Set System Parameters

RZ10: Verifica consistência, versiona, centraliza.

Setting up Operation Modes

Criar operation mode (RZ04)  atribuir instancias  distribuir work process  ajustar
o calendário (SM63).

Unit 11 – Fundamentals of Working with the Database

Architeture of Database Systems
Database process, fugger, data files e log files (dados alterados logados).

Backing Up the Database Contents

Recomendado: full diário, 28 dias, redo logs diários.
Agendamento DB13, DB12 para ver mais detalhes.

Overview: Monitoring the database

Além de verificar se o backup executou, atualizar estatísticas, verificar erros, etc.

Unit12 – Basics of User Administration

User Administration Concept
Tipos de users:
- Dialog: efetua logon;
- System: não efetua logon, não troca senha, usado para batch, RFC, ALE, Workflow,
etc.
- Communication: não efetua logon, setup de senha (validade, etc.), usado para
comunicação entre sistemas
- Service: usado para acesso anônimo via ITS, com baixas permissões, permitido
múltiplos logons, etc.
- Reference: referencia para criação de novos users.

Autorization Concept
Ações e acesso a dados são protegidos por authorization objects, que são formados por
object classes, que permitem determinada ação.
Quando se cria um menu com as transações em uma role, as autorizações vêm juntas.
Necessário verificar manualmente.
Ao associar user X role, não necessariamente começa a funcionar. Necessário fazer um
“user máster comparison”, que pode ser feita na PFCG  tab users  user
reconciliation ou via PFUD (defaul: 1x por dia).

Login Parameters and User Info

login/min_password_lng: tamanho mínimo da senha. De 3 (default) a 8 caracteres.
login/min_password_digits: quantidade mínima de dígitos;
login/min_password_letters: quantidade minima de letras;
login/min_password_specials: quantidade minima de caracteres especiais.

15
login/password_expiration_time: 0 (default) a 999 dias.
login/password/max_reset_valid: tempo em que a password alterada por administrador é
válida. 0 a 24000 dias.
login/password_max_new_valid: tempo em que a primeira senha é válida. 0 a 24000
dias.
Passwords:
- Não pode ser = últimas 5;
- Não pode começar com ?, ! ou espaço;
- Não pode ser “pass”;
- Não pode começar com 3 caracteres iguais.
login/fails_to_session_end: x vezes errado fecha sessão. 1 a 99. Padrão: 3.
login/fails_to_user_lock: quantidade de vezes erradas para bloquear usuário. 1 a 99.
Padrão: 12.
login/failed_user_auto_unlock: se desbloqueia usuário na virada do dia: 0 ou 1 (default);
login/disable_muilti_gui_login: usuário pode logar mais de 1 vez no mesmo client. 0
(default) ou 1.
login/multi_login_users: lista de user separados por vírgula q são excluídos da regra
acima.
Transação SUIM: overview de user máster records, autorizações, profiles, roles, etc.
SU53: mostras as autorizações que faltam para que o usuário possa completar a última
ação.

Appendix: Adcanced User Administration Topics

CUA + LDAP

Unit 13 – Setting Up Remote Connections

Fundamentals and Types of RFC
Tipos de RFC:
Síncrona (sRFC): para comunicação entre sistemas diferentes e entre o Web AS e SAP
Gui. Espera o retorno;
Assíncrona (aRFC): entre sistemas diferentes e processamento paralelo;
Transacional (tRFC): tipo de aRFC que garante o envio da interface;
Queued (qRFC): tipo de tRFC executada em seqüência.

Setting Up RFC Connections

Nenhum comentário.

Unit 14 – Working with the Transport System

Data Structure of SAP Systems and System Landscapes
Revisão de clients, customização e landscape de 3 sistemas.

Performing and Checking Transports

Goto  Tp systemlog

16
Unit 15 – Support Packages, Plugins and Add-nos
Term Definition: Support Packages
SP: correção de erros ou novas funcionalidades.
Componentes:
- Extension Set: extensão de uma funcionalidade;
- Industry Solution: software específico para uma indústria;
- Plug-In: interface entre componentes;
- Core Application (APPL): parte não HR de um ECC.
Tipos de SP:
- COP (Component Package): pacote dos componentes;
- CRT (Conflict Resolution Transport): resolve conflitos entre SP e ADD-Nos;
- PAT: novas funcionalidades para SPAM e SAINT

Importing Support Packages

SPAM: SPs;
SAINT: Industry Solution: Installation + upgrade.
Para aplicar um SP:
- Client 000;
- Atualizar última versão da SPAM/SAINT
- TMS configurado;
- Nenhum abort anterior.

Updating the Tools

Atualização da SPAM/SAINT via SPAM.

Importing SAP Notes

Nenhum comentário.

Unit 16 – Scheduling Background Tasks

Fundamentals of Background Processing
rdisp/max_wprun_time: tempo máximo em que um WP processará uma requisição,
antes de terminar o programa.
3 prioridades, com prioridade do especialmente configurado para rodar naquele servidor.
Um job consiste de um ou mais steps (ABAP, comando externo, programa externo).
Variants: entrada de dados de telas do programa executado no job.
Iniciado agora, agendado ou iniciado após evento.
SM36: criar novo job. SM36WIZ: wizard.
SM37: monitorar jobs.
Status:
- Scheduled: mandou rodar, mas não definiu quando começa;
- Released: mandou rodar, definindo quando começa;
- Ready: está na hora de executar, mas está aguardando WP livre;
- Active: executando;
- Finished: sucesso;
- Canceled: cancelado ou erro.

17
Time-Based Scheduling of Jobs
Nenhum comentário.

Event-Based Scheduling of Jobs

rdisp/btcname: nome do background server que processa batches iniciados por evento.

Background Processing: Other Topics

Se tiver jobs classe A, alguns WP ficam livres, mesmo tendo jobs B e C para rodar.
Configura-se isso na RZ04, recomendado 1.
Caso execute programa externo, o job chama o programa sapxpg, que chama o
programa. Não há como restringir se o usuário pode executar determinado programa no
SO ou não.

Job Scheduling: Extending the Standard

Nenhum Comentário.

Unit 17 – System Monitoring

Monitoring Architecture
A infra estrutura está instalada em todos componentes a partir de versões 4.x.
Cada componente coleta seus dados e coloca na memória (monitoring segment).
Recomendado ter um sistema independente para controle de transporte, CUA,
monitoramento central, ou usar o SM para isso.
Dividido em 3 níveis:
- data collection: coletores em cada programa, salva dados na memória;
- data storage: onde ficam os monitoring segments; e
- administration level (exibe e permite avaliação de dados).
Podem ser usados produtos de parceiros para o monitoramento, conectando no sistema
através de interfaces.
RZ20 mostra o monitoramento em formato de árvore, cada nó é chamado de Monitoring
Tree Element (MTE), e os valores são chamados de atributos (monitoring attributes).
Monitor sets são diferentes por produtos.
Os nós podem se repetir em várias árvores. Ajustando em uma, automaticamente são
alteradas nas demais.
Alguns monitores não exibem dados. Podem-se usar monitores padrões ou customizá-
los.
Ao abrir alertas, duas visões são possíveis:
- Current Status: dados mais novos;
- Open Alerts: dados históricos.
Selecionar alerta  Start Analysis Method (tool, URL, transação de ajuda...)  F3 para
voltar ao Alert Browser  Complete Alerts.
Show Alert History para ver histórico dos alertas (concluídos apresentados como Done).

Including Remote Systems

Para versões 3.x, usar programa SAPCM3X, para componentes não SAP SAPCCMSR.
Criar 2 RFCs (tipo 3), para que uma acesse os dados do monitoramento (usuário
communication), e outra para métodos de análise (current user).
Acessar RZ21, Technical Infrastructure  Configure Central System  Create Remote
Monitoring Entry.

18
Creating Your Own Monitors
SAP recomenda a criação de monitores customizados. Originais não podem ser
alterados.
Monitores devem conter poucos dados (por causa do RFC).
RZ20  Extras  Activate maintenance function.

Properties Variants and Threshold Values

Threshold values determinam quando o status muda de cor (verde, amarelo, vermelho).
Todos sistemas possuem valores padrões, porém a SAP recomenda configurar no
sistema central e transportar via TMS para outros sistemas (desde que estejam em
properties variants).
Properties variants são containers que guardam uma série de thresholds. Podem ser
criados vários, mas apenas um estará ativo por vez.
Vantagens:
- pode ser alterado de um variant para outro para testes.
- pode ser linkado com o operation mode;
- pode ser transportado usando o TMS.
RZ21  Properties  Variants.
Podem ser organizadas hierarquicamente, onde os valores não especificados são obtidos
pelo “pai”, até chegar ao padrão (SAP-DEFAULT).
Link com operation mode: RZ04  Operation Mode  Change  Monitoring
Properties Variant.
Após criar um variant, selecionar o atributo na RZ20 e ir em propriedades.
Para copiar via TMS: RZ21  Variant  Transport.

Concept of the SAP Solution Manager

Plataforma de serviços e suporte para implementação e operação de sistemas SAP. Provê
conteúdo, ferramentas e procedimentos para implementação, operação e suporte.
Suporta durante o início do projeto, implementação funcional e técnica, durante o
período em produção e durante a otimização dos landscapes.
Centralizar no SM provê: distribuição e sincronização centralizada de customizações,
gerenciamento de testes, monitoramento e gerenciamento de incidentes.
Para monitoramento, podem ser criados Solution Landscapes, monitorado via Early
Watch alerts (EWAs) ou via CCMS.
Funcionalidades:
- Serviços preventivos (Early Watch, GoingLive ...);
- Continuous Improvement services;
- Melhores práticas;
- Monitoramento da aplicação e do sistema;
- SAP Service Desk;
- Remote support (NetMeeting ...);
Suportes durante instalação:
- Gerenciamento de projetos;
- Repositório de processos de negócio;
- Ferramentas para cenários integrados de negócio;
- Integrated Implementation Guides;
- Suporte ao monitoramento de processos de negócio;
- Monitoramento centralizado;
- Tarefas de administração centralizadas;
- melhores práticas;
19
- Serviços remotos.
SMSY: transação para apontar para o SM.
Dados de monitoramento são coletados nos sistemas satélites, porém exibidos
centralmente na RZ20 do SM.
Pode-se usar o Service Desk para controlar mensagens de problemas.
Change request management:
- gerencia todas as requests;
- classifica-as;
- aprovação de workflow;
- trace de status;
- documentação de alterações.

20
TADM10_2
Unit 1 – Fundamentals
Fundamentals Concepts of Java
Propriedades:
- Aplicativos: usado para programação como em outras linguagens: local, client/server,
etc.
- Applets: pequenas porções de código para execução em navegadores, obedecendo a
regras de segurança;
Java é mais lento que outras linguagens compiladas, devido ser interpretado no runtime.
Isso é minimizado pelo JIT (just in time), que compila na linguagem nativa da maquina
em memória. Continua mais lento que C, porém com pouca diferença.
Java Development Kit (JDI) possui o Javac, JRE, applet viewer, java debugger, classes
“padrões”, documentação, etc.
JDK 1.2 = Java Plataform 2.
Java 2 Software Development Kit (SDK):
- Java 2 Standard Edition (J2SE): ambiente que define o SDK;
- Java 2 Enterprise Edition (J2EE): add-ons para o J2SE que adiciona Enterprise Java
Beans, Servlets, Java-Mail-API, ITS.
- Java 2 Micro Edition (J2ME): small runtime para PDAs e telefones. Substitui o
Personal Java e o Embedded java.
.jar: classes compiladas compactadas, em formato unzip ou winzip. O compilador se
encarrega de extrair.
J2EE define a estrutura de desenvolvimento de aplicações em 3 camadas, banco,
aplicativo e apresentação.
Servlets: páginas JSP compiladas em código Java.

The Architecture of SAP Web Application Server

Nenhum Comentário.

Java Cluster Architecture

Server Process: infraestrutura para aplicações Java;
Java Dispacher: distribui requisições dos clientes para server process da instância.
Central service: comunicação e sincronização no java cluster.
Connection request handler recebe solicitação do cliente  inicializa um objeto de
conexão (que é usado durante toda a sessão do user), usa o load balance para determinar
um server process  determina o tipo de serviço (ex.: http)  via communication
handler, contacta o server process.
Central Service:
- Message Service:
- Notificação de eventos do cluster (serviço para, etc.);
- Comunicação entre os serviços;
- encaminhar mensagens e requisições entre os serviços;
- prepara informações de logon para o SAP Web Dispacher;
- Suporta o failover;
- garante a transmissão da mensagem;
- cuida das informações do cachê da instância.

21
- Enqueue Service: administra os locks lógicos e a sincronização do cluster.

The Internal Structure of SAP Web AS Java

Startup: runtime enviroment  services  application
SAP Java Enterprise Runtime:
Realiza as operações “core”, através de managers:
- Log Manager: controla o processo de log;
- Ports Manager: controla a criação de portas;
- Application Thread Manager: controla as requests, associando à Threads ou
enfileirando;
- Thread Manager: controla as threads nas operações internas;
- IP Verification Manager: controla a listas de hosts e a usa para controlar os acessos a
elementos do cluster;
- Connections Manipulator: controla as conexões dos clientes no cluster (executado no
dispacher);
- Locking Manager: interface entre o server process e enqueue server;
- Configuration Manager: acessa banco de dados;
- Classloading Manager: centralizador do registro e remoção de loaders e referências
entre eles.
- Cluster Manager: gerencia elementos do cluster (dispatcher e server process):
- Join Port: entrada de conexões;
- Open Port: conexões entre elementos do cluster;
- Cluster Hosts: hosts que o dispatcher cria conexões.
- Service Manager: contexto em que todos os serviços do cluster são executados.
J2EE Components (services):
Infraestrutura para executar aplicativos J2EE e SAP.
Três componentes:
- Interfaces: determina como os componentes trabalham em conjunto. Usadas pelos
serviços;
- Libraries: provê nomes, classes e objetos para o AS Java;
- Services: usa funções do JRE através da API:
- Security provider: administra usuários, grupos e autorizações;
- Monitoring service: informações do sistema (memória, performance, etc);
- Log Configurator Service: gerencia a configuração de log e trace;
- Deploy service: gerencia os deploys;
- EJB container service: gerencia os EJB;
- HTTP Provider: analisa a requisição HTTP, envia para o serviço específico e
retorna ao cliente.
Application Layer:
Terceiro nível dentro da arquitetura do AS Java.
A comunicação entre a camada de aplicação e os componentes J2EE é feita através da
API Java e de poucas APIs SAP. Tipos de aplicação:
- Servlets: programa Java que responde requisições para um web server;
- JSP: tecnologia para geração de HTML e XML de forma dinâmica. Através de
compilador específico, é transformado em applets, e permite a separação da lógica de
programação da apresentação.
- EJB: usado para desenvolvimento de aplicações Java;
- Java DataBase Connectivity (JDBC): conversação com o banco de dados.
Web Container: Servlets + JSP; EJB Container: EJB; Persistência: JDBC.

22
Load Balancing in the SAP Web AS Java Environment
Client Based Load Balance: cliente se conecta a um servidor, que devolve a
informação do servidor “oficial” a ser usado. O cliente então direciona a comunicação
para este servidor. Desvantagens: confusão devido muitas URLs, uso de favoritos,
necessidade de vários certificados de segurança (1 por servidor), abertura no firewall.
Stateless: um centralizador, que direciona comunicações para vários app servers, sem se
preocupar em manter uma sessão.
Stateful: um centralizador, que mantém o usuário sempre no mesmo app server, para
manter os dados da sessão do usuário.
O Java Web Dispacher se comunica apenas com o messager server, que informa quais os
servidores e portas dos dispatchers, bem como a carga de cada um. Pode ser usado para
Java, ABAP ou Java + ABAP.

Unit 2 – Starting and Stopping a SAP Web AS Java

Overview of the Process of Starting and Stopping a SAP Web AS
Java
Possível parar Java e não ABAP (via SMICM), mas não o contrário.
No caso de apenas Java, o startup é feito de forma comum (startsap ou MMC), porém o
comando é passado direto para o Startup and Control Framework.

Java Startup and Control Framework

Framework usado para iniciar, parar e monitorar as instâncias Java, exceto o Message
Service.
Processos:
- JControl
- Inicia, para e monitora processos da instância Java. SAP Signal Handling é
implementado com o JLaunch para encaminhar comandos de inicio e parada para a
instância;
- reinicia processos parados, para serviços suspensos, e manda sinal de shutdown
para instâncias;
- lê o instance profile;
- inicia o JLaunch;
- cria a shared memory para controle dos processos JLaunch;
- JLaunch
- recebe comando do JControl para parar nós como dispatchers e servers;
- para sozinho caso não detecte o JControl;
- inicia a JVM em um processo separado.
Startup: JControl é iniciado  JControl inicia o SAP Signal Handler e cria um canal de
comunicação com o Message Service  JControl inicia o processo de boot da instância
 o processo de boot cria arquivo instance.properties no SO  o processo lê a
definição da instância no banco de dados  JControl inicia o processo de boot dos nós
java, que sincroniza todos os binários  JControl inicia os nós, como os dispachers e
servers como processos JLaunch.
JCmon: monitora o JControl. Localizado em <instance_dir>/j2ee/os_lib e iniciado pelo
comando JCmon pf=<instance_profile>.

Starting under Microsoft Windows and UNIX

Windows: MMC. Quando parar java sem parar ABAP, acessar SMICM.

23
Unix:
Sistemas só com java: startsap JC<instance> (SCS) ou startsap J<instance> (dialog).
startsap J2EE inicia Java E ABAP.

Logs of the Start and Stop Processes of SAP Web AS Java

- dev_jcontrol: trace do JControl;
- dev_<node_name>: trace de processos JLaunch;
- jvm_<node_name>.out: trace da JVM.

Unit 3 – Installation in the SAP Web Application Server Java

Enviroment
Installing an SAP Web AS Java
Master guide: descreve os cenários do NetWeaver e links para guias de instalação dos
componentes.

Installation of SAP NetWeaver Developer Studio

NetWeaver Developer Workplace = Developer Studio + Web AS Java

Unit 4 – Basic Configuration of SAP Web AS Java

Administration and Configuration Tools for SAP Web AS Java
Config Tools:Usado para configurar o Web AS Java no banco.
- BD deve estar rodando
- Configuração da JVM;
- Configuração dos serviços e managers.
- Necessário reinício do AS após setup;
- não necessário user/senha;
- executado localmente;
- Chamado via configtool.bat, em /<instance_dir>/j2ee/configtool;
Visual Administrator: usado para administrar e configurar o AS Java.
- BD e Web AS devem estar rodando;
- Configuração de serviços e managers;
- configuração remota;
- parar e ativar serviços;
- parar uma instância java (se só java, quando java+ABAP, causa boot);
- parâmetros alterados em runtime;
- Chamado via go.bat, em /<instance_dir>/j2ee/admin;
- Porta 50004.
SAP Web AS Java Telnet:
- DB e AS devem estar rodando;
- Ativar e parar serviços;
- parar uma instância java (ABAP + Java = reiniciar).
- tool para emergências;
- overview das informações importantes;
- atividades simples de administração;
- telnet <servidor> 50008.

24
General Configuration of the SAP Web AS Java Cluster with Config
Tool
Só pode usar o config tool para alterar parâmetros se todas as instâncias Java estiverem
paradas.

General Configuration of the SAP Web AS Java Cluster with Visual

Administration
2 visões: global e cluster.

Other Administration Tools

System Information
Acessar via browser, na pág. Principal escolher “System Information”.
Mostra de forma geral a configuração do AS Java e informações de cada instância (host,
portas, banco, SO, service pack, etc.).
Telnet
Comando “man” lista help.
Principais:
- lsc: lista os clusters ativos;
- jump: trocar de nó;
- shutdown.

Selected Configurations
Instance: 1 dispatcher e no máximo 16 server process.
Config tool  selecionar nó ou instância  botão Add server p/ adicionar server
process.
Config tool é usado para alterar parâmetros do message server.
Template Configuration Tool: fornece modelos fornecidos pela SAP. Iniciado em
/usr/sap/<SID>/SYS/global/TemplateConfig.

Unit 5 – User Administration in Java Environment

Overview of User Administration in Java
Tipos de armazenamento de usuários:
- UME (User Management Engine): Default, serviço do Web AS Java, administração
central de usuários. Administra usuários no banco de dados, serviço de diretório ou
ABAP.
- UDDI (Universal Description Discovery and Integration): iniciativa para descrever
serviços e integrar negócios via internet.
- Banco de dados, hard code, utilizado na versão 6.20 e não recomendado.

User Management Engine (UME)

Características:
- console de administração, com facilidades de administração;
- cenários de auto-atendimento: workflow de autorização, alterar os próprios dados,
registrar-se como novo usuário, etc.
- políticas de segurança para usuário (tamanho da senha, etc.);
- logs de segurança.
A UME é apenas uma interface para guardar dados de usuários. Utiliza vários data
sources.

25
Interfaces:
- persistence manager: permite guardar dados em fontes diferente. Define qual dado
estará em qual data source;
- replication manager: gera um XML e manda para um sistema externo.
Tipos de particionamento:
- Attribute-based: um campo (telefone, nome, etc.) é guardado em uma origem, outro
campo em outra origem;
- User-based: um tipo de usuário em um (ex.: terceiros) e outro tipo de usuários em
outro;
- Type-based: ex.: usuários no sistema e roles no LDAP.
Particionamentos geram cenários, que possuem arquivos de configuração (XML)
específicos.
Durante a instalação podem ser ecolhidos 2 tipos de acessos: Java without ABAP: para
centralização via java ou outro app server ABAP; ou ABAP + Java, onde o java acessa o
repositório do ABAP.

User Administration Tools

Config Tool: apenas para alterar o data source.
UME Console: site http://server:5xx00/useradmin. Administra usuários, roles, grupos,
replicação manual e import/export de usuários, roles e grupos.
Visual Administrator: administração caso os usuários sejam gravados no banco.
ABAP User Management: caso integração ABAP x UME, permissões Java são
consedidas via UME Console ou Visual Administrator.

User Administration
Administrator: ABAP + Java.
J2EE_Admin: só Java.
Usuário possui profile (nome, email, etc.). Usuário pode ser atribuído a grupos. Roles
podem ser atribuídas a grupos e usuários.
Se o ABAP user management é usado como data source, usuários devem ser mantidos
na SU01.
O usuário de comunicação ABAP/Java é o SAPJSF, que contém a role
SAP_BC_JSF_COMMUNICATION_RO (recomendada). A role pode ser alterada para
SAP_BC_JSF_COMMUNICATION para ter direito de escrita.
A UME Console é sempre usada se a administração de usuários for no diretório ou
banco de dados.
Grupo de usuários é usado para atribuir roles para um grande número de usuários.
Se o data source é ABAP, roles ABAP são vistas como grupos.

The Java Authorization Concept

Dois tipos:
- J2EE security roles: administradas no Visual Administrator, parte do J2EE Standard, e
se refere a um objeto;
- UME roles: administradas via UME Console, uma extensão SAP que se refere à vários
objetos.
Na role UME:
- permissions: definidos no código, e provê controle de acesso;
- action: grupo de permissions especificadas em arquivo XML;
- roles: grupo de ações de um ou mais objetos.
SAP utiliza UME roles nas suas aplicações J2EE.

26
UME Parameters
SAP recomenda que se use o Config Tool em modo offline (AS parado) para administrar
os parâmetros (custer_Data  Server  cfg  Services  Propertysheet
com.sap.security.core.ume.service).
Proprieadades:
- Security Policy: tamanho de senha, expiração, tamanho de login, etc.;
- E-mail Notification: ao criar/remover/bloquear usuário, etc.
- outras propriedades: histórico de alteração de usuário, criação de password automático,
imagem apresentada no login.

Special Users and UME Log/Trace Files

Para alterar a senha do administrador, deve ser ajustado no secure store (Config Tool) e
no UME Console.
Existe um usuário “emergencial” (SAP*) que pode ser desbloqueado em casos de
necessidade. O desbloqueio é via Config Tool e todos os demais usuários ficam
bloqueados quando este está desbloqueado. Necessário reinicializar o Java cluster.
Duas formas de ver log/trace:
- via SO (security log (eventos de segurança) + trace files + log files (bibliotecas + UME
provider));
- via log viewer.

Unit 6 – Monitoring SAP Web AS Java

Java Monitoring: Overview
Junto ao CCMS, o monitoramento JAVA acumula dados, históricos e gera alertas.
Podem ser exibidos localmente ou em um monitoramento central, usando o agente
SPCCMSR.
Funções para monitorar AS Java:
- Monitoring Service;
- Logging usando o Log Viewer;
- Application Trace;
- Single Activity Trace;
- System Info;
- SAP Application Statistics
Monitoring Service
Consiste de monitores de status e de configuração.
Arquitetura baseada no padrão JMX.
Monitora memória, threads, serviços e managers, conexão com o BD, transações do BD
e sessões.
Visualizado no Monitoring Service do dispatcher e do Server, via Visual Administrator.
Logging
Todos eventos importantes são gravados em log.
Configuração via Log Configurator Service e exibido via Log Viewer.
Application Trace
Usado por desenvolvedores para Debug. Alguns marcadores mostram o tempo usado por
métodos.
Application Trace é integrado no Performance Tracing service no Visual Administrator.
Single Activity Trace (SAT)
Faz trace de requisições individuiais, que rodam em vários components.

27
Faz parte do Performance Tracing service no Visual Administrator e visto via Log
Viewer.
SAP Application Statistics
Se existem problemas de performance, cada usuário individual pode ser adicionado na
análise. Coleta tempo de resposta da aplicação, usuário que criou a requisição e a
quantidade de dados transferidos. Visualizado no Visual Administrator, no Performance
Tracing service.
SQL Trace
Trace de SQL pode ser ativado dinamicamente, e aponta o SQL, tempo, duração,
resultados e parâmetros utilizados.
System Info
Mostra o status dos dispatchers, servidores, service pack...

CCMS
Os dados coletados pelo JMX podem ser enviados ao CCMS do sistema central via
agente SAPCCMSR. Dados apresentados:
- Dados de monitoramento;
- Dados de disponibilidade;
- Dados estatísticos:
- ST03G: dados estatísticos relacionados à performance. AS Java usa distributed statistic
records (DSRs). Para ativar, registrar o agente SAPCCMSR e agendar o job
SAP_COLLETOR_FOR_NONE_R3_STAT.
- STATTRACE: trace de performance.
- Monitoramento de logs: monitora warnings, errors e fatal e dispara alertas. Resultados
exibidos na RZ20.
- Monitoramento do sistema operacional (coletados via SAPOSCOL e transferido via
agente);

Monitoring SAP Web AS Java

O monitoramento é basedo no Java Management Extension (JMX).
Através da API JMX é possível monitorar os recursos de todos componentes do servidor
e de aplicações usando MBean (Manageable Bean).
Tarefas da interface JMX e do Monitoring Service:
- Monitorar o status atual;
- Criar histórico;
- Usar mecanismo de alertas para reagir em situações críticas;
A infraestrutura JMX é provida pelo JMX Adapter Service.
Os dados são coletados dos monitores JMX (passivo) ou os recursos mandam dados
(ativo).
JMX usa configurações em arquivos XMLs, e a SAP provê templates para serem usados.
SAP recomenda monitoramento do Java via CCMS (ABAP) no PRD. Lá podem ser
cofigurados sistemas de notificação e de auto-reação.
Visual Administrator  Server  Services  Monitoring:
- Kernel;
- Performance
- Services
- System: propriedades do sistema.
- Applications: desenvolvedor utiliza funções no código, para monitoramento. Table
buffer é exibido aqui, por default.

28
Alertas em branco: apenas informação (não há medida de desempenho) ou está com erro
no monitor.
History: histórico de valores. Cálculo dos valores/horas é configurado no monitor-
configuration.xml. A freqüência de coleta de dados pode ser alterada em Configuration
 General (do monitor).
Configuration: configurar os valores de referência. General: freqüência e descrição.
Performance: valores de referência. States: apenas em monitores estáticos.

Important: cuidar dos monitores, que refletem informações de comunicação,

processamento de requisições, conexão com banco, etc.
Other Useful: utilizado para situações específicas;
Info monitors: utilizado mais pela equipe de desenvolvimento.

Appendix: Background Information About the Monitoring Service

Seqüência:
- Cliente manda HTTP para o dispatcher;
- HTTP Provider abre um server socket na porta HTTP do ServerSocketListeners;
- ServerSocketListener cria conexões entre o cliente e o dispacher. Default: 10
ServerSocketListner, para até 650 novas conexões por segundo. Se for maior que isso,
fica no HTTP socket queue até o keepalive timeout;
- após o ServerSocketListener, as requisições são direcionadas a thread do sistema, para
processamento. Caso não possa iniciar o processo, é armazenada em WaitingTaskQueue
do System Thread Pool do Thread Manager.
- Cluster Manager transfere para o server. Uma session communication é criada
diretamente entre o dispatcher e o server (requisições não provenientes de usuários são
tratadas pelo message Server quando pequenas, ou pelo Lazy connection quando
grandes).
- o server inicia uma system thread e passa a requisição para uma application thread (ou
aguarda na thread pool).

29
O System Thread Pool é responsável por atividades como backup e otimização em
background dos dados:
- ActiveThreadsCount: número de threads do Thread Pool que estão executando uma
requisição;
- CurrentThreadPoolSize: número de threads no Thread Pool;
- InitialThreadPoolSize: tamanho inicial do Thread Pool;
- MaximumThreadPoolSize: tamanho máximo do thread pool;
- MinimumThreadPoolSize: tamanho mínimo do thread pool;
- ThreadPoolIncrementStep: de quantas em quantas threads a Thread Pool crescerá;
- ThreadPoolPercentageUsage: uso da Thread Pool em %.
- WaitingTasksCount: número de requisições que estão aguardando uma thread livre na
Thread Pool;
- WaitingTasksQueueOverflow: número de threads que estão aguardando uma “vaga” na
request queue;
- WaitingTasksQueueSize: tamanho da request queue.
O Application Thread Pool é responsável por executar o código. Possui o mesmo
monitoramento que o System Thread Pool.
O Cluster Manager é responsável pela comunicação entre elementos do cluster, seja via
message server (poucos dados), seja via conexão direta (> lazy thresold parameter):
- MessageContextCommunication:
- TotalMSBytesReceived: quantidade de bytes recebidos por um serviço usando a
camada de comunicação do server;
- TotalMSBytesSent: quantidade de bytes enviados por um serviço usando a camada de
comunicação do server;
- AverageMSProcessTime: média de tempo em milisegundos em que uma mensagem é
processada no message server.
- LazyContextCommunication:
- CurrentLazyPoolSize: tamanho atual do message object pool na lazy communication
area;
- CurrentMSPoolSize: tamanho atual do message object pool na message server area;
- MaxLazyPoolSize: tamanho máximo do message object pool na lazy communication
área;
- MaxMSPoolSize: tamanho máximo da message object pool na message server area.
- SessionContextCommunication:
- CurrentSessionQueueSize: tamanho da message queue na session communication area;
- TotalSessionBytesReceived: número de bytes utilizados por um serviço no session
communication layer;
- TotalSessionBytesSent: número de bytes enviados por um serviço usando a session
communication layer;
- AverageSessionProcessTime: média de tempo em milisegundos de uma mensagem na
communication area;
- MaxSessionQueueSize: tamanho máximo da message queue na session communication
area.
O Services  Memory Service é usado para monitorar memória da JVM no cluster:
- AvaliableMemory: memória total que pode ser usado pela JVM (-Xmx);
- Allocated Memory: memória alocada;
- Used Memory: memória em uso (dentro da alocada).
Application  Table Buffers são usados para diminuir acessos ao banco de dados e
rede:
- BufferSize: tamanho máximo dos buffers de tabela;

30
- FreeSize: memória livre, em bytes;
- HitRate;
- Number of displacements: número de deslocamento do buffer desde start do BD.
Kernel  Configuration Manager permite que módulos J2EE acessem dados no BD.

Connecting to a Central Monitoring Service;

Durante a instalação o agente SAPCCMSR cria um segmento na shared memory
separado, onde os dados de monitoramento do AS Java são guardados. O agente manda
dados para o CMS via RFC a cada 60 segundos.
Para instalar e configurar o agente SAPCCMSR:
- criar o usuário CSMREG no CMS (RZ21);
- criar arquivo CSMCONF no CMS (RZ21);
- registrar o agente com o SAP NetWeaver CCMS Agent Setup Tool.
O arquivo CSMCONF é guardado no diretório do SAPCCMSR
(/usr/sap/ccms/<SID>/sapccmsr). Este arquivo contém informações do usuário
CSMREG e do administrador do ambiente.

RZ20: SAP J2EE Monitor Templates:

- Engines monitor: kernel, memória, serviços, performance...
- Applications monitor: dados de aplicações.
Para atualizar valores base de monitoramento:
- Criar uma entrada na JCo RFC Provider service via Visual Administrator;
- Criar uma coneão TCP/IP com o programa configurado (SM59);
- Ajustar entrada do agente na RZ21.
Após isto, a alteração pode ser feita dos dois lados.

Log Viewer and Log Configuration

O AS Java gera mais de 100 arquivos de logs, que podem ser acompanhados de duas
formas:
- via CCMS, caso esteja configurado;
- via monitoramento da infraestrutura do WEB AS Java (log viewer, etc.).
Todos os componentes java usam a mesma infraestrutura de log e trace, o que permite
visualização central dos logs (Log Viewer).
O log viewer é usado para ver arquivos de logs, independente de quem gerou (kernel,
services, etc.). Pode ser usado para pesquisa de índice de severidade nos logs.
Log viewer pode ser usado:
- como um integrado log viewer;
- como um central log viewer: visualização central de logs (de outros servers);
- log viewer via linha de comando.

Log Viewer Integrado

Log Viewer roda como serviço no AS Java, disponível via Visual Administrator.
Log Viewer é usado inicialmente para ler e para registrar arquivos de log. Cada
aplicação fornece o log-configuration.xml, que é registrado manualmente ou
automaticamente (diretório de logs ou via conexão de soquete).
O registro de logs pode ser feito de forma manual (Log Viewer Service  Runtime 
Add file) ou via log directory (importa do diretório tmp).

Central Log Viewer

31
Permite visualização de logs mesmo quando o AS Java não está ativo, e visualização de
logs ASCII, como do banco de dados.
Central log viewer = log viewer + servidor remoto. Conecta no Web AS Java via porta
P4 e no servidor remoto via porta RMI.
Scritps para o Log Viewer central estão dentro de admin/logviewer_standalone. Deve ser
executado o remoteserver.bat em cada AS a ser monitorado, e o logviewer.bat no que
exibirá o log. File  Connection to server para adicionar servidores a serem
monitorados. Necessário registrar os logs para exibição.

Command Line Log Viewer

- via Standalone log viewer (lv.bat);
- mostra apenas arquivos locais;
- pode ser ativado durante deploys;
- converte binários para formato legível.

Logs significam:
- eventos normais e excepcionais;
- informações de runtime de uma aplicação ou sistema;
- atividades durante operação normal;
- dividido em categorias: sistema, aplicação e performance que apontam para um ou
mais logs.
Trace significa:
- fluxo de processos de uma aplicação;
- usado no desenvolvimento e para detecção de erros em produção;
- todos os traces são guardados no trace default;
- são estruturados em locations, que representam códigos de áreas, como classes ou
packages.
Logging/trace infraestructure:
- SAP Logging API, Log Manager, Log Controller;
- é configurado usando o Log Configurator Service;
- é apresentado no Log Viewer.
O Log manager lê o arquivo de configuração e informa ao Log Controller qual nível
de log deve ser capturado. Este por sua vez cria o output dos dados de trace.
Os arquivos de logs são salvos em <j2ee>/cluster/<server ou cluster>/log.
Existem 7 níveis de log, sendo 3 para trace (ALL, DEBUG, PATH) e 4 para log (INFO,
WARNING, ERROR, FATAL).
O Log Configurator Service provê um ambiente para configuração de logs e traces.
Use o log configurator via visual administrator para:
- mudar o nível do trace;
- adicionar, mudar ou remover destinos de logs;
- adicionar, mudar ou remover formatos de log (diferentes de XML, como traces);
- adicionar, mudar ou remover controladores de log;
- arquivar arquivos de log.
Log Formaters cuidam do tipo de formato de log (XML, trace, etc.), log destination é
onde ficam guardados e log controllers são os objetos que podem escrever logs/traces.
A mudança do nível de log pode ser feita via controllers (principal) ou no destino do log.
Os logs são automaticamente (por default) arquivados em <j2ee>/cluster/<server ou
cluster>/log/archive. Não são apagados automaticamente.
O Log Configuration Tool é usado quando o AS não está disponível, e pode ser feito
download a partir do SDN.

32
Via Log Manager é possível configurar o destino do log, se vai ser junto com os outros
(padrão) ou separado.

Availability Monitoring
Ferramentas disponibilizadas para monitorar aplicações e o AS são baseadas no GRMG
(Generic Request and Message Generator).
GRMG é separado em duas partes:
- Infraestructure: parte da arquitetura de monitoramento do CCMS. Manda um XML
para a aplicação GRMG, recupera a resposta e encaminha-a para o CCMS;
- Application: interface JSP ou BSP para monitoramento de disponibilidade.
O monitoramento é conceituado como agente, sendo executado separadamente da
aplicação monitorada.
Cenários:
- customização técnica para monitoramento: aplicação já existente, onde será habilitado
o monitoramento;
- instrumentação da aplicação: criar na aplicação um monitoramento GRMG.
GRMG usa funções do CCMS para gerar o heartbeat (GRMG infrastructure manda
XML para GRMG application  GRMG application faz testes de disponibilidade e
manda de volta para o GRMG infrastructure  GRMG infrastructure manda resultado
para o Alert Monitor).
Para configurar monitor de disponibilidade:
- alterar o grmg-customizing.xml via Visual Administrator;
- upload do arquivo no CMS (automaticamente via SAPCCMSR ou manualmente via
transação GRMG);
- Iniciar cenários GRMG para monitoramento de disponibilidade.
Para criar um monitoramento GRMG na aplicação:
- Desenhar o cenário GRMG (aplicações, componentes, processos, etc.);
- Criar mensagens que serão retornadas;
- Criar um template do arquivo de customização;
- Implementar a aplicação.

Statistics and the Performance Trace

Performance data = Performance statistics (overview = JARM + DSR) + performance
trace (detalhes do fluxo de dados = Single Activity Trace (SAT) + Performance Trace +
Application Trace + SQL Trace + Logging API Trace).
Todos os traces de performance podem ser ativados juntos para monitorar uma sessão.
Normalmente visualisados via:
- DSR (área técnica) na ST03G (dados agregados para analise de performance) e
STATTRACE (dados crus, para análise de problemas);
- JARM (aplicação) no AS Java.
Java Application Response Time (JARM) coleta dados de tempo de resposta de
aplicações JAVA, que são disponibilizadas no Visual Administrator, serviço
Performance Trace (Server  Service  Performance Tracing).
Single Activity Trace (SAT) é usado para trace de ações de um usuário. Um trace é
gerado para cada componente, e são interligados via passaportes.
DSR coleta dados que são agrupados e enviados de hora em hora para o CCMS via
agentes (iniciado pelo job SAP_COLLECTOR_FOR_NONE_R3_STAT). Esses dados
agrupados são exibidos na ST03G.
ST03G possui funções para parametrização e guardar dados DSR:
- Exibir e deletar conteúdos de dados de performance;

33
- Reorganização (delete, etc.) de dados de performance (pelo job diário
SAP_REORG_NONE_R3_STAT_DB);
- Mostar logs de coletores;
- Configurar parâmentros do coletor DSR
- Configurar parâmetros de geração de estatísticas;
- Exibir logs de aplicação;
- Definir sistemas a serem monitorados.
Ativar o trace de performance quando quiser detalhes maiores da operação executada.
Para cada módulo, as informações de chamada de métodos e a sua duração são gravadas,
e exibidas na STATTRACE. Para isso:
- SAPCCMSR deve estar instalado;
- CMS deve ser >= 6.40
- DSR service deve estar ativo.
Para ativar o trace: Performance Tracing  Runtime Control  Trace Configuration.
Application trace é direcionado apenas para desenvolvedores, que podem ativá-lo sem
necessidade de boot do container, redeploy da aplicação ou colocar a VM em modo de
debug. Neste caso, a aplicação é iniciada em bytecode-modified mode, e quando
completado, volta para o normal mode.
SQL Trace provê informações como tempo, duração, resultado, input... e é utilizado por
desenvolvedores ou para análise de problemas de performance.
Pode ser ativado e desativado via WEB (/OpenSQLTrace e /SQLTrace) ou Visual
Administrator (Server  services  Log Configurator  enable/disable SQL Trace).
O peformance tracing pode ser ativado para uma sessão específica, em server 
Services  Performance Tracing  Runtime.

Unit 7 – Change Management and Software Logistics in the SAP

Web AS Java Environment
Overview of the Standard J2EE Development Process
Java é uma linguagem de programação orientada a objetos, similar a C ou C++. Toda
codificação é feita através de classes, e os status através de métodos. Possui bibliotecas
que facilita o trabalho com protocolos TCP/IP, como FTP, ou HTTP. Via RMI (Remote
Method Invocation) é possível acessar métodos em outros servidores.
A codificação (.java) é compilada em um formato independente de arquitetura, chamado
bytecode (.class), que é interpretado e executado por uma Virtual Machine.
JRE consiste de três elementos principais:
- Class Loader que carrega as classes necessárias para execução do programa;
- Bytecode Verifier que verificar se as classes são compatíveis com a VM;
- JVM.
Para execução de um programa, é necessário o JRE, que vem com a JVM, as interfaces
padrões (ex.: RMI) e outros componentes necessários para aplicações e applets.
J2SDK (software development kit) contém ferramentas para o desenvolvimento, como o
compilador e debug.
J2EE (enterprise edition) é um standard que permite desenvolvimento de aplicações
multi-camadas e distribuídas usando componentes.
A arquitetura do J2EE é dividido em 3 níveis:
- presentation tier: web browser, aplicativo Java, etc.
- middle tier: J2EE Server;
- back-end tier: banco de dados, ERP, etc.

34
Componentes são unidades completas e funcionais do software, que quando combinada
com outras classes formam uma aplicação J2EE. Componentes diferentes no J2EE:
- Applets: componentes de apresentação que rodam no cliente;
- Servlets e JSP: componentes de apresentação que rodam no servidor;
- Enterprise Java Beans: lógica de negócio que roda no servidor.
A comunicação entre o servidor Java e o cliente é via Web Standards, como HTTP,
HTML e XML (criados via JSP ou Servlets).
Container são objetos que proveem um runtime para outros objetos. Representam a
interface entre o componente e a funcionalidade J2EE que suporta aquele componente.
Antes de um componente poder ser usado, ele é juntando em uma aplicação J2EE
(assembly) e deployed em um container.
De acordo com o padrão J2EE, aplicação e apresentação são separadas durante o
desenvolvimento.
A configuração da aplicação é feita através do deployment descriptor (arquivo XML).
Após a criação da aplicação, o desenvolvedor faz o build, que é a combinação de EJB,
classes Java e o deployment descriptor (gerando um arquivo .jar). Também é gerado um
web archive (.war) que contém a camada de apresentação e classes dependentes.
O application assembler (administrador) reúne .jar + .war + outros enterprise archives +
outro deployment descriptor para gerar um EAR (enterprise archive). Esta etapa é
chamada de assembly. É feito um deployment deste EAR, que instala este arquivo em
um J2EE Server.

Introduction to the SAP NetWeaver Java Development

Infraestructure (JDI)
JDI transfere conceitos do ABAP para o Java, evitando sobreposição de arquivos em
desenvolvimento e trabalhos em equipe. O JDI é baseado em padrões J2EE ou WebDav
e DeltaV como repositório, para acesso e versionamento de objetos. O ambiente de
desenvolvimento local é baseado no Eclipse.
A ferramenta de desenvolvimento SAP NetWeaver Developer Studio é utilizada para
desenvolvimento de aplicações Java multi-camadas. A vantagem é a integração com as
ferramentas SAP, como o repositório central de objetos (DTR), processos de build
automático (CBS), associado ao Change Management e transportável.
Em comparação ao ABAP, no J2EE faz-se login no Development configuration do JDI,
que contém uma lista de componentes de software requeridos para análise, construção e
testes de um ou mais componentes no Developer Studio. As versões são baixadas na
máquina do desenvolvedor, que as altera e, após testes locais, envia novamente ao
servidor central. O servidor verifica novamente as versões (também de classes de
bibliotecas) e, caso a nova versão seja ativada com sucesso, o desenvolvimento pode ser
transportado.
O Developer Studio conversa com o JDI, que consiste de um ambiente local para
desenvolvimento (IDE) e serviços no servidor central, que provê um controle central do
desenvolvimento e suporte para o desenvolvimento de softwares (DTS, CBS e Name
Server do SLD).
Para evitar conflitos de nomes, o System Landscape Directory (SLD) provê um serviço
de reservas de nomes (Name Server).
O DTR (Design Time Repository) provê versionamento, distribuição entre times de
desenvolvimento e transporte e replicação dos sources.
O CBS (Component Build Sercice) via developer Studio, permite build central do source
code, em comunicação com o DTR. O CBS ainda conversa com o CMS para transporte.

35
CMS (Change Management System) é usado para configurar os landscapes de
desenvolvimento e o transporte das modificações. Ele faz um link entre os componentes,
criando uma unidade.
O landscape é dividido em 4 ambientes:
- DEV: usado por desenvolvedores para testes locais, sem interferência de alterações de
outros desenvolvedores;
- CONS: consolidar um determinado status do software;
- TEST: teste final;
- PROD.

Configuring the SAP NetWeaver Java Development Infraestructure

O WEB AS Java atua como runtime quando as aplicações sofrem deploy nele.
O JDI suporta desenvolvimento em 3 cenários:
- orientado a time: suporte para desenvolvimento de aplicações Java e J2EE, porém não
para Web Dynpro;
- componentes em uma track: usável apenas se um único componente for alterado, e a
administração e ambiente de build sejam usados;
- desenvolvimento em camadas: utilizado para desenvolvimento de múltiplos e
interdependentes componentes.
O cenário orientado a desenvolvimento em times é recomendado apenas para times
pequenos, onde administração centralizada não é utilizada. Usado apenas o estúdio e o
DTR. A compilação, assembly e deployment são feitos através do Studio. São criadas
versões diferentes do software no DTR, para cada nível (desenvolvimento, testes, etc.).
O cenário para desenvolvimento de componentes em uma track é recomendado para
grandes grupos de desenvolvimento, mas sem administração centralizada. Todos os
produtos do JDI são usados. A configuração do desenvolvimento representa o ponto
central do processo. Esta configuração define a visão dos desenvolvedores do landscape
JDI. O administrador usa o CMS para definir uma track, e o CMS automaticamente cria
os workspaces e buildspaces necessários, e adiciona a configuração de desenvolvimento
no SLD. Passos: instalar e configurar o DTR  criar o client definition para os studios
 (opcional) implementar processo de change management.
Como no primeiro cenário, os desenvolvedores têm o Developer Studio e um AS Java
instalados na estação de trabalho, e usa o DTR como origem do código fonte. Usando
componentes, os desenvolvedores podem quebrar o código em unidades menores e
reusáveis. O build central é feito pelo CBS, e o processo de change management roda
automaticamente.
Passos: instalar o SLD  instalar AS para CMS e DTR e outro (opcional) para CBS 
deployment do JDI no CBS, CMS e DTR  instalação do Developer Studio e AS Java
na estação de trabalho  instalação de outro AS Java para testes centralizados.
Após isto, o SDM (Software Deployment Manager) é usado para configurar o JDI:
configurar o JDI database  atribuir autorizações ao administrador  preparar o SLD
 configurar o CBS.
O SLD é um servidor cujos clientes comunicam via HTTP. Contém informações de
componentes e descrição do landscape (versões, patches e dependências dos
componentes). Quando o AS é instalado, ele é criado dentro de /SYS/global/sld, mas
deve ser configurado e ativado:
- Ativar o servidor SLD: via url HTTP://<sld-host>:<porta>/sld. O nome do object
Server deve ser especificado, seja via SAP Marketplace ou com o nome do próprio
servidor (que impossibilita o uso para reservas de nome no JDI);
- download e import do SAP Master Component Information e updates;

36
- Configurar o SLD data bridge: converte dados de entrada no formato CIM;
- Configurar o SLD data supplier: via ABAP são criadas RFCs, e via Java conexão
HTTP, em cada cliente;
- registrar o servidor SLD e o name service: no próprio AS do SLD e via DTR,
respectivamente;
- reservar namespace;
- registrar o name service no DTR.

Preparing for the Development of Java Applications

Criar usuários e funções:
- Desenvolvedores: trabalham no Developer Studio e no JDI. Requer acesso ao SLD e
todos componentes no JDI;
- Administrador: acesso a todos componentes do JDI não é requerido acesso ao SLD
para tarefas no CMS;
- CMS user: acesso full ao CMS, DTR e CBS. Acesso ao SLD é necessário para
configurar o JDI e operar o CMS. Não é atribuído a uma pessoa real.
Um development component (DC) é um container para uma série de objetos que fazem
parte do software. Componentes possuem interfaces para comunicação com outros
componentes, mas sua lógica interna é fechada em uma unidade.
Development object (DO) é um objeto (classe, JSP, tabela) que faz parte de um
componente e que pode ser alterado por si só. São guardados no repositório
Software componets agrupam DCs para delivery e deployment em unidades maiores.
Um produto consiste de um ou mais SCs, e representam um processo de negócio.
Produtos e SC são criados no SLD (home  Software Catalog).
Um CMS domain representa a parte do landscape que é administrado pelo CMS. O
domain name (3 caracteres) e o CMS name são criados e não podem mais ser alterados.
O development configuration define os SCs que serão desenvolvidos e controla os
acessos aos objetos no JDI.
Uma track contém todos development configurations e todos os ambientes de runtime
requeridos para desenvolver, testar, e produzir SC.
Os componentes SAP-JEE, SAP_BUILDT e SAP_JTECHS são requeridos para um
build central.
O plug-in DTR Administrator facilita a administração do DTR. Deve ser ativado no
Developer Studio do Administrador. Para isto, renomear arquivo plugin.xml.disabled.
Para conectar o Developer Studio no JDI:
- Ativar o Development Configuration Pool: Java Development Infraestructure 
Development Configuration Pool;
- Configurar o local do runtime environment (AS Java), em SAP J2EE Engine;
- Configurar o Proxy.
Development configurations são criados e guardados no CMS. O SLD contém
informação de onde (qual CMS) uma determinada configuração está.

Developing Java Objects in SAP NetWeaver Developer Studio

Development configurations são importados no Developer Studio, o que faz sincronizar
as fontes no DTR e arquivos no CBS  fontes são criados ou revisados  build local:
fontes e archives são carregadas e o build inicia  testes locais  sources são
atualizados no DTR  build central é iniciado pelo Studio  sources e archives
necessários são lidos do CBS, o build é realizado e a nova versão é ativada no DTR  o
deployment no sistema central é iniciado, usando software logistics  testes gerais 
após release, as mudanças estarão no import do CONS.

37
O elemento central do developer Studio é o J2EE Explorer, ou J2EE DC Explorer, o que
permite uma visão lógica do projeto e provê ponto de início para atividades de
desenvolviemento (de JSPs, etc.).
O DTR provê versionamento do código fonte no contexto do JDI, permite
desenvolvimentos em times, transporte e replicação dos códigos fontes.
O DTR é dividido em client (no developer Studio) e em Server (gerencia o
versionamento dos arquivos).
Arquivos alterados estarão sempre no workspace inativo no DTR. Para ativação, ocorre
o build central. Após a ativação, a aplicação sofre deploy no sistema central de
desenvolvimento da track usada.

Transporting Java Developments

Após o desenvolvimento, os desenvolvedores transferem as modificações para o CMS
do ambiente de desenvolvimento central.
DEV: desenvolvimento individual;
CONS: consolidar testes de versões que não estão em desenvolvimento.
TEST: teste final
PROD: produção.
Desenvolvedor transfere para o CBS  CBS reinterpreta e disponibiliza resultado em
forma de bibliotecas ou deployable archives  desenvolvedor transfere as mudanças
para o CMS  CMS empacota atividades em uma change request e coloca na import
queue da consolidação  administrador importa: integra releases no DTR da
consolidação e o CBS automaticamente compila os componentes alterados  CMS cria
uma nova versão da aplicação (assembly).
Ao contrário do desenvolvimento no ABAP, onde o transporte utiliza sempre a mesma
track (route), no Java uma track é usada apenas para um software component. Os
sistemas envolvidos não estão relacionados apenas no runtime e banco de dados, mas
nos workspaces do DTR e buildspace do CBS.
O transporte entre desenvolvimento e consolidação é feito através de transport requests,
porém a partir da consolidação, apenas componentes completos são transportados.
Durante o export no desenvolvimento, é criado um arquivo pra (Propagation Request
Archive), juntamente com um log. Como dev e cons usam o mesmo DTR, o arquivo pra
contém apenas informações, e não código fonte.
Após import, o CBS gera um arquivo SDA (Software Deploymet Archive), que é usado
para deploy.
Arquivos gerados no dir CMS:
- CMS/logs: logs do export e import
- CMS/archives: sca e pra files gerados no export
- CMS/CBS: sda files gerados pelo CBS para deployment.
Quando é liberado no sistema de consolidação, um processo de assembly é iniciado.
Nele, as change requests são coletadas e uma versão do componente é criada, contendo
todas as alterações das change requests. A versão do componente é disponibilizada no
system landscape. As change requests não são usadas para futuras migrações no
landscape.
Os componentes gerados, além de archives e sources (dependendo da track), contêm
informações sobre seus componentes e versões, mas não os componentes requeridos em
si. Este componente de software é importado no TEST, onde ocorre um assembly.
O desenvolvimento normalmente é feito em camadas, cada uma gerando sua track. Os
componentes normalmente são independentes entre as tracks.

38
O Software Deployment Manager (SDM) é um software usado para gerenciar e fazer
deploy de packages da SAP. A SAP disponibilisa SDAs e SCAs para serem importados.
O software é cliente (para import)/servidor (embutido no AS Java).
SDA: software deployment archive: aplicações SAP não ABAP. Contém um manifest,
arquivos (jar/war). Representa a menor unidade de patches que podem ser
disponibilizados.
SCA: software component archive: representação física do status de um componente.
Contém um número de SDAs, que prescreve um status de uma versão.
A manutenção de software é feita em 3 níveis:
- um produto: um ou mais SC que representam um processo de negócio;
- support package: disponibilizados para manutenção de um produto;
- patches: pequenas correções de erros.

Unit 8 – Importing Corrections

Installing Corrections for SAP Web AS Java
SAP provê extensões, correções e updates via Service Packages. SAP Notes com patches
são usados para pequenas correções.
Para o AS Java, os seguintes arquivos são requeridos:
- SAPINST<##>_<xx>.SAR: SAPInst;
- CTRL<DB><##>_<xx>.SAR: arquivos de controle do SAPInst;
- J2EERT<##>_<xx>.SAR: arquivos independentes de SO;
- J2EERTOS<##>_<xx>.SAR: arquivos dependentes de SO.
SPs para AS Java são importados via SAPInst. SPs para aplicações Java são importadas
via SAPInst ou via Software Deployment Manager (SDM).
Procedimento geral:
- leitura da documentação do SP (ou SP Stack) + SAP Notes;
- download no Service Marketplace;
- descompactação dos arquivos (irá gerar diretórios SAPINST-CD e J2EE-RUNT-CD);
- instalação na Central Instace;
- instalação nas dialog instances.
Para instalar um SP, entrar no diretório SAPINST-CD e iniciar o SAPInst. Primeiro ir
em “Apply Support Package <#>” e depois em “Apply Support Package <#> for Dialog
Instance”.

Installing Corrections for a Java Application

Lição usa JDI como exemplo.
Arquivos do JDI:
- SAPDEVINFF<##>_<xx>.SCA;
- SAPDEVINF<##>_<xx>.SCA;
- SAPBUILDT<##>_<xx>.SCA.
São feitos deploys dos arquivos via SDM. Para alguns, deve ser offline, outros online.

Offline
Parar o AS Java, e para iniciar em modo StandAlone para o deploy, em
/usr/SAP/<SID>/<central_instance>/SDM/program:
- sdm.sh jstartup mode=standalone;
- StartServer.sh
- RemoteGui.sh (inicia o SDM GUI).
Na guia Deploy, escolher ícone “Add SCA/DAS to Deployment List”.

39
Pressionar “Next” várias vezes e depois “Start”.
Após o deploy, reiniciar o SDM em modo íntegro:
- StopServer.sh;
- sdm.sh jstartup mode=integrated;
- iniciar o AS Java.
Online
Apenas iniciar o SDM e realizar o deploy.

Unit 9 – Backing Up SAP Web AS Java

Backing Up SAP Web AS Java
Primeiro backup após instalação e upgrade:
- file system backup: /usr/SAP/<SID>/<instance>;
- Backup do SDM;
- Backup do diretório home do banco de dados.
O SDM deve ser parado para backup. Backup do dir /usr/SAP/<SID>/<CI>/SDM.
O SDM contém a lista de todos os deployments instalados fora do banco de dados

Unit 10 – Technology Components for Browser-Based User

Dialogs
Internet Schenarios with SAP Systems
ITS é um software que age como gateway entre o web Server e o SAP. HTTP(s) e
HTML de um lado e DIAG, RFC, screens de outro.
Aplicativos desenvolvidos especialmente para ITS são chamados de Internet Application
Components (IAC), como o self service.
ITS ainda é requerido para SAP Gui for HTML e algumas aplicações.
Devido a novas tecnologias usadas no AS 6.10, a SAP criou o ICM para processar
HTTP diretamente da internet, e enviar a resposta de volta (sem web Server).
J2EE Standard não descreve uma comunicação baseada em browser, mas sim um
application Server completo.
Web Dynpro é um modelo de programação preferido para interfaces Web de aplicações
em sistemas SAP baseados no SAP Netweaver. Provê uma distinção entre interface e
lógica de negócios. Inclui funções como verificar inputs, help, suporte a multilinguagem,
etc.

SAP Internet Transaction Server (Standalone)

Um web Server é requerido. O ITS é dividido em AGate (application) e WGate (web).
Usuário manda requisição HTTP  Webserver identifica e direciona para o WGate 
WGate transfere para o AGate  AGate determina a função que deve ser executada  a
transação é executada  AGate transforma o output em HTML, usando templates 
Dados são mandados para o usuário através do WGate e do Web Server.
A configuração do WGate é feita no arquivo Registry.xml, diretório config (para
configurar o WGate e o IAC Object Receiver – IACOR). ITSRegistryWGATE.xml
contém informações como a lista de ITS, AGate servers usados, parametrização.
Necessário reinicializar o web Server após mudanças.
Outra opção é usar o WGate configuration tool:
- abrir ITSRegistryWGATE.xml e mudar ConfigMonitorEnabled para Yes;
- acessar url HTTP://<server>:<SID ITS port>/scripts/wgate/wgate-restart;

40
- configurar na URL HTTP://<server>:<SID ITS port>/scripts/wgate/wgate-config;
- retornar parâmetro para NO e reiniciar o WGate novamente.
O ITS Configuration Tool permite a configuração do AGate. Inicialmente o usuário
itsadmin é usado. Permite:
- Administração de usuários,
- Configuração dos parâmetros;
- Iniciar e parar o AGate e o IACOR;
- Verificar logs e traces;
- Monitorar performance e tuning.
Para desenvolvimento de objetos IAC:
- Web Application Builder for ITS Sercives: SE80;
- SAP@Web Studio (recomendado apenas para <= 4.6B).
Watchdog: executado como serviço no Windows, no servidor do Web Server, permite
monitoramento de todas instancias ITS via DCON, High-avaialability do WGate usando
o MS WLNB, registro do ITS no LDAP.
O monitoramento do ITS pode ser feito via CCMS, via agente SAPCCMSR.

Internet Communication Manager

Características:
- Suporte a HTTP(S), SMTP, SOAP, WebDav;
- Output em XML, HTML e XSLT;
- integração completa com o SAP
Funciona como Web Server e Web Client.
Junto com o Work Process, o Internet Communication Framework (ICF) prove o
ambiente para manipular requisições HTTP. ICF é a ponte entre o kernel do SAP e
aplicações criadas em ABAP.
O Work Process pode enviar uma resposta web via ICM. Para isto, as aplicações são
desenvolvidas em BSPs (SE80).
O ICM é um processo a parte (icman), baseado em threads, iniciado e monitorado pelo
dispatcher ABAP.

41
Componentes:
- Thread control: recebe a entrada TCP/IP e direciona ao thread pool;
- Worker Thread: manipula as requisições e respostas. Contem I/O handler para input e
output e plug-ins para cada protocolo (padrão: HTTP(S) e SMTP);
- Watchdog: work thread espera por uma resposta do usuário. Caso dê timeout, o
watchdog libera a thread para processar outra requisição;
- Signal Handler: processa sinais enviados pelo SO ou outro processo;
- Connection Info: informações sobre todas as conexões;
- Memory Pipes: permite transmissão de dados entre ICM e ABAP work process.
ISC: Internet Server cachê:
- hierarquia em 2 níveis: cachê em memória e disco;
- cachê dinâmico: cachê para BSPs e JSPs;
- active caching: aplicação tem controle para verificar se o cachê está atualizado;
- UFO cachê (UnFound) requisições inválidas são rejeitadas, evitando ataques;
- cachê dependente de browser: usa cachê apenas para um tipo de navegador
especificado no BSP.
ISC é configurado via parâmetros icm/HTTP/server_cache*
Parâmetro rdisp/start_icman determina qual instância terá o ICM.
Para detalhes e monitoramento: SMICM. Em Administration  ICM pode-se parar.
Colocando Restart  Yes/No indica se é para reiniciar (devido a erro) ou deixar parado
(manutenção).
SMICM:
- monitora e reinicializa o ICM;
- define o nivel de trace;
- exibe o trace;
- overview dos parâmetros;
- mostra estatísticas;
- monitora.

42
O programa icmon no SO exibe mais detalhes do ICM (icmon –h para help).

Internet Communication Framework

Permite a comunicação entre sistemas diferentes através de protocolos standard da
internet. Nenhuma biblioteca adicional é requerida, exceto para HTTPS (sapcryptolib).

O Task Handler recebe a requisição, executa alguns processos e responde a request.

Caso a requisição deva ser direcionada a um Work Process, o Task Handler inicia um
ICF controller. A partir daí, está no mundo ABAP.
Usuário manda requisição HTTP  ICM direciona para ABAP ou Java  ICM guarda
dados na memory pipe e avisa o ABAP dispatcher  ABAP coloca a requisição no
dispatcher queue, cria o contexto e seleciona um WP  o task handler lê os dados do
memory pipe e transfere para o ICF controller  ICF controller transfere para o ICF
Manager  usuário autenticado  a requisição HTTP é processada e o controle é
devolvido para o ICF controller  o task handler escreve o resultado na memory pipe e
sinaliza ao ICM que a resposta está pronta  ICM devolve a resposta.
O ICF é uma classe ABAP por trás da requisição HTTP. A SAP disponibiliza algumas
classes. Outras podem ser criadas no Class Builder (SE24).
Todos os serviços são exibidos e mantidos na transação SICF. Serviços ativos são
exibidos em preto, enquanto os inativos em cinza. Em azul os que são
ativados/desativados de acordo com o serviço pai.
A alteração das propriedades dos serviços é feita na forma de herança (mudou o pai, os
filhos também são mudados), exceto quando o filho é alterado manualmente.
O ICF cria links (ou alias) entre um serviço e outro.
O ICF Recorder permite a desenvolvedores ou administradores a identificar e corrigir
erros em solicitações HTTP. A request com problemas pode ser reexecutada várias vezes
usando a entrada no banco de dados.
Para acessar o ICF Recorder: SICF  Edit  Recorder  Activate
Recording/Deactivate Recording/Display recording, ou transação SICFRECORDER

43
para exibir o trace. Na hora de ativar o trace: determinar a URL, o tempo de duração e se
uma ou mais requests serão gravadas.
Até 6.20, o ITS era Standalone. A partir do 6.40, está imbutido no kernel (integrated).
Na 6.40, o ITS é acessado via processo ICM, implementado como serviço ICF e usa o
banco de dados como object store.
Restrições:
- o integrado não suporta o flow logic, WebRFC e WebReporting. Para isso necessário
ITS 6.20;
- um ITS standalone não pode sofrer upgrade para o integrated. Apenas via upgrade do
Web AS.
Para ativar o ITS integrated:
- ICM deve estar rodando;
- paramentro itsp/enable=1;
- o serviço ITS deve estar publicado no site interno;
- ITS service está ativo e o ICF e propriedade GUI Link=Y;
- serviço ICM /SAP/public/BC/its/mimes está ativado e ICF e propriedade GUI link= “ ”
(espaço).
Outros parâmetros iniciam com itsp/*. Especial atenção para:
- itsp/enable: ativa o ITS integrado;
- em/global_area_MB: shared memory para todos Work Processes + integrado ITS.
Além destes parâmetros, existem parâmetros de serviços, mantidos via SICF.
Um desenvolvedor pode criar um novo serviço via Web Application Builder for ITS
Service (SE80), e publicá-lo no site INTERNAL.
Para usar o SAP GUI for HTML, é necessário ainda:
- serviço system e webgui publicados no site INTERNAL;
- serviço ICF /SAP/BR/gui/SAP/its/webgui ativado, com o GUI Link=Y.
O monitoramento é feito via SM21, SM22, SMICM e SMICF, e os logs estão junto dos
logs dos Work Process (dev_w*.trc).

SAP Web Dispatcher

O Web Dispatcher é usado como centralizador de conexões e como load balance. Age
como um Web switch.
1) O Web Dispatcher identifica se a chamada é ABAP ou Java, e qual logon group a ser
usado;
2) O load balancing é feito no grupo.
É necessário um Web Dispatcher por sistema.
O controle sobre sessão statefull é feita via cookie (usa sempre o mesmo AS). Se é
stateless, é usado um logon group !DIAG ou !J2EE.
Para usá-lo, copiar o executável (sapwebdisp.exe) para um host, junto com o profile. A
configuração é feita basicamente em 3 parâmetros:
- icm/server_port_<X>: porta do Web Dispatcher;
- rdisp/mshost: host do message server;
- ms/http_port: porta do message Server.
Ativando em modo bootstrap (sapwebdisp –bootstrap):
- se não existir o profile sapwebdisp.pfl, ele é criado;
- se o arquivo de autorização icmauth.txt não existe, ele é criado e um usuário para
administração é criado;
- o Web Dispatcher é ativado com o profile criado.
Outra forma de ativar: sapwebdisp pf=<profile>. Para desativar, executar o kill.

44
Monitorado via ICMON. A SAP disponibiliza uma interface de administração e
monitoramento baseado em web.
As entradas no icmauth.txt podem ser alteradas via icmon –a.

45
TADM12_1
Unit 1 – mySAP ERP Solution Architecture
Introducing to mySAP ERP Solution
ERP desenvolvido para levar para web processos para comunicação com clientes e
fornecedores.
Combina o core do ERP com colaboração baseada no portal.
SAP Web AS componentes: SAP Kernel, SAP_BASIS, SAP_ABA e SAP_BW.
SAP ECC componentes: SAP_APPL e SAP_HR
5 -1 2 release and maintenance strategy: 5 anos de suporte (Mainstream maintenance), 1
ano de supporte extendido com acréscimo de 2% e mais 2 anos de suporte extendido
com acréscimo de 4%. Após isto, o cliente é responsável pelo suporte.
ICM - Internet Communication Manager: adicionado na versão Web AS 6.10, possibilita
a conversa via HTTP com web servers e via SMTP com mail servers.

New Features of SAP ERP Central Component and SAPinst

Linguagens:
- SAP suporta mais de 30 linguagens diferentes;
- Apenas linguagens com mesmo code page podem ser usadas juntas sem restrições;
- suporta múltiplas linguagens com sistemas MDMP (multi-display-multi-processing).
Unicode:
- define um tipo de caracter que engloba virtualmente todos os caracteres usados no
mundo;
- suportado desde o Web AS 6.10;
- aumenta consumo entre 30 e 35% de CPU, memória e rede; e de 36% (UTF8) ou 60%
a 70% (UTF-16) no banco de dados.
- o mesmo SAP GUI pode ser usado tanto em unicode quanto em não unicode.
MCOD (Multiple Components One Database)
- Não necessita de esforços adicionais, é integrado no processo de instalação.
- Sap recomenda utilizar apenas em mesmo contexto (DES com DES, etc.) e não
misturar OLTP com OLAP.

46
- Não é possível misturar produção com sistemas não produtivos.
- Cada componente possui um usuário para base de dados.
Directory Server
Atua como repositório central de usuários.
LDAP e CUA trabalham de forma independentes.
SAPInst: System Landscape Implementation Manager
Novidades:
- GUI independente do SAPInst: você pode desconecta-la clicando em logoff, sem
precisar cancelar a instalação;
- Possível voltar steps sem precisar cancelar a instalação;
- Erros não causam aborts;
- Poucos arquivos de log;
- SAPInst GUI permite monitorar toda a instalação e mostra todas as mensagens
apresentadas pelo SAPInst;
- Instalações canceladas podem ser continuadas;
- SAPInst GUI pode ser iniciado em outro computador;
- SAPInst GUI requer JDK e JRE.

Unit 2 – Planning the Installation of SAP Central Component

Planning the instalation
Sugestão de separação dos discos em RAID:
- Business Data e índices: RAID5;
- Logs e arquivos de configuração do banco de dados: RAID1;
RAID1  Dois discos espelhados. Caso um pare, o outro assume;
RAID5  Vários discos trabalhando como em RAID0, porém gravando dados de
paridade em todos eles. Caso um falhe, com informações de paridade e demais dados em
outros HDs é possível reconstruir o arquivo.

Unit 3 – Preparing for the Installation of SAP Central

Component
General Preparation for Instalation
- Order or download installation DVDs;
- Download install guide para SO e BD específicos;
- Download de todas as notas espeficicadas no install guide;
- Preparar os DVDs de instalação:
- Não usar espaços nos nomes dos diretórios;
- SAPInst precisa que todos os arquivos e diretórios estejam em maiúsculo.

Futher preparation for Installation on Windows

Pré-install
- Precisa ser NTFS;
- Utilizar um único domínio de rede;
- Usuário com privilégio de Administrador;
- Mapear (no arquivo hosts ou no DNS) o servidor SAPTRANSHOST apontando para o
servidor que possui o diretório de transporte;
Preparando a instalação
- Instalar JDK em todos os servers que rodarão o SAPInst;

47
- Renomear arquivos em <java_home>\jre\lib\ext, tirando extensão .jar. Voltar após
instalação;
- Criar variável de ambiente JAVA_HOME;
- Adicionar %JAVA_HOME\bin para a variável PATH

Futher preparation for Installation on Unix

- Criar FS ou RAW Device /usr/sap/<SID>, /usr/sap/trans e sapmnt/<SID>;
Preparando a instalação
- Instalar JDK em todos os servers que rodarão o SAPInst;
- Renomear arquivos em <java_home>\jre\lib\ext, tirando extensão .jar. Voltar após
instalação;
- Criar variável de ambiente JAVA_HOME;
- Criar variável DISPLAY apontando para o servidor que terá o GUI do SAPInst;
- Caso utilize UNICODE, adicionar /sapmnt/<SID>/profile para o path do sistema.

Unit 4 – Installing SAP GUI

Installation of SAP GUI for Windows
Três tipos de GUI:
- for windows;
- for java;
- for HTML
Instalar e aplicar patch.
Admsetup.exe para gerar SAP GUI Installation Server. Para aplicar patch no installation
Server, executar o SAPAdmin.exe.

Installation of SAP GUI for Java

Baixar do site da SAP a versão mais atual e consultar c:\program files\ SAPGUI for
Java\<version>\doc\manual.html para maiores detalhes de configuração.

Unit 5 – Installing the SAP ERP Central Component

Introducing SAPInst
Serviços que fazem parte do SAPInst:
- Controller: controla todo o processo;
- KeyDB: faz a persistência. Grava as ações completadas em XMLs;
- GUI Engine: cuida da exibição de telas, do input de dados (o KeyDB grava nos
arquivos XMLs), e valida input do usuário. Conversa com o SAPInst Java GUI,
cuidando da comunicação via TCP/IP;
- Message Lib: cria logs e traces durante a instalação;
- SysLib: interface de comunicação com o SO, para atividades específicas dele (ex.: criar
diretórios, etc.);
- Registry: permite carregar bibliotecas dinâmicas durante a execução.
Output files:
- sapinst.log: progresso da instalação (diretório de instalação);
- sapinst_dev.log: grava todas as mensagens de todos os passos, em detalhes (diretório
de instalação);
- instgui.log: mensagens referente ao GUI (máquina que possui o GUI).
XML files:

48
- dialog.xml: contém todas as telas usadas na instalação;
- keydb.xml: progresso da instalação e entrada dos usuários;
- messages.xml: mensagens usadas na instalação;
- control.xml: definição dos componentes utilizados no SAPInst;
- packages.xml: para administração dos pacotes a serem instalados;
SAPInst de forma remota:
- Servidores devem estar na mesma rede e aceitar o ping entre si;
- portas 21212 e 21213 devem estar liberadas;
- Para instalar, utilizar startinstgui.bat;

Installing and Patching Oracle Database Software

Iniciar instalação via sapserver.cmd;
Instalação sem criação de banco, com configurações típicas.
Para aplicar patches e interim patches, parar o banco.
OUI: Oracle Universal Instaler: para aplicar patches, apenas.
OPatch: para aplicar e remover interim patches.

Central Instance Installation

No windows, não utilizar portas 25, 43, 60, 72 ou 89 devido a problemas conhecidos em
serviços do windows (como terminal server).
Memória:

Database Instance Installation

Recomendação: redo log archive não deve estar nos mesmos discos que sapreorg,
sapbackup, sapdata<x>, etc.
Número de jobs paralelos de import: número de processadores do servidor.

Dialog Instance Installation

SAP Web AS Java Central Instance Installation

SAP Web Application Server Java = J2EE Engine = J2EE add-in.
Criar um novo client antes de instalar?!?!?!?!
SCS: SAP Central Services.
Central Services Instance: serviço que gerencia todo o cluster J2EE. Formado pelo
Message Service e Enqueue Service. Controla os dispachers e server processes e provê
infra-estrutura para troca de comunicação entre os nós. Provê informações de load
balance para o Web Dispacher. Gerencia lock lógico de dados e sincroniza dados pelo
cluster.
Usuários criados:
- SAPJSF: comunicação via RFC entre ABAP e Java;
- J2EE_ADMIN: administrador da instância java;
- J2EE_GEST: usuário anônimo.

SAP Web AS Java Dialog Instance Installation

Mesmo dialog instance do ABAP.

Appendix: SAP Gateway Installation

Instance number: se na mesma máquina que a CI, usar número diferente;
Memória: pode ser 128Mb.

49
Unit 6 – Performing Post-Installation Activities
Installation of SAP License and Other Components
Parando e voltando o SAP:
- Parar e iniciar o sap;
- Efetuar logon com user SAP* ou DDIC;
- Verificar logs em \usr\sap\<SID>\DVEBMGS<XX>\work;
- verificar transações SM50, SM51 e SM21;
Instalar licença (ver procedimento).
Instalar Documentação :
- Um CD por cada linguagem;
- PlainHtmlHttp requer web server;
- Usar diretórios diferentes para cada linguagem, com dois caracteres (EN para inglês,
etc.);
- Não pode ser via SAP* e DDIC, pois vai gerar change request.
Instalar SAPRouter
- Necessário para conversação entre o SAPNet e o R3, para utilização do EarlyWatch e
para consultoria remota;
- Aumenta segurança e simplifica a configuração da rede.

TMS and Basic Configuration

- Transação SE06;
- o TMS deve ser configurado após a instalação apenas em caso de cópia de um sistema
já existente. Quando é nova instalação, a configuração é feita ao se configurar o
transporte;
- Importar os profiles após instalação: eles são escritos no banco e após isto nos
arquivos;
- Acessar tranzação RZ10 e importar os profiles (utilities  import profiles  of active
servers);
- Number of dialog work processes = RAM/256 (min 2, max 18);
- Number of update work processes = RAM/768 (min 1, max 6);
- Number of update2 work processes = RAM/1024 (min 1, max 3);
- Number of batch work processes = RAM/1024 (min 2, max 3);
- Number of enqueue work processes = 1;
- Number of spool work processes = 1;
- Realizar configuração de operation modes, transação RZ04;
- Configurar usuários e funções na transação SU25;
- Configurar logon groups (transação SMLG);
- Instalar impressoras (SPAD);
- Configurar System Log na transação SM21.

Additional Tasks
- Verificar inconsistências via transação SICK:
- Verifica se a versão e o character set do kernel são as mesmas guardadas no
BD;
- Verificar se a estrutura de definições são iguais no Data Dictionary e no
Kernel.
- Ativar o SAP ERP Central Component Extension Set (SPRO);
- Instalar nova linguagem;
- Fazer backup do BD e FS;
50
- Verificar RFC SAPOSCOL_<hostname> (apenas se a instalação foi distribuída);
- Verificar se user SAPJSF foi criado, e está com a role
SAP_BC_JSF_COMMUNICATION_RO;
- Executar o Load Generation (SGEN): carrega programas, grupos de funções, classes...
Também gera BSPs.

Appendix: Specific Post-Installation Activities

- Windows: configurar usuários <SID>adm e SAPService<SID> para que o password
nunca expire;
- Verificar se o brtools está funcionando.

Unit 7 – Implementing Patches

Applying Patches
- Support Packages Stack: conjunto otimizado de support packages e patches;
- Possui toda documentação de o que contém como aplicar em determinados cenários,
em determinados componentes, etc.
- services.sap.com/patches, o wizard ajuda a escolher o que você precisa.
Atualização de Kernel:
- SAP System parado;
- no windows, serviços parados.
Aplicar no JAVA: via SAPInst.

Unit 8 – Converting Non-Unicode to Unicode

Procedure for Converting Non-Unicode to Unicode
Exportar a base;
Instalar nova base com Unicode;
Importar a base antiga.

Unit9 – Troubleshooting Installations Problems

Solving Problems During SAP ERP Central Component Installation
Verificar sapinst.log e procurar por mensagens de erro;
Verificar o erro em notas informadas na instalação, no SAPInst Troubleshooting Guide
(service.sap.com/sapinstfeedback) e no SAP Notes;
Se não for um erro conhecido, executar o comando que deu erro na linha de comando e
abrir um chamado na SAP, enviando keydb.xml e sapinst_dev.log via FTP.
Implementar a solução e continuar com a instalação.
Flow Trace provê mais informações sobre o progresso e sucesso da instalação.

Unit 10 – Introduction to Software Logistics

SAP System Landscape
Revisão dos produtos, componentes, landscape.

Client Concept
Revisão da definição de client.

51
System and Client Change Options
SE06 – System Change Option
Define se os objetos de customização e de repositório são alteráveis globalmente e, se
sim, se os componentes são.
SCC4 – Changes And Transports for client-especific objects:
- Changing without automatic records: permite alteração, porém a change request deve
ser feita manualmente
- Automatic record of change: alterações geram requests. Ex.: desenvolvimento;
- No changes Allowed: sem modificações. Ex.: QAS, PRD;
- Changes without automatic recording, no transports allowed: permite alterar, porém
não pode transportar. Ex.: Sandbox.
Client-independent object changes:
- Changes to repository and cross-client customizing allowed: tudo liberado,
adicionando em requests;
- No changes to cross-client customizing objects: sem customização, mas pode
desenvolver, adicionando em requests;
- No changes to repository objects: permite customização, adicionando em requests,
porém não pode desenvolver;
- No changes to repository and cross-client customizing objects: tudo bloqueado.
Current Settings: quando está tudo bloqueado, alguns valores podem ser alterados, por
ex.: taxa de cambio, etc.

Unit 11 – Setting Up an SAP System Landscape

Setting Up the Transport Management System (TMS)
Inicializar via SE06 e configurar o transporte via STMS.
Configurar variável DIR_TRANS apontando para o diretório de transporte.
Conceitos do TMS:
- Configuração centralizada do Change and Transport System (CTS) para todos os
sistemas SAP;
- Gerenciamento centralizado de change requests e processo de importação;
- estratégia de transporte baseada em rotas.
Transport domain: todos os sistemas que usam o mesmo TMS. Devem ter SIDs
diferentes e 1 deles é o domain controller.
Transport domain controller: sistema onde toda a configuração do TMS é mantida.
Alteram-se nele os parâmetros, que são direcionados às outras instâncias.
System landscape: conjunto de ambientes que utilizam as mesmas customizações e
change requests. Normalmente um landscape = domain, porém pode-se ter + de 1
landscape em 1 domain controler.
Um transport domain possui pelo menos um transport group, que é um ou mais sistemas
que compartilham o mesmo diretório.
Configurar o TMS:
- Configurar o domínio, que define quais sistemas estão inclusos no domínio;
- configurar as rotas, que define sistemas e clients;
- configurar o QAS com regras de aprovação (opcional).
Configurar o domínio:
- O primeiro sistema que é configurado é o domain controller (geralmente dev). Esta
configuração é obrigatória no client 000. Depois, essa responsabilidade pode ser passada
para outro ambiente (ex.: produção), por ser mais estável.
- Ao se configurar um domínio:

52
 - Um grupo de transporte é criado “GROUP_<SID>”;
- Usuário TMSADM é criado no client 000;
- RFCs são criadas para o TMS (TMSADM@<SID>.<DOMAINNAME> e
TMSSUP@<SID>.<DOMAINNAME>);
- Arquivo de configuração DOMAIN.CFG e arquivo de profile para o programa
tp TP_<DOMAIN>.PFL são criados no diretório /bin.
- Configura-se outro sistema, que pede permissão ao domain controller. Este deve
aprovar.
- Caso os sistemas ainda não estejam instalados, pode-se criar sistemas virtuais, que
futuramente virarão sistemas físicos;
- Recomendada a configuração de um backup domain controller, que irá funcionar caso
o domain controller oficial esteja desativado.
- A configuração do profile do programa tp deve ser feito via STMS, não via sistema
operacional.
Configurar rotas
- rotas definem a regra de cada sistema e o fluxo das change requests. Ela define o
system landscape;
- Para configurar, deve-se modelar as rotas, usando os modelos existentes ou configurar
manualmente. Após isto, distribuir e ativar as configurações nos outros sistemas.
- As configurações das rotas são versionadas, e as versões mais antigas podem ser
ativadas novamente.
- As rotas podem ser de consolidação (export/import) ou de delivery (importação
apenas);
- Customizações e objetos são direcionados a uma rota de consolidação através de um
transport layer. Os objetos são agrupados logicamente em pacotes, onde se define o
transport layer.
- Objetos originais usam o transport layer “SAP”. Os customizados a “Z<SID>”.
- DEV = integration system (origem das change requests);
- QAS = consolidation system (destino da rota de consolidação);
- PRD = delivery system (destino da rota de delivery).
- Para ativar a configuração, no domain controller clicar no botão de ativação, ou
“Configuration  Distribute and activate”.
Configuração do procedimento de aprovação no QA:
- Após liberação (release) de uma change request, no QAS terá uma lista de change
requests para serem importadas (import buffer), marcadas como inativas. Apenas após a
aprovação do responsável é que estará liberada para sistemas delivery.
Verificar se a configuração do TMS está ok:
- testar conexão RFC: STMS  SAP System  Check  Connection Test;
- testar diretório de transporte: STMS  SAP System  Check  Transport directory;
- testar programa tp: STMS  SAP System  Check  transport tool.

Extended Transport Control

Originalmente não é possível configurar duas rotas em cima do mesmo transporte layer.
Isto porque a package é apontada para um transport layer.
A solução para este problema é criar um target group, que contém um ou mais sistemas.
O TMS oferece o Extended Transport Control ( = CTC, client-dependent transport
control), que automatiza os processos por:
- cliente específico transport targets: transporte especifica <SID>.<client>;
- cliente específico rotas de consolidação: destino pode ser um client em um sistema ou
grupo de sistemas;

53
- cliente específico rotas de delivery.
Transporte entre diferentes grupos de transporte (sistemas em um grupo de
transporte usam mesmo diretório de transporte).
Limitações: logs e transportes apresentados no CTO só aparecem no sistema de origem
Transporte entre domínios de transporte diferentes
Pode se usar link entre dois domínios ou sistemas externos.
Domain link: conexão permanente via RFC, com funcionamento similar ao transporte
convencional. Os logs são apresentados no sistema de destino.
External system: utiliza-se outro diretório de transporte, comum aos dois domínios.

Unit 12 – Customizing and Development in ABAP

Customizing and Customizing Projects
Implementation Guide (IMG): guia para customização em todo ambiente SAP. Provê
documentação, e ferramentas para gerenciamento de projetos e documentação.
Os projetos podem ser alterados, sobrepondo o projeto anterior, mas mantendo a
documentação.
Os projetos são cross-client, e podem ser acessados via transação SPRO_ADMIN.
Centralização de projetos no Solution Manager permite:
- Administração e definição do projeto;
- Administração centralizada do landscape, o que permite aplicar modelos, centralizar
configurações e testes;
- Através do Business Process Repository, integrado ao SAP Knowledge Warehouse é
possível acelerar a documentação do blueprint;
- Permite controle central das modificações do projeto e customizações;
- Criação de planos de testes que refletem em testes seqüenciais e integrados;
Customizações afetam várias tabelas, que são vistas através de table view = tabela
virtual, que apresenta dados de várias tabelas.

Customizing Tools
Ferramentas para customizing:
- Implementation Guide (IMG): tool central para cuidar das customizações.
- Transport Organizer: guarda as alterações em forma de requests.
Transport Organizer é usado para criar, gerenciar, liberar e analizar requests. Acesso via
SE09.
Customizações alteram tabelas que são salvas em change requests do tipo customizing,
que pertencem somente ao usuário que as criou.
Tasks são unidades menores utilizadas pelos customizadores para guardar as mudanças.
Recomendado pela SAP: Gerente do projeto cria uma change request  os membros do
projeto são adicionados na change request, através de tasks  cada membro trabalha na
sua request.
Quando uma change request é salva, apenas as chaves da tabela são salvas. Quando
acontece o export, há a leitura das demais linhas.
Customizações podem ser logadas, o que é muito usado para documentação, através da
transação SCU3.
Caso a change request não seja associada a um projeto no início, é possível associar
posteriormente, via CTS (Change and transport system).
Quando se ativa funções de projeto CTS em um projeto IMG:
- pode-se associar change requests ao projeto;
- no overview da request pode se ver essa associação;

54
- quando se altera customizações no projeto IMG, elas são apenas associadas a requests
do projeto IMG.
A associação de projetos IMG à requests pode ser feita de 2 maneiras:
- Através da SPRO_ADMIN;
- Através da SE09, entrando em propriedades e associando o projeto IMG.

Customizing Procedure
Papéis:
- Project manager: cria as change requests e associa os customizadores a ela (criando
tasks). Após a customização estar ok, ele libera a change request.
- Customizer: faz a customização e libera sua task. Tem permissão para copiar as
modificações para o client de teste;
- TMS Administrador: transporta as change requests para demais ambientes.
Algumas transações são classificadas como transporte manual. Elas devem ser
manualmente adicionadas à change requests.
Antes de se fazer a release de uma change request, realizar testes unitários para testar a
funcionalidade da change request e verificar se o conteúdo dela é completo.
Criar um client para testes, que permite um teste unitário e testes sem risco de criar
dados dependentes de customização.
Transação SCC1 permite a copia de tasks, de change requests e de tasks + change
requests para outro client.
Ao copiar uma task para outro client, ela não deve ser liberada, para permitir
recustomização caso necessário.
Quando uma task é liberada, indica que a customização ou desenvolvimento foi
terminado, o teste unitário está ok e a documentação está completa.
Quando a change request é liberada, o conteúdo das tabelas é exportado para o SO e é
criada em uma entrada na fila de import no QAS.
É possível fazer o merge de change requests, através de utilities  reorganize  merge
requests.
Tipos de customização:
- Client-dependent;
- Client-independent;
- Repository objects.
É possível ver o tipo de customização (dependente/cross) em IMG  View 
Additional information  Technical data Client-dependence.
Tipos de customização cross client:
- objetos de customização, gerados pela demanda (objetos do repositório);
- customizações em opções do sistema, cujas tabelas não contêm o número do client.
Change requests:
- customizing: setups client dependentes;
- workbench: customização cross client e alterações em objetos do repositório.

Managing Workbench Change Requests

Áreas que devem ser documentadas para o gerenciamento de mudança:
- Restringir alterações a objetos do repositório:
- Criar 1 sistema para todo desenvolvimento;
- certificar-se que as opções de sistema e client estão corretas;
- colocar autorizações corretas aos usuários.
- Definir padrões de desenvolvimento: usar pakages, padrões de documentação e
manutenção de versões;

55
- definir times de projetos: treinar sobre os padrões e definir líderes.
Recomendações da SAP:
- desenvolvimento em um ambiente apenas;
- usar packages para agrupar funções relacionadas.
- após release da change request, documentar o propósito e o status das modificações.
- usar autorizações para controlar perfis.
Tools que ajudam na customização: IMG; e no desenvolvimento: ABAP Development
Workbench.
Características de customizing requests: Características de workbench requests:
- documentação das mudanças; - documentação de mudanças
- trabalho em equipe - trabalho em equipe
- histórico de mudanças - SAP Software Change Registration
- conectado ao Client Administration e ao (SSCR);
TMS - Packages
- Object lock
- controle de versão
- conectado ao TMS
O Transport organizer (SE09 ou SE10) pode ser usado para customizing e workbench
change requests:
- exibe as change requests;
- mostra informações globais sobre transport;
- provê acesso a tools especiais.

Prerequisites for development

Desenvolvedores precisam ser registrados no SSCR para poder criar, modificar ou
apagar objetos do repositório.
Registrar objetos (originais) a serem alterados (apenas 1x, até upgrade), recebendo um
número de licenças para alteração.
Customizações começam com Z ou Y, e o nome pode ter um domínio (direcionado a
uma package), registrado via view V_TRESN.
Alterações em ambiente não padrão de desenvolvimento são chamadas REPAIRS.
Objetos do repositório são organizados em packages, conhecidos como development
class:
- provê agrupamento lógico de objetos;
- define qual transport layer será usado;
- pode controlar nomenclatura de objetos.
- Z ou Y demonstra que pode ser transportado
- $ indica que tem objetos temporários, e não transportáveis;
- TEST objetos locais, porém ligado ao transport organizer, para prover lock e
versionamento.
Características das classes:
- Permite o agrupamento em hierarquias, garantindo a segurança;
- Permite interfaces com outras classes, desde que elas sejam visíveis;
- Definição de acesso de uso.
Tipos de change requests:
- Não-classificada: lista de objetos vazia
- transportáveis: contém um transport layer definido (tipo development/correction ou
repair);
- local: não contém transport layer definido ou é inválido (tipo development/correction
ou repair).

56
Repair: não permite modificações no QAS por desenvolvedores da primeira versão. É
necessário criar uma nova repair e associar o(s) desenvolvedor(es).

Handling Repairs and Modifications

Modificações devem ser feitas apenas no sistema original (sistema onde foi
desenvolvido). Quando copiado para outros sitemas, o objeto existe como uma cópia, e
alterações lá são ditas “repair”.
Objetos originais da SAP são cópias em todos os sistemas. Modificações são ditas
“modifications”. Para tal, utilizar IMG, Business Add-nos, transação CMOD e o ABAP
Workbench. Lista de objetos modificados: SE95.
Durante o upgrade, modificações podem gerar necessidade de ajustes.
Antes do upgrade, todas as modificações devem ser confirmadas e liberadas.
Durante o upgrade, transação SPDD é utilizada para alterações no repositório. Para
merge de outros objetos, utilizar SPAU.
Tipos de lock durante a modificação de objetos do repositório:
- Pelo programa editor, que permite que apenas um usuário utilize um objeto por vez;
- Pela workbench change request, que assegura a modificação de objetos em tasks
válidas, e apenas pelos desenvolvedores associados a ela.
Objetos podem ser manualmente inseridos em uma lista de objetos em uma task ou
request: SE09  Display  Request/task  Object list  lock objects.
Uma task liberada não pode mais ser alterada, porém outras tasks podem ser criadas na
mesma change request para alterar os mesmos objetos.
Quando uma change request é liberada, gera um controle de versionamento, que não é
migrado para outros ambientes.
Versionamento pode ser acessado por:
- Repository Browser (SE80);
- Transport organizer (SE09/SE10);
- transações de exibição e manutenção para todos os objetos do repositório.
Logs de transport:
- 0: sucesso;
- 4: warnings, porém transportou com sucesso;
- 8: warnings, e pelo menos um objeto não foi transportado;
- 12 ou maior: erro.
Transport Organize tools (SE03) provê:
- mostrar o erro de transporte ao logar no ambiente;
- provê sistema de verificação de objetos antes de ser exportado ao SO.
Autorizações/ Roles compostas:
- super usuário (ex.: administrador): S_CTS_ALL/S_A.SYSTEM;
- líder de projeto: S_CTS_PROJEC/S_A.CUSTOMIZ;
- desenvolvedor: S_CTS_DEVELO/S_A.DEVELOP;
- usuário final: S_CTS_SHOW/S_A.SHOW.

Unit 13 – Transport Management in ABAP

The Transport Process
O TMS pode ser usado para importar toda a fila de change requests exportadas no
desenvolvimento. Isto evita que ocorram erros de falta de objetos ao importar uma
request (cuja dependente não foi importada) ou que objetos antigos sobreponham os
novos.

57
As requests são exportadas para o diretório data e o arquivo de controle no diretório
cofiles.
No diretório buffer, existe o import buffer file para cada sistema no grupo de transporte
(requests e ordem de importação = ordem de release das requests).
Exporta do DEV  importa no QAS  fica inativa na PRD  testa e aprova no QAS
 fica ativa na fila da PRD.

Imports Using TMS

Import queues (ABAP) = import buffer (SO)  todas as change requests na ordem que
foram liberadas. Podem ser visualisadas/importadas de qualquer sistema do domínio.
Para ver a lista de import: STMS Overview  Imports.
Dados da fila são lidos do SO e jogados no banco, pela primeira vez. Para atualizar:
- Edit  refresh;
- Overview  Imports  Extras  Update all Import Queues;
- Relatório RSTMSCOL (SAP recomenda agendar para rodar de hora em hora).
Colocando um end mark (import queue) ou um stopmark (import buffer), significa que
no import all apenas as requests até ali serão importadas.
- Stopmark: Overview  imports  <system>  Queue  Close ou tp setstopmark;
- Remove stopmark: Overview  imports  <system>  Queue  Open ou tp
delstopmark;
- Mover: via TMS ou tp mvstopmark.
Import queue pode ser usada para:
- Ver o status das requests;
- Acessar lista de objetos, documentação e logs de transporte;
- Abrir e fechar a queue, e mover a end mark;
- Importar todas requests, um projeto inteiro, requests preliminares (apenas uma request)
ou de acordo com seleção de filtro;
- Adicionar, remover e passar adiante (outro sistema fora do domínio) requests.
SAP recomenda um deadline para release de requests: após este horário, as requests são
importadas, setando um end mark, e as seguintes serão importadas apenas no outro
horário.
Para copiar uma request em um sistema fora do domínio (forward): Request  Forward
 System.
Cuidado ao apagar requests para não gerar inconsistência de objetos. Melhor corrigir os
objetos e gerar nova request.
Import all: STMS  Overview  imports  Queue  Start Import. Importa todas
requests na ordem que apareceram no buffer/queue.
Asynchronously: import em background, sessão não fica presa no import.
Se uma request de um projeto não for aprovada no QAS, o projeto não pode ser
importado na PRD. Apenas as requests aprovadas.
Pode-se desabilitar o import all utilizando o parâmetro NO_IMPORT_ALL.
Antes de importar, SAP recomenda usar o end mark.
Para evitar problemas quando se importa uma única request, esta fica na fila e pode ser
importada novamente quando a import queue é processada.
TMS verifica se uma request é dependente de outras.
Dependendo do tipo de importação (simples, all, workflow, etc.), algums opções são
apresentadas:
- immediate;
- at start time;

58
- after event: selecionando “execute import periodically”, será processado sempre após
um evento, caso contrário só na primeira vez do evento.
SAP recomenda uso do import all em períodos determinados. Importação freqüente não
é recomendada.
Inclusos no transporte:
- versões de change requests;
- import no mesmo sistema usando SCC1;
- import em sistemas seguintes (QAS  PRD).
Tipos de estratégias de transporte:
- Queue-controlled mass transports: recomendado quando se tem muitos transportes e se
quer automatizar;
- transportes simples: recomendado para transportes controlados (ex.: produção).
- workflow: para comunicação entre desenvolvedores e administradores do TMS.
Para selecionar estratégia: abrir rotas de transporte no STMS e efetuar um duplo clique
no sistema.
Mass transports: marcando “leave transport request in queue for later import” permite
que importações simples sejam novamente importadas em import all.
Utilizar “transport of copies” quando copiar objetos para outros sistemas, mantendo a
versão do sistema de origem.
Utilizar “relocations of objects w/o package change” para mover a localização original
para outro sistema (ex.: de desenvolvimento temporário  DEV).
Utilizar “Relocations of objects with package change” copia os objetos movendo a
origem para o sistema de destino, criando sistema de transporte.
Utilizar “relocations of complete package” caso todo o package deverá ser mudado de
origem.

QA Approval Procedure and Transport Proposal

Para ser QAS:
- Deve ser destino de uma rota de consolidação;
- Deve ser origem de uma rota de delivery.
Enquanto todos os steps de aprovação não forem aprovados ou rejeitados, os já
escolhidos podem ter sua posição mudada. Ex.: de recusado para aprovado.
SAP recomenda não rejeitar requests. Recomenda desenvolver outra que corrija e migrar
as duas.
Goto  QA History indica todas as requests para um período que não é apresentado no
QA Worklist. Padrão até 30 dias.
Para ver quem aprovou/recusou: Request  Display  QA Status.
Para usar o Workflow, SAP recomenda que o sistema que esteja com o Workflow
Engine tenha alta disponibilidade, mas baixa carga = QAS.
Escolher “Special Transport Workflow” caso o transport seja urgente ou não siga a rota
padrão: Utilities  Create transport proposal.
Se aprovado  importa automaticamente e vai um e-mail pra quem solicitou. Se não,
vai e-mail informando a recusa, que pode ser rebatido ou cancelado.

Monitoring Tools
Tools para monitoramento:
- Import Monitor;
- tp system log
- Import queue consistency check;
- Transport control program check;

59
- Transport directory check;
- RCF connection test.

STMS  Overview  Imports:

- tp status: goto  Import Monitor;
- tp system log:
- SLOG: Goto  TP system log;
- ALOG: Goto  History  Import History.
- Import queue verificação de consistência: verifica se data files e control program da
import queue estão no import buffer: Import queue  Check  Consistency.

STMS  Overview  Systems:

- verificar o tp: SAP System  Check  Transport tool;
- verificar o diretório de transporte: SAP System  Check  Transport Directory;
- verificar conexões RFC: SAP System  Check  Connection test.

Existem dois momentos de se fazer a verificação por objetos críticos (somente do tipo
R3TR):
- Antes do import da change request no destino (manualmente: STMS  overview 
imports  Import Queue  Check  Critical objects);
- Durante o export: automático se parâmetro CHK_CRIOBJ_AT_EXPORT for W
(warning) ou E (error).
Para manter lista de objetos críticos: STMS  Overview  Imports  Extras 
Critical transport objects.
SAP recomenda o congelamento de desenvolvimentos durante testes:
- Liberar change requests com customizações;
- Congelar o desenvolvimento no DEV;
- Importar e verificar no QAS ;
- “Assinar” as alterações no QAS.
- Se necessário, liberar para outras customizações no DEV.
Para isso:
- parar as exportações: criar arquivo em <dir_trans>/bin/T_OFF.<SID> (primeira linha
do arquivo uma mensagem);
- parar as importações: criar arquivo em <dir_trans>/bin/NOIMPORT.<SID>.

Transport Directory Structure and Files

Devido o tp rodar em vários SOs, a nomenclatura é restrita: <DEV>K9<5 caracteres>.
Subdiretórios do DIR_TRANS:
- actlog: <DEV>Z<6 digitos>: grava ações na request (criação, modificação, release);
- sapnames: <USER>: registro de ações de usuários;
- buffer: <SID>: import buffer;
- data: R9<5 digitos>.<SID>: objetos exportados;
- cofiles: K9<5 digitos>.<SID>: passos para import;
- log: ULOGs, ALOGs, SLOGs, <Source SID><action>9<5 digitos>.<action SID> (step
executado) e <action><date>.<action SID> (steps coletivos).

tp, The Transport Protocol Program

tp é usado para controlar transports (export e import) entre sistemas, bem como fazer
upgrade de releases.

60
tp é um programa que roda no SO, baseado em C, comandos SO e ABAP no sistema
SAP.
tp utiliza o R3trans para efetuar comunicação com o banco de dados.
Não há mecanismos de import no target imediatamente após o export.
Executar o tp via SO (diretório DIR_TRANS/bin com o <SID>adm) deve ser somente
em casos especiais, como indisponibilidade do TMS.
Para importar:
- tp import all <SID> <CLIENT> pf=TP_<DOMAINNAME>.PFL;
- tp import <REQUEST> <SID> <CLIENT> u0 pf=TP_<DOMAINNAME>.PFL;
Uso do modo “uncondicional” para controle de erro. u0 significa que um transport
individual não vai sobrepor objetos mais novos, mantendo ele na fila de imports:
- 0: requests importadas não são removidas do buffer;
- 1: ignorar já importadas;
- 2: sobrepor original;
- 6: sobrepor objetos em repairs não confirmados;
- 8: ignorar restrições baseadas em tabela de restrições;
- 9: ignorar que o sistema está lockado para esse tipo de transporte.
Outros comandos:
- tp showbuffer <SID>: buffer daquele SID;
- tp addtobuffer <REQUEST> <SID>: adiciona request como última da fila;
- tp delfrombuffer <REQUEST> <SID>: remove request do buffer;
- tp cleambuffer <SID>: remove requests importadas com sucesso do buffer (intrinceco
no inport all). Via STMS: Overview  Imports  Import Queue  Display  Extras
 Delete Imported Requests.
- tp setstopmark <SID>: cria a stopmark no final do buffer;
- tp movestopmark <REQUEST> <SID>: marca a request como última da fila;
- tp delstopmark <SID>: remove a stopmark.

Import Process
R3trans é chamado eventualmente pelo tp e programa de controle de upgrade.
A execução do R3trans não é suportada, mas pode ser usada em determinados casos,
com pós-atividades necessários. No transporte, utilizar sempre via tp, que chamará o
R3trans quando preciso e garantirá todas as atividades completas.
Pode exportar em versão velha de R3trans e importar em novo.
Pode exportar de um SO e importar em outro SO diferente.
Pode exportar de um DB e importar em outro DB diferente.
SAP não garante transporte entre releases diferentes de SAP.
tp import all: tp setstopmark  importa  tp delstopmark  tp cleanbuffer.
Caso haja algum erro no import, após corrigi-lo, o tp recomeça de onde parou.
Para cada passo do import: tp passa informações do buffer para o R3trans  R3trans lê
os data files e conecta no banco de dados, processando inserts e updates  R3trans gera
log no dir tmp e devolve um exit code para o tp  tp move logs para dir log.
tp chama job RDDIMPDP, comunicando via table TRBAT. tp escreve uma linha
(header) para dizer ao RDDIMPDP que deve começar o processamento. Dependendo do
tipo de atividade, apenas o header é escrito.
RDDIMPDP lê a tabela TRBAT e seta a linha do header como “R” (run), inicia
programa RDD* (que gera uma entrada na TRJOB) e se auto-agenda.
Quando o header da TRBAT é “F” e a TRJOB está vazia, tp copia os logs dos steps
concluídos do dir tmp para o dir log e remove entradas na TRBAT.

61
Se o tp detecta problemas nas tabelas TRBAT e TRJOB, inicia um sapevt para
reprocessar o RDDIMPDP, que reconhece as entradas nas tabelas e reinicia de onde
parou.
Após a cópia de um client, o RDDIMPDP é agendado. Para verificar, SM37. Para
agendar, o nome do dispatcher é RDDIMPDP_CLIENT_<###>. O evento é o
SAP_TRIGGER_RDDIMPDP_CLIENT.
O tp import all não necessariamente inicia uma request apenas quando terminou todos os
steps da anterior.
Steps de import:
- DDIC I: ABAP dictionary import: de forma inativa, pelo R3trasns
- ACTIV: ABAP dictionary activation: pelo RDDMASGL
- ACTIV: ABAP dictionary distribution: ações para trazer o objeto ativado para o
sistema em execução, pelo RDDGENBB;
- Structure conversion: alterações em tabelas: RDDGENBB;
- ACTIV: Move nametabs: objetos de runtime são colocados no ambiente ativo, pelo
pgmvntab;
- MAIN I: Main import: todos dados importados, pelo R3trans;
- MCACT: ativação e conversão de enqueue objects: objetos não ativados antes são
ativados e colocados em execução, pelo RDDGENBB;
- ADO I: application-defined objects import: importação dos ADOs, como formulários,
estilos, formatos de impressão, pelo RDDIC1L;
- VERSF: versionamento, se vers_at_impotrt está ativado, pelo RDDVERSL;
- XPRA: execução de atividades definidas pelo usuário (ex.: reports), pelo RDDEXECL;
- GENERA: geração de programas ABAP e telas, pelo RDDIC03L.

Troubleshooting transports
Durante o import é usado o dir tmp, depois é movido para log.
Os arquivos de log possuem nome <source SID><action><6 digitos>.<target SID>.
Níveis de detalhes dos logs, visualizados no SAP:
- ações e códigos de retorno;
- mensagens de erro adicionais;
- logs de usuário;
- detalhes para desenvolvedores e hot-line.
ULOG: cada linha representa um comando livre de erro;
SLOG: monitora as atividades de transporte de um sistema;
ALOG: todos os códigos de retorno de steps num mesmo diretório de transporte.
Códigos de retorno:
- 0 a 16: valor máximo todos códigos de retorno da ferramenta de transporte;
- 17 a 99: calculado dos códigos de retorno das ferramentas de transporte e tp warnings;
- 100 a 199: indica warnings. Até 149 são “normais”, após isto indica operação incorreta
pelo usuário;
- 200 ou mais: erro.
Para verificar erro:
1 – STMS  Monitor  Alert viewer;
2 – Informações mais detalhadas no SLOG;
3 – ALOG apresenta steps cujos códigos de retorno estão no SLOG;
4 – Verificar se o job RDDIMPDP está agendado e se é iniciado por eventos.
5 – Comparar coteúdo das tabelas TRBAT e TRJOB com o import buffer (SM31).

62
Cleaning Up the Transport Directory
Comandos
- tp check all: procura por requests que não estão marcadas para import;
- tp clearold all: usa o comando acima para ver requests que passaram da idade máxima.
Parâmetros de idade máxima: datalifetime (move para dir olddata), olddatalifetime
(apaga do dir olddata), cofilefiletime (apaga do dir cofiles), loglifetime (apaga do dir
log).

Unit 14 – Client tools

Client Copy and Transport Tools
Client Copy tools copia esses tipo de dados:
- User máster data: só apaga dados no destino se um profile com user máster data é
copiado;
- customizing: todos profiles exceto SAP_USER. Tabelas classe C, G, E e S.
- Cross-client customizing: para outro sistema;
- máster/transacion (application) data: dados de aplicação. Tabelas classe A.
Testes a serem feitos antes de liberar uma request:
- testar funcionalidade;
- verificar se o conteúdo é completo.
Manter cliente separado para testes permite:
- teste unitário verdadeiro;
- teste sem risco de criar dados que dependam de customização;
SCC1 permite copiar (a partir do destino):
- uma task;
- uma change request;
- uma change request com suas tasks.
Somente uma change request pode ser copiada por vez. As change requests podem ser
agrupadas em outra, para migrar tudo de uma vez.
Local client copy: no mesmo sistema:
- SCC4 para criar novo client;
- Setar login/no_automatic_user_sapstar=0 e logar no destino com SAP*/pass;
- entrar na SCCL e importar dados;
- setar login/no_automatic_user_sapstar=1.
Acessando edit  Expert settings pode-se tirar tabelas da cópia.
Remote client copy: para outro sistema (SCC9):
- Não precisa de espaço em disco, vai via RFC;
- cross-client customizing objects podem ser migrados juntos;
- tabelas devem ser iguais nos dois ambientes.
Podem ser usados com vários processos paralelos, acelerando o processo: goto 
Parallel processes ou definindo grupos de RFC na SM59  RFC  RFC Groups.
Um processo paralelo monitora se o outro está rodando. Caso negativo o reinicia.
Client transport: não usa RFC, mas gera arquivo no dir de transporte, via SCC8.
Arquivos gerados:
- RO<number>: cross client data;
- RT<number>: dados específicos de client;
- RX<number>: SAPsripts.
Não é importada via import all, mas pode ser importada via TMS. Após: SCC7 para pós-
atividades.
Para apagar um cliente: SCC5.

63
Atentar para:
- não efetuar logon no client de destino enquanto importa os dados;
- max online runtime (rdisp/max_wprun_time) deve ser grande o suficiente.
Recomendado > 2000segs;
- executar um teste de cópia antes, para ver se tem espaço no banco.
Para monitoramento: SCC3:
- estatísticas de tabelas;
- controle de informação;
- informações sobre cada tabela copiada.
Verificar não só o log da cópia, mas também do sistema (RFC com problema, etc.).
Re-execução recomeça de onde parou.

Client Compare and Maintenance Tools

A função de compare (SCU0) serve para ver diferenças de tabelas ou views entre clients
diferentes, usando RFC.
Usos:
- comparar client com o client de referencia (000, por exemplo);
- comparar clients durante um cenário de rollout.
- comparar customizações cross-client antes de combinar clients (roll in).
No compare, pode-se usar uma visão orientada a projeto, via IMG.
A informação mais importante é o status (comparision status) que indica a existência e a
natureza das diferenças. Process status indica os que já foram comparados ou não.
Apenas um objeto pode ser alterado por vez, e aqueles que são alterados via SM30. Os
demais apenas comparados.
Via SCC4, configura-se o nível de proteção do cliente:
- Protection level 1: no overwriting: não pode ser sobreposto, mas pode sofrer compare.
- Protection level 1: no overwriting and no external availability: não sobrepõe e não
aparece em compare (PRD).

Unit 15 – Note Assistant, SAP Support Packages and Upgrades

SAP Note Assistant
Notas podem fornecer informações sobre produtos, parceiros e clientes da SAP, bem
como correções.
A nota inclui:
- sintomas do erro;
- causa do erro;
- descrição de como corrigir o código;
- a versão e support package necessários;
- links para support packages que resolvem o problema.
SNOTE:
- implementa automaticamente notas que modificam códigos ABAP;
- cuida da dependência com outras notas, support packages e modificações;
- mostra todas as notas implementadas no sistema;
- corrige apenas um bug, sem alterar ABAP Dictionay Objects, e não substitui SP.
Pode-se aplicar uma nota diretamente via conexão com o SAP Net r/3 Frontend ou faz-
se o download da nova e aplica-se separadamente.
Alterações no código original não requerem chave SSRC.
Aplicar na DEV  transportar para o QAS via TMS, não aplicar diretamente no QAS
 importar na PRD.

64
Acessando a SNOTE, é apresentada a worklist pessoal, diferente do Note Browser.
Note Browser é um overview de todas as notas existentes no sistema.
Note Assistant provê:
- Exibição de informações de notas direcionadas para seu usuário, notas inconsistentes
(todas) e notas novas;
- Pesquisa por notas;
- Download de notas;
- Verificação de notas para verificar seu status;
- definir o status de aplicação da nota.
Notas podem ser implementadas/removidas (Cancel SAP Note Implementation).
Para baixar direto via Note Assistant, é necessária conexão direta com a SAPNet.
Pode-se classificar a nota, bem como direcionar a aplicação para outra pessoa.
Para aplicar, selecionar “Implement SAP Note”. Será solicitado que salve as alterações
em uma change request. Antes de importar, execute uma syntax check.
Um log é gerado após a aplicação da nota.
Caso seja necessário aplicar outras notas antes da escolhida, e havendo conexão direta
com o SAPNet, serão apresentadas as outras notas não aplicadas.
Caso haja necessidade de modificações, na aplicação da nota pode ser direcionado ao
Modification Browser (SE95).

SAP Support Packages

Correções de erros e novas funcionalidades dos layers (SAP_BASIS, SAP_ABA, etc.)
são implementados via support packages.
Tipos:
- COP: component package;
- CRT: conflict resolution transport: resolve conflitos entre Support Packages e Add-ons.
- PAT: novas funcionalidades para SPAM/SAINT
SPAM é utilizado para importar SP tanto para o sistema standard SAP quanto para Add-
ons:
- Leitura de SAP SP;
- Import de SP:
- Restarting: reinicia de onde parou;
- Exibe a situação atual do sistema;
- Permite procedimentos especiais de importação, como o downtime-minimized;
- Permite agendamento de início;
- Permite processamento em background.
Atualizações PAT são feitas apenas via SPAM: melhorias nas transações para os novos
SPs. Apenas em Inglês e Alemão, linguagens recomendadas para se utilizar esta
transação.
Pré-requisitos:
- SP requerido disponível;
- espaço no FS;
- import em período de baixo uso;
- SPAM/SAINT mais novo;
- TMS/CTS configurado;
- nenhum SP abortado;
- client 000;
- usuário com autorização para a SPAM (administrador = S_A.SYSTEM =
S_TRANSPRT + S_CTS_ADMIN).

65
Carregar o SP do site ou CD e descomprimir  copiar para o servidor  SPAM >
Support Package > Load Package  From Application Server.
Se for < que 10MB, Support Package  Load Packages  From the Front End. Marcar
“decompress”.
Processo de import:
- Preparation: fase de preparação e testes de import. Durante período produtivo;
- Import1: import, ativação e modificações (se necessário) em objetos do dicionário.
Durante período produtivo;
- Import2: demais passos do import, como ativação dos objetos inativos. Durante
período não produtivo;
- Clean up: modificações no dicionário. Durante período não produtivo.
Não transportar de preparation até import 2.
SAP Support Package Manager garante que apenas SP relativos ao sistema serão
importados.
Pode ser criada uma fila selecionando “All Components”, que contém SP disponíveis
para o sistema, CRTs e Industry Solutions.
Regras:
- os SP são colocados na fila na seqüência correta;
- Caso um SP não esteja no meio, ele é adicionado automaticamente.
Test Scenario ou Standard Scenario: Extras  Settings:
- Para verificar possíveis conflitos com modificações, prevendo o esforço e tempo a ser
usado;
- importa toda a fila. Se ocorrer erros, continua de onde estava. Pode ser ativada a opção
“downtime minimized”.
Modificações:
- SPAM paraliza o serviço para a modificação (continua a partir do step RUN_SPAU ou
RUN_SPDD);
- Alterar o código, salvando em uma request, através da SPAU ou SPDD (SPAM 
Extras  Adjust Modifications);
- SPAM  Support Package  Import Queue. Será apresentada tela de customização,
clicar em continue.
Após importar, selecionar “Confirm queue”;
Para atualizar em outros sistemas do landscape:
- Devem ter sido importados com sucesso em um sistema;
- Modificações devem ter sido feitas;
- Sistemas devem ter o mesmo diretório de transporte;
- No sistema seguinte, importar normalmente os SP;
- Alterar o SPDD manualmente;
- Importar a(s) request(s) que modificaram a SPAU.
Para downtime minimized import, onde report sources e report texts são importados com
o sistema ativo (reduz de 70 a 80% no ECC):
- Importar report sources e report texts em modo inativo. Paralelamente a versão ativa
estará no sistema;
- Ativar os sources e texts que foram alterados e remover os obsoletos (down-time);
- Inativar sources e textos ativos (down-time);
- Remover sources e texts obsoletos.
SPAM faz preparação e testes e importa objetos durante período ativo (customizações
bloqueadas)  SPAM apresenta uma tela solicitando a desativação do sistema 
Administrador para os batches e pede para todos usuários efetuarem logoff 

66
Administrador pressiona “continue”  SPAM ativa os objetos e informa conflitos em
modifications  modifica-se os objetos  Import Queue novamente.
Recomenda-se atualizar a SPAM/SAINST antes de usar.
Updates na SPAM/SAINST só são feitos se não houverem SP abortados:
- Aplica-se a fila de SPs; ou
- Limpa a fila (Extras  reset status  queue) e aplica atualização da SPAM/SAINST.
Support Package Stack possui a combinação otimizada de SPs e patches. Contém
instruções de aplicação, componentes, requerimentos, etc.

SAP System Upgrade

Antes de realizar o upgrade, deve-se analisar o por quê: técnico, estratégico, etc:
- qual o custo total do upgrade?
- o upgrade trará vantagem financeira para mim (payback/ROI)?
- Quais os benefícios do upgrade?
- Quais os riscos envolvidos?
Itens a serem pensados no planejamento do upgrade:
- Release de customizações;
- modifications;
- adaptação e testes de melhorias de usuários;
- adaptação e testes de interfaces;
- adaptação e testes de formulários;
- treinamento do usuário final;
- testes e validação de novos releases.
A maior parte do projeto de upgrade é adequar os processos do negócio às novas
funcionalidades do sistema.
Atividades técnicas a prever:
- requerimento de hardware;
- sizing e configuração;
- planos de SO, DB, Kernel e upgrade de sistemas SAP;
- testes e validação de backup da nova versão;
- tecnical upgrade de todo o system landscape;
- atividades pós-upgrade, incluindo acompanhamento de performance.
Um upgrade técnico envolve:
- tomar decisões sobre a estratégia de upgrade e a conversão de tabelas. Planejar as
modificações para minimizar o downtime;
- requerimentos de software, hardware, SO e BD devem ser vistos antes do upgrade;
- após realizar as atividades de PREPARE, iniciar o upgrade;
- PREPARE são atividades para verificar se o sistema pode receber o upgrade. Testes e
ações manuais podem ser feitos antes do upgrade;
- realizar o upgrade;
- atividades pós-upgrade.
Ferramentas para auxiliar o upgrade:
- Prepare: faz verificações no sistema, como SP e Add-ons, e importa outros tools para o
upgrade;
- ICNV (incremental table conversion): tool importado pelo PREPARE responsável por
trabalhar mudanças na estrutura de tabelas.
- Upgrade Assistant: processa independentemente de um certo front-end;
- Upgrade Monitor: monitora o upgrade e ajuda a identificar onde está parado. Estima
quanto tempo falta.
- SGEN: feito upgrade a cada versão.

67
Fases do upgrade:
- PREPARE (prepare);
- EU_IMPORT (import);
- DIFFEXP (import);
- START_SHDI (shadow);
- ACT (shadow);
- SHD_IMP (shadow);
- SWITCH (switch);
- PCON (switch);
- TABIM (switch);
- XPRA (switch);
Durante a fase de switch, o sistema estará em período não produtivo.
Alterações feitas na SPAU e SPDD devem ser incluídas (não importadas) no upgrade da
próxima base.
Todas as modifications são perdidas, sobrepostas em novos objetos. Elas devem ser
refeitas nesses novos objetos.
A lista de objetos que precisam ser ajustados é gerada na fase ADJUSTPRP, durante o
PREPARE,
As modifications devem ser feitas durante o downtime, antes da ativação de objetos do
dicionário ABAP. São agrupadas em uma request, que não sofre release, mas é marcada
como export na SPDD.
Objetos não devem ser manualmente ativados. Eles serão ativados nas fases corretas.
Após o upgrade, são concedidos 14 dias para execução da transação SPAU sem
necessitar de SSCR em objetos modificados anteriormente.

68
TADM12_2
Unit 1 – Introduction to Workload Analysis
Components of Dialog Step
ST06 – detalhes do sistema operacional;
ST04 – detalhes do banco de dados;
SM04 – usuários no sistema;
ST02 – buffers do SAP.
Dialog Response Time: tempo entre recebimento da solicitação pelo dispacher e a
resposta (não conta tempo do GUI).
Wait Time (tempo na fila de espera por um WP livre)  Roll-in Time (carga do
contexto do usuário do roll buffer na roll memory do WP)  Load And Generation
Time (tempo para carregar o programa do buffer ou banco, e compila-lo, se necessário)
 Processing Time (dialog response time menos a soma de todos outros times) 
Buffer Access Time (tenta ver se tem o dado no buffer – 0ms) e Database Request
Time (tempo para pegar o dado do banco, caso não tenha no buffer)  Lock Time ou
Enqueue Time (tempo para fazer um lock lógico)  Roll Out Time (tempo para
devolver o user context para o buffer na shared memory) em paralelo com o envio do
resultado para o SAP GUI.
CPU Time é diferente de Processing Time.
Para análise de problemas:
Alto Wait Time: falta work process;
Alto roll-wait time: problemas de comunicação com o GUI, outro sistema ou muitos
dados requeridos;
Alto Load And Generation Times: buffers pequenos (CUA, Program ou Screen);
Alto tempo de banco de dados: verificar problemas no banco de dados;
Alto tempo de CPU: muito processamento ABAP (ex.: tabelas grandes), melhorar lógica
de programação;
Tempo de processamento maior que 2x CPU Time: gargalo na CPU.

Statistical Records and the Workload Monitor

ST03N: Workload Statistics
Visões:
- Workload: workload statistics;
- Detailed Analysis: link para a STAD;
- Load History and Distribution: dados de workload históricos e histórico de acesso de
usuários;
- BW System Load (BI Workload): histórico de acessos BW;
- Collector and Performance DB: dados de performance do banco, acesso ao arquivo de
log e configuração dos coletores.
Analysis View:
- Workload overview;
- Transaction profile: standard (dialog data) e EarlyWatch (todos tipos de tasks);
- Time Profile;
- Ranking lists;
- Memory Use Statistics;
- RFC Profiles;
- User and Settlement Statistics: estatísticas por usuários e clients;
69
- Front end Statistics;
- Response Time distribution: tempo de resposta. Em %, deve ter + de 95% abaixo de 2
segs;
ST03G: Global workload Monitor
Idem ST03N, porém monitora todos os sistemas cadastrados. Os dados são armazenados
localmente nos sistemas, e transferidos a cada hora para o central.
A mais:
Control: controla quantas records serão coletadas nas instâncias e quanto tempo ficará
disponível;
Settings and logs: sistemas monitorados e logs escritos.
STAD: Business Transaction Analysis
Monitora do início da transação até a chamada de update, ou quando o usuário abandona
a transação.
STATTRACE: Functional trace
Análise de dados estatísticos de sistemas remotos (ou local).
Cada dialog step gera dados coletados, que é colocado na shared memory, consultável
via ST02  (buffer full, ou STAD/Last minute, ou a cada hora) passa para disco
(parâmetro stat/file: <dir_instance>/data ), consultável via STAD e ST03N Last minute
load  Job SAP_COLLECTOR_FOR_PERFMONITOR roda relatório RSCOLL00 que
agrupa informações do arquivo e joga no banco de dados.

Unit 2 – Performance Analysis Monitors

SAP Performance Monitors
SM50:
- No: número do WP;
- Ty: tipo (dialog, etc.);
- PID: PID no SO;
- Status: waiting (IDLE), running, On hold (esperando o q está falado em “reason”),
stopped (erro), shutdown, reservied (reservado);
- Reasn: possível razão para o status;
- Start: se será automaticamente reiniciado caso erro;
- Err: número de reinícios;
- Sem: semáforo usado para gerenciar recursos no SO;
- CPU: tempo usado de CPU desde o startup;
- Time: tempo de processamento, em segundos, fica vermelho quando maior que
rdisp/max_wprun_time;
- Report: report em execução;
- CI: client;
- User: usuário;
- Action: ação executada;
- Table: tabela acessada.
SM66: global workprocess Overview: idem SM50, porém mostra a transação executada.
Shift F6 ou F7 para navegar entre os modos de visão.
SAPOSCOL: 1 por máquina, independente de quantas instâncias tiverem;
Monitorar SO: ST06, OS06 e OS07.
Mais importantes:
- CPU Utilization:
- User: deve estar entre 50% e 60%;
- System: abaixo de 20%;

70
 - Idle: acima de 20%. Abaixo disso pode causar gargalo
- I/O Wait: CPU esperando resposta, deve estar abaixo de 10%;
- Average CPU Load: separado por minutos, mostra processos em espera para entrar na
CPU. Valor alto + consumo CPU alto = muitos processos no sistema. Valor alto +
consumo CPU baixo = pouca memória.
- Count: número de CPUs no sistema;
- Memory: physical mem avail.: RAM do sistema;
- Swap:
- Maximum swap space: espaço de swap;
- Commit Charge Limit (Windows): virtual memory (RAM + Swap);
- Operating System Monitor: detalhes do SAPOSCOL;
- Detail analysis Menu: informações detalhadas de CPU, memória, etc.
ST02: The Buffer Monitor
Mostra o status dos buffers do SAP, utilização de memória e buffer de tabela.
Considerações:
- Hit Ratio deve estar acima de 95%;
- Swaps ocorrem devido não ter espaço livre no buffer ou os diretórios do buffer estão
ocupados (diretório são divisões do buffer para cada objeto. Quanto maior, menos
objetos cabem, quanto menor, o objeto pode não caber no diretório);
- Não pode haver swap, nem telas em vermelho;
Detalhes:
- Nametab: Repository buffer ou ABAP Dictionary Buffer. Contém valores de definição
de tabela e campos. Hit Ratio deve estar por volta de 99,5%. Dividido em:
- Table Definitions (TTAB)
- Field Descriptions (FTAB);
- Initial Record Layouts (IREC): layout da record, dependendo do tipo de campo
usado;
- Short Nametab (SNTAB): sumário dos buffers TTAB e FTAB.
- Program Buffer (PXA): ABAP Buffer. Programas carregados antes do processamento
pelo WP. Caso não haja espaço no buffer, o algorítimo LRU tira o mais antigo para abrir
espaço para o novo. A remoção é marcada como Swap. Para evitar queda de hit ratio
durante boot, os programas no buffer são escritos em um arquivo, e recarregados após
reinício. Swap de até 10.000 objetos por dia é considerado normal.
- CUA Buffer: Menu Buffer. Guarda informações para o SAP GUI, como botões e
menus. Não prejudica o desempenho.
- Screen Buffer: Dynpro buffer. Guarda telas do sistema;
- Calendar Buffer: feriádos públicos e da empresa. Não atrapalha o desempenho do
sistema;
- OTR Buffer: Online Text Repository: textos usados por BSPs, Exception Builder e
serviços HTTP. Não atrapalha o desempenho do sistema;
- Generic Table Buffer: generic buffer ou generic table key buffer. Guarda dados de
tabelas, conforme definido no ABAP Dictionary;
- Single Record Table Buffer: Single record buffer ou partial table buffer. Guarda apenas
uma linha da tabela. Esperado Hit Ratio baixo, devido guardar poucos dados. Se não há
muito swap, não influencia no desempenho;
- Export/Import Buffer: dados carregados para vários WP;
- Exp / Imp SHM (Shared Memory): usada por programa ABAP, através de commando.
Se não há swap, está ok.

71
Analysing SAP Web AS Java Performance
Via ST03G e STATTRACE.
Trace de SQL pode ser iniciado via Visual Administrator ou via
http://<server>:<port>/SQLTrace.

Analysing ICM Performance

SAP provê parâmetro para limitar quantidade de acessos nos WP pelo ICM.
SAP Web Dispacher: dispacher para se usar vários ICMs.
Monitoramento via SMICM ou via Web.
SMICM: limpeza de cachê: goto  http Server Cachê  Invalidate  Only Local
Tuning:
rdisp/start_icman: identifica se a instância tem ICM ou não;
SAP Web Dispacher permite load distribution;
UFO Cache: unfound object cache. Bloqueia requisição de serviços não existentes;
ISC: Internet Server Cachê: cachê do ICM. Eficiência: goto  HTTP Server Cachê 
Display Statistics.
Work Threads: configurar nos parâmetros icm/min_threads e icm/max_threads o número
mínimo e máximo, que pode ser maior que icm/max_conn (número máximo de
conexões, pois conexões inativas não consomem threads). Cada thread ocupa 512Kb.
Cota de acessos: através do parâmetro icm/HTTP/context_quota setar em % em relação
ao parâmetro rdisp/tm_max_no.

Performance Analysis on Integrated ITS

ITS veio integrado no Web AS 6.40, chamado pelo ICM e monitorado via SICF.
Parâmetro: itsp/enable = 1;
SICF para configuração;
Report SITSPMON mostra o status;
Transações de logs (SM21 e ST11).
72
ITS: 10 Mb por linguagem, 10 Mb por tipo de browser + 3Mb por sessão, que usa a área
da em/global_area_MB, que não deve ser maior que ¼ da Extended Memory.

Unit 3 - SAP Memory Management

Memory Areas
Work processes trabalham na local memory e todos eles compartilham a shared
memory. As duas memórias formam a virtual memory.
A virtual memory pode estar na memória física ou no Swap, sendo gerido pelo sistema
operacional.
A local memory dos work processes é usada para:
- ABAP load;
- Data, stack;
- Buffer for database transfer;
- Local roll área;
- Local paging área.
A shared memory possui:
- SAP Buffers: que contém programas, conteúdos de tabelas, etc;
- Extended Memory: que contem dados e objetos de transações ainda não finalizadas.
- Heap memory: contém dados da Extended Memory, caso esta esteja full. Aloca sob
demanda no espaço da local memory.
- Roll Buffer: parte inicial do contexto do usuário;
- SAP Paging Buffer: possui objetos ABAP e objetos independentes de contexto;

Problemas na configuração de memória (ST02):

- Extended Memory: Max Use deve ser menor de 80% da In memory;
- Roll Área: Max Use deve ser menor que 80% da In Memory.

73
SAP Memory Allocation
User Context: dados que estão sendo usados para aquela sessão do usuário (autorizações,
set/get parâmetros, tabelas internas, report lists).
Roll-in: contexto do usuário da Roll Área para a local memory;
Roll Buffer  roll file: contexto de usuário
Page buffer  page file: memória para comandos específicos.
Os dados das transações são guardados na memória estendida e acessadas via pointers, o
que permite mudança de work process de forma rápida, sem precisar copiar dados de
memória (apenas os ponteiros).
Windows + Dialogs de outros SO:
Processo ocupa na roll memory apenas o valor do parâmetro ztta/row_first  começa a
usar a memória estendida até estourá-la ou quando a cota por usuário é superada
(ztta/roll_extension)  o restante da Roll Memory (ztta/roll_area) é usada (para evitar
usar a Heap Memory e PRIV mode)  usa Heap Memory (abap/heap_area_dia),
entrando em modo PRIV, sendo o WP dedicado àquele usuário.
WP não dialogs em outros SO:
Processo ocupa toda roll memory (ztta/roll_area)  Usa Heap Memory
(abap/heap_area_nondia ou até estourar)  Usa extended memory (ztta/roll_extension).
Após uso, a Heap Memory é liberada, exceto no Unix (e sistemas baseados), que quando
o limite estipulado em “abap/heaplimit” for ultrapassado, ele é marcado para reiniciar,
liberando a memória.
Parâmetros

ztta/roll_first: alocação inicial da roll área, antes de usar a extended;

ztta/roll_area: roll área total, por WP;
rdisp/roll_SHM: tamanho do roll buffer;
rdisp/roll_MAXFS: tamanho do arquivo de roll buffer;
em/initial_size_MB: tamanho inicial da memória estendida;
ztta/roll_extention: cota de usuário para memória estendida;
abap/heap_area_dia: tamanho ocupado na Heap Memory pelo dialog;
abap/heap_area_nondia: define o limite de memória local para processos não dialogs;
abap/heap_area_total: total de heap memory para todos os WP.

74
Implementation Of SAP Extended Memory

O parâmetro em/initial_size_MB é limitado por SO, sendo 32 bits <= 4Gb e 64 bits
espaço maior. SAP recomenda <= 2Gb no 32bits.
O valor padrão de ztta/roll_extension é 2Gb, então é limitada pelo parâmetro
em/adress_space_MB.
Quando a instância é iniciada, a memória estendida é alocada pela variável
em/initial_size_MB. No windows, será esticada até o valor de em/max_size_MB (ou
limite de memória física = RAM + Swap).
ST02  Detail Analysis Menu  SAP Memory  Mode list. Verificar user que
estejam usando Heap Memory (PRIV mode). A terceira coluna (X), mostra WP que
estejam processando. Os demais estão aguardando.

Memory Usage for SAP Web AS Java

JVM dividido em:
- Young generation: objetos recentes;
- Tenured generation: usados por um bom tempo;
- Permanent generation: ex.: classes principais e métodos.
Avaiable memory = memória alocada, não necessáriamente no máximo possível =
reserved memory.
Virtual memory = memória não alocada (total – alocada).

75
Recomendado colocar valor de início = valor máximo, para evitar mudanças de tamanho
durante a operação.

Unit 4 – Hardware Bottlenecks

Hardware Bottlenecks
CPU idle na transação ST06 deve estar por volta de 20%. Menos do que isso pode
causar “CPU Wait”. Valor ótimo é em torno de 20%.
Se a CPU estiver alta:
- ST06  Detail analysis menu  Top CPU processes: processo consumindo muita
CPU;
- Anotar o PID do processo acima e identificar na SM50;
- Verificar na ST04 o porquê de tanto consumo, se pode ser feito tuning ou se é melhor
deixar para horários com menos utilização da máquina.
SOs baseados em Unix, toleram swap-out até 20% do tamanho da memória física por
hora. Swap-in não influencia na performance.
Windows tolera page-in até 25% da memória física por hora. Page-out não influencia na
performance.
Para verificar a atividade de Page/swap, ST06  Detail analysis menu  Previous
hours  Memory.
Alto swap/Page pode indicar gargalo de memória. Para reduzir o consumo:
- Distribuir processos que não são específicos para este hardware para outra máquina;
- se necessário, reduzir o tamanho do cachê de file system para menos de 10% da
memória física total;
- Identificar usuários/programas que consomem muita memória: ST02  Detail analysis
menu  SAP memory  Mode list. Tuning de SQL ou ABAP pode ser necessário.
Na transação ST03N podem ser verificados processos com grande média de wait time.
Processo com processing time maior que duas vezes o tempo de CPU pode indicar
gargalo.

76
Optimizing Hardware Utilization
Dicas para configuração inicial de memória (ECC 5.0):
- Banco de dados por volta de 20% da memória física de todos servers SAP;
- Buffers em um total de 1Gb por instância;
- Considerar por WP entre 50 e 60Mb de memória
- de 15 a 20Mb por usuário;
- Após primeiro startup, o consumo de memória virtual não pode exceder 2x RAM;
- Swap no Unix: 3x RAM, mínimo de 5Gb. No 64bits, 20Gb;
- Page size no Windows: 4x RAM.
Verificar memória virtual: ST02  Detail Analysis Menu  SAP Memory.
Fatores para sizing de CPU:
- distribuição de carga durante 24hs, 7 dias, 1 mês, 1 ano;
- aplicações usadas;
- Número de usuários concorrentes;
- Tipo de hardware, SO, produto SAP e versões.
Notas gerais de consumo de CPU:
- BD entre 10% e 30% do total de CPU de todo sistema SAP;
- Update process entre 10% e 20% do total de CPU de todo sistema SAP.

Unit 5 – Expensive SQL Statements

Detecting Expensive SQL Statements
Expensive selects sao definidos como todos SQLs que fazem o banco ler muitos blocos
(do disco ou buffer).
Usualmente, comandos são considerados expensivos quando lêem mais de 5 blocos por
Record encontrada. Algumas definições alteram esse limite para 30 blocos.
No Workload Analysis (ST03N), podem-se somar os tempos de resposta para ver os
comandos que demoram mais a responder ou transações mais demorada. Mas nem todo
comando SQL expensivo será passível de melorias.
Como usar o Work Process Overview (SM50):
- Identificar ações longas (ex.: “Sequential Read”, “Insert” ou “Update”);
- Verificar o nome do report e transação (SM66) para futuro detalhamento;
- Verificar o nome da tabela;
- Duplo clique na linha mostra o SQL que está executando (SM50).
Como usar o Transaction Profile (ST03N):
- Ordenar por Average DB time. Transações com alto tempo de resposta pode ser por
causa de SQLs;
- Ordernar por Total Database Time e somar. Transações com mais de 5% do total
devem ser verificadas. Podem conter SQLs expensivos.
- ordernar por Total Response Time e somar. Transações com mais de 5% do total
devem ser verificadas. Podem necessitar tuning de ABAP.
Como usar Statistical Records (STAD):
- Selecione um tempo;
- Task type D;
- Escolher um valor relevante para DB request time (ex.: 1000ms).
- Duplo clique nos resultados para análise.
No Database Monitor (ST04):
- Qualidade do data buffer > 95%;
- devem haver menos recursive calls do que user calls;

77
- verificar “reads/user call”: não exceder 30 (blocos por user call). Isto é um forte
indicador de comandos expensivos.
Como usar o Database Process Monitor (ST04  Detailed Analysis Menu  Oracle
Session):
- Identificar processos demorados, comparando o WP ID com o Client PID na
SM50/SM66;
- Verificar a ação no banco clicando em SQL Statement, no popup verá a informação do
dicionário do objeto, o explain plan do SQL e a referência para a linha do programa
ABAP. Analise o explain.
Terminologia no monitoramento do banco de dados:
- Reads: número de blocos lidos para o comando a partir do data buffer (encontrado
diretamente no buffer ou lido do disco e jogado no buffer);
- Buffer Gets: número de blocos lidos do data buffer;
- Physical Reads/Disk Reads: blocos lidos do banco de dados (ST04  Detailed
Analysis Menu  SQL Request: Analysis of Shared Cursor Cache).
SQLs:
- ABAP: maúsculo e com aspas. Podem ser alterados;
- Database administration tools: maiúsculo e não pode ser tunado;
- SAP Basis tables: tabelas D*, não podem ser tunadas;
- SQL Recursivos (Oracle): minúsculas, não pode ser tunado.

Analysis and Tuning of Expensive SQL Statements

Todas as tabelas SAP utilizam o otimizador bazeado em custo, que calcula o custo
diferentes formas de acesso baseados em estatísticas.
Estatísticas contém informações da tabela (ou índice) como número de entradas,
distribuição nos blocos do BD, etc.

Unit 6 – SAP Table Buffering

Introduction to Table Buffering in SAP Systems
O sistema pode acessar dados de tabelas em buffer, chamado table buffer.
Via transações SE11 e SE13 podem ser definidos 3 níveis de buffer:
- Fully Buffered: tabela inteiramente bufferizada;
- Generic Area Buffered: dados são bufferizados seguindo regras de campos chaves
definidos;
- Single Record Buffered: cada linha acessada é bufferizada.
Ambientes que possuem apenas um Central System, o buffer é sempre up to date, uma
vez que dados alterados são invalidados no buffer. Porém, em ambientes com mais de
uma instância, o parâmetro rdisp/bufrefmode deve ser setado para “sendon,exeauto”,
para se segurar que:
- o SAP logará cada alteração de buffer na tabela DDLOG (sendon);
- as instâncias frequentemente acessarão a tabela DDLOG para verificar se os dados no
buffer são válidos (exeauto).
O tempo para invalidação do buffer é definido pelo parâmetro rdisp/bufreftime,
usualmente setado para 60s ou 120s.
Não ativar buffer em tabelas de dados de negócio, que devem ter garantia de não pegar
dados antigos no buffer. Considerar opção de buffer “Buffering not allowed”.
Comandos SQL que não utilizam o buffer:
- Select ... bypassing buffer;
- Select for update;

78
- Select distinct;
- Order by (campos não chaves primárias);
- Funções de agragação (min, Max, count, sum, avg);
- Where com “is null”;
- SQLs nativos.
Não ativar buffer de tabelas para:
- Tabelas originais SAP definidas como “buffering not allowed”;
- Tabelas que não podem ter dados desatualizados;
- Tabelas de transação.
Recomendações:
- Tabelas que são pouco alteradas;
- Tabelas muito acessadas;
- Somente em casos especiais para tabelas com mais de 1Mb;
- São mais efetivos para tabelas acessadas pela chave primária;
- Verificar se o buffer tem espaço suficiente para a nova tabela bufferizada;
- Dados de customizações são geralmente bufferizados.

Analyzing Table Buffering

Acessar ST03N  Transaction Profile e ordernar por “Response time total” 
transações com CPU time altos (> 40%) fazer trace de ABAP (SE30). Transações com
database time alto (> 40%)  selecionar a transação e pressionar “Single Records” 
Fazer trace de SQL (ST05) e analizar os buffers de dados (ST10).
Perguntas a se analisar na ST10:
- Tabelas sem bufferização com muitos “Total ABAP Processor Requests”: bufferizar?
- Tabelas bufferizadas com grande número de invalidações: retirar bufferização?
- Tabelas bufferizadas com grande número de “Rows affected”: retirar bufferização?
- Tabelas com grande tamanho de buffer: retirar bufferização?

Unit 7 – RFC Monitoring

Remote Function Call Basics
RFC é uma tecnologia para conectar sistemas SAP. RFC entre servidores SAP permite
processamento automático de dados. SAP GUI utiliza RFC para se comunicar com o
sistema SAP.
Uso de RFC:
- Comunicação entre sistemas SAP ou SAP e sistema externo;
- Comunicação entre a aplicação SAP e o SAP GUI;
- Inicializar processos em paralelo no SAP.
Tipos de RFC:
- Synchronous (sRFC): comunicação entre sistemas e SAP com o SAP GUI;
- Asynchronous (aRFC): comunicação entre sistemas e processamento paralelo;
- Transactional (tRFC): tipo especializado de aRFC, usado para comunicações seguras
entre sistemas;
- Queued (qRFC): tipo especializado de tRFC, para comunicação em ordem
específica.
Terminologias:
- Client: quem estabelece a comunicação;
- Server: quem recebe a comunicação;
- Roll Wait Time: tempo de espera de retorno da chamada RFC;
- RFC+CPIC time:

79
 o Synchronous: tempo no cliente de estabelecer RFC + Roll out (envio) + Roll
wait +Roll in;
o Asynchronous: tempo de estabelecer RFC.
AS envia informações em blocos ao GUI, chamados round trips.
GUI Time:
- Server: estabelecimento de RFC p/ cliente + Roll out + roll wait time;
- Client: network transfer + screen build.
Response time: wait, roll in & load time + processing time + database time + processing
time + Gui time.
GUI Time é acumulativo, ou seja, somado em cada dialog step. Na ST03N pode-se
retirar o GUI time no Response Time Distribution.

Monitoring RFC Load and Solving RFC Load Problems

Records estatísticos contêm informações detalhadas de um step de uma transação. Existe
uma Record principal por step, que pode conter várias sub-records, dependendo da
parametrização.
Parâmetros para coleta de dados estatísticos:
- Kernell administration: stat/adrec: normalmente desligado, visto que engrandece o
arquivo de estatísticas;
- BTC: stat/btrrec: padrão 50 subrecords, cada uma corresponde a um step do job;
- Database procedure: stat/dbprocrec: zero por default, tem relevância no APO;
- Spool: stat/sporec: default 5;
- Table Access: stat/tabrec: usado em combinação com o stat/tabrec_tcode_nr para
restringir sub-records de acesso a tabelas para somente códigos de transações
selecionadas;
- HTTP client: stat/httprec: número de sub-records para salvar estatísticas de queries do
AS para cada transaction step;
- Remote function call: stat/rfcrec: default 5, que significa 5 RFCs sub-records são
escritas por transaction step. 5 para top five response time e + 5 para top five
destinations.
No caso de transaction steps com RFCs, o SAP kernel escreve adicionais records
estatísticas: as RFC Sub-records.
ST03N  Workload  RFC Profiles:
- RFC Client profile: agregado de individuais RFC Client sub-records para cada function
module chamado;
- RFC Server profile: agregado de individuais RFC Server sub-records para cada
function module chamado;
- RFC Client-destination profile: agrupamento de todas chamadas RFCs individuais por
cliente;
- RFC Server-destination profile: agrupamento de todas chamadas RFCs individuais por
Server.
As functions modules ARFC_DEST_CONFIRM, ARFC_DEST_SHIP,
ARFC_RUN_NOWAIT e RFC_PING fazem parte do framework da tRFC e não devem
ser analizadas.
Na STAD, se RFC+CPIC time exceder em muito o roll-wait, pode haver problemas de
comunicação.
Roll wait time alto pode indicar expensive GUI round trips. Neste caso, tempo de GUI
alto pode ser observado na ST03N.
O Performance Trace (ST05) possui informações relevantes sobre SQL, enfileiramento e
acesso a buffers, além de comunicação RFC. Quando o Trace é ativado, a primeira

80
entrada é a função SAPGUI_PROCESS_INDICATOR. O comando referindo a
OLE_FLUSH_CALL indica o round trip para o GUI. O máximo de dados a ser
transferido é 32Kb, caso ultrapasse, a função GUICORE_BLOB_DIAG_PARSER é
chamada.
Trace de autorizações pode ser iniciado via ST01, o trace indica o início de transações,
chamadas RFCs e SQLs.
sRFC: CALL FUNCTION ... DESTINATION
aRFC: CALL FUNCTION … DESTINATION … STARTING NEW TASK
tRFC: CALL FUNCTION … DESTINATION … IN BACKGROUND TASK
tRFCs não são executadas imediatamente, são executadas no COMMIT WORK
seguinte: chamadas são guardadas nas tabelas ARFCSSTATE e ARFCSDATA, onde
cada logic unit of work (LUW) é identificada por um ID  COMMIT WORK  calls
referentes aos IDs são executados no target system  LUW executada no destino com
sucesso?  função ARFC_DEST_CONFIRM (no cliente)  tabelas ARFCSSTATE E
ARFCSDATA apagadas.
Erros em tRFCs podem ser vistas na SM58. Caso o sistema de destino não seja
encontrado, ex.: conexão não ativa, um report RSARFCSE é agendado com o ID. Para
ver o intervalo padrão: SM58  Info  System Settings. Se quiser alterar para uma
determinada RFC, SM59  Destination  tRFC options.
Monitoramento de carga RFC: ST03N.
Análise de RFC:
- SM50:
- reports SAPLARFC (aRFC) e SAPLERFC (tRFC);
- Acessos a tabelas ARFCSSTATE ou ARFCSDATA (tRFC);
- Workprocess com status “stopped”, com ação CMINIT, CMSEND ou
CMRECEIVE por longo tempo indica problemas de comunicacao.
- SM04: tipo RFC;
- STAD: task type R;
- SM58: monitorar tRFCs;
- ST03N: RFC Profiles.
Se for esperada uma grande carga de chamadas RFC entrantes, é recomendado
configurar uma instância dedicada a essas RFCs.

Unit 8 – Acess to Help

Configuring the Online Documentation
SAP Library = Online Documentation = help instalado.
Usando o SAP Library, pode-se facilmente pesquisar, acessar o glossário e uma
introdução de como usar o SAP (Getting Started).
Tipos de help:
- HtmlHelpFile: formato HTML compilado, disponibilizado em file server, exibidos no
HelpViewer. Disponível apenas no windows, pode-se fazer pesquisa e imprimir várias
documentações concorrentes, 10% do tamanho do HTML padrão;
- PlainHtmlHttp: formato HTML padrão, disponibilizado em um web Server, permite
fazer pesquisa e imprimir uma documentação individual;
- PlainHtmlFile: formato HTML padrão, disponibilizado em file Server, aberto
diretamente no Browser;
- DynamicHelp: usado em todos front-ends, formato HTML padrão, acessível via
Knowledge Warehouse Server.

81
IMG  General Settings  Setting Variants for help (SAP Library) ou SR13 é usado
para configurar o help. A partir do R/3 4.6C, não é necessário alterar configurações no
perfil.
Na configuração das variáveis do help, o campo Area indica a área de conhecimento a
que se refere o conteúdo. Ex.: EWBHELP (documentação para todos usuários),
IWBTRAIN (treinamento), etc.
Se forem instalados vários tipos de help, o usuário poderá optar em Help  Settings 
Extended Help (via GUI).
Configurações locais de front end são possíveis através do arquivo sapdoccd.ini,
presente no windir, diretório do sapgui ou um nível acima deste. Este arquivo deve ter
dados que estão na SR13, caso contrário não mostrará o help.

Unit 9 – Introduction to System Security

Security in the SAP Environment
Mecanimos de criptografia, parâmetros de segurança de sistema e SAPRouter são alguns
componentes que apóiam na implantação de conceitos de segurança.
Usuários administradores padrões devem ter sua senha trocada. Sendo eles: SAP* em
todos clientes e DDIC existe apenas no 000. O EarlyWatch no 066 não possui acessos
administrativos, então não é necessário alterar a senha.
O parâmetro login/no_automatic_user_sapstar só funciona se o usuário SAP* não existir
no client.
SNC é uma camada de software no SAP que fornece uma interface com produtos
externos de segurança. A implementação de segurança é feita com produtos que não são
diretamente fornecidos pela SAP.
SNC provê segurança em nível de aplicação, isto quer dizer que a comunicação entre
componentes estará segura.
Níveis de proteção:
- Authentication only: apenas a identidade do partner é verificada;
- Integrity protection: o sistema identifica alterações na mensagem, feitas durante a
transferência;
- Confidentiality protection: mensagem é encriptada, inclui as duas anteriores.
SNC criptograva protocolos DIAG e RFC. Para HTTP, é usado o SSL. Usos:
- comunicação direta do AS com a internet, via ICM;
- comunicação com internet via ITS, presente no WGate (web Server).
Secure Store and Foward (SSF) assegura que dados e documentos são seguros durante
transações dialog. É o caso de:
- dados que deixam o sistema (eletronic orders, invoices, information);
- dados que são gravados em mídias não seguras (disquetes, archive);
- dados que são transferidos usando redes não seguras (internet);
- dados individuais de pessoas (assinatura digital, dados pessoais).
SAPRouter gerencia conexões através do firewall, mas não dispensa o uso deste.
O SAPRouter pode ser usado para:
- controlar e logar conexões;
- criar conexões indiretas (ex.: regra da rede não permite acesso direto);
- resolver conflitos de endereçamento quando não usa IPs registrados;
- aumenta segurança: protege por senha, apenas acessos permitidos, SNC...
- aumenta a performance e estabilidade reduzinho do workload do sistema com uma
LAN durante comunicação com a WAN.

82
Unit 10 – Archiving
Fundamentals of SAP Data Archiving
Data Archiving significa a extração de objetos de dados do banco de dados, de forma
consistente, onde todos dados extraídos são escritos em um arquivo fora do banco de
dados. A consistência de regras de negócio é assegurada pelos programas de archiving
da SAP.
Os dados são archivados de forma online, ou seja, com o sistema no ar. Não é necessário
fazer o shutdown.
Razões para archiving:
- melhorar ou assegurar tempos de resposta mais baixos;
- reduzir custos de administração do banco de dados;
- reduzir tempos de backup offline, recoveries, upgrades;
Levar em consideração regras legais do país, como tempo de retenção, etc.
Dados arquivados podem ser acessados a qualquer momento por queries.
Dados arquivados são independentes de versões do SAP. Pode ser extraído em uma
versão, o sistema sofrer upgrade, e serem lidos na nova versão.
Processo de archiving:
1) Criando o arquivo de archive: o arquivo (ou mais) que conterá o archive é criado.
Dados são lidos do banco e escritos nele(s);
2) Guardando os arquivos de archive: após completado a escrita dos archives, eles
podem ser guardados;
3) Removendo os dados: o programa de remoção primeiro lê os arquivos de archive e
então remove as records do banco de dados.
Opções para guardar archives:
- Hierarchical Storage Management (HSM): indicar caminho na transação FILE, o
sistema gerencia onde guardar;
- Optical archiving: CDs, etc.
- Manual Storage: após deleção, podem ser manualmente movidos a uma fita, por
exemplo.

Performing Data Archiving

O elemento central do arquivamento é o archiving object. Ele define a menor unidade
que pode ser completamente arquivado e removido do banco de dados, e descreve qual
database object deve ser acessado, e quando, para o archivamento completo do business
object.
O arquivamento consiste de 3 componentes:
- Data declaration component: descreve todos os database objects que caracterizam um
aplication object;
- Customizing settings: paramentros do archiving object para a execução de um archive;
- Programs: o programa de escrita (do archive em arquivos), de remoção (dos dados do
banco) e o programa de exibição de dados após archive.
Transação DB15 informa qual tabela está associada com qual archiving object e vice-
versa.
Parâmetros:
- General customizing (Basis customizing): logical path e nome dos arquivos gerados;
- Cross-archiving object Customizing: grupo de servidores para processo background;
- Archiving Object-Specific Customizing: tamanho dos arquivos e configurações para
o programa de remoção dos dados arquivados.

83
O processo é agendado para execução em background  seleciona objetos do banco de
dados (levando em conta integridade)  verifica se cada objeto de dados pode ser
arquivado  objetos são escritos no archive  configurado para deleção automática?
 após término da escrita, programa de deleção é executado.
A execução é agendada via transação SARA, clicando no botão “write”:
1) Crie um archive variant (seleciona archiving objects);
2) Especifique um usuário (tem q ter acesso S_ARCHIVE.S_ARCHIVE);
3) Especifique a hora de início;
4) Defina os parâmetros de spool.
O monitoramento pode ser feito via background tools (SM37) ou via CCMS.

Accessing Archived Data

O Archive Development Kit quarda os dados de forma que possam ser lidos
posteriormente, bastando para isso o programa de leitura que é disponibilizado pelo
archiving object.
O acesso é possível de duas formas:
- Sequential (reading) Access: o programa primeiro abre o arquive, lê o conteúdo e
lista os dados que correspondem ao critério de seleção. Ex.: mostrar documentos de um
determinado período;
- Direct Access: o objeto é primeiramente indexado utilizando critérios de pesquisa.
Após isso, acessa diretamente o objeto via o índice criado. Forma mais custosa e não
oferecida para todos archiving objects.
A pesquisa pode ser feita acessando diretamente a transação SARA e escolhendo
“Read”.
O SAP Archive Information System é um utilitário para pesquisa em data archives,
integrado no ambiente de archive. Oferece suporte para pesquisa e provê funções para
exibição dos dados.
Quando acessando dados arquivados, o usuário pode escolher entre diversar formas de
exibição dos data objects. Exemplo são o tecnical view e o Business view.

Unit 11 – Including Printers in SAP Systems

Configuring Printers in SAP Systems
O output em uma impresora é feita sempre da seguinte forma: uma spool request é
criada (formato independente de impressora, com informações de autor, data, etc. e os
dados a serem impressos) e após uma output request é criada (dados específicos para
impressora).
Isso permite visualização da spool antes da impressão. Uma spool pode ter vários output
requests.
O conteúdo de uma spool request é guardado na TemSe (para temporariamente
seqüenciar os objetos) na localização definida pelo parâmetro rspo/store_location:
- db = banco de dados (tabela TST03), com a vantagem de entrar em backup;
- G = file system, com a vantagem de performance.
Para definir uma localização individual para uma output device: SPAD  Edit  Data
Storage.
Se uma impressora não pode ser controlada pelo sistema operacional, ela não pode ser
usada no SAP.
Os principais métodos de impressão são: Local Printing, Remote Printing, e Front-end
Printing.

84
O local printing caracteriza-se por o spool work process e o spool do sistema
operacional estarem na mesma máquina, independente se a impressora está ou não. O
WP passa dos dados de impressão na mesma máquina. É o método mais rápido para
impressão.
- no Unix, os dados são passados via método “L”, usando métodos do sistema
operacional com linguagem específica sendo guardadas em profiles;
- no Windows, o método de acesso é “C” e os dados são passados diretamente ao
sistema operacional via API da impressora.
O uso de vários SPO WP gera diferenças no seqüenciamento de outputs.
No caso do remote printing o SPO WP e o spooler do sistema operacional estão em
hosts separados. Cenários típicos:
- a impressora é acessada diretamente via rede (Access method U);
- uso do programa saplpd instalado em Windows (método “S” ou “U”).
O front-end printing caracteriza-se por utilizar a impressora local do usuário. O
administrador cria apenas uma impressora e associa ao método de acesso “F”.
No Windows, o sapldp recebe a solicitação e encaminha ao Windows output controle.
Nos outros SOs, os dados são direcionados diretamente ao spooler do sistema
operacional.
O número de SPO WP direcionados para front-end printing pode ser estipulado no
parâmetro rdisp/wp_no_Fro_max.
Para criar uma impressora, acessar SPAD, preencher em “devices/servers”:
- Output device: nome longo, 30 caracteres;
- Short Name: nome interno;
- Device type: modelo da impressora. SWIN direciona para o formato Windows printer
driver, que pode ser útil caso o usuário tenha várias impressoras diferentes;
- Spool Server: AS com SPO ou logical Server;
- Location: texto da localização da impressora;
- Message: mensagem que substitui a localização (ex.: temporariamente fora do ar);
- Lock print in SAP system: cria output, mas não manda para impressora;
- Host spool Access method: como o SPO WP acessa o spooler do SO?
- Host printer: nome da impressora no sistema operacional (case-sensitive);
- Host: apenas para local printing, calculado pelo Spool Server.
- Destination host: apenas para remote printing. Nome do servidor que tem o spooler do
SO.

Concept of Logical Spool Servers

Um Spool Server é um AS com pelo menos um Spool WP. Cada output request é
processado em um spool Server.
Um output device pode ser colocado diretamente em um spool Server, mas existem
vantagens de se usar um logical (spool) Server, como classificação (dev/PRD), load
balancing, etc.
A criação de um spool Server é feita na SPAD, guia Devices / Servers, escolhendo spool
servers. Informações importantes:
- Server Name: nome do spool Server, Max 20 caracteres;
- Server class: classificação (ex.: mass printing);
- Logical Server: para criar um logical Server;
- Mapping: nome de um real ou logical Server que este logical aponta;
Pode-se definir um spool Server apenas para front-end printing, através do parâmetro
rspo/local_print/server, apontando para o nome do servidor. Caso contrário, será usado o
servidor local (se tiver S WP) ou o com menor carga.

85
A classificação do output device pode ser feito via SPAD  Output Devices  Edit 
Classification).
Vantagens do logical Spool Server:
- Downtime security: utilizando um alternative Server, caso o normal não esteja
disponível, as requisições são direcionadas. O servidor alternativo pode ser outro logical
apontando para outros logicals, formando uma teia.
- Load Balancing: calcula o número de spool work process, output requests e pages,
entre o principal e o alternativo. Requisições seqüenciais têm prioridade sobre load
balance.
- Transporting the Print Landscape: os logical servers podem ser migrados entre
ambientes, sendo necessário apenas mapear os logical servers para os spool servers no
novo sistema.

Managing Spool Requests

Para manter spool e output devices, acessar transação SP01. Para apenas verificar o
status da sua própria requisição de spool, SP02.
É possível monitorar outros sistemas, colocando uma RFC válida no campo system
name. Caso o monitoramento remoto via RZ20 esteja configurado, basta deixar esse
campo vazio.
Status de uma spool request:
- : ainda não enviado ao sistema operacional;
+ : spool request sendo criada;
Waiting: ainda não processada pelo pool do sistema;
Proc.: Spool WP formatando a output request;
Print: sendo impressa pelo spooler do sistema operacional;
Compl.: output request impressa.
<F5>: output requests com vários status;
Problem: erro não sério, a requisição foi impressa;
Error: indica erro grave;
Time: um horário foi especificado para o output pelo seu criador.
A remoção de spool requests antigas é trabalho de administração do sistema;
Para remover spool requests antigas, agendar o programa ABAP RSPO1041 com uma
variant apropriada.
Para verificar a consistência do spool database, agendar o RSPO1043 com uma variant
apropriada com freqüência diária.
O SAP pode acessar um external Output Management System (OMS) via interface BC-
XOM, método de acesso “E”, interessante no caso de grande volume de processamento
ou compartilhamento com outros sistemas.
Desde a versão 4.0B, a saída de impressão pode ser enviada por e-mail (Acesso M).
Web Printing é possível via device type PDF1, desde a versão 4.6B. Via ITS, é exibido
um PDF para o usuário imprimir localmente.

Unit 12 – Structured Troubleshooting

Trace options
Existem dois tipos de trace: performance trace e system trace. Pode ser usado ainda o
developer trace e o system log para correção de problemas;
- System log SM21: detectar e corrigir erros no sistema e ambiente;
- Dump Analysis ST22: erros em runtime geram um short dump;

86
- System Trace ST01: atividades internas do SAP, como authorization check, acesso ao
banco, kernet e RFC;
- Performance Trace ST05: chamadas de: acesso ao banco, lock management, remote
cals…;
- Developer trace ST11: infomações técnicas sobre problemas internos.
System log
Se estiver usando sistema operacional UNIX, pode-se trabalhar com central logging.
SM21  System log  Choose  All Remote System Logs ou System log  Choose
 Central System Log.
No Expert Mode (Edit  Expert Mode) pode-se extender os critérios de pesquisa para
um terminal apenas.
Definição do path e nome de arquivo do log local e central:
- rslg/local/file: local log (ex.: SLOG<SAP_SYSTEM_NUMBER>);
- rslg/central/file: central log (ex.: SLOGJ).
Dump Analysis
Uma excessão não tratada gera um runtime error. Neste caso, o ABAP runtime finaliza a
execução do programa, gerando um short dump. Situações de erros podem ser:
- Internal Error: indentificado pelo error, contactar SAP;
- Installation and Enviroment/Resource Error: instalação incorreta ou recurso faltando
(ex.: shutdown);
- Error in Application Program.
Por default, short dumps são guardados por 14 dias. Short dumps podem ser removidos
(goto  Reorganize) ou salvos sem limite de tempo (Short Dump  Keep/Release).
SAP System Trace
Primeiramente usado caso um authorization trace deve ser criado. SAP recomenda o uso
de sytem log ou developer trace para analizar problemas.
Usado para:
- Authorization Checks: que permissões e quando são usadas;
- Kernel functions;
- Kernel Modules;
- DB Accesses (SQL Trace): quando e com que parâmetros as Open SQL são
transformandas em comandos SQL;
- Table buffers;
- Lock operations.
Exibe quando chamadas RFCs são feitas e na instância que são executadas.
Performance Trace
- Gravar chamadas ao banco;
- gravar gerenciamento de lock;
- buffers de tabelas;
- remote calls de reports e transações;
- análize detalhada de trace records;
- análize de comandos SQL.
Os traces não são escritos diretamente em arquivos, mas guardados antes em um buffer.
O parâmetro rstr/buffer_size_kB determina o tamanho deste buffer.
O arquivo de buffer é criado com nome de acordo com o parâmetro rstr/filename;
O arquivo de trace cresce até o tamanho de rstr/max_filesize_MB e então os mais
antigos são renomeados, adicionando 00 até 99, ou quantidade definida pelo parâmetro
rstr/max_files.
Developer Trace

87
Contém informações técnicas e é usado em caso de erros. Utilizado para investigar
problemas no SAP e servidor.
O Acesso pode ser feito via SO, AL11 ou SM50 (Process  Trace  Display File).

Unit 13 - Advanced User Administration Topics

Introduction to CUA
Usuários devem ser bloqueados, e não excluídos.
Obs.:
- Central deve ser 4.6C pra cima;
- Cliente pode ser 4.5B pra cima.
Logical System: sistema ligado um ao outro via ALE. No contexto do CUA, são os
clients envolvidos.

Setting UP a CUA
Passos:
Definir logical system na DB54;
Acessar SCC4 e definir o logical system no client;
No Server:
Copiar funções “SAP_BC_USR_CUA_SETUP_CENTRAL”,
“SAP_BC_USR_CUA_CENTRAL” e “SAP_BC_USR_CUA_CENTRAL_BDIST”,
adicionando “Z_” na frente e regerar os profiles;
Criar user “CUA_<SID>”.
No Client:
Copiar funções “SAP_BC_USR_CUA_SETUP_CLIENT” e
“SAP_BC_USR_CUA_CLIENT”, adicionando “Z_” na frente e regerar os profiles;
Criar user “CUA_<SID>_###”.
Configurar RFCs via SM59, RFC do tipo 3, nome igual logical system;
Na transação SCUA, criar nova e cadastrar todos os clientes (server);
Na transação SCUM, alterar modo de replicação (server);
Acertar company adress via SUCOMP, e replicar nos clients via SCUG;
Sincronizar usuários via SCUG;

User Administration with the CUA

Após o CUA habilitado, algumas diferenças:
- nova tab Systems: mostra os sistemas em que o usuário está cadastrado. Se removido
desta tela, remove do ambiente;
- Roles page: contém as roles do cliente. Executar o Text comparison para atualizar lista;
- Profiles: idem roles;

Introduction to Directory Services

Directory Services age como um repositório central de usuários.
As informações são gravadas de forma hierárquica (tree).
Acesso normalmente via LDAP, X.500 DAP ou DSML.
LDAP
Utiliza pilhas TCP/IP;
Contém entradas q são um ou mais atributos; atributos estão em Classes, que fazem
parte de um Schema.

88
Entradas estão organizadas em árvores (chamada Directory Information Tree – DIT), e
cada entrada possui um Distinguished Name (DN), que é criado descrevendo o caminho
do root da árvore.
SAP & LDAP
Na versão 4.0A foi disponibilizado o LDAP Gateway, programa instalado a parte.
Na versão 4.6A foi disponibilizado o LDAP Connector, integrado ao AS, interface entre
o AS e o LDAP Server.
Desde o Web AS 6.10 foram disponibilizadas funções para sincronização de dados.

Technical Connection of Directory Services

SAP usa RFC do tipo T (TCP/IP).
Se só existe um ambiente no servidor, usar RFC com nome LDAP_<SERVIDOR>, caso
tenha mais que um, utilizar LDAP_<SERVIDOR>-<SEQN>. Letras maiúsculas e sem
espaço.
Necessário registrar no gateway local (sapgw<instance number>).
Transação LDAP ou SPRO  SAP NetWeaver  SAP Web Application Server 
System Administration  Directory Integration.
Quando o Status do servidor LDAP é determinado como ativo no SAP, o CCMS
monitora frequentemente o status do LDAP.
Necessário usuário para acessar o LDAP (ou acesso anônimo). Esse usuário não
corresponde a usuário no SAP ou no Directory Server. O user pode estar cadastrado no
SAP, porém aqui é salvado um user diferente.
Após isto, configurar o Connection Data, com informações sobre o servidor LDAP.

89
TADM51
Unit 1 – Database Overview
Database Architecture
No sistema SAP, o único usuário que se conecta com o banco deve ser o administrador
de banco.
Terminologia:
- database: coleção de dados, logicamente tratado como uma unidade. Fisicamente os
dados são gravados em um ou mais datafiles em disco;
- instance: combinação entre os processos do Oracle (background) e os buffers de
memória. Uma database é associada a uma e somente uma instância;
- SGA: system global área, dados e informações de controle para uma instância do
Oracle;
- processes: processos background;
- system identifier (DBSID): cada banco de dados é identificado por um system
identifier. No SAP são 3 dígitos, sendo o primeiro caracter maiúsculo e os outros dois
caracteres maiúsculos ou números.
Na inicialização de uma instância Oracle, um processo chamado Listener é carregado e
abre um canal de comunicação pelo qual clientes podem se conectar com a instância.
Em um ambiente SAP, a configuração de dedicated Server é usada, o que significa que
para cada requisição de conexão do WP, o listener cria um Server process dedicado.
Cada Server process criado para o WP é chamado de shadow process.
Oracle Background processes realizam várias atividades para que o DBMS funcione
corretamente.
Dados são gravados em data files no disco. Para acelerar o acesso, os dados são
gravados em cache, no database buffer, na SGA.
O sistema trabalha as SQLs na Shared SQL área (ou chared cursor cachê), como parte do
shared pool na SGA. A outra parte do shared pool é o row cachê, que contém
informações sobre o dicionário do Oracle.
Os dados primeiramente são copiados do banco para o database buffer pelo shadow
process para depois ser usado pelo cliente.
A menor unidade lógica do Oracle é chamada de data block (tanto em disco quanto em
buffer):
- Durante a instalação do Oracle pode-se escolher qual o tamanho do bloco. No SAP é
sempre 8kb;
- Por questões de performance, recomenda-se formatar os file systems com 8Kb.
Alterações em dados são feitos sempre no buffer cache. O shadow process não copia
blocos modificados (dirty blocks) do buffer cache para o disco. Este é o trabalho do
database writer (DBW0), nas seguintes situações:
- quando o shadow process procura por blocos livres no buffer, e este número está
abaixo de um valor padrão, o shadow process inicializa o DBW0 que escreverá os dirty
blocks na lista dos menos recentemente usados no disco e liberará os blocos;
- em tempos específicos, o checkpoint process (CKPT) sinaliza ao database writer a
gravar todos os dirty blocks em disco.
Na maioria dos bancos, um processo DBW0 é suficiente, mas em alguns casos
adicionais database writer processes podem ser criados (DBW1, etc.).
Para garantir consistência nos dados e a leitura, Oracle mantém redo entries para
executar comandos e undo entries para roll back, em caso de crashes.

90
Redo entries contém dados necessários para refazer as modificações feitas no banco de
dados em uma transação efetivada. Redo entries contém novos valores, chamados after
images.
Em paralelo, shadow processes escrevem redo entries no redo log buffer, que contém
todas as entradas (commitadas ou não). O processo log writer (LGWR) escreve porções
do redo log buffer em online redo log files se:
- a transação é efetivada (LGWR coloca uma informação específica no arquivo);
- a cada 3 segundos;
- quando o redo log está 1/3 cheio;
- quando o DBW0 escrever dirty blocks no disco, mas esses ainda não foram para o
online redo log.
Quando uma transação sofre commit, é gerado um system change number (SCN), que é
gravado no redo log.
Undo entries contém informações para undo ou roll back, e suas entradas são chamadas
before images. Essas entradas estão separadas do redo log, em undo tablespaces ou
rollback segments.
Durante um recovery, Oracle primeiramente aplica todas as modificações do redo log,
para depois fazer o roll back das transações não efetivadas.
Redo log files possuem um tamanho fixado (no SAP 50Mb), e quando começa a ficar
cheio o LGWR fecha o arquivo e começa a escrever no arquivo seguinte, o que é
chamado de log switch. Cada log recebe uma numeração log sequence number (LSN).
Cada database possui um control file, que contém entradas que especificam a estrutura
física e o estado da base, como tablespaces, nomes e localizações dos data files e redo
logs, ou o LSN.
Control file é apenas alterada pelo Oracle, deve estar disponível para escrita quando o
banco é ativado e no SAP ele é espelhado em 3 lugares diferentes por segurança.
O termo checkpoint tem dois significados:
1) Evento em que todos buffers no buffer cachê são escritos nos data files, pelo DBW0:
O checkpoint process (CKPT) sinaliza o DBW0 copiar todos os dirty blocs para o
disco.
2) Posição no log que indica a partir de onde é necessário fazer recovery, usando o redo
log (dados anteriores já estão no data file). O Oracle lê a partir do control file o
checkpoint para recorvery.
O CKPT ainda atualiza os headers dos data files gravando os detalhes do checkpoint e
escreve a posição do checkpoint no online redo log.
Checkpoint ocorre a cada log switch e quando especificado em parâmetros do Oracle (no
SAP esses parâmetros não são usados, e o checkpoint apenas no log switch).
O recorvery na inicialização da base consiste de duas etapas:
- inicia a partir do checkpoint, refazendo atividades do redo log, incluindo mudanças na
undo space;
- atividades que sofreram roll back explicitamente antes do crash são reprocessadas e o
undo é garantido porque o Oracle não apaga entradas de transações abertas na undo
space.
Os redo logs devem ser espelhados, em duas ou mais cópias, e cada redo log deve estar
em discos separados. O Oracle trás essa característica e é usada na instalação do SAP
como default. Desta forma, não é necessário utilizar soluções externas.
Como o online redo log é limitado em tamanho e não pode crescer automaticamente,
Oracle deve sobrescrever redo logs antigos por novas entradas.

91
Para retornar uma situação antes do crash, normalmente é necessário além do backup
aplicar os online redo logs posteriores. Para evitar perda de dados, os online redo log
devem ser gravados em um local seguro, tarefa do archiver (ARC0).
Archiving deve ser explicitamente ativado, via parâmetro LOG_ARCHIVE_START to
TRUE.
Em ambientes produtivos este parâmetro deve ser ativado, e os offline redo log devem
ser guardados em discos espelhados (RAID).
Caso haja perda de offline redo logs e data files, um recovery completo não é possível.
System Monitor (SMON):
- executa o recovery quando a instância é inicializada (se necessário);
- escreve log de alertas se outro processo da instância falha;
- limpa segmentos temporários que não estão em uso.
Process Monitor (PMON):
- monitora os shadow processes;
- no caso de crash, faz roll back dos dados não comitados, para os shadow process e
libera recursos que os processos estavam usando.

A estrutura de diretórios no SAP é padrão (em todas instalações) e não deve ser alterada:
- dbs (UNIX) ou database (Windows): profiles de configuração do Oracle
(init<DBSID>.ora e spfile<DBSID>.ora e do BR*Tools (init<DBSID>.sap);
- sapdata<n>: data files;
- origlogA/B, mirrlogA/B: online redo logs 1 e 3 no A e 2 e 4 no B;
- oraarch: offline redo log files, no formato <DBSID>arch1_<LSN>.dbf;
- saptrace: usado para dump do Oracle. Oracle alert em saptrace/background e sadow
processes in saptrace/usertrace;
- saparch: logs do BRARCHIVE;
- sapbackup: logs do BRBACKUP, BRRESTORE E BRRECOVER;
- sapreorg: usado pelo BRSPACE para logs de diferentes atividades;

92
- sapcheck: usado pelo BRCONNECT para logs de diferentes atividades.
Variáveis de ambiente para usuários <SAPSID>adm e no Unix também o
ora<ORASID>:
- ORACLE_SID: system ID para a instância;
- ORACLE_HOME: diretório home do Oracle, que contém o Bin, DBS e network;
- SAPDATA_HOME: contém arquivos do banco de dados;
- no caso do Windows, se diretórios diferentes do SAPDATA_HOME são usados,
SAPARCH, SAPBACKUP, SAPCHECK, SAPREORG.
No Unix, ORA_NLS33 e LD_LIBRARY_PATH (ou LIBPATH no AIX, SHLIB_PATH
no HPUNIX.
Para melhoria de performance, aumento de carga e alta disponibilidade, o Oracle Real
Application Clusters (RAC) pode ser usado, provendo:
- processamento paralelo;
- load balancing;
- rápida e segura detecção de node ou network failure;
- fast recovery.
Para prover consistência de dados, o RAC coordena cada acesso da instância:
- o TNS (Transport Network Service) listener prove um load balancing entre todos os
nós;
- se adicionar um novo nó no cluster, o Oracle atualiza todos os arquivos de listener.
RAC requer que todos os nós acessem simultaneamente os discos compartilhados, e a
escolha do tipo depende do SO escolhido, como em file system ou raw devices. Porém o
uso de cluster file systems simplifica a instalação e administração dos RACs.
RAC também controla os buffers cachês de múltiplas instâncias em diferentes nós.
RAC também suporta as formas de backup e arquiving do Oracle single-instance.

Connecting to the Database

Para proteger o SAP, é necessário controlar usuários em três níveis:
- Sistema Operacional;
- Banco de Dados;
- SAP.
System privileges controla operações realizadas por um usuário em uma instância ou
database.
Object privileges controla operações em objetos, como select, update, etc.
Special system privileges SYSDBA e SYSOPER são oferecidos durante as conexões, e
de nenhuma outra maneira.
Usuários do sistema operacional membros do grupo dba ou ORA_DBA (ou
ORA_<SID>_DBA) podem conectar no banco com o privilégio SYSDBA. Membros do
grupo oper ou ORA_<SID>_OPER como SYSOPER.
System e objects privileges podem ser enfileirados em roles. A role mais importante é a
DBA, que contém todos privilégios necessários para administração. Porém, para
algumas atividades (como stop ou start), é necessário privilégio de SYSDBA ou
SYSOPER.
O SAP cria apenas a role SAPDBA, que provê acesso a certas tabelas para os SAP
Tools, como DBSTATC, SDBAD, etc.
Todas as instalações do Oracle contêm dois usuários administrativos: SYS e SYSTEM,
que possuem a role DBA.
SYS é o usuário mais poderoso no Oracle:

93
- todas as tabelas e views do data dictionary são guardadas no schema sys. Essas tabelas
são críticas para o Oracle, não podem ser alteradas ou novas tabelas criadas nesse
schema;
- SYS garante adicionais privilégios que a role DBA, e pode alterar qualquer dado no
banco.
SYSTEM é usado pelo Oracle para criar tabelas internas e views adicionais para exibir
informações administrativas. Não possui permissão para alterar tabelas do dicionário de
dados.
No SAP:
- SYSTEM recebe função SAPDBA para que o BR*Tools possam acessar certas tabelas
no schema SYS;
- SYSTEM é o usuário default quando se usa SAP tools para administração do Oracle.
Durante a instalação do SAP, é criado no banco um usuário SAP<SCHEMA-ID> (ou
SAPR3 até Basis 4.6D). Todas as tabelas do SAP são guardadas neste schema, porém o
usuário não possui direitos administrativos na database (não tem DBA ou SAPDBA).
Outros usuários criados no Oracle fazem uso do operating system authentication. Se:
- Usuário chamado OPS$<USERNAME> é criado na base, e <USERNAME> no
sistema operacional;
- parâmetro REMOTE_OS_AUTHENT=TRUE;
- parâmetro OS_AUTHENT_PREFIX=OPS$;
- usuário do SO só conseguirá se conectar no banco se for membro dos grupos dba ou
oper no UNIX, ou ORA_DBA, ORA_<SID>_DBA ou ORA_<SID>_OPER no
Windows.
Conexões AS SYSDBA garante full administration na database e na instance, com o
system privilege SYSDBA e os privilégios do usuário SYS.
Processo de logon do WP: conecta-se no banco com o OPS$ user  WP faz select na
tabela SAPUSER e lê o password para SAP<SCHEMA-ID>  WP disconecta do banco
e conecta de novo com o usuário SAP<SCHEMA-ID>.
Password do SAP<SCHEMA-ID> deve ser somente alterado via BRCONNECT.
Na rede, a comunicação é via TCP/IP e no topo, no software layer, o OracleNet (Oracle
Network Services). Na mesma máquina, o SAP usa o interprocess communication (IPC)
protocol Named Pipes.
OracleNet existe tanto no cliente quanto no servidor, e é responsável por estabelecer e
manter a conexão entre os dois, bem como controlar as mensagens entre eles, usando
protocolos padrões, como o TCP/IP.
Um processo chamado listener (OracleNet Listener) se encarrega de ouvir novas
conexões e ligá-las ao servidor. Após a conexão ser estabelecida, a comunicação passa
ser diretamente entre cliente e servidor.
Três arquivos são usados para essa configuração:
- listener.ora: configura o listener e é usado apenas no servidor. Contém todas entradas
dos sistemas Oracle que deverão aceitar conexões;
- tnsnames.ora: contem a lista de services names que podem ser acessados via rede;
- sqlnet.ora: pode conter informações do cliente, como domínio, traces, etc.
O utilitário lsnrctl é usado para parar e ativar o listener, bem como ver seu status. No
Unix é o processo tnslsnr, no Windows serviço Oracle<DBSID><Release>TNSListener.
Se várias instâncias são usadas em um único host, geralmente há apenas um listener com
todas entradas.
O listener pode ser pingado via utilitário tnsping <DBSID>.

94
Database Administration Tools
Administração do banco de dados Oracle pode ser feito via SAP administration tools,
chamados de BR*Tools. Estão no diretório /usr/sap/<SID>/SYS/exe/run e podem ser
usados em qualquer versão do SAP, a partir do Oracle 9i.
BRTOOLS é disponibilizado como uma interface baseada em caracteres, para os
programas BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRSPACE e
BRCONNECT. Além do BRTOOLS, existe o BRGUI, baseado em Java, que usa as
funções via BRTOOLS.
Tools:
- BRBACKUP: backup de data files, control files e online redo log files;
- BRARCHIVE: backup dos offline redo log files;
- BRRESTORE: restore de data files, control files, online e offline redo log files;
- BRRECOVER: tools interativo para restore e recovery;
- BRCONNECT: database administration: database check, update statistics, etc.;
- BRSPACE: database administration: instance management, space management e
reorganização;
Os tools são separados em programas funcionais e de ajuda, bem como batch e
interativos:
- Funcionais: executam atividades no banco de dados: BRBACKUP, BRARCHIVE,
BRRESTORE, BRRECORVER, BRSPACE e BRCONNECT;
- Help: BRTOOLS que oferece menus para navegação e BRTOOLS E BRCONNECT
são chamados por outros programas;
- batch: BRBACKUP, BRARCHIVE, BRRESTORE e BRCONNECT não possuem
menus próprios.
- interativos: BRRECOVER e BRSPACE (além do BRTOOLS) possuem seus próprios
menus, e podem ser chamados diretamente via prompt.
Símbolos no menu do BR*Tools:
Símbolo Usado em Significa
+ Control choise Ação está completada
- Control choise list Pode escolher ou executar essa opção agora
* Control input Não pode escolher ou executar agora
Exibição apenas, não é possível input
- Input Parâmetro pode ser alterado
~ Input Você pode alterar este parâmetro ou resetar
seu valor
Stop Todos Cancela o programa ativo
Help Todos Help específico
Back Todos Volta um menu
Continue Yes Todos Continua pro próximo menu ou passo
= Control list choise Valor automático se clicar em continue
? Input Um valor deve ser digitado
# Control input Não pode ser executado ou não pode ser
alterado.
A função chpass do BRCONNECT deve ser usado para alterar a senha do
SAP<SCHEMA-ID>.
A customização do SQL*Plus pode ser feita via comando “set <variável> <valor>”. Se
AUTOCOMMIT for OFF, o commit é realizado via comando “commit” ou quando é
desconectado do Oracle.
Transações para monitoramento e administração do banco:

95
- DB12: backup logs overview: resultado do backup e status do diretório de archives;
- DB13: DBA Planing Calendar: agendamento de backups e outros Jobs administrativos.
Caso use vários sistemas, pode-se usar a DB13C (central planning calendar);
- DB14: DBA Operations Monitor: logs de backup, update statistics, database checks;
- DB16: overview of database checks;
- DB17: manter os valores usados durante system check;
- DB20: manter estatísticas;
- DB21: parâmetros de geração de estatísticas;
- DB26: parâmetros do banco de dados;
- DB02: table and indexes Monitor: monitora o tamanho do BD, e o status dos objetos
do banco;
- ST04: Database Performance Monitor: mostra os indicadores mais importantes
(buffers, acessos de usuários, etc.) e a parametrização atual;
- RZ20: database alert monitor.
A DB13 é usada para agendar Jobs administrativos, como database check, backup,
adapting next extents e update statistics. São executados os Jobs DBA:*, com base na
tabela SDBAC.
A DB14 é usada para monitoramento diário, clicar em “all activities”. Para limitar por
data: Edit  Selection Options.

Administration of Oracle Instances

Durante o startup do banco, passa-se por três fases:
- NOMOUNT: o arquivo de parâmetros é lido, a instância é iniciada e os recursos
alocados no sistema operacional. Usado para criar a database e recriar control files
perdidos;
- MOUNT: os control files são abertos, informações da estrutura física são lidas, parte
do data dictionay é carregado. Usado para recovery, alteração do ARCHIVELOG,
renomear data files, adicionar, remover ou renomear online redo log files;
- OPEN: todos arquivos restantes são abertos, instance recovery é realizada (se
necessário).
Para inicializar via BRTOOLS: Instance Management  Start up database, ou brspace –
c force –f dbstart –s <state>. Para parar: Instance Management  Shut down database,
ou brspace –c force –f dbshut –m <mode>.
Tipos de shutdown:
- NORMAL: não aceita novas conexões, mas aguarda todos os usuários fazerem
logout. Padrão do Oracle;
- TRANSACTIONAL: não aceita novas conexões, aguarda transações atuais
terminarem, mas não executa novas transações;
- IMMEDIATE: não aceita novas conexões, não executa novas transações e faz roll
back das transações atuais. Padrão do BRSPACE;
- ABORT: não aceita novas conexões, não exeuta novas transações e cancela as
transações atuais, sem roll back. Requer recovery (automaticamente executado) no
próximo startup.
O arquivo de parâmetros de inicialização tradicionalmente era em formato texto, com
nome init<DBSID>.ora. a partir da versão 9i, pode-se manter em formato binário
(SPFILE), com nome spfile<DBSID>.ora, ou spfile.ora. SPFILE é totalmente suportado
a partir do BR*Tools 6.40 e a SAP recomenda usar SPFILE no upgrade para Oracle 9i.
Quando um parâmetro é alterado no SPFILE, um init<DBSID>.ora é gerado
automaticamente, permanecendo uma consistência entre eles. É recomendado criar e

96
guardar o SPFILE no local default do Oracle (ORACLE_HOME/dbs ou
ORACLE_HOME\database).
Quando uma instância é iniciada sem especificação de uma profile em particular, a
ordem de pesquisa é: spfile<DBSID>.ora, spfile.ora, init<DBSID>.ora, init.ora.
A inicialização com um spfile não padrão só é recomendado em casos emergenciais.
Para modificar parâmetros do Oracle, via BRTOOLS acesse Instance Management 
Alter database parameters. Digite diretamente o parâmetro que quer alterar, ou “c” para
continuar (pesquisa).
Mensagens de informação, warnings ou erros são gravados em dump files. Os locais são
definidos nos parâmetros:
- BACKGROUND_DUMP_DEST (padrão: /saptrace/background): log de alerta
(alert_<dbsid>.log), que loga eventos e mensagens de atividades, e traces em caso de
erros; e
- USER_DUMP_DEST (padrão: /saptrace/usertrace): traces escridos pelos shadow
processes, quando ocorre problema com a conexão do cliente.

Unit 2 – Backup, Restore & Recovery

Backup Strategy
A estratégia de backup deve ser adequada com as necessidades da empresa. Ela deve ser
testada antes do GO Live e sempre após mudanças na mesma.
O SAP oferece ferramentas para diferentes tipos de backup, como full online,
incremental com RMAN, split-mirror.
Devem-se manter pelo menos duas cópias dos offline redo logs em discos ou fitas.
Ao se fazer point-in-time recovery, é necessário voltar toda a base, para manter
consistência entre as tabelas. Desta forma, os dados entre o point-in-time e o momento
em que a base foi desativada serão pedidos. Desta forma, point-in-time não deve ser a
opção padrão para erros lógicos em produção. Pode-se ativar outra base com o backup e
copiar os dados manualmente.
O backup deve incluir verificação dos dados a sofrerem backup, bem como os dados nas
fitas.
Para verificar consistência no banco, um system check deve ser executado para
descobrir data blocks corrompidos:
- Corrupt Oracle blocks (erro ORA-1578) podem aparecer no banco devido erros de
sistema operacional ou hardware;
- Sem o check, os corrupt data blocks serão encontrados apenas no acesso aos mesmos;
- base com corrupt data blocks sofre backup, porém o mesmo não pode ser usado.
O check é recomendado uma vez por semana.
Para verificar as fitas usadas pelo backup, executa-se o physical data check. Durante
este check, as fitas são lidas e se a conexão com os dados é possível.
No Offline backup, pode-se fazer um check para ver se os binários da fita são iguais aos
do banco. Isto requer que a base fique desativada enquanto isso.
No backup online, apenas verifica-se se os arquivos nas fitas podem ser lidos.
Um cliclo de backup é o tempo em que o backup fica em fita.
SAP recomenda o ciclo de backup de quatro semanas. O ciclo de backup do banco e dos
offline redo logs deve ser o mesmo:
- backup completo online todo dia útil;
- backup completo offline uma vez no ciclo;
- backup dos offline redo logs todo dia útil, bem como após backups online e offline.
Gravar os offline redo logs em duas fitas diferentes antes de apagar do disco;

97
- fazer um logical check antes ou após o backup e pelo menos um physical check no
ciclo (recomendado uma vez por semana);
- retirar a fita do último backup offline do ciclo e guardar. Substituí-la por uma nova.
A freqüência de backups completos se dá ao ponto de ter vários backups deste tipo
disponível. Desta forma, evita-se perda de dados caso o último backup não esteja
disponível.
Executar backups adicionais após reorgs e upgrades, e guardar esses backups em long-
term storage.
O SAP usa dois programas para backup: BRBACKUP para backup e BRARCHIVE para
offline redo logs. Desta forma, duas filas de fitas são necessárias e só poderão ser
reusadas após o término do ciclo de backup.
Se os dois backups forem feitos ao mesmo tempo, são necessárias duas fitas, ou seja, não
é possível guardar na mesma fita duas execuções de backups.
A quantidade de fitas necessárias é:
- backup do banco: número de fitas necessárias para um backup completo e número de
backups por ciclo;
- backup de offline redo logs: média do número e tamanho dos offline redo logs e
capacidade das fitas.
Os backups padrões da DB13 (Whole database offline + redo log backup e Whole
database online + redo log backup) faz o backup do banco e offline redo logs em uma
execução. Desta forma, não é necessária duas filas de fitas, bem como os dois podem ir
para uma fita apenas (se couber).
É recomendado um acréscimo de 30% no número de fitas esperadas por ciclo, para caso
de crescimento inesperado de banco ou offline redo logs.
Tipos de backup:
- Offline: o banco é parado antes do backup e os data files são copiados. Desta forma,
não é necessário restaurar offline redo logs;
- Online: o banco continua aberto durante o backup, então modificações podem ocorrer
e é necessário aplicar offline redo logs após o mesmo.
- Backup completo:
- full (via RMAN): salva toda a base e o catálogo são salvos no control file,
permitindo posterior backup incremental;
- whole: toda base, porém não salva informações do catálogo.
- Incremental Backup: backup somente dos data blocks modificados após último full.
Todos os data blocks são lidos, então o tempo pode não ser reduzido:
- só pode ser executado após um full;
- controlado via RMAN;
- via SAP tools, apenas acumulativo é suportado (é feito com base no último
full);
- via SAP tools, apenas o backup de todo banco é possível, não dá para
selecionar apenas alguns data files;
- Backup parcial: backup de apenas algumas partes do banco.
A estratégia de backups pode conter backups incrementais ao invés de completos,
economizando tempo de backup. Para recovery da base, é necessário o último full,
restore do último parcial e os redo logs.

Backup Tools and Tape Management

O BRBACKUP faz backup dos data files, control file e online redo log, se necessário. É
usado para backup do diretório do banco e do SAP.
O BRARCHIVE faz o backup dos offline redo logs;

98
O BRRESTORE pode restaurar todos os arquivos do banco de dados: data files e offline
redo log.
O programa interativo BRRECOVERY verifica se arquivos do banco estão faltando,
chama o BRRESTORE para restauração, executa o recovery e abre o banco.
O BRBACKUP e o BRARCHIVE gravam as ações em arquivos de logs, que são
analisados pelo BRRESTORE para restauração de arquivos inexistentes.
O arquivo de configuração init<DBSID>.sap contém parâmetros para os BR*Tools.
Itens mais importantes:
- backup_mode: escopo do backup (all, full, incr...);
- backup_type: offline ou online;
- backup_dev_type: mídia do backup (tape, disk);
- tape_copy_cmd: comando de cópia (cpio, dd  recomendado, mais rápido que cpio);
- disk_copy_cmd: comando de cópia para discos locais;
- expir_period e tape_use_count: data de expiração da fita e quantidade de vezes que ela
pode ser sobrescrita;
- volume_backup e volume_archive: nome dos volumes para backup e archives;
- tape_adress: endereço do drive de fitas.
O Oracle Recovery Manager (RMAN) é o programa padrão para backup e restore.
O BRBACKUP suporta o RMAN para backup de duas diferentes formas:
- classificar um backup como completo (level 0) que servirá como base para um
incremental (level 1);
- dados podem ser escritos em fitas via RMAN, ao invés de comandos CPIO e DD.
Se o backup é levado para fita via RMAN, este deve ser usado para restore e recovery,
fato q é detectado pelo BRRECOVER. Caso este encontre algum problema, é necessário
fazer o restore manualmente.
Para copiar para a fita via BRBACKUP, escolha tape_copy_cmd como CPIO ou DD.
Para deixar o controle com o RMAN, colocar valor rman.
No caso do RMAN, na última etapa, o backup_mode é setado para full, RMAN escreve
informações no control file e o CPIO copia o control file para a fita.
O RMAN copia diretamente para disco, mas não para fita. Nete caso, ele necessita de
uma biblioteca System Backup to tape (SBT), provida pela Oracle e que cada fabricante
de fitas deve prover uma biblioteca. Antes de usar backup com RMAN, a biblioteca deve
ser instalada:
- caso não a tenha, o SAP instala automaticamente em /SYS/exe/run;
- para usar um utilitário de backup externo, deve ser instalada a biblioteca SBT do
mesmo. Oracle trás uma versão limitada single-server do Legato Networker. Para usar
setar backup_dev_type para rman_disk ou rman_util.
Vantagens de usar o RMAN:
- todos blocks são verificados, procurando blocos corrompidos. Neste caso, o backup é
consistente e futuros checks não são necessários;
- apenas blocos usados são gravados (mesmo vazios, se já foram usados);
- durante backups online, a tablespace é configurada para modo de backup, para evitar
inconsistência.
A partir do Web AS 6.10, RMAN também pode ser usado no BRARCHIVE, o que
garante verificação interna de consistência nos offline redo logs.
Quando se usa o RMAN, a biblioteca de backup SAP provê uma forma de otimizar o
uso de fast tape drives, combinando vários data files em save sets. Neste caso, vários
data files são lidos ao mesmo tempo, maximizando o fluxo de dados no modo streaming.
Cada save set contém um header, um trailer e os blocos de pelo menos um data file.
O parâmetro saveset_members, dentro do init<SAPSID>.sap permite os valores:

99
- 1,2,3,4: número de files que podem ser agrupados (default: 1);
- tsp: um save set por table space;
- all: um save set com todos data files.
Usar save sets grandes ajuda a acelerar o backup, porém tem a desvantagem do
restore/recovery se tornar mais lento. Todo o save set deve ser lido da fita.
Backups para disco via RMAN (backup_dev_type = disk e disk_copy_cmd = rman),
nenhum save set é formado. Data files são copiados diretamente para disco, como no uso
dos comandos CP ou DD. Em outras palavras, uso de save sets só é possível quando uma
SBT library é usada para backups incrementais.
Se um backup via RMAN criará save sets com mais de um membro (saveset_members >
1) ou se usa tape stations com compressão e se quer levar em consideração a compressão
para calcular o tamanho do save set, deve-se executar uma preparação para determinar a
distribuição otimizada de tape sets. Esta preparação é executada via DB13  Prepare for
RMAN Backup.
Neste caso, o BRBACKUP inicializa o RMAN para backup dos data files. Nenhum
backup é feito nesta etapa, o BRBACKUP apenas comprime os arquivos para estimar a
taxa de compressão.
O BRBACKUP determina quais data files são alocados nos save sets para cada valor
possível do saveset_members, e calcula a taxa de compressão de cada save set. As
informações de compressão e composição do save set são gravados no banco, para
futuras utilizações. Essas informações não podem ser alteradas manualmente, apenas via
uma nova preparação.
Se durante um backup o RMAN identifica um data file não incluído na última
preparação de execução, um novo save set é criado.
É recomendado executar a preparação uma vez por ciclo, e após grandes modificações
no banco.
Um backup incremental é sempre um backup de todo o banco de dados, não de um
individual data file. Ferramentas de sistema operacional não podem ser usados para
cópia para fita, os parâmetros tape_copy_cmd ou disk_copy_cmd são ignorados e
implicitamente alterados para rman. Após, completado o backup incremental, o control
file é copiado para fita via CPIO.
Apenas um save set “.INCR” é criado, uma vez que o parâmetro saveset_members é
internamente setado para all. Desta forma, o backup pode ser feito em apenas uma fita.
Se um data file foi criado entre o backup full e o incremental, um backup nível 0 é
executado antes do início do backup nível 1. Todos novos data files são gravados em um
novo file set “.FULL”.
A volta de backup neste caso se dá em três passos:
- volta os data files do backup nível 0;
- os blocos alterados do backup de nível 1 podem ser importados no data file;
- finalmente um recovery deve ser executado, do horário em que o backup nível 1 foi
feito.
Para facilitar a utilização de fitas para backup, o BRBACKUP e BRARCHIVE oferece
um tape management system que:
- ajuda a encontrar a fita correta para o backup;
- ajuda a encontrar as fitas corretas para restore e recorver;
- provê proteção às fitas contra sobrescrição acidental.
Um pré-requisito é que se tenha duas filas de fitas: uma para BRBACKUP e outra para
BRARCHIVE.

100
Durante a inicialização da fita, um arquivo é gravado primeiramente (.tape.hdr0),
contendo o nome do volume. Pode ser especificada manualmente ou o
BRBACKUP/BRARCHIVE seleciona da lista de nomes definidos no init<DBSID>.sap.
Para inicializar tapes: BRTOOLS  backup and database copy  additional functions
 initialization of BRBACKUP (ou BRARCHIVE) tape volumes.
Opções:
- Initialize: rename (default)  só pode ser inicializada após tempo de retenção; force 
inicializa mesmo assim; show  exibe label;
- Number: número de fitas a serem inicializadas (zero = todas);
- Volume: nomes das fitas a serem inicializadas. Caso vazio, serão inicializadas as
especificadas no init<DBSID>.sap.
Após inicialização, a tape label contém o nome da fita, o nome da base que sofreu
backup, o timestamp do último backup e o número de backups realizados por essa fita.
Se o nome da fita está incorreto ou a fita está bloqueada, um erro é reportado. Se foi
usada mais que o número de vezes especificado, um warning é gerado.
No início do backup, o BRARCHIVE/BRBACKUP escreve o timestamp no header da
fita. Adicionalmente, quando cada database file sofre backup com sucesso, informações
sobre ele são escritas em um log (summary log e datailed log) e nas tabelas SDBAH e
SDBAD. Desta forma, as ferramentas usam dois métodos de controle para verificar se a
fita está bloqueada:
- Physical lock: lê o tape label e verifica se o timestamp é maior que o expir_period
(init<DBSID>.sap);
- logical lock: lê o timestamp das tabelas SDBAH e SDBAD, a última fita usada e que
não está no período de lock, é usada para o backup.
Se o backup é finalizado antes que o primeiro arquivo possa ser gravado na fita, o
volume é bloqueado fisicamente, mas não logicamente. Desta forma, deve-se fazer uma
nova inicialização (force) da fita para cancelar o lock.
Se um volume for reinicializado com force antes do período de expiração, o volume não
está bloqueado fisicamente, mas logicamente. Desta forma, deve-se fazer o próximo
backup com um volume chamado SCRATCH.
Para permitir o BRBACKUP e BRARCHIVE escolherem a fita a ser usada de forma
automática, os parâmetros volume_backup e volume_archive devem estar preenchidos.
Além disto, não se deve especificar um volume na execução do backup (batch ou
agendamento).
Para verificar a próxima fita a ser usada, escolher um backup na DB13 e Goto  Tapes
needed. Via SO brbackup|bararchive –q|-query. Acrescentando parâmetro “check”, é
realizado um physical tape check.
Para executar um backup com qualquer fita, deixar o nome em branco.
Executar um backup com um nome simbólico scratch desliga o gerenciamento
automático de fitas. O BRBACKUP/BRARCHIVE faz apenas uma verificação de um
physical lock. Pode ser usado, por exemplo, para criação de um backup mensal e não
quer que ele seja gravado no pool de fitas.
Executar um backup com um volume simbólico scratch, a próxima fita será renomeada
para a requisitada.
Lembrar:
- volume = scratch: qualquer fita inicializada sem lock físico;
- sem especificar volume name, mas uma fita com nome scratch, ela será renomeada
para o próximo volume.

101
Para especificar uma fita a ser usada, especifique o nome na opção “volume” no
BRTOOLS, ou opção –v|-volume <volume> no prompt. O physical tape check será
realizado da mesma forma e fitas locadas são rejeitadas.
Arquivos escritos pelo BRBACKUP e BRARCHIVE:
- .tape.hdr0: tape label;
- init<DBSID>.ora: arquivo de configuração do banco;
- init<DBSID>.sap: arquivo de configuração do BR*Tools;
- space<DBSID>.log: informação da criação, extensão ou reorganização de tablespaces
ou tabelas (diretório sapreorg);
- struc<DBSID>.log: histórico de mudanças estruturais no banco (diretório sapreorg);
- <action_ID>.<function_ID>: log completo do BRBACKUP/BRARCHIVE;
- back<DBSID>.log: sumário do BRBACKUP, lista de todos backups inicializados pelo
BRBACKUP (diretório sapbackup);
- arch<DBSID>.log: sumário do BRARCHIVE, lista de todos offline redo log files que
sofreram backup pelo BRARCHIVE (diretório saparch).
Os parâmetros tape_size e tape_size_arch especificam o tamanho da fita em GB, MB ou
KB. Se o tape_size_arch estiver em branco, o valor é igual a tape_size.
No início do backup, o BRBACKUP/BRARCHIVE verifica o tamanho total dos
arquivos e planeja a distribuição nas fitas. Os arquivos nunca são quebrados, sempre são
gravados em uma parte. Desta forma, o tamanho do maior arquivo (ex.: datafile) não
pode ser maior que o especificado em tape_size.
Os valores de tape_size e tape_size_arch devem ser menores que o valor da fita, uma vez
que outros arquivos são copiados (ini files, logs, CPIO file headers). É recomendado
deixar 10% do tamanho livre.
Quando os arquivos são copiados para uma fita, não é verificado o espaço livre na
mesma. O BRBACKUP chama outra fita e continua o backup.
Já no BRARCHIVE, são copiados apenas os offline redo logs que cabem em uma fita.
Caso o tamanho total exceda o parâmetro tape_size_arch, é necessária uma nova
execução do BRARCHIVE.
Com o parâmetro de inicialização “compress”, pode-se especificar quais arquivos serão
comprimidos ou se compressão por hardware será levado em consideração quando
planeja a distribuição dos arquivos em fitas:
- compress=no: compressão por software não é usado. Compressão por hardware não é
levado em conta;
- compress=yes: junto com parâmetro compress_cmd e compress_dir, indica que haverá
compressão por software;
- compress=hardware: compressão por hardware deverá ser levado em conta (não ativa,
apenas informa). Neste caso, tape_size contém o tamanho total de arquivos após
compressão.
No caso de compressão por hardware, BRBACKUP apenas estima a taxa de
compressão. BRARCHIVE não usa compressão (1:1).
Antes do backup com compressão por hardware, e uma vez por ciclo ou quando houver
reorganização do banco, é necessário executar um copression run para determinar a taxa
de compressão. Via DB13  compress database ou brbackup –k only.
Como o valor de compressão pode variar e é apenas estimado, é recomendado usar o
tape_size para um valor bem menor que o real, para evitar chegar ao final da fita.
Para reduzir o risco na compressão por hardware, pode-se usar compress=no e tamanho
da fita 2x o tamanho real, uma vez que a compressão geralmente é maior que 2:1.
Os tools BRBACKUP, BRARCHIVE, BRRECOVER e BRRESTORE podem utilizar
uma interface chamada BACKINT para acessar programas externos de backup.

102
Vantagens:
- Pode-se usar mídias de backup específicas de um fabricante, como robôs e magnet-
optical media;
- pode-se fazer um backup consistente de file systems e banco de dados;
- client/Server backup configuration permite uso de backup Server.
De qualquer forma, o backup deve ser inicializado via SAP tools, para manter logs
atualizados, monitoramento via CCMS e permitir restore/recover via BRRECOVER.
Para configurar uma interface BACKINT, atribua ao parâmetro backup_dev_type para
util_file ou util_file_online (coloca tablespace em backup mode) no init<DBSID>.sap e
altere o parâmetro util_par_file para o arquivo de configuração do utilitário de backup.
Para usar com RMAN, colocar backup_dev_type como rman_util, rman_disk ou
rman_stage.

Performing Backups
O backup deve incluir todos objetos, como sistema operacional, arquivos do SAP e do
software do Oracle. Geralmente sofrem backup via sistema operacional, uma vez por
ciclo.

Via RMAN as tablespaces não são colocadas no backup mode, uma vez que ele garante
a integridade dos data blocs.
Ordem de prioridade de parâmetros: command line/job/menu, depois arquivo
init<DBSID>.sap, depois valores default. Não há transação SAP para alterar o
init<DBSID>.sap.
A forma recomendade de backup é via DB13, onde backups são agendados e executados
na forma de Jobs (podem ser monitorados via SM37).
Outra forma é agendamento via utilitário no sistema operacional (Cron/ task scheduler).
Em casos excepcionais, pode ser executado via BRTOOLS.

103
Uma vez que o backup foi reportado como com sucesso, não quer dizer que ele está livre
de erros. Para verificar:
- Tape verification: verifica se o backup é passível de leitura, os arquivos são restaurados
um a um e comparados com o original;
- Databese block consistency: utilitário do Oracle DBVERIFY. Verifica bloco a bloco se
estão consistentes. Caso contrário, deve-se voltar do backup.
O offline redo log possui vários status durante a cópia para fita:
- ARCHIVE: ainda não copiado;
- SAVED: copiado para uma fita;
- COPIED: copiado para segunda fita;
- DELETED: após deleção.
Durante cópia para disco:
- DISK: ainda não copiado;
- DISKSAV: savo em disco;
- DISKDEL: deleção após salvo em disco.
O parâmetro aconselhado para o BRARCHIVE (default na DB13) é –cds
(copy_delete_save), que copia por uma segunda vez os redos com status SAVED e então
apaga do disco. Redo com status ARCHIVE são sempre copiados para fita.
Para definir “one-run strategy” de backup, escolha a opção –a|-archive do BRBACKUP.
Depois dessa seleção, opções do BRARCHIVE serão apresentadas.
Consistent online backups é executado via comando brbackup –t online_cons, e é
inteiramente regido pelo BRBACKUP. Após a cópia de todos data files, é executado um
log switch e o offline redo log gerado é copiado para a mesma fita, sem intervenção do
BRARCHIVE. Ao término, summary e detail log são copiados.
Normalmente é executado para salvar em long term tapes e recomendado antes de
upgrades.
Para verificar os logs dos backups:
- DB14: DBA operations: logs de todas atividades de DBA;
- DB13: DBA Planning Calendar: de acordo com a cor da execução:
- DB12: apenas logs de backups, relatório de recover, status do diretório de archive e
overview dos archived redo logs.

Restore and Recovery

Oracle cria sincronização usando timestamps. Timestamps são inteiros incrementados
por certos eventos, como logwriter e checkpoint. Ex.: log sequence number (LSN) a
cada log switch e system change number (SCN) a cada commit e checkpoint.
Para analisar problemas no banco, verificar o alert log e trace files no diretório
/saptrace/background.
Faça um backup completo offline do banco corrompido antes de restaurar o backup. Isto
é recomendado principalmente em point-in-time recovery ou database reset, que envolve
perdas de dados. Da mesma forma, fazer um backup dos offline redo logs.
Para testar a realidade da estratégia de backup, execute o Recovery report na transação
DB12. Ele contém informações que podem ser usadas em caso de recovery.
O report informa o último backup com sucesso, incluindo o tipo de backup e o nome da
fita, qual backup deve ser usado para recovery e quais redo log files estão disponívels.
O report também ajuda a detectar gaps nos backups:
- redo log files que estão faltando;
- se a lista de redo logs está grande, o tempo de recovery pode se tornar muito longo.
Complete Database Recovery: usado para restaurar data files que estão faltando, e para
restaurar a base até o status imediatamente anterior ao erro ocorrido.

104
Para sincronização, o Oracle utiliza informações salvas nos cabeçalhos dos arquivos. O
banco requer todos os offline redo log files desde o último database file.
Com o complete database recovery, todas as alterações são feitas novamente, desde que
todos os arquivos tenham o mesmo SCN. Este procedimento é chamado de media
recovery.
Para realizar um Complete Database Recovery com o Brtools, acesse Restore and
recovery  complete database recovery. Fases:
1) Check the status of database files: verifica o status de todos os arquivos do banco,
com ajuda das views V$, e escreve os logs no diretório sapbackup;
2) Select database backup: BRRECOVER determina os backups utilizáveis (código de
retorno 0 ou 1) via log back<DBSID>.log. Data files ausentes podem ser
recuperados de vários backups. Um backup incremental pode ser escolhido antes de
aplicar os offline redo log files. Neste caso, o BRRECOVER escolhe o backup full
correspondente.
3) Restore data files: BRRECOVER chama o BRRESTORE para restaurar os arquivos
para o local de origem (o diretório sapdata não é criado automaticamente, mas os
sub-diretórios sim);
4) Restore and apply incremental backup: se existir backup incremental, é aplicado
nesse ponto;
5) Restore and apply archive logs: com base no arch<DBSID>.log, a lista de offline
redo log files é montada. BRRECOVER chama BRRESTORE para restaurar os
archivos da fita para o diretório oraarch. Finalmente o BRRECOVER chama o
SQL*Plus para aplicar os offline redo log files. Eles são aplicados em grupos de 100.
6) Open database: BRRECOVER ativa a base e verifica o status dos arquivos e
tabespaces.
Point-in-time Recovery: usado para restaurar a base a em certo horário, com a ajuda de
um backup completo.
Point-in-time recovery sempre resulta em perda de dados. Quando a base é ativada, é
usado o comando ALTER DATABASE OPEN RESETLOGS, o que reinicia os
contadores de LSN. Desta forma, deve-se fazer um backup full antes de liberar para uso.
O point-in-time pode ser usado para toda base ou só para umas tablespaces específicas
(ex.: usando MCOD).
Para executar via BRTOOLS, acessar Restore and recovery  Database point-in-time
recovery. Fases:
1) Set point-in-time for recovery: LSN, SCN ou horário específico;
2) Select database backup: BRRECOVER determina os backups utilizáveis (código de
retorno 0 ou 1) via log back<DBSID>.log. Data files ausentes podem ser
recuperados de vários backups. Um backup incremental pode ser escolhido antes de
aplicar os offline redo log files. Neste caso, o BRRECOVER escolhe o backup full
correspondente.
3) Check the status of database file: BRRECOVER verifica status de todos os arquivos
e determina quais serão sobrescritos;
4) Restore control file: se necessário;
5) Restore data files;
6) Restore and apply incremental backup: se selecionado anteriormente;
7) Restore and apply archivelog files: BRRECOVER verifica no arch<DBSID>.log os
offline redo log files necessário, chama o BRRESTORE para copiar da fita para o
oraarch e chama o SQL*Plus para importar no banco.

105
8) Open database: abre o banco com opção RESETLOGS, cria arquivos temporários
que estão faltando, verifica o status dos data files e tablespaces e remove arquivos
desnecessários.
Whole Database Reset: usado para restaurar a base para o momento imediatamente
após o backup completo. Como o point-in-time recovery, database reset resulta em perda
de dados.
Para executar via BRTOOLS, acessar Restore and recovery  Whole database reset.
Passos:
1) Select consistent database backup: BRRECOVER determina backups que podem ser
usados, com base no back<DBSID>.log. Se escolher um backup incremental, o
backup full correspondente é escolhido para restaurar todos data files;
2) Restore control files and redolog files: sempre restaurados se um backup online é
escolhido;
3) Restore data files;
4) Apply incremental backup: se escolhido;
5) Apply archivelog files: se escolhido online backup;
6) Open database: ativa o banco (se necessário com RESETLOGS), cria arquivos
temporários que possam estar faltando, verifica o status dos data files e tablespaces,
deleta aquivos desnecessários
Disaster Recovery: usado quando não houver arquivos de controle e profiles de
configuração. Pré requisitos: SAP e Oracle instalados, file system sapdata existe e
configurado como antes do disaster.
O disaster recovery é apenas um step anterior. O recovery é feito via point-in-time ou
whole database reset.
Para realizar o disaster database recovery, via BRTOOLS Restore and recovery 
Disaster recovery.
Após restaurar o init<DBSID>.sap, o back<DBSID>.log é restaurado e o sistema
conhece através de quais backups fará o restore.
Outros profiles e logs podem ser restaurados através de uma lista. Na maioria dos casos,
não é necessário mudar a seleção default, uma vez que o BRRECOVERY já determina
quais arquivos devem ser restaurados.
Na próxima seleção, Restore of BRBACKUP detail logs, a lista de backup detail logs é
exibida para restore.
Outras funções do BRRECOVER, não tratadas aqui são:
- Restore of individual backup files: restaurar um arquivo de backup para restauração
manual;
- Restore and application of archivelog files: para recovery manual.

Advanced Backup Techniques

Algumas técnicas podem melhorar a estratégia de backup, mas em compensação exige
esforços como:
- Hardware;
- Treinamento dos administradores;
- Aumento na administração do ambiente.
Split-mirror Disk Backup: algumas alterações são necessárias no init<DBSID>.sap e o
BRBACKUP do servidor espelho deve enchergar o servidor de produção.
Online: tablespaces em backup mode  quebra do espelhamento  produção sai do
modo backup  online backup no espelho  resincronização.
Offline: shutdown do banco  quebra do espelhamento  inicialização da base de
produção  offline backup no espelho  resincronização do espelho.

106
SAP Tools and the Oracle Standby Database: o banco de dados de produção fica
aberto, porém o standby em “mount” e frequentemente recebe os offline redo log files
do de produção. No caso de falha do Server, este pode ser usado como produção.
O backup é feito na base standby via BRBACKUP, backup_type = offline_standby, com
ações registradas na SDBAH e SDBAD do servidor de produção, além do diretório
sapbackup (devem estar acessíveis do standby Server). O BRARCHIVE roda nos dois
servidores, sendo no Server colocando os archives em disco, e no standby lendo do
oraarch e jogando em fita. Os redo são aplicados com a opção “-m | -modify <delay>”,
onde delay é o tempo para atualização.
Structure Retaining Database Copy: usado para criar uma base com outro DBSID no
mesmo servidor, ou outra base com mesmo ou diferente DBSID em outro Server.

Unit 3 – Monitors and Tools

Introduction to Oracle Data Management
Segment contém dados de uma tablespace. Existem 4 tipos de segumento:
- Data;
- Index: usado para acelerar o acesso e forçar unique constraint;
- Temporary: usado para sorts e criação de índices;
- rollback/undo: prover consistência, roll back ou undo e para recovery.
Qualquer seguimento é guardado em uma tablespace, mas pode estar em vários data
files.
Para atender a demanda de bancos grandes, as tabelas e índices podem ser particionados,
o que permite que dados possam ser quebrados em pedaços menores e mais maleáveis.
Cada partição é guardada em seu próprio segmento, e gerenciada manualmente. SAP
recomenda utilizar a mesma tablespace original.
No SAP, um segmento possui todos os dados de uma tabela ou todos dados de uma
partição de uma tabela particionada.
Até a versão 4.6C, as tablespaceses eram divididas em system, rollback, temporária,
dados por tipo de tabela (dados, máster data, pool, logs, etc.) e índices por tipo de tabela.
As vantagens eram: data files poderiam ser guardados em discos diferentes (dependendo
do uso) e a reorganização poderia ser feita em unidades menores. As desvantagens eram
o aumento do trabalho de organização e baixa efetividade do armazenamento.
A partir do AS 6.10:
- SYSTEM: Oracle Data Dictionary;
- PSAPROLL ou PSAPUNDO: rollback/undo;
- PSAPTEMP: segmentos temporários;
- PSAP<SCHEMA-ID>: objetos ABAP;
- PSAP<SCHEMA-ID>USR: customer objects;
- PSAP<SCHEMA-ID><REL>: dados dependents da release;
- PSAP<SCHEMA-ID>DB: objetos do AS Java (AS 6.40 e mais novos).
Através deste desenho, é possível utilizar o MCOD, pois além do desenho da tabela, a
substituição do usuário SAPR3 por SAP<SCHEMA-ID> foi incorporada.
Definições:
- SAP SID: identificador do SAP System;
- Database SID: identificador do banco de dados, pode ser diferente do SAPSID;
- Schema ID: usado como identificador de parte de tablespace e do user SAP.
Se MCOD não é usado, todos IDs devem ser iguais. Se é usado, o segundo SAP System
deve ter um SCHEMA-ID diferente do DBSID.

107
O MCOD pode ser usado a partir do 4.6C SR2, e o BR*Tools pode ser usado em
qualquer tipo de layout de tablespace (e sempre suportará).
Convensões para os data files:
- criado no diretório sapdata<n>, onde <n> é número da divisão da tablespace;
- possui o nome da tablespace, sem PSAP e com final .data<n>.
Se uma tablespace está cheia, três saídas podem ser adotadas:
- criar um novo datafile;
- data file pode ser aumentado;
- o data file pode ser alterado para autoextensible. Ele crescerá até MAXBYTES em
intervalos de INCREMENT_BY.
Como o tamanho da base não é importante (salvo sistemas 32 bits), o número de data
files deve ser em torno de 100, quando a base está no tamanho esperado. Neste caso,
será múltiplos de 2Gb, sendo tamanho máximo/100:
- Até 200Gb de banco: 2Gb por data file;
- De 200 a 400Gb: 4Gb por data file...
RAW devices são somente suportados em UNIX, e nesse caso o Oracle vai gerenciar o
uso do disco. No uso de RAC, deve-se usar um cluster file system ou um RAW device,
uma vez que existem várias instâncias acessando o mesmo datafile.
Vantagens do RAW: I/O mais rápido, um pouco menos de espaço requerido, recovery
mais rápido.
Desvantagens do RAW: deve ser bem documentado, apenas um data file por raw device,
backup somente via RMAN ou dd (ambos suportados pelo BR*Tools).

Data-dictionary tablespaces eram usados no formato antigo de tablespaces, mas a SAP

recomenta a conversão para gerenciada localmente (possível via reorganization).
Cada segmento é formado por um ou mais extents (coleção de blocos alocados
sequencialmente). O Oracle verifica e atualiza o dicionário de dados sempre que precisar
alocar um novo extent. O tamanho do extent e outros parâmetros são chamados de
storage parameters, e são guardados do dicionário de dados.
Esses parâmetros são configurados na criação da tablespace, e podem ser sobrepostos na
criação de uma tabela ou alterado via BR*Tools para as tabelas existentes:
- MINEXTENTS: quatidade de extents alocados na criação da tabela;
- INITIAL: tamanho do extent inicial;
- NEXT: tamanho dos extents criados quando os anteriores estão cheios;
- PCTINCREASE: não usado no SAP. Porcentagem maior do anterior a ser criado;
- MAXEXTENTS: quantidade máxima de extents que podem ser criados.
Desvantagens deste tipo de alocação de espaço:
- deve haver área livre contínua maior que o NEXT. Pequenas áreas livres não são
usadas neste caso;
- quando um segmento é dropado, ele pode ser usado. Porém áreas livres subseqüentes
não são aproveitadas como uma área grande livre, até execução do coalesce;
- o administrador deve verificar se está perto de MAXEXTENTS. Para evitar erro
(ORA-01553 maxextents reached), aumentar o tamanho de NEXT;
- o parâmetro NEXT deve ser verificado freqüêntemente para evitar que cresça mais
queo necessário para o período.
O BRCONNECT pode ser usado para adaptar o NEXT extents. O BRSPACE pode ser
usado para coalesce manual, e o brconnect –f ceck para coalesce de forma automática.

108
Locally Managed Tablespaces são usadas no novo layout MCOD. Cada data file tem
um bitmap listando blocos usados e livres. O Oracle procura em cada data file se há
espaço contínuo para alocar um novo extent.
O tamanho do extent não é mais definido por parâmetro. Ele pode ser idêntico para todos
extents (UNIFORM) ou escolhido de acordo com o tamanho do segmento
(AUTOALLOCATE), escolhidos na criação da tablespace e não mais alterado
posteriormente.
SAP usa locally managed tablespace, com automatic extent allocation, exceto:
- PSAPTEMP: UNIFORM;
- PSAPROLL: dictionary-managed (substituída pela PSAPUNDO: UNIFORM);
- Em sistemas SAP BW, tablespaces que contém tabelas de fatos ou agregamentos,
devem ser criadas com uniform extent size de 1Mb.
Vantagens:
- adaptação de NETX ou MAXEXTENTS não é mais necessário;
- devido ao tamanho máximo do extent ser 64Mb, menos fragmentação é causado e o
espaço no data file é melhor gerenciado;
- melhor performance em dropps ou criação de tabelas em paralelo, uma vez que não é
necessário atualizar o dicionário de dados.
Desvantagem: a busca por blocos usados e livres consome recurso.

Além de guardar dados, o banco de dados Oracle deve prover:

- consistência de transação;
- consistência de leitura: outras transações devem ler dados ainda não alterados (antes de
commit ou deletes).
Para prover esse tipo de consistência, Oracle provê rollback segments em uma
tablespace de rollback, ou, a partir do Oracle 9i, undo segments em undo tablespace.
Quando um dado é alterado, antes ele é levado para um segmento de rollback (ou undo).
Se for feito rollback, os blocos voltam do segmento de rollback (ou undo) para o local de
origem. Se antes do commit ou rollback outro comando selecionar esses dados, eles são
lidos do segmento de rollback (ou undo).
SAP utiliza tablespace de rollback até a versão 6.20. É recomendado mudar para undo
tablespace quando usando Oracle 9i, pela facilidade e novos recursos.
Rollback tablespace: o gerenciamento de extents é similar ao da dictionary-managed
tablespace, porém com a adição do parâmetro OPTIMAL.
Quando uma transação sofre commit, o extent é marcado para sobreescrito. Em certos
casos, o Oracle redimensiona a tablespace para seu tamanho OPTIMAL.
Desvantagens:
- parâmetros devem ser experimentados até chegar a um bom valor, pois depende do
tamanho e uso do sistema;
- como o Oracle pode escolher qualquer segmento de rollback, os parâmetros devem ser
alterados para todos os segmentos de rollback;
- em caso de grande movimentação de dados, a SAP recomenda criar outra tablespace de
rollback.
Undo Tablespace: a partir da versão 9i a Oracle introduziu o automatic undo
management (AUM).
Vantagens:
- gerenciados automaticamente;
- uma transação pode usar mais de um undo segment;
- o tempo em que um segmento pode ser sobreposto não é mais o commit, e sim o tempo
definido em undo_retention, evitando o erro ORA-01555;

109
- alterar para undo tablespaces grandes, para grande movimentação de dados, é mais
fácil.
Parâmetros adicionados:
- undo_management: MANUAL ou AUTO (para ativar);
- undo_tablespace: comando CREATE UNDO TABLESPACE „PSAPUNDO‟;
- undo retention: tempo de retenção em segundos, antes que o dado possa ser sobreposto;
- undo_supress_errors: suprime os erros ao tentar mudar manualmente.
Passos para alterar de rollback para undo:
1) Criar tablespace PSAPUNDO;
2) Alterar ou inserir os 4 parâmetros;
3) Drop em todos os segmentos de rollback (exceto no SYSTEM);
4) Remover ou comentar o parâmetro rollback_segments;
5) Remover a tablespace de rollback

Database System Check

O BRCONNECT é usado para verificar o banco de dados, adaptar NEXT extents, criar
estatísticas e apagar DBA logs.

Checking the Database

Para fazer o check do banco de dados, o BRCONNECT verifica as condições na tabela
DBCHECKORA. O log é criado /sapcheck/c<encoded_timestamp>.chk, e pode ser visto
via editor de textos, BRTOOLS ou DB14. Erros e warnings podem ser vistos ainda na
DB16 e CCMS.
Pode ser executado via BRTOOLS  Check and verification  Database system check
ou comando brconnect –f check.
Para atualizar os parâmetros, acessar DB17:
- adicionar novas condições DBO, ORA ou PROF;
- excluir condições do check;
- especificar valores padrão;
- criar condições para serem excluídas do check;
- criar condições para definir valores padrões;
- especificar ações de correção;
- manter descrições das condições.
Tipos de verificação na tabela DBCHECKORA:
- Database administration (DBAs): operações de administração, como configuração,
gerenciamento de espaço. Não podem ser adicionados. Para excluir, usar parâmetro
check_exclude do init<DBSID>.sap;
- Database operation (DBO): verificações de operação, como backup e falhas;
- Oracle messages: o arquivo e log é verificado em busca de erros.
- Oracle profile parameters (PROF): verificação de parâmetros do profile.

Adapting the NEXT Extent Size

Brconnect –f next deve ser executado regularmente para adaptar o parâmetro NEXT de
todas as tablespaces gerenciadas por dicionário para evitar:
- ter vários pequenos segmentos (degrada performance, perto do limite de
MAXEXTENTS);
- ter segmentos muito grandes (perda de espaço em disco, fragmentação, tablespace
overflow).
Objetos em tablespaces localmente gerenciadas são automaticamente excluídos.
Comando normalmente utilizado: brconnect –u / -c –f next –t all

110
O algorítimo utilizado para determinar o valor otimizado para NEXT garante que NEXT
é:
- não é valor menor que o valor atual e como especificado no SAP data dictionary para
este tipo de tabela ou índice;
- em torno de 10% do tamanho total da tabela ou índice, se o tamanho é maior que o
esperado;
- menor que a maior área livre contínua da tablespace, se esta não é auto-extensível.
O log é guardado em /sapcheck, com extensão .nxt e pode ser visto da mesma forma que
o log da database system check.

Checking and Updating Database Statistics

Oracle usa otimizador baseado em custo para encontrar o melhor caminho quando
selecionando tabelas. No SAP, o parâmetro optimizer_mode é configurado para
CHOOSE, o que indica que o Oracle usará o otimizador baseado em custo quando
estatísticas estão disponíveis. Isto porque algumas tabelas sofrem alterações de dados
frequentemente, e não devem ter estatísticas geradas.
Para fazer o update statistics, executar brconnect –f stats, que verificará se as estatísticas
estão desatualizadas e atualizará as necessárias.
SAP recomenda a execução de brconnect –u / -c –f stats –t all semanalmente. Pode ser
agendada via DB13. Para atualizar apenas as tabelas que não possuem estatísticas (ex.:
recém criadas): brconnect –f stats –t missing, ou DB20  Global statistics  Create
missing.
O log é gerado em sapcheck, com a extensão .sta, e pode ser visualizado como no
database system check.

Cleaning Up Old Logs and Traces

Para limpar logs e arquivos intermediários (como backups), execute brconnect –f
cleanup, que limpará:
- Logs detalhados do BR*Tools;
- Backups em disco;
- Export dumps e scripts criados pelo BRSPACE;
- log records e check results nas tabelas SDBAH, SDBAD, DBA*, e DBMSGORA;
- Oracle trace e audit files.
Comando normalmente executado: brconnect –u / -c –f cleanup
Por padrão, arquivos anteriores a 30 dias e database log records anteriores a 100 dias são
removidos. Esses valores podem ser alterados via parâmetros específicos no
init<DBSID>.sap.

Checking Database Growth

Os dados estatísticos sobre o crescimento do banco podem ser visualizados via DB02.
A tela de entrada mostra um sumário das informações do tamanho do banco de dados e
espaço livre. Para mais detalhes, selecionar os botões:
- Space statistics: estatísticas do espaço de toda a base;
- Current sizes: tamanho e status de tablespaces e tabelas;
- Space statistics: estatísticas de espaço por tablespace;
- Freespace Statistics: informações detalhadas do espaço livre nas tablespaces, incluindo
fragmentação;
- Space critical obects: todos os segmentos que o next extent é maior que a maior área
livre.

111
Para coletar estatísticas do banco de dados, SO e SAP, e guardar os dados em tabelas, o
job COLLECTOR_FOR_PERFORMANCE_MONITOR deve estar agendado em
freqüência horária, executando o ABAP report RSCOLL00.
O report RSCOLL00 lê a tabela TCOLL para ver o que será verificado e em que horário.
O report coleta as informações e guarda nas tabelas MONI (dados estatísticos) e PAHI
(parâmetros).

CCMS Alert Monitor

O CCMS pode ser usado para monitorar e verificar as seguintes funções:
- Space Management: tablespaces e segments;
- Performance: otimizador de estatísticas, buffers, logs e checkpoints;
- Backup or restore;
- Consistency: entre objetos ABAP e dicionários do Oracle;
- Health: system checks do BRCONNECT.
O principal coletor de informações sobre o banco é o BRCONNECT, que escreve os
resultados na DBMSGORA, lida pelo CCMS.
Os MTEs na RZ20 podem ser removidos, após alteração de parâmetros na DB17. Após
remoção, executar programa RSDBMON0 para recriá-los, com as novas configurações.
Para evitar acessos excessivos à view DBA_SEGMENTS, é necessário executar o
brconnect –f check uma vez por dia. Caso os dados sejam mais antigos que um dia na
DBMSGORA, os dados serão exibidos da DBA_SEGMENTS.

Unit 4 – Storage Management

Tablespace Administration
Em operação “normal”, a criação de uma nova tablespace ou a remoção de uma
existente não é necessária. Este é ocaso de upgrade e preparação de uma reorganização
online.
Para criar uma nova tablespace, acessar BRTOOLS  Space management  Create
tablespace. Opções:
- tablespace: nome da tablespace, seguindo padrão SAP (PSAP<SCHEMA-ID><unique
name>;
- contents: data (dados + índices), temp ou undo;
- space: auto (gerenciamento de espaços de segmento automático) ou manual. Sempre é
criado locally managed tablespaces;
- owner: só em casos de MCOD;
- data: table, índex ou both (recomendado para facilitar administração);
- joint: se escolheu table ou índex acima, especificar a tablespace de índice ou tabelas
correspondente.
Após o continue, um novo menu é apresentado:
- file: o nome do novo data file para a tablespace;
- size: em MB;
- autoextend: Yes (cresce automaticamente) ou no;
- maxsize;
- incrsize.
Antes e a pós a criação, um backup do control file é criado em /sapreorg, além de log da
operação em /sapreorg/struc<DBSID>.log.
Para remover, BRTOOLS  Space management  Drop tablespace.
Por padrão, uma tablespace não é apaga se não estiver vazia. O parâmetro force = Yes
altera isso. O BRSPACE vai:

112
- criar um backup do control file antes de após a remoção;
- verificar se a tablespace está vazia;
- torná-la offline;
- removê-la, inclusive seus data files;
- remover todos os subdiretórios;
- criar uma entrada no log struc<DBSID>.log.
Para aumentar uma tablespace, três opções são possíveis:
- adicionar novo data file;
- as propriedades do data file pode ser mudada para “autoextensible”;
- o data file pode ser aumentado.
Para adicionar um novo datafile, BRTOOLS  Space managment  Extend
tablespace. O menu é similar ao de criar uma tablespace nova.
Para alterar um data file para autoextensible, acessar BRTOOLS  Space
management  Alter data file  Maintain autoextend. É possível alterar maxsize e
incrsize nessa função.
Para alterar o tamanho de data file, BRTOOLS  Space management  Alter data
file  Resize data file.
Para mover ou renomear um data file, o BRSPACE o faz somente com padrão de
nomenclatura SAP. BRTOOLS  Space management  Move data file. Opções:
- Destination;
- parallel: se foi selecionado mais de um data file;
- force: força o shutdown do banco mesmo que o SAP esteja ativo.
Para exibir informações de uma tablespace: BRTOOLS  Space management 
Additional space functions.
Para alterar uma tablespace: BRTOOLS  Space management  Alter tablespace:
- Set tablespaces offline ou online;
- Set ou reset the backup status: quando o BRBACKUP apresenta erro, uma ou mais
tablespaces podem ficar em status backup mode. Neste caso, um shutdown não
funciona e se for um shutdown abort, é necessário recovery manual.
- Coalesce free extents

Reorganization of Tables
Reorganização é normalmente utilizada para retirar a fragmentação de objetos do banco.
Executando ela, melhora-se a performance e recupera-se espaços fragmentados. O
modelo clássico é:
- export das tabelas;
- drop das tabelas (e tablespace);
- recriação da tablespace (se foi removida);
- import das tabelas.
Nas versões de Oracle 8 e 9i, junto com a evolução de discos e RAID, novas
características foram introduzidas, diminuindo a necessidade de reorganizações:
- locally managed tablespaces possuem alocações mais eficientes;
- usando automatic segment space allocation, a fragmentação de blocos é
significadamente reduzida e a performance de queries em paralelo melhorada;
- discos grandes com RAID e buffers maiores e mais seguros diminuem o I/O.
Usando as facilidades de redefinição online do Oracle, a reorganização (online table
redefinition) ocorre de forma mais fácil. Vantagens e características:
- pode ser feita online;
- pode ser paralelizado;
- pode ser usado para mover tabelas para outras tablespaces;

113
- pode ser usado para recriar uma tabela, reduzindo fragmentação;
- diminui o risco, onde verificações são feitas antes do processo e a remoção do objeto
apenas após a criação do mesmo.
Razões para desfragmentação no Oracle 9i:
- tabelas fragmentadas e índices fragmentados ou degenerados;
- transformar dictionary-managed em locally managed tablespaces;
- mover tabelas para novas tablespaces.
BRSPACE suporta online table redefinition e métods tradicionais de reorganização.
BRTOOLS  Segment Management. Opções:
- Reorganize Tables: redefinição online, usado para diminuir fragmentação, transformar
dictionary-managed tablespaces em locally managed, transformar tablespaces do layout
tradicional em layout do MCOD, mover tabelas grandes para uma tablespace separada.
- Rebuild indexes: recriar índices;
- Export e Import tables: método tradicional de reorganização. Usado em Oracle 9i em
tabelas com campos LONG ;
- Alter tables e indexes: algumas funções de performance, como “switch on table
monitoring”, onde o Oracle controlará se a tabela foi alterada (acelerando consulta para
update statistics) e “set parallel degree”, para prover performance em INSERTs (com o
aval da SAP, não usado em produção).
Passos do online table redefinition:
- BRSPACE usa o PL/SQL DBMS_REDEFINITION;
- tabelas são verificadas se podem ser redefinidas online;
- cria uma tabela temporária, com nome <ORIGINAL>#$;
- copia os dados para a temporária, pode ser paralelizado;
- cria índices, contraints, triggers, etc.;
- termina o processo com o pacote DBMS_REDEFINITION;
- objetos criados são renomeados;
- BRSPACE apaga a tabela temporária.
Em caso de erros, a tabela original permanece intacta, e o BRSPACE apaga a tabela
temporária.
Antes de iniciar a reorganização usando online table redefinition, verifique:
- se vai mover para nova tablespace, ela existe?
- tablespace é locally managed?
- há espaço na tablespace/disco?
Para reorganização, BRTOOLS  Segment management  Reorganize tables.
Pode-se usar caracteres para tabelas ([<owner>].<prefix>* ou *), especificar a
tablespace (todas tabelas sem LONG sofrerão reorg) ou deixar em branco (serão
apresentadas as tabelas). O parâmetro reorg_table no init<DBSID>.sap pode ser usado
para informar quais tabelas sofrerão reorg.
Os parâmetros para reorganização são:
- newts: nova tablespace ou vazio para atual;
- indts: tablespace de índice (se diferente da de tabelas);
- parallel: paralelismo;
- degree: paralelismo de cópia para as tabelas temporárias;
- ddl: NO (comando DDL gerado apenas internamente, não recomendado), YES (gera
ddl.sql em /sapreorg), FIRST (gera o ddl.sql e aguarda confirmação antes de executar).
Para recriar índices, acessar BRTOOLS  Segment management  Rebuild indexes.
As opções são similares à de reorganização, porém não é Criado DDL (é usado o
comando ALTER INDEX REBUILD ONLINE), especificando a tabela, todos índices
dela serão recriados e uma nova tablespace para os índices pode ser informada.

114
O BRSPACE suporta o método tradicional EXP/IMP, porém só é recomendado para
tabelas que não podem sofrer redefinição online. Além do utilitário, vários passos devem
ser feitos manualmente.
Para transformar uma tablespace gerenciada pelo dicionário de dados em localmente
gerenciada, faz-se a online reorganization em uma nova tablespace, com os passos
adicionais:
1) Criar uma tablespace localmente gerenciada, que conterá dados e índices.
Recomenda-se que seja auto-extensível;
2) BRTOOLS  Segment management  Reorganize tables, escolha a tablespace e
coloque “*” para as tabelas;
3) Continue e confirm;
4) Em “Options for reorganization of tables, defina o nome da nova tablespace.
Tabelas que não podem ser reorganizadas online permanecerão na tablespace antiga.
Neste caso:
- utilizar export / import após a reorganização;
- assim que possível, usar o BRSPACE para converter LONG em LOB antes da
reorganização.

Housekeeping and Troubleshooting

Revisão das atividades:
- Database System check deve rodar diariamente, agendada via DB13. DB14 deve ser
verificada para warnings/erros. Warnings e erros devem ser solucionados;
- Check and adapt NEXT extents: executar semanalmente, agendada via DB13.
Verificar logs na DB14;
- Update optimizer statistics: deve rodar semanalmente, agendada via DB13. Verificar
logs na DB14;
- Clean up old logs and traces: deve rodar semanalmente, agendada via DB13.
Verificar logs na DB14.
Archiver stuck ocorre quando não é possível copiar o online redo log e o LGWR
necessita sobrepor este arquivo. Isto normalmente ocorre quando o disco do diretório de
archive está cheio.
Para evitar, recomenda-se:
- ter bastante espaço no diretório de archives, pelo menos 3x o tamanho diário esperado;
- criar um arquivo dummy 10x maior que um archive. Assim ele pode ser apagado, o
sistema volta a funcionar e rotinas como backup de offline redo log files podem ser
executadas;
- usar o diretório de archive em uma unidade diferente de onde o BRARCHIVE guarda
os logs.
Quando ocorre erro durante o backup online, algumas tablespaces podem ficar em
estado de backup. Para verificar, executar brspace –c force –f dbshow –t tslist. Neste
caso:
- Verificar no sistema operacional se o BRBACKUP está em execução;
- BRTOOLS  Space management  alter tablespace  Reset backup status;
- coloque 0 para selecionar todas tablespaces;
- remover arquivo /sapbackup/.lock.brb;
- executar um teste de backup para ver se está OK.
Caso o banco tenha caído durante o backup, o erro ORA – 01113: file N needs media
recovery. Um recovery pode ser necessário:
- brrecover –c force –t complete; ou

115
- via SQL*Plus: ALTER DATABASE END BACKUP, em que o recovery não é
executado (somente se um data file não precisou ser restaurado).

Unit 5 – Introduction to Oracle cache management

Oracle System Global Area
Em sistemas SAP, o único usuário que deve acessar o banco é o administrador do banco.
Terminologia:
- database: coleção de dados, logicalmente formam uma unidade, fisicamente um ou
mais datafiles. Um objeto do banco de dados (ex.: tabela) está em uma tablespace
(unidade lógica), que pode ter um ou mais datafile.
- Instance = memory + processes:
- memory: shared memory = system global area (SGA). Cada instância possui
sua própria SGA, que não é compartilhada com outras instances.
- processes: processos background. No Unix se vê processo a processo, no NT
apenas um “Oracle” (usa threads).
- DBSID: identificador do banco de dados, nome único, no caso da SAP com 3
caracteres (upercase, sendo primeiro obrigatóriamente letra, os outros 2, letras ou
número).

Listerner não faz parte da instância, faz parte de processos de rede.

Cada work process se comunica com um shadow process. O work process se conecta
automaticamente após queda/startup do banco.
O gerenciamento de memória separa área de memória que pode ser usada por todos os
processos (SGA) ou para cada processo individualmente (PGA) – parâmetros em bytes:
- SGA (System Global Area ou shared memory):
- Buffer Pool (Data Buffer ou Buffer Cache): buffer para data blocks
(DB_BLOCK_BUFFERS em blocos ou DB_CACHE_SIZE usando dynamic SGA);

116
 - Shared Pool: buffer para comandos SQL (Shared SQL Area, Shared Cursor
Cache ou Library Cache) e informações do dicionário de dados (Dictionary Cache ou
Row cache). Parâmetro SHARED_POOL_SIZE;
- Java Pool: cache para java (JAVA_POOL_SIZE);
- Large Pool: buffer para dados especiais (multi-thread, RMAN com vários I/O,
PL/SQL, etc.). Parâmetro LARGE_POOL_SIZE;
- Redo Buffer: buffer para redo log (LOG_BUFFER).
- PGA (Program Global Area ou process-local memory): buffer para sorting, hash joing
e outras atividades temporárias (PGA_AGGREGATE_TARGET quando usa automatic
PGA administration).
Parametrização do SAP:
- Buffer pool: grande o suficiente para a qualidade ser maior que 95%;
- Shared pool: pelo menos 400Mb;
- Java Pool: se não usado, valor 0;
- Large Pool: não necessita configuração, pois usa pouca memória;
- Redo buffer: bom valor: 1Mb, não deve ser excedido;
- PGA: valor máximo que conseguir.

Até oracle 8.1.7.* as áreas de memórias não eram mudadas dinamicamente. A partir da
versão 9, com a opção Dynamic SGA, o boot não é requerido.
 Multiple Block Sizes para tablespaces não são recomentadas pela SAP.
Parâmetros para Dynamic SGA:
- SGA_MAX_SIZE: tamanho máximo em que a SGA pode crescer automaticamente
(soma dos parâmetros das subáreas da SGA);
- DB_CACHE_SIZE: tamanho do buffer cache, e que ativa o Dynamic SGA. Não usar
junto com DB_BLOCK_BUFFERS (Oracle 8i e menores);
Parâmetros que podem ser alterados dinamicamente quando ativo o Dynamic SGA:
- DB_CACHE_SIZE: buffer cache;
- SHARED_POOL_SIZE: shared pool;
- LARGE_POOL_SIZE: large pool.
Parâmetros não alterados dinamicamente:
- SGA_MAX_SIZE: tamanho máximo da SGA;
- LOG_BUFFER: tamanho do redo log;
- JAVA_POOL_SIZE: java pool.

Shared Pool
- shared SQL area: SQLs parsed, com o plano de execução. Quando já existe o comando
na shared SQL area: soft parse. Quando não existe, e precisa consultar o dicionário de
dados: hard parse. SQL executado  tem na shared? Se não  parse e salva na shared
 recupera dados e armazena na shared pool.
- Data Dictionary cache (nomes, definições, acessos, segurança...).
Execução do SQL:
1) Declare: substitui o SQL por variáveis: select * from mara where mandt=:A0 and
matnr=:A1. Shadow Process allocates memory areas from PGA;
2) Prepare: determina o plano de execução;
3) Open: substitui variáveis pelos valores: select * from mara where mandt=‟100‟ and
matnr=‟4711‟
4) Fetch: retorna os dados da consulta.

117
Oracle Program Global Area
Program Global Area = Process Global Area = work area.
Optimun: comando feito sort na PGA. Ideal > 90% (OLTP);
One-pass: acessa tabela temporária para fazer 1 nível de sort (separa em “blocos” de sort
e depois junta tudo no banco). Ideal < 10% (OLTP);
Multi-pass: necessita criar vários níveis de sort até chegar no resultado esperado. Não
deve ocorrer.
No Oracle 8i:
SORT_AREA_SIZE
HASH_AREA_SIZE
BITMAP_MERGE_AREA_SIZE
BITMAP_CREATE_AREA_SIZE
Parâmetros estáticos.
No Oracle 9i:
WORKAREA_SIZE_POLICY = AUTO
PGA_AGGREGATE_TARGET = 100MB
Define-se o tamanho total da PGA da instância, e o Oracle gerencia de forma automática
como deve ser. O parâmetro é dinâmico, ou seja, pode ser alterado em runtime.
O Oracle avalia toda a memória disponível na PGA, a quantidade que o comando precisa
e aloca a memória necessária.
O Oracle calcula, em regra geral (9i):
- máximo 5% para Shadow Process;
- máximo 30% para processo paralelos da Shadow Process;
- máximo 200Mb para Shadow Process.
Cálculo estimado para a PGA:
PGA_AGGREGATE_TARGET = <memória física > * 20% (OLTP);
PGA_AGGREGATE_TARGET = <memória física > * 40% (OLAP);
PGA_AGGREGATE_TARGET = (SORT_AREA_SIZE + HASH_AREA_SIZE + ...) *
(#Shadow process / 10).

Unit 6 – Monitoring of the database instance

The New Oracle Database Monitor provided by SAP
A nova transação ST04N pode ser usada para monitoramento do Oracle, seja ele single
ou RAC. Ela substitui a antiga ST04 e busca informações das views V$, GV$ (existe
apenas no RAC) e DBA. A nova transação é apenas para Oracle 9i+.
Para utilizar a funcionalidade da nova transação, é requirido:
- parallel_min_servers pelo menos 10;
- executar alguns scripts para criar tabelas de históricos, views e sinônimos utilizados;
- para ter dados históricos, o report “RSORAHCL” deve estar agendado.
Main monitor:
- data buffer quality: proporção das leituras físicas em relação ao total de leituras. Deve
estar acima de 94% em um total de 15 milhões de leituras;
- ratio of user and recursive calls: uma boa performance indica proporção maior que 2;
- number of reads per user call: se exceder de 30, pode indicar expensive SQL;
- Time/User Call: valores acima de 15 ms indicam necessidade de otimização;
- Busy wait tine X CPU time: valores em torno de 60:40 indicam um sistema estável.
Valores muito acima indicam necessidades de melhoria;
- DD-cache quality: deve estar acima de 80%.
Além dos menus, a ST04N povê submonitores para informações detalhadas:

118
- Overall Activity:
- Buffer busy waits: indica que há buffers em que vários processos tentam
acessar de forma simultânea;
- File system requests (GV$FILESTAT): data files mais utilizados;
- System/wait events (GV$SYSTEM_EVENT): wait events;
- Undo statistics (GV$UNDOSTAT);
- Automatic segment space management: verifica o ASSM do banco;
- Online redefinition tables;
- Resumable space allocation;
- Parallel query (V$PQ*): ocorrência de queries em paralelo, que são úteis em
caso de full table scans, etc.
- Resource Consumptions:
- Oracle Session Monitor: lista as sessões do oracle, pode-se ver o plano de
execução de um SQL;
- SQL request: acesso a SQLs processadas no banco de dados;
- Top SQL statements: informações da instância e dados históricos;
- Table Access monitor: shared cursor cachê pelo ponto de vista das tabelas
acessadas;
- Latch monitor: atividades de uso exclusivo de recurso;
- PGA monitor: monitora a PGA;
- SGA monitor: monitora a SGA.
- Exceptional Conditions:
- enqueue monitor: monitoramento das filas;
- Lock monitor: monitora os locks ativos;
- Database message log.
- Additional Functions:
- Display V$/GV$ views and values: acesso a views de performance;
- Parameter configuration: parâmetros do SPFILE ou init<sid>.ora;
- arbitrary monitoring;
- System statistics for CBO;
- Checkpoints;
- Data guard: monitora a funcionalidade de data guard do Oracle;
- State on disk: chama DB02.
As novas funcionalidades do Oracle 9i suportadas pela SAP são:
- uso do SPFILE;
- Automatic Undo Management (AUM);
- Automatic segment space management (ASSM), que provê um uso melhor de espaço,
reduzindo buffer busy waits;
- Dynamic System Global Area: permite alterar parâmetros de buffers online;
- Automatic Program Global Area memory management;
- Online reorganization of tables: também possível no 8i;
- Defaul temporary tablespace: a partir do AS 6.40, tablespace PSAPTEMP é a
tablespace temporária padrão, não usando a SYSTEM para isso;
- Locally managed SYSTEM tablespace;
- Suporte ao RAC.
Snapshots = dados históricos.
Dados históricos do SAP são guardados na tabela MONI;
Dados históricos do banco são gravados em tabelas GVD*, atualizadas via report
RSORAHCL (ou RSORAHIST).

119
Oracle Wait Interface
Determinando o Wait Event, é possível saber o que a sessão está fazendo, ou o que está
esperando. Se um processo demora muito tempo, analisando os wait events é possível
saber quanto desse tempo é perdido com full table scans, leitura de discos causadas por
idex lookups, etc.
A análise detalhada é muito usual, uma vez que o tempo de resposta geralmente é
determinado pelo tempo de espera no framework de wait events e o consumo de CPU.
Em sistemas otimizados, wait events consome na faixa de 60% do tempo de resposta.
Analisando os wait events acumulados desde o startup do banco, é possível saber o nível
de otimização possível e onde é necessário focar.
Total wait time = idle wait time (não há o que fazer) + busy wait time (espera por um
recurso).
Busy wait mais comuns:
- dB file sequential read: aguardando blocos paralelos serem lidos do disco;
- dB file parallel read: esperando por blocos a serem lidos paralelamente do disco;
- dB file scattered read: aguardando por vários blocos serem lidos do disco;
- log file sync: aguarda enquanto LGWR escreve dados do redo buffer, após commit ou
rollback;
- log buffer space: aguardando espaço livre no redo buffer;
- log file switch: aguardando switch do relo log file;
- log file parallel write: LGWR aguarda por blocos a serem escritos no disco;
- Buffer busy waits: aguardando um bloco que está sendo carregado ou alterado por
outra sessão;
- write complete waits: aguardando o DBWR escrever um bloco no disco;
- enqueue: aguardando um lock do Oracle;
- library cachê pin / library cache lock: aguardando acesso exclusivo a dados no library
cachê (Shared SQL Area);
- row cachê lock: aguardando por um acesso exclusivo no row cachê;
- db file parallel write: espera do DBWR, enquanto blocos são escritos no disco;
- direct path read: aguardando enquanto está lendo buffers do disco para o PGA;
- direct path write: aguardando enquanto escreve buffers da PGA pro disco;
- free buffer waits: procurando por buffer blocks livres.
Quando um processo está busy, não há informações no wait event interface.
A wait event information provida pelo Oracle provê informações detalhadas de quanto
tempo e quantas vezes foi necessário esperar por um determinado evento. Não são
gravadas informações de uso de CPU, desta forma não é possível saber o tempo de
espera por uma CPU, o tempo de uso de uma CPU e o tempo da memória sofrer swap de
volta à memória física.
Quando o acesso a um data block é feito diretamente ao buffer cachê, uma leitura lógica
ocorre sem leitura física. Desta forma, o processo consegue ler o bloco sem wait event.
A interface do Oracle para wait events, consiste de 4 views:
- V$SYSTEM_EVENT: wait events acumulados no sistema desde que a base foi
inicializada: uma linha para cada evento, o número de vezes que um processo esperou
por esse evento, o numero de timeouts, o tempo total esperado e a média de tempo;
- V$SESSION_EVENT: wait events acomulados por sessão desde que a base foi
iniciada: dados semelhantes à V$SYSTEM_EVENT, porém por sessão;
- V$SESSION_WAIT: wait events atuais: processo, quantas vezes entrou em wait e o
estado atual (se STATE for Waiting, espera por evento, caso contrário está
processando);

120
- V$EVENT_NAME: nome e parâmetro dos wait events, exibe uma linha para cada wait
event conhecido pelo banco de dados Oracle.
Para evitar acesso direto ao banco, ST04N  Detail analysis menu  Additional
Functions  display V$/VG$ views and values.
Se a proporção é 60% Wait time para 40% CPU Time e o sistema está lento, expensive
SQLs devem ser monitorados. Se é mais de 60%, os wait events devem ser tunados. Se é
menos, a CPU deve ser tunada.
Os wait events mais importantes podem ser monitorados no SAP/Oracle Database
Monitor, no submonitor “System / Wait Events”:
- Busy waits summary: mostra um resumo dos busy waits dependendo do tipo de
processo (Background / user);
- Wait event details: mostra detalhes de cada wait event. Apenas eventos de processos
non-idle são listados;
- GV$SYSTEM_EVENT: mostra os dados da view no banco, interessante somente em
RAC.
Para achar eventos com alto potencial de otimização, escolha o TOP 5 non idle events
que mais influenciam na performance.
DB file sequential read, significa que está aguardando parallel blocks serem lidos do
banco. De regra geral, não deve exceder 20ms na V$SYSTEM_EVENT (ou 15ms para
read-write-cache-memory). Usando a V$FILESTAT, verificar quais data files possuem
pior acesso e movê-los. Usar tempos anteriores para comparação de queda de
desempenho. Além do tempo, a quantidade é importante, demonstrando baixo hit rate do
buffer pool, expensives SQLs e necessidade de aumento do DB_CACHE_SIZE.
DB file scattered read, significa esperar que vários blocos sejam lidos do disco. É
causado por full table scans e mais raramente por índex fast full scans, que devem ser
evitados em sistemas R/3.
Buffer busy waits, significa que está aguardando um bloco ser importado ou alterado
por outra sessão. Esse valor não deve exceder 40ms na V$SYSTEM_EVENT (ou 15ms
para read-write-cache memory). Normalmente ocorre por problemas na I/O area, e deve
ser tratado como descrito em db file sequential read.
Free buffer waits, significa que deve aguardar o DBWR escrever dirty blocks no disco,
para ter blocos livres. Não deve estar no top 10 da V$SYSTEM_EVENT. Verificar se o
I/O subsystem deve ser melhorado, como aumentar o DB_CACHE_SIZE ou colocar
mais processos DBWR.
Write complete waits, significa que está esperando enquanto o DBWR está escrevendo
blocos necessários para o disco. Não deve estar no top 10 da V#SYSTEM_EVENT, e
I/O subsystem deve ser melhorado nesse caso.
Log file sync, significa que o LGWR está escrevendo todos dados do redo buffer para o
online redolog, durante commit ou rollback. Não deve exceder 40ms no
V$SYSTEM_EVENT (ou 15ms para read-write-cache memory). Verificar se o sistema
de I/O está configurado e otimizado. RAID5 não deve ser usado para online redologs.
Log file parallel write, significa que LGWR está esperando por blocos serem escritos
no disco. Deve ser otimizado como no log file sync.
Log file switch, significa que está aguardando por um log switch. Verificar Archiver
Stuck (log file switch (archiving needed)) ou necessário melhorar o DBWR (log file
switch (checkpoint incomplete)).
Log buffer space, significa que está esperando por espaço livre no redo buffer. Colocar
LOG_BUFFER = 1MB. Se continuar, pode ser problema de I/O, verificar procedimento
de log file sync.

121
Latch free, que significa que uma área deve ser liberada. Latch é um mecanismo de
serialização que é usado para evitar que estrutura de dados sejam acessadas
simultaneamente na SGA. Para otimizar, ver nota 767414.
Enqueue significa esperando por um Oracle-Lock. Ver nota 745639.
Se um número de um wait event está inexplicavelmente alto, pode ser gargalo de CPU.
Acessar ST06/OS07 e verificar o consumo de CPU (deve ter pelo menos 30% em
idle/hora).
Para evitar a exibição de parâmetros incorretos, um reset deve ser feito em várias telas
do SAP.

Unit 7 – Analysing Application Design

Consequences of Expesive SQL Statements
Resumo de lição anterior

Using SM50/SM66 to Find Expensive SQL Statements

Como identificar:
- Identificar atividades longas relacionadas ao banco (ex.: sequential read, insert,
update);
- Anotar o nome do report e da transação (SM66) para análise detalhada;
- Anotar o nome da tabela em que a ação é executada;
- Anotar o nome do usuário para possíveis futuras assistências;
- Na SM50, é possível ver o SQL atual.

Using ST03N/STAD to Find Expensive SQL Statements

Usando a ST03N, é possível identificar transações que usam uma parte significativa do
tempo total de resposta, bem como transações com tempo de banco de dados grande.
Escolha “Standard Transaction Profile” e restrinja por Dialog e ordene por Total
Database Time: acima de 5% do tempo todal deve ser avaliada;
Acessar a STAD e escolher:
- um período de tempo;
- Task Type D;
- Valor relevante do DB Request Time.

Using ST04N to Find Expensive SQL Statements

A ST04N oferece uma visão diretamente nos processos atuais do banco de dados. Isto é
útil para identificar queries em execução e prover maiores detalhes do quê está
acontecendo.
Acessar Detailed Analyses  Resource Consumption  Oracle Session Monitor:
- Identificar o work process ID (proveniente da SM50/SM66);
- Verificar a ação em SQL text;
- Analizar o explain plan da query.
Informações de Buffer gets podem ser obtidas em Detailed Analyses  Resource
Consumption  SQL Request.
Obtendo expensives SQL usando o shared cursor cachê:
- ST04N  Detailed Analyses  Resource Consumption  SQL Request: Analysis of
Shared Cursor Cache;
- Selecionar em buffer gets, um numero igual a 5% dos logical reads da ST04N;
- Verificar as SQLs que causam esse consumo;
- Analisar o explain plan (com link para o call point no programa ABAP);
122
Critérios de seleção:
- Buffer gets/execution: considerar os raramente chamados, mas muito expensivos
(normalmente batches);
- Disk reads: comandos que atrapalham a performance de I/O;
- Buffer gets/Record: comandos expensivos para banco e AS;
- Records/execution: ex.: muitos buffer gets para várias records, mas muito utilizado.

Using the SQL Trace to Find Expensive SQL Statements

ST05 é uma ferramenta para analisar acessos ao banco de dados. Grava tempos de
acessos em diferentes passos executados no banco. Também faz trace de enqueue, RFC
e buffer.
O tamanho máximo é definido pelo parâmetro rsrt/Max_filesize_MB, que normalmente
é 16MB no ECC.

Exlusive Lockwaits
Os locks podem ser divididos em “Database Locks”/”Database enqueues” e “SAP
Enqueues.
Tipos de lock Oracle:
- Usuário:
- TX (Tansaction enqueue);
- TM (DML Enqueue): quando o objeto todo está em lock (ex.: rebuild,
VALIDATE STRUCTURE);
- Sistema:
- ST (space transaction): em tablespaces dictionary-managed em alocação ou
liberação de extents;
- CI (Cross Instance Invocation enqueue call): em truncates, drops, etc.
O monitoramento de database locks pode ser feito via análise do wait event “enqueue”,
via V$LOCK ou ST04N. A duração pode ser acompanhada na V$ENQUEUE_STAT ou
ST04N  Detailed Analyses  Exceptional Conditions  Enqueue Monitor.
Quando um processo aguarda um lock para utilizar um recurso, é chamado Exclusive
Lockwaits.
Lockwaits podem ser enfileirados de forma que ocupem todos os WP disponíveis, sendo
necessária a eliminação do processo via sistema operacional.
O Oracle Lock Montor pode ser acessado via DB01 ou ST04N  Detailed Analysis 
Exceptional Conditions  Lock monitor, que indica o causador do lock, os bloqueados e
a chave bloqueada.
Para evitar exclusive lockwaits, o lock deve ser requisitado pelo programa o mais tarde
prossível.

Unit 08 – Index Management and Optimization

Index utilization
Index serve apenas para acelerar o acesso ao dado, apontando diretamente para onde ele
está. A criação de índices não necessita alteração de códigos SQL.
Um índice é composto de um ou mais campos de tabelas. Cada linha de uma tabela é
identificada por um ROWID, que é o datafile number + data block + row number. No
índice, as colunas são ordenadas para facilitar o acesso. Quanto menos campos em um
índice, a reusabilidade aumenta e a decisão do otimizador melhora.
Index scheme:
- B-Tree: um bloco “root”, com pointers para outros blocos;

123
- Bitmap: bom para vários valores repetidos, aponta para uma range de valores na tabela.
Tipos de índices:
- primário: define normalmente o unique da tabela;
- secundário: para acelerar pesquisas sem ser pelos campos chaves;
- unique secondary: índice secundário, com unique constraint.
Acesso a índices:
- Fast Full Index: campos requeridos estão no índice.
- Index Unique Scan: quando a cláusula where tem os mesmos campos que no índice;
- Index Range Scan: quando a cláusula where tem menos campos que o índice. Nesse
caso, a ordem é importante para acelerar o processo;
- Unselective Index Range Scan: quando um campo da cláusula where está no índice, o
outro não. Todos os dados são lidos do índice, onde é feito um sort do outro campo.
Muita carga é gerada, e pode ser interessante o full table scan neste caso;
- Index Skip Scan: até Oracle 8i, só podia usar índices compostos (mais de um campo)
caso o where contivesse todos os campos necessários. A partir do Oracle 9i, caso apenas
dois campos estejam na query, um índice com 3 campos não na mesma sequência pode
ser usado. As vantagens são: aceleração de algumas queries e obtenção de uma boa
performance com menos índices (ocupa menos espaço, acelera manutenções e DMLs).
- Full Table Scan: são verificados todos os blocos da tabela, sem índice. Pode ser
eficiente se vários dados são requisitados.

Creating an Index
Antes de sair criando indices:
- se o SQL for original, procurar por notas ou abrir chamados;
- se o SQL for customizado, tentar usar técnicas como “matched tables” e “SAP business
índex tables”, reescrever o código para usar índices já existentes ou adaptar um índice já
existente.
Índices secundários crescem junto com a tabela, o que torna a pesquisa cada vez mais
lenta.
Regras gerais:
- colocar apenas campos selecionáveis na query;
- usar poucos campos como possível (máximo de 4);
- posição dos campos no índice: campos geralmente não utilizados colocar no final;
- índices devem ser disjunct: não se parecer com outros índices;
- usar poucos índices em uma tabela: geralmente até 5, exceto quando tabelas que
sofrem muita leitura, como máster data;
- não alterar índices originais da SAP.
Antes de criar um índice, deve-se ver quão seletivo ele será. Para isso, acessar a DB05,
ou via SQL*Plus (having count(*) > 100, para ver se retornará mais de 100 linhas
diferentes).
Na DB05, se adicionado um campo para o índice e o número de valores únicos não
aumentar, este campo não deve entrar no índice.
Os índices são criados e mantidos no ABAP Dictionary, via SE11.
Para verificar índices criados no ABAP, mas que faltam no banco, acessar DB02 
Missing Indexes.
Caso um índice primário esteja faltando: SE11  nome da tabela  Utilities 
Database Utility  selecionar o índice e clicar em “Choose”  Create Database Index.
Caso um índice secundário: DB02  missing indexes  selecionar o índice  Create
in DB.

124
Unit 09 – Cost Based Optimizer
Update Statistics
O otimizador baseado em custo procura o caminho (access path) com menor custo
esperado de I/O.
Casos em que estatísticas não são necessárias:
- quando se usa Rule Based Optimizer (RBO) ou usando o comando RULE;
- tabelas de pools e clusters;
- exceções de acordo com a DBSTATC;
- Oracle DDIC Objects;
- para comandos Insert.
Tipos de estatísticas:
- table statistics: informações como número de linhas, número de blocos usados,
exatidão (sample_size) e data das últimas estatísticas;
- índex statistics: tamanho da árvore do índice, número de chaves diferentes, etc;
- column statistics: número de valores diferentes, o menor e o maior valor, exatidão e
data da última criação de estatísticas.
Informações de histograma são gravados na DBA_TAB_HISTOGRAMS, que descreve
a distribuição dos valores das colunas no menor e no maior valor.
Para atualizar:
- SQL ANALYSE TALE: deve cair em desuso;
- Oracle DBMS_STATS package: forma mais recente. Para mudar de tipo de
estatísticas, deve-se deletar a anterior;
- BR*TOOLS ou BRCONNECT: método recomendado e deve ser agendado via DB13.
Utiliza o ANALYSE TABLE, mas pode ser alterado para DBMS_STATs no
init<sid>.sap;
- DB20: para tabelas especificadas manualmente;
- Report RSANAORA: pode gerar novas estatísticas para tabelas ou índices.
A criação de estatísticas pelo BRCONNECT é feita baseando se a tabela foi alterada em
50% (para mais ou para menos).
A partir do BRCONNECT 6.10, uma opção chamada table-monitoring pode ser ativada
e é recomendado pela SAP. Esse monitor acelera a fase de check das estatísticas, pois se
baseia em mudanças na tabela.

Cost Evaluation
Parâmetros que influenciam:
- OPTIMIZER_MODE: deve ser “CHOOSE”, para ativar o CBO;
- OPTIMIZER_INDEX_COST_ADJ: fator de multiplicação do custo de acesso por
índice. Ex.: valor 10 significa 10% do custo;
- OPTIMIZER_INDEX_CACHING: porcentagem de blocos do índice que irão para
cachê.
- DB_FILE_MULTBLOCK_READ_COUNT: quantidade de blocos lidos por vez.
- HASH_AREA_SIZE / PGA_AGGREGATE_TARGET: quanto maior, menor o
custo de hash join;
- SORT_AREA_SIZE / PGA_AGGREGATE_TARGET: usada para sort. Quanto
maior, menor custo.
O custo de um full table scan pode ser estimado pelo número de blocos lidos, além do
parâmetro DB_FILE_MULTIBLOCK_READ_COUNT.
Para bases SAP R/3, o acesso deve ser feito via índice, então este parâmetro deve estar
configurado para evitar o full table scan. A experiência mostra que o valor deve ser 8.

125
“Oracle hints” são comandos para forçar o CBO a ir a uma direção estabelecida. Além
de manual hints, também existem generated hints, que podem ser controlados via
parâmetro dbs/ora/use_hints. Valor padrão é -1 (ativado).

Unit 10 – Analysing Memory Configuration

Data Buffer Utilization
ST04N  Data Buffer Quality > 95%
ST04 calcula determinando as leituras físicas dividido pelas leituras em buffer, enquanto
a ST04N calcula retirando as leituras diretas na tabela (através de comandos que forçam
isso).
Parâmetros para o cálculo:
- session logical reads: total de requisições para acessar um bloco, em memória ou em
disco;
- phisical reads: total de requisições para acessar um bloco em disco;
- phisical reads direct: número de blocos lidos em disco, através de bypass do buffer,
exceto LOBs;
- phisical reads direct (LOB): idem acima, porém para large objects.
Um Buffer Quality alto não quer dizer que o sistema esteja com tamanho de buffer ok.
SQLs consumidores que estão com muitos dados em buffer, aumentam o hit ratio, porém
consome espaço para outros SQLs. Um tuning desse SQL pode levar a abaixar o hit
ratio. Se log reads/user calls > 15, esse marcador é inválido.
A performance view V$DB_CACHE_ADVICE provê uma simulação do I/O quando se
altera o tamanho do buffer, pode ser ligado/desligado pelo parâmetro dinâmico
DB_CACHE_ADVICE. Os dados são coletados desde o startup da base, e em máquinas
com consumo de até 60% de CPU não degride a performance. Também pode ser obtido
via ST04N  Detailed Analyses  Resource consumption  SGA Monitor  Cachê
Advisory Stat.  Size for estimation.

Efficience Of Shared Pool

Componentes do shared pool:
- Shared SQL Área: SQLs executados armazenados para todos os processos;
- Data Dictionary Cache: dicionário de dados, incluindo otimizador baseado em custo.
Uso:
- User Calls: acesso dos shadow process à Shared SQL Area;
- Recursive Calls: leituras físicas do dicionário de dados da tablespace do sistema.
Monitoramento (ST04N):
- Shared SQL Area:
- reloads/pins < 0,04.
- pin/ratio >= 95%.
- Dictionary Cachê
- User/recursive calls: > 2;
- DD-cache quality: > 80%.
Shared Pool Advisory: ferramenta do Oracle de simulação de alteração da SGA e
possíveis resultados. View: V$SHARED_POOL_ADVICE.
 não há parâmetros para alterar o tamanho da shared e/ou dictionary. Aumentando a
SGA aumenta os dois.

Monitoring the Automatic Program Global Area

Views para monitorar:

126
- V$PGASTAT: estatística de uso da PGA da instância;
- V$SQL_WORKAREA: informações sobre work areas utilizadas por cursores de
SQL;
- V$SQL_WORKAREA_HISTOGRAM: mostra dados estatísticos sobre execuções
por work areas, separadas por execuções otimizadas, one pass ou multi-pass.
- V$SQL_WORKAREA_ACTIVE: visão atual de quais work areas estão alocadas,
quais estão em disco, etc;
- V$PROCESS: mostra a PGA usada por processo Oracle.
Importante saber a utilização das views abaixo para tuning:
- V$SYSSTAT: estatísticas do sistema. Concatenar “STATISTICS#” com a view
“V$STATNAME”;
- V$SESSTAT: estatística dos usuários. Concatenar “STATISTICS#” com a view
“V$STATNAME”.
No SAP: ST04N  Detailed Analysis  Resource Consumption  PGA Monitor

Guia Status: configuração da PGA, baseado na view V$PGASTAT:

- PGA Status
- Aggregate PGA Target parameter: valor do parâmetro
PGA_AGGREGATE_TARGET: tamanho da PGA;
- Aggregate PGA Auto Target: área que o Oracle reserva para work areas.
- Over Allocation Count: valor acima do PGA_AGGREGATE_TARGET
necessário. Deve ser 0, caso contrário aumentar valor deste parâmetro.
- Cachê hit percentage: valor ideal de 100% mostra que todas os work areas
trabalham de forma otimizada, e não one-pass ou multi-pass.
- SQL workarea
- View SQL Workarea: view V$SQL_WORKAREA, tamanho em bytes, tempo
em segundos;
- Top 10 mem. Cachê con: top 10 consumidores de memory cache. Informação
da V$SQL_WORKAREA;
- One-multipass workarea: SQLs, tipo de execução (otimizada, one ou multi-
pas) e percentuais de execução. Baseada na V$SQL e V$SQL_WORKAREA.
- SQL workarea histogram:
- Histogram: visão baseada na V$SQL_WORKAREA_HISTOGRAM
- Percent optimal: percentagem de work areas que executaram em modo
otimizado, one-pass ou multi-pass.
- Work area executions: mostra quais work areas foram executadas em modos
diferentes. Baseado na V$SYSSTAT.

Guia Snapshot: dados atuais

- Current Operations: atividades correntes com suas work areas. Baseada na
V$SQL_WORKAREA_ACTIVE.
- PGA Memory Usage: operações em execução, com processo no SO, a instância,
informações de memória e se possível o SQL. Baseada na V$PROCESS. Memória em
bytes.

Guia PGA Advice

- Target Advice Size: simulação do hit ratio do cache para diferentes configurações do
parâmetro PGA_AGGREGATE_TARGET, baseado na view
V$PGA_TARGET_ADVICE.

127
- Advice Histogram: baseado na view V$SQL_WORKAREA_HISTOGRAM, simula o
comportamento dos work areas de acordo com um fator digitado.
Para tuning, avaliar as views V$PGA_TARGET_ADVICE (simulação de hit percentage
em referência ao tamanho da PGA) e V$PGA_TARGET_ADVICE_HISTOGRAM
(simulação baseada na V$SQL_WORKAREA_HISTOGRAM).
 Valores de hit ratio em 90% p/ BW e 60% para OLTP são válidos e suficientes.

Unit 11 Analyzing Physical and Logical Layout

Se uma query está consumindo recursos e o uso do índice está apropriado e o código
ABAP está otimizado, pode ser problema de índice fragmentado. Para desfragmentá-lo,
é necessário reorganizá-lo.
Um índice fragmentado consiste de blocos vazios ou páginas vazias ou com poucos
registros, sendo necessária a leitura de vários blocos para poucas informações.
Um exemplo de índices que precisam de reorganização são índices de tabelas de RFC.
Índices se tornam fragmentados:
- após archive de dados;
- após várias records serem removidas;
- tabelas dinâmicas.
Existem duas formas de se medir a fragmentação de índices:
- índex storage quality, que compara espaço livre e usado;
- deleted Leaf rows: compara número de leaf rows removidas com todas leaf rows.
Índex storage quality compara o espaço disponível com o espaço usado, onde os dados
são levantados como:
- espaço disponível: número de blocos de índices usados multiplicados pelo tamanho do
bloco, menos cabeçalho dos blocos;
- espaço usado: número de entradas no índice multiplicadas pela média de tamanho de
uma entrada mais 6 bytes para o ROWID e o cabeçalho para os blocos root e branch.
Devido à imprecisão da análise dos dois métodos, eles são apenas indicadores do nível
de fragmentação do índice, mas não podem dizer o quanto influencia na performance.
Para estimar a qualidade de storage, o report RSORATAD pode ser executado
diretamente na SE38 ou a funcionalidade pode ser acessada via DB02.
A percentagem exibida não é precisa, mas em índices abaixo de 70% a desfragmentação
é recomendada. Para índices pequenos, a percentagem pode ser baixa mesmo quando o
índice foi reorganizado. Para índices abaixo de 10 blocos, outro método é recomendado.
Vantagens:
- lock não é necessário;
- mostra informação exata sobre a fragmentação do índice;
Desvantagens:
- um índice por vez;
- execução demorada;
- aumenta a carga do sistema.
Estimar a proporção de leaf rows e deleted leaf rows pode ser feita via ANALYZE
INDEX VALIDATE STRUCTURE diretamente no Oracle ou via DB02. A relação entre
deleted/entries deve ser menor que 25%.
No Oracle 9, a adição de “online” permite a diminuição do lock, porém estatísticas não
são criadas.
Vantagens:
- diretamente no Oracle, todos índices podem ser analizados (via script);
- fornece informações exatas sobre fragmentação do índice.
Desvantagens:

128
- a tabela é bloqueada para comandos DML;
- execução demorada;
- aumenta carga no sistema.
Nos logs de execução de estatísticas do BRCONNECT, entradas informando que o
índice “is unbalanced” indicam que o índice está fragmentado. Razões para esta entrada
no log podem ser:
- índice não balanceado;
- parâmetro STATS_CHANGE_THRESHOLD no init<DBSID>.sap está com valor
baixo (padrão: 50%);
- a precisão do cálculo do índice está baixa, devido aos valores definidos na DBSTATC.
Vantagens:
- não é necessário lock;
- não é necessário aumento de carga no sistema;
Desvantagens:
- não há garantia que todos índices fragmentados sejam reconhecidos.
Para desfragmentar, 3 formas são possíveis:
- Drop and create view;
- Rebuild:
- vantagens: pode-se mudar de tablespace, cria nova árvore do índice, possível
mudar parâmetros sem necessidade de remover o índice, lock na tabela pode ser
evitado via parâmetro “online”.
- desvantagens: requer espaço em disco ou em memória.
Pode ser feito via BRSPACE, report RSANAORA e via DB02 (tables and
indexes monitor).
- Coalesce índex: para liberar espaço livre interno. Pode ser feito online.
- vantagens: não requer espaço adicional, solução rápida, libera blocos para uso
futuro, não causa lock;
- desvantagens: não pode mudar de tablespace, não resolve todos problemas de
storage quality baixa.

I/O contention
Contenção em I/O refere-se à altos tempos de I/O, por processos acessando o banco de
dados. Quando vários shadow proesses e o DBWR acessam o mesmo disco ao mesmo
tempo, contenção de I/O pode ocorrer.
Contenção de I/O pode ocorrer:
- design de aplicação não é eficiente;
- I/O não distribuído em vários discos;
- acessos pesados a tabelas ou índices não distribuídos em vários discos;
- configuração incorreta de hardware, file system e sistema operacional.
Contenção de I/O normalmente é causado por problemas de design da aplicação, então
este item deve ser verificado primeiro.
Para identificar, usar o submonitor “Filesystem requests” na ST04N, que exibe
informações baseadas na V$FILESTAT:
- I/O per File (data file);
- Total per devices;
- I/O per Path.
Verificar se a média de escritas e leituras está alta, acima de 20ms.
Verificar existência de eventos como “write complete waits”, “free buffer waits” e “log
file switch” (checkpoint not complete).
Para resolver problemas de contenção de disco:

129
- distribuir o I/O nos discos disponívels;
- distribuir o I/O em mais discos;
- usar discos mais rápidos;
- mover tabelas ou índices muito acessados para discos próprios.

130