Установка 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) для более легкого тестирования некоторых метрик (но не получите хорошего представления об общем времени процесса, поскольку он пропускает ввод-вывод записи)

Ресурсы

Я проверил с:

--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файл, он сжимает его. Таким образом, процесс резервного копирования не замедляется на время, необходимое для сжатия каждого файла.

sql-server backup best-practices maintenance Соломон Руцкий
источник

Просто любопытно, вы пытаетесь решить проблему медленного резервного копирования? Обычно настройки по умолчанию работают нормально в большинстве сред. Кроме того, опция питания настроена на высокую производительность - поскольку при резервном копировании используются циклы ЦП.

Кин Шах

@ Кин Нет, резервные копии не очень медленные. Но если внесение незначительного изменения сделает / может сделать их на 20% (или более) быстрее, то я, безусловно, возьму это на себя. Для 206 баз данных требуется около 62 минут для ПОЛНОГО резервного копирования (один раз в неделю) и от 7 до 20 минут для резервного копирования DIFF в оставшиеся дни. И это запускает их последовательно (один поток). Когда я начинал с этим клиентом, предыдущей настройкой было использование 4 МБ для MaxTransfer и 50 для BufferCount. В настоящее время я просто использую значения по умолчанию, так что не уверен, смогу ли я уменьшить выигрыш в производительности, поэтому хотел узнать больше, прежде чем вносить какие-либо изменения.

Соломон Руцкий

@srutzky - лишь краткое замечание из вашего последнего комментария. Я сэкономил немало времени, разбивая свои резервные копии на несколько файлов, имеющих одинаковый объем. Я просто хотел поделиться этим с вами на случай, если вы еще не попробовали. Если ваши 206 БД запускают резервное копирование параллельно между несколькими БД, хотя вы можете не получить преимуществ многопоточности.

Али Разеги

@MaxVernon «Резервные копии интерфейса виртуальных устройств (VDI) позволяют сторонним решениям резервного копирования интегрироваться с SQL Server.», Которое было взято из Ресурса № 10 в моем Вопросе :). Я не хотел проходить столько усилий ;-)

Соломон Руцкий

@srutzky на случай, если вы захотите повеселиться: прочитайте MSSQL Backups - проверьте максимальный размер передачи HBA - парень гениален и действительно хорош в своих тестах. И то, что, вероятно, соответствует вашим тестам: Автоматическая настройка резервного копирования SirSQL .

Marian

Установка BUFFERCOUNT, BLOCKSIZE и MAXTRANSFERSIZE для команды BACKUP

Ответы: