2-Apostila Basis - Sgarbi

5/16/2018 2-Apostila Basis - Sgarbi - slidepdf.com

http://slidepdf.com/reader/full/2-apostila-basis-sgarbi 1/137

Administração Basis ________________________________________________________________________________________

Cópia Controlada C:\Formação\Cursos\IESA\Basis II versao 2.doc Page 1 of 137Last 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 quetodas as funções sejam acessadas diretamente.






Sistema Aberto

O sistema R/3 garante uma portabilidade usando interfaces standards de comunicação, permitindo umaintegraçã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 entresistemas 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 (3camadas). 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 dedados, com seus dados mestres e dados transacionais, dados de usuário e também seus próprios parâmetrosde customização.

Usuários em diferentes mandantes coexistem em um mesmo sistema R/3, mas seus dados são isolados e nãopodem ser acessados de outro mandante. Somente usuários com as autorizações necessárias podemvisualizar ou processar dados em um mandante específico. Esse conceito de isolamento se reflete naestruturas das tabelas, tanto em nível de aplicação quanto de customização, que é um nível de adaptaçãodependente 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 acriaçã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 serconsiderado 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 osprocessos do R/3 sendo executados, com a exceção do G (gateway), mas que também deve estar presenteem 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, dessemodo 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 computadorcom 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 sejanecessá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. Quandoo 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 comomultiplexaçã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 debanco 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 directorydo 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 omesmo não esteja sendo executadostartsap, então, chama o satrtdb, que inicia o banco de dados, caso o mesmo ainda não estaja sendoexecutado.Depois disso, o startsap inicia a central instanceO administrador pode iniciar instancias adicionais e servidores de aplicação. Para iniciar instanciasindependentes 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 SAPSTARTO programa SAPSTART lê o perfil de inicialização da instância e inicia os componentes do R/3 listados eoutros serviços

Em uma central instance, SAPSTART inicia os serviços message server, dispatcher, collector e sender. Emuma instância de dialog, somente o sender e o dispatcher são iniciados. O collector e o sender são usadospara 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 processosfilhos 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émconhecida 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ãosubstituí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 logpara 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. Abaixocomentamos 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 serinicializado. 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 avisoatravé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ématravé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 umservidor de aplicação antes de um backup offline. Os buffers do R/3 não são esvaziados, e os work processconfiguram 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´sreceberã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 muitotempo.

- 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 sedecidir 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 umasérie de dicas de como devemos analisar as transações voltadas para Performance de Banco de Dadosindependente de qual seja ele (SQL, Oracle, Informix, etc)

- Fazer a pergunta: é um problema generalizado (afeta todos os usuários), localizado (afeta somente aexecução de algumas transações) ou ainda um problema localizado que, quando ocorre, leva a umproblema 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ãorelacionados 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 deperformance.

Podem haver problemas de performance mais localizados, ocorrendo apenas em uma ou algumastransações, causados por fatores mais específicos. Detectadas estas transações, devemos submetê-las auma 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 dentroda 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 performanceque 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 umwork process.

Roll Time é oTempo para copiar a parte inicial do contexto do usuário(atributos de logon, autorizações, eoutras informações relevantes) para dentro do work process – da roll memory (shared) para a roll_first daroll_area (local do WP).






Load Time é o Tempo de carga do “load” (objeto compilado) de programa ABAP, telas, menus para dentro dobuffer 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çãopassada 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 queenvolvem CPU do Application Server (Roll, Load e Processing). Não é possível determinar quanto de CPU foigasto em cada um dos componentes. Desta forma, parte do CPU Time está em Roll, parte em Load e parteem Processing. Espera-se que o CPU Time seja próximo do Processing Time; caso contrário, é provável quehaja 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édiode 4s, mas o Wait Time médio é 3.5s. Desta forma, o Dispatch Time é de 0.5s (rápido). O ajuste para estasituação é completamente diferente em um outro caso, onde o TR médio de uma transação também é 4s, maso Wait Time é 0.2s. Neste caso, o Dispatch Time é 3.8s (alto). O que quer dizer que o dispatcher encontra umwork 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 quedeve ser feito cuidadosamente. Selecionamos o botão "Performance database", emseguida o aplication server a ser analisado, e finalmente o período de análise. A próxima tela apresenta asestatísticas do sistema, com os valores dos componentes do tempo de resposta para cada um diferentestipos de processamento (Dialog, Update, Background, etc).

Dialog Step: Database TimeNetwork






Netw

Se o processo requer dados do database, esta requisição é enviada para o interface database, mas antespesquisa 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 ComponentesWait Time < 10% do TRRoll Time (in/out) < 50msLoad 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 cadatipo de processamento (para selecionar o tipo de processamento, devemos usar os botões na parte inferiorda janela.

Analisados cada um deles, podemos determinar os sintomas dos problemas que eles identificam:Wait Time Tempo de espera para obter work processesRoll Time (in/out) Problemas com CPU ou memória do Sistema SAP R/3Load 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, eprincipalmente 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 estarpresente 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) egera esse load. Em seguida,o WP lê esse load do banco de dados para dentro do buffer de programa (partedo DB Req. Time). A partir daí, este work process passa a executar o programa. Em execuçõessubseqü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 sendochamados, e a taxa de eficiência do buffer (hitratio) vai subindo, já que os programas são localizados embuffer, não havendo a necessidade de carregá-los a partir do banco. Contudo, se o buffer de programa forpequeno 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 ecarrega outro de 4.5MB – gap de 0.5MB).Um buffer de programas fragmentado pode levar a um problema generalizado de performance. Se estãoocorrendo swaps, programas estão sendo retirados do buffer. Estes programas, se forem chamados maistarde por usuários, deverão obrigatoriamente ser carregados a partir do banco de dados, e sua cargaacarretará 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 pormais 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 workprocesses.- 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 ReportAction: Direct Read / Table: D010*

ST02 Program Buffer:HitRatio < 90%Swaps > 0Gaps = Free Space

ST03 TR médio das transações altoWait Time altoLoad Time altoDB 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ãoconsideradas LOCAIS, pois são acessíveis somente por um WP (roll area, paging area e heap area). Outrassã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 doservidor- 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 MemoryMode 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 doservidor. Quanto maior utilização ou concorrência, maior o tempo de processamento. Há ainda outrosfatores 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 serobservados indicadores sobre utilização de CPU, processos que mais consomem CPU, load average etaxas de paginação do sistema operacional. Nunca deve haver um gargalo de hardware no servidor debanco 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 consumoconsiderá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 ProcessingTime fosse preenchido com CPU Time.

O que observar:ST06 CPU Idle < 20%Load Average > 3Pages OutTop 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 seencontra 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árioVeremos 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çãode:






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

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áginaspor 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 devemser 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 conformeprocedimentos ASAP. Abaixo segue documento para se fazer o acompanhamento:

System Name_____________ Date_____________

SM21 System LogData Mensagem de erro Ação OSS Note1/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 senecessá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 pelosusuá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 jobsexecutados com sucesso nos ultimos X dias.Frequencia Recomendada : diário.Nome do Job : SAP_REORG_JOBSVariante: sim

Client Depende: sim

•RSPO0041 •Este programa é responsável por remover objetos do spooling. A fila de impressão vai aumentando comrelatórios que falharam ou não, cabendo ao administrador o critério para deleção.Frequencia Recomendada : diário.Nome do Job : SAP_REORG_SPOOLVariante : sim.Client Depende: sim

•RSM13002 •Este programa limpa os processos requisitados de Update. É necessário somente se a deleção automaticados processos requisitados de updadte estiver setado TURNED OFF . Frequencia Recomendada : diário.Nome do Job : SAP_REORG_UPDATERECORDSVariante: nãoClient Depende: não

•RSBDCREO






•Este programa é responsável em limpar o log dos batch input.Frequencia Recomendada : diário.Nome do Job : SAP_REORG_BATCHINPUTVariante : sim.Client Depende: sim

•RSSNAPDL •Este pr ograma limpa os dumps gerados por programas abap/4. Processar na madrugada. FrequenciaRecomendada : diário.Nome do Job : SAP_REORG_ABAPDUMPSVariante: simClient Depende: não

•RSBPCOLL •Este programa acumula informações de de estatística, ele calcula a média de tempo de processamentodo jobque termino com sucesso. Estes dados são armazenados numa tabela chamada BTCJSTAT , esta tabelanecessita periodicamente de reorganização.Frequencia Recomendada : diário.Nome do Job : SAP_COLLECTOR_FOR_JOBSTATISTICVariante : 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 alteradasnum determinado período.Frequencia Recomendada : mensal.Nome do Job : SAP_REORG_JOBSTATISTICVariante: simClient Depende: não

•RSCOLL00 •Este programa coleta dados de performance.Frequencia Recomendada : toda hora.Nome do Job : SAP_COLLECTOR_FOR_PERFMONITORVariante : 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 seocorrer um erro de perda de conexão ou erro do programa, esse objeto pode ficar travado (lock). Estatransaçã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 oclient (ex. o PC esta processando e o SAPLPD está desabilitado). Por causa que o R/3 encaminha os jobs deimpressão para a fila destino, não são garantidos os jobs de impressão com status de sucesso para o controlede saida. Para jobs de impressão critica, deve ser confirmado com o usuário final se a impressão está okantes 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 sefor 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 analiza r o numero de workload,especialmente para prever problemas de performance. Em se tendo uma visão do quadro limpo doacompanhamento do sistema, é mais fácil quando houver um problema de performance, achar rapidamente omesmo.






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 msChange Sales Order – VA02 – 1,500 msDisplay Sales Order – VA03 – 1,000 msCreate Billing Document – VF01 – 1,500 msCreate Delivery - VL01 – 2,000 msMaintain 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çoslivres, e areas de swap. Este processo ajuda o administrador a se familiarizar com os valores para numapró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 passardo 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 duploclique.

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 acessomais 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 ouda 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 parao 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ósutilizaremos 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 paraos 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 possuiacesso 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 domesmo, como no exemplo abaixo.






3. Estes dois dados deverão constar no arquivo hosts (/etc/hosts ) do servidor R/3, viabilizando acomunicação do servidor (UNIX) com este micro (Windows). Note que este micro deverá possuir umendereço IP fixo na rede, pois se o mesmo está configurado para receber o seu endereçoautomaticamente através do DHCP ele poderá ter o seu endereço IP trocado tornando a comunicaçãocom 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 parao 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 - Rel4.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 umaresposta do dispositivo, o valor padrão está definido no parâmetro rspo/tcp_timeout_connect no profile dainstance) 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 letrasmaiúsculas e minúsculas).

Classe aparelho: selecione o tipo de dispositivo que está sendo instalado, no nosso caso Impressoranormal.

Tipo acoplam.p/spool host: informe o modo que o R/3 se comunicará com o dispositivo, no nosso caso nósutilizaremos 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 quevocê 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 dedados, com seus dados mestres e dados transacionais, dados de usuário e também seus próprios parâmetrosde customização.

Descrições dos Clients:

Customizing/Development – Aqui se cria o protótipo do sistema, todas as customizações de aplicações sãodesenvolvidas neste client.Sandbox – É um client de teste geral, inicialmente criado do client 000, é utilizado pelos Key-users sefamiliarizarem com o sistema, testarem aplicações e customizações.Customizing/Development Testing – É usado para testarem as mudanças feitas no client de customizing edevelopment.Quality Assurance Testing – É usado para testar as mudanças de configuração e customizações feitas noclient 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 QASPRD

Master Client

Development

Sand Box

Master Client

Quality Testing

Batch Input

Integrated Testing

Production






InstanceClient

Changes andTransports for Client –

Dependent Objects

Client-Independent

Object ChangeProtection: ClientCopier and Comparison

ToolDES InstanceN 00

200 No change allowed No changes torepository and client-ind. customizingallowed

Protection Level 0:No restriction

210 Automatic recordingof changes

Changes to repositoryand client-ind.customizing allowed


220 Automatic recordingof changes

No changes torepository and client-independent cust. obj.


230 No change allowed No changes torepository and client-ind. customizing

allowed


QASInstanceN 00

300 No changes allowed No changes torepository and client-independent cust. obj.







Protection Level 1:No overwriting

PRD InstanceN 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 QASPRD

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 QASPRD

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 paraeste 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 eo 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 eindependente) não estão protegidos contra regravação. As tabelas são bloqueadas enquanto as transaçõesde customizações estão sendo usadas, mas são desbloqueadas quando as alterações são completadas esalvas 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 sistemaoperacional (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çãoSE10 .






Transport Management

Quando é feito o EXPORT, os arquivos de dados são armazenados no diretório usr/sap/trans/data e osarquivos 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 osistema destino.

A Change request pode ser deletada ou adicionada na fila de import. Note que uma vez que os objetos sãodependentes, pode causar uma inconsistência de dados no sistema destino. Ex. Se você deletar uma requestque contém novos elementos de dados, todas as outras request que contém tabelas dependendo desteelemento 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 ogerenciamento 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 qualityassurance.

Time Quality Assurance tem a função de verificar e testar todas as funcionalidades contidas na changerequest. Este time deve ser representado por pessoas de diversos departamentos da empresa, par que juntospossam 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 ousuá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 osarquivos começarem com D9<5 dígitos>.<source SID> é um (ADO – Application Defined objetcts ) que foitransportado

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

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 asrequest, 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 serimportada.

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 asrequest, 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 ) paralocalizar 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 ecofilifetime .

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, vejanotas 41732 no OSS.

Criação de Usuário

Digite a transação SU01.

Digite o nome do usuárioe New.Click em






Clique o perfil de autorização nocombo-box e cli ue ENTER.






Escolha a linguagem que o usuário iráTrabalhar.

Escolha qual a impressora estará configurada paraele.Assinale Print Immediate e Delete out ut.

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.






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áximopor 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 aInstance.Para salvar clique em

Clicar em createassignment






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

Existem dois modos de se ajustar o sistema para se adequar a necessidades diferentes dependendo doperíodo do dia e do tipo de utilização principal. Isso pode ser feito alternado-se os perfis da instância ouusando 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 areinicializaçã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ãoSAPKH<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 diariamenteestaremos acompanhando o crescimento das tabelas, indexes e tablespace. Para através da ferramentaSAPDBA 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órioOrant\Backup do servidor SAP. Trata-se de um arquivo TXT, que pode ser editado com qualquer editor detexto. 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 portantoeditado 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 dedados, 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 inicializarentre 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






1011A 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).







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


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.


12. Enter S (Start BRBACKUP).


68

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







6. Digite a letra do tipo de Archive que será executado. (Recomendamos marcar 2 cópias do OracleArchive 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.


6Nunca deixe de fazer o backup deles, pois se faltar espaçõ no disco físico onde se encontram os archives oR/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/3que 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 terseus 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 itemmostra 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 Oracleinteria, 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 setadoON, o banco criará arquivos de 20 MB cada, onde conterá cópias das informações contidas no banco dedados. 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óprioSAPDBA, 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 tabelaespecifica 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 sobreseguranç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.

34- 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 medidaque 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çõessobre nosso sistema, isto é, acesso a todas as transações de sistemas e de negócios. Este acesso é somenteREAD 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 Auditoriacomo ACL, e outras.

Não é necessário aumentar espaço em disco para a utilização desta ferramenta, e caso a estrutura do AISnã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 :123

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 balancosfinanceiros. 4. Selecione Profit and Loss Projection .






1

234

65 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






1213






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çãoTDDAT 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,

Documents

2-Apostila Basis - Sgarbi