С неделю назад Oracle  под сабжем около полуночи прибил пару своих транзакций за превышение интервала UNDO_RETENTION.
Посмотрели - прослезились: им возраст был насчитан 36 лет, т.е. родились в 1970м году, или 0 по-юниксовому.
За всю ночь транзакций продолжительностью хотя бы порядком близко к UNDO_RETENTION не отмечено (т.е. считается как-то иначе)
Среди багов софтины такое числится, как раз под SUNами разными, но внятного толкования нет, проблема случается совершенно случайно и воспроизвести способа не нашли, потому не пофикшено. 

Думаю ноги у проблемы растут из SUNа, а не из Oracle. В связи с этим - вопрос: а не встречалось кому на жизненном пути такого бага, когда вместо метки времени система выдёт нолик? Я пытался сановский сайт поковырять, но пока неуспешно (недоковырял), мож кто по-простому пальцем ткнёт?

Это сообщение отредактировал(а) 3x3 - 2.10.2006, 23:09

Может оракла был был ка-то не по-человечески собран и просто метка времени не влезла в отведенные размеры?

Oracle не поставляется в исходниках, а производитель худо-бедно тестирует свой продукт. Ни и проблема бы эта случалась бы постоянно..

3x3, Можешь сказать версию оракла и привести пример при каких вызовах появлялись такие транзакции?

Помнится, сидел я как-то 1-го января 1970го за терминалом AT&T Unix и мне как хрясь - метка нолик выдала!

BobiKK, А до этого время называлось "До нашей эры", обозначалось знаком минуса и шёл обратный отсчет...

Oracle - 9.2.0.6
SunOS - 5.9  sun4u sparc SUNW,Sun-Fire

У Oracle на металинке есть пара сообщений про похожие баги:
- 2846827 : Oracle  9.2.0.2 под Solaris Operating System (SPARC 64-bit) v.8, происходит 5-6 раз в месяц
- 4112819 : Oracle  9.2.0.5 под Solaris Operating System (SPARC 64-bit)  v.2.8, непонятно, вроде как всегда происходит




Сама транзакция там без разницы. 

Просто когда какой-то из транзакций требуется память из сегмента отката, а свободных в памяти нет - база смотрит, а нету ли чего, удерживающего ресурс дольше, чем разрешено параметром UNDO_RETENTION (который на порядки дольше тех транзакций, которые имели место быть во время возникновения проблемы) - и если находит такие престарелые блоки, то отнимает их у транзакций-владельцев, а самих бывших владельцев блока пристреливает - что бы те не напакостили в отместку. 

Механизм простановки штампика возраста блока UNDo - он один. И работает обычно без проблем во всех версиях, но вот изредка, по ночам, под Sun - нет-нет да и отчебучит...

На 8*, на Intel Pentium и Атлон не сталкивался ни разу.
Не думаю, что такие функции оракловцы переписывали.
Судя по-всему тут либо:
- какая-то непофикшенная фича в time.h (вряд ли, но не исключено)
- фича в модуле, который вызывает функцию получения метки времени, причем такая, что при получении null, она возвращает ноль (либо как раз сам этот null)
или совсем уж грустно предполагать, что из-за каких-либо реализаций процессора, по каким-то причинам ответ передается не в ту ячейку и по указателю опять же возвращается некорректное значение, которое при использование получения времени преобразуется в null

Добавлено @ 22:02 
С моих знакомых никто не сталкивался с такой вещью((

Это сообщение отредактировал(а) teplik - 3.10.2006, 21:59

    

Вряд ли там уместна аналогия с х86..
В данном окружении 16 процессоров работает и, по потребности, в пиковые нагрузки, тула перекидывают ещё штук 8 из других независимых окружений. На днях на моих "глазах" (по логам), у людей засбоил модуль памяти: пошло писать пару раз в день, что на таком-то проводе был пойман за руку неправильный байт и тут же исправлен - так они просто заоффлайнили несправный блок мозгов, вытащили на ходу из машины и сдали в ремонт. Да, оно реконфигируется и обслуживается на ходу, не приостанавливая работу приложений. Что бы обеспечить бесперебойную работу невзирая ни на что. 

Там нет "фич непофикшенных", речь идет о  проблемах проявляющихся, по видимому, при очень редком стечении самых разных обстоятельств и, возможно, признанных изготовителем и имеющих официальные пути обхода. Oracle, будь его вина и имея шанс исследовать проблему, думается давно бы уже выпустил патч. Или Sun. Но не всегда можно быстро найти источник проблемы, пофиксить или отозвать железо и заменить его на другое. Обычно предлагается решение как обойти проблему на первое время, до выпуска патча, который годами может выпускаться. И эту проблему в принципе можно обойти со стороны Oracle, но уж больно неприличным путём, так что со стороны системы это может всё проще оказаться..

я бы ткнул в memtest какой-нибудь спарковский. (к сожалению нет у меня в памяти оного ПО для соляры... могет имеет смысл спросить сановских технарей, если вы с полным по самые не могу контрактом поддержки) . могет быть память начала потихонечку накрываться.... часто на санях бывают очень эзотерические неполадки, потому как сани иногда бывают с прошлого века, с 3-й четверти.

Короче готовь сани летом...  n - 5-го года

Исключено.
Я выше описал что происходит при проблемах с памятью: железо идентифицирует ошибку четности, свистит админу, тот приходит и вытаскивает блок на ремонт/замену.

а я не про основную память. Сколько десятков лет оборудованию ?
Память тоже знаете ли в разных местах понапихана... в процессоре есть, в каждом счётчике тоже... 
и вообще если в firmware ( или как там BIOS зовётся, не помню ) в каком-то регионе глюк, не факт, что ОСь отследит.
там кстати, IIRC, свой дневничок имеется, его тоже можно посмотреть, но для этого надо машину в downtime.
1. Сани слишком серьёзно к ПО относятся, чтобы наворачиваться программно на таких делах как часы.
2. Если сервер - не единственный ( имеется т.с. high availability/fault tolerance ), то попробуйте просимулировать, и убедитесь, что на другой машине ошибка не выявляется, доказав неисправность не в ПО, а в оборудовании.


Самое главное - пишите на специфическую почтовую рассылку клиентов sun и оракл, по-английски. укажите габариты, вес и цвет. уверен, кто нибудь откликнется. можете перевести сообщение на китайский и отослать также на китайские рассылки, тогда шанс найти ответ увеличивается  ( китайцев, как известно - не мало )

Понятия не имею.


Это аппаратная диагностика, от системы мало что зависит


Ну да.. Да и не факт что в часах дело..



Боюсь, что у них все машины физически живут на одной.. К тому же просимулировать невожно - это относительно редкий баг, случающийся под воздействием непонятно чего.. Вот намедни опять случился.
Косвенно о том, что баг достаточно известен, говорит тот факт, что другие наши заказчики применили против него обход - поставили UNDO_RETENTION в Oracle под сотню лет.. Но это некрасивый вариант.


Не, меня любопытство гнетёт - как такое получается, не более. Выбор платформы и её администрирование - это в общем-то проблема заказчика. Тем не менее - любопытно. Хотя, конечно, не до такой степени, что бы переводить на китайский.. В то же время, идея классная - ведь китайцы могут решить любую проблему просто перебором вариантов 

во-во...
сумлеваюсь что конкретный ответ будет получен здесь. особенно за неимением особой нужды у вопрошающего,  , но я бы первым делом копал под неполадки в оборудовании.