Principais Transaes a serem verificadas diariamente

1.0 Memria
Criticidade: (mdia)
1.1 - Atividades principais a serem efetuadas:
- Entrar na instncia SAP, ir ao servidor que est gerando o alarme.
- Transao ST06, observar a sesso memory. Tentar identificar alguma
possvel situao de anormalidade nos indicadores de memria (pouca
memria fsica disponvel ou pouco swap disponvel).

Fig. 3 Transao ST06, tela inicial.

- Outras possveis aes sobre problemas de memria, de uma forma geral:

. Transao ST02 -> Primeiramente, observar o Current Use de memria. Se
alguma estiver prximo de 100%, estamos com problema em alguma rea.
Para problemas j acontecidos, verificar se o Max Use chegou prximo do
total de memria o que caracterizaria um estouro ou prximo disso em
algum momento passado. Outra ao verificar se uma determinada rea est
gerando muito swap. Caso a Extended Memory esteja prxima de 100%,
tentarmos identificar via SM04 (conforme abaixo) qual o usurio que est
utilizando mais memria, e verificar se possvel matar a sesso deste usurio

Fig.4 - Transao ST02 Abaixo esquerda Sap Memory, com o Current

Use. Acima direita, informaes sobre swaps que podem ter acontecido.

.Transaes SM50 e SM04 -> Caso tenhamos muitos processos na SM50 no

status PRIV, isso pode significar que ele j consumiu toda a memria que ele,
individualmente poderia. Tambm pode representar uma situao de consumo
excessivo de memria por parte de alguns usurios do sistema.

Fig. 5 Tela da SM50. Observe o nico processo em status PRIV. Temos um

problema quando muitos se encontram nesse estado.
Para vermos a utilizao de memria por usurio/sesso, ir transao SM04,
depois em Goto -> Memory. Ordenar por Mem(total), e teremos uma
situao parecida com a da Figura 6. Clicando em um usurio e depois em
Sessions, podemos ver as sesses que esto consumindo memria. Caso a
sesso esteja perdida (ou seja, ela muito antiga e no est rodando nada na
SM50), ela pode ser morta atravs da opo End Session. Mais uma vez,
certificar-se com o usurio antes, se possvel.

Fig. 6 - Transao SM04 Consumo de memria por usurio / sesso

Fig. 7 Detalhes de uma sesso e como termin-la.

1.2 Tempo de Resposta

Criticidade:

(mdia)
(quando vier acompanhado de lentido generalizada no sistema)

1.2.1 Quando normalmente ocorre

Quando o tempo de resposta das operaes de dialog em um servidor
especfico encontra-se demasiadamente alto.
1.2.2 Threshold
Tempo de resposta de dialog:
1.2.3 Atividades principais a serem feitas
Primeiramente, observar se o alto tempo de resposta est acontecendo apenas
em um servidor ou em todos os servidores de aplicao de uma instncia.
Caso haja algum sintoma de performance generalizada pode acontecer de
termos um problema de banco de dados, discos, ou um programa causando
uma queda de performance em todo o sistema. Tentar identificar via SM50,
SM66, SM21 ou ST22 o que pode estar causando essa lentido. Avisar o
suporte de segundo nvel, caso no consiga identificar o problema.
Caso haja um problema localizado num servidor entrar nesse servidor via
SM51, e observar os comportamentos dos processos verificar se h algum
processo com erro, com muita demora no processamento, etc.
Caso tenha sido um problema temporrio, e o alarme de tempo de resposta
no mais ocorrer, fechar o chamado. Caso o problema persistir e no encontrar
uma soluo, contatar o atendente de segundo nvel.

1.3 Erros de Up-date

Criticidade: TI1 (mdia).
1.3.1 Quando normalmente ocorre
Quando o nmero de updates com erro superior ao limite pr-estabelecido do
checklist.
1.3.2 Threshold
Quantidade de erros de update mostrados na transao SM13 deve ser maior
de 6 para gerao de alertas e abaixo de 3 para o fechamento.

1.3.3 Atividades principais a serem feitas

Entrar na transao SM13. Procurar os updates de todos os usurios, na data
desejada. Observar na tela seguinte os updates com status Err. Analisar os
logs, e tentar identificar se o problema foi funcional, ou relativo a Basis, como
um problema no banco de dados.
Se updates com problema estiverem acontecendo repetidamente em um
mesmo programa, procurar notas sobre o assunto ou repassar para anlise da
rea funcional ou de Abap envolvida.
Se nenhuma anormalidade for encontrada, fechar o chamado.

1.4 Erros de Jobs Cancelados

Criticidade: (mdia).
1.4.1- Quando normalmente ocorre
Quando o nmero de jobs cancelados compreendido no perodo dos ltimos 15
minutos, superior ao threshold pr-definido.
1.4.2 Threshold
Quantidade de Jobs cancelados na transao SM37 deve ser maior de 6 para
gerao de alertas e abaixo de 3 para o fechamento.
1.4.3 Atividades principais a serem feitas
Observar na transao SM37 os jobs cancelados. Verificar se um mesmo job
que est sendo sempre cancelado, se os jobs esto sendo cancelados pelo
mesmo motivo, etc. Analisar os logs e tentar identificar uma soluo. Outra dica
observar o comportamento do job em dias anteriores quanto tempo ele
demorou, se foi finalizado com sucesso, etc.
Se um mesmo job estiver sempre cancelando, e o motivo no for algo
relacionado Basis, passar para anlise do responsvel. Se nenhuma situao
de anormalidade for detectada, fechar o chamado.

1.5 Erros de Dump

Criticidade: (mdia).
1.5.1- Quando normalmente ocorre
Quando o nmero de dumps via ST22 compreendido no perodo do checklist,
superior ao threshold pr-definido.
1.5.2 Threshold
Quantidade de dumps no sistema transao ST22 deve ser maior do 6 para
gerao de alertas e abaixo de 3 para o fechamento.

1.5.3 Atividades principais a serem feitas

Observar os dumps que se repetem, e buscar identificar o programa que gera o
problema, se um erro Oracle, se um programa standard ou um programa Y,
etc. Se for o caso, buscar notas sobre o assunto ou passar para o responsvel
ABAP. Se nenhuma situao de anormalidade for detectada, fechar o
chamado.

1.6 Percentual de Utilizao no Modo PRIV de Work Process

Criticidade: TI1 (mdia).
1.6.1- Quando normalmente ocorre
A utilizao em PRIV indica que o work process est reservado para um nico
usurio para o uso de gerenciamento de memria. O work process excedeu o
limite da SAP memria que utilizada por outros usurios. O processo tem o
status HOLD enquanto o usurio atual requer memria local.
1.6.2 Threshold
O percentual de utilizao de work process em PRIV precisa ser maior que 80
para gerar alerta e o mesmo fechado quando o valor retorna a 70.
1.6.3 Atividades principais a serem feitas
Verificar a transao SM50 -> Caso tenhamos muitos processos na SM50 no
status PRIV, isso pode significar que ele j consumiu toda a memria que ele,
individualmente poderia. Tambm pode representar uma situao de consumo
excessivo de memria por parte de alguns usurios do sistema. Avaliar se
estes work process precisam ser liberados.

1.7 Utilizaes de Work Process de Background

Criticidade: (mdia).
1.7.1- Quando normalmente ocorre
Quando a utilizao dos work process de background alta gerando fila na
execuo de jobs.
1.7.2 Threshold
O percentual de utilizao de work process de background precisa ser maior
que 95 para gerar alerta e o mesmo fechado quando o valor retorna a 70.
1.7.2 Atividades principais a serem feitas
Verificar na transao SM50 a quantidade de work process de background
em uso e analis-las, verificando se alguma pode estar travada com um
processo morto.