ORA-03113 al ejecutar una consulta SQL

Question

Tengo una consulta SQL 400 línea que está lanzando una excepción a efectuar en 30 segundos

ORA-03113: EOF en el canal de comunicación

Abajo son cosas a tener en cuenta:

1. he puesto el tiempo de espera de hasta 10 minutos
2. Hay una última condición cuando se retiran resuelve este erro r.
3. Este error apareció recientemente cuando analicé índices.

La condición preocupante es la siguiente:

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%') 

Así que mi suposición es que la consulta se está terminada desde el lado del servidor, aparentemente porque su identificó como un consumidor de recursos.

¿Mi hipótesis es apropiada? ¿Cómo debo solucionar este problema?

EDIT: Traté de obtener el plan de explicación de la consulta defectuosa pero la consulta del plan de explicación también me da un error ORA-03113. Entiendo que mi consulta no es muy eficiente, pero ¿por qué debería ser un motivo para el error ORA-03113? Estoy tratando de ejecutar la consulta de sapo y no hay registro de alertas o de rastreo generada, mi versión db es Oracle9i Enterprise Edition Release 9.2.0.7.0 - Producción

Answer 1

Significa que ha sido desconectado. Es probable que esto no sea debido a ser un cerdo de recursos.

He visto donde la conexión a la base de datos se está ejecutando a través de una NAT y porque no hay tráfico, cierra el túnel y, por lo tanto, se desconecta la conexión. En general, si usa la agrupación de conexiones, no obtendrá esto.

Answer 2

Como dijo @ Daniel, la conexión de red al servidor se está rompiendo. Puede echar un vistazo al End-of-file on communication channel para ver si ofrece alguna sugerencia útil.

Comparte y disfruta.

Answer 3

Una posible causa de este error es un bloqueo de hilo en el lado del servidor. Compruebe si el servidor Oracle ha generado algún archivo de rastreo o ha registrado errores en su registro de alertas.

Usted dice que eliminar una condición de la consulta hace que el problema desaparezca. ¿Cuánto tarda la consulta en ejecutarse sin esa condición? ¿Ha revisado los planes de ejecución para ambas versiones de la consulta para ver si al agregar esa condición se está eligiendo algún plan ineficiente?

Answer 4

Esto a menudo es un error en el optimizador basado en costos con consultas complejas.

Lo que puede intentar hacer es cambiar el plan de ejecución. P.ej. use WITH para sacar algunas subquetas. O use SELECT/* + RULE */hint para evitar que Oracle use CBO. También ayuda a eliminar las estadísticas, porque Oracle luego usa otro plan de ejecución.

Si puede actualizar la base de datos, realice una instalación de prueba de 9.2.0.8 y ver si el error se fue allí.

A veces ayuda hacer un vuelco del esquema, colocar todo en él e importar el volcado de nuevo.

Answer 5

Según la información hasta el momento, parece un bloqueo de back-end, como sugirió Dave Costa hace algún tiempo. ¿Pudiste verificar los registros del servidor?

¿Puedes obtener el plan con set autotrace traceonly explain? ¿Sucede desde SQL * Plus localmente, o solo con una conexión remota? Ciertamente suena como un ORA-600 en el back-end podría ser el culpable, particularmente si es en tiempo de análisis. La ejecución exitosa que lleva más tiempo que la falla parece descartar un problema de red. Sospecho que está fallando bastante rápido, pero el cliente tarda hasta 30 segundos en abandonar la conexión muerta, o el servidor tarda tanto en escribir archivos de rastreo y de núcleo.

Lo que probablemente le deje la opción de parchear (si puede encontrar una solución relevante para el ORA-600 específico en Metalink) o actualizar la base de datos; o reescribiendo la consulta para evitarla. Puede obtener algunas ideas sobre cómo hacerlo desde Metalink si se trata de un error conocido. Si tiene suerte, podría ser tan simple como una pista, si la condición adicional está teniendo un impacto inesperado en el plan. ¿someMultiJoin.someColumn forma parte de un índice que se utiliza en la versión correcta? Es posible que el UPPER lo confunda y que pueda persuadirlo nuevamente al plan exitoso insinuando que use el índice de todos modos, pero eso es obviamente bastante especulativo.

Answer 6

Puede quitar el "ALTO" en ambas partes si está utilizando el como con los números (que no distinguen entre mayúsculas y minúsculas), esto puede reducir el tiempo de consulta para comprobar la frase como

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%') 

Is es igual a:

AND someMultiJoin.someColumn LIKE '%90936%' 

Los números no se ven afectados por SUPERIOR (% y es independiente de la carcasa de caracteres).

Answer 7

He tenido problemas de caída de conexión similares con ciertas variaciones en una consulta. En mi caso, las conexiones se cayeron cuando usé rownum en ciertas circunstancias. Resultó ser un error que tenía una solución mediante el ajuste de una determinada configuración de configuración de Oracle Database. Fuimos con una solución alternativa hasta que se pudiera instalar un parche. Me gustaría poder recordar más detalles o encontrar un correo electrónico anterior sobre esto, pero no sé si los detalles ayudarían a resolver su problema. Estoy publicando esto solo para decir que probablemente haya encontrado un error y que si tiene acceso al sitio de soporte de Oracle (support.oracle.com) probablemente encontrará que otros lo han informado.

Editar: Eché un vistazo rápido al soporte de Oracle. Hay más de 1.000 errores relacionados con ORA-03113 pero he encontrado uno que puede aplicar:

Bug 5015257: consulta falla CON ORA-3113 Y Coredump CUANDO QUERY_REWRITE_ENABLED = 'TRUE'

En resumen:

• Identificado en 9.2.0.6.0 y corregido en 10.2.0.1
• Ejecución de una consulta en particular (no identificado) provoca ORA-03113
• Ejecución de explicar en consulta no la misma
• No es un archivo básico de $ ORACLE_HOME/dbs
• solución consiste en establecer QUERY_REWRITE_ENABLED a falso: modifique conjunto de sistemas query_rewrite_enabled = FALSE;

Otra posibilidad:

Bug 3659827: ORA-3113 CONSULTA DE LARGA MARCHA

• 9.2.0.5.0 través 10.2.0.0
• Problema: El cliente tiene consulta larga ejecución que consistentemente produce ORA-3113 errros.
  En el sistema de clientes, reciben archivos core.log pero no reciben ningún error en el archivo alert.log. En el sistema de prueba que utilicé recibí errores de ORA-7445.
• Solución alternativa: configure "_complex_view_merging" = false en el nivel de sesión o instancia.