qizer,

В общем виде _в_такой_ постановке задача не решается.

Как Константин подсказал, можно посмотреть в сторону Workload Managementa, но его эффективность - вопрос. Никакой раздачей приоритетов не справиться с кардинально неэффективным запросом (запросами) или серьёзной нагрузкой, существенно отличающейся от назначения сервера. Помогут только ограничителные меры, а они, в свою очередь, уже требуют долгой вдумчивой настройки.

"В лоб" - завести сервисный класс с пониженными приоритетами:


Но проверить, на сколько это изменит влияние ваших запросов на текущую нагрузку сервера можно только экспериментальным путём, для чего хорошо бы уже иметь настроенную систему workload managementa просто для того, чтобы получить картину нагрузки/производительности, разбитую по разным классам работ по отдельности. А это уже большой и долгий процесс.

Тут есть ещё важный дополнительный фатор:
В целом на приоритет I/O повлиять нельзя (по крайней мере пока в AIX/Linux WLM не добавили возможность контролировать приоритет I/O ну уровне threads). Можно повлиять только на приоритет чтения в режиме PREFETCH (чтобы оно в очереди таких запросов задвигалось в конец) - три уровня (LOW, MEDIUM, HIGH).
Если остальная нагрузка идёт в основном не в PREFETCH режиме (OLTP система, что похоже на ваш случай - "К серверу периодически приходят запросы, на которые он должен быстро реагировать и делает это."), то они будут просто идти в параллель, и мы никак не сможем повлиять на их взаимную приоритезацию, и, соответственно, остальная I/O активность будет проседать. На сколько - вопрос мониторинга и конкретной нагрузки.


Два серьёзных дополнительных момента:
1. Как только мы запихиваем нагрузку в отличный от дефолтового сервисный класс, он сразу перестаёт быть предметом рассмотрения DB2 governor'а и Query Patroller'а.
Т.е. если они используются для контроля активностей, использование WLM не подойдёт.

2. На OLTP системах с большим количеством запросов на изменения можно "в лёт" переполнить журналы транзакций просто заблокировав их на часик/другой.
Картина примерно следующая:
- наш запрос открывает транзакцию, что-то изменяет в данных, и это попадает в журнал;
- пока наш большой запрос с низким приоритетом долго-долго выполняется, журнал остаётся "активным" (содержащим данные активной транзакции);
- пока журнал активен, ни он, _ни_последующие_ (для соблюдения целостности архива журналов) в архив не отправляются;
- количество журналов "текущих" транзакций растёт, пока не упираемся в заданное ограничение;
- все встаёт колом, приложения на любые действия получают отлуп "log is full" (и, если не умеют действовать по принципу "попробовать чуть позже", отваливаются), пока СУБД не разберётся с проблемой (автоматически отстрелит и откатит виновника).
Если "виновник" успел к этому времени много "наколбасить" (в случае больших запросов на изменения), то откатываться может _очень_ долго.


В общем, чтобы "всё было хорошо", надо
а) чётко представлять текущую нагрузку, как запросы будут работать, и придерживаться некоторых правил;
б) работать в тесном контакте с админами тех баз.