Безпечне фіксація даних виробничої бази

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

1. Нам потрібно зареєструвати, хто керував запитом і що вони виконували
2. В ідеалі нам потрібно надати людині доступ лише до запитів проти цікавих таблиць і лише на короткий час
3. Незалежно від запущених запитів, потрібно мати деякі розумні відомості про це, щоб не дозволяти тривалому запуску та блокуванню SQL запускатися без явного дозволу
4. Цей процес повинен бути агностиком БД або принаймні розуміти DB2, Oracle та SQL Server.

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

Ніколи не оновлюйте виробничі бази даних вручну.

Пишіть сценарії.

Потрійно перевіряйте їх, і чимало людей це роблять, а не лише одна людина робить це тричі.

Включіть запити перевірки після зміни змін у цих сценаріях.

Щоразу, коли ситуація дозволяє, протестуйте всю зміну в межах транзакції, яка повертається в кінці, після того, як перевірка після зміни відбулася. Коли ви впевнені в своїх результатах, змініть відкат на фіксацію.

Перевірте ці сценарії з приводу нападів проти тестової бази даних.

Зробіть резервну копію перед запуском сценарію проти виробничої бази даних.

Запустіть сценарії.

Перевірка, перевірка та потрійна перевірка змінених даних за допомогою сценаріїв після зміни валідації.

Зробіть візуальну перевірку в будь-якому випадку.

Якщо щось здається, відключіть і відновіть резервну копію.

Не приступайте до змінених даних як до виробничих даних, поки не будете абсолютно впевнені, що все в порядку, і ви не вийдете із залучених (бізнес) менеджерів.

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

Уявіть такий випадок:

1. У програмному продукті є помилка, яка змушує його припиняти роботу, коли виявляє, що він вважає деякою невідповідністю даних у базі даних,

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

3. Наразі компанія втрачає тисячі доларів на годину (скажімо, 6 000 доларів США, що означає 100 доларів на хвилину),

4. Помилка впливає на кілька таблиць, одна з яких величезна, і стосується лише самих даних, а не схеми,

5. Щоб обійти помилку, слід трохи поекспериментувати з даними, що включає як видалення, так і зміну,

6. База даних велика, і потрібно три години, щоб взяти або відновити резервну копію,

7. Останнє повне резервне копіювання було зроблене три тижні тому; також існують щоденні додаткові резервні копії, і останню щоденну додаткову резервну копію було зроблено 14 годин тому,

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

9. Втрата даних за 14 годин неприйнятна, але втрата даних на одну-дві години -

10. Постановочне середовище востаннє використовувалося півроку тому; здається, це не актуально, і це може зайняти кілька годин,

11. База даних - Microsoft SQL Server 2008 Enterprise.

Чистий спосіб зробити це:

1. Відновити резервну копію в режимі постановки,

2. Експериментуйте,

3. Перевірте остаточний сценарій двічі,

4. Запустіть скрипт на виробничому сервері.

Тільки перший крок обійдеться вашій компанії 18 000 доларів. Ризик досить низький, якщо зробити третій крок бездоганно, але оскільки ви працюєте під надзвичайним тиском, ризик буде набагато більшим. Ви можете закінчити сценарій, який відмінно працював у постановці, а потім накрутите виробничу базу даних.

Натомість ви могли зробити так:

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

2. Експериментуйте безпосередньо на виробничій базі даних, повертаючись до знімка, якщо щось піде не так.

Хоча пурист буде виправляти базу даних чітким способом і все ще матиме ризик викрутити справи, враховуючи часовий тиск, витрачаючи більше 20 000 доларів США на свою компанію, адміністратор бази даних, який враховує обмеження бізнесу, виправить базу даних таким чином що дозволить мінімізувати ризики (завдяки знімкам), виконуючи це швидко.

Висновок

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

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

Безпечне фіксація даних виробничої бази. Який найбезпечніший спосіб зробити це з точки зору великої компанії? Чи є інструменти, які можуть допомогти?

Це погана практика та запрошення для більшої кількості даних та проблем. Існує навіть фраза, яка характеризує такий підхід як " Швидкий і брудний ".

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

Однак помилки будуть там і їх потрібно виправити. Де-факто промисловий стандартом є застосування патчів / (сценаріїв розгортання) на постановник (попередню версію середовища з останньої копією бази даних прода) і нехай аналітик даних / QA для перевірки виправлення. Цей самий сценарій повинен контролюватися версією та застосовуватися до середовища Prod, щоб уникнути проблем.

Існує ряд передового досвіду, згаданих у цій пов’язаній практиці з базою даних після етапу

Хороший набір посилань для перегляду:

• Як швидко ви можете отримати виправлену помилку у виробництві?
• Піраміда витрат на розробку програмного забезпечення
• Скільки часу потрібно відвести на тестування та виправлення помилок

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

Людина, яка пише сценарій оновлення, зробить це під час тесту (відповідно до інших відповідей) і отримає серйозний відхід від нетехнологів (тих, хто знає систему, а також когось із старшими повноваженнями), що функції, здається, "знову знову" крім власного параноїдального тестування. Сценарії та дані будуть незалежно перевірені іншим техніком (часто це роль DBA, яку я згадував) перед тестом, перш ніж запустити у виробництво. Результати перевірятимуться відповідно до очікуваних значень (унікальних для кожного сценарію, але часто такі речі, як кількість рядків тощо)

В одній компанії, над якою я працював, резервне копіювання не було реалістичним варіантом, але всі рядки, які потрібно оновити, списувались до текстового файлу для ознайомлення перед оновленням, а потім знову ПІСЛЯ оновлення, якщо хтось коли-небудь потребує посилання на нього. Сценарії та ці дані зберігаються у правильно організованому Журналі змін даних.

Кожен бізнес унікальний, і ризики оновлення одних даних явно більше, ніж в інших.

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

Бувають випадки, коли потрібно виправити дані на Prod, які не існують на інших серверах. Це не лише від помилок, але може бути імпортом даних із файлу, який клієнт надіслав неправильно, або через проблему, викликану тим, що хтось викрав вашу систему. Або через проблему, спричинену неправильним введенням даних. Якщо ваша база даних велика або критична за часом, можливо, у вас не буде часу на відновлення останньої резервної копії та виправлення на програму dev.

Ваш перший захист (і те, що жодна база даних Enterprise не може дозволити собі без цього!) - таблиці аудиту. Ви можете використовувати їх для запобігання поганим змінам даних. Крім того, ви можете написати сценарії для повернення даних у попередній стан і протестувати їх на інших серверах задовго до того, як вам потрібно буде відновити перевірені дані. Тоді єдиний ризик полягає в тому, що ви визначили правильні записи для відновлення.

Далі всі сценарії для зміни даних про виробництво повинні включати наступні:

Вони повинні мати явні транзакції та мати блок TRY Catch.

У них повинен бути тестовий режим, який можна використовувати для відкату змін після того, як ви побачите, якими вони були б. У вас має бути вибір позиції до внесення змін та один запуск після зміни, щоб переконатися в правильності зміни. Сценарій повинен переконатися, що відображається кількість оброблених рядків. Деякі з них попередньо налаштовані у шаблоні, який гарантує, що деталі будуть готові. Шаблони змін допоможуть заощадити час і на написанні виправлення.

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

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

Нарешті, розробки не повинні запускати ці сценарії. Їм слід керувати dbas або групою управління конфігурацією. Якщо у вас немає жодного з них, права на керування речами повинні мати лише люди, які працюють із технічними технологіями або вище. Чим менше людей працює на продажі, тим простіше відстежити проблему. Сценарії повинні бути написані так, щоб вони були просто запущеними, не виділяючи деталей і виконуючись один за одним. Саме підсвічуючий матеріал часто заважає людям у біді, коли вони забули виділити пункт де.

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

Це також було б дорого (ми подивимось на плечі один одного і, можливо, обговоримо 2 чи 3)

І золоте правило: завжди робіть вибір, щоб показати, що було б зроблено перед тим, як робити операцію оновлення / видалення / вставки

Золоте правило, яке виконують інші двоє людей у ​​команді!

re: відповідь MainMa ...

У програмному продукті є помилка, яка змушує його припиняти роботу, коли виявляє, що він вважає деякою невідповідністю даних у базі даних,

• Звідки ти знаєш, що це "помилка"? Дані суперечать правилам, викладеним розробником програмного продукту.

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

Наразі компанія втрачає тисячі доларів на годину (скажімо, 6 000 доларів США, що означає 100 доларів на хвилину),

• Мабуть, втрата в 100 доларів на хвилину не є достатньо важливою для керівництва компанії, щоб вони знаходили і гарантували, що компетентні розробники повернуться, щоб виправити свою помилку і допоможуть відновити базу даних.

Помилка впливає на кілька таблиць, одна з яких величезна, і стосується лише самих даних, а не схеми,

• Усі проблеми з базою даних "стосуються" схеми. Як розроблена схема - це те, що буде визначати, як ви вирішите цю проблему.

Щоб обійти помилку, слід трохи поекспериментувати з даними, що включає як видалення, так і зміну,

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

База даних велика, і потрібно три години, щоб взяти або відновити резервну копію,

• Тоді вам краще розпочати це відразу, щоб він міг працювати, коли ви аналізуєте проблему, розробляєте свої сценарії виправлення, тестуєте та вдосконалюєте їх разом із розробниками та іншими DBA, які допомагають вам.

Останнє повне резервне копіювання було зроблене три тижні тому; також існують щоденні додаткові резервні копії, і останню щоденну додаткову резервну копію було зроблено 14 годин тому,

• У вас немає щоденних повних онлайн резервних копій? Ви накручені. Але ти, мабуть, звик до цього. Добре, що повна резервна копія, яку ви почали вище, працює. Будьте впевнені, що керівництво відстежує кожну хвилину витрат, яких можна було б уникнути за допомогою щоденних резервних копій в Інтернеті.

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

• Відмінно! Тоді вам, можливо, доведеться не один раз відновлювати базу даних.

Втрата даних за 14 годин неприйнятна, але втрата даних на одну-дві години -

• За описаним вами сценарієм усі ставки знімаються. Це ситуація "управління інформаційними катастрофами". Добре, що менеджмент повинен робити протягом усього цього, - це документування витрат, яких можна буде уникнути в майбутньому за допомогою резервного копіювання prpoer та процедур відновлення та ресурсів.

Постановочне середовище востаннє використовувалося півроку тому; здається, це не актуально, і це може зайняти кілька годин,

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

База даних - Microsoft SQL Server 2008 Enterprise.

• Складніше все це зробити, але не неможливо. Щасти!