viernes, 9 de agosto de 2024

ORA-12801: error signaled in parallel query server P09S "NO siempre es un error de Paralelismo"

Me reportan que un proceso mensual, dejó de "funcionar" de un momento a otro.

No se ha actualizado código últimamente.

Cuando el proceso se ejecuta, el mismo se detiene con el siguiente error.

ORA-12801: error signaled in parallel query server P09S

ORA-41422: unsupported use of an incoming database link connection from a background, JOBQ slave or PQ slave
ORA-02063: preceding 2 lines from PROD

Validando, una de las tablas, es una tabla grande con un campo CLOB y que podría ser el problema, ya que tengo un paralelismo de 5 en dicho objecto.

Modificó el objeto y le quito el nivel de "degree" cambiando el paralelismo a 1 y vuelvo a ejecutar la consulta del reporte.

Consulta:
SELECT DISTINCT FC.NUMERO_CLIENTE AS CodCliente,
FC.CEDULA AS IdCliente,
NOMBRE_COMPLETO AS NombreCliente, EC.EMAIL
FROM oOWNER1.TABLA1 FC INNER JOIN OWNER2.TABLA2 EC
ON TO_NUMBER(FC.NUMERO_CLIENTE) = EC.COD_CLIENTE
WHERE NOMBRE_COMPLETO LIKE '%GUSTAVO %' 
AND FC.CEDULA LIKE '%%' 
AND EC.FECHA_GENERACION BETWEEN TO_DATE( '05/01/24','MM/DD/RR') 
AND TO_DATE( '08/01/24','MM/DD/RR');

El mensaje ahora ha cambiado.

ORA-01722: número no válido
01722. 00000 - "invalid number"
*Cause: The specified number was invalid.
*Action: Specify a valid number.

Lo único especial que observo, es la función TO_NUMBER en el cambio de JOIN entre las tablas.
Procedo a quitar la función y la consulta se ejecuta sin problema.

Pienso ahora, que es más un problema de datos.
Estas columnas en el JOIN son de tipo varchar2, pero debería almacenar sólo dígitos. Sobre dichas columnas no hay un constraint que valide que no se permita caracteres en dichos campos.

ALTER TABLE tu_tabla ADD CONSTRAINT solo_digitos CHECK (REGEXP_LIKE(tu_columna, '^[0-9]+$'));

Busco en la columan de JOIN de ambas tablas, a ver si existen valores que no sean dígitos en el campo.

select * from owner1.tabla1
where regexp_like(upper(NUMERO_CLIENTE),'[^0-9]'); 

select * from owner2.tabla2
where regexp_like(upper(COD_CLIENTE),'[^0-9]');

Para la primera tabla no se devuelven registros, sin embargo, para la segunda tabla si.

Simple, esto es lo que realmente esta dando problemas, pero el mensaje que estábamos recibiendo no era el correcto.

Ahora lo que queda es solucionar el problema de datos en la tabla.

Al final, el problema termino siendo en error en un proceso que consultaba una columna que no era la correcta para insertar los números de clientes.




No hay comentarios:

Publicar un comentario

Te agradezco tus comentarios. Te esperamos de vuelta.

Todos los Sábados a las 8:00PM

Optimismo para una vida Mejor

Optimismo para una vida Mejor
Noticias buenas que comentar