Схема схеми SQL Server 2014 змінюється в середовищі користувачів 24/7 для кількох користувачів

У нас встановлено SQL Server 2014 Enterprise для запуску бази даних, яка повинна бути доступною 24/7. Наша база даних величезна (200 Гбіт +). Також у нас є безліч сервісів, які щохвилини потрапляють у нашу базу даних для читання, оновлення або вставки нових даних. Ми хочемо надати «гарячу» функцію повторного використання для наших клієнтів та зробити наші щоденні оновлення (.net та оновлення схеми) прозорими для клієнтів. Ми знайшли рішення, засноване на кластері з балансиром завантаження, щоб оновити бінарні файли нашого додатка, але ми все ще маємо непорозуміння щодо процесу розгортання бази даних та які найкращі практики вирішити цю проблему.

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

Наша загальна схема зміни: додавання / випадання стовпця, додавання / видалення збереженої процедури

Нижче знадобиться трохи більше планування та тестування.

Синьо-зелена концепція:

Суть Blue-Green Concept полягає в тому, щоб розділити ваше виробництво на 2 середовища, і вони завжди однакові (синхронізація даних), де

1. Синій (Поточний) матиме поточну версію схеми / збірки або продукту і буде вашим середовищем "LIVE".

2. У той же час Green буде вашим середовищем для постановки / тестування, в якому ви будете модернізувати свою схему / збірку або продукт до випуску NEXT, пройдете повний тест регресії та підпишитесь на бізнес-користувачів. Коли ви щасливі, під час перерізного періоду ви просуватимете Зелене, щоб воно було вашим "LIVE" середовищем, і знищити Blue, щоб бути попередньою підготовкою / постановкою або тестуванням для наступного випуску.

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

Знову ж таки, це потребує більшого обладнання / ліцензування, а також планування та тестування.

Більшість кроків можна автоматизувати за допомогою DACPAC і PowerShell. Крім того, якщо ви встановлюєте кілька екземплярів на одному сервері, переконайтесь, що перезбалансуйте параметри пам'яті при переключенні між синім та зеленим. Навколишнє середовище LIVE отримує більше пам'яті, ніж пасивне.

У моєму теперішньому середовищі ми впровадили синьо / зелену модель для розгортання кодового коду, яка дозволяє просувати код кожні 2 тижні з достатньою кількістю часу для тестування та виходу з бізнесу. Крім того, його легкий вітер відкатати, якщо щось піде жахливо не так. Ми автоматизували більшість матеріалів розгортання за допомогою Dacpacs та PowerShell.

(Джерело зображення)

Також дивіться статтю Гранта Фрітчі про усунення несправностей; Виклики та стратегії

Якщо ваша база даних не реплікується, стовпці для додавання та падіння будуть запускатися дуже швидко. Тому що додавання стовпця - це лише порожня позиція, яку створює SQL. Стовпчик "Drop" просто видалить посилання.

В іншому випадку, якщо на цьому є якесь обмеження або індекс, будьте обережні.

ADD/DELETEпроцедури якраз будуть впливати на сам виконати. Рекомендація - перед будь-якими змінами на ній запустіть рекомпіляцію

sp_recompile 'myproc'