Структура не меняется, только данные. Есть некоторое исходное состяние. И около тысячи тестовых сценариев, для каждого нужна слегка видоизмененная от исходной база (сотня-другая insert, update, delete). Есть программа, которая генерирует эти изменения, только ее нужно дебажить, останавливать в нужном месте. Раньше думали, останавливать и снимать полный дамп базы. Но он весит около 50 Mb, и у начальства возникло опасение, что 1000 * 50Mb размер пакета клиентам не понравится.
// Мне вообще кажется, что идея бредовая и без полных дампов не обойтись, там по крайней мере все просто - expdp, impdp.
Пытался протрэйсить запросы с помощью V$SQL, sql-trace и аудита. Но везде вылезают в некоторых запросах биндинги - переменные, что делает запросы бесполезными в плане diff-sql.
Смотрю в сторону Liquibase, но он вроде только изменения структуры отслеживает.
Последняя идея - отслеживать, какие таблицы поменялись, и сохранять/заменять только их, предварительно сделав им drop или truncate. Внешних ключей вроде почти нет, но в случае чего придется их все удалять, а после заменения таблиц восстанавливать.
Или делать для каждой таблицы select minus select, но это ж ручной работы сколько.
Вот, какие будут идеи? Аргументы, почему так делать не надо либо задача сложнее чем кажется, интересны тоже :)

dmdmdmЕсли задача в том, чтобы отследить действия закрытого приложения в БД (насколько понял ваши многабукв), есть еще аудит.
Не просто отследить, но записать их в sql-файл diff.sql, чтобы потом их воспроизвести снова с помощью imp ... diff.sql
Аудит и трэйс возвращают, к сожалению, биндинги, типа insert ... values (:p1). :p1 - это как я понимаю ранее выуженная селектом переменная. То есть весь запрос в результате непригоден для воспроизведения, так как неоткуда взять значение :p1
Есть Oracle streams, но они вроде для прямой трансляции изменений в другую базу, а не в sql-файл. Есть еще change data capture (CDC)... Но видимо задача действительно нетривиальная, постараюсь спихнуть в отдел баз данных, что с меня программиста взять.

Спасибо всем за ответы. Мне даже неловко, все сомневаются в серьезности этого мероприятия.

Цель - тесты. Есть около 1000 тестовых сценариев. На исходной тестовой базе (для которой есть дамп initial.sql, то есть ее можно приводить в исходное состояние снова и снова) перед каждым тестом выполняются подготовительные sql-запросы, несколько сотен. Только после этого можно начинать тест. Эти запросы выполняются сейчас скриптами на Perl, от которых решено избавиться и в которые никто вникать не хочет. В принципе можно сохранить для каждого из 1000 тестов его начальный дамп, и вместо выполнения скриптов загружать эти дампы.

То есть если раньше было

1. загрузить initial.sql
2. запустить перл-скрипт для подготовки теста 1
3. выполнить тест 1
4. загрузить initial.sql
5. запустить перл-скрипт для подготовки теста 2
6. выполнить тест 2
и т.д.

то сейчас будет
1. загрузить dump1.sql (заготовленный начальный дамп для теста 1)
2. выполнить тест 1
3. загрузить dump2.sql (заготовленный начальный дамп для теста 2)
4. выполнить тест 2
и т.д.

Но тогда размер данных увеличивается примерно в 1000 раз (размер initial.sql * 1000). И это типа плохо из-за размера, клиенты скажут, у нас были раньше один дамп на 50 мб и сотня килобайт скриптов, а теперь что?

Поэтому идея для каждого теста построить дифф к initial.sql, эти диффы будут очень небольшими по сравнению с initial.sql
Тогда получится

1. загрузить initial.sql
2. загрузить diff1.sql
3. выполнить тест 1
4. загрузить initial.sql
5. загрузить diff2.sql
6. выполнить тест 2
и т.д.

Структура нигде не меняется, только данные. Перед каждой загрузкой initial.sql вся схема удаляется, создается новый пустой юзер, все с нуля начинается.
Пока я нашел, что в аудите в поле sql_text запросы, а в поле sql_bind - bind variables к каждому запросу. В принципе, можно распарсить и реконструировать полный текст каждого запроса. Я конфронтировал начальство с необходимостью писать для этого дополнительную программу. Как-то так: https://discuss.elastic.co/t/parsing-field-sql-bind-into-sql-text/97447
Начальство будет думать, может еще передумают.