Комментарии 38
BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304
BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152
BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304
и разница между ними менее 1%, то уверенно можно сказать, что связь между параметрами и скоростью бекапа в этих пределах значений случайна, никакой закономерности нет. Но отход от встроенных параметров, очевидно, хорошо повлиял на результат.
Предложу вам построить графики зависимости времени бекапа от каждого параметра. Будет понагляднее и, думаю, можно будет предположить, в каких интервалах было хорошее влияние на скорость.
Плюс есть у меня еще ощущение, что для точности теста надо рестартить sql, чтобы гарантировать, что в кэше ничего не осталось. Иначе довольно сложно предсказать, когда он может что-то из кэша взять, а когда нет.
отход от встроенных параметров, очевидно, хорошо повлиял на результат
Хорошо сформулировано, спасибо. Завтра добавлю его в текст, с указанием авторства, если вы не против. Просто это именно то, что я хотел проверить и показать. Если делать по-хорошему, нужна серия тестов и какое-то усреднение. Но мне уже дальше не очень интересно, т.к. хватает (точнее хватало, потому что сейчас бэкапы не в моей ответственности) того результата, который даёт размазывание по разным устройствам.
Что касается кэша, насколько я понимаю, влиять может только кэш ос/диска, но тогда все они были в равных условиях, т.к. предварительно я несколько раз прогонял «стандартный» бэкап, чтобы убедиться, что скорость всегда примерно одинакова.
Да, конечно, там в тексте ссылка https://docs.google.com/spreadsheets/d/19af2YOxP5VfnWpZcF1Imt4InFV4C1c5-0Qq7tvER1YQ/edit?usp=sharing
Чего тут объяснять то, очевидно же, у чего буфера отнимаются. Об этих параметрах пишут уже 20 лет и потом описывают последствия. ИМХО, не стоит без большой нужды их использовать.
Ну у нас 30 баз на одном сервере и сокращение времени копирования позволит добавить например обновление статистики (в отчётный период нужная вещь). Переносить некуда, нового не покупают, остаются такие эксперименты).
Так сегодня память на сервере БД исчисляется сотнями гигабайт, расход каких-то мегабайт на буферы навряд ли сделает больно
RESTORE DATABASE [bt]
FROM
DISK = 'D:\SQLServer\backup\bt1.bak',
DISK = 'D:\SQLServer\backup\bt2.bak',
DISK = 'D:\SQLServer\backup\bt3.bak',
DISK = 'D:\SQLServer\backup\bt4.bak'
WITH REPLACE, RECOVERY;
BACKUP DATABASE [bt]
TO
DISK = 'D:\SQLServer\backup\bt1.bak',
DISK = 'D:\SQLServer\backup\bt2.bak',
DISK = 'D:\SQLServer\backup\bt3.bak',
DISK = 'D:\SQLServer\backup\bt4.bak'
WITH COMPRESSION;
BACKUP DATABASE [bt], [bt2], [bt3]
TO
DISK = 'D:\SQLServer\backup\bt1.bak',
DISK = 'D:\SQLServer\backup\bt2.bak',
DISK = 'D:\SQLServer\backup\bt3.bak',
DISK = 'D:\SQLServer\backup\bt4.bak'
WITH COMPRESSION;
Большое спасибо за интересную статью.
Но обычно резервную копию делают на постоянной основе через теневые копии-обычно либо через PowerShell, либо через стороннее ПО, минимально нагружая тем самым промовскую (продовскую) среду. Естественно, если все среды виртуальные.
Конечно, но в большинстве случаев лучше брать готовые и проверенные временем и разными проектами решения, чем делать свое.
Хотя порой тоже спорно.
В любом случае не будет лишним знать что внутри и как это делают готовые решения.
Однако, важно правильно применять и оценивать готовые решения и самописные.
ИМХО никто лучше sql server'а не знает что и как нужно бэкапить.
конечно, shadow copy хорошо интегрированы, и sql server знает, что его сейчас будут бэкапить, но родное резервное копирование всё равно мне кажется предпочтительнее.
минимально нагружая тем самым промовскую (продовскую) среду. Естественно, если все среды виртуальные.
вы просто выносите нагрузку с виртуальной машины, но она остаётся на том же физическом сервере, так что в чём профит?
А Вы проверяли на практике что и как нагружает БД?
Через backup как раз БД периодически сильно нагружается, а вот через теневую копию практически незаметно по счетчикам производительности
можно детали? на какие счётчики вы ориентируетесь, какие значения получаете
Прямо сейчас на вскидку не готов ответить, но счетчики стандартные по блокировкам именно и времени ожидания процессов.
На одной стороне разные скрипты с использованием backup, а с другой скрипт на PowerShell с использованием теневой копии.
Второй дольше создает резервную копию базы из теневой копии системы, что естественно. Однако, при этом практически незаметно для СУБД.
В документации вообще говорится, что в будущем конструкции BACKUP и RESTORE не будут поддерживаться.
Хотя профайлер поддерживается уже как 5+ лет после аналогичной публикации о том, что он не будет поддерживаться.
И скрипты по теневым копиям значительно сложнее писать, чем просто использовать BACKUP.
интересно, не знал. а как же тогда бэкапить сервер на линуксе?
Честно-не знаю.
Профайлер заменяется расширенными событиями (и то-это упрощенный мониторинг, т е он полностью профайлер не заменит, о чем говорится в документации).
Резервные копии и восстановления можно делать и без ключевых слов BACKUP и RESTORE-об этом в частности обсуждалось здесь и более детально описано в документации.
Но сам честно прям 100% без BACKUP и RESTORE еще не делал.
Я Вас обманул-прошу прощения, делали что-то подобное как с помощью вима, так и потом с помощью PowerShell-скриптов без вима:
Резервное копирование и восстановление баз данных виртуализованного Microsoft SQL Server.
Благодарю за поправку.
Делали что-то подобное как с помощью вима, так и потом с помощью PowerShell-скриптов без вима:
Резервное копирование и восстановление баз данных виртуализованного Microsoft SQL Server.
При этом не использовались ключевые слова BACKUP и RESTORE.
По ссылке, несколько я понял, всё равно под капотом используется backup log, как минимум. Не очень понимаю зачем делать бэкап без использования ключевого слова бэкап.
Предполагаю, что со снапшота ФС можно снять копии файлов данных и ЖТ, и оно потом заведётся.
MS SQL Server: BACKUP на стероидах