Занимаясь goldengate-репликацией столкнулся с необходимостью выполнить сравнение таблицы, в исходной бд и её таблицы-реплики, в бд-приёмнике.
Для случая когда таблица и таблица-реплика  обе имеют, одинаково устроенные ключи (как оно и д.б., по идее), есть замечательный пакет dbms_comparison.

Однако, что делать, если ключей нет никаких, нет и unique-индекса, с not-null. А такое — бывает.

Тут нужно велосипедить какое то решение.

Или договариваться с заказчиками репликации чтобы — добавляли ключи, на таблицы и им релевантные таблицы-реплики.

Добавление ключей — не всегда желательно, с т.з. заказчика, например потому что прикладной код может нехорошо отреагировать, на появление в таблице/таблице-реплике нового столбца.

Это можно обойти, сделав новый, ключевой столбец не видимым, gg-такие ключевые столбцы: поддерживает, это интересный способ, но о нём — в другой раз.

В этой статье — про велосипед.

Тема, насколько старая, настолько же и актуальная. Поделюсь, своим концептом на архитектуру провиженинга тестовых субд, с целью получения комментариев по существу - может кто ходил уже этой дорогой. И знает более короткий/удобный пусть.

В общем, в одной далёкой-далёкой галактике динамичной-быстро развивающейся компании есть множество (десятки) продовых oracle-баз. Продовые бд - названы одинаково. Специфика обстановки, с этой стороны: SE, типовой размер баз 3-3.5Тб, самая большая бд - 7+Тб. Легаси-монолит, всё работает - на хранимках (да, буээ и фу, но разговор не об этом).

Из этого бытия следует что, поскольку легаси/монолит: существует армия разработчиков, поделённая на группы. И т.к. с одной стороны: группы - работают с разными проектами, в разных стадиях работы, групп много, а с другой стороны - всё запихано в одних и тех же базах - группы работают практически с одними и теми же объектами бд и с разными целями этой работы, включая разрушающие тесты.

Т.е., такое бытие определяет потребности каждой группы в выделенной, для группы тестовой бд. А то и: прям для каждого разработчика.

Иначе говоря: тестовых баз надо:

Добрый день.

Первый вопрос: зачем, есть же Toad/SQL-developer/PLSQL-developer и т.п. графические ide-среды.

Ну. Да. Есть. Однако не всем именно они нужны, как средство работы с объектами oracle-субд.

Т.е. я тут, в этой статье - не именно для oracle-разработчиков буду рассказывать что то. Скорее для dba, т.е. людей у которых работа с СУБД значительно более специфичная.

Второй момент: сейчас: удалёнка, везде и всюду. В этой связи доступ на работу - организовывается удалённый.

Либо: через что то типа VDI/RDP. Либо: выдаётся рабочий ноутбук и от на нём, с него - работай.

В первом случае - ну, часто подразумевается графический интерфейс удалённого рабочего стола и: виндовый и с ограничением по ресурсам.

Во втором случае: ну, организации часто пытаются и тут сэкономить - выдадут какой-нибудь ноутбук с 8Гб оперативы и - как хочешь, так на этом и работай. Т.е.: файрфокс, с N>>10 кол-вом вкладок, какой-нибудь sql-developer/Жаба/plsql-девелопер, скайп/зум, ещё что то.

В обоих случаях: возникает вопрос - а как то бы тут сэкономить, на ресурсах, например - на IDE для oracle-субд.

Здравствуйте.

Пролог.

Есть пара вопросов, которые уже много лет любопытно уточнить у причастной общественности.
Но. В моём болотистом-низменном крае — и людей в теме: мало и обстановка в ит-направлении, на большинстве предприятий, не способствует. Вот, поэтому, попробую с помощью хабра удовлетворить своё любопытство. Вопрос касается подхода к обработке awr|statspack-данных, по наблюдаемой-поддерживаемой oracle-бд.

Итак к сути.

Здравствуйте.

Решил поделится своей находкой — плодом раздумий, проб и ошибок.
По большому счёту: это никакая не находка, конечно же — всё это должно быть давно известно, тем кто занимается прикладной стат-обработкой данных и оптимизацией каких либо систем, не обязательно именно СУБД.
И: да знают, пишут занятные статьи по своим ресерчам, пример (UPD.: в комментариях указали на очень интересный проект: ottertune )
С другой стороны: навскидку не усматриваю широкого упоминания, распространения такого подхода, в интернете, среди ит-специалистов, ДБА.

Итак, к сути.