OPDATERING:
Jeg kan ikke finde nogen publiceret reference til denne specifikke type DATE-korruption på Oracles supportwebsted. (Det kan være der, mine hurtige søgninger viste det bare ikke.)
- Baddate-script til at kontrollere databasen for korrupte datoer [ID 95402.1]
- Bug 2790435 - Seriel INSERT med parallel SELECT og typekonvertering kan indsætte korrupte data [ID 2790435.8]
Outputtet fra funktionen DUMP() viser, at datoværdien faktisk er ugyldig:
Typ=12 Len=7: 120,110,11,18,13,0,16
Vi forventer, at minutbyten skal være en værdi mellem en og tres, ikke nul.
De 7 bytes af en DATO-værdi repræsenterer i rækkefølge århundrede(+100), år(+100), måned, dag, time(+1), minutter(+1), sekunder(+1).
Den eneste gang, jeg har set ugyldige DATE-værdier som denne, når en DATE-værdi blev leveret som en bindingsvariabel, fra et Pro*C-program (hvor bindingsværdien leveres i den interne 7 byte-repræsentation, helt uden om de normale valideringsrutiner, der fange ugyldige datoer, f.eks. 30. februar)
Der er ingen grund til at forvente den adfærd, du ser, i betragtning af den Oracle-syntaks, du har sendt.
Dette er enten en falsk anomali (hukommelseskorruption?), eller hvis dette kan gentages, så er det en fejl (fejl) i Oracle-koden. Hvis det er en fejl i Oracle-koden, vil de mest sandsynlige mistænkte være "nye" funktioner i en ikke-patchet udgivelse.
(Jeg ved, at CAST er en standard SQL-funktion, der har eksisteret i evigheder i andre databaser. Jeg tror, jeg er gammeldags, og jeg har aldrig introduceret det i mit Oracle-syntaksrepertoire. Jeg ved ikke, hvilken version af Oracle det var, der introducerede CAST, men jeg ville have holdt mig væk fra den i den første udgivelse, den dukkede op i.)
Det store "røde flag" (som en anden kommentator bemærkede) er, at CAST( datecol AS DATE) .
Du ville forvente, at optimeringsværktøjet behandler det som svarende til date_col ... men tidligere erfaringer viser os, at TO_NUMBER( number_col ) tolkes faktisk af optimeringsværktøjet som TO_NUMBER( TO_CHAR ( number_col ) ) .
Jeg formoder, at noget lignende kan være i gang med den unødvendige CAST.
Baseret på den ene registrering, du viste, formoder jeg, at problemet er med værdier med en "59"-værdi i minutter eller sekunder, og muligvis en "23"-værdi for timer, ville være dem, der viser fejlen.
Jeg ville prøve at se efter steder, hvor minutter, time eller sekunder er gemt som 0:
SELECT id, DUMP(activitydate)
FROM newtable
WHERE DUMP(activitydate) LIKE '%,0,%'
OR DUMP(activitydate) LIKE '%,0'