Перенос базы данных Oracle с приложенным к ней приложением C#: как управлять миграцией базы данных?

Question

У меня есть приложение C#, которое работает с базой данных Oracle и уже отправлено. Теперь пришло время отправить новый выпуск. Объектная модель C# была пересмотрена и оказала влияние на структуру таблицы.

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

Чтобы устранить эту проблему, я собрал SQL-скрипты, которые изменят ранее выпущенную структуру базы данных на новую структуру базы данных. В ходе этого также переносятся данные. Сценарии SQL привязаны к репозиторию, подобному исходному коду C#. Патч базы данных тестируется на регулярной основе с помощью CruiseControl.NET. Тесты NUnit выполняются против исправленной базы данных, чтобы выявить несоответствия между таблицами базы данных и объектной моделью C#.

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

На прошлой неделе я споткнулся LiquiBase и я спросил себя - а теперь в SO:

Какие инструменты или методы могут помочь сделать миграцию базы данных с меньшими рисками и больше доверия? Есть ли хорошие книги или интернет-ресурсы?

Меня особенно интересуют конкретные решения для C# и Oracle, которые могут вписываться в процедуру разработки, описанную выше.

Answer 1

Database сценарии должен быть частью процесса разработки. Вот один из способов отслеживания о базе данных обновления схемы:

• создать VERSION таблицу в базе данных, которая содержит одну запись с номером версии
• каждый раз, когда вы делаете изменения в схеме базы данных вашего приложения вам необходимо:
  • создать SQL-скрипт для создания, изменения или удаления объектов базы данных
  • создать SQL-скрипт для управления изменениями данных, которые должны выполняться с помощью новой схемы данных (например, вставлять значения по умолчанию в новые поля, вставлять записи по умолчанию в новые таблицы, создавать сценарии для разделения или слияния ле ...) версия базы данных
  • прироста число
    • Для каждого изменения я обычно создаю один сценарий с именем DbVerXXXX.SQL, который содержит все необходимые обновления (XXXX это номер версии). Кроме того, я делаю изменения в небольших шагах - измените схему БД только для следующего изменения, которое вы будете делать в своем приложении. Не создавайте обновление базы данных, которое займет недели или месяцы работы для обновления вашего приложения.
• создать скрипт, который будет обновить базу данных вашего пользователя в новую версию:
  • скрипт должен проверить текущую версию базы данных, а затем выполнить обновление базы данных сценариев, которые будут преобразовывать схемы до требуемого уровня
  • изменения номер версии в версии таблице

Это проц сс позволяет:

• положить все изменения схемы базы данных в системе управления версиями, поэтому у вас есть полная история изменений
• попробовать и проверить свои сценарии обновления на тестовых базах данных, прежде чем отправить его клиенту
• автоматически с уверенностью обновлять пользовательские базы данных

Answer 2

Возможно, вы захотите ознакомиться с некоторыми имеющимися там технологиями избыточности базы данных, такими как Oracle Dataguard. Я считаю, что в нем, в частности, есть некоторые функции, которые могут помочь в этом типе сценариев.

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

Answer 3

Чтобы убедиться, что вы не теряете данные при изменении базы данных, вы можете создавать сценарии, чтобы скрыть новую структуру, а старая - с теми же логическими данными.Например, скажем, версия 1 базы данных выглядит следующим образом (псевдо-код)

CREATE TABLE Customer 
CustomerID INT, 
FirstName string, 
Surname string, 
AddressLine1 string, 
AddressLine2 string, 
AddressLine3 string, 
AddressLine4 string 

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

CREATE TABLE Address 
AddressID INT, 
CustomerID INT, 
AddressLine1 string, 
AddressLine2 string, 
AddressLine3 string, 
AddressLine4 string 

вы перемещаете адреса из таблицы клиентов в новую адресную таблицу, как это:

INSERT Address 
CustomerID , 
AddressLine1 , 
AddressLine2 , 
AddressLine3 , 
AddressLine4 

SELECT 
* 
FROM Customer 

Затем удалите лишние поля адреса от клиента:

ALTER TABLE Customer 
DROP COLUMNS 
AddressLine1 , 
AddressLine2 , 
AddressLine3 , 
AddressLine4 

Пока все хорошо. Но откуда я знаю, что новая таблица адресов содержит те же адреса, что и таблица старого клиента. Было бы очень легко запустить весь процесс и каким-то образом скремблировать адрес, чтобы клиенты эффективно меняли адреса друг с другом. Код может проходить все тесты, но мы уничтожим данные наших клиентов, поскольку они больше не знают, где живут их клиенты.

Мы можем подтвердить перемещение адресных полей работают, запустив

Если это возвращает какую-либо запись, то обновление не удалось, потому что некоторые клиенты не получили их адрес поколеблется:

SELECT 
* 
FROM 

    OldCustomerTable OCT LEFT JOIN Address A 
    ON OCT.CustomerID = A.CustomerID 
WHERE 
    A.CustomerID IS NULL 

Если это возвращает любое запись, обновление не удалось, потому что адреса были подняты

SELECT 
    * 
FROM 
OldCustomerTable OCT INNER JOIN Address A 
    ON OCT.CustomerID = A.CustomerID 
WHERE 
    OCT.Address1 != A.Address1 
    OR OCT.Address2 != A.Address2 
    OR OCT.Address3 != A.Address3 

ИЛИ OCT.Address4! = A.Address4

Вы можете дополнительно проверить, что новый адрес таблица содержит только 1 адрес для каждого клиента обновления

SELECT 
CustomerID 
, COUNT(AddressID) 
FROM 
Address 
GROUP BY 
CustomerID 
HAVING 
COUNT(AddressID) >1 

Answer 4

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

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

Отъезд:

• Autopatch
• Ответы на this question
• Ответы на this question

Вы также могли бы рассмотреть идеи этих инструментов и развить свой собственный.