Як я можу створити резервну копію великої бази даних 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)? Я не робив жодного обширного тестування продуктивності на всій матриці варіантів, але IMHO слід використовувати лише ті параметри, які знаєте, що вам потрібно.
3. Виконайте повні резервні копії в інший час, що не заважає регулярній діяльності користувачів. Це не завжди можливо, але навіть у цілодобових операціях настають пікові та затишні часи.
4. Якщо ви переходите до 2008+, ви можете скористатися компресією резервного копіювання (Enterprise 2008, Standard або Enterprise у R2 + 2008). Якщо ви не можете перейти до 2008 року або не маєте відповідного видання, є сторонні інструменти резервного копіювання, які зроблять компресію для вас, і всі вони дуже добре в цьому справляються. Починаючи з 2008 року, я міг використовувати натиснене стиснення, і я був дуже задоволений як швидкістю, так і стисненням% там, не потребуючи додаткових інвестицій у треті сторони. Але з 2005 року я пам’ятаю, що мав успіх у Red-Gate SQL Backup ; Quest LiteSpeed теж непоганий, але я не маю уявлення, які зусилля докладаються до нього з моменту придбання Dell.
5. Якщо ваші бази даних відновляться повністю, ви можете пройти довше між повними резервними копіями, торгуючи це тим, що, якщо вам доведеться відновитись до певного моменту, у вас буде потенційно більше журналів для відновлення. Ви можете поєднати цю опцію з пропозицією Алі нижче про прийняття різниць протягом тижня - якщо вам довелося відновити в четвер, вам потрібно буде відновити 1 повний, 1 розл. І журнали з моменту розл.
6. Якщо у вас багато даних, які є несвіжими та незмінними, ви можете розглянути можливість розміщення даних в іншій базі даних з іншим планом відновлення або, принаймні, на різних групах файлів, і розділити свої операції з резервного копіювання таким чином. Якщо у вас є довідкові або архівні дані, які можна зробити лише для читання, і якщо ви просте відновлення, ви можете перемістити їх у власну файлову групу, доступну лише для читання, створити резервну копію один раз, і не потрібно включати її у свої нічні резервні копії. колись знову. Перегляньте ці теми MSDN:

Виконання відрізків відновлює

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

Це поширена проблема, є кілька рішень і дійсно залежить від вашого оточення. Перейдемо до них:

1- Стиснення резервного копіювання на льоту

У 2008 р. Резервне копіювання R1 стало доступним у Enterprise, у 2008R2 - у Standard. Це ВЕЛИЧЕЗНО. Це заощадить багато часу. Якщо ви можете оновити, перейдіть на це. Якщо ви не можете, перевірте утиліту HyperBak RedGate або Quest LiteSpeed . Обидва мають безкоштовну пробну версію.

2- Повні та різні резервні копії

Я отримав у спадок базу даних 2TB, яка спричинила багато очікувань часу для 24-годинної великої інтернет-компанії, яку я працював. Ми ввімкнули повне та диференційоване резервне копіювання, що заощадило нам багато часу. Я б зайняв повну резервну неділю 12:00 ранку, коли активність була низькою, і я брав різницю протягом тижня. Це заощадило багато місця. Робота Diff відрізняється від журналів транзакцій, оскільки вони працюють на сторінках бази даних. Будь-які змінені сторінки є резервними копіями. Таким чином, ви робите повне відновлення, а потім відновлення diff, щоб додати змінені сторінки.

3- Яка ваша пляшка?

Для діагностики важливий аналіз пляшки. Ви створюєте резервну копію на той же дисковий масив, що і ваші файли даних? Чи прив’язані ваші файли даних? Який ваш DISK SEC / READ та DISK SEC / WRITE для дисків даних під час резервного копіювання? Я змінив резервні копії, щоб створити 4 файли. У кожного файлу є свій власний програмування потоків, і в нашому SAN це вийшло чудово. Перевірте це, я поголив 45 хвилин, просто створивши 4 файли резервної копії. Просто переконайтесь, що показники вашого диска, перелічені вище, низькі. Отримайте базову лінію.

4- Повторити на іншому сервері та створити резервну копію

Цей трохи просунутий. Ви повинні переконатися, що ваша реплікувана база даних оновлена, і вам потрібен належний моніторинг. Якщо це все-таки, ви можете просто створити резервну копію реплікуваної бази даних.

Ви можете використовувати ці параметри:

BLOCKSIZE - виберіть розмір 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536. (у КБ)

BUFFERCOUNT - Вказує загальну кількість буферів вводу / виводу, які будуть використані для операції резервного копіювання. Ви можете вказати будь-яке додатне ціле число; однак велика кількість буферів може спричинити помилки "поза пам'яттю" через недостатній віртуальний адресний простір у процесі Sqlservr.exe. - від MSDN

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

Спробуй це. це вирішило проблему з минулим терміном, в той час як великі розміри db.

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