SQL Server Доставка колод: Повний посібник для адміністратора баз даних [2026]

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

1.2 Мета та переваги перевезення колод

Доставка журналів виконує кілька важливих функцій в адмініструванні баз даних:

Його основна роль — аварійне відновлення, забезпечення надійного цільового ресурсу для відновлення після збою, коли ваш основний сервер стає недоступним через збій обладнання, пошкодження програмного забезпечення або катастрофічні події, що впливають на ваш центр обробки даних.
Це також економічно вигідно рішення високої доступностіНа відміну від функцій корпоративного рівня, які потребують дорогого ліцензування, доставка журналів працює з SQL Server Стандартна версія, що робить її доступною для організацій з обмеженим бюджетом.
Вторинні бази даних у режимі очікування пропонують додаткову цінність, окрім аварійного відновлення. Адміністратори баз даних можуть використовувати їх для звітності лише для читання, розвантажуючи робоче навантаження запитів з виробничого сервера.
Функція відкладеного відновлення забезпечує захист від випадкових змін даних. Налаштовуючи затримку відновлення, ви створюєте часове вікно для відновлення після помилок користувача, перш ніж руйнівні зміни досягнуть вашої вторинної бази даних.

2. SQL Server Компоненти та робочий процес доставки журналів

Перевезення колод складається з наступних компонентів:

Основний сервер та основна база даних: основний сервер представляє вашу виробничу систему. SQL Server екземпляр, на якому працює основна база даних.
Спільне сховище резервних копій: проміжне місце для зберігання та передачі резервних копій журналу транзакцій з основного сервера на додаткові сервери.
Додаткові сервери та додаткові бази даних: На додаткових серверах розміщуються теплі резервні копії вашої основної бази даних.
Сервер моніторингу (необов'язково): цей сервер відстежує історію та стан усіх операцій резервного копіювання, відновлення та резервного копіювання по всій топології доставки журналів.
Завдання агента: включаючи завдання резервного копіювання, відновлення та оповіщення, автоматизуючи весь процес доставки журналів.

Робочий процес автоматизації такий:

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

3. Передумови та вимоги

3.1 SQL Server Вимоги до версії

Доставка колод доступна з SQL Server 2000 року та залишається підтриманою у всіх наступних версіях з SQL Server 2005–2025 роки. Ця тривала підтримка демонструє стабільність технології та її актуальність.

3.2 SQL Server Вимоги до видання

Доставка журналів працює з версіями Standard, Workgroup, Enterprise та Developer. SQL ServerЦя широка підтримка видань робить доставку журналів доступною для організацій без ліцензій Enterprise Edition, на відміну від таких функцій, як Завжди доступні групи доступності для яких потрібні версії Enterprise або Evaluation.

Примітка: Експрес-версія не підтримує доставку журналів.

3.3 Вимоги до моделі відновлення бази даних

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

Щоб дізнатися більше про моделі відновлення, див. наші вичерпний посібник з SQL Server резервна копія.

4. Налаштування доставки журналів за допомогою SSMS

4.1 Створення папки для спільного резервного копіювання

Перш ніж налаштовувати доставку журналів, підготуйте спільну папку резервних копій, куди будуть зберігатися та передаватись резервні копії журналів транзакцій.

На основному сервері або виділеному файловому сервері створіть папку (наприклад, C:\Резервна копія)
Клацніть папку правою кнопкою миші та виберіть властивості
Натисніть Поділ таб
Натисніть Розширене спільний доступ
перевірити Поділіться цією папкою
Натисніть Дозволи і грант повний контроль дозвіл на SQL Server сервісний рахунок Служба NT\MSSQLSERVER.
Натисніть OK застосовувати.
Задокументуйте мережевий шлях (UNC) (наприклад, \\ІМ'Я-СЕРВЕРА\Резервна копія)

4.2 Увімкнення та налаштування доставки журналів

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

4.2.1 Налаштування параметрів резервного копіювання

Натисніть Налаштування резервної копії button
Перейдіть на вкладку Налаштування резервного копіювання журналу транзакцій діалогове вікно, під Мережевий шлях до папки резервних копій введіть UNC-шлях (наприклад, \\ІМ'Я-СЕРВЕРА\Резервна копія)
Якщо папка резервної копії знаходиться на основному сервері, введіть локальний шлях (наприклад, C:\Резервна копія)
Налаштуйте інші параметри, такі як період зберігання резервних копій, поріг сповіщень, завдання резервного копіювання та стиснення.
Натисніть OK щоб підтвердити налаштування та закрити діалогове вікно.

4.2.2 Налаштування екземпляра вторинного сервера та бази даних

Натисніть додавати під Екземпляри вторинних серверів та бази даних
Перейдіть на вкладку Налаштування додаткової бази даних діалог, клацніть Спілкування для підключення до екземпляра вторинного сервера.
Перейдіть на вкладку Вторинна база даних у розкривному списку виберіть існуючу базу даних або введіть нову назву бази даних
Перейдіть на вкладку Ініціалізація вторинної бази даних вкладка, виберіть Так, створити повну резервну копію основної бази даних та відновити її у вторинній базі даних (і створити вторинну базу даних, якщо вона не існує)
Натисніть Копіювати файли таб
Перейдіть на вкладку Папка призначення для скопійованих файлів (ця папка зазвичай розташована на додатковому сервері), введіть локальний шлях до папки призначення на додатковому сервері.
Переконайтеся, що папка існує, а SQL Server обліковий запис служби має дозволи на запис
Натисніть OK щоб підтвердити налаштування та закрити діалогове вікно.

4.2.3 Налаштування сервера моніторингу

перевірити Використання екземпляра сервера моніторингу
Натисніть Налаштування
Натисніть Спілкування для підключення до екземпляра сервера моніторингу
Установка Видалити історію після вказати термін зберігання в годинах
Натисніть OK щоб підтвердити налаштування та закрити діалогове вікно.

4.2.4 Перегляд та завершення конфігурації

Перегляньте всі налаштування на Доставка журналу транзакцій сторінка
Перевірте налаштування резервного копіювання, конфігурації додаткового сервера та налаштування моніторингу
Натисніть OK застосувати конфігурацію
Майстер створює всі необхідні завдання на основному, додатковому та моніторному серверах.
Натисніть Закрити коли конфігурація завершена

5. Переваги та недоліки перевезення колод

5.1 Переваги SQL Server Доставка журналів

Економічне рішення: Працює з SQL Server Стандартна версія, що усуває вимоги до дорогого ліцензування корпоративної версії. Це робить надійне аварійне відновлення доступним для організацій з обмеженим бюджетом.
Простий у налаштуванні та обслуговуванні: Майстер налаштування допоможе адміністраторам пройти процес налаштування, пропонуючи чіткі параметри. Більшість баз даних можна налаштувати протягом 15-30 хвилин без спеціального навчання.
Підтримка кількох вторинних серверів: Підтримуйте численні вторинні сервери без архітектурних обмежень. Розгорніть один вторинний сервер для локального аварійного відновлення, інший віддалено та третій для звітності.
Мінімальний вплив на основний сервер: Працює асинхронно, що усуває накладні витрати на синхронізацію на основному сервері. Час фіксації транзакцій залишається незмінним.
Використовує існуючі резервні копії журналів транзакцій: Резервні копії доставки журналів – це стандартні резервні копії журналів транзакцій, які можна використовувати для відновлення на певний момент часу незалежно від доставки журналів.
Варіант відкладеного відновлення: Функція затримки відновлення забезпечує захист від випадкових змін даних, недоступних у рішення для реплікації в реальному часі.
Спільне сховище не потрібне: Використовує незалежне сховище на кожному сервері, що усуває вимоги до спільного сховища та пов'язані з ним витрати.
Підтримка між платформою: Працює однаково як у Windows, так і в Linux SQL Server розгортання.
Працює в різних доменах: Не вимагає довірчих відносин домену або інтеграції з Active Directory.

5.2 Недоліки та обмеження перевезення колод

Без автоматичного перемикання на резервний комп'ютер: Основним обмеженням є вимога ручного перемикання на резервний комп’ютер. Адміністратори повинні виконати кілька кроків, перш ніж служба відновить роботу.
Затримка синхронізації даних: Вторинні бази даних завжди відстають від первинних за частотою резервного копіювання та відновлення.
Тільки конфігурація на рівні бази даних: Налаштовує на рівні бази даних, а не на рівні екземпляра. Захист 50 баз даних вимагає 50 окремих конфігурацій.
Ручні зміни рядка підключення: Програми повинні оновлювати рядки підключення, щоб вони вказували на вторинний сервер після відновлення після відмови.
Вторинні переривання бази даних: Вторинні бази даних у режимі очікування відключають користувачів під час операцій відновлення.
Окреме управління базами даних: Кожна конфігурація бази даних повинна керуватися індивідуально без скоординованих можливостей управління.

6. Найкращі практики та варіанти використання

6.1 Коли використовувати доставку колод

Низькобюджетне відновлення після стихійних лих: Чудово підходить як економічно ефективне рішення для аварійного відновлення для організацій, які не можуть виправдати витрати на ліцензування Enterprise Edition.
Помірні вимоги до RPO/RTO: Програми, що витримують 15-30 хвилин втрати даних та 30-60 хвилин простою, ідеально відповідають його можливостям.
Сервер звітності лише для читання: Створюйте копії лише для читання для робочих навантажень звітності, які допускають періодичні відключення.
Середовища стандартної версії: Організації, стандартизовані за SQL Server У Standard Edition немає доступу до груп доступності Always On, що робить доставку журналів найкращим доступним варіантом.
Проекти міграції серверів: Сприяє міграції серверів, підтримуючи синхронізовані копії протягом перехідних періодів.
Вимоги до затриманих даних: Налаштуйте затримки відновлення, щоб бази даних залишалися на фіксованих значеннях у минулому для цілей відповідності вимогам або аудиту.

6.2 Коли НЕ слід використовувати доставку колод

Вимоги до майже нульового простою: Застосунки з вимогами RTO менше 15 хвилин не можуть покладатися на ручне перемикання на резервний режим.
Потрібне автоматичне перемикання на резервний пристрій: Недоречно, коли бізнес-вимоги вимагають автоматичного перемикання на резервний режим без втручання адміністратора.
Необхідна синхронізація в реальному часі: Програми, що потребують даних у режимі реального або майже реального часу на вторинних серверах, не можуть прийняти властиву доставці журналів затримку.
Мінімальна толерантність до втрати даних: Організаціям, у яких RPO вимірюється в секундах або не вимагають втрати даних, потрібні синхронні рішення.

6.3 Найкращі практики

Оптимізація частоти резервного копіювання: Збалансуйте частоту резервного копіювання з системними витратами та цілями відновлення. Почніть з 15-хвилинних інтервалів та коригуйте їх відповідно до фактичних потреб.
Міркування щодо мережевого шляху: Використовуйте UNC-шляхи, а не підключені диски, для розташування резервних копій. Розміщуйте спільні ресурси резервних копій на надійній мережевій інфраструктурі.
Налаштування моніторингу та оповіщення: Налаштуйте сповіщення про збої резервного копіювання, копіювання та відновлення одразу після завершення налаштування доставки журналів.
Графік регулярного тестування: Плануйте щоквартальні або піврічні тести на відновлення після збою для перевірки процедур та підтримки готовності адміністратора.
Ведення документації: Ведіть детальні книги процедур, що документують деталі конфігурації, процедури відновлення після відмови та кроки з усунення несправностей.
Міркування безпеки: Використовуйте виділені службові облікові записи з мінімальними необхідними дозволами. Обмежте дозволи на спільний мережевий ресурс належним чином.
Керування дисковим простором: Постійно контролюйте дисковий простір у резервних копіях. Налаштуйте сповіщення, коли обсяг місця падає нижче 20%.
Конфігурація політики збереження: Встановіть періоди зберігання резервних копій, довші за максимально допустиму затримку синхронізації.
Затримка відновлення для захисту: Налаштуйте затримки відновлення, коли захист від випадкових змін виправдовує збільшення затримки синхронізації.

7. Усунення поширених проблем

7.1 Збої резервного копіювання

Недостатньо дискового простору: Перевірте історію завдань на наявність помилок дискового простору. Перевірте доступний та вільний простір, видаливши старі резервні копії або ввімкнувши стиснення.
Проблеми з дозволом: Перевірте SQL Server Обліковий запис служби має повний доступ як до локальної папки, так і до мережевого ресурсу.
База даних не повністю відновлена: Поверніться до моделі повного відновлення та створіть повну резервну копію, щоб перезапустити ланцюжок журналу транзакцій.

7.2 Невдалі завдання копіювання

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

7.3 Відновлення невдалих завдань

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

7.4 Проблеми із затримкою синхронізації

Обмеження пропускної здатності мережі: Увімкніть стиснення резервних копій, щоб зменшити розміри файлів і вимоги до пропускної здатності.
Високий обсяг транзакцій: Розгляньте можливість збільшення частоти резервного копіювання, щоб створювати менші та зручніші для керування файли резервних копій.
Недостатня частота відновлення: Збільште частоту завдань відновлення приблизно до частоти резервного копіювання та мінімізуйте затримку.

7.5 Проблеми з підключенням до сервера моніторингу (SQL 2025)

Помилки постачальника OLE DB: SQL Server Обов'язкове шифрування за замовчуванням у версії 2025 конфліктує зі старими екземплярами, яким бракує належної конфігурації шифрування.
Невідповідність конфігурації шифрування: Перевірте конфігурацію підключеного сервера на сервері монітора та налаштування шифрування.
Рішення для тимчасового вирішення проблеми: Видалити та повторно створити доставку журналів за допомогою параметрів TLS 1.3 або оновити всі екземпляри до SQL Server 2025.

7.6 SQL Server Проблеми з обслуговуванням агента

Послуга не розпочата: Перевірте стан служби агента та налаштуйте її автоматичний запуск.
Графік завдань вимкнено: Перевірте стан розкладу завдань та увімкніть вимкнені розклади.
Невдалі кроки завдання: Перегляньте історію завдань, щоб виявити кроки, що завершилися невдачею, та конкретні повідомлення про помилки.

8. Поширені запитання (FAQ)

З: Чи можу я використовувати доставку журналів з Express Edition?

A: Ні, SQL Server Експрес-версія не підтримує доставку журналів, оскільки їй бракує SQL Server Агент.

З: Як часто слід планувати резервне копіювання журналів?

В: Стандартні 15-хвилинні інтервали забезпечують достатній баланс. Відрегулюйте їх відповідно до вашої цільової точки відновлення.

З: Чи можна використовувати вторинні бази даних для звітності?

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

З: Що станеться, якщо основний сервер вийде з ладу?

A: Виконайте ручне перемикання на резервний комп’ютер, щоб перевести вторинну базу даних в онлайн-режим. Втрата даних дорівнює затримці синхронізації під час збою.

З: Чи можу я мати кілька вторинних серверів?

В: Так, доставка журналів підтримує необмежену кількість вторинних серверів з незалежними конфігураціями.

З: Як розрахувати затримку синхронізації?

A: Порівняйте останню відновлену позначку часу журналу транзакцій з поточним часом, використовуючи таблиці моніторингу доставки журналів.

З: Чи може доставка журналів працювати між різними доменами?

В: Так, це працює в різних доменах або в робочих групах без необхідності довірчих відносин.

З: Яка різниця між режимом «Без відновлення» та режимом очікування?

A: Жоден режим відновлення не робить базу даних доступною. Режим очікування дозволяє запити лише для читання між відновленнями.

З: Чи можу я тимчасово призупинити доставку журналів?

A: Так, вимкніть завдання резервного копіювання, копіювання та відновлення, щоб призупинити синхронізацію, зберігаючи конфігурацію.

З: Як видалити конфігурацію доставки журналів?

A: У Доставка журналу транзакцій сторінка власності:

Зніміть прапорець Увімкнути це як основну базу даних у конфігурації доставки журналів
Натисніть OK щоб видалити конфігурацію та завдання.

З: Чи можна перевести вторинну базу даних у режим читання та запису?

A: Так, виконайте команду RESTORE DATABASE WITH RECOVERY, але це порушить ланцюжок доставки журналів.

З: Яку максимальну затримку можна налаштувати для відновлення?

В: Жорстких обмежень немає. Налаштуйте затримки від хвилин до днів залежно від ваших вимог до захисту.

З: Як доставка журналів впливає на стратегію резервного копіювання?

A: Він створює резервні копії журналів транзакцій, які можна використовувати як для доставки журналів, так і для відновлення в певний момент часу.

З: Чи можу я використовувати доставку журналів для міграції сервера?

A: Так, налаштуйте доставку журналів на новий сервер, синхронізуйте, а потім виконайте планове перемикання на резервний старий сервер під час технічного обслуговування.

З: Які інструменти моніторингу працюють із доставкою журналів?

A: SQL Server Management Studio містить вбудовані звіти. Сторонні інструменти, такі як SQL Monitor та SolarWinds, забезпечують розширений моніторинг.

9. Висновки та рекомендації

9.1 Резюме ключових положень

SQL Server Доставка журналів забезпечує надійне та економічно ефективне аварійне відновлення завдяки автоматизованим операціям резервного копіювання та відновлення журналів транзакцій. Технологія працює зі Standard Edition, вимагає мінімальної інфраструктури та підтримує кілька вторинних серверів.

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

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

9.2 Зробіть правильний вибір для вашого середовища

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

Організації, що використовують SQL Server Стандартній версії з помірними вимогами до відновлення слід серйозно розглянути доставку журналів. Підприємствам зі суворим часом відновлення менше 15 хвилин слід оцінити групи доступності Always On.

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

9.3 Наступні кроки та додаткові ресурси

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

Плануйте регулярні тести на відновлення після збою, щоб перевірити процедури та підтримувати готовність адміністратора. Будьте в курсі подій SQL Server оновлення та вдосконалення.

Посилання

Офіційний документ Microsoft: Про доставку колод (SQL Server)
Офіційний документ Microsoft: Налаштувати доставку журналів (SQL Server)

Про автора

Юань Шен є старшим адміністратором баз даних (DBA) з понад 10-річним досвідом роботи в SQL Server середовища та управління корпоративними базами даних. Він успішно вирішив сотні сценаріїв відновлення баз даних у фінансових службах, охороні здоров'я та виробничих організаціях.

Юань спеціалізується на SQL Server відновлення баз даних, рішення для забезпечення високої доступності та оптимізація продуктивності. Його великий практичний досвід включає управління багатотерабайтними базами даних, впровадження груп доступності Always On та розробку автоматизованих стратегій резервного копіювання та відновлення для критично важливих бізнес-систем.

Завдяки своїй технічній експертизі та практичному підходу, Юань зосереджується на створенні комплексних посібників, які допомагають адміністраторам баз даних та ІТ-фахівцям вирішувати складні SQL Server ефективно вирішує проблеми. Він слідкує за останніми новинками SQL Server випуски та технології баз даних Microsoft, що розвиваються, регулярно тестуючи сценарії відновлення, щоб переконатися, що його рекомендації відображають найкращі практики реального світу.

Є запитання щодо SQL Server відновлення чи потрібні додаткові інструкції з усунення несправностей бази даних? Юань вітає відгуки та пропозиції для покращення цих технічних ресурсів.