АКТУАЛИЗАЦИЯ:
Не намирам никакви публикувани препратки към този специфичен тип повреда на DATE на сайта за поддръжка на Oracle. (Може да е там, бързите ми търсения просто не го откриха.)
- Скрипт с лоши данни за проверка на базата данни за повредени дати [ID 95402.1]
- Програмна грешка 2790435 – Серийният INSERT с паралелен SELECT и преобразуване на типа може да вмъкне повредени данни [ID 2790435.8]
Резултатът от функцията DUMP() показва, че стойността на датата наистина е невалидна:
Typ=12 Len=7: 120,110,11,18,13,0,16
Очакваме байтовете за минути да са със стойност между едно и шестдесет, а не нула.
7-те байта от стойността на ДАТА представляват по ред век (+100), година (+100), месец, ден, час (+1), минути (+1), секунди (+1).
Единственият път, когато съм виждал невалидни стойности на ДАТА като тази, когато стойността на ДАТА се доставя като свързваща променлива от програма Pro*C (където свързващата стойност се доставя във вътрешното 7-байтово представяне, напълно заобикаляйки нормалните процедури за валидиране, които улавяне на невалидни дати, напр. 30 февруари)
Няма причина да очаквате поведението, което виждате, предвид синтаксиса на Oracle, който сте публикували.
Това е или фалшива аномалия (повреда на паметта?), или ако това е повторяемо, тогава е недостатък (бъг) в кода на Oracle. Ако това е пропуск в кода на Oracle, най-вероятните заподозрени биха били „нови“ функции в версия без корекция.
(Знам, че CAST е стандартна SQL функция, която съществува от векове в други бази данни. Предполагам, че съм от старата школа и никога не съм я въвеждал в репертоара си за синтаксис на Oracle. Не знам коя версия на Oracle беше тази въведе CAST, но щях да стоя настрана от него в първото издание, в което се появи.)
Голямото „червено знаме“ (което отбеляза друг коментатор) е, че CAST( datecol AS DATE) .
Бихте очаквали оптимизаторът да третира това като еквивалент на date_col ... но миналият опит ни показва, че TO_NUMBER( number_col ) всъщност се интерпретира от оптимизатора като TO_NUMBER( TO_CHAR ( number_col ) ) .
Подозирам, че нещо подобно може да се случи с този ненужен CAST.
Въз основа на този един запис, който показахте, подозирам, че проблемът е със стойности със стойност „59“ за минути или секунди и вероятно стойност „23“ за часове, които ще показват грешката.
Бих се опитал да проверя за места, където минутите, часът или секундите се съхраняват като 0:
SELECT id, DUMP(activitydate)
FROM newtable
WHERE DUMP(activitydate) LIKE '%,0,%'
OR DUMP(activitydate) LIKE '%,0'
