Можно ли увидеть выполняемый DML (оператор SQL), который вызвал запуск триггера?
Например, внутри триггера INSERT я хотел бы получить это:
"вставить в myTable (имя) значения ('Фред')"
Я читал о ora_sql_txt (sql_text) в таких статьях, как this , но не смог заставить его работать - не уверен, что это даже ведет меня по правильному пути?
Мы используем Oracle 10.
Заранее спасибо.
=========================
[РЕДАКТИРОВАНИЕ] ПОДРОБНОЕ ОПИСАНИЕ: Нам необходимо скопировать существующую базу данных (DB1) в классифицированную базу данных (DB2), которая не доступна через сеть. Мне нужно синхронизировать эти базы данных. Это односторонняя синхронизация из (DB1) в (DB2), поскольку (DB2) будет содержать дополнительные таблицы и данные, которых нет в системе (DB1).
Я должен определить способ синхронизации этих баз данных, не отключая их (скажем, для резервного копирования и восстановления), потому что он должен оставаться в живых. Поэтому я подумал, что если я смогу сохранить действующий DML (при изменении данных), я мог бы «воспроизвести» DML в новой базе данных, чтобы обновить его, точно так же, как кто-то вручную вводил его обратно.
Я не могу перенести все данные из-за огромного размера, и я не могу просто скопировать измененные записи из-за ограничений FK и порядка, в котором я вставляю / обновляю записи. Я подумал, что, если бы я мог «воспроизвести» журнал событий, используя точный SQL, который изменил мастер, я мог бы синхронизировать базы данных.
Мой текущий план атаки состоял в том, чтобы вести журнал всех записей, которые были изменены, вставлены и удалены, и когда я хочу синхронизировать, система генерирует DML для вставки / обновления / удаления этих записей. Затем я просто беру файл .SQL в секретную систему и запускаю скрипт. Проблема, с которой я сталкиваюсь - это ФК. (Потому что, когда я генерирую DML, я знаю только, каково текущее состояние данных, а не путь к нему - так что упорядочение операторов является проблемой). Я думаю, я мог бы отключить все FK, выполнить слияние, а затем снова включить все FK ...
Итак - мой подход хранения фактического DML, как он есть, сосет воду, или есть лучшее решение ???