apostila-basis

Prévia do material em texto

Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 1 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 2 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Integração do SAP R/3................................................................................................................................... 4 
Sistema Aberto .............................................................................................................................................. 5 
Arquitetura ..................................................................................................................................................... 6 
Middleware ..................................................................................................................................................... 6 
Navegação ..................................................................................................................................................... 8 
Mandantes do R/3 .......................................................................................................................................... 9 
Start/Stop R/3 ............................................................................................................................................... 11 
Visão Geral dos Trace Logs ........................................................................................................................ 14 
Administrando o Banco de Dados .............................................................................................................. 18 
Composição do tempo de resposta ............................................................................................................ 18 
Valores Ótimos dos Componentes ............................................................................................................. 22 
Principais Transações para Análise de Performance ................................................................................ 22 
Buffer de Programas e impactos na Performance. .................................................................................... 22 
Gerenciamento de Memória ........................................................................................................................ 23 
Gargalos de Hardware ................................................................................................................................. 24 
SAPGUI Installation ..................................................................................................................................... 25 
Checklists Diário .......................................................................................................................................... 30 
Backup Log – DB12 ..................................................................................................................................... 31 
Verifica todos os Servidores de Aplicação – SM51 .................................................................................... 31 
CCMS - Computing Center Management System – RZ20 ......................................................................... 33 
Failed Updates – SM13 ............................................................................................................................... 35 
System Log – SM21 .................................................................................................................................... 37 
Background Jobs – SM37........................................................................................................................... 39 
Locks – SM12 .............................................................................................................................................. 42 
Active Users – SM04 and AL08 ................................................................................................................... 44 
Check Spool – SP01 .................................................................................................................................... 45 
Batch Input Jobs, in error or to be processed – SM35 ............................................................................... 47 
ABAP Dump Analysis – ST22 ...................................................................................................................... 48 
Workload Analysis – ST03........................................................................................................................... 50 
Buffers – ST02 ............................................................................................................................................. 53 
Database Tasks............................................................................................................................................ 54 
Operating System Tasks ............................................................................................................................. 57 
Scheduled Weekly Tasks ............................................................................................................................ 59 
Checking for Tables nearing their Maximum Extents ................................................................................ 60 
Checking File System Space Usage ........................................................................................................... 61 
Printing/Spool System ................................................................................................................................. 65 
Impressoras com ligação direta na rede ................................................................................................... 65 
Impressora ligadas através de um micro na rede ..................................................................................... 68 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 3 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
Planing the system Clients .......................................................................................................................... 73 
Transport Management ............................................................................................................................... 83 
Transport Directory File Name Conventions .............................................................................................. 87 
Logon Balancing .......................................................................................................................................... 96 
Operation Mode ........................................................................................................................................... 99 
R/3 Upgrade and OCS Patches ................................................................................................................. 101 
Verificar o Patch Level do sistema. ........................................................................................................ 104 
SAPDBA Backup Tasks .............................................................................................................................105 
Aplicando uma Nota .................................................................................................................................. 122 
System Administration Assistant - SSAA ................................................................................................. 129 
Audit Information System - SECR ............................................................................................................. 130 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 4 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
Integração do SAP R/3 
 
 
O sistema SAP R/3 é baseado no modelo econômico, e suas áreas são: 
Financeira(FI), Controladoria(CO), Gerenciamento de Ativos(AA), Gerenciamento de Materias(MM), 
Planejamento e Produção (PP), Vendas e distribuição (SD), Gerenciamento de Qualidade (QM), Manutenção 
(PM), Recursos Humanos(HR) e outros. 
 
O Sistema SAP R/3 mantém uma integração entre os diversos módulos, o alto nível do aplicativo garante que 
todas as funções sejam acessadas diretamente. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 5 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Sistema Aberto 
 
O sistema R/3 garante uma portabilidade usando interfaces standards de comunicação, permitindo uma 
integração da aplicação com outras interfaces de dados. 
 
O sistema é compativel com diferentes sistemas operacionais, (NT, UNIX, AIX, DIGITAL, SOLARIS, 
AS400,LINUX) e diversos banco de dados (Oracle, SQL, Informix, DB2, SAPDB). 
 
E diversos protocolos TCP/IP, EDI, OLE e Open Interfaces. 
 TCP/IP: Network communication protocol 
 EDI (Electronic Data Interchange): Processo para troca de dados entre diferentes sistemas. 
 OLE (Object Linking and Embedding): Integra outros aplicativos com o R/3. 
 Open Interfaces: Desde optical archiving, barcoding devices, etc. 
 RFC (Remote Function Calls) usa protocolo CPI-C(IBM). 
 ALE: (Application Link Enabling): permite distribuição automática dos processos e a integração entre 
sistemas R/3 e R/2. 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 6 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Arquitetura 
 
O sistema R/3 é um software de arquitetura orientada em Client/Server. 
 
 Esta arquitetura permite que voce separe a aplicação lógica da apresentação e do banco de dados (3 
camadas). 
 Esta arquitetura permite que você ajuste a performance (Escalabilidade). 
 Instalação de servidores adicionais, 
 Buffer data , 
 Logon e load balancing (distribuição de usuários em servidores dedicados, 
 Distribuição da carga de Jobs. 
 
 
 
 
 
Middleware 
 
O sistema R/3 pode rodar em diferentes plataformas e com alta performace. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 7 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
O Middleware é responsável por: 
 
 Prover o runtime da aplicação do R/3. 
 Otimização da alpicação. 
 Define a estabilização da arquitetura. 
 Contém ferramentas de administração do ambiente. 
 Permite a distribuição de recursos e componentes. 
 Facilita a comunicação entre o R/3 e sistemas externos. 
 Features of Basis technology are: 
 Relacionamento com o banco de dados. 
 Interface grafica. 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 8 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Navegação 
 
 
 
 
 
 
O sistema R/3 possui um Help para cada campo e para cada tela. 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 9 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Mandantes do R/3 
 
 
Mandantes R/3 (ou clients R/3) são organizados independentemente. Cada um tem seu próprio ambiente de 
dados, com seus dados mestres e dados transacionais, dados de usuário e também seus próprios parâmetros 
de customização. 
 
Usuários em diferentes mandantes coexistem em um mesmo sistema R/3, mas seus dados são isolados e não 
podem ser acessados de outro mandante. Somente usuários com as autorizações necessárias podem 
visualizar ou processar dados em um mandante específico. Esse conceito de isolamento se reflete na 
estruturas das tabelas, tanto em nível de aplicação quanto de customização, que é um nível de adaptação 
dependente de cada implementação. 
 
O mandante 000 é definido como o padrão SAP e não pode ser modificado. Ele serve como um modelo para a 
criação de outros mandantes. 
 
O número máximo de mandantes em um sistema R/3 é de 997, número dificilmente atingido. 
 
Uma instancia (instance) é um grupo de serviços do R/3 que são iniciados e finalizados em conjunto. 
Normalmente, o termo é associado a um dispatcher e seus wp´s correspondentes, mas também pode ser 
considerado uma instancia um servidor executando somente o serviço de gateway do SAP. 
 
Central instance (instância central) é a combinação de um dispatcher com todos os processos do R/3, ou seja, 
a combinação DVEBMGS. Como exemplo disso, temos a instância C na figura acima, que mostra todos os 
processos do R/3 sendo executados, com a exceção do G (gateway), mas que também deve estar presente 
em uma central instance. 
 
Um servidor R/3 de aplicação consiste principalmente de um dispatcher, seus wp´s associados e seu banco 
de memória. 
Em um ambiente R/3, os conceitos “cliente” e “servidor” são geralmente abordados como software, desse 
modo vários servidores de aplicação podem ser executados em um só computador. 
 
Do ponto de vista de hardware, entretanto, um servidor de aplicação pode ser definido como um computador 
com pelo menos um dispatcher, configuração que também é chamada de instância de dialog. 
 
As seguintes restrições se aplicam ao número permitido para cada tipo de work process: 
- Dialog: cada dispatcher precisa de, pelo menos, dois wp´s de dialog 
- Spool: pelo menos um por sistema R/3, e os dispatchers podem ter mais de um spool 
- Update: pelo menos um por sistema R/3, e os dispatchers podem ter mais de um update 
- Background : pelo dois um por sistema R/3, e os dispatchers podem ter mais backgrounds 
- Enqueue : somente um wp de enqueue pode existir em um sistema R/3 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page10 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Uma vez estabelecida a conexão com um dispatcher através do SAPGUI, um sessão no sistema R/3 é 
iniciada para o usuário 
 
Os dados são passados do SAPGUI para o dispatcher usando o protocolo padrão do SAPGUI, que é 
transmitido sobre TCP/IP, e o seguinte processo é iniciado: 
- o dispatcher classifica o pedido e coloca-o na fila de pedidos apropriada 
- os pedidos são passados por ordem de chagada (FIFO) para um wp de dialog que estiver livre 
- o subprocesso taskhandler restaura o contexto do usuário num passo chamado “roll-in”. Esse 
contexto contém os dados principais das transações a serem executadas por esse usuário e 
também as autorizações específicas do usuário 
- o taskhandler chama, então, o processador dynpro para a conversão da tela em variáveis ABAP 
- o processador ABAP executa o código referente ao módulo “process after input” (PAI) da tela 
precedente seguido do módulo “process before output” (PBO) da tela subsequente. Caso seja 
necessário, ele também se comunica com o banco de dados. 
- o processador dynpro então converte as variáveis ABAP novamente em campos de tela. Quando 
o dynpro é finalizado, o taskhandler assume novamente o processamento. 
- O contexto do usuário é novamente armazenado na memória compartilhada dos WP´s. 
- Por fim, o resultado do processamento é retornado ao SAPGUI através do dispatcher e o WP´s 
que tratou do pedido pode ser liberado novamente 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 11 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
Se a transação envolver mais de uma tela, a sequência de passos de dialog descrita anteriormente é, 
geralmente, processada por diversos WP´s de dialog diferentes. Essa característica é conhecida como 
multiplexação de work process. 
 
Cada pedido de dialog é primeiro colocado pelo dispatcher na fila de pedidos de dialog, de onde ele poderá 
ser assumido por um WP de dialog disponível. 
O WP não realiza operações no banco de dados. Em vez disso, ele repassa comandos para os processos de 
banco de dados através da interface de programação do próprio banco. 
 
 
 
 
 
 
 
 
 
 
 
Start/Stop R/3 
 
Um usuário do sistema operacional loga usando o usuário <sid>adm 
Para iniciar o R/3, execute o script de inicialização startsap_<host>_instance_no> a partir do home directory 
do usuário <sid>adm. O script startsap_<host>_instance_no> tem um alias “startsap” 
startsap inicia o processo sopsocol, que é o coletor de estatísticas de dados do sistema operacional, caso o 
mesmo não esteja sendo executado 
startsap, então, chama o satrtdb, que inicia o banco de dados, caso o mesmo ainda não estaja sendo 
executado. 
Depois disso, o startsap inicia a central instance 
O administrador pode iniciar instancias adicionais e servidores de aplicação. Para iniciar instancias 
independentes do banco de dados, use o startsap: 
- startsap r3: verifica se o banco está no ar: se estiver, só a instancia é iniciada 
- startsap db: só o banco de dados 
- startsap all: default, inicia o banco e a instância 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 12 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
 
O gráfico acima mostra a inicialização do R/3 em maior detalhe. 
 
Passos para a inicialização: 
 
O script startsap chama o programa SAPSTART 
 
O programa SAPSTART lê o perfil de inicialização da instância e inicia os componentes do R/3 listados e 
outros serviços 
 
Em uma central instance, SAPSTART inicia os serviços message server, dispatcher, collector e sender. Em 
uma instância de dialog, somente o sender e o dispatcher são iniciados. O collector e o sender são usados 
para implementar os serviços centrais do log do sistema R/3. 
 
O dispatcher, então, assume o papel de pai dos processos a serem criados. Para isso, ele cria processos 
filhos como o gateway e os work processes, de acordo com os perfis de inicialização correspondentes. 
 
Os work processes, então , se conectam ao banco de dados, que, nesse momento, já deve ter sido 
inicializado. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 13 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Os ID´s de vários processos do R/3 na figura acima mostram a ordem de execução na inicialização. 
- sapstart cria o dispatcher, o collector e o sender 
- saposcol é iniciado diretamente do script startsap 
- o processo init do UNIX tem o ID 1 
 
 
De modo a construir um procedimento de inicialização, a sequência de leitura dos parâmetros (também 
conhecida como sequência de substituição de parâmetros) é definida como: 
- o R/3 processa os parâmetros como definido em seu código fonte no kernel R/3 (disp+work) 
- o perfil default é lido, e os parâmetros já definidos através do código fonte do kernel são 
substituídos pelos correspondentes encontrados no perfil default 
- o perfil da instancia é lido e, do mesmo modo, sobreescreve os valores anteriores 
 
 
 
Esse procedimento garante que os parâmetros de sistema vão refletir as configurações das três fontes. 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 14 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Durante a inicialização da base de dados, o startsap chama o script startdb, o qual acessa um arquivo de log 
para armazenar o processo de inicialização do banco. 
 
Todas os eventos importantes no processo, como inicialização e parada do banco de dados e qualquer erro 
na base, são anotados no arquivo de alerta do Oracle. Maiores detalhes são anotados no arquivo de trace. 
 
 
 
 
Visão Geral dos Trace Logs 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 15 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
O gráfico acima mostra os possíveis pontos de falha durante o processo de inicialização do R/3. 
 
Se ocorrer algum erro, a informação correta deve ser encontrada para se diagnosticar o problema. Abaixo 
comentamos algumas das possibilidades de erro: 
 
Se o acesso a recursos como os scripts startsap ou startdb, a causa pode ser, por exemplo: 
- as permissões de sistema de arquivo não estão corretas 
- o usuário <sid>adm não foi criado corretamente 
 
Se o banco de dados não foi iniciado ou o WP não pode se conectar ao banco, o R/3 não pode ser 
inicializado. Algumas das causas que podem levar a base de dados a falhar na inicialização são: 
- as variáveis de ambiente não foram configuradas corretamente 
- a base de dados está sendo executada no modo DBA 
- os arquivos da base estão corrompidos 
- osarquivos de dados foram renomeados no banco mas não no sistema operacional 
 
Se o R/3 não inicia, podemos verificar se: 
- o kernel do UNIX não foi configurado corretamente 
- existem erros no sistema de gerenciamento de memória 
- os perfis do R/3 não estão acessíveis 
 
Existem duas razões principais para parar um sistema R/3: 
 
Parada planejada: 
- para alterar os parâmetros dos perfis 
- para realizar uma atualização do R/3 
- para manutenção do sistema operacional ou do hardware 
 
Paradas não planejadas podem ocorrer por diversos fatores (por exemplo, um problema físico nos discos) 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 16 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Antes de parar o R/3, o administrador deve verificar: 
- visão geral dos jobs 
- verificar se nenhum job de background de qualquer servidor de aplicação está ativo ou sendo 
inicializado por processo externo 
- visão dos processos 
- verificar se o processo BTC está sendo executado nos servidores de aplicação 
- verificar a execução de processos de batch input 
- verificar se alguma atualização está pendente no banco de dados 
 
O administrador deverá decidir se interrompe ou não os processos que estiverem pendentes. Um aviso 
através de uma mensagem de sistema também pode ser útil. 
 
 
Para parar um sistema R/3, o administrador deve: 
- parar os servidores de aplicação (instâncias de dialog e também a central), o que pode ser feito de 
dois modos: através do CCMS ou usando o script stopsap_<host>_<instance_no> ou também 
através do alias: stopsap r3 
- parar a base de dados usando o stopsap all, o stopdb, pelo Oracle Manager ou pelo SAPDBA 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 17 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
Se a reconexão à base de dados (databese reconnect) estiver configurada no R/3, não é necessário parar um 
servidor de aplicação antes de um backup offline. Os buffers do R/3 não são esvaziados, e os work process 
configuram o status “reconnect” até que a base de dados seja reinicializada 
 
Durante um backup offline, a execução do banco de dados deve ser interrompida (shut down), e os WP´s 
receberão da base de dados uma mensagem com código de erro “reconnect” 
 
Cada vez que um pedido acontecer ou que o tempo de espera expire, o WP tentará se reconectar ao banco, 
por isso, antes da cada backup offline, o administrador deverá mandar uma mensagem avisando aos usuários. 
 
 
 
 
 
 
Se a base de dados não puder ser finalizado, a casa pode ser por: 
- o banco de dados está fazendo um rollback de transações abortadas pela finalização do R/3. 
Dependendo da última atualização do banco de dados em disco, esse processo pode levar muito 
tempo. 
- um backup online está sendo executado, e deve-se esperar que o mesmo termine 
 
Se não existir nenhuma razão natural para a demora, uma análise mais detalhada deve ser efetuada para se 
decidir o que fazer. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 18 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
Administrando o Banco de Dados 
 
Quando começamos a falar de banco de dados com R/3, nos preocupamos com Performance, segue uma 
série de dicas de como devemos analisar as transações voltadas para Performance de Banco de Dados 
independente de qual seja ele (SQL, Oracle, Informix, etc) 
 
- Fazer a pergunta: é um problema generalizado (afeta todos os usuários), localizado (afeta somente a 
execução de algumas transações) ou ainda um problema localizado que, quando ocorre, leva a um 
problema generalizado de performance (uma transação que, ao ser executada, “derruba” o servidor de 
banco de dados)? 
 
Parte dos ajustes que podem ser realizados a fim de melhorar o desempenho de um sistema R/3 estão 
relacionados a configurações dos componentes do R/3, como Sistema Operacional (tamanho de swap, 
presença de processos externos), Banco de Dados (parâmetros que controlam o tamanho do data buffer, 
shared pool), Instâncias R/3 (número e tipos de work processes, tamanho das regiões locais e 
compartilhadas de memória como buffers e extended memory) e Rede. 
Uma configuração não otimizada dos componentes acima leva a problemas generalizados de 
performance. 
 
Podem haver problemas de performance mais localizados, ocorrendo apenas em uma ou algumas 
transações, causados por fatores mais específicos. Detectadas estas transações, devemos submetê-las a 
uma análise mais detalhada, analisando os trechos que realizam processamentos muito longos, ligados à 
execução de programas ABAP ou ao acesso à tabelas no banco de dados. Após detectar o gargalo dentro 
da transação, devemos levantar as possíveis ações para amenizá-lo ou até mesmo eliminá-lo. 
Transações com gargalos durante suas execuções caracterizam problemas localizados de performance 
que podem, eventualmente, levar a problemas generalizados de performance. 
 
Composição do tempo de resposta 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 19 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Wait Time é o Tempo que o request do usuário aguarda na fila do dispatcher até ser “despachado” para um 
work process. 
 
 
 
 
 
Roll Time é oTempo para copiar a parte inicial do contexto do usuário(atributos de logon, autorizações, e 
outras informações relevantes) para dentro do work process – da roll memory (shared) para a roll_first da 
roll_area (local do WP). 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 20 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Load Time é o Tempo de carga do “load” (objeto compilado) de programa ABAP, telas, menus para dentro do 
buffer correspondente (na instância R/3). 
 
Processing Time é o Tempo gasto na execução dos comandos ABAP do programa chamado. 
Deve ser calculado da seguinte forma: 
Processing Time = TR – Wait – Roll – Load – DB Request Time 
 
DB Request Time é o Tempo aguardando a resposta do gerenciador de banco de dados a uma solicitação 
passada através da Database Interface (componente do WP). 
 
Enqueue Time é Tempo gasto para realizar “lock” – muito pequeno. 
 
 
 
 
 
 
CPU Time Corresponde ao tempo de utilização de CPU pelos componentes do Tempo de Resposta que 
envolvem CPU do Application Server (Roll, Load e Processing). Não é possível determinar quanto de CPU foi 
gasto em cada um dos componentes. Desta forma, parte do CPU Time está em Roll, parte em Load e parte 
em Processing. Espera-se que o CPU Time seja próximo do Processing Time; caso contrário, é provável que 
haja problemas de gargalos de hardware. 
 
Dispatch Time é o tempo gasto pelo request dentro do Work Process. A fórmula para o cálculo é: 
 Dispatch Time = TR –WaitTime. 
O Dispatch Time ajuda muito na análise do tempo de resposta, por exemplo: uma transação tem um TR médio 
de 4s, mas o Wait Time médio é 3.5s. Desta forma, o Dispatch Time é de 0.5s (rápido). O ajuste para esta 
situação é completamente diferente em um outro caso, onde o TR médio de uma transação também é 4s, mas 
o Wait Time é 0.2s. Neste caso, o Dispatch Time é 3.8s (alto). O que quer dizer que o dispatcher encontra um 
work process disponível rapidamente, mas o tempo gasto dentro dele é muito alto. Para acessar as 
estatísticas devemos usar a transação ST03. Em seguida escolhemos qual o período a ser analisado, o que 
deve ser feito cuidadosamente. Selecionamos o botão "Performance database", em 
seguida o aplication server a ser analisado, e finalmente o período de análise. A próxima tela apresenta as 
estatísticas do sistema, com os valores dos componentes do tempo de resposta para cada um diferentes 
tipos de processamento (Dialog, Update, Background, etc). 
 
Dialog Step: Database Time 
Network 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 21 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
Netw 
 
 
Se o processo requer dados do database, esta requisição é enviada para o interface database, mas antes 
pesquisa no shared memory buffers. 
 


 
 
Dialog Step: Roll out time 



Após terminar a transação o work process libera o contexto do usuário. 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 22 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
Valores Ótimos dos Componentes 
Wait Time < 10% do TR 
Roll Time (in/out) < 50ms 
Load Time < 10% do TR 
Processing Time < 40% do Dispatch Time (TR – Wait) 
DB Request Time < 40% do Dispatch Time (TR – Wait) 
CPU Time > (Processing Time/2) (maior que metade do Processing Time) 
 
Baseado nesses valores ótimos dos componentes do tempo de resposta, devemos analisá-los para cada 
tipo de processamento (para selecionar o tipo de processamento, devemos usar os botões na parte inferior 
da janela. 
 
Analisados cada um deles, podemos determinar os sintomas dos problemas que eles identificam: 
Wait Time Tempo de espera para obter work processes 
Roll Time (in/out) Problemas com CPU ou memória do Sistema SAP R/3 
Load Time Problemas nos buffers do Sistema SAP Sistema SAP R/3 (muito pequenos) 
Processing Time Problemas no programa ABAP ou no banco de dados. 
DB Request Time Problemas no banco de dados (SQL, índices, estatísticas, etc). 
CPU Time Problemas de programas ABAP, grandes tabelas, CPU, rede, S.O. 
 
 
 
 
 
Principais Transações para Análise de Performance 
 
ST03 Analisa o TR médio de um período. É possível realizar consultas “quebradas” por horário, memória, e 
principalmente por Transação (Transaction Profile). 
 
SM50/SM66 Visão geral de work processes 
 
ST06 Monitor de Hardware e Sistema Operacional. 
 
ST02 Monitor de memória e buffers 
 
ST04 Monitor do banco de dados 
 
ST05 SQL Trace 
 
SE30 Runtime Analysis (ABAP Trace) 
 
ST10 Estatísticas de chamadas a tabelas 
 
 
Buffer de Programas e impactos na Performance. 
 
Para que um programa chamado por um usuário seja executado, o seu “load” (objeto compilado) deve estar 
presente no buffer de programa da instância R/3 onde o usuário está conectado. Quando um programa é 
chamado pela primeira vez (ainda não está no buffer), o work process tenta localizar o “load” no banco de 
dados, nas tabelas D010*. Se não existir um load, o R/3 compila o programa fonte (parte do Load Time) e 
gera esse load. Em seguida,o WP lê esse load do banco de dados para dentro do buffer de programa (parte 
do DB Req. Time). A partir daí, este work process passa a executar o programa. Em execuções 
subseqüentes deste programa, os WP localizarão o programa em buffer (Load Time) e não haverá a 
necessidade de carregá-lo novamente a partir do banco de dados. 
Se o buffer de programa foi definido com um tamanho ideal, todos os programas chamados pelos usuários 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 23 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
serão carregados dentro dele e ainda sobrará espaço livre. Com o tempo, os mesmos programas vão sendo 
chamados, e a taxa de eficiência do buffer (hitratio) vai subindo, já que os programas são localizados em 
buffer, não havendo a necessidade de carregá-los a partir do banco. Contudo, se o buffer de programa for 
pequeno para a quantidade de programas chamados, haverá um momento em que ele estará 100% 
utilizado, só que mais programas ainda precisam ser carregados em buffer. A partir deste momento, 
começam o ocorrer SWAPS. O indicador “swaps” indica o número de objetos (no caso, programas) que 
foram retirados do buffer para que outros objetos pudessem ser carregados. Quando ocorrem swaps, 
podem aparecer os GAPS, que são resultado da fragmentação do buffer (desaloca um programa de 5MB e 
carrega outro de 4.5MB – gap de 0.5MB). 
Um buffer de programas fragmentado pode levar a um problema generalizado de performance. Se estão 
ocorrendo swaps, programas estão sendo retirados do buffer. Estes programas, se forem chamados mais 
tarde por usuários, deverão obrigatoriamente ser carregados a partir do banco de dados, e sua carga 
acarretará no swap de um ou mais programas do buffer, perpetuando o problema. Se um programa que já 
havia sido carregado em buffer sofreu um swap e precisa ser recarregado (reload), o WP fica ocupado por 
mais tempo, pois precisa carregar o “load” a partir do banco de dados (tabelas D010*) para dentro do Buffer 
de programa. 
- Ficando o WP ocupado por mais tempo (maior DB Request Time), diminui a disponibilidade de work 
processes. 
- Diminuindo a disponibilidade de work processes, aumenta a concorrência por eles. 
- Aumentando a concorrência por work processes, aumenta o Wait Time. 
- Aumentando o Wait Time, aumenta o Tempo de Resposta. 
 
O que observar: 
SM50/SM66 Action: Load Report 
Action: Direct Read / Table: D010* 
 
ST02 Program Buffer: 
HitRatio < 90% 
Swaps > 0 
Gaps = Free Space 
 
ST03 TR médio das transações alto 
Wait Time alto 
Load Time alto 
DB Request Time alto 
 
 
Gerenciamento de Memória 
 
Cada instância de R/3 aloca diferentes regiões de memória para diferentes propósitos. Algumas são 
consideradas LOCAIS, pois são acessíveis somente por um WP (roll area, paging area e heap area). Outras 
são consideradas COMPARTILHADAS, pois são acessíveis por todos os WPs (roll buffer, paging buffer, 
extended memory e buffer). 
As principais considerações na definição destas áreas são: 
- Garantir que a memória virtual total alocada pelo R/3 não exceda 50% acima da memória física do 
servidor 
- Evitar que um usuário, ao executar transações que consomem muita memória, entre em modo “PRIV”, 
pois o WP que estiver utilizando assume status “stopped” e fica exclusivo para este usuário, até que ele 
conclua a transação. Desta forma, diminui o número de WPs disponíveis, aumentando a concorrência, 
aumentando Wait Time, aumentando Tempo de Resposta. 
 
O que observar: 
SM50/SM66 Status: “stopped” / Reason: “PRIV” 
Err > 0 
 
ST02 SAP Memory: 
Extended Memory: Current Use > 80% 
 Administração Basis 
________________________________________________________________________________________Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 24 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
Heap Memory 
Mode List – memória alocada por sessão de usuários 
 
Gargalos de Hardware 
 
O tempo de processamento depende diretamente da capacidade e disponibilidade dos processadores do 
servidor. Quanto maior utilização ou concorrência, maior o tempo de processamento. Há ainda outros 
fatores que podem influenciar o tempo de processamento, como I/O e rede. 
O consultor deve analisar estes fatores em cada servidor que tem uma instância de R/3. Devem ser 
observados indicadores sobre utilização de CPU, processos que mais consomem CPU, load average e 
taxas de paginação do sistema operacional. Nunca deve haver um gargalo de hardware no servidor de 
banco de dados, o que causaria um problema generalizado de performance que afetaria todos os usuários. 
Os processos que mais consomem CPU devem ser processos ligados ao R/3 – work processes, saposcol, 
processos do banco de dados. Caso algum processo externo seja o responsável por um consumo 
considerável de CPU, o mesmo deve ser reavaliado e até mesmo cancelado. 
Quando há gargalos de hardware, os componentes do TR que utilizam CPU apresentam valores altos, 
embora o valor total de CPU seja baixo em relação a eles. Isso indica alguns “buracos” ocorridos durante 
estes componentes. Ex: Processing Time de 1s e CPU total de 300ms. O ideal seria que todo o Processing 
Time fosse preenchido com CPU Time. 
 
O que observar: 
ST06 CPU Idle < 20% 
Load Average > 3 
Pages Out 
Top CPU Processes (processos ligados ao R/3 ou processos externos?) 
 
ST03 CPU Time < (Processing Time/2) 
Processing Time alto 
às vezes, Roll Time e Load Time altos (porque dependem de CPU) 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 25 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Instalando o SAPGUI 
 
Para iniciar o processo de instalação de um client SAP R/3 é necessário posicionar-se no diretório onde se 
encontra o produto em referência. 
 
1. Abrir a pasta WIN32. Dando doble click. 
 
 
 
2. Na tela seguinte escolha o programa Setup.exe. 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 26 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
3. Click no botão Next. 
 
 
 
4. Selecione Local Instalation e clicle em Next.. 
 
 
 
 
 
 
 
5. Verifique o folder destino e click Next.. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 27 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
6. Selecione Sapgui e click Next. 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 28 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
7. Selecione English e click Next. 
 
 
 
 
 
8. Verifique o Sapgui work diretory e click Next. 
 
 
 
 
 
 
 
 
 
9. Verifique o PATH de Documentação e click Next. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 29 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
10. Click Next. 
 
 
 
 
 
 
 
 
 
 
11. Icon Group click Next. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 30 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
12. Clicle install para iniciar o processo. 
 
 
13. Aguarde o processo para finalizar. 
 
 
 
 
 
Checklists Diário 
Veremos as principais transações diárias que devemos analisar : O CCMS (Computing Center Management 
System) é uma parte do sistema de administração basis do R/3 que fornece ferramentas para administração 
de: 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 31 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
- performance do sistema R/3 
- banco de dados e backups 
- carga de trabalho do sistema 
- velocidade de resposta 
- segurança dos dados 
 
 
Backup Log – DB12 
 
– Verifica os logs dos backups diários. 
 
 
Verifica todos os Servidores de Aplicação – SM51 
 
SM51 – Permite visualizar todos os servidores de seu landscape (Database server e Application server). 
 
 
Dando um duplo clique na linha, você verifica o que está processando no servidor. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 32 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 visualisa detalhes do processo (arquivo de trace do WP). Podemos também visualizarmos pelo sistema 
operacional em /sapmnt/<SID>/<instance>/work 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 33 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
CCMS - Computing Center Management System – RZ20 
 
 
A transação RZ20 é centralizada no alert monitor. Você pode gerenciar seu sistema através deste monitor 
central. 
O alerta do Oracle só foram adicionados no rel. 4.5. 
 
De um duplo clique no Operating System e verifique os alertas. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 34 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
De um duplo clique na linha escolhida e verifique os detalhes. 
 
 
 
 
o ícone mostra os valores setados para o alerta. 
 
 Administração Basis 
________________________________________________________________________________________Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 35 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
No campo Change from YELLOW to Red 200 PG/S – mostra que ao atingir uma paginação de 200 páginas 
por segundo o MTE CLASS de page_out fica vermelho. 
 
O ícone na tela inicial, inicializa a analisa da ferramenta. 
 
 
 
 
Failed Updates – SM13 
•Esta transação mostra alterações canceladas. Isto nunca deve ocorrer em produção. Estas alterações devem 
ser reporatadas e corrigidas pela equipe de desenvolvimento. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 36 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
De um clique no botão para visualizar os Updates Fails 
 
 
 
 
 
 
 
 
 
 
 
 
Dê um duplo clique numa linha que contem erros. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 37 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
Dê um duplo clique na linha que contém o erro, e visualize o Abap dump. 
 
 
 
Você pode chamar o programa pelo Editor ou visualizar o Dump pelo ABAP Short dump. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
System Log – SM21 
 
•Todas as manhãs as mensagens de erro devem ser analizadas e corrigidas. Este procedimento deve ser 
documentado no formulário de Gerenciamento de Tasks. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 38 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
A empresa deverá seguir como padrão o acompanhamento das seguintes transações conforme 
procedimentos ASAP. Abaixo segue documento para se fazer o acompanhamento: 
 
 
System Name_____________ 
Date_____________ 
 
SM21 System Log 
Data Mensagem de erro Ação OSS Note 
1/1/91 User Lockout (I001748) Unlock user none 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 39 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
No campo Problem Class , você tem classe K – erros para analise de basis e W – erros de warning. 
 
 
Backgroud Jobs – SM37 
•O administrador deve examinar todos os jobs cancelados. Esses jobs devem ser analizados e reparados se 
necessário. Problemas e resoluções devem ser documentados. O administrador deve checar todos os logs, 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 40 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
incluindo listagem de output os logs de aplicações. Devem ser liberados todos os jobs schedulados pelos 
usuários que não foram liberados. 
 
 
 
 
 
 
 
 liberar um job. 
 
 cancelar um job. 
 
 deletar um job já agendado. 
 
 visualizar spool do job referenciado. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 41 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 visualizar detalhes do job. 
 
 visualizar o passo atual do job. 
 
 visualizar todos os steps do job 
 
 
 
 
•RSBTCDEL 
•Este programa limpa os jobs em background. Este programa é usado para remover todos os registros de jobs 
executados com sucesso nos ultimos X dias. 
Frequencia Recomendada : diário. 
Nome do Job : SAP_REORG_JOBS 
Variante: sim 
Client Depende: sim 
 
 
•RSPO0041 
•Este programa é responsável por remover objetos do spooling. A fila de impressão vai aumentando com 
relatórios que falharam ou não, cabendo ao administrador o critério para deleção. 
Frequencia Recomendada : diário. 
Nome do Job : SAP_REORG_SPOOL 
Variante : sim. 
Client Depende: sim 
 
 
 
 
 
 
 
 
 
•RSM13002 
•Este programa limpa os processos requisitados de Update. É necessário somente se a deleção automatica 
dos processos requisitados de updadte estiver setado TURNED OFF. Frequencia Recomendada : diário. 
Nome do Job : SAP_REORG_UPDATERECORDS 
Variante: não 
Client Depende: não 
 
 
•RSBDCREO 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 42 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
•Este programa é responsável em limpar o log dos batch input. 
Frequencia Recomendada : diário. 
Nome do Job : SAP_REORG_BATCHINPUT 
Variante : sim. 
Client Depende: sim 
 
 
•RSSNAPDL 
•Este programa limpa os dumps gerados por programas abap/4. Processar na madrugada. Frequencia 
Recomendada : diário. 
Nome do Job : SAP_REORG_ABAPDUMPS 
Variante: sim 
Client Depende: não 
 
 
•RSBPCOLL 
•Este programa acumula informações de de estatística, ele calcula a média de tempo de processamentodo job 
que termino com sucesso. Estes dados são armazenados numa tabela chamada BTCJSTAT, esta tabela 
necessita periodicamente de reorganização. 
Frequencia Recomendada : diário. 
Nome do Job : SAP_COLLECTOR_FOR_JOBSTATISTIC 
Variante : não. 
Client Depende: não 
 
 
•RSBPSTDE 
•Este programa limpas informações de estatísticas. Este job deleta as informações que não foram alteradas 
num determinado período. 
Frequencia Recomendada : mensal. 
Nome do Job : SAP_REORG_JOBSTATISTIC 
Variante: sim 
Client Depende: não 
 
 
•RSCOLL00 
•Este programa coleta dados de performance. 
Frequencia Recomendada : toda hora. 
Nome do Job : SAP_COLLECTOR_FOR_PERFMONITOR 
Variante : não. 
Client Depende: não 
 
 
 
Locks – SM12 
•De tempos em tempos, o usuário pode travar um objeto (lock an object) quando esse está trabalhando, e se 
ocorrer um erro de perda de conexão ou erro do programa, esse objeto pode ficar travado (lock). Esta 
transação verifica e corrige isto. 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 43 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 44 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando SgarbiActive Users – SM04 and AL08 
 
Estas transações mostram todos os usuários que estão logados no sistema. 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 45 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Mostra os usuários por instance (AL08). 
 
 
 
 
 
 
 
 
 
 
 
Check Spool – SP01 
•Falha de impressão de Jobs pode ser restartado. Geralmente essas falhas ocorrem por problemas com o 
client (ex. o PC esta processando e o SAPLPD está desabilitado). Por causa que o R/3 encaminha os jobs de 
impressão para a fila destino, não são garantidos os jobs de impressão com status de sucesso para o controle 
de saida. Para jobs de impressão critica, deve ser confirmado com o usuário final se a impressão está ok 
antes de deletar o spool. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 46 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
 
 
Marque a linha e clique no para visualizar o relatório. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 47 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Clique no para visualizar o status da impressora. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Batch Input Jobs, in error or to be processed – SM35 
•Batch Input logs devem ser checados após cada processamento. O batch input processado marca o erro e se 
for possível você pode repará-lo. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 48 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
ABAP Dump Analysis – ST22 
 
Análise de dump. 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 49 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
De um duplo clique no erro escolhido e analise o ABAP Dump. 
 
O botão visualiza as seções do abap dump. 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 50 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
Workload Analysis – ST03 
•Quando o sistema R/3 estiver processando, o administrador deve analizar o numero de workload, 
especialmente para prever problemas de performance. Em se tendo uma visão do quadro limpo do 
acompanhamento do sistema, é mais fácil quando houver um problema de performance, achar rapidamente o 
mesmo. 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 51 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
Clique no botão 
 
 
 
 
 
 
 
 
Marcar Last minute load .... 
 
 
 
 
 
Temos que analisar o Av. response time . 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 52 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
Clique no Transaction profile. 
 
 
 
Posicione o cursor na coluna Response Time e clique no SORT. 
 
Poucas transações standard superam 1 segundo no tempo de resposta: 
Create Sales Order – VA01 – 1,500 ms 
Change Sales Order – VA02 – 1,500 ms 
Display Sales Order – VA03 – 1,000 ms 
Create Billing Document – VF01 – 1,500 ms 
Create Delivery - VL01 – 2,000 ms 
Maintain Master data HR – PA30 – 1,000 ms 
 
 
. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 53 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Buffers – ST02 
•Os Buffers devem ser monitorados regularmente pela equipe de Basis, como, taxas de proporção, espaços 
livres, e areas de swap. Este processo ajuda o administrador a se familiarizar com os valores para numa 
próxima checagem ir analizando os numeros obtidos. 
 
 
 
 
 
A- Hit Ratio, deve ser maior ou igual a 95%, quando o sistema inicia este valor é baixo, porem com o passar 
do tempo ele aumenta. Ele indica a utilização dos buffers. 
B- Swaps, o valor deve ser menor que 1,000. O swap ocorre quando dados necessários não estão no buffer. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 54 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
Database Tasks 
•AL02 Database Alert Monitor 
•Todos os alertas devem ser reconhecidos, analizados, corrigidos e documentados. 
 
 
 
 
 
 
Clique na linha para visualisar o detalhe. 
Drill down na tablespace PSAPBTABD (Oracle), mostra o gráfico a seguir. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 55 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
A- Indica a data atual, B- o passado e C- o futuro. 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 56 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
•ST04 Database Logs 
•Monitora os logs de erros do database. 
 
 
 
 
Clique no botão Detail Analysis Menu – Error Logs. 
 
 
 
 
Verifique as mensagens de erros. 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\BasisII versao 2.doc Page 57 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Operating System Tasks 
 
OS06 – Verifica os logs do sistema operacional. 
•Todos os alertas devem ser reconhecidos, analizados, corrigidos e documentados. 
 
 
 
Clique na opção Detail analysis menu. 
 
 
 
 
Selecione OS Log. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 58 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Esta tela acima é similar ao event log do NT. 
 
 
 
A tela abaixo é similar ao UNIX log. 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 59 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
Scheduled Weekly Tasks 
 
DB02 - Storage Management 
•Monitora o database, tabelas e index. 
 
 
 
 
Selecione DB Space History – clique no botão Files. 
 
 
3- Mostra o espaço livre. 
 
 
 
 
 
Para Oracle Selecione Back e clique na opção Tablespace. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 60 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
Esta tela mostra o espaço livre das tablespaces, para obter o histórico da tablespace, basta dar um duplo 
clique. 
 
 
 
A coluna A- mostra o espaço livre (Kbyte), a coluna B- mostra o total usado (Kbyte). 
 
 
 
 
 
 
 
 
 
 
 
 
Checking for Tables nearing their Maximum Extents 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 61 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
•Este ponto é muito importante para uma análise de performance. No Oracle 8.x o valor do MaxExtents é 
teoricamente ilimitado, mas na prática devemos manter um número não tão alto de extents. 
 
Quando uma tabela tem muitos extents (acima 100), esta deve ser reorganizada, para se obter um acesso 
mais rápido aos dados contidos nela. 
 
Para verificarmos quais tabelas estão com mais de 100 extents, devemos proceder da seguinte maneira: 
Execute a transação SA38 e execute o programa RSORATC5. 
 
 
 
5- marque com o valor 100, e execute. 
 
A coluna 7- mostra a quantidade de extents existentes, caso seja maior que 100, a reorganização do objeto ou 
da tablespace é necessária. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Checking File System Space Usage 
 
Entre na transação RZ20. 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 62 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
Selecione SAP CCMS Monitor Templates – Operating System – Filesystem . 
 
 
 
De um duplo clique na linha escolhida ou clique no botão Complete Alerts. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 63 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
o ícone mostra os valores setados para o alerta. 
 
 
 
 
 
 
No campo Change from YELLOW to Red – mostra que no filesystem só temos 500MB de espaço livre. 
 
O ícone na tela inicial, inicializa a analisa da ferramenta. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 64 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 65 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 Printing/Spool System 
 
Existem dois tipos básicos de ligação entre o R/3 e as impressora que ele poderá utilizar, são eles: 
 Impressoras com ligação direta na rede (impressora remota) 
impressora ligadas através de um micro na rede. 
 
 
Impressoras com ligação direta na rede 
 
 
Neste caso o procedimento será o seguinte: 
 
1. Indentifique o endereço IP que esta impressora possuirá na sua rede e o endereço IP do micro que está 
administrando a mesma. 
2. Cadastre-os no arquivo hosts no servidor R/3 (/etc/hosts). 
3. Crie esta impressora no sistema operacional (UNIX) do servidor R/3. 
4. Teste-a com enviando algum documento para impressão através do sistema operacional (UNIX) do 
servidor R/3. 
5. Concluido a instalação da mesma no sistema operacional, vamos agora criar está impressora no R/3 
através da transação SPAD. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 66 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6. Selecione o botão dispositivos de saída, está tela exibirá todos os dispositivos de saída configurados para 
o R/3. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 67 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
7. Selecione o botão modificar e para criar um novo dispositivo acesse selecione o botão criar. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8. Na tela de criação do dispositivo você terá as seguintes informações: 
 
 Dispositivo de saída: nome que este dispositivo será chamado no R/3. 
 Nome Breve: abreviação do nome do dispositivo de saída no R/3. 
 Ctg. de dispositivo: selecione o driver que seja compatível com o dispositivo de saída. 
 Servidor de edição: selecione o servidor R/3 que irá administrar este dispositivo. 
 Impressora host: informe o nome que este dispositivo possui no sistema operacional (obedecendo letras 
maiúsculas e minúsculas). 
 Classe aparelho: selecione o tipo de dispositivo que está sendo instalado, no nosso caso Impressora 
normal. 
 Tipo acoplam.p/spool host: informeo modo que o R/3 se comunicará com o dispositivo, no nosso caso nós 
utilizaremos a opção L - Impressão local via LP/LPR. 
 Modelo: informe o modelo da impressora (Opcional). 
 Localização: informe aonde a impressora está localizada (Opcional). 
 Mensagem: informe uma mensagem que o usuário visualizará impressão. 
 Bloquear impressora págSAP: se selecionado bloqueia a utilização deste dispositivo. 
 Folha de rosto SAP: se selecionado emitirá uma folha de rosto para cada trabalho a ser impresso. 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 68 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
9. Preenchido estas informações, salve-as e a partir deste momento este dispositivo estará disponível para 
os usuários do R/3. Observe o exemplo abaixo. 
 
 
 
 
 
 
Impressora ligadas através de um micro na rede 
 
 
Segue abaixo o procedimento para instalar impressoras com está característica no sistema R/3. 
 
1. A impressora a ser utilizada pelo R/3 deve estar instalada no sistema operacional do micro que possui 
acesso ao R/3. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2. Deverá ser acionado um aplicativo chamado SAPLPD que é instalado junto com o front end. Você 
observará que ao acioná-lo ele exibirá o endereço IP que este micro está utilizando na rede e o nome do 
mesmo, como no exemplo abaixo. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 69 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3. Estes dois dados deverão constar no arquivo hosts (/etc/hosts) do servidor R/3, viabilizando a 
comunicação do servidor (UNIX) com este micro (Windows). Note que este micro deverá possuir um 
endereço IP fixo na rede, pois se o mesmo está configurado para receber o seu endereço 
automaticamente através do DHCP ele poderá ter o seu endereço IP trocado tornando a comunicação 
com o servidor R/3 (UNIX) inviável pois o mesmo não será atualizado pelo DHCP. 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 70 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
4. No R/3 você acessará a transação SPAD. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5. Selecione o botão dispositivos de saída, está tela exibirá todos os dispositivos de saída configurados para 
o R/3. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 71 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
6. Selecione o botão modificar e para criar um novo dispositivo acesse selecione o botão criar. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7. Na tela de criação do dispositivo você terá as seguintes informações: 
 
 Dispositivo de saída: nome que este dispositivo será chamado no R/3. 
 Nome Breve: abreviação do nome do dispositivo de saída no R/3. 
 Ctg. de dispositivo: selecione o driver que seja compatível com o dispositivo de saída (Neste caso, 
independente da impressora que estamos utilizando, será selecionado a opção SAPWIN - Rel 
4.x/SAPLPD 4.x ONLY!). 
 Servidor de edição: selecione o servidor R/3 que irá administrar este dispositivo. 
 Host de comutação: informe o nome do micro que possui a impressora que será instalada. 
 Opções...: ele exibirá três campos de configuração, são eles: Tmp.estr.conex (tempo de timeout para 
conexão em segundos, padrão 60s), Tempo resposta (especifica o tempo limite para receber uma 
resposta do dispositivo, o valor padrão está definido no parâmetro rspo/tcp_timeout_connect no profile da 
instance) e Número de porta (número da porta disponível para comunicação com o dispositivo). 
 Impressora host: informe o nome que este dispositivo possui no sistema operacional (obedecendo letras 
maiúsculas e minúsculas). 
 Classe aparelho: selecione o tipo de dispositivo que está sendo instalado, no nosso caso Impressora 
normal. 
 Tipo acoplam.p/spool host: informe o modo que o R/3 se comunicará com o dispositivo, no nosso caso nós 
utilizaremos a opção L - Impressão local via LP/LPR. 
 Modelo: informe o modelo da impressora (Opcional). 
 Localização: informe aonde a impressora está localizada (Opcional). 
 Mensagem: informe uma mensagem que o usuário visualizará impressão. 
 Bloquear impressora págSAP: se selecionado bloqueia a utilização deste dispositivo. 
 Folha de rosto SAP: se selecionado emitirá uma folha de rosto para cada trabalho a ser impresso. 
 
 
 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 72 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Observe que os campos Host de comutação e o botão opções apareceram para o preenchimento depois que 
você tentar salvar as configurações. 
 
 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 73 of 137 
Last printed 24/11/2010 
 
Preparado : Luiz Fernando Sgarbi 
 
 
 
Planing the system Clients 
 
 
Mandantes R/3 (ou clients R/3) são organizados independentemente. Cada um tem seu próprio ambiente de 
dados, com seus dados mestres e dados transacionais, dados de usuário e também seus próprios parâmetros 
de customização. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Descrições dos Clients: 
 
Customizing/Development – Aqui se cria o protótipo do sistema, todas as customizações de aplicações são 
desenvolvidas neste client. 
Sandbox – É um client de teste geral, inicialmente criado do client 000, é utilizado pelos Key-users se 
familiarizarem com o sistema, testarem aplicações e customizações. 
Customizing/Development Testing – É usado para testarem as mudanças feitas no client de customizing e 
development. 
Quality Assurance Testing – É usado para testar as mudanças de configuração e customizações feitas no 
client de customizing e development. E serve para testar o transporte dessas informações. 
End-User Training – É o treinamento dos usuários finais. 
Customizing/Development Master – É usado para checar todas as mudanças feitas antes de se transportá-
las para produção. 
 
 
 
 
Protótipo Quality Produção 
200 
210 
220 
2XX 
300 
310 
320 
340 
400 
DES QAS 
PRD 
Master Client 
Development 
Sand Box 
Master Client 
Quality Testing 
Batch Input 
Integrated Testing 
Production 
 Administração Basis 
________________________________________________________________________________________ 
 
 
Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 74 of 137 
Last printed