Lo más importante que debe entender sobre el paralelismo de Oracle es que es complicado. Optimizar el paralelismo requiere mucho conocimiento de Oracle, leer los manuales, verificar muchos parámetros, probar consultas de ejecución prolongada y mucho escepticismo.
Haga las preguntas correctas
Los problemas paralelos realmente involucran tres preguntas diferentes:
- ¿Cuántos servidores paralelos se solicitaron?
- ¿Cuántos servidores paralelos se asignaron?
- ¿Cuántos servidores paralelos se usaron significativamente?
Use las mejores herramientas
Vaya directamente a la mejor herramienta:SQL Monitoring con informes activos. Encuentre su SQL_ID y genere el informe HTML:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Esta es la única manera de saber cuánto tiempo se dedicó a cada paso del plan de ejecución. Y le dirá cuánto paralelismo se usó efectivamente y dónde. Por ejemplo:
Otra buena opción es type => 'text' . No tiene tanta información, pero es más rápido de ver y más fácil de compartir.
SQL Monitoring también incluye el DOP solicitado y el DOP asignado:
Un paralelo de 100 líneas select puede funcionar maravillosamente, pero luego todo se detiene en un solo paso debido a una secuencia no almacenada en caché. Puede mirar un plan de explicación, un seguimiento o un informe AWR durante horas y no ver el problema. El informe activo hace que los pasos lentos sean casi triviales de encontrar. No pierdas el tiempo adivinando dónde está el problema.
Sin embargo, todavía se requieren otras herramientas. Un plan de explicación generado con explain plan for ... y select * from table(dbms_xplan.display); proporcionará algunas piezas clave de información. Específicamente las Notes La sección puede incluir muchas razones por las que la consulta no solicitó paralelismo.
Pero ¿POR QUÉ obtuve esa cantidad de servidores paralelos?
La información relevante se distribuye en varios manuales diferentes, que son muy útiles pero, en ocasiones, inexactos o engañosos. Hay muchos mitos y muchos malos consejos sobre el paralelismo. Y la tecnología cambia significativamente con cada versión.
Cuando reúne todas las fuentes confiables, la lista de factores que influyen en la cantidad de servidores paralelos es asombrosamente grande. La lista a continuación está ordenada aproximadamente por lo que creo que son los factores más importantes:
- Paralelismo entre operaciones Cualquier consulta que utilice clasificación o agrupación asignará el doble de servidores paralelos que el DOP. Esto es probablemente responsable del mito "¡Oracle asigna tantos servidores paralelos como sea posible!".
- Sugerencia de consulta Preferiblemente una sugerencia a nivel de declaración como
/*+ parallel */, o posiblemente una sugerencia a nivel de objeto como/*+ noparallel(table1) */. Si un paso específico de un plan se ejecuta en serie, generalmente se debe a sugerencias a nivel de objeto en solo una parte de la consulta. - SQL recursivo Algunas operaciones pueden ejecutarse en paralelo, pero SQL recursivo puede serializarlas de manera efectiva. Por ejemplo, una secuencia no almacenada en caché en una inserción grande. El SQL recursivo generado para analizar la declaración también será serial; por ejemplo, consultas de muestreo dinámico.
- Alterar sesión
alter session [force|enable] parallel [query|dml|ddl];Tenga en cuenta que DML paralelo está deshabilitado de forma predeterminada. - Grado de tabla
- Grado índice
- El índice era más barato Las sugerencias paralelas solo le dicen al optimizador que considere un escaneo completo de la tabla con un DOP determinado. En realidad, no fuerzan el paralelismo. El optimizador aún puede usar un acceso de índice en serie si cree que es más barato. (El
FULLuna sugerencia puede ayudar a resolver este problema). - Gestión de planes Las líneas de base del plan SQL, los esquemas, los perfiles, la reescritura avanzada y los traductores de SQL pueden cambiar el grado de paralelismo a sus espaldas. Consulte la sección Nota del plan.
- Edición Solo las ediciones Enterprise y Personal permiten operaciones paralelas. Excepto por el paquete DBMS_PARALLEL_EXECUTE.
- PARALLEL_ADAPTIVE_MULTI_USER
- AJUSTE_AUTOMÁTICO_PARALELO
- PARALLEL_DEGREE_LIMIT
- PARALLEL_DEGREE_POLICY
- PARALLEL_FORCE_LOCAL
- PARALLEL_INSTANCE_GROUP
- PARALLEL_IO_CAP_ENABLED
- PARALLEL_MAX_SERVERS Este es el límite superior para todo el sistema. Hay una compensación aquí. Ejecutar demasiados servidores paralelos a la vez es malo para el sistema. Pero degradar una consulta a serial puede ser desastroso para algunas consultas.
- PARALLEL_MIN_PERCENT
- PARALLEL_MIN_SERVERS
- PARALLEL_MIN_TIME_THRESHOLD
- SERVIDORES_PARALELOS_OBJETIVO
- PARALLEL_THREADS_PER_CPU
- Número de nodos RAC Otro multiplicador para el DOP predeterminado.
- CPU_COUNT Si se utiliza el DOP predeterminado.
- RECUPERACIÓN_PARALELISMO
- FAST_START_PARALLEL_ROLLBACK
- Perfil
SESSIONS_PER_USERtambién limita los servidores paralelos. - Administrador de recursos
- Carga del sistema Si parallel_adaptive_multi_user es verdadero. Probablemente sea imposible adivinar cuándo Oracle comenzará a acelerar.
- PROCESOS
- Restricciones DML paralelas Parallel DML no funcionará si se da alguno de estos casos:
- COMPATIBLE <9.2 para dentro de la partición
- INSERTAR VALORES, tablas con disparadores
- replicación
- integridad autorreferencial o eliminación en cascada o restricciones de integridad diferida
- acceder a una columna de objeto
- tabla sin particiones con LOB
- paralelismo dentro de la partición con un LOB
- transacción distribuida
- tablas agrupadas
- mesas temporales
- ¿Las subconsultas escalares no se ejecutan en paralelo? Esto está en el manual, y desearía que esto fuera cierto, pero mis pruebas indican que el paralelismo funciona aquí en 11g.
- ENQUEUE_RESOURCES Parámetro oculto en 10g, ¿sigue siendo relevante?
- Tablas organizadas por índice ¿No se puede insertar la ruta directa a los IOT en paralelo? (¿Sigue siendo cierto?)
- Requisitos de funciones canalizadas en paralelo Debe usar un
CURSOR(?). POR HACER. - Las funciones deben ser PARALLEL_ENABLE
- Tipo de declaración Las versiones anteriores restringían el paralelismo en DML según la partición. Algunos de los manuales actuales aún incluyen esto, pero ciertamente ya no es así.
- Número de particiones Solo para uniones por partición en versiones anteriores.(?)
- Errores Específicamente, he visto muchos errores con el análisis. Oracle asignará la cantidad correcta de servidores paralelos, pero no pasará nada, ya que todos esperan eventos como
cursor: pin s wait on x.
Esta lista ciertamente no está completa y no incluye características 12c. Y no se ocupa de los problemas del sistema operativo y del hardware. Y no responde a la pregunta terriblemente difícil, "¿cuál es el mejor grado de paralelismo?" (Respuesta corta:más suele ser mejor, pero a expensas de otros procesos). Con suerte, al menos le dará una idea de lo difíciles que pueden ser estos problemas y un buen lugar para comenzar a buscar.
