¿Usa ODBC Trace o Oracle Trace para encontrar la causa del error?

Question

Tengo un servicio de terceros de Windows que controla/monitorea equipos y actualiza una base de datos Oracle. Sus servicios ocasionalmente informan que un error sobre una fila/columna en la base de datos es "malo" pero no da el error subyacente de la base de datos, y sus servicios deben reiniciarse y todo está bien. La sospecha actual es que algo de nuestras aplicaciones/servicios que leen/escriben en esas mismas tablas/filas está interfiriendo, es decir, algún tipo de bloqueo/bloqueo. Sospecho que hay algún tipo de filtración en su sistema, ya que ocurre una vez a la semana, pero nuestros sistemas nunca necesitan reiniciarse de esta manera.

Intenté hacer que el DBA ejecutara un rastreo en Oracle (10g), pero esto logró que nuestras aplicaciones no pudieran acceder a la base de datos de Oracle. Nuestros sistemas acceden a Oracle en .NET, ya sea utilizando el cliente Oracle ODP o el cliente de Microsoft (programas más antiguos) y en este mismo servidor (aplicaciones web o servicios) o desde otras estaciones de trabajo de control. Los servicios de terceros se conectan a Oracle a través de ODBC en este servidor. También intenté ejecutar un seguimiento ODBC (ya que eso solo sería actividad del servicio de terceros), pero no obtuve nada en el archivo de rastreo en absoluto.

Así que estoy tratando de encontrar la manera de conseguir que el seguimiento de ODBC funcione o lo que tengo que cuidar para que el seguimiento de Oracle no mate mi servidor.

Estoy buscando el error sin conexión que Oracle está devolviendo al servicio de terceros, por lo que puedo decir si estamos interfiriendo con su acceso a los datos de alguna manera.

Answer 1

Si un bloque en la base de datos está dañado "Malo" esto debería aparecer en los registros de alerta como un error ORA-01578. Buscaría en el registro de archivo el error ORA y luego lo compararía con la marca de tiempo en el error del cliente que se informa. Esto hace que se asuma la definición de "malo". Sería mejor publicar los mensajes de error exactos.

El rastreo combinado en la base de datos es algo delicado ya que afectará el rendimiento de toda su aplicación. Y dejarlo encendido durante una semana entera puede no ser factible. También encontré en un caso (no puedo recordar la circunstancia exacta) donde activar el rastreo solucionó el error.

Un método que he utilizado en el pasado es agregar la instrucción SQL para modificar la sesión y activar sqltrace. Esto se basa en la capacidad de modificar el código de alguna manera. Dependiendo de la aplicación esto puede o no ser posible.

Otro método sería trabajar con el DBA para identificar la sesión y activar el rastreo sql para esa sesión. Además, si puede identificar las sentencias sql ofensores y los valores de los parámetros, es posible que pueda replicar el problema fuera del servicio.

He encontrado que la mayoría de los ORM evitan volver a pasar el error de ORA. Sin embargo, normalmente se registra en la capa del servidor de aplicaciones con el error ORM asociado.

He utilizado estos métodos y las variaciones de estos métodos para solucionar problemas de errores en la aplicación. Espero que esto sea útil.