Sql server: фрагментованість резервних копій і агенти читання журналів

Відео: Як створити архівувати та відновлення системних баз даних в SQL Server 2014

У процесі створення груп доступності AlwaysOn ви можете задати налаштування резервних копій. Це можна зробити і після формування групи доступності- клацніть правою кнопкою миші на відповідній групі доступності, в меню, що розкрилося виберіть пункт Properties і перейдіть на вкладку Backup Preferences.

І хоча окремі аспекти цих налаштувань можуть здатися дещо незрозумілими - в усякому разі, спочатку, насправді їх установка досить проста. Настільки проста, що відповідної документації, підготовленої фахівцями Microsoft, цілком достатньо для огляду наявних варіантів. Втім, тут є два «підводних камені». Перший «підводний камінь» - ліцензії. Хоча підготовлена корпорацією Microsoft документація по засобам управління настройками резервних копій, що входять до складу груп доступності AlwaysOn баз даних, досить докладна, в ній нічого не говориться про те, що для реалізації більшості пропонованих варіантів необхідно купувати додаткові ліцензії і. Іншими словами, якщо ви створюєте «просту», що складається з двох вузлів і призначену виключно для забезпечення високого ступеня готовності групу доступності (тоді, до речі, в ряді ситуацій видається більш логічним використовувати рішення FCI), єдиний параметр, який ви фактично зможете вказати, - це Primary. Вибравши його, ви тим самим заявите про своє бажання генерувати резервні копії на сервері або для сервера, де размешается основна репліка. Будь-який інший варіант буде цілком обгрунтовано віднесений до категорії сценаріїв розгортання, а для підтримки операцій розгортання вам потрібна додаткова ліцензія. Таким чином, якщо ви роздумуєте про те, щоб розвантажити свій основний сервер і перенести процес резервування з нього на додатковий сервер для перерозподілу навантаження, майте на увазі, що це цілком можливий варіант. Але в даному випадку мова не йде про просте сценарії забезпечений і я відмовостійкості, і, отже, положення про ліцензування типової програми Software Assurance, що передбачають «безкоштовну» ліцензію відмовостійкості або хост на кожен повністю ліцензований основний / активний хост, на цю ситуацію не поширюються.

Другий «підводний камінь» полягає в тому, що настройки не виконують ніякої роботи. Перейшовши на вкладку Backup Preferences (або діючи безпосередньо засобами мови T-SQL), ви можете чаклувати над настройками з ранку до вечора, проте ніщо з того, що ви зробите, не зможе спонукати SQL Server ні підкоритися вашим вказівкам, ні навіть виконати якусь або перевірку.







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

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


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