PEMBARUAN:
Saya tidak menemukan referensi yang dipublikasikan untuk jenis korupsi DATE khusus ini di situs dukungan Oracle. (Mungkin ada, pencarian cepat saya tidak berhasil.)
- Script Baddate Untuk Memeriksa Database Untuk Tanggal Rusak [ID 95402.1]
- Bug 2790435 - INSERT Serial dengan SELECT paralel dan konversi jenis dapat menyisipkan data yang rusak [ID 2790435.8]
Output dari fungsi DUMP() menunjukkan nilai tanggal memang tidak valid:
Typ=12 Len=7: 120,110,11,18,13,0,16
Kami berharap byte menit harus berupa nilai antara satu dan enam puluh, bukan nol.
7 byte nilai DATE mewakili, secara berurutan, abad(+100), tahun(+100), bulan, hari, jam(+1), menit(+1), detik(+1).
Satu-satunya saat saya melihat nilai DATE yang tidak valid seperti ini ketika nilai DATE diberikan sebagai variabel bind, dari program Pro*C (di mana nilai bind diberikan dalam representasi 7 byte internal, sepenuhnya melewati rutinitas validasi normal yang tangkap tanggal yang tidak valid, mis. 30 Feb)
Tidak ada alasan untuk mengharapkan perilaku yang Anda lihat, mengingat sintaks Oracle yang Anda posting.
Ini adalah anomali palsu (korupsi memori?) Atau jika ini berulang, maka itu adalah cacat (bug) dalam kode Oracle. Jika itu adalah kesalahan dalam kode Oracle, kemungkinan besar tersangka adalah fitur "baru" dalam rilis yang belum ditambal.
(Saya tahu CAST adalah fungsi SQL standar yang telah ada selama berabad-abad di database lain. Saya kira saya sekolah lama, dan belum pernah memperkenalkannya ke dalam repertoar sintaks Oracle saya. Saya tidak tahu versi Oracle apa itu memperkenalkan CAST, tapi saya akan menjauh darinya di rilis pertama yang muncul.)
'Bendera merah' besar (yang dicatat oleh komentator lain) adalah CAST( datecol AS DATE) .
Anda akan mengharapkan pengoptimal memperlakukannya sebagai setara dengan date_col ... tetapi pengalaman sebelumnya menunjukkan kepada kita bahwa TO_NUMBER( number_col ) sebenarnya ditafsirkan oleh pengoptimal sebagai TO_NUMBER( TO_CHAR ( number_col ) ) .
Saya menduga sesuatu yang serupa mungkin terjadi dengan CAST yang tidak dibutuhkan itu.
Berdasarkan satu catatan yang Anda tunjukkan, saya menduga masalahnya ada pada nilai dengan nilai "59" untuk menit atau detik, dan mungkin nilai "23" untuk jam, yang akan menunjukkan kesalahan.
Saya akan mencoba memeriksa tempat di mana menit, jam, atau detik disimpan sebagai 0:
SELECT id, DUMP(activitydate)
FROM newtable
WHERE DUMP(activitydate) LIKE '%,0,%'
OR DUMP(activitydate) LIKE '%,0'
