ACTUALIZAR:
No encuentro ninguna referencia publicada a este tipo específico de corrupción de FECHA en el sitio de soporte de Oracle. (Puede estar allí, mis búsquedas rápidas simplemente no aparecieron).
- Script Baddate para verificar la base de datos en busca de fechas corruptas [ID 95402.1]
- Error 2790435:Serial INSERT con SELECCIÓN paralela y conversión de tipo puede insertar datos corruptos [ID 2790435.8]
El resultado de la función DUMP() muestra que el valor de la fecha no es válido:
Typ=12 Len=7: 120,110,11,18,13,0,16
Esperamos que el byte de minutos sea un valor entre uno y sesenta, no cero.
Los 7 bytes de un valor DATE representan, en orden, siglo (+100), año (+100), mes, día, hora (+1), minutos (+1), segundos (+1).
La única vez que he visto valores de FECHA no válidos como este cuando se proporcionaba un valor de FECHA como una variable de vinculación, desde un programa Pro*C (donde el valor de vinculación se proporciona en la representación interna de 7 bytes, omitiendo por completo las rutinas de validación normales que captura fechas no válidas, por ejemplo, 30 de febrero)
No hay razón para esperar el comportamiento que está viendo, dada la sintaxis de Oracle que publicó.
Esta es una anomalía espuria (¿corrupción de memoria?) o si es repetible, entonces es una falla (error) en el código de Oracle. Si se trata de una falla en el código de Oracle, los sospechosos más probables serían características "nuevas" en una versión sin parches.
(Sé que CAST es una función SQL estándar que existe desde hace años en otras bases de datos. Supongo que soy de la vieja escuela y nunca la introduje en mi repertorio de sintaxis de Oracle. No sé qué versión de Oracle era esa). introdujo el CAST, pero me habría mantenido alejado de él en el primer lanzamiento en el que apareció).
La gran 'bandera roja' (que señaló otro comentarista) es que CAST( datecol AS DATE) .
Esperaría que el optimizador lo tratara como equivalente a date_col... pero la experiencia anterior nos muestra que TO_NUMBER( number_col ) en realidad, el optimizador lo interpreta como TO_NUMBER( TO_CHAR ( number_col ) ) .
Sospecho que algo similar podría estar pasando con ese CAST innecesario.
Según ese registro que mostraste, sospecho que el problema es con valores con un valor "59" para minutos o segundos, y posiblemente un valor "23" para horas, serían los que muestran el error.
Intentaría buscar lugares donde los minutos, horas o segundos se almacenan como 0:
SELECT id, DUMP(activitydate)
FROM newtable
WHERE DUMP(activitydate) LIKE '%,0,%'
OR DUMP(activitydate) LIKE '%,0'
