Внутренние компоненты резервного копирования. Что происходит при выполнении задания резервного копирования с точки зрения блокировки и снижения производительности в SQL Server?

Я знаю, что для MySQL база данных резервируется по таблицам в SQL-выражениях, это приводит к блокировке, и если вы обновляете столбцы во время резервного копирования, вы можете столкнуться с проблемами целостности.

Насколько я понимаю, это не относится к Microsoft SQL Server, но как SQL Server справляется с этим? Есть ли какое-то внутреннее замораживание, чтобы поддерживать согласованность БД?

Также я слышал, что резервное копирование является однопоточным, то есть используется только одно ядро, при условии, что вы создаете резервную копию в один файл. Также предполагается, что у вас есть многоядерный компьютер, например, 16 ядер или, по крайней мере, значительно большее число, чем одно.

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

Так что же происходит, когда выполняется задание резервного копирования? А также есть ли существенные различия для разных версий? например 2008,2012 и 2014 (не лицензии).

Все ваши пункты покрыты мифами резервного копирования - Пол Рэндал

30-01) операции резервного копирования вызывают блокировку

Нет. Операции резервного копирования не блокируют объекты пользователя . Резервные копии действительно вызывают большую нагрузку чтения в подсистеме ввода-вывода, поэтому может показаться, что рабочая нагрузка блокируется, но на самом деле это не так. Это просто замедляется. Существует особый случай, когда резервная копия, которая должна собирать экстенты с массовой записью, будет блокировать файл, который может заблокировать операцию контрольной точки, но DML никогда не блокируется.

Также я слышал, что резервное копирование является однопоточным, то есть используется только одно ядро, при условии, что вы создаете резервную копию в один файл.

При резервном копировании в один файл или устройство будет использоваться 1 поток записи. Таким образом, если вы выполняете резервное копирование на несколько файлов / устройств (будь то несколько файлов .bak), будет иметь один поток записи на файл / устройство.

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

Проверьте

1. SQL Server 2008 Microsoft Certified Master (MCM) Готовые видеоролики, особенно о внутренностях резервного копирования.
2. Взгляд на внутреннее устройство резервного копирования и как отслеживать пропускную способность резервного копирования и восстановления (часть 1) - Автор: Джонатан Кехайяс
3. Взгляд на внутреннее устройство резервного копирования и как отслеживать пропускную способность резервного копирования и восстановления (часть 2) - Автор: Джонатан Кехайяс

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

Также я слышал, что резервное копирование является однопоточным, то есть используется только одно ядро, при условии, что вы создаете резервную копию в один файл. Также предполагается, что у вас есть многоядерный компьютер, например, 16 ядер или, по крайней мере, значительно большее число, чем одно.

Операция резервного копирования, can use parallelismно помните, что это не параллелизм, управляемый Optimizer в SQL Server, который определяется количеством дисков, с которых резервная копия должна прочитать файл данных, и где резервная копия записывает файл данных и количество созданных файлов резервных копий.

Вы не можете использовать MAXDOPподсказку при выполнении резервного копирования SQL Server

Вы не можете сгенерировать план выполнения в SSMS для простой операции резервного копирования TSQL.

Параллелизм, управляемый оптимизатором запросов в SQL Server, в основном предназначен для задействованных операторов (на самом деле он более сложный, но для простоты вы можете это принять), поскольку операция резервного копирования не требует использования какого-либо оператора, поэтому он не может использовать параллелизм, управляемый оптимизатором.

Я написал статью на Technet Wiki о резервном копировании и параллелизме, где использовал простые примеры для объяснения параллелизма во время резервного копирования SQL Server. Ниже приводится заключение

1. Если файлы базы данных находятся на нескольких дисках, операция резервного копирования будет запускаться в потоке для каждого диска устройства для чтения данных. Таким же образом, если восстановление выполняется на нескольких дисках / точках монтирования, операция резервного копирования инициирует один поток на диск / точку монтирования.

2. Даже если вы сбрасываете несколько копий резервной копии на один диск, у нас будет один поток на файл резервной копии.

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

4. Максимальная степень параллелизма не влияет на операции резервного копирования.

Я получил экспертное заключение по этому вопросу от Пола и Боба Дорра.

Так что же происходит, когда выполняется задание резервного копирования? А также есть ли существенные различия для разных версий? например 2008,2012 и 2014 (не лицензии).

Я бы предложил вам прочитать эту статью blog.msdn Боба Дорра. Он подчеркнул, что некоторые важные моменты

1. При запуске резервного копирования создается ряд буферов, выделенных из памяти вне пула буферов. Целевой размер обычно составляет 4 МБ для каждого буфера, в результате чего получается приблизительно от 4 до 8 буферов. Подробная информация о расчете находится по адресу: http://support.microsoft.com/kb/904804/en-us

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

3. Вы получаете средство записи для каждого устройства резервного копирования, каждое из которых извлекает данные из очереди данных. Таким образом, команда резервного копирования с четырьмя (4) спецификациями на диск будет иметь четыре записывающих и считывающих устройства. Читатель использует асинхронный ввод-вывод, поэтому он может идти в ногу с авторами.

Вы можете включить trace flags 3213 and 3605, оба недокументированы, поэтому, пожалуйста, используйте его в тестовой среде, и посмотрите, какое интересное сообщение сбрасывается в журнал ошибок SQL Server. Появится что-то вроде ниже

Memory limit: 249MB
BufferCount:                7
Sets Of Buffers:            1
MaxTransferSize:            1024 KB
Min MaxTransferSize:        64 KB
Total buffer space:         7 MB
Tabular data device count:  1
Fulltext data device count: 0
Filestream device count:    0
TXF device count:           0
Filesystem i/o alignment:   512
Media Buffer count:            7
Media Buffer size:          1024KB

Я не в курсе каких-либо существенных изменений в резервном коде для различных версий, такие вещи не документированы. Я знаю только об усовершенствовании, представленном во SQL Server 2012 SP1 Cumulative Update 2,включении резервного копирования и восстановления из службы хранилища BLOB-объектов Windows из SQL Server с использованием TSQL или SMO. Читать здесь

По сути, SQL Server делает грязную копию всех страниц на диске. Эти страницы, скорее всего, несовместимы, если есть параллельная активность или если ранее была неактивная активность.

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

Я не могу говорить о многопоточности операции резервного копирования. Я ожидаю, что это будет распараллелено. Как еще можно создать резервную копию базы данных 10 ТБ в подсистеме ввода-вывода 10 ГБ / с?