Limite el grado de paralelismo (DOP) disponible para cualquier consulta

En Oracle Exadata (11gR2), tenemos una base de datos relativamente robusta.

• cpu_count es 24
• paralelo_instalaciones_servidor es 2
• parallel_threads_per_cpu es 2

Observamos, a través de la observación en Oracle Enterprise Manager (OEM), que el rendimiento era terrible debido a que las consultas se ejecutaban en serie. Para resolver esto, todas las tablas, vistas materializadas e índices fueron alterados para aprovechar el paralelismo. p.ej:

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

El sistema fue alterado para activar la paralelización:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

Esto dio como resultado un mejor rendimiento, pero ocasionalmente observamos en OEM que una sola consulta vincularía un DOP de 96 (todos los recursos disponibles). Esto dio como resultado que las consultas posteriores se redujeran a un DOP de 1 (sin paralelización). Resultando en un bajo rendimiento hasta que se completa la consulta de acaparamiento.

Para resolver esto, intentamos limitar el DOP disponible para cualquier consulta con:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

Esto no tuvo efecto. Frecuentemente observamos consultas que usarán más del límite (generalmente 48 o 96, pero ningún patrón real).

¿Cómo evitamos que una sola consulta acapare todos los recursos disponibles?

Conjuntos de servidores paralelos: PARALLEL_DEGREE_LIMIT limita el grado de paralelismo, pero si su consulta está ordenando o agrupando, el número de procesos paralelos puede ser el doble (dos conjuntos de servidores para permitir el paralelismo entre procesos). Eso explica por qué verá 48 procesos paralelos incluso con un límite de 24. Esto también sucede si utiliza el administrador de recursos para limitar el DOP.

Sugerencias paralelas: PARALLEL_DEGREE_LIMIT solo se aplica a las declaraciones que usan el grado de paralelismo automático. Cualquier declaración que use un grado codificado, o incluso cualquier tipo de sugerencia paralela a nivel de objeto, ignorará el límite. Si tienes esas pistas, eso podría explicar por qué ves 96 algunas veces.

Calibrate IO: tal vez no se esté utilizando DOP automático y, por lo tanto, no se siga el límite, porque el IO no se calibró . Esta consulta le dirá si el IO fue calibrado:

select * from V$IO_CALIBRATION_STATUS;

He visto que esto causa problemas antes, pero mi sistema actual no está calibrado y el DOP automático parece funcionar bien. Puede saber si esto es realmente un problema mirando la sección de Notas del plan de explicación. Si ves algo así - automatic DOP: Computed Degree of Parallelism is 2, estás bien, pero no quieres ver automatic DOP: skipped because of IO calibrate statistics are missing.

Aumente PARALLEL_MAX_SERVERS: en lugar de preocuparse por quedarse sin servidores paralelos, le recomendaría que aumente significativamente PARALLEL_MAX_SERVERS. Al menos debe intentar volver al valor predeterminado , PARALLEL_THREADS_PER_CPU x CPU_COUNT x concurrent_parallel_users x 5, entre 240 y 960, según la configuración de su memoria.

Esos números altos suenan ridículos para muchos DBA, pero en realidad tienen mucho sentido por las siguientes razones:

• Los servidores paralelos de Oracle son más livianos de lo que la mayoría de la gente supone. (Y casi nadie lo prueba, solo encuentran una situación en la que un DOP grande causa un problema y asumen que un DOP alto siempre es malo).
• Es común ejecutar una consulta adhoc en una herramienta GUI que solo recupera las primeras 50 filas, pero aún usa docenas de servidores paralelos. Estas consultas NO están consumiendo recursos significativos, a menos que PARALLEL_MAX_SERVERS sea demasiado bajo. Luego se les grita a las personas por ejecutar consultas perfectamente razonables, lo que puede conducir a algunas situaciones feas.
• Un DOP muy grande para una sola consulta no siempre es malo. Todos asumen que si sigue aumentando el DOP, la sobrecarga será demasiado alta y el rendimiento disminuirá significativamente. Pero en muchos sistemas he descubierto que incluso un DOP ridículamente alto conducirá a un mejor rendimiento, aunque definitivamente hay rendimientos decrecientes, y puede ser muy injusto para otras sesiones. Pero no solo adivines, pruébalo; tome una consulta y ejecútela con todo tipo de DOP, hasta 1000. Puede sorprenderse.
• Sí, demasiado paralelismo puede ser malo. Pero, ¿qué es peor para el sistema, tener un poco más que el número óptimo de sesiones o forzar una consulta en serie y básicamente matar un trabajo importante? Debe monitorear el sistema antes de introducir límites arbitrarios.