Установка 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)]}

  • Если установить вручную, значение должно быть> = Размер блока, используемого для создания файла (ов) данных, иначе вы получите следующую ошибку:

    Сообщение 3272, уровень 16, состояние 0, строка 3
    Устройство 'C: \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak' имеет размер аппаратного сектора 4096, но параметр размера блока указывает несовместимое значение переопределения 512. Повторно введите оператор, используя совместимый размер блока.

• BUFFERCOUNT:

  • По умолчанию ^{[2], [8]} :

    SQL Server 2005 и более поздние версии:
    (NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [mystery_multiplier]: есть некоторое несоответствие относительно этого значения. Я видел это в трех формах:

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

    
    Тестирование, показывающее, какой множитель необходимо выполнить, 3было выполнено в SQL Server 2005 с пакетом обновления 2 ^[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]
  • Значения по умолчанию: Если устройство находится в режиме чтения (восстановление) или это Desktop или Express Edition, используйте 64 КБ, иначе используйте 1 МБ. ^[9]
• Общее / Разное:
  • Максимальный размер, который может быть использован ( буферный пул к физической памяти / 16 ). Как возвращено из вызова API GlobalMemoryStatusEx (ullTotalPhys). ^[9]
  • Trace Flag 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 Backup и Restore выбирают размеры передачи
10. Как это работает: SQL Server Backup Buffer Exchange (фокус 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:00 по тихоокеанскому времени (т.е. с 10:00 по восточному поясному времени) до 19:00 по тихоокеанскому времени. (то есть в 22:00 по восточному времени), но 7 дней в неделю, а не только с понедельника по пятницу, хотя нагрузка на выходные немного меньше.

Они настроены так, что у каждого клиента есть своя БД. Это нишевая отрасль, поэтому потенциальных клиентов не существует десятков тысяч (или более). Количество клиентских баз данных варьируется в зависимости от экземпляра, причем самый большой экземпляр содержит 206 клиентов. Самая большая БД составляет ок. 8 ГБ, но только около 30 БД занимают более 1 ГБ. Следовательно, я специально не пытаюсь максимизировать производительность VLDB.

Когда я начинал с этим клиентом, его резервные копии всегда были ПОЛНЫМИ, один раз в день, и никаких резервных копий LOG. Они также установили MAXTRANSFERSIZE на 4 МБ и BUFFERCOUNT на 50. Я заменил эту настройку слегка настроенной версией Олы Хелленгрен. сценария резервного копирования базы данных . Слегка настроенная часть состоит в том, что он запускается из многопоточного инструмента (который я написал и, надеюсь, скоро начнут продавать), который динамически обнаруживает БД при подключении к каждому экземпляру и позволяет регулировать количество для каждого экземпляра (следовательно, в настоящее время я запускаю три экземпляра одновременно, но DB для каждого экземпляра последовательно, так как я не был уверен в последствиях их одновременного запуска).

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

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

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

Вы ответили на множество вопросов в вашем вопросе. Спасибо за тщательность!

Просто пара вещей, которые я замечаю от руки:

• Как различное оборудование / факторы нагрузки влияют на то, что должно быть сделано.

Вы работаете в режиме 24x7? Какая нагрузка круглосуточно? Я заметил, что у вас отключено сжатие резервных копий; Это сделано специально для теста или желательно по какой-то причине отключить его при запуске в производство? Если у вас есть тонны запаса аппаратного обеспечения (ЦП / ОЗУ), и первостепенное значение имеет завершение резервного копирования в кратчайшие сроки, то вам нужно настроить эти параметры для конкретного оборудования, которое у вас есть с этой целью. Если вы хотите, чтобы рабочие нагрузки OLTP обслуживались круглосуточно, и не хотите, чтобы резервное копирование влияло на это, вам, вероятно, придется настроить эти параметры наоборот. Вы не определили свои цели дизайна, так как вы просите общее руководство, как вы мудро заявляете «это зависит ™».

• Существуют ли обстоятельства, при которых ни одно из этих значений не должно быть переопределено?

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

• Есть ли подводные камни для преодоления любого из них, которые не сразу очевидны? Используете слишком много памяти и / или дисковый ввод-вывод? Сложные операции восстановления?

Поскольку в документах, на которые вы ссылаетесь, четко указано, что чрезмерное повышение этих параметров, безусловно, может оказать негативное влияние на время безотказной работы. Как и во всех продуктах, основанных на производстве, вам необходимо тщательно проверить это перед развертыванием и оставить настройки в покое, если в этом нет крайней необходимости.

• Если у меня работает сервер с несколькими экземплярами SQL Server (инстанс по умолчанию и два именованных экземпляра), и если я одновременно запускаю резервные копии всех 3 экземпляров, влияет ли это на то, как я устанавливаю эти значения, не будучи уверенным, что коллектив (BUFFERCOUNT) * MAXTRANSFERSIZE) не превышает доступную оперативную память? Возможный конфликт ввода / вывода?

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

Я написал сообщение в блоге с некоторым кодом, показывающим, как я выполняю тестирование производительности резервного копирования, на SQLServerScience.com

^{это может быть не самый лучший ответ, который я когда-либо писал, но, как однажды сказал The Great One, «вы пропускаете 100% снимков, которые не делаете»}