Limitar o grau de paralelismo (DOP) disponível para qualquer consulta

No Oracle Exadata (11gR2), temos um banco de dados relativamente robusto.

• cpu_count é 24
• parallel_server_instances é 2
• parallel_threads_per_cpu é 2

Observamos, através da observação no Oracle Enterprise Manager (OEM), que o desempenho foi péssimo devido à execução de consultas em série. Para resolver isso, todas as tabelas, visualizações materializadas e índices foram alterados para aproveitar o paralelismo. por exemplo:

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

O sistema foi alterado para ativar a paralelização:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

Isso resultou em melhor desempenho, mas ocasionalmente observamos no OEM que uma única consulta amarraria um DOP de 96 (todo o recurso disponível). Isso resultou em consultas subseqüentes sendo rebaixadas para um DOP de 1 (sem paralelização). Resultando em baixo desempenho até que a consulta oculta seja concluída.

Para resolver isso, tentamos limitar o DOP disponível para qualquer consulta com:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

Isso não teve efeito. Frequentemente, observamos consultas que usarão mais do que o limite (geralmente 48 ou 96, mas sem padrão real).

Como impedimos que uma única consulta monopolize todo o recurso disponível?

Conjuntos de servidores paralelos: PARALLEL_DEGREE_LIMIT limita o grau de paralelismo, mas se sua consulta estiver classificando ou agrupando, o número de processos paralelos pode ser o dobro (dois conjuntos de servidores para ativar o paralelismo entre processos). Isso explica por que você verá 48 processos paralelos, mesmo com um limite de 24. Isso também acontece se você usar o gerenciador de recursos para limitar o DOP.

Dicas paralelas: PARALLEL_DEGREE_LIMIT se aplica apenas a declarações que usam o grau automático de paralelismo. Quaisquer declarações que usem um grau codificado ou mesmo qualquer tipo de dica paralela no nível do objeto ignorarão o limite. Se você tiver essas dicas, isso pode explicar por que você vê 96 algumas vezes.

Calibrar E / S: Talvez o DOP automático não esteja sendo usado e, portanto, o limite não está sendo seguido, porque o E / S não foi calibrado . Esta consulta informará se o IO foi calibrado:

select * from V$IO_CALIBRATION_STATUS;

Já vi isso causar problemas antes, mas meu sistema atual não está calibrado e o DOP automático parece funcionar bem. Você pode saber se isso é realmente um problema, consultando a seção Notas do plano de explicação. Se você vê algo como - automatic DOP: Computed Degree of Parallelism is 2você, está bem, mas não quer ver automatic DOP: skipped because of IO calibrate statistics are missing.

Aumente o PARALLEL_MAX_SERVERS: em vez de se preocupar com a falta de servidores paralelos, recomendo que você aumente significativamente o PARALLEL_MAX_SERVERS. Você deve pelo menos tentar voltar ao valor padrão , PARALLEL_THREADS_PER_CPU x CPU_COUNT x concurrent_parallel_users x 5, entre 240 e 960, dependendo das configurações de memória.

Esses números altos parecem ridículos para muitos DBAs, mas na verdade fazem muito sentido pelos seguintes motivos:

• Os servidores paralelos da Oracle são mais leves do que a maioria das pessoas supõe. (E quase ninguém o testa, apenas encontra uma situação em que um DOP grande causa um problema e assume que o DOP alto é sempre ruim.)
• É comum executar uma consulta ad-hoc em uma ferramenta GUI que recupera apenas as 50 primeiras linhas, mas ainda usa dezenas de servidores paralelos. Essas consultas NÃO estão consumindo recursos significativos, a menos que PARALLEL_MAX_SERVERS seja muito baixo. Em seguida, as pessoas são gritadas por executar consultas perfeitamente razoáveis, o que pode levar a algumas situações feias.
• Um DOP muito grande para uma única consulta nem sempre é ruim. Todos assumem que, se você continuar aumentando o DOP, a sobrecarga ficará muito alta e o desempenho diminuirá significativamente. Mas em muitos sistemas, descobri que mesmo um DOP ridiculamente alto levará a um melhor desempenho, embora haja retornos definitivamente decrescentes, e isso pode ser muito injusto para outras sessões. Mas não adivinhe, teste; faça uma consulta e execute-a com todos os tipos de DOPs, até 1000. Você pode se surpreender.
• Sim, muito paralelismo pode ser ruim. Mas o que é pior para o sistema, com um pouco mais do que o número ideal de sessões, ou forçando uma consulta para serial e basicamente matando um trabalho importante? Você deve monitorar o sistema antes de introduzir limites arbitrários.