Apostila Basis Iniciantes

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

________________________________________________________________________________________
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

________________________________________________________________________________________
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


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.

________________________________________________________________________________________
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.


________________________________________________________________________________________
Navegação
O sistema R/3 possui um Help para cada campo e para cada tela.


________________________________________________________________________________________
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


________________________________________________________________________________________
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


________________________________________________________________________________________
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


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.


________________________________________________________________________________________
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


________________________________________________________________________________________
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
- os arquivos 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)


________________________________________________________________________________________
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


________________________________________________________________________________________
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.


________________________________________________________________________________________
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


________________________________________________________________________________________
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).


________________________________________________________________________________________
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 –Wait Time.
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


________________________________________________________________________________________
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.


________________________________________________________________________________________
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

________________________________________________________________________________________
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%

________________________________________________________________________________________
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)


________________________________________________________________________________________
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.


________________________________________________________________________________________
3. Click no botão Next.
4. Selecione Local Instalation e clicle em Next..
5. Verifique o folder destino e click Next..


________________________________________________________________________________________
6. Selecione Sapgui e click Next.


________________________________________________________________________________________
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.


________________________________________________________________________________________
10. Click Next.
11. Icon Group click Next.


________________________________________________________________________________________
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:


________________________________________________________________________________________
- 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.


________________________________________________________________________________________
visualisa detalhes do processo (arquivo de trace do WP). Podemos também visualizarmos pelo sistema
operacional em /sapmnt/<SID>/<instance>/work


________________________________________________________________________________________
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.


________________________________________________________________________________________
De um duplo clique na linha escolhida e verifique os detalhes.
o ícone mostra os valores setados para o alerta.


________________________________________________________________________________________
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.


________________________________________________________________________________________
De um clique no botão para visualizar os Updates Fails
Dê um duplo clique numa linha que contem erros.


________________________________________________________________________________________
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.

________________________________________________________________________________________
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


________________________________________________________________________________________
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,

________________________________________________________________________________________
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.


________________________________________________________________________________________
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.
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

________________________________________________________________________________________
•Este programa é responsável em limpar o log dos batch input.

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
•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.
Nome do Job : SAP_COLLECTOR_FOR_JOBSTATISTIC
Variante : 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
•RSCOLL00
•Este programa coleta dados de performance.
Frequencia Recomendada : toda hora.
Nome do Job : SAP_COLLECTOR_FOR_PERFMONITOR
Variante : 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.


________________________________________________________________________________________


________________________________________________________________________________________
Active Users – SM04 and AL08
Estas transações mostram todos os usuários que estão logados no sistema.


________________________________________________________________________________________
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.


________________________________________________________________________________________
Marque a linha e clique no para visualizar o relatório.


________________________________________________________________________________________
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.


________________________________________________________________________________________
ABAP Dump Analysis – ST22
Análise de dump.


________________________________________________________________________________________
De um duplo clique no erro escolhido e analise o ABAP Dump.
O botão visualiza as seções do abap dump.


________________________________________________________________________________________
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.


________________________________________________________________________________________
Clique no botão
Marcar Last minute load ....
Temos que analisar o Av. response time .


________________________________________________________________________________________
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


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.


________________________________________________________________________________________
A- Indica a data atual, B- o passado e C- o futuro.


________________________________________________________________________________________
•ST04 Database Logs

•Monitora os logs de erros do database.
Clique no botão Detail Analysis Menu – Error Logs.
Verifique as mensagens de erros.


________________________________________________________________________________________
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.


________________________________________________________________________________________
Esta tela acima é similar ao event log do NT.
A tela abaixo é similar ao UNIX log.


________________________________________________________________________________________
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.


________________________________________________________________________________________
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


________________________________________________________________________________________
•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.


________________________________________________________________________________________
Selecione SAP CCMS Monitor Templates – Operating System – Filesystem .
De um duplo clique na linha escolhida ou clique no botão Complete Alerts.


________________________________________________________________________________________
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.


________________________________________________________________________________________


________________________________________________________________________________________
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.


________________________________________________________________________________________
6. Selecione o botão dispositivos de saída, está tela exibirá todos os dispositivos de saída configurados para
o R/3.


________________________________________________________________________________________
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: 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.


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.


________________________________________________________________________________________
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.
Produção
Protótipo Quality
PRD
DES QAS
400
300
200 Master Client Production
Master Client
310
210 Quality Testing
Development
320
220 Batch Input
Sand Box
340
Integrated Testing
2XX
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.


________________________________________________________________________________________
Instance Changes and Client-Independent Protection: Client

Client Transports for Client– Object Change Copier and Comparison
Dependent Objects Tool
DES 200 No change allowed No changes to Protection Level 0:
Instance repository and client- No restriction
N 00 ind. customizing
allowed
210 Automatic recording Changes to repository Protection Level 0:
of changes and client-ind. No restriction
customizing allowed
220 Automatic recording No changes to Protection Level 0:
of changes repository and client- No restriction
independent cust. obj.
230 No change allowed No changes to Protection Level 0:
repository and client- No restriction
ind. customizing
allowed
QAS 300 No changes allowed No changes to Protection Level 0:
InstanceN repository and client- No restriction
 00 independent cust. obj.
310 No changes allowed No changes to Protection Level 0:
repository and client- No overwriting
PRD 400 No changes allowed No changes to Protection Level 1:
Instance repository and client- No overwriting
N 00 independent cust. obj.


________________________________________________________________________________________
Na política de Refresh, podemos adotar.
Produção
Protótipo Quality
PRD
DES QAS
300
200 Master Client
Master Client
310
210 Quality Testing
Development
400
220 Production
Sand Box
320
Batch Input
340
2XX
Integrated Testing
O client de produção nunca sofrerá refresh, somente será atualizado por transporte.
Na política de Transporte, podemos adotar.


________________________________________________________________________________________
Produção
Protótipo Quality
PRD
DES QAS
300
200 Master Client
Master Client
310
210 Quality Testing
Development
400
220 Production
Sand Box
320
Batch Input
340
2XX
Integrated Testing
Cópia de Client
Verifique e avalie o espaço disponível nas tablespaces (via sapdba). Se for acessar o SAPDBA remotamente,
utilize o Net Meeting


________________________________________________________________________________________
Desligue o Archive do banco de dados (via sapdba)
Veja o tipo de perfil a ser usado para a cópia ideal do client.
1. Verifique se a entrada do client de destino já foi criada na transação SCC4.
2. Se a entrada para o client de destino não existir você deverá criá-la.
3. Logue no client de destino com o usuário SAP* , caso o client de destino seja um novo client, a senha para
este usuário será PASS.
4. Entre na transação SCCL para configurar a cópia do client.


________________________________________________________________________________________
5. Escolha o perfil para cópia (SAP_ALL – Perfil para cópia completa), escolha o client de origem do dados e
o client de origem dos dados de usuários.
6. Escolha a opção execução de fundo (executar em background).
7. Confira os dados e clique no botão continue.


________________________________________________________________________________________
8. Aperte o botão Escalonar job (Date/Time) e confira o dados para a cópia.
9. Na próxima tela será solicitado um dispositivo de saída para impressão do andamento da cópia (Se você
não quiser este protocolo basta não selecionar nenhum dispositivo) clique em gravar.


________________________________________________________________________________________
10. SCC3. Escolha o client de destino que você deseja ver o protocolo.
11. Clique no botão all clients e ecolha seu client destino para o status atual.


________________________________________________________________________________________
Sistema de Transporte
Por causa do dinâmismo de acesso as tabelas durante a customização, ambos clients (dependente e
independente) não estão protegidos contra regravação. As tabelas são bloqueadas enquanto as transações
de customizações estão sendo usadas, mas são desbloqueadas quando as alterações são completadas e
salvas na request.
Para ativar o LOGIN para Changes to Customizing Tables, selecione a transação OY18.
Geralmente todos os objetos são transportados para o sistema Destino na qual eles existem no sistema Fonte,
os objetos transportados do sistema fonte regravam os objetos no sistema destino que tem o mesmo nome,
estes objetos são deletados do sistema destino se eles não existirem no sistema fonte.


________________________________________________________________________________________
Release and Export – copia as entradas das tabelas do banco de dados para um arquivo do sistema
operacional (no sistema fonte).
Release to Request – libera e copia a change request de customização para change requst transportavel.
Após liberar a change request customizing, lembre-se de verificar a execução do EXPORT pela transação
SE10.


________________________________________________________________________________________
Transport Management
Quando é feito o EXPORT, os arquivos de dados são armazenados no diretório usr/sap/trans/data e os

arquivos de controle no usr/sap/trans/cofiles.


________________________________________________________________________________________
Para visualizar a fila de import no sistema R/3, selecione na tela de Import Overview a opção import Queue >
display. A fila é mostrada na ordem que as requests são importadas
Em casos excepcionais, a request pode ser retornada para outro sistema R/3 e depois ser importada para o
sistema destino.
A Change request pode ser deletada ou adicionada na fila de import. Note que uma vez que os objetos são
dependentes, pode causar uma inconsistência de dados no sistema destino. Ex. Se você deletar uma request
que contém novos elementos de dados, todas as outras request que contém tabelas dependendo deste
elemento ficarão com falha.


________________________________________________________________________________________
O transporte não deve ser de responsabilidade de uma única pessoa, mas requer o esfoço de várias pessoas,
cada um com sua função.
Líder de projeto tem a funçao de organizar o desenvolvimento ou a customização do projeto usando o

gerenciamento das Change requests e se possível o IMG.
Verifica o conteúdo da request antes do RELEASE e após o IMPORT e verificar os arquivos de logs.
Administrador R/3 tem a função de usar o TMS para importar as requests e verificar o resultado do import,
testar o conteúdo da request não é função do administrador e sim do líder de projeto e do time de quality
assurance.
Time Quality Assurance tem a função de verificar e testar todas as funcionalidades contidas na change
request. Este time deve ser representado por pessoas de diversos departamentos da empresa, par que juntos
possam validar os processos , relatórios e transações antes de serem enviadas para produção.


________________________________________________________________________________________


________________________________________________________________________________________
Transport Directory File Name Conventions
O programa TP processa em diferentes sistemas operacionais, mas sempre segue uma convenção de nomes:
<source SID>K9<5 dígitos> - onde o K9 indica request de customização.
No diretório actlog o arquivo <source SID>Z<6 dígitos> grava cada ação executada da request.
No diretório sapnames é criado um arquivo com o nome do usuário que fez um transporte e atualiza quando o
usuário libera a request.
Buffer quando a change request é liberada o import buffer do sistema destino é atualizado.
Data contém os arquivos R9<5 dígitos>.<source SID> onde ficam os objetos exportados. Quando os
arquivos começarem com D9<5 dígitos>.<source SID> é um (ADO – Application Defined objetcts) que foi
transportado
Log contém todas os arquivos de logs,tanto os ULOGS, ALOGS, SLOGS e os arquivos:

N<data>.<action SID> para cada step de conversão de estrutura.
P<data>.<action SID> para cada step de nametabs.


________________________________________________________________________________________
Import Mode :


________________________________________________________________________________________
0 – importa do buffer sem deletar.

1 – ignora o que a change request já importou.
2 - regrava os originais.
3 – regrava os objetos do sistema específico.
6 – regrava os objetos não confirmando Repair.
8 – ignora as restrições.
9 – ignora que o sistema está bloqueado para este tipo de transporte.
Os comando do Buffer são :
TP SHOWBUFFER <SID> mostra as entradas contidas no buffer <SID>.
TP ADDTOBUFFER <change request> <SID destino> registra na fila de requests do buffer para ser
importada.
TP DELFROBUFFER <change request><SID destino> deleta uma entrada da fila.
TP CLEANBUFFER <SID> remove do buffer as requests que foram importadas com sucesso.
TP SETSTOPMARK <SID> coloca uma marca na lista de request que estão no buffer, e qdo importar as
request, só importará as requests antes da marca.
TP DELSTOPMARK <SID> retira a marca da lista de request.


________________________________________________________________________________________
Os comando do Buffer são :
TP SHOWBUFFER <SID> mostra as entradas contidas no buffer <SID>.
TP ADDTOBUFFER <change request> <SID destino> registra na fila de requests do buffer para ser
importada.
TP DELFROBUFFER <change request><SID destino> deleta uma entrada da fila.
TP CLEANBUFFER <SID> remove do buffer as requests que foram importadas com sucesso.
TP SETSTOPMARK <SID> coloca uma marca na lista de request que estão no buffer, e qdo importar as
request, só importará as requests antes da marca.
TP DELSTOPMARK <SID> retira a marca da lista de request.


________________________________________________________________________________________
Para limpar o diretório de transporte, use os comandos TP CHECK ALL e TP CLEAROLD ALL.
TP check all – pesquisa nos diretórios os arquivos que não são mais necesssários, aqueles arquivos que
correspondem a request não marcadas para import.


________________________________________________________________________________________
TP clearold all – usa o resultado da lista gerada pelo tp check all gravada no arquivo (ALL_OLD.LIS) para
localizar os arquivos que excederam o seu tempo de permanência nos diretórios.
Este tempo é definido no arquivo TPPARAM nos parâmetros :

Datalifetime – move os arquivos do usr/sap/trans/data conforme o tempo estabelecido para o olddata, os
arquivos do subdiretório LOG e COFILES são deletados se excederam o tempo específicado no loglifetime e
cofilifetime.
Os arquivos do OLDDATA são deletados de acordo com o olddatalifetime.
Antes de limpar o diretório de transporte, a SAP recomenda salvar uma cópia do diretório para auditoria, veja
notas 41732 no OSS.
Criação de Usuário
Digite a transação SU01.
Digite o nome do usuário

e New.
Click em


________________________________________________________________________________________
Clique o perfil de autorização no

combo-box e clique ENTER.


________________________________________________________________________________________
Escolha a linguagem que o usuário irá

Trabalhar.
Escolha qual a impressora estará configurada para

ele.
Assinale Print Immediate e Delete output.
Digite as variaveis, caso tenha alguma que será

default.
Tecle ENTER.


________________________________________________________________________________________
Neste passo o usuário está criado.

1
No botão LOCK/UNLOCK, voce trava e destrava o usuário.
No botão CHANGE PASSWORD, voce altera a senha do usuário.
Para se alterar click no desenho do lápis.


________________________________________________________________________________________
Logon Balancing
O Logon Balancing é usado para distribuir os usuários do R/3 nos servidores de aplicação.
O grupo de logon são instalados e gerenciados pelo R/3. Se define um tempo de resposta máximo
por servidor de aplicação e o número máximo de usuários por servidor.
Para criar Logon group: Selecione transação SMLG.
Clicar em create
assignment
Criar grupo e marcar a

Instance.
Para salvar clique em
copy.


________________________________________________________________________________________
Para assinalar o tempo de resposta máximo para cada grupo de logon, clique no botão de avanço:
Frontend – Marque o endereço IP do servidor assinalado.

Resp.Time – deve se definir um mesmo tempo para todos os grupos da mesma instance.
Users – É o numero máximo de usuários configurados que podem se logar nesta instance.


________________________________________________________________________________________
A tela acima mostra como estão as distribuição dos usuários por instance.
Clique em GOTO – LOAD DISTRIBUTION


________________________________________________________________________________________
Operation Mode
Normalmente, os sistemas R/3 precisam de mais WP´s dialog durante o dia e mais WP´s background durante
a noite.
Existem dois modos de se ajustar o sistema para se adequar a necessidades diferentes dependendo do
período do dia e do tipo de utilização principal. Isso pode ser feito alternado-se os perfis da instância ou
usando o processo de modo de operação (operation mode).
O uso de modo de operação maximiza a utilização dos recursos nas diferentes fases de atividade do sistema.
A mudança do modo de operação reconfigura o R/3 dinamicamente, o que substitui a alteração dos perfis e a
reinicialização do sistema.
A utilização das mudanças de modo de operação se baseia nos seguintes fatores:
- os serviços ou os tipos de work processes needed
- o intervalo de tempo escolhido

Para configurar o Operation Mode, digite a transação RZ04.
1-) Clique em Operation Mode – New – crie o novo modo de operação Noturno e Diurno – SALVE !!!
2-) Clique no botão Instance/OP modes – Settings – Based on act status – new instance – create.
3-) Dar duplo clique no Operation-Day e programe as quantidades de processos de dialog e background.


________________________________________________________________________________________
4-) Repetir o passo 3 para Operation-Night.
Para configurar a tabela TIMETABLE.

1-) Clicar no Operation Mode – Timetable – clique no botão Change.
2-) De duplo clique num intervalo de hora, para que o mesmo fique marcado, após clique no botão Assign.
3-) Escolha o Operation Mode, e salve.


________________________________________________________________________________________
R/3 Upgrade and OCS Patches
A evolução típica do sistema R/3 em produção segue:
Alterações e customizações para novos deenvolvimentos.
Aplicação de correções da SAP, os OCS (Online Correction Service).


________________________________________________________________________________________
Aplique as correções na sequência : SPAM update, Hot package e LCP e as CRT´s.
SPAM update é a alteração da versão da transação SPAM.


________________________________________________________________________________________
Hot Packages são grupos de correções e devem ser aplicados na sequência. Os nomes das hot´s são
SAPKH<release N.><sequência numérica>, são aplicados pela transação SPAU.
CRT (Conflit Resolution Transports) fornece adicionais objetos para resolver conflitos entre o R/3 e o SAP
ADD-ON.
LCS (Legal Change Patches) são correções usadas para aplicações de HR.
1- Requisitar os patches do OSS ou SAPNET.

2- Fazer download dos patches no servidor de desenvolvimeto usr/sap/trans/EPS.
3- Use a SPAM para :
a. Definir a fila de patches.
b. Selecione a SPAM.
c. Aplique os patches da fila.
d. Faça os ajustes caso sejam necessários.
e. Verifique os logs.
f. Confirme os patches.
4- Verifique e valide o ambiente.
Veja nota 33525.


________________________________________________________________________________________
Verificar o Patch Level do sistema.
1-) Entre na SM51.

2-) Posicione o cursor sobre a instance .
3-) Clique na tecla Release Notes.


________________________________________________________________________________________
SAPDBA Backup Tasks

O gerenciamento do Banco de Dados Oracle será acompanhado pela transações DB02, onde diariamente
estaremos acompanhando o crescimento das tabelas, indexes e tablespace. Para através da ferramenta
SAPDBA prestar-mos a manutenção necessária nas tabelas; Alterando um paramêtro de maxextent,
reorganizando uma tabela ou um tablespace, etc.
Os Backup utilizam informações que estão contidas no arquivo INIT<SID>.SAP, localizado no diretório
Orant\Backup do servidor SAP. Trata-se de um arquivo TXT, que pode ser editado com qualquer editor de
texto. Caso seja editado salvar as alterações como somente texto, sem formatação.
Este arquivo é configurado somente no inicio da implantação das rotinas de backup, não sendo portanto
editado diariamente, somente em eventuais alterações.
O processo de backup do SAP envolve o backup do Database Oracle e também dos Off-Line Redo log Files,
que são alterações feitas no Database.
Isto significa que cada operação de Backup, terá de ser executada em 2 fases:
A ferramenta de backup e restore do SAP R/3 é o SAPDBA, por ela, é que devemos gerenciar o banco de
dados, independente de qual seja ele.
Se logar no UNIX com o usuário ora<SID> e execute o comando SAPDBA.


________________________________________________________________________________________
Na tela SAP DATABASE ADMINISTRATION , selecione a letra H para fazer um backup da base de dados.
4. Selecione a opção A – Backup Function.
5. tecle enter.


________________________________________________________________________________________
6. Digite B para inicializar a fita de backup.
7. Pressione Enter.
8. Enter q (Return).
9. Pressione Enter.
10. Note a descrição da linha que mostra Initialize BRBACKUP tape.
11. Se você só tem uma fita para inicializar, vá para o passo 16. Caso tenha mais de uma fita para inicializar
entre com a opção D e digite o numero de fitas.
12. Pressione Enter.
13. Enter o numero da fita para ser inicializada.
14. Pressione Enter

.
15. O numero de fitas deve aparecer na linha da opção D.
16. Enter s (Start BRBACKUP).

6


________________________________________________________________________________________
10
11
A tela acima mostra a fita que foi inicializada com sucesso, pressione Enter.
Podemos inicializar um fita pelo PROMPT do sistema operacional : brbackup –i force –n 1 –v <nome fita>.
-n indica o numero de fitas.
-v o nome da fita.
15


________________________________________________________________________________________
Digite a opção I
O Archive Tape pode ser feito por 2 caminhos :

_ Usando o SAPDBA
_ Usando o BRARCHIVE
1 -No prompt, enter SAPDBA, pressione Enter.
2- Na tela acima digite a opção I (Backup offline redo logs).
3- Pressione Enter.
4. Enter a (Archive function).
5. Pressione Enter.
1


________________________________________________________________________________________
6. Enter k (Initialize BRARCHIVE tape).
7. Pressione Enter.
8. Enter q para retornar ao menu.
9. Pressione Enter.
9. Note a mensagem a direita -> Initialize BRARCHIVE tape.

O numero da fita inicializada pode ser trocada pelo mesmo caminho do BRBACKUP.
Enter d (Number of tapes)
Pressione Enter.
Enter o número da fita que será inicializada.
Pressione Enter.
10. Enter s para iniciar o BRARCHIVE e pressione Enter.
11. Quando termina o processo aparecerá a mensagem : BRARCHIVE executed successfully displays.
12. Remova a fita e atualize o seu controle de backup de acordo com suas normas internas.


________________________________________________________________________________________
Para executar o backup Offline:

_ Parar o R/3
_ Ter as fitas de backup inicializadas.
1. No prompt, enter SAPDBA, pressione Enter.
2. Entre h (Backup database).
3. Pressione Enter.
2
4. Verifique que no campo Backup Function aparece -> Normal Backup.


________________________________________________________________________________________
5. Reveja a linha e (Backup type) para determinar que tipo de backup está configurado (Online ou Offline).
6. O tipo de Backup pode ser alterado, selecione opção e (Backup type), e selecione :
_ a (online backup)
_ b (offline backup)
7. Tecle Enter.
8. Escolha uma opção (por ex. a).
9. Pressione Enter.
10. Digite q (Return) para voltar a tela anterior.
12. Enter S (Start BRBACKUP).
6
8
14. No prompts você recebe a mensagem para troca da fita quando for necessário.


________________________________________________________________________________________
15. Digite cont, para continuar o processo.
17. Quando o Backup termina , aparece a mensagem : BRBACKUP terminated successfully
18. Remova a fita e armazene-a num lugar seguro.


________________________________________________________________________________________
Para o Backup dos Achives Logs, devemos ter as fitas inicializadas.
Usamos o SAPDBA para executar este backup, e também podemos executar o BRARCHIVE atrvés de um
job chron.
1. No prompt, enter SAPDBA, pressione Enter.
2. Digite i (Backup offline redo logs).
3. Pressione Enter.
4. Entre com a opção a (Archive function).
5. Pressione Enter.
24


________________________________________________________________________________________
6. Digite a letra do tipo de Archive que será executado. (Recomendamos marcar 2 cópias do Oracle
Archive Logs).
7. Pressione Enter.
8. Digite s (Start BRARCHIVE).
9. Pressione Enter.
10. Quando o archive logs termina ele mostra a seguinte mensagem :

BRARCHIVE executed successfully appears.
6
Nunca deixe de fazer o backup deles, pois se faltar espaçõ no disco físico onde se encontram os archives o
R/3 trava.
Para destravar execute o comando BRARCHIVE –sd no prompt do sistema operacional.
Recomendamos as seguintes notas : 68059, 43499, 43491, 43489.


________________________________________________________________________________________
Outras Funções do SAPDBA
Opção A da tela do SAP Database Administration , é utilizada para conectar e desconectar o banco de dados.
Opção B da tela do SAP Database Administration, é utilizada para mostrar informações da Instance do R/3
que estamos conectados.
Opção C do SAP Database Administration , é utilizada para mostrar informações sobre as table-spaces, isto é
como estão os espaços alocados por cada tabela, as table-space com mais de 80% de utilização devem ter
seus EXTENT extendidos.


________________________________________________________________________________________
Na opção C, você terá os percentuais de cada table-space.

Na opção F você altera o tamanho da table-space escolhida (verifique a que tiver mais de 80% ). Este item
mostra valores sugeridos pelo próprio sistema, recomendamos aceitar este valor.
Este processo pode ser feito com o banco operando (Online).
Opção D do SAP Database Administration , é utilizada para reorganizar uma tabela ou uma table-space, isto é
feito quando não se tem mais espaço para alocar extents nas mesmas.


________________________________________________________________________________________
Opção E do SAP Database Administration, é utilizada para se fazer um EXPORT/IMPORT da base do Oracle
interia, muito utilizado para se fazer uma cópia do banco para uma outra instalação.
Opção F do SAP Database Administration , é utilizada para se abilitar o archive, isto é com o archive setado
ON, o banco criará arquivos de 20 MB cada, onde conterá cópias das informações contidas no banco de
dados. Com o archive setado OFF, isto não ocorrera. A opção a seta o archive para ON ou OFF.


________________________________________________________________________________________
Opção G do SAP Database Administration , é utilizada para lhe dar informações adicionais sobre o próprio
SAPDBA, serve para executar comando SQL, e mostar informações estatísticas do sistema.
Opção J do SAP Database Administration , é utilizada para restaurar a base de dados ou uma tabela
especifica ou uma table-space. E também para recuperar a base numa eventual perda das informações.


________________________________________________________________________________________
Opção K do SAP Database Administration , é utilizada para verificar a base de dados.
Opção L do SAP Database Administration, é utilizada para mostrar os logs de backup, de archives, etc.


________________________________________________________________________________________
Opção M do SAP Database Administration , é utilizada para mostrar informações do usuário do R/3 e sobre
segurança.
Opção N do SAP Database Administration, é utilizada para se conectar com a SAP.


________________________________________________________________________________________
Aplicando uma Nota

Transação SNOTE, é utilizada para aplicar correções nos programas standars da SAP.


________________________________________________________________________________________


________________________________________________________________________________________


________________________________________________________________________________________


________________________________________________________________________________________


________________________________________________________________________________________


________________________________________________________________________________________


________________________________________________________________________________________
System Administration Assistant - SSAA
A transação SSAA foi desenvolvida para dar um roteiro de gerenciamento para os profissionais de basis.
Ela lista todas as tarefas que são necessárias para o dia/dia.
1. Execute a transação SSAA. e 2. Selecione Entire View tab.
2
3. Selecione o botão do óculos.
3
4- Selecione o botão acima.


________________________________________________________________________________________
4- Selecione o botão acima.
5- Selecione no Menu a opção View –Transaction Code para visualizar os códigos das transações, na medida
que você for executando-as o semáforo ficará verde.
Audit Information System - SECR

Esta transação deverá ser utilizada pela Auditoria interna da empresa, pois nela temos todas as informações
sobre nosso sistema, isto é, acesso a todas as transações de sistemas e de negócios. Este acesso é somente
READ ONLY quando utilizado o perfil próprio de auditor.
Todos os relatórios gerados pelo AIS podem ser salvos e exportados para outras ferramentas de Auditoria
como ACL, e outras.
Não é necessário aumentar espaço em disco para a utilização desta ferramenta, e caso a estrutura do AIS
não esteja disponível, basta aplicar um nota para que isto seja feito.
Perfil Funções
ZBC-AUDITOR SAP_CA_AUDITOR_APPL_ADMIN
ZBC-AUDITOR SAP_CA_AUDITOR_SYSTEM
ZBC-AUDITOR SAP_CA_AUDITOR_DS
ZBC-AUDITOR SAP_CA_AUDITOR_HR
ZBC-AUDITOR SAP_CA_AUDITOR_APPL
Entre com a transação SECR.


________________________________________________________________________________________
1. Selecione Complete audit e 2- execute.

3. Clique no nó(+) para expandir :
1
2
3
1. Sob o System Audit, clique no nó(+) para expandir Repository / Tables.

2. Clique no nó(+) para expandir Table Information.
3. Selecione Data Dictionary display.


________________________________________________________________________________________
4. Quando a transação é executada, visualizamos a seguinte tela.
5. Selecione Back.
5
1. Sob o Business Audit, clique no nó(+) para Closing (FI-GL). 2. (+) Balance Sheet/ P&L/Balances.
3. Clique (+) Balance Sheet/ P&L , você pode executar diferentes relatórios para inspecionar balancos
financeiros. 4. Selecione Profit and Loss Projection.

________________________________________________________________________________________
2
3
4
6
5
Criar uma Visão de Auditoria:
Entre na transação SECR e selecione 2- User-defined audit. 3. entre com o nome da Visão(ZVUE).


________________________________________________________________________________________
4. Selecione o botão para criar. (os nomes devem começar com “Y” or “Z.”)
5. Entre com o nome da visão ZVUE.
6. Selecione Manual selection. 7- e execute.
8. Selecione 9. crie e 10- gerar a visão.
2


________________________________________________________________________________________
12
13


________________________________________________________________________________________
Exemplos :


________________________________________________________________________________________
1.0 Tentativa de acesso não autorizado à Transação

Caminho System Audit – System Logs and Status Display – system Log – System Log File
Obs. Não foi encontrado nenhuma tentativa de acesso não autorizado no período de 01/02/2002 à
22/02/2002.
Recomendamos acompanhar o log semanalmente.
2.0 Tentativa de acesso aos objetos críticos

Caminho System Audit – User Admin – Info System Authorization & User – users – By complex search criteria
Objetos Activity User Group Usuarios
S_USER_GRP 01 ou 02 * BZAAI, BZAMH, BZAPO, BZINTERFACE, BZSAG, DDIC, OSS, SAP*, WF-
BATCH
S_USER_PRO 01,02,07,22 * BZAAI, BZAMH, BZAPO, BZINTERFACE, BZSAG, DDIC, OSS, SAP*, WF-
BATCH
S_USER_AUT 01 ou 02 S* BZAAI, BZAMH, BZAPO, BZINTERFACE, BZSAG, DDIC, OSS, SAP*, WF-
BATCH
S_TABU_DIS 02 SS BZAAI, BZAMH, BZAPO, BZINTERFACE, BZSAG, DDIC, OSS, SAP*, WF-
BATCH
S_TRANSPRT 01 ou 02 * BZAAI, BZAMH, BZAPO, BZINTERFACE, BZSAG, DDIC, OSS, SAP*, WF-
BATCH
S_DEVELOP * * Ver anexo
S_ARCHIVE * * BZAAI, BZAMH, BZAPO, BZINTERFACE, BZSAG, DDIC, OSS, SAP*, WF-
BATCH
S_NUMBER 02,11,13 * BZAAI, BZAMH, BZAPO, BZINTERFACE, BZSAG, DDIC, OSS, SAP*, WF-
BATCH
S_PROGRAM * * BZAAI, BZAMH, BZAPO, BZINTERFACE, BZSAG, DDIC, OSS, SAP*, WF-
BATCH
Obs. Recomendamos rever os usuários com estes objetos.
3.0 Tabelas desenvolvidas sem atribuição de grupos de autorização

Caminho System audit – Repository table – table information – data browser
Tabela Verificar Observação
TDDAT Z* ou Y*
Obs. Ok não foi encontrada nenhuma tabela desenvolvida sem uma autorização.
4.0 Parâmetros de Login

Caminho System audit – user administration – authorization – system parameters
Parâmetros Descrição RSPARAM
1- Login/ext_security Acesso ao sistema com segurança externa N
2- Login/failed_user_auto_unlock Se 1 o sistema desbloqueia usuário após a 24H e 1 min. 1
3- Login/fails_to_user_lock Numeros de logon invalido permitido 3
4- Login/min_password_ing Comprimento minimo de senha 8
5- Login/no_automatic_user_sapstar Controle de login do usuario SAP* 0
6- Login/password_expiration_time Numero de dias que o usuario deve trocar sua senha 30
7- Login/multi_login_users Permite que um usuario só se logue uma vez (valor 1)
8- Rdisp/gui_auto_logout Numero de segundos que uma seção é interrompida por inatividade 0
Obs. Rever parâmetros 1,2,5,7 e 8,


Apostila Basis Iniciantes

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Basis Iniciantes

Enviado por

Direitos autorais:

Formatos disponíveis

Administração Basis

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 1 of 137

Preparado : Luiz Fernando Sgarbi

Integração do SAP R/3................................................................................................................................... 4

Preparado : Luiz Fernando Sgarbi

Planing the system Clients.......................................................................................................................... 73

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 3 of 137

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:

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 4 of 137

Preparado : Luiz Fernando Sgarbi

E diversos protocolos TCP/IP, EDI, OLE e Open Interfaces.

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 5 of 137

Preparado : Luiz Fernando Sgarbi

Preparado : Luiz Fernando Sgarbi

O Middleware é responsável por:

 Prover o runtime da aplicação do R/3.

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 7 of 137

Preparado : Luiz Fernando Sgarbi

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 8 of 137

Preparado : Luiz Fernando Sgarbi

O número máximo de mandantes em um sistema R/3 é de 997, número dificilmente atingido.

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 9 of 137

Preparado : Luiz Fernando Sgarbi

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 10 of 137

Preparado : Luiz Fernando Sgarbi

Um usuário do sistema operacional loga usando o usuário <sid>adm

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 11 of 137

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

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 12 of 137

Preparado : Luiz Fernando Sgarbi

De modo a construir um procedimento de inicialização, a sequência de leitura dos parâmetros (também

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 13 of 137

Preparado : Luiz Fernando Sgarbi

Visão Geral dos Trace Logs

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 14 of 137

Preparado : Luiz Fernando Sgarbi

Se o R/3 não inicia, podemos verificar se:

Existem duas razões principais para parar um sistema R/3:

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 15 of 137

Preparado : Luiz Fernando Sgarbi

Antes de parar o R/3, o administrador deve verificar:

Para parar um sistema R/3, o administrador deve:

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 16 of 137

Preparado : Luiz Fernando Sgarbi

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 17 of 137

Preparado : Luiz Fernando Sgarbi

Administrando o Banco de Dados

Composição do tempo de resposta

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 18 of 137

Preparado : Luiz Fernando Sgarbi

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 19 of 137

Preparado : Luiz Fernando Sgarbi

Enqueue Time é Tempo gasto para realizar “lock” – muito pequeno.

Dialog Step: Database Time

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 20 of 137

Preparado : Luiz Fernando Sgarbi

Dialog Step: Roll out time

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 21 of 137