Плани обслуговування

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

Переваги планів обслуговування

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

Плани обслуговування SQL Server надають такі функції:

• Створення робочого процесу з використанням різноманітних типових завдань обслуговування. Ви також можете створити власні скрипти користувача Transact-SQL.
• Концептуальні ієрархії. Кожен план дозволяє створювати та редагувати робочий процес. Завдання у кожному плані можна згрупувати у вкладені плани, яким можна призначити запуск різні моменти часу.
• Підтримка багатосерверних планів може використовуватися серед головного або цільового сервера.
• Підтримка ведення журналів планів на віддалених серверах.
• Підтримка автентифікації Windows та автентифікації SQL Server. По можливості використовуйте автентифікацію Windows.

Функціональні можливості плану обслуговування

Плани обслуговування можна створювати для виконання таких завдань.

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

Результати, отримані в задачах обслуговування, можна записувати у вигляді звіту в текстовий файл або таблиці плану обслуговування ( sysmaintplan_log і sysmaintplan_logdetail ) в msdb . Щоб переглянути результати у засобі перегляду файлів журналу, клацніть правою кнопкою миші плани обслуговування та виберіть пункт "Перегляд журналу".

Наступні кроки

Сервісне обслуговування, частина 6: створення плану обслуговування SQL

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

Autodesk рекомендує виконувати такий план у неробочий час хоча б раз на тиждень.

У середовищі пов'язаних робочих груп виконання плану має бути налаштовано кожному сервері SQL Server.

До завдань адміністраторів має входити регулярна перевірка успішного виконання плану.

Якщо план був налаштований для попередньої версії сервера сховища, переконайтеся, що план перевірено та оновлено відповідно до цієї статті.

Наступні кроки є універсальними для всіх версій SQL, які використовуються в Vault Server (SQL Express та Full SQL). Повний перелік систем управління базами даних, що підтримуються, представлений у файлі ознайомлювальних відомостей.

Примітка: Зверніть увагу, що якщо використовується SQL Express без SQL Management Studio, можна виконати такі кроки в командному рядку за допомогою сценаріїв, описаних у розділі «Створення сценарію обслуговування для Microsoft SQL Express», або можна встановити SQL Management Studio for Express, доступний на веб-сайті Microsoft.

1. Увійдіть у SQL Management Studio.
2. Розгорніть вузол «Бази даних» та «Системні бази даних».
3. Клацніть правою кнопкою tempdb і виберіть пункт Властивості.
4. Виберіть сторінку файлів.
5. У разі використання багатоядерної системи слід налаштувати додаткові файли даних за допомогою інструкції нижче. Під час використання одноядерної системи можна перейти до кроку D нижче.
   1. Кількість файлів даних має відповідати кількості доступних логічних/віртуальних процесорів. Наприклад, якщо на комп'ютері встановлено 12 логічних процесорів, то має бути присутнім 1 файл MDF і 11 файлів NDF. Якщо обмежений обсяг вільного простору, замість 1024 МБ можна використовувати розмір 512 МБ. Примітка. При використанні SQL 2016 або пізнішої версії кількість файлів даних за замовчуванням буде менше 8 або відповідатиме кількості логічних ядер, визначеній при налаштуванні. У разі потреби значення може бути збільшено з урахуванням вимог конкретного робочого навантаження. Імена додаткових файлів даних будуть відповідати угоді про ім'я tempdb_mssql_#.ndf, де # означає порядкове число кожного доданого файлу.
   2. Щоб додати додаткові файли даних, натисніть кнопку «Додати» .
   3. За потреби надайте новим файлам імена temp2, temp3 і т.д.
   4. Вкажіть розмір кожного файлу даних — 1024 МБ. Якщо використовується лише 8 файлів даних, можна використовувати значення 512 МБ.
   5. Встановіть для параметра «Авторозширення» значення «100 МБ» та необмежене збільшення для кожного файлу даних.
   6. Вкажіть файл журналу LDF, спільний для всіх файлів даних. (Наприклад, за наявності двох файлів даних для LDF має бути встановлений розмір 2048 МБ.)

   Створення плану обслуговування для Full SQL

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

   Примітка: Ці параметри рекомендовані Autodesk і повинні бути автоматично налаштовані для нових установок. При перенесенні з більш ранньої версії Vault Server ці параметри не задаються примусово, оскільки вони були змінені адміністратором навмисно.

   1. Перед продовженням переконайтеся, що резервні копії було створено для сховищ за допомогою Autodesk Vault Server Console.
   2. Переконайтеся, що всі користувачі вимкнулися від сервера сховища.
   3. На панелі керування двічі клацніть Адміністрація, а потім двічі клацніть піктограму Служби.
   4. Знайдіть SQL Server Agent (AUTODESKVAULT).
   5. Клацніть правою кнопкою миші агент SQL-сервера (AUTODESKVAULT) і виберіть пункт «Властивості».
   6. Змініть тип запуску на автоматичний та запустіть службу.
   7. Відкрийте Microsoft SQL Management Studio і підключіться до екземпляра AutodeskVault. Як ім'я сервера введіть \AUTODESKVAULT і натисніть "З'єднати".
   8. Клацніть правою кнопкою миші базу даних Vault та виберіть «Властивості».
   9. На сторінці файлів задайте:
      • для параметра «Авторозширення» для всіх баз даних значення 100 МБ та необмежене збільшення;
      • для всіх файлів типу _log слід вибрати значення 500 МБ;
      • для параметра "Авторозширення" для файлів значення 25 МБ;
      • для параметра «Авторозширення» для всіх _log файлів значення «На 10 відсотків» і необмежене збільшення.

   Як зберегти план обслуговування ms sql у файл

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

   Налаштування плану обслуговування баз даних MS SQL Server виконується через Microsoft SQL Management Studio. Розглянемо завдання, які ми виконуватимемо в рамках регулярного обслуговування баз даних:

   (раз на тиждень, у неділю о 2:00); (щодня, з понеділка по суботу о 2:00); (щодня); (щодня о 4:00); (щодня).

   У чому відмінність повного бекапу від різницевого?

   Повне резервне копіювання зберігає всю базу даних.

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

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

   Створення повного бекапу бази.

   В браузері об'єктів переходимо до пункту "Управління \ Плани обслуговування". У контекстному меню вибираємо "Створити план обслуговування".

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

   У створеному плані натискаємо кнопку "Додавання вкладеного плану"

   Вводимо назву "Повний бекап" та опис. Задаємо розклад для виконання завдання: Раз на тиждень у неділю о 2:00.

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

   Відкриваємо завдання на редагування: правою кнопкою миші за завданням, вибираємо пункт "Змінити".

   • Тип резервної копії: Повне;
   • Бази даних: якщо вибрати "Всі бази даних користувача", то буде виконуватися бекап всіх створених вами баз даних, але є можливість вказати на конкретні бази;
   • Створити файл резервної копії для кожної бази даних: відзначаємо пункт "Створювати вкладений каталог для кожної бази даних", щоб зручніше було орієнтуватися в бекапах та вказуємо шлях як папці, в якій зберігатимуться резервні копії;
   • Зазначаємо пункт "Перевіряти цілісність резервної копії";
   • Встановлюємо параметр "Стискати резервні копії".

   Створення різницевого бекапу.

   Створення плану виконання різницевого бекапу виконується аналогічно повному бекапу.

   Відзначимо деякі відмінності в налаштуванні:

   • Розклад виконання завдань: з понеділка до суботи о 2:00;
   • Тип резервної копії вибираємо "Розхідне"

   Очищення застарілих бекапів.

   Для очищення застарілих бекапів баз 1С Підприємства в MS SQL вибираємо на панелі елементів плану обслуговування Завдання "Очищення після обслуговування".

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

   Перетягуємо завдання з Панелі елементів у план і задаємо такі налаштування:

   • Видалити такі файли: Файли резервних копій;
   • Видалити з папки файли з певним розширенням: вказуємо папку зберігання бекапів баз 1С;
   • Включити вкладені папки першого рівня: відзначаємо галочкою, тому що у нас для бекапів баз створюються окремі папки
   • Видалити файли на основі віку під час виконання завдання: тут все обмежується лише вашими потребами та обсягом жорсткого диска, а мені достатньо 4 тижнів.

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

   Через стрілки можна задавати умову, за якої виконуватиме таке завдання: помилка, успішне завершення, виконання. Змінити умову можна клацнувши правою кнопкою миші по стрілці.

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

   Переходимо до дуже важливого та відповідального пункту: Перебудова індексу та оновлення статистики.

   Дефрагментація індексу (реорганізація чи перебудова).

   У процесі роботи бази даних 1С Підприємства, внаслідок постійного запису та видалення даних, утворюються порожні (фрагментовані) області. Тому може збільшуватися марний обсяг БД і уповільнюватися швидкість взаємодії з нею.

   Для усунення фрагментованих областей баз даних у MS SQL існує можливість проведення Реорганізації індексу та Перебудова індексу.

   У чому різниця між реорганізацією та перебудовою?

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

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

   У яких випадках потрібна реорганізація індексу?

   • Рівень фрагментації від 5% до 30%, проводимо реорганізацію.
   • Фрагментація понад 30% необхідно проводити перебудову індексу

   Під виконання цих завдань дуже підходить інструкція Transact-SQL із таким вмістом:

   Створюємо вкладений план під назвою "Дефрагментація індексу та оновлення статистики" з розкладом щодня о 4:00 і перетягуємо до нього з Панелі елементів Завдання "Виконання інструкції T-SQL".

   Вставляємо в завдання наведену вище інструкцію T-SQL.

   Оновлення статистики.

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

   Вибираємо на панелі елементів Завдання "Оновлення статистики" та додаємо її у вкладений план "Дефрагментація індексу та оновлення статистики".

   • Бази даних: всі бази даних користувача;
   • Оновити: уся зібрана статистика;
   • Тип перегляду: перегляд.

   За допомогою стрілки пов'язуємо умовою виконання завдання по оновленню індексу із завданням дефрагментації. Таким чином у разі успішного виконання дефрагментації буде проведено оновлення статистики.

   Я намагаюся експортувати простий план обслуговування з екземпляра SQL Server.

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

   StackOverflow та SQL Server Newbie рекомендують використовувати служби Integration Services для експорту плану обслуговування.

   Коли я намагаюся підключитися до Integration Services на цілі експорту, я отримую таку помилку:

   З'єднання зі службою Integration Services на комп'ютері WEBSERVER завершилося з наступною помилкою: Вказана служба не існує як встановлена ​​служба.

   Ми вирішили відключити служби Integration Services на WEBSERVER, тому що ми використовуємо це поле лише для надання даних користувачам додатків. Всі дані на WEBSERVER реплікуються із серверного екземпляра.Служби Integration Services активно використовуються для обробки даних на внутрішньому екземплярі.

   Чи є документований спосіб експорту плану обслуговування без використання служб Integration Services? Майкрософт підтримує це?

   Плани обслуговування зберігаються в msdb.dbo.sysssispackages, як і будь-які інші пакети служб SSIS, які зберігаються на SQL Server. У мене є зручна стаття про пакет SSIS Extract from MSDB, яка повинна вилікувати те, що вас турбує.

   Це працює тільки в тому випадку, якщо у вас повністю встановлений SSIS, тому що dtutil - який побудований на ньому - в основному вимкнений, навіть якщо він присутній. Деякі версії SQL Server (наприклад, Web Edition) не дозволяють повністю встановити SSIS, хоча плани обслуговування по суті використовуються майже всі функції SSIS. (Але є спосіб обійти це, якщо у вас є дві версії SQL Server, одна з яких не заблокована - див. Моя відповідь нижче.)

   Є спосіб зробити це.

   Припустимо, що, як і в OP, у вас є два екземпляри SQL Server, на одному з яких встановлений SSIS, а на іншому - ні (ймовірно, ні, наприклад, якщо це SQL Server Web Edition).

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

   Вам потрібно було б написати цей SP, щоб він id спочатку видаляв усі рядки з відповідними , а потім вставляв останні версії (або аналогічний підхід, наприклад, UPDATE відповідні id s, а потім INSERT відсутні id s). І вам потрібно буде налаштувати зв'язаний сервер на одній чи іншій стороні, щоб ви могли писати SQL, який адресований обом серверам.

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

   Звичайно, це величезний злам, але насправді це працює. (Я вважаю, що дуже важливо, щоб номер версії SQL Server був однаковим по обидва боки, щоб дані msdb.dbo.sysssispackages були настільки сумісні між різними екземплярами сервера, наскільки це дійсно здається).

   Звичайно, ви завжди можете зробити резервну копію відповідних рядків з таблиці бази даних служб SSIS. Це спрацювало б у будь-якому разі – як повна відповідь на оригінальне запитання. Як уже говорилося, це не має нічого спільного з припущенням про SSIS - це просто передбачає плани обслуговування!

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

   Я боровся з такою самою проблемою. Ось основний виніс:

   На вашому веб-сервері не потрібні інтеграції. Одним із документованих способів є використання DTUTIL. Просто використовуйте БУДЬ-ЯКИЙ SQL Server (навіть безкоштовну версію для розробників з усіма функціями Enterprise), на якому встановлені служби Integration Services, щоб скопіювати пакети обслуговування SQL Server з джерела в ціль, навіть якщо це не джерело або ціль пакета, як показано в Приклад А.

   Приклад A: Запустіть DTUTIL на SQL Server MySSISServerA, щоб скопіювати пакет обслуговування SQL з MySourceServerB у MyDestServerC .

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

   Для початку потрібно в management studio потрібно підключитися до SSIS, при цьому використовується доменна автентифікація:
   

   Далі розкрити папку бази MSDB, де знаходяться наші плани обслуговування:
   

   При підключенні можна отримати помилку SSIS, що не існує, на даному instance:

   Failed to retrieve data for this request. (Microsoft.SqlServer.Management.Sdk.Sfc)
   
   For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&LinkId=20476 Jump
   ------------------------------
   ADDITIONAL INFORMATION:
   
   SQL Server instance specified in SSIS service configuration is not present or no available.
   Цей дзвінок при цьому не є меншою частиною SQL Server на комп'ютері.
   Для більш докладної інформації, клацніть "Configuring the Integration Services Service" в SQL Server 2012 Books Online.
   
   Login timeout expired
   Network-related or instance-specific error error має місце, коли establishing a connection to SQL Server.
   Server is not found or not accessible. Виберіть, якщо ім'я дзвінка є правильним і якщо SQL Server configured to allow remote connections.
   For more information see SQL Server Books Online.
   SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF]. (MsDtsSrvr)
   ------------------------------
   Login timeout expired
   Network-related or instance-specific error error має місце, коли establishing a connection to SQL Server.
   Server is not found or not accessible. Виберіть, якщо ім'я дзвінка є правильним і якщо SQL Server configured to allow remote connections.
   For more information see SQL Server Books Online.
   SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF]. (Microsoft SQL Server Native Client 11.0)
   
   В інтернеті повно посилань на ті самі рішення, у файлі C:\Program Files\Microsoft SQL Server\110\DTS\Binn\MsDtsSrvr.ini.xml необхідно вказати ім'я сервера та інстансу.
   Але в моєму випадку це не допомогло, тому що використовується кластер, при чому я вказував і ім'я сервера і ім'я кластера, а інстанс використовується за умовчанням MSSQLSERVER.

   Рішення виявилося ще простіше, в XML файлі необхідно вказати тільки ім'я кластера, без імені інстансу.

   Далі на конкретному плані обслуговування натискаємо ПКМ та вибираємо "Export package", у вікні експорту краще вибрати "Package location - File System", чому? А тому, що при виборі "SQL Server" не правильно переноситься параметр "connection", і ваші плани просто не працюватимуть.
   

   І тому після експорту у файл, у ньому обов'язково необхідно замінити всі рядки, із зазначенням імені старого сервера на нове ім'я сервера.

   Наступний крок це імпорт у SSIS нового сервера – виробляється аналогічно. Підключаємося до SSIS, на папці MSDB тиснемо ПКМ і тиснемо "Import package", і вибираємо "Package location - File System" та наш змінений файл. Тепер наш план з'явиться у списку Мaintenance plans.

   Важливий момент - це вказівка ​​пароля sa або користувача з якого виконуються плани в connection manager. Відкриваємо на редагування план і вводимо облікові дані, вибравши "Local server connection" (це стандартний коннект).

   Досить часто необхідно перенести завдання Агента на інший екземпляр MS SQL Server. Відновлення бази даних msdb не завжди саме те рішення, яке підійде, тому нерідкі випадки, коли потрібно перенести тільки завдання Агента, а також при переході на більш нову версію MS SQL Server.То як можна перенести завдання Агента без відновлення бази даних msdb?

   У цій статті буде розібрано приклад реалізації скрипту T-SQL, який копіює завдання Агента з одного екземпляра MS SQL Server на інший. Це рішення було випробувано при перенесенні завдань Агента з MS SQL Server 2012-2016 на MS SQL Server 2017.

   Рішення

   Опишемо спочатку саму послідовність дій:

   1) створити список завдань, який переносити не потрібно
   2) перенести самі завдання
   3) перенести кроки перенесених завдань
   4) перенести розклади перенесених завдань
   5) перенести зв'язку розкладу-завдання для перенесених завдань
   6) перенести цільові сервери для перенесених завдань
   7) реєструємо завдання та активізуємо їх розклади, перевівши в неактивний режим ці завдання (вимкненням завдань)
   8) призначаємо власника всім перенесених завдань (наприклад, sa)

   Тепер для кожного пункту наведемо реалізацію на T-SQL.

   1) збираємо ті завдання, які переносити не потрібно:

   2) перенести самі завдання:

   3) перенести кроки перенесених завдань:

   4) перенести розклади перенесених завдань:

   5) перенести зв'язку розкладу-завдання для перенесених завдань:

   6) перенести цільові сервери для перенесених завдань:

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

   7) реєструємо завдання та активізуємо їх розклади, перевівши в неактивний режим ці завдання (вимкненням завдань)

   8) призначаємо власника всім перенесених завдань (наприклад, sa)

   Наведемо код всього скрипту:

   Результат

   5 способів зробити резервні копії в SQL Server

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

   Метод 1: Використання графічного інтерфейсу в SSMS для створення бекапу

   Ви потрапите на сторінку General Backup Menu page у SSMS. Тут ви можете отримати доступ до безлічі налаштувань, що відносяться до бекапу, що створюється.

   У списку “Backup type” ви можете вибрати тип створюваного бекапу - повний, диференціальний або журналу.

   У розділі “Backup component” можна уточнити, який бекап робитиметься - файлів і файлових груп чи бази даних (за замовчуванням).

   У розділі Destination (призначення) ви обираєте, де буде створено бекап - диск (за замовчуванням) або, якщо вибрати зі списку URL, то на Azure. При виборі Disk вам пропонується місце та ім'я для бекапу. Цим місцем буде каталог за промовчанням для бекапів, вказаний під час встановлення SQL Server. Якщо вас не влаштовує це місце, просто натисніть "Remove" (видалити), а потім "Add" (додати), щоб вибрати місце, яке ви хочете використовувати. У меню “Add” можна використовувати спільні шляхи.

   Розділ Media Options на “Select a Page” дозволяє вибрати такі варіанти, як ви хочете додати цей бекап до наявного набору або почати заново.

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

   У розділі Reliability (надійність) можна встановити опції “Verify backup when finished” (перевірити бекап по завершенню) та “Perform checksum before writing to media.” (Порахувати контрольну суму перед записом на носій). Ці опції збільшать час створення бекапу, але допоможуть з перевіркою цілісності під час запису.

   У Backup Options меню “Select a page” є одна дуже важлива особливість, яку слід зазначити.

   Тут є опція, пов'язана зі стисненням бекапу. У більш старих версіях SQL Server, наприклад, 2005 та 2008, ця опція була доступна тільки для Enterprise Edition. Починаючи з SQL Server 2008R2, вона доступна у Standard Edition. Щоб зробити використання стандартного стиснення для всіх ваших бекапів, просто виконайте нижченаведений код на вашому SQL Server. Потім, коли ви перейдете до цієї опції в графічному інтерфейсі SSMS, просто залиште її встановленим у “Use the default server setting.” Вам захочеться заощадити простір, який пропонує стиснення. Навіщо використовувати більше простору на окремому сховищі бекапів, ніж це необхідно? Я маю на увазі, що ви зберігаєте свої резервні копії деінде, а не на SQL Server, вірно?!

   Встановивши необхідні опції, просто натисніть "ОК", і SQL Server зробить вам бекап. Ви можете також клацнути опцію "Script" нагорі вікна майстра, щоб SQL Server показав код T-SQL, який буде виконано. Ви зможете зберегти його як приклад для подальшого використання.

   Метод 2: Використання T-SQL для створення резервної копії на SQL Server

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

   Варто відзначити два параметри Buffer Count та maxtransfersize. Ви можете поекспериментувати з цими параметрами T-SQL для прискорення створення бекапів. Значення Buffer Count управляє числом буферів вводу/виводу, які використовуються для обробки бекапу, а maxtransfersize відповідає за те, скільки даних переміщається за один раз.

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

   Як ви можете бачити початкова пропускна здатність становила 219,412 Мб/с, а час для цієї частини був 39 секунд. Це були стандартні налаштування SQL Server.

   Збільшення числа буферів до 8 збільшило пропускну здатність до 258,653 Мб/с, і час виконання впав приблизно на 6 секунд. Поєднання другої зміни з розміром maxtransfersize 4Мб збільшило пропускну здатність до 270,095 і скоротило час на 1,4 секунди. Я скинув 8 секунд часу бекапу. То була невелика база даних розміром близько 14Гб. Для більших баз даних збільшення пропускної спроможності може дати значну економію часу.

   Метод 3: Використання Powershell для створення резервних копій

   Якщо ви не використовуєте Powershell із SQL Server, то це того варте. Якщо ви не використовуєте модуль DBATools із SQL Server, отримайте його зараз. PowerShell може робити фантастичні, чудові речі, а DBATools може зробити вам потужні, дивовижні речі у всьому, що пов'язане з SQL Server. Нижче простий приклад використання команди DBATools Backup-DbaDatabase для створення повного бекапу. Ця команда має повний набір опцій, включаючи резервування всіх баз даних SQL Server, якщо не передавати параметр -Database. Перевірте це зараз.

   Метод 4: Використання планів обслуговування для створення резервних копій

   Тут лише поділюся з вами кількома думками щодо використання планів обслуговування. По-перше, плани обслуговування (Maintenance Plans) є ще одним методом з графічним інтерфейсом для налаштування резервних копій. У цьому відношенні вони є простим способом «вказати і клацнути» для обробки зберігання резервних копій, про що ми ще не говорили. По-друге, в силу природи цього методу, який дозволяє вибрати Backups як варіант плану, а потім пройти по кроках кожну частину майстра процесу, Maintenance Plans може стати загальним підходом для ІТ-професіоналів, що вийшли з системних адміністраторів. Наприклад, немає потреби знати чи розуміти опції, представлені у майстрі SSMS Backup.