N style="mso-spacerun: yes">
Clique aqui para ler todos os artigos desta edição
Perigos e armadilhas do particionamento - Parte 1
por Arup Nanda
Particionar é um dos tópicos favoritos para autores, apresentadores e para a comunidade de DBA em geral, mas a maioria dos documentos enfatiza apenas as bases e conceitos fundamentais por trás do particionamento. A atitude mais freqüente da maioria do DBAs, depois de aprender os fundamentos, é mergulhar dentro dos bancos de dados com o particionamento em mente. Este artigo descreve alguns dos problemas potenciais, características pequenas ou não documentadas, que podem criar situações inesperadas (e não desejadas) para as quais deveríamos estar atentos (ler Nota 1). Veremos também como solucioná-los.
Nota 1. Importante.
Para uma melhor compreensão deste artigo, é interessante ter o conhecimento básico sobre particionamento, pois este artigo não irá abordar este assunto.
Revisão da plan table
Antes de começarmos, vejamos uma tabela muito familiar para a identificação de caminhos de execução que já está disponível há muito tempo - a PLAN_TABLE. Você certamente já usou esta tabela para identificar o plano otimizado de uma consulta. Nós examinaremos três colunas específicas nesta tabela (quatro, em Oracle9i) uma vez que isto é importante para a opção de particionamento (partitioning option). Na Tabela 1 temos uma descrição básica destas colunas.
Tabela 1. Descrição das colunas da PLAN_TABLE
|
PARTITION_START |
Quando o otimizador procurar por dados numa faixa de partições, esta coluna indica o PARTITION_ID da partição inicial daquela faixa. |
|
PARTITION_STOP |
Quando o otimizador procurar uma faixa de partições, esta coluna indica o PARTITION_ID da última partição da faixa. |
|
PARTITION_ID |
Cada passo no otimizador é identificado por um número unívoco chamado STEP_ID. Esta coluna exibe o STEP_ID do passo em PLAN_TABLE que decidiu o dos PARTITION_IDs inicial e final. |
|
FILTER_PREDICATES |
A condição exata usada para avaliar e chegar aos PARTITION_IDs inicial e final (específica do Oralce 9i). |
Maiores informações e explicações sobre estas colunas serão providas adiante neste documento junto com os exemplos correspondentes.
A ferramenta DBMS_XPLAN
Seria proveitoso aqui descrever uma ferramenta interessante disponível no 9i, um novo pacote chamado DBMS_XPLAN que é útil para examinar os dados da PLAN_TABLE. Em vez de escrever um comando SQL complicado para analisar o plano de execução do PLAN_TABLE, uma chamada ao DBMS_XPLAN exibe o plano de execução formatado, o que facilita o seu uso. Para selecionar o plano de execução para o último comando "explain plan", simplesmente use a consulta:
select * from table(dbms_xplan.display(format=>'BASIC'))
O uso do operador TABLE () (ou, a execução de uma operação de cast) faz com que os valores retornados pela função sejam exibidos como colunas em uma tabela, podendo ser consultados como se tivessem sido selecionados de uma tabela relacional (ver Listagem 1).
PLAN_TABLE_OUTPUT
---------------------------------------------
--------------------------------------------
| Id | Operation | Name |
--------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
| 2 | NESTED LOOPS | |
| 3 | TABLE ACCESS FULL | PTEST3HA |
| 4 | TABLE ACCESS FULL | PTEST3HB |
--------------------------------------------
Listagem 1. Plano de execução.
A função display() possui três argumentos (ver Tabela 2).
Tabela 2. Argumentos da função display.
|
TABLE_NAME |
O nome da tabela na qual o plano de otimização é armazenado. Por padrão será armazenado em PLAN_TABLE. ... |
