AKTUALIZACJA:
Nie znajduję żadnych opublikowanych odniesień do tego konkretnego typu uszkodzenia DATE na stronie pomocy technicznej Oracle. (Może tam być, moje szybkie wyszukiwania po prostu tego nie podniosły).
- Niepoprawny skrypt sprawdzający bazę danych pod kątem uszkodzonych dat [ID 95402.1]
- Błąd 2790435 – Serial INSERT z równoległym SELECT i konwersją typu może wstawić uszkodzone dane [ID 2790435.8]
Dane wyjściowe funkcji DUMP() pokazują, że wartość daty jest rzeczywiście nieprawidłowa:
Typ=12 Len=7: 120,110,11,18,13,0,16
Spodziewamy się, że bajt minut powinien mieć wartość od jednego do sześćdziesięciu, a nie zero.
7 bajtów wartości DATE reprezentuje kolejno wiek (+100), rok (+100), miesiąc, dzień, godzinę (+1), minuty (+1), sekundy (+1).
Jedyny raz, kiedy widziałem nieprawidłowe wartości DATE, takie jak ta, gdy wartość DATE była dostarczana jako zmienna wiązania, z programu Pro*C (gdzie wartość wiązania jest dostarczana w wewnętrznej 7-bajtowej reprezentacji, całkowicie z pominięciem normalnych procedur sprawdzania poprawności, które złap nieprawidłowe daty, np. 30 lutego)
Nie ma powodu, aby oczekiwać zachowania, które widzisz, biorąc pod uwagę składnię Oracle, którą opublikowałeś.
Jest to albo fałszywa anomalia (uszkodzenie pamięci?), albo jeśli jest to powtarzalne, to jest to wada (błąd) w kodzie Oracle. Jeśli jest to usterka w kodzie Oracle, najbardziej prawdopodobnymi podejrzeniami będą „nowe” funkcje w niezałatanej wersji.
(Wiem, że CAST jest standardową funkcją SQL, która była od wieków w innych bazach danych. Myślę, że jestem oldschoolowy i nigdy nie wprowadziłem jej do mojego repertuaru składni Oracle. Nie wiem, jaka to była wersja Oracle wprowadził CAST, ale trzymałbym się od niego z daleka w pierwszym wydaniu, w którym się pojawił.)
Dużą „czerwoną flagą” (którą zauważył inny komentator) jest to, że CAST( datecol AS DATE) .
Można by oczekiwać, że optymalizator potraktuje to jako równoważne z date_col ... ale doświadczenia z przeszłości pokazują, że TO_NUMBER( number_col ) jest faktycznie interpretowany przez optymalizator jako TO_NUMBER( TO_CHAR ( number_col ) ) .
Podejrzewam, że coś podobnego może się dziać z tym niepotrzebnym CAST.
Na podstawie tego jednego rekordu, który pokazałeś, podejrzewam, że problem dotyczy wartości z wartością „59” dla minut lub sekund i prawdopodobnie wartością „23” dla godzin, które pokazują błąd.
Spróbowałbym sprawdzić miejsca, w których minuty, godziny lub sekundy są przechowywane jako 0:
SELECT id, DUMP(activitydate)
FROM newtable
WHERE DUMP(activitydate) LIKE '%,0,%'
OR DUMP(activitydate) LIKE '%,0'
