Универсальный триггер

Пишу тригер на таблицу (типа протокол изменений),
не знаю сколько и какие поля у таблицы - она меняться,
но есть строка типа ":NEW.ID, :NEW.NAME" или "ID, NAME" - это типа первичный ключ.
я её формиру как хочу.
можно ли как-то получить значения этих парметров
используя execute immediate или еще как-нибудь?
Цель - записать в таблицу-протокол в одно поле значения ключевых полей в другое не ключевых, чтобы иметь возможность сделать откат!

Smith2

Цель - записать в таблицу-протокол в одно поле значения ключевых полей в другое не ключевых, чтобы иметь возможность сделать откат!

А стоит ли изобретать велосипед?

Oracle® Database Concepts 10g Release 1 (10.1) Part Number B10743-01

17 High Availability ... Oracle Solutions to Human Errors This section covers some Oracle solutions to human errors, including the following: Overview of Oracle Flashback Features Overview of LogMiner

Smith2

делать подобное при каждом вызове триггера (парсить структуру таблицы и строить execute immediate) - крайне глупо и неэффективно.

Значительно проще нарисовать генератор этих самих триггеров...

DBA_ ALL_ USER_TAB_COLUMNS в помощь.

т.е. генерировать "чистый" PL/SQL, заранее скомпилированный и пропарсенный.

для особо ленивых, также, предусмотрены DDL триггеры..

из отряда....

CREATE TRIGGER audit_db_object AFTER CREATE ON SCHEMA

(правда, со всеми вытекающими последствиями от их ограничений ;)))

но для протоклола изменений (суть аудит) лучше воспользоваться
либо встроенными средствами аудита Oracle (как наименее ресурсоемкое),

либо уже более детально рассмотреть INSTEAD OF вариант триггеров (
если нужно ловить только "пользовательские" изменения....)

grexhide

либо уже более детально рассмотреть INSTEAD OF вариант триггеров (если нужно ловить только "пользовательские" изменения....)

Мнэээ... Вы о чем?

andrey_anonymous

grexhide либо уже более детально рассмотреть INSTEAD OF вариант триггеров (если нужно ловить только "пользовательские" изменения....) Мнэээ... Вы о чем?

Способ организации пресловутого процедурного API. Из категории - пользователям доступны только обзоры(и триггеры на них) и пакеты.

При условии, что "системные" операции, к примеру собственная схема репликации, не должны приводить к вызову каких либо триггеров на таблицы вообще (они в данном случае просто выбрасываются), в т.ч. при условии - не переписывать клиентские приложения не предмет замены DML именно процедурными вызовами.

grexhide

Способ организации пресловутого процедурного API. Из категории - пользователям доступны только обзоры(и триггеры на них) и пакеты.

Этого я и боялся :)
ИМХО - крутовато для озвученной задачи

Smith

чтобы иметь возможность сделать откат

ИМХО достаточно систематизировать использование logminer или flashback, в зависимости от реальной потребности в "откате".

andrey_anonymous

Smith чтобы иметь возможность сделать откат ИМХО достаточно систематизировать использование logminer или flashback, в зависимости от реальной потребности в "откате".

ИМХО от задачи уж очень сильно зависит. И понятие "откат".... оно имеет массу трактований, не обязательно в рамках технологических возможностей Oracle ;)))

grexhide

ИМХО от задачи уж очень сильно зависит. И понятие "откат".... оно имеет массу трактований, не обязательно в рамках технологических возможностей Oracle ;)))

Полагаю, в рамках специализированного форума подобные аспекты можно со спокойной совестью оставить за кадром :)

andrey_anonymous

Полагаю, в рамках специализированного форума подобные аспекты можно со спокойной совестью оставить за кадром :)

Безусловно. Хотя, признаться, я в меньшей степени имел в виду то, о чем возможно сразу, в данном случае, подумали Вы ;)

Но тем не менее, тогда уже, вместо "чисто" админских logminer... и flashback может имеет смысл рассмотреть Oracle Workspace Manager ?

Или тоже "тяжело" ? В сравнении с тем же вышеупомянутым logminer ?

Особенно в том ракурсе, что арх. логи не хранятся вечность, а скажем так, лишь до следующего 0-уровневого бэкапа...

grexhide

Но тем не менее, тогда уже, вместо "чисто" админских logminer... и flashback может имеет смысл рассмотреть Oracle Workspace Manager? Или тоже "тяжело" ? В сравнении с тем же вышеупомянутым logminer ?

Вопрос что взвешивать.
Возьму на себя смелость утверждать, что "откат" подобного (исключительно технического :) вида - операция эксклюзивная и крайне "интеллектоемкая" в любой "живой" системе, состоящей более чем из одной таблицы.
Проблема - в последующих "изменениях ошибочно измененой записи" и ограничениях целостности (что уже само по себе накладывает жестокое ограничение на ретроспективу).
Применяя Workspace Manager, триггеры и т.д., платим сейчас (наши тесты Workspace Manager показали замедление DML на один-два порядка) за вероятную в будущем операцию "отката".
Самое печальное, что ввиду вышеизложенного стоимость "отката" это никак не снижает.

grexhide

Особенно в том ракурсе, что арх. логи не хранятся вечность, а скажем так, лишь до следующего 0-уровневого бэкапа...

Какая разница - хранить два-три цикла арклогов или немерянных размеров "логи" в специальной таблице + редо к ней? Лента все стерпит :)

Кстати, из еще не обсуждавшихся возможностей - со стародавних времен наши админы решали задачу "flashback" посредством сервера standby.
Для этого ставится 3-4часовая задержка применения архивов.
Если кто по глупости или неразумению грохнул что-то ненужное :), то надо просто горомко об этом заорать в течение двух часов.
Цена вопроса - переключение на standby удлинняется на время, необходимое для применения очереди логов за эти 3-4 часа (до 40 минут, но у нас изменений довольно много).