Как вы изменяете свою базу данных Oracle?

Мне интересно узнать, какие методы используют другие люди для отслеживания изменений, внесенных в базу данных, включая изменения в определениях таблиц, новые объекты, изменения пакетов и т. Д. Используете ли вы плоские файлы с внешней системой управления версиями? Триггеры? Другое программное обеспечение?

На сайтах, над которыми я работал, любые изменения, которые необходимо внести в производственные экземпляры, должны быть написаны как сценарии изменений, которые будут работать в SQL * Plus; Кроме того, необходимо постоянно обновлять сценарии, необходимые для воссоздания всех объектов схемы с нуля. Все эти скрипты проверяются на контроль изменений и переносятся оттуда.

Вы можете проверять изменения DDL или использовать триггеры DDL, чтобы получить изменения, или даже использовать программное обеспечение сравнения для сравнения двух экземпляров, но эти методы неразборчивы; часто разработчик вносит и отменяет ряд изменений в схеме (например, небольшие тестовые изменения, создание фиктивных таблиц для проверки концепций и т. д.), прежде чем решить, что именно нужно изменить.

Я много думал и читал на эту тему. Это широкая тема контроля конфигурации и стратегии управления изменениями. У CMMI есть домен в этой теме. Даже в компаниях, имеющих аккредитацию CMMI 3-5, они иногда не осуществляют контроль версий своих баз данных.

На этот вопрос следует ответить, учитывая следующие ограничения .

1. У вас есть хранитель, и каждый DDL выполняется этим хранителем.
2. Другие люди имеют возможность выполнять операторы DDL.
3. Вам нужно только регистрировать, какие изменения были сделаны, но вам не нужно сравнивать огромные различия.
4. Ваш дизайн базы данных выполняется с помощью внешнего инструмента, а затем публикуется в базе данных. Этот внешний инструмент может быть даже сценариями DDL в системе контроля версий. Но ключевым моментом является то, что вы контролируете это, а затем публикуете в базу данных
5. Вам не нужно знать мгновенные изменения, но время от времени: то есть ежечасно, ежедневно.
6. У вас есть определенная структура сервера: разработка, тестирование, производство. И хорошая стратегия тестирования.

Ответ 1

• если 1, 4,6 - истина, то вы можете использовать внешний источник контроля. Например
  • Embercadero имеет инструмент управления изменениями базы данных ( http://www.embarcadero.com/products/db-change-manager-xe ). Который имеет возможность перепроектировать базу данных (Oracle) и поместить ее в систему контроля версий. Тогда любое количество разработчиков, dba, может достичь этой схемы и внести в нее изменения.
  • Oracle SQL Designer похож на этот подход.
  • Помещение созданных вами табличных сценариев в систему управления версиями (svn, mercurial и т. Д.) И их обслуживание тоже самое.
  • http://www.liquibase.org - это автоматизированный подход, описанный выше.
  • Я написал генератор кода, который генерировал операторы DAL (Data Access Layer), DDL (Create Table). Мы поставили им контроль источников и поддерживали там. Я думаю, что специализированное решение, такое как liquibase, может работать лучше.

Этот подход хорошо работает при наличии 6. Вы помещаете операторы DDL, которые также являются кодом, в систему контроля версий и сохраняете их. Никто не будет менять Тестовый и Производственный серверы без должного рассмотрения.

Недостатком является то, что по какой-либо причине вы вносите какие-либо изменения в рабочие или тестовые серверы, быстро исправляете ошибку, изменяете первичный ключ и т. Д. Вам также необходимо откатить эти изменения на сервере разработки. Так как на самом деле Сервер разработки - это ваша ОСНОВНАЯ ПРАВДА. Не наоборот.

Это очень ориентированный на разработчиков подход. Но когда вы впервые разрабатываете новый модуль, он работает довольно хорошо.

Ответ 2 - если 1 и 6 верны:

Подобный подход к ответу 1 - поддержка сервера разработки. Каждый использует это, меняет это. Чем когда придет время обновлять. Вы используете инструмент сравнения баз данных. Получите их как скрипты, поместите под контроль исходного кода.

- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)

Разница между ответом 1 и ответом 2 заключается в том, что в ответе 1 вы собираете операторы DDL для всей базы данных и сохраняете их. В ответе 2 вам необходимо сохранить каждую версию изменений.

1. Начало
2. V1
3. V2
4. V3
5. ...

Если вы поместите столбец в таблицу, а затем решите удалить его. Ваши сценарии покажут это в answer2, а в answer1 вы увидите только последнюю версию. И вам нужно сравнить V2 и V1, чтобы увидеть различия. Лично мне больше нравится ответ 1, так как я могу легко сравнить Start и V3, V1 и V3. В answer2 мне нужно искать все изменения. Также в ответе 2 скрипт в системе управления версиями имеет тенденцию быть сложным и сложным. Трудно найти информацию.

Ответ 3 Если 3 верно. Обратите внимание, что в этой ситуации у вас нет ограничения 6, то есть: у вас нет серверов разработки, тестирования, продуктов. Только рабочий сервер. Вы можете использовать триггеры DDL, чтобы регистрировать, какие изменения были сделаны. Это в основном используется, чтобы отговорить людей от злоупотребления своими грантами DDL. Если возникнет какая-либо проблема, вы можете найти ответственного. Чтобы это работало, каждый человек должен соединиться со своей учетной записью пользователя, а учетная запись приложения не должна иметь никаких грантов DDL. Так как каждый разработчик знает аккаунт Приложения и может им пользоваться.

Ответ 4 Если у вас есть 3 и 5. Обратите внимание, что в этой ситуации у вас нет ограничения 6, то есть: у вас нет серверов разработки, тестирования, продукта. Только рабочий сервер. Вместо триггера для сохранения изменений. Вы используете внешний инструмент для поиска изменений и сохранения сценариев DDL в системе контроля версий.

Если этот инструмент имеет возможность записывать, кто сделал изменения, это было бы полезно. Обратите внимание, что в этом решении вы теряете дополнительный DDL, который делается с интервалами.

Только что нашел интересное руководство по использованию Liquibase для версии Oracle.

В некоторых наших базах данных мы используем триггеры DDL, чтобы ловить изменения и сохранять их в таблице. Затем у нас есть веб-интерфейс для загрузки этих предыдущих версий. У него есть серьезные недостатки, поэтому я ищу альтернативы, но это легко и лучше, чем отсутствие контроля версий.

Мы использовали Schema Version Control для наших баз данных 11g, но у нас были некоторые проблемы с программным обеспечением на 11.2. Если бы не те проблемы, над которыми мы все еще работаем, это был бы отличный продукт.

Мы привыкли работать с Oracle SQL Designer, который (я думаю) был заменен на SQL Developer Data Modeler. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html

Это было довольно мило, особенно возможность устанавливать DOMAIN для столбцов и экономить много времени на создании общих столбцов (mtime, ctime и т. д.).

Мы используем набор инструментов oracle-ddl2svn (автором которого я являюсь) для автоматизации хранения схемы Oracle DDL в SVN.

Взгляните на DBmaestro TeamWork, который использует подход к управлению изменениями в своей базе данных .

_{раскрытие: я работаю на dbMaestro}

Я никогда не использовал его, но http://blog.gitora.com/ это еще один вариант.