Существуют различные подходы, в зависимости от ситуации. Самый простой из возможных подходов, на который можно надеяться, состоит в том, чтобы спросить, как долго будет выполняться самая продолжительная реалистичная операция (она, очевидно, зависит от системы и зависит от того, какую систему вы строите или что-то существует), и вернуться к CPU_PER_CALL, основанный на этом временном ограничении и степени параллелизма. Предполагая однопоточную операцию, если вы можете разумно сказать, что если запрос не вернулся через 30 минут, вы хотите его убить, вы можете установить CPU_PER_CALL для выделения 30-минутного ЦП (очевидно, что большинство запросов не будет использовать %, так что 30-минутный лимит дает вам некоторое пространство для дыхания).
Если это существующая система, вы (или ваш администратор БД) можете просматривать отчеты AWR / statspack в течение разумного количества дней (некоторые системы должны будут обязательно просматривать отчеты за месяц / квартал / год, где дополнительная обработка может быть сделано) и найти реальные операторы, которые используют больше всего процессора и ввода-вывода. Затем вы можете соответствующим образом установить пределы своего профиля (т. Е. Максимальный ЦП, зарегистрированный для выписки в прошлом месяце + 30% передышки).
Конечно, для любого ограничения, которое вы выбираете, кто-то должен контролировать систему, чтобы убедиться, что лимиты идут в ногу. Например, если запросы со временем становятся все более и более дорогостоящими из-за увеличения объема данных, этот максимальный предел + 30% может оказаться недостаточным через 6 месяцев. Вы не хотите это выяснять, когда ночная обработка прерывается, кто-то должен быть в курсе этого.
Если вы используете корпоративную версию, вам лучше будет смотреть на Resource Manager, а не на профили. В то время как профили позволяют вам убирать безудержные сеансы, Resource Manager позволяет вам изменять приоритет сеанса на основе множества факторов. Вместо того, чтобы убивать запрос, который использовал более 30 минут ЦП, может быть лучше сделать его более низким приоритетом, чтобы он не мешал другим сеансам, не убивая его, в случае, если он просто выполняется долго.