Як ви змінюєте версію змін у базі даних Oracle?


32

Мені цікаво знати, якими методами користуються інші люди для відстеження змін, внесених до бази даних, включаючи зміни визначення таблиці, нові об’єкти, зміни пакетів тощо. Чи використовуєте ви плоскі файли із зовнішньою системою контролю версій? Тригери? Інше програмне забезпечення?


1
Це дійсно схоже на dba.stackexchange.com/questions/2/… - звідти ви можете отримати деякі ідеї, що не стосуються Oracle!
Гаурав

@Gaurav Я це бачив, але мені хотілося певних відповідей Oracle.
Лей Ріффер

Не те, про що ви просили, а пов’язане з цим: переопределення на основі видання
Джек Дуглас

Відповіді:


22

На сайтах, над якими я працював, будь-які зміни, які необхідно внести у виробничі екземпляри, повинні бути прописані як сценарії зміни, які працюватимуть у SQL * Plus; крім того, сценарії, необхідні для відтворення всіх об'єктів схеми з нуля, повинні постійно оновлюватися. Усі ці сценарії перевіряються на контроль змін та переносяться звідти.

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


1
Моє робоче місце має схожий робочий процес із тим, що згадується тут
Сатьяджит Бхат

10

Я багато думав і читав на цю тему. Це широка тема управління конфігурацією та стратегія управління змінами. 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). Ми поставили їм контроль над джерелами і там підтримували. Я думаю, що спеціально розроблене рішення, як, наприклад, ліквідова база, може працювати краще.

Цей підхід добре працює, якщо є 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. У відповідь2 мені потрібно шукати всі зміни. Також сценарій відповіді 2 у контролі джерела має тенденцію до великого удару, складний сценарій. Важко знайти інформацію.

Відповідь 3 Якщо 3 відповідає дійсності. Зауважте, що в цій ситуації у вас немає обмеження 6, тобто: у вас немає серверів розробки, тестування, продуктів. Тільки сервер виробництва. Ви можете використовувати тригери DDL для реєстрації змін. Це в основному використовується для відсторонення людей від зловживань їх DDL-грантами. Якщо виникає якась проблема, ви можете знайти відповідальність. Для цього кожна людина повинна з'єднатися зі своїм обліковим записом користувача, а обліковий запис програми не повинен мати жодних грантів DDL. Оскільки кожен розробник знає акаунт програми і може ним користуватися.

Відповідь 4 Якщо у вас є 3 і 5. Зауважте, що в цій ситуації у вас немає обмеження 6, тобто: у вас немає серверів розробки, тестування, продуктів. Тільки сервер виробництва. Замість тригера зберігати зміни. Ви використовуєте зовнішній інструмент пошуку змін і зберігаєте сценарії DDL у контролі джерела.

Якщо цей інструмент має можливість записувати, хто змінив, було б корисно. Зауважте, що в цьому рішенні ви втрачаєте додатковий DDL, який робиться з інтервалом.



4

У деяких наших базах даних ми використовуємо тригери DDL для збору змін та збереження їх у таблицю. Потім у нас є веб-інтерфейс, щоб підняти ці попередні версії. Він має серйозні недоліки, саме тому я шукаю альтернативи, але це легко і краще, ніж відсутність контролю версій.


4

Ми використовували Schema Version Control для наших 11g баз даних, але мали проблеми з програмним забезпеченням на 11.2. Якби не ті проблеми, над якими ми все ще працюємо, це був би чудовий продукт.


2

Раніше ми працювали з Oracle SQL Designer, який (я думаю) зараз замінили на SQL Developer Data Modeler. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html

Це було досить приємно, esp. можливість встановити DOMAIN для стовпців і заощадити багато часу, створюючи загальні стовпці (mtime, ctime тощо).


2

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



Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.