Aleksey Kh.
Если память нарастить, то можно было бы увеличить размер страницы БД. Плюс можно поиграться с опцией -cw, исключив попадание кэша в свап. Так же можно попробовать калибровать ASA к текущим накопителям оператором ALTER DATABASE CALIBRATE, это позволит оптимизатору строить планы запросов с учетом реальной работы винтов, а не прикидывать по среднестатистическим значениям. Так же при наличие граммотно спроектированных кластерных индексов ASA будет вести упорядоченное чтение данных из таблиц, что опять же повысит скорость. Где кстати ASA хранит свои временные файлы, тоже немаловажный вопрос. Так же не указали, сколько пользователей работает с сервером и какая селективность выбираемых данных.

Дополнительно: на ASA 9.00 на Athlon 1500XP с гигом памяти у меня вполне успешно крутилась БД размером 15гб, сейчас в ASA 9.01 добавили поддержку параллейного чтения на RAID и новые алгоритмы оптимизации запросов, сложные запросы, которые раньше быстрее выполнялись раскидкой через времянки, теперь нормально прокручиваются оптимизатором запросами с подзапросами.

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

Ну про кривизну БД молчу - если она присутствует, то не помогут никакие рекомендации.

авторОптимизацию запросов не рассматриваем :)
А вот это Вы зря. Оптимизацией запросов можно добиться очень существенного увеличения скорости работы, тем более что в ASA профайлер ХП и графический план запросов в ISQL позволяет моментально вычислять критические запросы, при условии конечно, что у Вас логика разложена по ХП и триггерам, а не раскидана в виде запросов по клиентской части и нет множества вложений представлений друг в друга или необоснованного использования ни к месту UDF. На той 15 гиговой БД реально я за неделю с помощью профайлера вычислил и оптимизировал все самые узкие и кривые места, переписав где необходимо соединения и переделав индексную структуру. Запросы, которые работали от 40 минут и обьединяли в себе кучу таблиц с обьемом от 500 000 до 20 000 000 записей, после оптимизации у меня отрабатывали 15-60 секунд, в зависимости от селективности запроса (в среднем запросы возвращали от 20 000 до 300 000 записей). Оно и понятно, на неоптимизированных запросах был table scan, частенько с looper join, да еще целой кучи обьемных таблиц, тут сплошная работа винта, особенно когда памяти под построение хэш-карт не хватает и приходиться их порциями обрабатывать. На оптимизированных же запросах было уже красивое соединение по индексам и внутренним JOIN-ам, с построением хэш-карт по аггрегированным группам, что позволяло ASA моментально проводить выборки.

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

P.S. Советы из личного опыта, но не обязательно помогут, в БД каждая задача индивидуальна и требует своего творческого подхода и решения в зависимости от очень многих условий. Однако лично мое мнение, что самое главное это изначальная правильная проектировка БД и граммотное программирование логики ее работы, а потом уже ее администрирование и само железо.

авторЭтот оператор работает только в последних версиях, видимо (может быть, даже начиная с 9?). То же самое касается и остального - все зависит от версии АСА, хотя общие принципы одинаковы вообще для всех СУБД.
ALTER DATABASE CALIBRATE работает с ASA 8.0, у автора стоит 8.02 . Так что про версии я не забываю, а отличия 9 и 9.01 от 8-ки в посте я выделял отдельно, показывая какие преимущества мог бы получить автор, перейдя на 9-ую версию.

авторИнтересно, влияет ли на проихводительность сервера БД тип файловой системы? Если брать W2K, то что лучше ставить - FAT32 или NTFS?
Конечно же обязательно нужно ставить NTFS, так как это журналируемая файловая система, гарантирующая высокую надежность работы в отличие от FAT32.

авторНу вот, начались разброд и шатания... И кому верить? Один говорит - ставь NTFS, другой - вообще FAT16. Вы бы договорились между собой :)
Ну так Вам и посоветовали - ставить БД на NTFS и свап вынести на отдельный FAT диск :) Кстати если на ОС NT (2000, XP, 2003) памяти достаточно, то для ASA 9 я рекомендую включить AWE в Windows и указывать ASA размещение кэшей в AWE - это гарантирует работу кэшей без их попадания в свап, что тоже повысит скорость работы.