ОБНОВЛЕНИЕ:
Я не нашел опубликованной ссылки на этот конкретный тип повреждения DATE на сайте поддержки Oracle.(Возможно, мои быстрые поиски просто не включили его.)
- Скрипт Baddate для проверки базы данных на наличие поврежденных дат [ID 95402.1]
- Ошибка 2790435 - Serial INSERTпри параллельном SELECT и преобразовании типов можно вставлять поврежденные данные [ID 2790435.8]
Вывод функции DUMP () показывает, что значение даты действительно недопустимо:
Typ=12 Len=7: 120,110,11,18,13,0,16
Мы ожидаем, что байт минут должен быть значением от одного до шестидесяти, а не ноль.
7 байтов значения DATE представляют, в порядке, век (+100), год (+100),месяц, день, час (+1), минуты (+1), секунды (+1).
Единственный раз, когда я видел недопустимые значения DATE, подобные этому, когда значение DATE предоставлялось как переменная связыванияиз программы Pro * C (где значение связывания предоставляется во внутреннем 7-байтовом представлении, полностью обходя обычные процедуры проверки, которые перехватывают недопустимые даты, например, 30 февраля)
Нет причин ожидать, что вывидишь, учитывая оракулсинтаксис, который вы опубликовали.
Это либо ложная аномалия (повреждение памяти?), либо, если это повторяется, то это ошибка (ошибка) в коде 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'