Налаштування BUFFERCOUNT, BLOCKSIZE та MAXTRANSFERSIZE для команди BACKUP

Я шукаю практичне керівництво для установки значень для BUFFERCOUNT, BLOCKSIZEі MAXTRANSFERSIZEз BACKUPкоманди. Я трохи провів дослідження (див. Нижче), трохи провів тестування, і я повністю усвідомлюю, що будь-яка справді цінна відповідь розпочнеться з "Ну, це залежить ...". Моє занепокоєння щодо тестування, яке я зробив, і тестування, показаного на будь-якому з знайдених нами ресурсів (див. Спосіб нижче), полягає в тому, що тестування проводиться у вакуумі, швидше за все, у системі без іншого навантаження.

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

• Як різні апаратні / навантажувальні фактори впливають на те, що потрібно робити.
• Чи існують обставини, за яких жодне з цих значень не слід перекривати?
• Чи є підводні камені для переосмислення будь-якого з них, які не відразу очевидні? Використовується занадто багато пам'яті та / або дискового вводу / виводу? Ускладнення операцій відновлення?
• Якщо у мене працює сервер з кількома екземплярами SQL Server (екземпляр за замовчуванням і два іменовані екземпляри), і якщо я запускаю резервні копії всіх 3 екземплярів одночасно, це впливає на те, як я встановлюю ці значення, крім того, щоб переконатися, що колективний ( BUFFERCOUNT* MAXTRANSFERSIZE) не перевищує доступну оперативну пам’ять? Можлива суперечка вводу / виводу?
• У тому самому сценарії наявності трьох екземплярів на одному сервері та повторного запуску резервних копій на всіх трьох паралельно, як би також запуск резервних копій для декількох баз даних одночасно в кожному екземплярі впливав на встановлення цих значень? Це означає, що якщо кожен з трьох екземплярів має 100 баз даних у кожній, виконуючи 2 або 3 резервних копій на кожен екземпляр одночасно, таким чином, що одночасно працює від 6 до 9 резервних копій. (У цій ситуації у мене є багато малих та середніх баз даних, а не кілька великих.)

Що я зібрав поки що:

• BLOCKSIZE:

  • Підтримувані розміри - 512, 1024, 2048, 4096, 8192, 16384, 32768 та 65536 (64 Кб) байт. ^[1]
  • За замовчуванням 65536 для стрічкових пристроїв, а 512 - інакше ^[1]
  • Якщо ви берете резервну копію, яку плануєте скопіювати та відновити з компакт-диска, вкажіть BLOCKSIZE = 2048 ^[1]
  • Коли ви пишете на одиночні диски, за замовчуванням 512 просто чудово; якщо ви використовуєте RAID-масиви або SAN, ви повинні перевірити, чи краще за замовчуванням або 65536. ^{[13 (стор. 18)]}

  • Якщо встановити вручну, значення повинно бути> = Розмір блоку, який використовується для створення файлів даних, інакше ви отримаєте таку помилку:

    Msg 3272, рівень 16, стан 0, рядок 3
    Пристрій "C: \ програмні файли \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ резервне копіювання \ BackupTest.bak" має апаратний розмір 4096, але параметр розміру блоку визначає несумісне значення перевизначення 512. Перезапустіть оператор, використовуючи сумісний розмір блоку.

• BUFFERCOUNT:

  • За замовчуванням ^{[2], [8]} :

    SQL Server 2005 та новіші версії:
    (NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [mystery_multiplier]: Існує деяка невідповідність щодо цього значення. Я бачив це у 3 формах:

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    Тестування, що показує мультиплікатор, повинен бути 3виконаний на SQL Server 2005 SP2 ^[9] .

    Моє тестування на SQL Server 2008 R2 та 2012 та коментар користувача щодо SQL Server 2014 ^[8] показують, що мультиплікатор має бути 4. Значення, з огляду на вказане значення для GetSuggestedIoDepth(безпосередньо нижче), або:

    • GetSuggestedIoDepthзараз 4, або
    • множник зараз GetSuggestedIoDepth + 1
  • GetSuggestedIoDepthповернення 3для пристроїв DISK ^[9]
  • Максимально встановлене максимальне значення не має, але враховуючи, що потрібна пам'ять = ( BUFFERCOUNT* MAXTRANSFERSIZE), здається, що практичне максимальне значення буде: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • Можливі значення є кратними 65536 байтів (64 КБ), починаючи з 4194304 байт (4 МБ). ^[1]
  • Значення за замовчуванням: Якщо пристрій перебуває в режимі читання (відновлення) або це настільний або експрес-версія 64K, використовуйте 1 Мб. ^[9]
• Загальне / інше:
  • Максимальний розмір, який можна використовувати, є ( Buffer Pool's to Physical Memory / 16 ). Як повернуто з виклику API GlobalMemoryStatusEx (ullTotalPhys). ^[9]
  • Прапор Trace 3213виводить параметри налаштування резервного копіювання / відновлення під час виконання операцій резервного копіювання / відновлення та 3605скидає вихід у файл ERRORLOG :DBCC TRACEON (3213, 3605, -1);
  • Ви можете використовувати DISK = N'NUL:'(еквівалент DOS / Windows /dev/nullв UNIX) для легшого тестування деяких показників (але не отримаєте хорошого відчуття загального часу процесу, оскільки він пропускає введення / виведення запису)

Ресурси

1. MSDN сторінка для T-SQL BACKUP команди
2. KB904804: Під час створення резервної копії бази даних у SQL Server 2000 у вас низька продуктивність
3. Параметри для підвищення продуктивності резервного копіювання SQL Server
4. Резервне копіювання і відновлення
5. Оптимізація резервного копіювання та відновлення SQL Server
6. Оптимізація продуктивності резервного копіювання
7. Як збільшити повну швидкість резервного копіювання бази даних SQL за допомогою стиснення та твердотілих дисків
8. Неправильний варіант передачі даних BufferCount може призвести до стану OOM
9. Як це працює: як резервне копіювання та відновлення SQL Server вибирає розміри передачі
10. Як це працює: обмін резервним кодом резервного копіювання SQL Server (фокус VDI)
11. Налаштування великих баз даних SQL Backup
12. Пам'ять SQL Server для резервного буфера
13. Приклад: Швидке та надійне резервне копіювання та відновлення VLDB через мережу (файл .docx)
14. Скільки пристроїв резервного копіювання рекомендується покращити продуктивність резервного копіювання?

Я тестував:

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

ОНОВЛЕННЯ

Здається, я іноді забуваю додати інформацію, яку я завжди прошу, щоб інші надали, коли я відповідаю на питання ;-). Я дав вище інформацію про мою поточну ситуацію, але можу надати більш детальну інформацію:

Я працюю для клієнта, який надає програму SaaS 24/7 / 365.25. Таким чином, є потенціал, що користувачі можуть бути в будь-якій точці, але реально, що користувачі базуються в США (поки що) і прагнуть працювати переважно "стандартними" годинами: 7 ранку Тихого океану (тобто 10 ранку Східної) до 7 вечора Тихого (тобто 10 вечора східної), але 7 днів на тиждень, а не лише понеділок - п’ятниця, хоча навантаження на вихідні трохи легше.

Вони налаштовані таким чином, що у кожного клієнта є своя БД. Це нішева галузь, тому потенційних клієнтів не існує десятків тисяч (і більше). Кількість клієнтських баз даних залежить від конкретного випадку, найбільший примірник - 206 клієнтів. Найбільша БД - це бл. 8 ГБ, але лише близько 30 БД понад 1 ГБ. Отже, я спеціально не намагаюся досягти максимальної продуктивності VLDB.

Коли я починав з цим клієнтом, їхні резервні копії завжди були ПОВНІ, один раз на день, і не було резервних копій LOG. Вони також встановили MAXTRANSFERSIZE на 4 МБ, а BUFFERCOUNT - на 50. Я замінив цю установку на трохи налаштовану версію сценарію резервного копіювання бази даних Ola Hallengren . Трохи налаштована частина полягає в тому, що вона запускається з багатопотокового інструменту (який я написав і, сподіваюся, незабаром розпочне продаж), який динамічно виявляє БД під час підключення до кожного Екземпляра, і дозволяє здійснювати занулення за кожну інстанцію (отже, я зараз запускаю три екземпляри одночасно, але БД на кожен екземпляр послідовно, оскільки я не був впевнений у наслідках їх одночасного запуску).

Налаштування тепер має робити ПОВНЕ резервне копіювання один день на тиждень та резервне копіювання DIFF в інші дні; Резервні копії LOG робляться кожні 10 хвилин. Я використовую значення за замовчуванням для трьох варіантів, про які я тут цікавлюсь. Але, знаючи, як вони були встановлені, я хотів переконатися, що я не скасовував оптимізацію (тільки тому, що в старій системі були деякі основні вади, це не означає, що всебуло неправильно). Наразі для 206 баз даних потрібно близько 62 хвилин для ПОВНИХ резервних копій (один раз на тиждень) і від 7 до 20 хвилин для резервних копій DIFF в інші дні (7 в перший день після ПОВНОГО і 20 в останній день раніше наступний ПОВНИЙ). І це запускає їх послідовно (одна нитка). Загальний процес резервного копіювання LOG (усі БД на всіх 3 екземплярах) займає від 50 до 90 секунд кожен раз (знову ж таки, кожні 10 хвилин).

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

Я також усвідомлюю, що я можу включити компресію (мій тестовий запит навмисно відключений), і я рекомендував це команді, але мені було відомо, що вбудоване стиснення начебто вдале. Частина старого процесу полягала в стисненні кожного файлу в RAR, і я зробив власне тестування і виявив, що так, версія RAR принаймні на 50% менша, ніж натиснута версія. Я спробував спочатку використовувати натиснене стиснення, щоб прискорити роботу, а потім RAR-файли, але ці файли, хоча і менші, ніж просто стиснені, але були ще трохи більшими, ніж лише стиснута версія RAR, і достатньо різниці, щоб виправдати не використовують нативної компресії. Процес стиснення резервних копій асинхронний і триває кожні X хвилин. Якщо він знаходить .bakабо.trnфайл, він стискає його. Таким чином, процес резервного копіювання не уповільнюється часом, необхідним для стиснення кожного файлу.

Ви вирішили взяти участь у запитанні. Дякуємо, що так ретельно!

Просто пару речей, які я помічаю з рук:

• Як різні апаратні / навантажувальні фактори впливають на те, що потрібно робити.

У вас працює екземпляр 24x7? Яке навантаження цілодобово? Я помічаю, що у вас вимкнено стискання резервного копіювання; це те, що розробляючи тест, чи бажано з якоїсь причини його вимкнути, коли ви вводите це у виробництво? Якщо у вас є тонна частина апаратури (процесор / оперативна пам’ять) і завершення резервного копіювання за найкоротший проміжок часу має першорядне значення, тоді ви хочете налаштувати ці параметри під конкретне обладнання, яке ви маєте на увазі. Якщо ви хочете переконатися, що робочі навантаження OLTP обслуговуються цілодобово, і не хочете, щоб резервне копіювання впливало на це, вам, ймовірно, доведеться налаштувати ці параметри навпаки. Ви не визначили своїх цілей дизайну, оскільки просите загальних вказівок, оскільки ви так розумно заявляєте "це залежить ™".

• Чи існують обставини, за яких жодне з цих значень не слід перекривати?

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

• Чи є підводні камені для переосмислення будь-якого з них, які не відразу очевидні? Використовується занадто багато пам'яті та / або дискового вводу / виводу? Ускладнення операцій відновлення?

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

• Якщо у мене працює сервер з кількома екземплярами SQL Server (екземпляр за замовчуванням і два іменовані екземпляри), і якщо я запускаю резервні копії всіх 3 Instancs одночасно, це впливає на те, як я встановлюю ці значення, крім того, щоб переконатися, що колектив (BUFFERCOUNT * MAXTRANSFERSIZE) не перевищує доступну оперативну пам’ять? Можлива суперечка вводу / виводу?

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

Я написав повідомлення в блозі з деяким кодом, який показує, як я роблю тестування продуктивності резервного копіювання, на SQLServerScience.com

^{це може бути не найкращою відповіддю, яку я коли-небудь писав, але, як колись сказав The Great One ™, "ти пропускаєш 100% пострілів, які ти не робиш".}