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