Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Create separated connection within stored procedure  [new]
Paulo82
Member

Откуда:
Сообщений: 42
Hello!

I have a stored procedure that takes a lot of time. Some parts of the sp could be separated to different "threads". I'm looking for a solution that permits me to open a separated connection and process independent parts of treatment within that connection. How could I accomplish this goal? Or probably there's another solution?

Thanks!

P.S. You can reply in Russian.
28 сен 07, 14:06    [4730406]     Ответить | Цитировать Сообщить модератору
 Re: Create separated connection within stored procedure  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 116152
Немного непонятно.
Если предположить, что части процедуры не связаны между собой, то их
выполнение можно распараллелить обычными jobs. Но ведь скорее всего
процедура по мере своего выполнения опирается на результаты , полученные
ранее в ней же...
28 сен 07, 14:08    [4730431]     Ответить | Цитировать Сообщить модератору
 Re: Create separated connection within stored procedure  [new]
Levandovskiy
Member

Откуда:
Сообщений: 329
Том Кайт: "Убыстряем" работу приложений
Вопрос. У нас есть приложение, которое создает пользователей и определяет для них приватные синонимы. Иногда администратор системы безопасности выполняет множественные удаления пользователей, которым больше не нужен доступ к базе данных. Для удаления пользователя, у которого имеется около тысячи приватных синонимов может потребоваться около двух минут. Я неудовлетворен таким слишком медленным удалением вышедших из употребления учетных записей. Есть ли у вас какие-то предложения по повышению производительности выполнения оператора DROP USER, не считая перевода системы на использование публичных синонимов?
Ответ. Все дело в восприятии. Всякий раз когда я имею долго работающий процесс, я думаю, как его выполнять в фоновом режиме, чтобы "несчастливый" конечный пользователь никогда не ждал его завершения. Если конечный пользователь не должен ждать завершения процесса, он будет казаться ему сработавшим мгновенно.
Итак, будем выполнять долго работающий процесс в фоновом режиме, и конечный пользователь подумает: "Класс, в самом деле он работает быстро"! Я рекомендую выполнять оператор DROP USER имя_пользователя CASCADE следующим образом:
1. ALTER USER имя_пользователя LOCK;
(Учетная запись блокируется, так что достигается "цель обеспечения безопасности".)
2. dbms_job.submit( l_job, 'execute immediate ''drop user a cascade'';' );
3. commit;
Пользователь сразу же получает сообщение, что все в порядке. Блокирование учетной записи запрещает ей доступ к базе данных, а фактическое удаление схемы пользователя (на него может потребоваться какое-то время) начнется в фоновом режиме вскоре после выполнения оператора COMMIT (конечный пользователь не должен ожидать завершения удаления).
Я прибегаю к этому способу всегда, когда появляются предположительно долго выполняющиеся задачи – скрытие реальной работы, благодаря фоновому режиму, и немедленное продолжение работы конечных пользователей, так что они думают, приложение работает намного быстрее, чем это есть на самом деле.
28 сен 07, 14:28    [4730630]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить