Grupo de Estudo e Pesquisa

em ABAP

Coordenador: Paulo César Camargo

Desde Dezembro / 2001
Apresentamos:
Snote
LSMW
IDOC
ITS
Busines Connector
Integração JAVA/VB com SAP
Banco de Dados Lógico
SapScript x SmartForm
Ainda vamos apresentar:

BAPI
ALV
ABAP Orientado a Objetos
Modelagem de Dados
Desenvolvimentos em R.H.
Enhancements
Futuro da Linguagem ABAP
Fórum ABAP
 ABAP Performance Tuning

Apresentação: Gervásio Márcio de Oliveira

gervasio.oliveira@pimentelbr.com
Focos de Análise de Peformance ABAP

A análise de performance em programas ABAP se dá

em dois focos:

 Reduzir o tempo de processamento dos programas no

servidor de aplicação

 Reduzir os acessos ao servidor de banco de dados

O R/3 é um sistema Client/Server de três camadas

Os servidores de apresentação e de aplicação são

escalonáveis

O servidor de banco de dados não é escalonável

Análise individual de objetos

Pré-requisitos

Conhecer o objeto a ser analisado

Ausência de problemas em Basis

Disponibilidade de configuração e dados representativos

 QAS ou PRD
R/3 Workload Monitor - STAT

Demonstra a estatística para cada passo da transação

Analisando as estatísticas, decide-se pelo próximo passo na análise:

 Se há excessivo consumo de tempo de CPU, utilize ABAP
runtime analysis para analisar o processamento de tabelas
internas.
 Se o problema for durante o acesso ao servidor de banco de
dados, utilize o SQL Performance Trace.

A média de tempo de acesso ao banco de dados deve ser:

 Acesso seqüencial (select...endselect, select...into table):10 ms
 Leitura direta (select single...): 5 ms
 Modificação de dados (update, insert, modify, delete): 20 ms
SQL Performance Trace – ST05
Antes de ativar o SQL Trace, alguns cuidados devem ser
tomados:

 O código ABAP deve ter sido gerado

 O Programa deve ser executado uma vez para
evitar que a carga de buffer influencie no trace
 Deve-se certificar de não estar utilizando outra
sessão ativa, executando job em background ou
processos de update

O Trace pode ser ativado em produção sem riscos de

erros ou inconsistências

Apenas um arquivo trace pode ser ativado por servidor

de aplicação
ABAP Runtime Analysis – SE30

A análise de execução de um programa ABAP possui três fases:

 Limitar o universo da análise

 Obter e salvar os dados da análise
 Avaliar os resultados da análise

Sugere-se a utilização de um procedimento “top-down”

 Primeiro analisa-se o objeto por inteiro (full aggregation)

 Depois, limita-se o universo às partes críticas do progama
ABAP Debugger

O ABAP Debugger é, normalmente, utilizado para se verificar

o funcionamento de programas ABAP, uma vez que nos permite

uma visualização passo a passo

Algumas funções específicas podem ser utilizadas em um

contexto de análise de peformance, principalmente no
gerenciamento de tabelas internas

Grandes tabelas internas são problemáticas pois os comandos

que as regem (loop at...endloop, read table..., ou sort)
consomem muito tempo de CPU

Cuidado com o ABAP Debugger em produção

Acesso ao Servidor de Banco de Dados

Caminho de acesso apropriado

 O comando SQL lê muitos blocos de dados e transfere
muitos registros para o servidor de aplicação.
 A performance do banco de dados é satisfatória porque
menos de 5 blocos de dados são lidos por registro
transferido.

Caminho de acesso não apropriado

 O comando SQL lê muitos blocos de dados mas não
transfere muitos registros para o servidor de aplicação.
 A performance do banco de dados não é satisfatória
de acordo com o critério de 5 blocos de dados lidos por
registro transferido.
Caminho de acesso apropriado

Pode-se solucionar problemas de acesso:

 Reduzindo o número de linhas transferidas.Por exemplo,
otimizando a cláusula WHERE ou utilizando funções
agregadas
 Reduzindo o número de colunas transferidas.Por exemplo,
utilizando uma lista de campos adequada ou, no caso de
atualização, utilizando o comando UPDATE...SET field = value.
 Reduzindo o número de transferências de dados
 Eliminando o uso desnecessário de comandos SQL
Reduzindo o Número de Registros Transferidos

Para reduzir o número de registros a ser transferido, deve-se

definir uma cláusula WHERE mais seletiva possível
Um comando SELECT sem cláusula WHERE é indicação de
erro de programação
Não utilize CHECK em um comando SELECT...ENDSELECT.
Evite a utilização de SELECT *
Prefira INTO TABLE a INTO CORRESPONDING FIELDS
Quando possível, utilize a leitura por pacotes usando o
comando SELECT...INTO TABLE itab PACKAGE SIZE n ...
ENDSELECT.
Reduzindo o Número de Registros Transferidos

Utilize SELECT FOR ALL ENTRIES, evitando SELECT dentro de

LOOP
 Cuidado para não utilizar com tabelas internas vazias
 Registros duplicados nas tabelas internas devem ser eliminados
 O parâmetro rsdb/max_blocking_factor deve ser configurado de
acordo com as recomendações da SAP para o banco de dados
Utilize tabelas RANGE nos comandos SELECT
Utilize funções agregadas do banco de dados (COUNT,SUM,MAX,
MIN,AVG)
Utilize a cláusula HAVING para substituir CHECK
Quando for limitar o número de registros, utilize SELECT ... UP TO
n ROWS
Reduzindo o Número de Registros Transferidos

Utilize-se de ABAP JOIN lembrando-se de não envolver muitas

tabelas e não envolver tabelas bufferizadas
Quando lidar com POOLED ou CLUSTER TABLES, certifique-se
de que está utilizando a cláusula WHERE mais restritiva. Caso não
seja possível, verifique se não há outro método de pesquisa, tal
como uma tabela secundária
Tabelas “bufferizadas“ são lidas sem a necessidade de leitura do
banco de dados.
Caminho de acesso não apropriado

Pode-se solucionar problemas de acesso:

Resolvendo problemas técnicos no banco de dados

Alterando-se o código ABAP
Criando-se ou alterando-se índices secundários
Utilizando-se “Database Hints”
Resolvendo problemas técnicos no
banco de dados

Otimizar comandos SQL só faz sentido se o R/3 e o Banco de

Dados estiverem corretamente configurados
Tais soluções são de responsabilidade dos administradores do
R/3 e do Banco de Dados
Ferramentas importantes no diagnóstico de problemas técnicos
são os relatórios de GoingLive e EarlyWatch da SAP
Problemas de comunicação entre os servidores de aplicação e
de banco de dados podem ocorrer.
Fragmentação de índices de banco de dados podem interferir na
performance do sistema
Alterando-se o código ABAP

O Database Optimizer determina a estratégia de acesso à base

de dados
A cláusula WHERE é fundamental para a utilização plena dos
índices primários ou secundários
Cláusulas positivas devem se utilizadas sempre que possível,
operadores NOT e <> não podem ser utilizados por índices de
dados
Evite utilizar BETWEEN, LIKE ou OR em cláusulas WHERE
Não utilize operadores OR combinados com operadores
críticos, como NOT, <>, BETWEEN, LIKE, OR.
Criando-se ou alterando-se índices secundários

Um índice só faz sentido se o comando SQL que o utiliza retorna

menos de 5% dos registros da tabela
Índices não devem estar contidos em outros índices
Crie o mínimo de índices possível para a tabela
(O mínimo possível mas o máximo necessário)
Não crie índices com muitos campos. O ideal é um máximo de
4 campos por índice
Não altere índices standard sem recomendação explícita da SAP
Utilizando-se “Data base Hints”

Se há a necessidade de “forçar” o database optimizer

utilizar um índice específico, utilize database hints
(4.5A ou superior)
Só utilize em último caso, uma vez que qualquer
alteração no DBMS requer mudanças nos comandos
SQL
Se a indicação não puder ser interpretada, a mesma é
tratada como comentário e não afeta o acesso ao
banco de dados
Tabelas Internas

Standard Tables
 Podem ser acessadas utilizando-se a chave ou índice
 Se o acesso é feito pela chave, o tempo de resposta é
proporcional ao número de registros.
 A chave é sempre não unívoca.

Sorted Tables
 São sempre armazenadas e classificadas por suas chaves
 Podem ser acessadas utilizando-se a chave ou índice
 Se o acesso é feito pela chave, o sistema utiliza uma busca
binária para acessar a tabela.
 A chave pode ser únivoca ou não-unívoca.
Tabelas Internas

Index Tables
 Standard tables e sorted tables são genericamente
conhecidas como index tables, uma vez que podem ser
acessadas via índices

Hashed Tables
 Podem ser acessadas apenas pela chave primária.
 O tempo de resposta no acesso é constante.
 A chave primária deve ser única.
 Não se pode acessar via índice.
Tabelas Internas – Escolhendo o tipo ideal

Hashed Tables
 Deve ser utilizada sempre que houver o acesso a
registros com a utilização plena da chave primária
 Um máximo de 2 milhões de registros são permitidos.
Se houver a necessidade de mais registros, deve-se
dividir em mais de uma tabela ou execução.

Sorted Tables
 Deve ser utilizada em processamentos em massa com
chaves parciais utilizando-se uma cláusula WHERE
adequada
 Para standard e hashed tables, processar uma cláusula
WHERE requer uma leitura completa da tabela
Tabelas Internas – Escolhendo o tipo ideal

Standard Tables
 Deve ser utilizada sempre que houver a necessidade de
acesso a registros com variação de chaves
 Pode-se classificar por qualquer campo e, logo, pode
ser
acessada, por exemplo, por READ... BINARY SEARCH
 BINARY SEARCH só pode ser utilizado em comando
READ e não para outros acessos como LOOP
 Para uma standard table, INSERT funciona exatamente
como APPEND
Tabelas Internas – Carregando com Eficiência

Evite carregar uma tabela interna registro a registro,

prefira a carga de uma só vez utilizando INTO TABLE ou
APPENDING TABLE
Para adicionar registros de uma tabela interna para outra,
utilize os comandos APPEND LINES OF ..., ou INSERT
LINES OF...
Para acumular valores em tabelas internas, utilize o
comando COLLECT
Para excluir registros duplicados de uma tabela interna,
utilize o comando DELETE ADJACENT DUPLICATES
FROM itab.
Tabelas Internas – Acessando com Eficiência

Utilizando TRANSPORTING para especificar os campos que

realmente interessam, pode-se reduzir o tempo de
processamento de uma tabela interna
LOOP... TRANSPORTING deve ser usado em combinação
com uma cláusula WHERE
FIELD SYMBOLS para o ABAP são como ponteiros para
outras linguagens de programação
A fim de evitar custos de cópia na leitura de tabelas
internas, utilize a cláusula ASSIGNING em substituição a
INTO wa.
Tabelas Internas – Acessando com Eficiência

Leitura de registros individuais (READ TABLE...)

 Sempre que possível, utilize operações com índice
 Se puder definir a chave primária de forma plena, utilize
FROM wa ou WITH TABLE KEY
 Utilize BINARY SEARCH para standard tables
Leitura de registros em massa (LOOP AT, MODIFY,
DELETE)
 Utilize cláusula WHERE, evitando o uso de CHECK
 Para aumentar a eficiência, os campos a serem
comparados devem possuir o mesmo tipo
 Limite seu acesso aos registros que são necessários.
Para tanto, utilize LOOP/APPEND/INSERT/DELETE...
FROM...TO...
Interface de Usuário

Telas de seleção
 Definir campos de seleção (parameter, select-option)
como campos obrigatórios
 Verificar as estradas de usuários para evitar
processamentos inúteis
 Implementar os acessos SQL adequados às entradas
dos usuários
Ajudas de Pesquisa
 Definir ajudas de pesquisa nos padrões SAP standard
 Se necessário, definir campos de entrada como
obrigatório
Curso SAP

Recomenda-se o curso BC490 – ABAP Performance Tuning