dimitr Dim2000 dimitrТ.е. целостность данных - не задача сервера БД?
При нормальных условиях эксплутации.

Отмазка. "Нормальность" условий определяется применением. Не у всех база лежит на выделенном сервере с UPS. Если бухгалтер с установленным локально ASA жмет reset десять раз на дню, то по твоему это уже экстремальные условия?

Что считать экстремальным? Частые ресеты для ASA не экстремальны и классифицируются как System failure. После такого восстановление происходит автоматически при последующем старте базы. Кстати, делается весьма быстро, если не практиковать очень длинных и объемных пишущих транзакций. В результате Reset теряются только незакоммиченные транзакции. По личному большому опыту могу сказать, что у ASA устойчивость к Reset очень хорошая, даже если ресет происходит в момент чекпоинта, т.е.непосредственного сброса данных из лога в базу. Технология чекпоинта достаточно понятно "на пальцах" расписана в документации в разделе
и там я не нашел слабых мест, чувствительных к ресету в плане потери базой целостности.Технология, наверное, похожа на используемую в NTFS.
Про периоды между чекпоинтами вообще молчу, ибо в это время файл бд не изменяется, а transaction log просто дописывается в конец.
dimitr
База имеет право портиться при аппаратном сбое или вследствии багов в ядре ОС.

Именно так. Если сервер честно записал данные на диск, а диск осыпался, тот тут никто не поможет, кроме backup.

dimitr
Dim2000После "гашения извратом" тебе уже никто ничего не должен . Да и невозможно это...
Это твоя точка зрения.
К тому же неверная.

michael_
ASCRUS
2. Версия ASA

Например, 7.0.1.918. Могу привести билды и для 6 и для 8, но это не важно.

ВАЖНО! 7.0.1 - сырая версия. Пригодна для разработки, но не для боевых баз.
Не знаю, портила ли она базы, ибо я не смертник, но ошибок было достаточно. Я ее воткнул кажется только когда вышла 7.0.3. А шестерку вообще с 6.0.4, ибо там было слишком много нововведений и переделок по сравнению с 5.5

Известная особенность ASA. Можно считать минусом.
michael_
Везде тоже самое. Только не надо предлагать поставить последний билд 7-ки или 8-ки, пробовали и откатились :)

Сочувствую вашим клиентам.

michael_
Dim2000
Нет. БД не нужно ремонтировать, для этого есть backup.

Дело в том, что портятся в ASA несколько страниц, и сразу возникшей проблемы не видно,проблема возникает только при попытке прочитать из них данные.

Естественно! Как ты обнаружишь сбойный кластер на диске, если не попытаешься его прочитать?
michael_
И хорошо, если на страницах был только индекс! И следовательно, восстаналивать придется данные интеллектуально, а не восстановлением последней копии.

Инкрементальный бэкап спасает в такой ситуации на 100%. Если есть исходный корректный полный бэкап и последующие отрезки логов, то физическая порча данных в файле БД не страшна - накатом получишь корректную базу на последний момент.
michael_
И VALIDATE тоже не всегда обнаруживает такие сбойные места, а значит и validate перед резервной копией не всегда спасает.

А ключик -f использовался? Если нет, тогда действительно может не обнаружить.
С -fd делается полная проверка чтения данных, -fi - индексов, -f - всего.
Без этого делается только поверхностная экспресс-проверка

dimitr Александр ГoлдунЧастые ресеты для ASA не экстремальны и классифицируются как System failure. После такого восстановление происходит автоматически при последующем старте базы. Кстати, делается весьма быстро, если не практиковать очень длинных и объемных пишущих транзакций. В результате Reset теряются только незакоммиченные транзакции.

Правильно говоришь, так оно и должно быть. Просто тут упоминались факты, когда это не так. И я твердо считаю это проблемой сервера, хотя меня пытаются убедить в обратном ;-)
Однозначно, целостность данных - забота сервера всегда, когда это возможно. Попадание 120 милиметрового снаряда в сервер ((с) Oleg Loa кажется) снимает ответственность с сервера. Как и любая независящая от сервера порча.

А факт в примерах я встретил только один - использование сырой версии ASA 7.0.1. Ты как-то писал про конфлик интересов юзеров, не желающих тестить бета версии, и производителей, нуждающихся в массовом тестирвании. Так вот у Sybase этот конфликт весьма рельефно проявляется в виде сырых релизов N.0.0-N.0.2. Не исключено, правда, что и у других производителей похожая картина. Не знаю, утверждать не берусь.

Еще факт, точнее предположение из приведенных примеров - это использование ASA на рабочей станции, возможно под Win 9x на FAT. Само по себе для ASA это не страшно, но в такой ситуации есть соблазн использовать ключик -u - это использвание системного кэша в дополнение к кэшу БД, чтоб бухгалтеру на лайнсы с одинэсами больше осталось ;))) Это похоже на отключение Forced writes в IB. Чем это чревато при ресетах - сам знаешь.

michael_
Страницы локализуются. Если испорчен индекс, то я его вего лишь перестраиваю. Если испорчены данные, то я могу их взять из бекапа.

Испорчен файл - беру бэкап. Зачем заморачиваться?
Читайте доки. Порча файла классифицируется как Media Failure. В отличие от System Failure не подразумевает автоматической починки. Технология подьема описана в доках Recovering from media failure on the database file

michael_
Главное, что я перестаю падать на запросах вида SELECT * FROM T, при этом роняя сервер и все базы на нем.

На сырых версиях можно было и при нормальных базах запросом ронять сервер.
Примеры не спрашивай, но они есть. Если нужно - можно покопаться в sybase.public.sqlanywhere.general. Мне лень.

michael_2 ASCRUS и Александр Голдун

Исходя из вышесказанного предлагаю обратиться в Sybase с предложением убрать функции ремонта из Sybase ASE. :)
Ни к чему они, бекап есть. Оставить только функции проверки.
Вперед:
news://forums.sybase.com/sybase.public.ase.general

michael_
Ну и что в этом хорошего, что запрос на выборку роняет сервер?!


Ничего. А что хорошего в продолжении работы сервера при обнаружении весьма критической проблемы?
Только что проверил - запортил вручную db-файл в нескольких местах. Запустил сервер. Запустил dbvalid -f.
Остановилась проверка:
validating имя таблицы
internal database error и т.п.

Сервер при этом НЕ УПАЛ, а обрубил все коннекты и при попытке нового коннекта ругается с тем же сообщением Internal database error.
Это разве некорректное поведение? Если что-то привело к физической порче данных, то может быть продолжение обычной работы сервера опасно для тех данных которые еще целы?

michael_
Я тоже такие запросы знаю. :)


Не будешь ли ты так любезен привести запрос, который роняет ASA 8.0.3.5122?

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

michael_
Потому что, у пользователя не всегда есть резервная копия. :(


Значит это должно быть жирным шрифтом оговорено в документации. Игнорируют - сами виноваты, будут раскошеливаться на ремонт.

Поинтересуйся в англоязычных форумах, не исключено все же, что специализированные средства существуют, возможно третьих фирм. И изучи следующий документ:
http://www.ianywhere.com/developer/technotes/assertion.html

P.S. А еще кроме сыплющихся винтов бывает глючная безродная память.

В догонку ссылки по теме:
Correcting A Database With a Corrupt Table

What Backup, Recovery, and Disaster Recovery Mean to Your Adaptive Server Anywhere Databases

michael_
Вчера опять клиент порченную базу приволок :(

michael_
ASCRUS
2. Версия ASA

Например, 7.0.1.918. Могу привести билды и для 6 и для 8, но это не важно. Везде тоже самое. Только не надо предлагать поставить последний билд 7-ки или 8-ки, пробовали и откатились :)


И еще раз про "неважно"! Навскидку нашел по словам corrupt anywhere на sybase.com:
www.sybase.com/detail?id=1026907
http://www.sybase.com/detail?id=1026907
ASA Update Problem on a Database with Page Size Exceeding 4K
....
Description
On Adaptive Server Anywhere (ASA) 7.x, 8.x, or 9.x servers with a database page size larger than 4K, you may encounter a problem if you attempt to update a row containing Binary Large Objects (BLOBs), and the new row size exceeds 4K.

The update fails and you may see the following problems:

* Server failure; or
* table corruption resulting in missing rows .
........
Solution from Sybase
The problem has been resolved in the following versions:

* SQL Anywhere Studio Version 7.0.4 Build #3431 or later
* SQL Anywhere Studio Version 8.0.2 Build #4319 or later
* SQL Anywhere Studio Version 9.0.0 Build #1218 or later

You can download EBFs from http://downloads.sybase.com.

7.0.1.918 < 7.0.4.3431

Может это оно было?

К вопросу о пользе свежих EBF... Хотя, задолбался я это уже кучу раз повторять. Ваши клиенты (именно ваши, а не Sybase) - ваши проблемы. Мне за это не платят.