Как я могу сделать резервную копию большой базы данных SQL Server, не влияя на производительность?

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

Сама база данных составляет около 300 ГБ, а задание резервного копирования начинается в 4:30 утра и заканчивается только после 7:00 утра. Текущий синтаксис нашего задания резервного копирования:

BACKUP DATABASE [DatabaseName]
TO DISK = N'E:\Database Backups\DatabaseName.Bak'
WITH INIT, NOUNLOAD, NAME = N'DatabaseName.Bak',
NOSKIP, STATS = 10, NOFORMAT

E:\ это раздел на сервере, который содержит базы данных и резервные копии базы данных.

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

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

Мы используем SQL Server 2005

1. Изолируйте резервный ввод-вывод от остального ввода-вывода в вашей системе. Хотя это может занять больше времени и быть более подверженным сбоям, резервное копирование по сети, а не на локальный диск, может помочь смягчить прямое воздействие на экземпляр. Даже на виртуальной машине вы должны иметь возможность предоставлять другое хранилище, чтобы SQL Server мог выполнять запись в другую подсистему ввода-вывода.
2. Маловероятно, что это будет иметь какое-либо значение, но, если это выполняется из задания, зачем вам использовать эту STATSопцию? Вы уверены, что вам нужны другие варианты ( NOUNLOAD, NOSKIP, NOFORMAT)? Я не проводил всесторонних тестов производительности на всей матрице опций, но ИМХО вам следует использовать только те опции, которые вам нужны.
3. Выполняйте полное резервное копирование в другое время, которое не мешает обычной пользовательской активности. Это не всегда возможно, но даже в 24/7 операциях бывают пиковые и затишные времена.
4. Если вы перейдете на версию 2008+, вы сможете воспользоваться преимуществами сжатия резервных копий (Enterprise в 2008 году, Standard или Enterprise в 2008 R2 +). Если вы не можете перейти на 2008 год или у вас нет соответствующей редакции, есть сторонние инструменты для резервного копирования, которые сделают сжатие для вас, и все они довольно хороши в этом. С 2008 года я могу использовать собственное сжатие, и меня вполне устраивают как скорость, так и процент сжатия, и нет необходимости в дальнейшем инвестировать в сторонние компании. Но с 2005 года я помню, как добился успеха с Red-Gate SQL Backup ; Quest LiteSpeed также неплох, но я не знаю, какие усилия предпринимаются с момента приобретения Dell.
5. Если ваши базы данных находятся в полном восстановлении, вы можете пойти дольше между полными резервными копиями, обменивая это на знание того, что, если вам нужно восстановить на определенный момент времени, у вас потенциально будет больше журналов для восстановления. Вы могли бы объединить эту опцию с предложением Али, приведенным ниже, о проведении различий в течение недели - если вы должны были восстановить в четверг, вам нужно будет восстановить 1 полный, 1 разностный и журналы после различий.
6. Если у вас много устаревших и неизменных данных, вы можете разместить их в другой базе данных с другим планом восстановления или, по крайней мере, в разных файловых группах, и таким образом разделить операции резервного копирования. Если у вас есть справочные или архивные данные, которые можно сделать доступными только для чтения, и если вы выполняете простое восстановление, вы можете переместить их в свою собственную файловую группу только для чтения, выполнить резервное копирование один раз и не нужно включать их в свои ночные резервные копии когда-либо снова. Посмотрите эти темы MSDN:

Выполнение постепенного восстановления

Пример: частичное восстановление только некоторых файловых групп (простая модель восстановления)

Это общая проблема, существует множество решений, и она действительно зависит от вашей среды. Давайте пройдемся по ним:

1- Резервное сжатие на лету

В 2008 году R1 Backup Compression стала доступна в Enterprise, в 2008R2 стала доступна в Standard. Это ОГРОМНО. Это сэкономит вам много времени. Если вы можете обновить пойти на это. Если вы не можете, воспользуйтесь утилитой RedGate HyperBak или Quest LiteSpeed . Оба имеют бесплатную пробную версию.

2- Полное и разностное резервное копирование

Я унаследовал базу данных на 2 ТБ, что привело к большим тайм-аутам для 24/7 крупной интернет-компании, которую я разработал. Мы включили полное и дифференциальное резервное копирование, что сэкономило нам много времени. Я бы взял полную резервную копию в воскресенье в 12:00, когда активность была низкой, и делал различий в течение недели. Это сэкономило много места. Работа Diff отличается от журналов транзакций, поскольку они работают с тем, какие страницы базы данных были изменены. Любые измененные страницы резервируются. Таким образом, вы делаете полное восстановление, а затем восстановление diff, чтобы добавить измененные страницы.

3- Какое у вас узкое место?

Анализ узких мест важен для диагностики. Вы резервное копирование на тот же массив дисков, что и ваши файлы данных? Ваши файлы данных привязаны? Каковы ваши диски DISK SEC / READ и DISK SEC / WRITE для дисков данных во время резервного копирования? Я изменил резервные копии, чтобы создать 4 файла. Каждый файл имеет свою собственную программу записи потоков и в нашей сети хранения данных, которая отлично работает. Проверьте это, я сбрил 45 минут, просто создав 4 резервных файла. Просто убедитесь, что ваши показатели диска, перечисленные выше, низкие. Получить базовый уровень.

4- Репликация на другой сервер и резервное копирование

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

Вы можете использовать эти параметры:

BLOCKSIZE - Выберите размер 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536. (в КБ)

BUFFERCOUNT - указывает общее количество буферов ввода / вывода, которые будут использоваться для операции резервного копирования. Вы можете указать любое положительное целое число; однако большое количество буферов может вызвать ошибки «нехватки памяти» из-за неадекватного виртуального адресного пространства в процессе Sqlservr.exe. - из MSDN

MAXTRNASFERSIZE - от 65536 байт (64 КБ) до 4194304 байт (4 МБ)

Попытайся. это решило проблему истечения времени ожидания в то время как большой размер дБ.

Private Sub Command1_Click()
On Error Resume Next
Dim con As New Connection
Dim tm As String
con.CommandTimeout = 500'''Command timeout should be 500


 With con
    .ConnectionString = "Provider=SQLOLEDB.1;Persist Security Info=False;User ID=sa;Initial Catalog=dbiBMS;Data Source=192.168.103.4"
    .Open
 End With
 tm = CStr(Time)

con.Execute " backup database dbiBMS to disk='E:\Database_Backup\Test1.bak' with format "

con.Close
MsgBox tm
Exit Sub
x:
MsgBox Err.Description

End Sub