Análise Statspack Banco com ASM em SSD

Envie seu AWR para uma análise gratuita.
Podem ser enviados em formato texto ou html.

Procure sempre emitir o AWR para o menor período possível de análise em que seu problema de desempenho ocorre.

Se desejado, edite o texto e troque o nome do seu servidor, outra outras informações que julgue que não devam ser dilvulgadas.
Post Reply
m_torres

Análise Statspack Banco com ASM em SSD

Post by m_torres » Mon Sep 03, 2018 3:22 pm

Boa Tarde.

Existem algumas rotinas demorando várias horas para concluir. Existe alguma ineficiência mais evidente no banco?
Attachments
stats_infomed_6712_6729.zip
(81.18 KiB) Downloaded 178 times

portilho
Site Admin
Posts: 482
Joined: Wed May 29, 2013 8:51 am

Re: Análise Statspack Banco com ASM em SSD

Post by portilho » Thu Sep 20, 2018 7:54 am

Oi!
Desculpe pelo atraso em responder. Por algum motivo não vi a notificação de que chegou uma pergunta nova.a
Sobre o Relatório das 13:00 às 14:00 (o Relatório das 21 às 14 possui informações semelhantes):
- Em "Time Model", a maior parte do tempo (88%) está em CPU. Então nem adianta olhar Waits.
- Isto faz com que tenhamos que ir direto para "SQL ordered by CPU". O primeiro da lista é executado apenas 2 vezes, mas é responsável por 29.3% da CPU. Não dá para ver detalhes dele, pois é PL/SQL. O segundo SQL da lista é responsável por 23.7% da CPU, e não terminou de executar nenhuma vez no período analisado. Neste caso, não vejo o que fazer a não ser pegar estes SQLs e partir para a otimização deles.
- Os parâmetros optimizer_index_caching e optimizer_index_cost_adj contém valores agressivos. Talvez eles que estejam atrapalhando os planos de execução dos SQLs mais pesados.

Não parece serem causa de seu problema, mas seguem algumas observações:
- O "Time Model" mostra percentuais relativamente altos em Parse (parse time elapsed, hard parse elapsed time, PL/SQL compilation elapsed time). Procure por SQLs repetitivos sem BINDs. Parse é CPU, então está atrapalhando um pouco sim
- Se esta é a única instância do servidor, há um bom desperdício de memória. Com 192 GB no total, a SGA está com 64GB.
- Estranho pois não encontrei o parâmetro de PGA na seção de parâmetros, quase no final. E pelo PGA Memory Advisory, há um pequeno ganho em aumentar a PGA em 20%.

m_torres

Re: Análise Statspack Banco com ASM em SSD

Post by m_torres » Wed Sep 26, 2018 12:02 am

- A SGA deste banco está com 64GB porque existem outros bancos neste mesmo servidor;
- Os parâmetros "optimizer_index_caching e optimizer_index_cost_adj" foram definidos de forma a priorizar a utilização de índices, entretanto, algumas vezes por mês é executada uma função PL/SQL que é bastante demorada. Você acha conveniente estudar a possibilidade de mudar os valores destes parâmetros para quando for necessário executar essa função de processamento?

portilho
Site Admin
Posts: 482
Joined: Wed May 29, 2013 8:51 am

Re: Análise Statspack Banco com ASM em SSD

Post by portilho » Wed Oct 24, 2018 1:35 pm

Ok então sobre a SGA.
E sim, sugiro que você teste (em SESSION) com os parâmetros optimizer_index_caching e optimizer_index_cost_adj com seus valores padrão. Altera-los faz sim com que métodos de acesso de índices sejam mais utilizados, mas isto não necessariamente é bom.

Post Reply