Как перенести изменения DDL из одной среды в другую?

Question

Я делаю изменения DDL с помощью графического интерфейса SQL Developer. Проблема в том, что мне нужно применить те же самые изменения к тестовой среде. Мне интересно, как другие справляются с этой проблемой. В настоящее время мне приходится вручную писать инструкции ALTER, чтобы привести среду тестирования в соответствие с средой разработки, но это подвержено ошибкам (дважды повторяя одно и то же). В тех случаях, когда в тестовой среде нет важных данных, я обычно просто удаляю все, экспортируйте сценарии DDL из dev и запускайте их с нуля в тесте.

Я знаю, что есть триггеры, которые могут хранить каждое изменение DDL, но это сильно разделяемая среда, и я хотел бы избежать этого, если это возможно.

Возможно, мне нужно просто написать материал DDL вручную, а не использовать графический интерфейс?

Answer 1

Я видел, как многие методы пытались справиться с этим, и, в конце концов, я думаю, вам нужно просто поддерживать ручные сценарии.

Теперь вам не обязательно писать сами. В MSSQL, когда вы вносите изменения, есть небольшая кнопка для создания скрипта, которая выплевывает SQL-скрипт для изменения, которое вы делаете. Я знаю, что вы говорите об Oracle, и прошло несколько лет с тех пор, как я работал с их графическим интерфейсом, но могу только представить, что у них такая же функция.

Однако вы не можете уйти от работы со скриптами вручную. У вас будет много проблем с уже существующими данными, такими как значения по умолчанию для новых столбцов или способы обработки данных для столбца переименованного/удаленного/перемещенного. Это лишь часть анализа при работе со схемой базы данных с течением времени, от которой вы не можете уйти. Если вы попытаетесь сделать это с помощью полностью автоматизированного решения, ваши данные рано или поздно будут испорчены.

Единственное, что я хотел бы посоветовать, просто чтобы сделать вашу жизнь немного легче, убедитесь, что вы отделяете изменения схемы от изменений кода. Разница заключается в том, что изменения схемы в таблицах и столбцах должны выполняться ровно один раз и никогда больше и поэтому должны быть версиями в виде отдельных сценариев изменений. Тем не менее, изменения кода, такие как хранимые процедуры, функции и даже представления, могут (и должны) запускаться снова и снова и могут управляться версиями точно так же, как и любой другой файл кода. Лучший подход к этому я видел, когда у нас были все функции procs/functions/views в VSS, и наш процесс сборки потерял бы все и воссоздал их во время каждого обновления. Это та же идея, что и перестройка вашего кода C#/Java/любого другого, поскольку он гарантирует, что все всегда актуально.

Answer 2

Никогда не используйте графический интерфейс для таких целей. Напишите сценарии и поместите их в исходный контроль.

Answer 3

Вот триггер, который я реализовал для отслеживания изменений DDL. Использованные источники:

http://www.dba-oracle.com/t_ddl_triggers.htm

http://www.orafaq.com/forum/t/68667/0/

CREATE OR REPLACE TRIGGER ddl_trig 
AFTER create OR drop OR alter 
    ON scott.SCHEMA 
DECLARE 
    li ora_name_list_t; 
    ddl_text clob; 
BEGIN 
    for i in 1..ora_sql_txt(li) loop 
    ddl_text := ddl_text || li(i); 
    end loop; 

INSERT INTO my_audit_tbl VALUES 
    (SYSDATE, 
    ORA_SYSEVENT, 
    ORA_DICT_OBJ_TYPE, 
    ORA_DICT_OBJ_NAME, 
    ddl_text 
    ); 
END; 
/

Answer 4

Database Change/Управление базой данных Diff Некоторые инструменты для этого есть -

1) Oracle Change Management Pack

С документы -

Это позволяет нам выполнить базовую линию (моментальный снимок) через определенное время, а затем мы увидим, как изменилась схема и объекты БД.CMP также может генерировать сценарии DDL, хотя я не уверен, что мы захотим его использовать.

Подробности

• http://download-east.oracle.com/docs/cd/B19306_01/em.102/b31949/change_management.htm
• http://www.oracle.com/technology/products/oem/pdf/change-management-pack-11g-datasheet.pdf

2) PL/SQL Developer функцию сравнения объектов пользователей

 This is available from Tools -> Compare User Objects 

3) Oracle SQL Developer Database Diff FEA дифракционную картину

  This is available from Tools -> Database diff 
      http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html#copy See “Schema Copy and Compare” 

# 1 выглядит наиболее универсальным и гибким, но права DBA могут быть необходимы.

# 2 & 3 может использоваться любым разработчиком. Я думаю, что Oracle SQL Developer проще и предоставляет больше возможностей.

Использование любого из вышеуказанных варианта может помочь -

1. Идентификация измененных объектов и может также служить в качестве Контрольный список до представления MAC.
2. Заинтересованные разработчики могут взять на себя ответственность за определенные измененные объекты.

Answer 5

Вы можете сделать это с Toad.

Вы используете функцию Compare Schemas, чтобы найти все различия (она очень гибкая, вы можете указать, какие типы объектов просмотреть и многие другие параметры). Это покажет вам различия, вы можете взглянуть и убедиться, что это кажется правильным, а затем сказать ему, чтобы создать для вас сценарий обновления. Вуаля. Единственный улов - вам нужен модуль DBA для генерации сценария синхронизации, который является дополнительной стоимостью. Но я бы сказал, что это стоит того, если вы часто это делаете. (Или, если вы можете заполучить более старую версию Toad, до 9.0, я думаю, есть ошибка, которая позволяет извлечь скрипт синхронизации без модуля DBA.))

Жаба не из дешевых, но использовал его в течение многих лет, я считаю его незаменимым и хорошо ценным для любого разработчика Oracle или администратора баз данных.