Apostila Basis Sgarbi

Administração Basis ________________________________________________________________________________________

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc 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. 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





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





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.

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





Instance Client

Changes and Transports for Client–Dependent Objects

Client-Independent Object Change

Protection: Client Copier and Comparison Tool

DES Instance

N 00

200 No change allowed No changes to repository and client-ind. customizing allowed

Protection Level 0: No restriction

210 Automatic recording of changes

Changes to repository and client-ind. customizing allowed


220 Automatic recording of changes

No changes to repository and client-independent cust. obj.


230 No change allowed No changes to repository and client-ind. customizing allowed


QAS InstanceN

00

300 No changes allowed No changes to repository and client-independent cust. obj.







Protection Level 1: No overwriting

PRD Instance N 00


Protection Level 1: No overwriting





Na política de Refresh, podemos adotar.

O client de produção nunca sofrerá refresh, somente será atualizado por transporte. Na política de Transporte, podemos adotar.


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





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


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





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

1





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.

Criar grupo e marcar a Instance. Para salvar clique em copy.

Clicar em create assignment





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). 17. Pressione Enter. 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





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

Digite a opção I





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.

4





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.

11. Pressione Enter. 12. Enter S (Start BRBACKUP).

13. Pressione Enter. 6 8 14. No prompts você recebe a mensagem para troca da fita quando for necessário.





15. Digite cont, para continuar o processo.

16. Pressione Enter. 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.

11. Pressione Enter. 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





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.





1

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 Sgarbi

Documents

Transcript of Apostila Basis Sgarbi