10.06.2009 15:14
OlegON
 
Достаточно часто сталкиваюсь с проблемой, когда расчет ТД не считается, потому, что кто-то забыл закрыть Супермаг. Бывает, что кто-то регулярно кладет базу своими тяжелыми запросами, выбивая мелких создателей карточек и накладных из колеи. Я уже говорил о том, что лучше перевести в shared сервер. Теперь упомяну о том, чем я давно пользуюсь, ставя любителей рукописных поделий на место.
Во-первых, с самого начала надо выставить:
Цитата:
alter system set resource_limit=true scope=both;
говорю это для 10ки, но все это есть и в 9ке, а многое и в 8ке, но если вы серьезно настроены, то в 8ке уже не работаете.
Итак, самое простое и очевидное - настроить профили (Profiles). В чем их выгода? 1) Можно ограничить подключение юзера по времени (Idle time), т.е. поставить, например, 2 часа и к ночным процедурам уцелеют только те, кто действительно работает. Учтите, что если зайти в раздел, а потом перейти в другой и долго не возвращаться, то это другая сессия и она будет прибита спустя некоторое время. 2) Можно ограничить количество считанных блоков за вызов. Это интересно, если кто-то любит запускать избыточные отчеты. Все запросы должны укладываться в определенные рамки, все что выше - прибиваться. Это, конечно, относится к таким коробочным продуктам, как Супермаг. Среди прочего (я не планирую писать трехтомник) можно отметить параметры блокировки логина. Т.е. если кто-то долбится, перебирая пароль, то он добивается блокировки пароля. Есть плюсы и минусы этой опции. Обратите внимание, что обычно я создаю профиль ROOT, куда включаю системных пользователей, например, SUPERMAG, чтобы их не трогали изменения профилей. А издеваюсь над DEFAULT.
Менее очевидное, но гораздо более гибкое и мощное - планы ресурсов. Подробно писать не буду, но дам направления для поиска на закладке Administration (опять же 10ки). 1) Создаем планы, обычно - пара, на день и ночь, можно сначала просто их создать, не настраивая 2) Создаем окна (Windows), определяем их время и указываем в них план, опять же, обычно это день и ночь (у меня еще отдельный план на воскресение бывает, если это нерабочий день) 3) Создаем группы пользователей ресурсов (Consumer groups) у меня это единственная требуемая к существующим - группа ANAL (аналитики). Общее описание лестницы: Отдельно SYS_GROUP системных пользователей, затем идет DEFAULT, потом LOW, потом ANAL. Т.е. последняя получает полный фиг по отношению к остальным.
Продолжение следует...
10.06.2009 15:45
OlegON
 
Итак, создали группы (они по большому счету нужны для участия в планах и только). Необходимо дать возможность переключаться на них. На все группы пониженного приоритета даем:
Цитата:
BEGIN
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP (
GRANTEE_NAME => 'PUBLIC',
CONSUMER_GROUP => 'ANAL',
GRANT_OPTION => TRUE);
END;
т.е. в данном примере я даю PUBLIC (т.е. всем пользователям) возможность переключаться на ANAL.
Подойдем к самому интересному - созданию плана. Общее, что я обычно планирую, это днем системе мало, пользователям больше, ночью системе больше, а пользователям вообще фик (чтобы не блокировали ресурсы). Кстати, при использовании планов я обычно не использую профили, чтобы не путаться. Итак, правим один из созданных планов, добавляя туда группы пользователей ресурсов. На Level 1 определяются ресурсы в первом круге, минимум, в процентах. Я обычно дальше этого уровня и не ухожу, групп не много. Разделяем 100% по группам так, чтобы DEFAULT получил 90%, LOW - 9, ANAL - 1 (у меня это специфичные аналитики, поэтому так их давлю). Вторая закладка - параллелизм. У меня тут только на ANAL ограничение - 1. Третья закладка - количество доступных активных сессий. Все очень просто, аналитикам - 1, т.е. в конкретный момент времени только 1 запрос от группы аналитиков будут работать. Остальные будут "висеть" в очереди. Сам Супермаг будет выглядеть зависшим, но мои аналитики в Супермаге не работают. На ночном плане в этой закладке у меня две группы SYS_GROUP - UNLIMITED и OTHER - 0, т.е. сразу подключения сессия подвиснет. Очень удобно - никакие назначенные задания пользователей не отваливаются, но и блокировать ресурсы не получается. После этого переходим на закладку "Consumer Group Switching", тут обозначены условия при которых пользователи переходят в другую группу. Тут все просто. Ставлю, чтобы LOW после 600 секунд выполнения переходил в ANAL, DEFAULT после 600 - в LOW, а в ANAL после 900 минут делал Cancel SQL (ибо нефик, у меня таких долгих запросов нет). На закладке Idle time пробиваю всем по 3600 общего простоя и 240 - в случае блокировки ресурсов (для SYS_GROUP - 900).
Все... Можно оттачивать планы по своим условиям... Писал по памяти, может что-то забыл - поправьте, но работает уже давно и во многих местах...
Часовой пояс GMT +3, время: 06:23.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.