Який ваш робочий процес для планування міграції даних?

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

Схоже, щоразу, коли це одноразовий сценарій, стріляй із стегна, найкраще вгадай. Я відчуваю, що це моя найслабша майстерність, встановлена ​​як DBA.

Я хотів би познайомитися з деякими моделями підходу, управління та тестування міграцій даних .

Будь ласка, підкажіть мене про деякі найкращі практики та / або де я можу отримати навчальний матеріал, щоб допомогти мені покращитись у цій галузі.

Кожен раз, коли я це робив, ми проходили два проходи ...

1. зробіть знімок та працюючи на іншому сервері, використовуйте це, щоб визначити, що потрібно зробити для міграції, та скриптуйте його.
2. Після того, як вони матимуть скрипт у руці, знімковий майданчик буде відновлений у тестовій системі, і він приурочений до того, щоб перевірити, чи запуститься він протягом необхідного часу, або він буде налаштований та змінений, поки не зможе.
3. відмовитись від зацікавлених сторін, що нічого не здається з даними тестової системи.

Потім у вихідні у вас запланований відключення:

1. У п’ятницю ввечері системи, які використовують базу даних, збиваються, робиться повна холодна резервна копія, і сценарії запускаються для міграції / зміни / будь-яких даних
2. Системи повертаються під якоюсь приватною адресою або якимось чином налаштовуються, щоб вони не були відкриті для тестування прийняття будь-кого, окрім зацікавлених сторін
3. Якщо зацікавлені сторони схвалюють, система розміщується в Інтернеті та оприлюднюється; якщо ні, то база даних відновлюється із резервної копії, зробленої в ніч на п'ятницю, і ви запускаєте процес заново.

Згідно з нашим графіком, у базі даних люди, як правило, з 6 вечора в п’ятницю до 10 ранку в суботу, щоб запускати сценарії резервного копіювання та міграції, тому наша мета полягала в тому, щоб вони працювали за 8 годин (~ 6 з цього було резервне копіювання), тому ми ' Буде якийсь час для тестування та виправлення, перш ніж воно буде випущено для зацікавлених сторін.

Зацікавлені сторони отримали свої часові вікна заздалегідь, тому вони знали залишити свої вихідні відкритими для тестування на початку вікна. Їм також би сказали в кінці свого вікна, як правило, в неділю вдень, коли, якби всі не підписалися, нам доведеться почати відкочувати назад.

О, і звичайно ... якщо хтось змінився під час будь-якого з тестів на прийняття, і ми внесли зміни, це означало, що всі підписи зацікавлених сторін були анульовані, і вони повинні були повторно перевірити ... так ми б спробували приділити їм весь час пошук проблем і запустити будь-які виправлення як пакет, а не застосовувати їх по черзі.

На щастя, в тій ситуації, коли ми не могли мати значного простою, лише тоді, коли я мігрував, подавались із сценаріїв, а не з користувачем, тому я міг просто дві паралельні системи і замінити їх коли речі підписалися. (тільки колись була проблема, коли мій начальник наполягав на тому, щоб ми здійснили повну резервну копію, не розуміючи, що вся справа все ще буде в Інтернеті під іншим IP-адресом ... тож, що повинно було бути відключенням 5 хв на поганий день став відключенням 5 годин.)

Все залежить від обсягу даних порівняно з потужністю обладнання, яке підтримує базу даних, та домовленостей щодо наявності системи. Чи трапляється у вас простої або все це потрібно робити в Інтернеті? Почніть чистити дані, максимально витираючи застарілі рядки. Це сам проект. Якщо дані чисті та цінні, користувач повинен вирішити питання про час простою. Якщо простої є, це досить просто, якщо це відома трансформація, яку слід застосувати до наявних даних для формування оновленої колекції. Якщо простоїв немає - або дуже мало - дозволений пробіг починається. Oracle підтримує це кількома способами, як переопределення онлайнових таблиць і - нове в 11g - переосмислення на основі видання. Завдяки переопределенню онлайн-таблиць ви можете підготувати таблиці до їх нової форми. Це можна зробити під час роботи програми на старій формі таблиці [s]. Якщо вони готові, ви можете перейти до нової форми таблиці [s]. Це також буде момент введення нового коду програми та водночас означає початок простоїв, необхідних для встановлення нової програми. Старіші історичні дані можуть бути підготовлені до того, як живі дані мігруватимуть і синхронізуються за допомогою таких інструментів, як Oracle Golden Gate. У такому сценарії ви ефективно будуєте нову базу даних, яка бере на себе роль старої бази даних. Перевизначення на основі видання краще підходить, якщо не потрібно змінювати таблиці. Є багато варіантів, які слід розглянути, і я думаю, що важко дати хороше правило, яке завжди працює. Це також буде момент введення нового коду програми та водночас означає початок простоїв, необхідних для встановлення нової програми. Старіші історичні дані можуть бути підготовлені до того, як живі дані мігруватимуть і синхронізуються за допомогою таких інструментів, як Oracle Golden Gate. У такому сценарії ви ефективно будуєте нову базу даних, яка бере на себе роль старої бази даних. Перевизначення на основі видання краще підходить, якщо не потрібно змінювати таблиці. Є багато варіантів, які слід розглянути, і я думаю, що важко дати хороше правило, яке завжди працює. Це також буде момент введення нового коду програми та водночас означає початок простоїв, необхідних для встановлення нової програми. Старіші історичні дані можуть бути підготовлені до того, як живі дані мігруватимуть і синхронізуються за допомогою таких інструментів, як Oracle Golden Gate. У такому сценарії ви ефективно будуєте нову базу даних, яка бере на себе роль старої бази даних. Перевизначення на основі видання краще підходить, якщо не потрібно змінювати таблиці. Є багато варіантів, які слід розглянути, і я думаю, що важко дати хороше правило, яке завжди працює. Старіші історичні дані можуть бути підготовлені до того, як живі дані мігруватимуть і синхронізуються за допомогою таких інструментів, як Oracle Golden Gate. У такому сценарії ви ефективно будуєте нову базу даних, яка бере на себе роль старої бази даних. Перевизначення на основі видання краще підходить, якщо не потрібно змінювати таблиці. Є багато варіантів, які слід розглянути, і я думаю, що важко дати хороше правило, яке завжди працює. Старіші історичні дані можуть бути підготовлені до того, як живі дані мігруватимуть і синхронізуються за допомогою таких інструментів, як Oracle Golden Gate. У такому сценарії ви ефективно будуєте нову базу даних, яка бере на себе роль старої бази даних. Перевизначення на основі видання краще підходить, якщо не потрібно змінювати таблиці. Є багато варіантів, які слід розглянути, і я думаю, що важко дати хороше правило, яке завжди працює.

Це цікава тема, Рональд.

Хороших відповідей поки що. Я додам ще пару пунктів для розгляду.

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

• Підрахунок записів у відносно оброблених записів.
• Виявляйте помилки під час трансформації та обробляйте їх таким чином, що дозволяє продовжувати трансформацію та дозволяє повторно обробляти "погані" записи, коли ви виявили виправлення.
• Кількість записів повинна включати "погані" записи - тобто записи-в = записи-поза-хороші + погані-записи
• Якщо ваша трансформація змінює кількість записів (наприклад, один запис вводу стає більше, ніж один вихідний запис), можливо, передбачити кількість вихідних записів, які ви закінчите, а потім протестуйте результати на цей рахунок.

Інший момент, який я додам, полягає в тому, що важливо мати план того, що ви збираєтеся робити, якщо / коли справи йдуть не так, як планувалося. Це дійсно функція розгортання в цілому, але це, здається, заскленене досить часто, що я вважав, що варто згадати.

Огляд того, як це зробити

Щоб почати з

• У вас є база даних "після" в тесті / UAT / будь-якій "робочій БД"
• У вас є база даних "до" у виробництві. Тому використовуйте його для створення копії виробництва десь = "довідкова база даних". І інший як "тест скриптів DB"
• Я також сподіваюся, що у вас є маса сценаріїв розвитку з вашими ALTERs і т. Д. Якщо це так, інша копія виробництва зі своїм сценарієм розробки застосована, чисто і в порядку, корисна = "змінити БД"

Далі, внизу Red Gate Порівняйте інструменти або щось на зразок Embarcadero SQL Change Manager . Ви не можете легко мігрувати без нього. Вартість банальна за кількість заощадженого часу. І найголовніше, що створені сценарії вносять зміни в одну транзакцію, що означає чисте розгортання

Тепер,

• генерувати сценарії зміни та відкату за допомогою інструментів, що порівнюють між "посиланням" та "зміною"
• застосувати сценарій зміни до "тесту сценарію" і порівняти назад до "робочої БД"
• застосувати сценарій відкату до "тесту сценарію" та порівняти "до" та порівняти назад до "робочої БД"

Тепер у вас є безпечні + перевірені сценарії змін і відкатів, які потрібно застосовувати щоразу.

І звичайно, ви створюєте резервну копію бази даних перед будь-якими змінами, оскільки статистично лайно завжди буде в кінцевому підсумку.

Інструменти Red Gate також можуть порівнювати з папкою, яка знаходиться під контролем джерела. Потім ми фіксуємо ALTERs і т. Д. В нашому джерелі управління окремо до фактичних сценаріїв змін.