Menu de navegação

[mpvargasParticipante]

Caros amigos,
gostaria de uma ajuda pois já não sei mais o que fazer…
já abri um tópico semelhante a um tempo atrás e chegamos a conclusão após um longo bate papo que o problema da minha base era o ERP…
pois bem… o tempo passou, o ERP continua e voltei a ter problemas com lentidão em alguns processos…
Gostaria de uma ajuda para tentar minimizar o meu problema.
Obrigado.

[rmanParticipante]

@mpvargas

Analisando o relatório ADDM do tópico anterior, como ja tinha dito, a SGA está mal dimensionada, como você mesmo viu é ganho de 100% se aumentar, verifique se tem memória suficiente para isso.

Outra sugestão mais tranquila é rodar o Segment Advisor, provavelmente ele irá sugerir que se compacte ou particione um segmento.

Tem a parte de variável BIND também, mas isso depende de alteração no código fonte do sistema, infelizmente você como DBA fica refém.

[mpvargasParticipante]

@rman
já fiz isso anteriormente e identifiquei que era necessário rever as queries… o problema é que o ERP é um sistema comprado e muitas dessas queries nao podem ser alteradas, sendo assim eu gostaria de saber se é possível fazer algo além disso… abaixo alguns procedimentos que já tomei:

• Particionamento das maiores tabelas
• Alteração do tamanho dos redo logs
• Script para rodar estatística todos os dias

[mpvargasParticipante]

@rman

Quanto a SGA não consigo aumentar… o servidor tem 14 GB de memória mas não consigo alocar mais de 6 GB na SGA… já estou vendo a possibilidade de colocar mais memória no servidor.

Vou verificar as dicas do Segment Advisor…

Agora o que seria “parte de variável BIND”?

[rmanParticipante]

@mpvargas

FINDING 5: 2% impact (63 seconds)

Instruções SQL não foram compartilhadas em decorrência do uso de literais.
Isso resultou em parses adicionais que estavam consumindo um tempo de banco de dados significativo.

RECOMMENDATION 1: Application Analysis, 2% benefit (63 seconds)
ACTION: Investigue a lógica da aplicação para o possível uso de
variáveis de bind em vez de literais.
ACTION: Como alternativa, você pode definir o parâmetro
"cursor_sharing" como "force".

SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Hard parses de instruções SQL estavam consumindo um tempo de banco de dados significativo. (2,1% impact [64 seconds])


Muitos desenvolvedores não conhecem variavel BIND, e simplesmente adicionam os valores direto nos filtros das consultas, exemplo:

Primeira consulta:


SELECT CODIGO,NOME,SOBRENOME
FROM PESSOA
WHERE CODIGO = 12


Segunda consulta:


SELECT CODIGO,NOME,SOBRENOME
FROM PESSOA
WHERE CODIGO = 44


Terceira consulta:


SELECT CODIGO,NOME,SOBRENOME
FROM PESSOA
WHERE CODIGO = 56


Como não foi utilizado variavel BIND, o oracle teve que fazer o parser da mesma consulta 3 vezes, devido o valor no filtro o oracle não sabe que é a mesma consulta.

Agora utilizando variavel BIND, a consulta iria chegar assim:


SELECT CODIGO,NOME,SOBRENOME
FROM PESSOA
WHERE CODIGO = :1


Tem duas soluções, tinha esquecido de uma…


ACTION: Investigue a lógica da aplicação para o possível uso de
variáveis de bind em vez de literais.
ACTION: Como alternativa, você pode definir o parâmetro
"cursor_sharing" como "force".


Se tiver como alterar as consultas, implante variavel BIND, se não altere o parâmetro cursor_sharing. A alteração do parâmetro eu nunca fiz, não sei das consequências.

[mpvargasParticipante]

@rman

Consegui entender o funcionamento, mas não entendi na prática

Qual seria o resultado dessa query usando a variável bind?
SELECT CODIGO,NOME,SOBRENOME
FROM PESSOA
WHERE CODIGO = :1

No caso, essa variável tem que ser definida anteriormente?
porque aqui na aplicação eu não consigo identificar, em alguns casos, de onde vem esses valores

[fabiogaleraParticipante]

Vixe, dá para escrever um livro sobre Bind Variables =).

Analizando seu ADDM, o problema dos cursores é apenas 2% de impacto, o que não é muita coisa.

Eu particularmente odeio o ADDM, ele só faz analises automáticas e faz recomendações sem muito nexo.

Já que parece que você possui licensas para o ADDM/AWR, aconselho a retirar um AWR para o mesmo periodo.

A grosso modo, o problema são as leituras físicas, como já percebeu. O que eu faria era verificar as lógica das queries

SQL_ID
8d5k3z6xzwb11
g7r14b204jujf
7ynjzqu755j95

Pelo jeito, elas estão fazendo bastante FULL SCAN nas tabelas, sem utilizar índices.

Poste novamente com o AWR, juntamente com os SQL_TEXT dessas 3 queries.

[ithigvoParticipante]

@mpvargas

Apenas um breve explicação sobre a utilização ou não de bind variables,

Lendo brevemente o tópico vi que existe uma sugestão para aumentar a SGA do banco. Dentro da SGA está alocada a shared pool, que é a área aonde ficam armazenadas informações compartilhadas sobre os comandos SQL executados… essa área é util para economizar o trabalho de PARSE do banco. (você pode ter uma ‘idéia’ da shared pool por exemplo pela view v$sqlarea)

Onde entra o tal do BIND nisso tudo…
imagina que cada linha da v$sqlarea é um comando sql executado..

Agora imagina que sua aplicação possui uma telinha com um filtro simples por ID
select id, nome from tabela where id = 10

Para cada ID diferente q é feita essa pesquisa, é feito um parse completo, e alocado espaço na shared pool (gastando memória e CPU)
Dai,, imagina a quantidade dessas consultas simples que podem haver,, para cada ID…

Mas o comando SQL é o mesmo,, se ele vier com BIND da aplicação, vai ser entendido assim pelo banco:
select id, nome from tabela where id = :V_BIND

Então,, independente da quantidade de IDs diferentes que forem consultados, é SEMPRE a mesma consulta,, não alocando mais espaço nem gastando muita CPU para fazer o tal do HARD PARSE.

Como no seu caso, o ERP é uma aplicação fechada, e vc não tem controle sobre como estes comandos são enviados pro banco, pode considerar alterar um parâmetro no banco chamado CURSOR_SHARING para FORCE… ele força a utilização de bind variables pelo otimizador..

Esse parâmetro é dinâmico, e vc pode alterá-lo até pode uma trigger de logon,, fazendo assim pode filtrar uma determinada maquina, ou usuário para testes..

Quanto a necessidade de corrigir querys,, se for 11g, existe a possibilidade de se trocar o plano de execução de uma determinada query por outro que você sabe que é melhor..

Mas só lembrando,, sempre testar BEM este tipo de alteração para não ser um tiro no pé (principalmente o cursor_sharing)

[fabiogaleraParticipante]

Veja bem, vocês apenas estão se baseando em um report de ADDM, que muitas vezes, esconde o real problema do Banco de Dados. Muito além da Shared pool na SGA_TARGET, temos a DB BUFFER CACHE, que pode ser o grande vilão do número de leituras físicas na Base de Dados. Digo novamente, não se tem analises suficientes para dizer qual o problema da Base de Dados.

Muitas vezes os DBAs não podem se dar ao luxo de perder tempo analisando outros problemas ao redor, CURSOR_SHARING, embora seja uma alteração ONLINE é uma alteração GRANDE, pois necessita de testes e mais testes. Praticamente a aplicação inteira precisa ser verificada, pois podem passar a ter problemas de tabulação em reports que não fazem o TRIM depois de um substr nos campos da query, ou até mesmo passar a receber falhas na aplicação com a mensagem “not all variables bound”,por causa que o Oracle erra o Cursor, achando que é o mesmo, entre outros como, bind peaking, etc.

Vai por mim, você não irá querer trocar esse parâmetro só para ver o que dá e muito menos gastar horas e horas testando a aplicação apenas porque isso apareceu no ADDM como 2% de Impacto.

Por isso eu disse que Bind Variable dá para escrever um livro sobre. Pois envolve MUITA coisa no Banco de Dados.

Estou ainda no aguardo do AWR e as queries =).

[mpvargasParticipante]

Fabio,
gerei o AWR…
como faço para enviar pra vc… postar aqui nao vai ficar legal, tem muita informação

[fabiogaleraParticipante]

me envia no email

galera@pythian.com

[mpvargasParticipante]

OK…
Já enviei por email

[fabiogaleraParticipante]

Vamos lá.

Segundo o report, 50% do tempo de Base de Dados esta sendo gasto em leituras físicas (scaterred e sequencial read), 21% em CPU (processamento), 20% em log file sync (que também pode ser considerado I/O).

A grosso modo, 70% da sua Base de Dados está em espera por Disco.
Além do mais, você possui alguns datafiles que tem uma média de leitura de 200ms, o que é MUITO alto.

• scattered read: Famosamente conhecido como FULL SCAN, toda vez que faz uma leitura em uma tabela sem ser indexada, usando LIKE, !=, , etc.

Você possui algumas queries que possuem tudo que não pode possuir hehe, tem uma query que tem LIKEs, , etc. =)

pontos importantes:
– SGA_TARGET não tá igual ao SGA_MAX_SIZE … aqui você tem 400mb de espaço para aumentar, sem baixar o banco;
– Valores mínimos para buffer cache e shared_pool: O seu Banco de Dados esta reportando 70% de Soft Parse (o que não é ruim), mas o ideal seria ser perto de 90% … isso ocorre pois a sua Shared Pool esta sendo forçada a diminuir até 368MB, pois como tem muita leitura física, o ASMM (Automatic Shared Memory Managment), vulgo SGA_TARGET, opta por alocar a memória na DB BUFFER CACHE.
– log file sync não faz sentido estar aqui, pois você apenas possui 11 commits por segundo, mas pode ser por causa do report que você deu.

O seu report não nos ajuda muito para verificar o real problema, pois ele possui uma margem muito grande de tempo e todos os calculos de médias são feitas durante todo esse tempo. (seu report veio da 00:00 até as 15:00), notando o report, pude ver que possui até mesmo processo de EXPORT.

Procure retirar reports de AWR de periodos de no máximo 1 hora, mínimo de 15 minutos, durante a lentidão do problema.

[mpvargasParticipante]

OK Fabio
li atentamente as suas observações…

Com relação as queries eu não tenho muito o que fazer por ser um pacote fechado… sei que tenho esse problema… e tenho que tentar minimizar com o que tenho em mãos…
Referente aos datafiles, é possível identificar qual exatamente está com essa média de leitura?
Sobre a SGA eu não aumentei porque de acordo com alguns artigos que eu li, é recomendável manter uma margem entre o SGA_MAX e a SGA.
Com relação aos redo logs deu para identificar alguma coisa, digo, será que estão bem dimensionados?

Amanhã, qdo eu tiver o mesmo problema, mando outro relatório pra vc com uma análise de 1 hora

Em tempo, verifiquei com o meu gerente a possibilidade de aumentar a memória do servidor para poder aumentar a SGA… tenho 14GB no servidor mas só consigo alocar 6GB na SGA

Obrigado pela ajuda

[fabiogaleraParticipante]

Você possui poucos switchs/hora, seus REDOs estão bem.

Não queria muito aprofundar nesse report, pois por reportar um grande periodo de tempo, algumas coisas aqui podem estar ocultas.

Mas veja na sessão File IO Stats, na quinta coluna Av Rd(ms).

Você provavelmente esta com problemas em discos, especificamente onde esses datafiles estão armazenados.

Aliás, qual o Sistema Operativo da máquina ?

edit: meu deus, Operativo é em Portugal, aqui é Operacional hahaha.

[Autor]

Posts