Um pouco sobre paralelismo em Oracle Database 11g

Queremos compartilhar com vocês nosso primeiro artigo, algumas informações sobre paralelismo no Oracle 11g release 2. Pontos importantes e cruciais para execuções paralelas de alta performance no ambiente de banco de dados. Vamos nessa!

Para inicio, é importante entendermos o processo e os paradigmas envolvidos na execução de uma query em paralelo. Quando optamos por uma execução paralela: seja ela indicada através do hint parallel, alter table <table_name> parallel ou através do parâmetro parallel_degree_policy (Falaremos mais sobre este parâmetro posteriormente). O Database irá seguir os seguintes passos para a execução da query:

• A Query “coordenadora” sera criada.
• A Query coordenadora irá obter o número de parallel servers indicado.
• As operações necessárias para query serão executadas na sequência definida pelo otimizador(por exemplo: full table scan, usado posteriormente para um join…). Cada operação desta será executada em paralelo, isto quando for possível.
• Ao final da execuçao de cada parallel server, a query coordenadora executará partes que nao podem ser executadas em paralelo. Por exemplo, a operação COUNT() que exigirá a contagem dos resultados de cada parallel server.
• Feito! A Query Coordenadora retorna o resultado ao usuário.

As operações parallelas no Oracle são implementadas utilizando o paradigma clássico da computação paralela: Produtor - Consumidor. Uma otima definição: O paradigma Produtor e o Consumidor, consiste em um conjunto de processos que compartilham um mesmo buffer. Os processos chamados produtores põem informação no buffer. Os processos chamados consumidores retiram informação deste buffer.

No caso do Oracle, as operações do consumidor podem iniciar no momento do término da operação do produtor. Supondo um query que faz um acesso FULL a uma tabela, e na sequencia um GROUP BY. Enquanto alguns parallel servers estiverem produzindo dados do FULL SCAN TABLE, outros parallel servers podem gerar o HASH JOIN das informaçoes que são necessárias ao GROUP BY. 

Com o paradigma Consumidor - Produtor temos dois tipos de operaçoes diferentes: As Intra-operaçoes e Inter-operaçoes. Intra-operaçoes envolvem o paralelismo de uma operação individual e Inter-operações envolvem o paralelismo no fluxo de dados entre as operações. No documento “How Parallel Execution Works” há um exemplo de intra-operações e inter-operações executadas durante uma query:

Supondo este select, executado com um nível quatro de paralelismo:

SELECT * FROM employees  ORDER BY last_name;   

Esta sequência de operaçoes será executada:

Figura 1: Inter-operaçoes e Intra-operaçoes.

Agora que o processo de execução em paralelo ficou melhor esclarecido, vamos entender como gerar de uma query em paralelo e o seu grau de paralelismo.

  Tradicionalmente, há duas formas de direcionar uma query a ser executada em paralelo:

• Através do hint “/*+ parallel(n) */”. O n é o grau de paralelismo usado para a execução da consulta.
• Atribuindo a uma tabela o paralelismo e o seu grau. Por exemplo, “ALTER TABLE customers PARALLEL 4;” a tabela customers assume o grau 4 de paralelismo e todas as operações nela serão paralelizadas.

Entretanto, há uma novidade no Oracle 11G release 2 que é o Automatic Parallel Degree Policy. Através do Automatic Parallel Degree pode-se habilitar as seguintes funcionalidades: automatic DOP, parallel statement queuing e in-memory parallel execution. O Automatic Parallel Degree é ativado através de um novo parametro no database, o “PARALLEL_DEGREE_POLICY”. Este pode assumir três valores: 

• MANUAL - Desabilita todas as funcionalidades indicadas acima. Remete ao comportamento anterior ao Oracle Database 11g, Release 2 (11.2). É o valor default.
• LIMITED - Habilita apenas o automatic DOP.
• AUTO - Habilita automatic DOP, parallel statement queuing e in-memory parallel execution.

Quando PARALLEL_DEGREE_POLICY está setado como AUTO, o Oracle Database automaticamente determina quais processos devem executar em paralelo ou não e qual o grau de paralelismo. Também irá definir se tal processo pode ser executado imediatamente ou deve ser enfilerado até adquirir número de recursos suficientes a operação.

Vamos analisar as três funcionalidades Automatic Parallel Degree:

Automatic Degree Of Parallelism: Quando PARALLEL_DEGREE_POLICY está setado como AUTO, o automatic DOP é ativada. Com ela o otimizador automaticamente determina o grau de paralelismo para a execuçao de determinada query. O Otimizador irá determinar isto atraves de metricas como as estatísticas coletadas e estatisticas de I/O Há um parametro que limita o número maximo do grau de paralelismo, que é o parametro: PARALLEL_DEGREE_LIMIT. O valor default dele é CPU, que é calculado através da fórmula: PARALLEL_THREADS_PER_CPU * CPU_COUNT * número de instancias. Um outro parâmetro importante é o PARALLEL_MIN_TIME_THRESHOLD. O valor desta variável indica o tempo de execução mínimo para o uso do DOP. Significa dizer que se o tempo calculado pelo otimizador for inferior ao valor da variavel PARALLEL_MIN_TIME_THRESHOLD, a query será executada serialmente. Um ponto importante é: O DOP é utilizado para apenas nas intraoperações paralelas.

In-memory Parallel Execution

Quando PARALLEL_DEGREE_POLICY está setado como AUTO, a opção In-memory Parallel Execution é ativada. Com esta funcionalidade o Oracle pode armazenar o objeto acessado paralelamente no buffer cache(SGA). A decisão de colocar o objeto em memória é feito atraves de heurísticas baseadas na frequência de acesso ao objeto e tambem ao seu tamanho.

Parallel Statement Queuing

Imagine a situaçao onde uma query parallel é gerada, mas não há recursos suficientes para executá-la. Com a funcionalidade Parallel Statement Queuing, o Oracle Database pode enfileirar estas consultas para a execução quando existirem parallel servers ativos suficientes para tal. O valor máximo de parallel servers ativos simulteneâmente é indicado pela variável PARALLEL_SERVERS_TARGET. Supondo que a variável está setada em 64, e o número de servers ativos é 60 e uma nova execução em paralelo exige 16 novos parallel servers, isto irá para a fila, devido a não existencia de parallel server suficientes.

Com o parâmetro PARALLEL_DEGREE_POLICY setado para AUTO deixamos para o otimizador a decisão de paralelizar uma query e também o seu grau de paralelismo. Alem de todo gerenciamento destas execuções como a decisão de colocar em cache e o enfileiramento no caso da necessidade de recursos.

Um pouco mais sobre as interoperaçoes…

Analisando um pouco as interoperações percebemos um grande uso de área “temporária” para a execução. Randolf Geist faz uma análise sensacional sobre isto: //www.oracle.com/technetwork/articles/database-performance/geist-parallel-execution-1-1872400.html

Existem dois principais buffers associados a estas interoperações: HASH_AREA_SIZE e SORT_AREA_SIZE alocados no PGA. Caso não exista espaço suficiente nestes buffers para suportar os dados das operações, o Database usará o disco para esta tarefa, gerando lentidao no processamento.

Desde o Oracle 11G utilizamos o AMM(Automatic Memory Management), onde atribuimos à instância a distribuiçao de memória entre o PGA e o SGA e suas áreas de buffer. Entretanto, os dois buffers SORT_AREA_SIZE e HASH_AREA_SIZE vem setados por default. Os valores estao na figura 2: 

Sugiro que estes valores sejam modificados de acordo com a necessidade de operações envolvidas e a disponibilidade de memory_target.

Ponto importante:

O otimizador utiliza de várias métricas para decidir o DOP em tempo de execuçao. Uma das métricas utilizadas envolve os recursos de hardware e principalmente estatísticas de I/O do disco. Estas informaçoes são coletadas através da procedure DBMS_RESOURCE_MANAGER.CALIBRATE_IO.

Neste artigo mostrei uma forma de atribuirmos a responsabilidade de operações paralelas a propria instância. E verificando os pontos necessários para o melhor desempenho destas operações.

Com isto criamos um ecossistema favorável as operações paralelas no banco de dados. Este ecossistema pode propiciar altissímos ganhos de desempenho em ambientes OLAP ou a consultas com altíssimo processamento de dados.

Referências:

//docs.oracle.com/cd/E11882_01/server.112/e25523/parallel002.htm //docs.oracle.com/cd/E11882_01/server.112/e25523/parallel002.htm#BEIBHJJC

Joel Pérez é um DBA (Oracle ACE Director, Maximum Availability OCM, OCM Cloud Admin. & OCM12c/11g) Especialista com mais de 16 anos de experiência real no mundo da tecnologia Oracle, especializada na concepção e implementação de soluções: Nuvem, alta disponibilidade, recuperação de desastres, Upgrades, replicação e toda a área relacionada com bancos de dados Oracle. Joel serve como "Chief Technologist & MAA, TEM Architect" para www.Enmotech.com Yunhe ENMO (Beijing) Technology Co. Ltd. Beijing, China. OCM Perfil Joel Perez: //education.oracle.com/education/otn/JoelPerez.htm

Jean Maia é bacharel em Ciência da Computação e Oracle DBA. Possui conhecimentos em Alta Disponibilidade, Backup/Recovery, Replicação e Tuning. Além de experiências com outras soluções Oracle como: Oracle Soa Suite, ODI e Oracle NoSQL. Siga Jean em seu blog: //jeanmaiadba.blogspot.com.br/

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.