Резервні копії SQL Server - пара питань

Ми виконуємо роботу з резервного копіювання щотижня о 21:00 по п’ятницях, і ми стикаємося з декількома проблемами щодо дискового простору (який часом стає дуже низьким) та продуктивності. Ми дивимось на оптимізацію / оптимізацію того, що відбувається, і будемо вдячні за ваші коментарі.

Конкретно:

1. Процес резервного копіювання займає близько 4 годин, щоб оновити статистику під час резервного копіювання. Чи можемо ми безпечно відключити цей процес, щоб заощадити час?

2. Ми втрачаємо дисковий простір дуже регулярно і задаємось питанням, чи варто повторно переміщувати процес. В даний час він створює резервну копію, а потім видаляє попередню резервну копію, і ось що займає дисковий простір. Чи можемо ми спочатку видалити попередню попередню, а потім зробити резервну копію?

Будь-які інші коментарі чи спостереження будуть дуже вітаються EDIT: Загальний розмір файлів SQL на сервері становить близько 35 ГБ. Один db має розмір близько 25 ГБ, а інші шість ділять інші 10 Гб.

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

(2) Чи копіюєте ви резервну копію на стрічку чи інший диск? Якщо так, то я зазвичай прибираю файли, перш ніж створювати нові резервні копії локально. Якщо ні, то, якщо я зачищаю місце для зберігання, я б розглядав можливість завантаження файлу резервної копії до створення нового. (Тобто, якщо ви не можете ввімкнути компресію на резервних копіях , як запропонував @Simon , це також заощадить певний простір.)

Тут я можу відповісти лише на питання 2. Рекомендую поглянути на стислі резервні копії.

• SQL Server може це зробити, якщо у вас є корпоративне видання 2008 року. Якщо не дивитися на два нижче.
• Квест Litespeed
• Резервне копіювання SQL RedGate

1) Я не бачу прямого зв'язку між завданням створення резервної копії та завданням оновлення статистики. Тож ви можете розділити їх без проблем. Я побачив би частину оновлення статистики, пов’язану із завданням, яке б знеструмило / відновило індекси.

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

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

Бічна примітка 2: як уже вказав Саймон, вкладайте час / гроші в стиснуті резервні копії, якщо у вас є проблеми з простором. У цьому питанні ви можете побачити багато ідей: Найменша можлива резервна копія… за допомогою SQL Server .

Ваша задача оновлення статистики не повинна займати 4 години для бази даних 3-4 Гб. Швидше за все, у вас є деякі проблеми вводу / виводу або у вас сильно фрагментарна база даних, яка створює проблеми вводу / виводу. Запустіть відновлення дефрагментів або індексів на базі даних і подивіться, чи покращує це продуктивність. Якщо ні, то запустіть парфмон і перевірте, де знаходиться вузьке місце.

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

Це не рішення вашої проблеми. Зрозуміти, як мати більше місця для обох, було б правильним шляхом зробити це.