Комментарии 22
С OCN не работал, а нельзя для этих целей использовать триггеры на таблицах? В триггере также можно вызывать процедуру или послать сообщение по сети DBMS_TCP. Какие тут минусы?
Ну, как мне кажется у любого подхода есть своя применимость. Вообще, обилие триггеров на таблицах может снизить производительность insert-ов. Код который Вы выполняете в триггере по умолчанию выполняется в той же транзакции что и insert. И в том же потоке. А здесь все сделает менеджер задач Oracle, в фоновом потоке. Еще, Вам видимо придется самостоятельно реализовать обработку сообщений, полученных из триггеров, а здесь предлагается уже готовое решение. Зато, вероятно, гибкость которую Вы получите в случае отказа от OCN будет больше. Вопрос только в том, нужна ли она.
Не совсем так. OCN построена поверх Advanced Queue которые, в свою очередь построены на обычных таблицах.
Так что производительность триггеров, которые пишут в сокет будет скорее всего ВЫШЕ чем при использовании OCN (у которого будут писаться редо логи, архив логи, undo segment и т.п.)
Проблема с триггерами и записью в сокет в том, что в оракле нет события (триггера) OnCommit, на которое можно было бы повесить обработчик (само событие вообще-то есть — materialized view умеют по OnCommit обновлятся).
Я даже где-то понимаю оракловцев мужественно терпящих висящий с 90-х годов тикет про это событие. Действительно — а что делать если в обработчике произошло исключение? делать роллбек? или все-таки коммит?
Так вот, в триггере на таблице, который пишет в сокет проблема в том, что вы не можете определить достоверность данных. Т.е. можно реализовать идиотский метод — запрашивать данные «в обратку» но тогда вы нагрузите оракл лишними запросами и достоверность не увеличите. Вы же не знаете, закончилась транзакция или нет.
Так что производительность триггеров, которые пишут в сокет будет скорее всего ВЫШЕ чем при использовании OCN (у которого будут писаться редо логи, архив логи, undo segment и т.п.)
Проблема с триггерами и записью в сокет в том, что в оракле нет события (триггера) OnCommit, на которое можно было бы повесить обработчик (само событие вообще-то есть — materialized view умеют по OnCommit обновлятся).
Я даже где-то понимаю оракловцев мужественно терпящих висящий с 90-х годов тикет про это событие. Действительно — а что делать если в обработчике произошло исключение? делать роллбек? или все-таки коммит?
Так вот, в триггере на таблице, который пишет в сокет проблема в том, что вы не можете определить достоверность данных. Т.е. можно реализовать идиотский метод — запрашивать данные «в обратку» но тогда вы нагрузите оракл лишними запросами и достоверность не увеличите. Вы же не знаете, закончилась транзакция или нет.
Проблема с триггерами и записью в сокет в том, что в оракле нет события (триггера) OnCommit, на которое можно было бы повесить обработчикесть очень древний подход — раньше в таких случаях делали в триггере dbms_job.submit, который должен вызвать нужную процедуру-хэндлер события. Соответственно, пока основная транзакция не делала коммит — джоб не запускался.
Тяжеловесно :) Так же как делать триггер на materialized view которая OnCommit обновляется.
И не решает проблемы обработки Rollback. Я этой задачей интересовался в попытках реализовать хранение логов изменений данных в NoSQL DB. Собственно я хотел избежать дополнительных записей в таблицы и иметь актуальные данные. При наличии обработки коммита можно только частично решить задачу.
И не решает проблемы обработки Rollback. Я этой задачей интересовался в попытках реализовать хранение логов изменений данных в NoSQL DB. Собственно я хотел избежать дополнительных записей в таблицы и иметь актуальные данные. При наличии обработки коммита можно только частично решить задачу.
&
И не решает проблемы обработки Rollback.в смысле? Вообще-то как раз решают — при роллбэке джоб-хэндлер вызван не будет.
Да, но как отличить это от ситуации что транзакция еще не закончилась?
Опять не понял вопроса… Отличать что, от чего и зачем? Предполагается, что обработка нужна только для закоммиченных изменений — так она и будет запущена только для закоммиченных изменений. Для незакоммиченных ничего не будет происходить.
Спасибо за ответ, про commit я действительно забыл. Но решения через dbms_job.submit очень интересное, надо записать в блокнотик :)
Так вот, в триггере на таблице, который пишет в сокет проблема в томтут опаснее то, что любые проблемы в таком триггере скажутся на самой основной транзакции, которые зачастую стараются делать как быстрее, а все лишнее проводить в асинхронной обработке близкой к реальному времени
Абсолютно согласен. Хотя латчи самого оракла такое иногда вытворяют… и нагрузка на редологи только увеличивает вероятность.
Короче, опасности везде поджидают )
Короче, опасности везде поджидают )
Я даже где-то понимаю оракловцев мужественно терпящих висящий с 90-х годов тикет про это событие.
Почему бы им не сделать 2 события: beforecommit — ошибка бы откатывала и aftercommit — ошибка не откатывала.
Вообще хватило бы и одного aftercommit.
Можно, конечно, но не в лоб, т.к.могут быть и роллбэки
Триггеры в большинстве случаев «забываются» разработчиками, особенно если не они их писали :)
Кстати, если в БД логика вынесена в plsql, то можно еще использовать стандартные пакеты dbms_pipe и dbms_alert. Естественно, соответствующий код надо прописать ручками, зато функционал потенциально интереснее.
В одной из систем (2-звенка) перед установкой патча на БД выгоняли пользователей из приложения через алерты.
Кстати, если в БД логика вынесена в plsql, то можно еще использовать стандартные пакеты dbms_pipe и dbms_alert. Естественно, соответствующий код надо прописать ручками, зато функционал потенциально интереснее.
В одной из систем (2-звенка) перед установкой патча на БД выгоняли пользователей из приложения через алерты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт использования Object Change Notification в Oracle