Заранее благодарим за любую помощь, которую вы можете мне предложить по этой теме. Это мой первый пост об ошибке сервера, полученный из stackoverflow.
Я настраивал на работе экземпляр SQL Server для установки приложения, которое мы продаем, и в идеале мы хотим оставить его само по себе. С этой целью я установил ряд планов обслуживания, которые запускают резервное копирование, очищают таблицы журналов, восстанавливают индексы и т. Д.
Все это работает нормально, но я немного запутался в том, как работает резервная копия. Я выбрал полноценное еженедельное полное резервное копирование с ночным дифференциальным резервным копированием и ежечасным резервным копированием журнала транзакций. Все работало нормально, но по мере увеличения использования системы я заметил, что ежечасные резервные копии журналов транзакций становятся огромными. До 2 ГБ, а иногда и больше, в то время как полная резервная копия занимает всего 90 МБ. Это может быть нормально, но мне кажется странным. Насколько я понял, резервное копирование журнала транзакций должно иметь очень небольшое влияние на сервер, но как это может быть, запись 2 ГБ данных никогда не будет такой быстрой операцией. И, конечно же, размер этих журналов вызывает проблемы с дисковым пространством (спецификации сервера скупы - не мой выбор), и у нас была некоторая потеря обслуживания.
Итак, на самом деле два вопроса: почему резервные копии журналов транзакций такие большие, и я, вероятно, делаю что-то не так.
Во-вторых, стоит ли мне беспокоиться о резервных копиях журналов транзакций, почему бы просто не использовать ежечасные дифференциальные резервные копии, поскольку они имеют размер всего около 20 МБ.
Если кому-то захочется указать мне на хорошее чтение по теме резервного копирования, я также буду признателен. У меня есть хорошая книга, выпущенная SQL Server 2005, но мне, вероятно, понадобится книга с более подробной информацией о резервном копировании, чтобы действительно получить информацию, необходимую для разработки соответствующего плана резервного копирования.
Одна из причин такого поведения - наличие базы данных, выполняющей множество обновлений, вставок и удалений. В вашем случае ваша общая база данных может не увеличиваться в размере, если данные только обновляются или строки вставляются / удаляются. Наличие вашей базы данных в Модель полного восстановления, будет означать, что серверу sql необходимо вести текущий журнал всех этих изменений, что позволяет выполнять восстановление на определенный момент времени, но, следовательно, означает, что резервные копии журналов будут большими.
Во-первых, я бы хотел спросить, действительно ли вашему приложению требуется восстановление на определенный момент времени? Не то чтобы это решение вы могли принять, это бизнес-решение. Если бизнес решит, что ему нужен момент времени, подумайте о том, чтобы делать резервные копии журналов транзакций через меньшие промежутки времени, и пусть власти знают, что вам понадобится много хранилища!
Если компания решит, что ей не требуется определенное время, но требуется возможность восстановления с точностью до минуты, рассмотрите возможность использования Модель восстановления с неполным протоколированием и создание резервных копий журналов каждые несколько минут. Это может уменьшить размер ваших резервных копий журнала, в зависимости от того, что делает приложение, поскольку некоторые операции могут быть минимально зарегистрированы. Это означает, что когда происходит резервное копирование журнала, оно фактически копирует страницы данных минимально регистрируемых транзакций.
Конечно, если компания довольна потерей данных на несколько часов или дней, переход на Простая модель восстановления с комбинацией полного / дифференциального резервного копирования - это лучший способ.