Оптимизация OLTP приложений.

Помогите найти статью о сабже! А то приложение начинает задыхаться, таблица порядка 5 млн записей, частая выборка, иногда запускается запрос на удаление старых записей и все подвисает на несколько минут. Интересует статья, в которой написано как определять узкие места в системе и как оптимизировать OLTP приложение. Спасибо!

Ну так первым делом найди узкое место. Что это - плохой план выполнения запросов, слишком большие объемы выборок, сколько записей за раз удаляется. Или может аппаратные ограничения (например, дисковой подсистемы).

Такая статья многим бы не помешала :)
Если в кратце, то - запускаем Profiler, Performance Monitor и пишем их результаты в файл и/или таблицу, например, целый день. Попутно хорошо бы фиксировать в какие моменты происходили особые тормоза, когда они снимались и т.д. А дальше сначала смотрим результаты Performance Monitor. В рассылке недавно серия статей была по анализу счетчиков. Но если упрощенно, то смотрим, что у нас является узким местов - диски, процессоры или память. Если диски, то начинаем в Profiler отбирать запросы, у которых количество Reads и Writes больше какого-то порога. Если процессоры - то отбираем по CPU. Обычно становятся видны целые группы запросов, над которыми надо думать и оптимизировать - тут уж Вам флаг в руки, т.к. надо видеть запросы, знать специфику приложения, т.к. иногда приходится менять архитектуру приложения, а не просто переписывать один запрос. А потом все по новой - пишем Profiler, Performance Monitor и снова анализируем.

Похоже подвисает, когда удаляется или изменяется много ключевых записей. Это можно как-то оптимизировать?

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

Ладно, буду мучить мозг! :)
Спасибо!