База данных Oracle допускает недопустимую часть времени значений столбца datetime при каких обстоятельствах?

Question

Этот случай возникает в реальной ситуации, когда недействительные данные находились (и продолжают поступать) в базу данных Oracle, которая извлекается в систему обработки данных в Focus. Фокус задохнется и умрет на некоторых строках с недопустимыми порциями времени. Затем администратор базы данных Oracle скопирует дату и время в соответствующий столбец из подходящего столбца, чтобы процесс мог продолжаться (да, я знаю).

Я помог устранить проблему и обнаружил, что в Oracle в уязвимой строке:

DUMP(START_TIME)

дает:

'Typ=12 Len=7: 100,99,255,255,0,0,0'

В то время как:

TO_CHAR(START_TIME, 'YYYY/MM/DD HH24:MI:SS')

дает:

ORA-01801: date format is too long for internal buffer

Глядя на результаты DUMP(), 'Typ=12 Len=7: 100,99,255,255,0,0,0' и соглашения о хранении , выясняется, что они могут обойти семантические ограничения столбца и вставить эквивалент 0, -1, -1 , -1, -1, -1, -1 или 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

Что имеет «смысл», поскольку 0xFF = 255 = -1 может потенциально привести к 0000/255/255 255:255:255 в зависимости от того, как вы интерпретируете байты, знаки и переполнения.

При каких условиях (механизм подключения и т. Д.) Oracle допускает попадание недопустимых данных в столбцы даты и времени?

Answer 1

Oracle вообще не позволяет этого. Уровень OCI может обойти проверку типа данных - Oracle в основном полагает, что то, что вы поместили в эти семь байтов, составляет правильную дату. Аналогично, на уровне OCI Oracle может передавать обратно семь байтов «даты», и клиентское программное обеспечение может делать с этими байтами все, что пожелает (оставить их как есть, преобразовать в строку или число эпох ... ) Возможно, лучшим подходом будет выяснить, что загружает туда данные, и посмотреть, что это делает с датами.

Если вы чувствуете себя чрезвычайно извращенным, вы можете использовать недокументированную функцию REVERSE для даты и сделать ее недействительной.

Answer 2

Кажется, я не могу найти ошибку в быстром поиске в Metalink (если вы еще не открыли SR с Oracle, я бы предложил это сделать), но я знаю, что были ошибки в слое OCI (Oracle Call Interface ) который позволял глючному коду вставлять недопустимые даты. По большей части эти ошибки были исправлены в течение некоторого времени, поэтому я бы поспорил, что если вы примените последний набор патчей к клиентским машинам, которые выполняют вставки, проблема исчезнет.