Хранить можно вместе, влияния на производительность или еще чего не будет - уже с времен DBF все системы хранят BLOB-ы отдельно от данных :)

авторSELECT db_property ( 'BlobArenas' )
Если вернет "ON", то в БД блобы храняться отдельно от страниц таблиц, если "OFF", то вместе.

Я с ASA начал работать начиная с 8-ки и как блобы в более ранних версиях храняться честно говоря не знаю. В 8-ке и 9-ке новая БД всегда создается с BlobArenas=ON. Так что по идее нужно выгрузить базу, создать ее в новой версии ASA и загрузить. Опциями ее никак включить нельзя. Например тоже самое относиться и к CHECKSUM на страницы - возможность появилась в ASA 9.01, но включить ее можно, только перегрузив БД, даже не смотря на то, что БД вроде как создавалась ASA 9.00

авторЕсли я правильно понял, то никого upgrade БД не будет? То есть только выгрузка и загрузка. Не гуманно.
Так никто Вам не навязывает. Не перегружайте БД и работайте, но на уровне физического хранения данных останется старый формат БД. В любой СУБД при смене версии нужно мигрировать БД, особенно если изменился физический формат хранения БД. Ничего страшного честно говоря не вижу, тем более что существуют автоматические визарды/утилиты для перезагрузки баз данных. В том же MSSQL БД с 6.5 на 7.0 так просто не мигрировались (думаю и MSSQL2000->MSSQL2005 не будет исключением).

авторMS SQL на два порядка лучше оттестирован
Тута я не согласен - без 3-его сервис пака лучше MSSQL в кач-ве тиражирумой СУБД не ставить, лучше спать будешь. Тоже самое можно сказать и про ASA - как минимум должна быть первая подверсия, а еще лучше вторую, чтобы тоже спать спокойно. Например 9.00 я гонял для ознакомления и выявления багов (мной было заявлено и в течении пару месяцев исправлено где то 6 багов, из них 2 действительно неприятных). Начиная с 9.01 я поставил сервак на промышленную эксплуатацию и особо не жалуюсь. Так что насчет бесконечных багов не согласен - начиная с 9.01 у меня и клиентов ASA работает как часы, за последние 2 месяца мной и коллегами был обнаружен и заявлен баг в механизме работы с удаленными серверами, думаю со следующим EBF они его уже поправят.

P.S. А вообще то я наоборот считаю, что ежемесячные EBF и открытый интерфейс между разработчиками СУБД и пользователями, где можно заявить о баге или попросить добавить новую возможность, гораздо эффективнее шаманских иногда выходящих сервис паков для MSSQL, где может быть изначально проблем действительно меньше, но те которые есть не решаются годами и никто не смотрит, чего там хотят пользователи, а развитие продукта определяется маркетинговыми политиками из MS. Ну а на личном опыте могу сказать - выход сервис пака похож на молитву - ставишь его и смотришь, помогло или не помогло.

авторДля перевода БД со структыры ASA 6 на структуру 7 можно было воспользоваться утилитой dbupgrade, я ее и имел в виду. А unload-reload - плохо запускать у клиента без своего личного присутствия по многим причинам
1. Долго
2. Требует много места на диске
3. Создается НОВАЯ БД, которую еще надо на старую заменить, а образования не всех клиентов хватает
4. и т. д.
DBUPGRATE меняет только системные обьекты БД (создает новые, правит существующие) и докатывает появившиеся опции. Физическую структуру БД она не трогает. Остальное по пунктам:
1. Честно говоря не верю. LOAD/UNLOAD работает моментально.
2. Согласен, но это разовая операция и думаю у клиентов давно уже не 2-х гиговые винчестеры стоят
3. Для всего этого существуют скриптовые языки ОС, которые позволяют автоматически описать операции:
- забакупить, выгрузить и остановить на сервере существующую БД
- создать новую БД, выполнить скрипт загрузки в нее и остановить на сервере
- скопировать новую БД поверх старой
- запустить новую БД на сервере
Все это реально можно автоматически проделать в том же BAT-файле, так что не вижу необходимости чьего то личного присутствия или достаточной граммотности у клиентов.

авторА баги в ASA бывают очень не приятные. Такое впечатления, что некоторые утилиты или команды просто при тестировании не трогают вообще, они просто падают при первом же обращении. :(
Пожалуйста парочку примеров о каких багах идет речь для ASA начиная с версии 8.02 ? Я например, могу ASA до 9.01 хорошенько вышибить, но все мои приемы на активацию багов будут довольно специфичны, не используются в реальной эксплуатации БД и были обнаружены случайно в процессе копания в ее потрохах. Хотелось бы услышать о реальных проблемах в 8-ке, чтобы потестировать на предмет их наличия в 9-ке, у нас тоже тиражные продукты, которые со следующего года будут очень маштабно распостраняться и подстраховаться на существующем опыте совсем не помешает :)

авторА если сервер на Novell, а если доступа к диску на сервере у клиента нет? Тут без присутствия спеца лучше и не начинать. Данных-то жалко.
С Novell я только в прошлом веке работал, поэтому ничего про него сказать не могу. Однако думаю там тоже должен быть соотвествующий скриптовый язык или модуль, позволяющий автоматизировать процесс работы выгрузки/загрузки.

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

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

автор- Порча баз (Assertion error)
Как я уже раньше писал один раз у меня было на 8-ке, но это случилось "благодаря" железу. Чтобы БД запортилась сама по себе или при неожиданном выключении сервера честно говоря не наблюдал. На 9-ке вообще еще ни разу не удалось грохнуть БД, даже при таких критических ситуациях, как добавление больших массивов записей через LOAD TABLE (который как известно не регистрирует их в логе) и нехватке места на винчестере для БД или же временных таблиц.

автор- отсутствие аналога DBCC
Все что делает DBCC в ASA аналогичным образом дублируется соотвествующими операторами, системными ХП и утилитами.

автор- отсутствие удобного аналога DBSHRINK
Согласен - удобная штука. Хотя в принципе если рассматривать БД, как хранилище данных, в которых наиболее частая операция - это добавление, далее обновление и самая редкая - удаление, то получается, что сжатие БД - операция редкая и применяемая только после удаления большого обьема данных в БД. В других же случаях она абсолютно бесполезная, так как ASA при удалении страниц помечает их как не использованные и далее использует их при вставке новых записей.


Теперь по поводу перегрузки БД. Я не поленился и проделал это сейчас на своей рабочей машине. Что получилось:
Во время перезагрузки я продолжал работать, т.е. у меня крутился еще инстанс рабочей базы ASA, открыт Central, ISQL, PB, в которых я продолжал писать проект, запущен WMP9 и т.д. Неудобств или тормозов в плане работы отмечено не было - не тормозила даже Central (хотя во многом благодаря тому, что под нее выделено 128MB памяти).

Так что насчет долгово процесса - это зря, хотя стоит заметить, что в 9-ке была оптимизированна работа LOAD TABLE, в т.ч. и с блобами. Ну и еще стоит не забывать про оператор REORGANIZE TABLE, который работает очень медленно, но позволяет дефрагметрировать таблицы и индексы в онлайн, не блокируя их на время работы.

Гм, в ASA9 COMMIT для SELECT действительно прекрасно работает. Насчет SHRINK тоже спорить не буду - нет и бог с ней, если бы была, то не отказался бы :) А то говорить о ненужности фичи, это как слушать рассуждения DB2-шников, которые говорят - а на кой нам ХП, ни разу в жизни не пригодились (для тех кто не знает - в DB2 нет языка хранимых процедур) :)

В общем с Вами я тоже во многом согласен, приятно встретить человека, занимающегося эксплуатацией ASA на нормальных промышленных обьемах. Беда только в том, что я знаком с технологиями Sybase (ASA, PD, PB) только год и по настоящему щупал именно их последние детища. Так что конечно же мне сложно оценить кол-во багов/глюков в более младших версиях. Как начнете тестировать 9-ку, будет интересно послушать, где и что сплыло и обьединится для коррекции действий по поводу работы на ASA9, заявления багов в Sybase.com, дописания CODE EXCHANGE, FAQ и т.д. Плюс я все никак не выберу время заполнить и запустить ресурс "Russian Sybase User Group" (RUSUG), движок которого готов и он будет базироваться прямо на SQL.RU и поддерживаться мной, членами RUSUG и Sybase CIS. Там бы тоже можно было выкладывать решения и рекомендации. Так же материал потихоньку у нас по ASA и в FAQ копиться, что совсем неплохо.