DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!


Ajustes Automáticos de SQL no Oracle Database 10g - Artigo Revista SQL Magazine 85

Este artigo discute algumas funcionalidades que automatizam operações de tuning (ajustes) no Oracle 10g.






Ajustes Automáticos de SQL no Oracle Database 10g

De que se trata o artigo:
Este artigo discute algumas funcionalidades que automatizam operações de tuning (ajustes) no Oracle 10g.

Para que serve:

Ajustes (tuning) em banco de dados são operações sempre necessárias para evitar a queda de desempenho de um banco de dados na medida em que este aumenta sua carga de trabalho. Desta forma, a automação desta tarefa tem um impacto importante nas atividades de um DBA devido à redução do tempo para realização de tal tarefa.

Em que situação o tema é útil:

DBAs que utilizam banco de dados Oracle 10g e que desejam aplicar ajustes (tuning) nas consultas disponíveis em seu banco de dados e que atualmente estão prejudicando o desempenho do mesmo.

Resumo DevMan
O desempenho de processos computacionais é medido por velocidade. Quanto mais rápido, melhor o desempenho. E quando se trata de velocidade, o desempenho só pode ser medido pelo TEMPO. O tempo é a única constante onde podemos nos basear sobre o desempenho de um processo computacional. Neste contexto, este artigo apresenta algumas funcionalidades que automatizam operações de tuning (ajustes) no Oracle 10g.

Antes de executar um ajuste no SGBD Oracle, em resposta a um problema de desempenho, devemos ter um diagnóstico correto. Sem um correto diagnóstico, não faz sentido prosseguir.
O desempenho de processos computacionais é medido por velocidade. Quanto mais rápido, melhor o desempenho. E quando se trata de velocidade, o desempenho só pode ser medido pelo TEMPO. O tempo é a única constante onde podemos nos basear sobre o desempenho de um processo computacional.
Portanto, para um correto diagnóstico de um problema de desempenho, deve-se saber onde o tempo é gasto.
Finalmente, para saber-se onde o tempo é gasto no Oracle, não há uma forma mais direta que observar os Wait Events (Eventos de Espera).
Os Wait Events são eventos de espera por recursos computacionais, físicos (discos rígidos, memória, rede, etc.) ou lógicos (latches, locks, etc.). Estes recursos são limitados, e são os únicos limitadores do desempenho de um comando SQL. Se não houvesse espera por recursos computacionais, todos os comandos SQLs seriam finalizados instantaneamente.
Os Wait Events do Oracle são implementados pela OWI, a Oracle Wait Interface. Esta implementação mede as esperas diretamente do kernel do Oracle, e não é nova, foi introduzida na versão 7.0.12. Desde então, os Wait Events monitorados pela OWI cresceram consideravelmente, de 104 Wait Events na 7.0.12, para 220 no 8i, 400 no 9i, e mais de 800 no 10g. Este progresso mostra como a própria Oracle acredita e investe neste método de diagnóstico de problemas de performance.
Neste contexto, apresentaremos a partir de agora algumas funcionalidades que automatizam operações de tuning (ajustes) no Oracle 10g.

Otimizando Consultas

Em seu modo normal, o otimizador de consulta (query optimizer) precisa tomar decisões sobre os planos de execução em um tempo muito curto. Como resultado disso, este pode nem sempre estar apto a obter informações suficientes para tomar a melhor decisão a respeito de tais consultas. O Oracle 10g permite que o otimizador execute em modo de tuning onde ele pode garantir informações adicionais e fazer recomendações sobre declarações específicas que podem ser ajustadas no futuro. Este processo pode levar vários minutos para uma simples declaração de forma que ele é recomendado para declarações que envolvem grande quantidade de recursos e uma alta carga de dados.
No modo tuning o otimizador realiza as seguintes análises:
•    Análises Estatísticas – o otimizador recomenda a obtenção de estatísticas sobre objetos com estatísticas que estejam faltando ou estejam obsoletas. Estatísticas adicionais para estes objetos são armazenadas em um perfil SQL (SQL profile).
•    Análise de Perfil de SQL – o otimizador pode ser apto a melhorar o desempenho através da obtenção de estatísticas adicionais e alterando parâmetros específicos de uma sessão, tal como o OPTIMIZER_MODE. Se tais melhorias são possíveis, a informação é armazenada em um perfil SQL. Se aceita, esta informação pode então ser usada pelo otimizador quando estiver executando em modo normal (não apenas no modo tuning). Ao contrário de um esquema armazenado que corrige o plano de execução, um perfil SQL pode ainda ser benéfico quando o conteúdo da tabela é drasticamente alterado. Mesmo assim, é sensato atualizar perfis periodicamente. A Análise de Perfil de SQL  não é executada quando o otimizador de tuning está sendo executado no modo limitado.
•    Análise de Caminho de Acesso – o otimizador investiga o efeito de índices novos ou modificados no caminho de acesso. São feitas recomendações de índices relacionadas a declarações específicas. Então, onde for necessário é ainda sugerido o uso do SQL Access Advisor para verificar o impacto desses índices em uma representativa carga de trabalho de SQL.
•    Análise de Estrutura de SQL – o otimizador sugere alternativas para declarações SQL que contêm estruturas que podem ter impacto no desempenho da consulta. A implementação dessas sugestões requerem intervenção humana para verificar sua validade.

As funcionalidades de tuning automático de SQL são acessíveis a partir do Enterprise Manager na página "Advisor Central" ou a partir de código PL/SQL usando o pacote DBMS_SQLTUNE. Neste artigo, iremos focar na API PL/SQL, pois o uso da interface do Enterprise Manager interface é bastante intuitivo e simples de ser usado, aliado aos diversos manuais sobre o assunto disponibilizado pela Oracle.
Conhecendo o SQL Tuning Advisor
Para acessar a API do SQL Tuning Advisor, um usuário deve ser instanciado com o privilégio ADVISOR, conforme apresentado na Listagem 1.

Listagem 1. Configurando um usuário com perfil ADVISOR
CONN sys/password AS SYSDBA
GRANT ADVISOR TO arilo;
"


ATENÇÃO! A exibição deste artigo foi interrompida.


  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!






    0 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.


Nenhum comentário foi postado - seja o primeiro a comentar!



[Este post ainda não foi associado a uma sequência]
Publicidade
Autor
Arilo Claudio Dias Neto

É Doutor em Engenharia de Sistemas e Computação formado pela Universidade Federal do Rio de Janeiro (COPPE). Possui 6 anos de experiência em análise e desenvolvimento de software. É ainda editor técnico da Revista SQL Magazine, gerenciada pelo Grupo DevMedia.


Space do autor
Estatísticas
Favorito:
Comentários:
Feedback:
Utilidade:
0   0
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2012 - Todos os Direitos Reservados a web-03