Tuning de bancos de dados Oracle - Revista SQL Magazine 95

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Este artigo apresenta informações relacionadas ao tuning em bancos de dados Oracle. Mais precisamente, analisaremos aqui alguns casos relacionados ao processamento de consultas SQL, entendendo como elas são processadas e o que fazer para melhorá-las.

Do que se trata o artigo:

Este artigo apresenta informações relacionadas ao tuning em bancos de dados Oracle. Mais precisamente, analisaremos aqui alguns casos relacionados ao processamento de consultas SQL, entendendo como elas são processadas e o que fazer para melhorá-las em termos de desempenho.


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

Este tema é útil a todo administrador de banco de dados e desenvolvedor que deseja aprender a formar queries mais apropriadas no Oracle, alcançando melhor performance à medida que diminui grandes ocorrências de hard parses.

Resumo DevMan:

Este artigo apresenta conceitos sobre a estrutura e mecanismos internos do banco de dados Oracle relacionados ao processamento de comandos SQL, conhecimento necessário para compreender as técnicas práticas de tuning, demonstradas na sequência, que deverão reduzir a ocorrência de hard parses.

Um banco de dados com baixo desempenho nem sempre é aceitável. É sabido que somente o investimento na capacidade física (hardware) dos servidores não é garantia de melhora na performance do banco de dados. Há momentos em que o tuning é a melhor ou a única saída.

Cada banco de dados possui seu mecanismo interno de processamento e, embora possam ser parecidos, não necessariamente são idênticos e tão pouco executam tarefas idênticas da mesma forma. Conhecer as características do Sistema Gerenciador de Banco de Dados (SGBD) usado é crucial para administrar e desenvolver aplicações com desempenho e escalabilidade melhores, mais seguras, enfim, superiores.

O presente artigo foi escrito para ajudar os profissionais da área a entenderem e diminuírem a ocorrência de hard parses, abordando como o produto banco de dados Oracle funciona internamente ao processar comandos recebidos e demonstrando algumas medidas e técnicas práticas a serem aplicadas para alcançar um melhor desempenho.

A profundidade técnica do artigo é intermediária. Os pontos principais não são tratados superficialmente, o que requer um conhecimento prévio relacionado à administração do banco de dados. Por sua vez, o público alvo são Administradores de Banco de Dados e Desenvolvedores envolvidos com o banco de dados Oracle.

Os conceitos e técnicas aqui propostos se baseiam em bancos de dados nas versões Oracle 10g e 11g, configurados como servidores dedicados (dedicated servers) e com o parâmetro CURSOR_SHARING no seu valor padrão EXACT. Portanto, as medidas aqui descritas podem não ser válidas em ambientes com outras configurações ou outras versões de banco de dados.

Processamento de SQL (SQL Processing)

Resumidamente, ao receber um comando, o Oracle irá analisar se ele é válido. Caso seja, verifica-se nas estruturas de memória se já existe alguma informação que possa fazê-lo pular etapas do processo ou se terá que percorrer o caminho completo. Após definida a rota, são realizados mais alguns processamentos internos e, finalmente, o comando é executado.

A Figura 1 representa um fluxograma com as etapas desse processo.

Figura 1. Etapas do processamento de comandos SQL (Fonte: Oracle Inc).

Os detalhes de cada etapa mostrada na Figura 1 serão discutidos a seguir.

Parsing

O verbo to parse do idioma inglês, conforme o dicionário Michaelis, significa analisar gramaticalmente, e é exatamente esse o sentido deste termo presente na primeira etapa do processo de análise de comandos SQL. To parse a query significa interpretar e analisar um comando SQL. Podemos fazer uma analogia com a compilação de um código considerando a sua linguagem, afinal, SQL (abreviação de Structured Query Language) não deixa de ser uma linguagem.

Após essa análise, também é executada uma busca na área de memória chamada library cache (situada dentro da shared pool) na tentativa de acelerar o processo, pulando algumas etapas custosas que vêm na sequência.

Análise Sintática

A primeira análise é verificar se o comando enviado é válido e interpretável pelo sistema. Aqui podem ser capturados erros de digitação (Listagem 1), erros de código ou de regras de SQL (Listagens 2 e 3), entre outros.

Na Listagem 1, digitou-se, sem querer, FORM ao invés de FROM.

Listagem 1. Exemplo de erro de digitação.

SQLPLUS> SELECT ename FORM emp;
 SELECT ename FORM emp
                   *
 ERROR at line 1:
 ORA-00923: FROM keyword not found where expected

Na Listagem 2, a cláusula GROUP BY deveria vir após a cláusula WHERE, não antes. Por definição da linguagem SQL isso não é possível.

Listagem 2. Exemplo de erro de código ou de regras de SQL.

SQLPLUS> SELECT COUNT(*) member#, deptno FROM emp GROUP BY deptno WHERE deptno IN (10, 20, 30);
 SELECT COUNT(*) member#, deptno FROM emp GROUP BY deptno WHERE deptno IN (10, 20, 30)
                                                          *
 ERROR at line 1:
 ORA-00933: SQL command not properly ended

Por fim, na Listagem 3, os tipos das colunas (datatypes) devem ser respectivamente compatíveis ao usar o comando UNION.

Listagem 3. Exemplo de erro de código ou de regras de SQL – parte 2.

SQLPLUS> SELECT ename, deptno FROM emp
   2  UNION
   3  SELECT deptno, dname FROM dept;
 SELECT ename, deptno FROM emp
        *
 ERROR at line 1:
 ORA-01790: expression must have same datatype as corresponding expression

Finalizada a análise sintática sem encontrar erros, passamos para a análise semântica.

Análise Semântica

Com a sintaxe correta, serão analisados mais alguns itens para confirmar se é possível executar o comando enviado. Os objetos solicitados existem (Listagem 4)? O usuário tem os privilégios necessários sobre os objetos requisitados (Listagem 5)? Há ambuiguidades no código (Listagem 6)? Essas e outras questões serão avaliadas para garantir que o comando poderá ser processado internamente nos próximos passos.

Na Listagem 4, solicitou-se extrair informações da tabela clientes, mas essa tabela não existe.

Listagem 4. Exemplo de verificação de objetos.

SQLPLUS> SELECT nome FROM clientes;
 SELECT nome FROM clientes
                  *
 ERROR at line 1:
 ORA-00942: table or view does not exist

Na Listagem 5, o usuário conectado tem privilégio de leitura, pois consegue executar um SELECT na tabela EMP do esquema SCOTT, mas não tem o privilégio necessário para fazer atualizações (UPDATE) nessa mesma tabela.

Listagem 5. Exemplo de verificação de privilégios.

SQLPLUS> SELECT empno, ename, sal FROM scott.emp
    2  WHERE ename='DBA Troll';
   
       EMPNO ENAME             SAL
  ---------- ---------- ----------
        7123 DBA Troll        1500
 
 SQLPLUS> UPDATE scott.emp SET sal=15999 WHERE ename='DBA Troll';
  UPDATE scott.emp SET sal=15999 WHERE ename='DBA Troll'
               *
  ERROR at line 1:
  ORA-01031: insufficient privileges
"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?