Внутрішнє резервне копіювання - Що відбувається, коли виконується завдання резервного копіювання - з точки зору блокування та продуктивності в SQL Server?

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

Наскільки я розумію, це не стосується сервера Microsoft SQL, але як це справляється з SQL сервером? Чи є якась внутрішня заморожування, щоб підтримувати db послідовно?

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

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

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

Всі ваші моменти висвітлюються в резервних міфах - Пол Рандал

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

Ні. Операції резервного копіювання не беруть блокування на об’єкти користувача . Резервні копії викликають дуже велике навантаження для зчитування підсистеми вводу / виводу, так що це може виглядати, як завантаженість завантажується, але насправді це не так. Це просто сповільнюється. Існує особливий випадок, коли резервна копія, яка повинна підбирати масові розширення, займе блокування файлів, яке може блокувати операцію контрольної точки - але DML ніколи не блокується.

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

Коли буде зроблено резервне копіювання в одному файлі чи пристрої, буде використано 1 потік запису. Отже, якщо ви створюєте резервну копію для декількох файлів / пристроїв (будь то декілька файлів .bak), буде мати один потік запису на файл / пристрій.

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

Перевірити

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

Стаття, написана Полом про внутрішні резервні копії, є чудовою, і ви повинні її прочитати. Додаючи до сказаного інші і наголошуючи на конкретній частині вашого питання

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

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

Під MAXDOPчас отримання резервної копії на SQL Server не можна використовувати підказку

Ви не можете генерувати план виконання в SSMS для простої операції з резервного копіювання TSQL.

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

Я написав статтю в Technet Wiki про резервне копіювання та паралелізм, де використовував прості приклади, щоб пояснити паралелізм під час резервного копіювання на SQL Server. Далі йде висновок

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

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

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

4. Максимальна ступінь паралелізму не впливає на роботу резервного копіювання.

З цього питання я отримав експертну думку від Пола та Боба Дорра.

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

Я б запропонував вам прочитати цю статтю Bob.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,резервного копіювання та відновлення з сервісу зберігання Windows Azure Blob з SQL Server за допомогою TSQL або SMO. Прочитайте тут

В основному, SQL Server робить брудну копію всіх сторінок на диску. Ці сторінки, ймовірно, невідповідні, якщо відбувається паралельна діяльність або якщо раніше існує неперевірена діяльність.

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

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