Ну в принципе советы действительны для всех СУБД:
1. Впервую очередь скорость работы СУБД зависит от скорости винта. Если на серваке много винтов, то неплохо бы разделить на разные винты сами файлы БД, лог файл и темповые временные файлы.
2. Конечно, чем больше памяти, тем лучше.
3. Необходимо правильно указать размеры минимальной и максимальной планки кэша - чтобы ASA изначально обладала достаточным запасом памяти для старта любого сложного запроса и в то же время не отбирала у ОС и ее сервисов всю память, что приводит к свапу.
4. Граммотно составленные запросы и правильно спроектированные индексы избавляют от Table Scan, что ускоряет работу в сотни раз.
5. Правильная бизнес-логика работы и граммотное использование транзакций уменьшают число и время блокировок, что приводит к снижению времени ожидания между читающими и пишущими сессиями.
6. Чем меньше курсоров, тем лучше. Если логику можно описать запросом, то ее не следует реализовывать курсором.
7. Если в запросе/запросах идет не единичное обращение к вычисляемой на основе некоего сложного запроса информации, то частенько гораздо быстрее оказывается запихнуть ее во временную таблицу и манипулировать уже ей.
8. Вьюверы полезны, но не стоит забывать: во первых не обязательно, что при использовании сложного вьювера в сложном запросе СУБД правильно соединит его в плане запроса и вернет ожидаемые результаты, так как вьювер не таблица или запрос, а фактически просто inline подстановка. Во вторых не обязательно, что СУБД при использовании в сложном запросе сложных вьюверов догадается, как и что правильно соединить и по каким индексам.
9. UDF полезны, но только по прямому назначению - именно как скалярные функции, возвращающие какое то расчитанное значение на основе переданного (например часть даты, наименование месяца, сумма прописью и т.д.). Если функция оперирует внутри себя запросом и участвует в SELECT, то это будет означать фактически использование курсора, то есть на 1000 строк возвращаемых записей еще 1000 раз будет вызвана функция, т.е. будет выполнен 1000 раз запрос внутри нее, причем оптимизатор запроса естественно в этом процесе участвовать не будет, хотя если бы вместо такой функции шло обьединение ее запроса с основным запросом, то оптимизатор запросов смог бы построить нормальный план выполнения, что ускорило работу в 10-100 раз.
10. Триггера должны быть в меру, слишком большое кол-во триггеров, особенно на ROW STATEMENT будет наихудшим образом сказываться на производительности при обьемных операциях изменения информации, причем в этом плане триггера EACH STATEMENT оказываются выгоднее в производительности, так как вызываются только раз перед завершением операции, в то время как ROW STATEMENT вызываются на каждую изменяемую запись в таблице. Простой пример - при удалении 1 000 000 записей соотвествующе EACH STATEMENT будет вызван только один раз, а ROW STATEMENT 1 000 000 раз. С другой стороны, если триггера служат для проверки правильности и целостности информации, то BEFORE ROW STATEMENT оказывается выгоднее тем, что может прервать операцию изменения информации до реальной операции изменения данных в БД и записи в лог файл, в отличие от AFTER EACH STATEMENT, который при генерации ошибки вызовет полный откат транзакции, что при большом обьеме измененных данных займет довольно долгое время.

Ну вот мои 10 заповедей для ASA :) Если что то Вам поможет, буду рад :)

Решил в догонку еще дописать для тех, у кого ASA 8-9:
Пользуйтесь командой ALTER DATABASE CALIBRATE, которая тестирует винчестеры и запоминает характиристики их времени доступа. Это позволяет оптимизатору запроса при вычислении лучшего плана запроса ориентироваться на реальные, а не абстрактные характеристики работы винчестера, что приводит к более правильным планам запросов и более быстрой работе (возможно ускорение многих запросов где то до 30%).