Выполняется ли резервное копирование SQL быстрее, если сначала настроить базы данных только на чтение?

Мне нужно сделать резервную копию всех баз данных подряд (3,25 ГБ данных для всех файлов .BAK вместе взятых).

Будет ли это работать быстрее, если я настрою скрипт на установку базы данных только для чтения перед ее резервным копированием?

Я использую опцию ВОССТАНОВИТЬ ПРОВЕРКУ, чтобы проверить целостность резервной копии. Я также хотел бы знать, есть ли что-нибудь, что может ускорить этот процесс? Я обнаружил, что это занимает больше времени, чем само резервное копирование!

Установив его на READ ONLY может помочь вам, поскольку вы удаляете одну каплю воды из океана.

Бэкапы учитывают активные транзакцииво время создания резервной копии.
Это означает, что да, когда вы помещаете свою базу данных в READ ONLY вы убираете крошечные накладные расходы.
Что технически действительно помогает, но оно того не стоит.

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

Чтобы повысить производительность резервного копирования:

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

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

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

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

Узким местом является ЦП: не сжимайте резервную копию.
Диск - это узкое место: сжимайте резервную копию.

Если вы хотите погрузиться глубже, запустите этот сценарий TSQL во время резервного копирования:

SELECT command,
            sh.text,
            start_time,
            percent_complete,
            CAST(((DATEDIFF(s,start_time,GetDate()))/3600) as varchar) + ' hour(s), '
                  + CAST((DATEDIFF(s,start_time,GetDate())%3600)/60 as varchar) + 'min, '
                  + CAST((DATEDIFF(s,start_time,GetDate())%60) as varchar) + ' sec' as running_time,
            CAST((estimated_completion_time/3600000) as varchar) + ' hour(s), '
                  + CAST((estimated_completion_time %3600000)/60000 as varchar) + 'min, '
                  + CAST((estimated_completion_time %60000)/1000 as varchar) + ' sec' as est_time_to_go,
            dateadd(second,estimated_completion_time/1000, getdate()) as est_completion_time,
            status, blocking_session_id, wait_type, wait_time, last_wait_type, wait_resource, reads, writes, cpu_time 
FROM sys.dm_exec_requests re
CROSS APPLY sys.dm_exec_sql_text(re.sql_handle) sh
WHERE re.command in ('RESTORE DATABASE', 'BACKUP DATABASE', 'RESTORE LOG', 'BACKUP LOG')

(в percent_complete не будет работать под 2014 годом, все равно нужно найти решение для этого).

В столбце wait_type вы увидите, что заставляет резервное копирование ждать. Вы можете посмотреть это в этот список. Если ему нужно дождаться другого процесса, он появится в blocking_session_id. Вы можете получить более подробную информацию об этом процессе с помощью sp_who2 xxx.

Если ваш сервер (диск / процессор) может справиться с этим, вы можете запланировать одновременное выполнение резервного копирования. Если вам действительно нужна производительность, резервное копирование в несколько файлов на нескольких дисках.

@BartDeVos прав, когда говорит, что это зависит от вашего узкого места, но он упустил ключевой момент: ЕСЛИ конкурирующие блокировки записи являются вашим узким местом, тогда да, создание базы данных только для чтения может помочь. (а если нет, то не беспокойтесь об этом).

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

РЕДАКТИРОВАТЬ. Прочтите комментарии. ЕСЛИ используемая система резервного копирования является той, которую предполагают другие респонденты, то скорость резервного копирования не будет затронута, и я предполагаю, что ссылка OP на .bak files имеет тенденцию поддерживать это.