2 Александр
В более поздних версиях это тоже бывает. Не видел пока только на 9-ке (пока :) ).

2 Автор.

Да, полный бекап "наследует эту ошибку".

Лечение - найти полный бекап неповрежденный и накатить на него все транзакции.

Если инкрементного бекапа нет, то выгрузить данные (dbunload), создать новую базу и закачать туда данные (reload).
Если это не помогает, сыпется на какой-то таблице при выгрузке, то существуют варианты применимые по месту. Например при выгрузке отсортировать по другому индексу или вообще индексы убить и т. п. Иногда и одной таблицей приходиться жертвовать.

Профилактика - перейти на ASA9 и делать регулярно полный VALIDATE.

Удачи!

Ой! Я наверное, не прав. Я описал проблему с физическими повреждениями БД.

У Вас же "Unexpected error occurred while fetching from a temporary table". Я с таким не сталкивался. Тут надо или версию другую ASA поставить или с памятью поиграть, например с размером кеша. Или еще раз на запрос посмотреть. Некоторые запросы на 7-ке могли приводить к падению сервера.

Чайник в SybaseБыл всегда 512 Mb, недавно 768Mb сделал, сейчас обратно вернул.
Всего на сервере - 1GB памяти.

А почему 768 :) 512+256? 512 вполне хватит. Тем более, что ASA сам его переразмеряет. Кстати на 9-ке делает он это намного быстрее.

Александр Гoлдун Надо поднять до 7.0.4 и накатить последний EBF.


Если ситема позволяет, то так и надо сделать. Но не факт, что поможет.

Но, система у автора не своя, а от стороннего разработчика. А разработчик не всегда может поддерживать несколько релизов одной версии. :(

И делается это именно из-за ошибок создателей СУБД. Далеко не всегда последний релиз лучше предпоследнего. А проводить полноценное функциональное и нагрузочное тестирование тиражного продукта на каждом EBF нереально. По своему опыту знаем. Иногда, легче знать и обходить известные ошибки, чем наслаждаться новыми.

Александр Гoлдун
Если система несовместима с более поздними подверсиями ТОЙ ЖЕ ВЕРСИИ, то виноваты сами разработчики.
Виноваты в том, что закладывались на ошибки и недокументированное поведение. А еще виноват тот, что решился поставить на боевой сервер сырую бета-версию.


А кто может утверждать, что продукт перестал быть сырым? Вы? Кто-то из Sybase? Продавали его не как сырой. Это не бета-версия! Это коммерческий продукт. И правило 3-го релиза не всегда работает. Вспомним 6:
6.0.0 - ничего сказать не могу, не юзал
6.0.1 - неплохо, но есть проблемы с внешними объединениями
6.0.2 - кошмар! медленно, куча ошибок, уж и не упомню каких, сразу отказались
6.0.3 - неплохо, но проблемы с русским языком при работе через BDE
6.0.4 - вроде ничего, но вышла поздно, чуть ли не после 7-ки и пришлось долгое время работать на 6.0.3 тщательно обходя ошибки разработчика
И это 6-ка - одна из очень неплохих версий

Разработчики не ограничивают пользователя одним релизом прямо, они ОФИЦИАЛЬНО ТЕСТИРУЮТ под 1 релиз, наиболее им симпатичный.

Представте что такое тестирование:
1 Функционально тестирование (пройти ВСЕ режимы при разных данных и настройках)
2 Нагрузочное тестирование
3 Пункты 1 и 2 повторить на ВСЕХ серверных платформах (у нас это Win NT 4, 2000 prof, 2000 server, 2003 server, XP и как ни странно 98, плюс Novell Netware 4/5/6 + Linux SuSE и ASP)
4 Пункты 1 и 2 повторить на ВСЕХ клиентских платформах (у нас это Win NT 4, 2000 prof, 2000 server, 2003 server, XP,98, Me)

Александр Гoлдун
Вообще, иногда складывается ощущение, что люди никогда не работали с данными, которые имеют стоимость. Причем иногда эта стоимость соспоставима со стоимостью бизнеса, использующего эту БД

Все разработчику СУБД заплачено и где результат? Хоть раз они ответили рублем за порченную базу? А мы несли убытки за их ошибки! Вопрос к разработчику СУБД.

Александр Гoлдун
Это верно для ранних релизов. В ASA 9.0.1, к примеру, внесли ошибку в LIKE, которой не было в 9.0.0. Но это не значит, что лучше ставить 9.0.0
Это значит только, что нельзя ставить ни 9.0.0, ни 9.0.1. Можно использовать только для разработки. Вот 9.0.2.последний билд, пожалуй уже после некоторого тестирования можно уже запускать. А вот после 9.0.3 пожалуй можно будет уже не глядя ставить.


Откуда у Вас такое мнение? А Вас связи в департаменте разработок iAnуwhere?
Кто сказал, что 3-й релиз будет конфекткой? Я приводил пример с 6-кой. Мы переводим на 9-ку своих клиентов как раз из-за ошибок, так что рано что ли?

По поводу установки нового EBF всем пользователям - Вы представляете весь геморой, когда их тысячи? Когда они по всей матушке России и за бугром работают. Мы на это идем только когда ошибка ВОЗНИКАЛА при работе с нашим приложением и она РЕАЛЬНО исправлена. А Assertion Failed с физическим повреждение базы РЕАЛЬНО не был исправлен ни в одной из версий 6, 7 и 8. Такая информация у меня от Sybase CIS. Их рекомендация - переход на 9-ку с установкой контрольной суммы на страницу.

Александр Гoлдун
Бывает хуже. Бывает и 7.0.0 ставят на рабочие сервера. А потом рассказывают байки про ненадежный ASA.

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

Чайник в Sybaseнаверное...
Вы мне еще скажите - вот у нас база 12Gb, интенсивное использование.
ОЗУ 1Gb -> проапгрейдим до 2GB.
Имеет ли смысл поставить кеш при этом 1Gb?
Будет ли это безопасно?

(версия будет уже 7.0.4.3538)

Теоритически - да. Практически - надо тестировать.

Все-таки база в 12 Гб не часто при пользовании ASA встречается, по крайней мере на 7-ке. У наших клиентов наблюдался всплекс проблем при разрастании базы до размеров нескольких Гб. Многие решались, какие-то оставались. Такой объем заставил их серьезнее относится к резервному копированию и проверке физической целостности базы. Иногда возникали проблемы в связке ОС-СУБД, что-то решается простой перезагрузкой сервера (например, раз в неделю).