У меня есть вопрос относительно резервных копий журнала транзакций в sql server 2008. В настоящее время я делаю полные резервные копии раз в неделю (воскресенье) и резервные копии журналов транзакций ежедневно. Я поместил полную резервную копию в папку 1 в воскресенье, а затем в понедельник я также поместил первую резервную копию журнала транзакций в ту же папку. Во вторник, прежде чем я сделаю вторую резервную копию журнала транзакций, я перемещаю первую резервную копию журнала транзакций из папки 1 и помещаю ее в папку 2, а затем беру вторую резервную копию журнала транзакций и помещаю ее в папку 1. То же самое в среду, четверг и так далее. Обычно в папке1 у меня всегда есть последняя полная резервная копия и последняя резервная копия журнала транзакций, в то время как другие резервные копии журнала транзакций находятся в папке2. Мои вопросы: когда сервер sql собирается сделать, скажем, 4-ю (четверг) резервную копию журнала транзакций, ищет ли он предыдущие резервные копии журнала транзакций (1-й, 2-й и 3-й), чтобы эта новая резервная копия включала только транзакции из последняя резервная копия или у него есть другой способ узнать, есть ли другие резервные копии журналов транзакций. По сути, я спрашиваю об этом, потому что все мои резервные копии журнала транзакций кажутся примерно одинакового размера, и я думал, что их размер будет зависеть от количества транзакций с момента последнего резервного копирования журнала транзакций.
Пример: если у вас есть, скажем, полная резервная копия, а затем вы делаете резервную копию журнала транзакций, и эта резервная копия журнала транзакций составляет, скажем, 200 МБ, и теперь вы сразу же делаете еще одну резервную копию журнала транзакций, эта последняя резервная копия журнала транзакций должна быть значительно меньше, чем первый, потому что между этими двумя резервными копиями не было или почти не было транзакции, верно? По крайней мере, я так предполагал. Что происходит в моем случае, так это то, что эта вторая резервная копия почти такого же размера, что и первая, и мне интересно, связана ли это с тем, что я переместил первую резервную копию журнала транзакций в другую папку, поэтому теперь sql-сервер думает, что все, что я have - это просто полная резервная копия, которая затем получает все транзакции, которые произошли с момента создания полной резервной копии, и помещает их во вторую резервную копию журнала транзакций.
Кто-нибудь может объяснить, верны ли мои предположения? Спасибо...
Крис и joeqwerty, Спасибо, ребята, за ответы. Я понимаю разницу между дифференциальным резервным копированием и резервным копированием журналов, но, полагаю, я не ясно выразился. Я всегда думал, что резервные копии журналов содержат все транзакции с момента последней резервной копии журнала (или полной резервной копии в случае первой резервной копии журнала), и вы только что подтвердили это, так что я думаю, что я был здесь. Что меня сбило с толку, так это то, что я сделал резервную копию журнала сегодня утром, а затем мне пришлось сделать еще одну (незапланированную) резервную копию журнала сегодня днем, и эти 2 оказались примерно одинакового размера, хотя на компьютере не должно было быть слишком много активности. db (хотя я могу ошибаться в этом). По сути, я боялся, что, перемещая старые файлы резервных копий журнала в другую папку, я `` заставляю '' SQL Server захватывать все транзакции с момента полной резервной копии (и, по сути, вести себя как дифференциальная резервная копия, потому что это то, что первая резервная копия журнала в любом случае) для каждой новой резервной копии журнала. Итак, я думаю, пока SQL-сервер отслеживает эту информацию внутри, и я могу перемещать файлы, я в порядке. Еще раз спасибо...
SQL-сервер не обращает внимания на файлы резервных копий на жестком диске, когда выполняет какие-либо последующие резервные копии. Он отслеживает все это внутри файла журнала базы данных.
Да (вообще говоря) размер резервной копии журнала транзакций будет в некоторой степени зависеть от того, сколько действий было выполнено с момента последней резервной копии журнала, но может быть минимальный размер.
Но еженедельное заполнение и ежедневное резервное копирование журналов - это своего рода необычный план. Гораздо более распространенными будут еженедельные полные и ежедневные дифференциалы, а также ежечасное резервное копирование журналов, если вам действительно нужно восстановление на определенный момент времени. +1 по ссылке Спенсера.
Я думаю, вы путаете резервные копии журналов транзакций и различия.
Резервная копия журнала SQL - это изменения с момента последней резервной копии журнала. Чтобы выполнить восстановление, вам понадобится полная резервная копия плюс полная цепочка резервных копий журналов, иначе вы не сможете восстановить данные на определенный момент времени. SQL отслеживает все внутри, поэтому не имеет значения, перемещаете ли вы файлы. Главное - это полная резервная копия плюс непрерывная цепочка ВСЕХ резервных копий журналов.
С другой стороны, резервная копия diff будет включать в себя все изменения с момента последней полной резервной копии, независимо от любых других резервных копий diff или журнала, которые вы сделали за это время.
Если ваш трафик согласован, ваши резервные копии журналов могут работать примерно с одинаковым размером, поскольку они в среднем содержат одинаковый объем транзакций в каждой.
Само собой разумеется ... но я все равно скажу ... часто проверяйте свои резервные копии, пробуя несколько тестовых восстановлений - это лучший способ узнать, есть ли в вашей стратегии какие-либо дыры.
Резервная копия журнала транзакций обрезает только неактивную часть журнала. Определение «неактивного» - это то, с чем, кажется, у многих людей возникают проблемы. Неактивная точка - это область журнала транзакций. позади в самый старый of: самая последняя контрольная точка или начало самой старой незавершенной транзакции. Для большинства баз данных самая последняя контрольная точка определяет неактивную часть журнала.
Итак, когда же появляется контрольная точка БД? Только когда нужно. То есть, когда вы его выключаете, журнал становится слишком полным или активная часть журнала становится настолько большой, что БД считает, что это займет больше времени, чем recoveryinterval играть вперед в случае неудачи. Идея нечастых контрольных точек заключается в том, что БД знает, что запись на диск стоит дорого, поэтому она пытается сохранить в памяти как можно больше.
Итак, в вашем случае, когда вы делаете две резервные копии tlog один за другим без естественной контрольной точки или вы форсируете контрольную точку (с checkpoint command) вы дважды выполняете резервное копирование одного и того же фрагмента журнала транзакций, потому что он все еще считается активным.
(Этот вопрос, вероятно, больше подходит для serverfault.com, а не для stackoverflow.)
Резервное копирование журнала транзакций обеспечивает ТОЛЬКО резервные копии транзакций, НЕ УЖЕ резервированные предыдущей резервной копией журнала транзакций.
То есть для восстановления вам понадобится полная резервная копия И все резервные копии журнала транзакций с момента начала полного резервного копирования.
HTH
Я думаю, что вы можете спутать резервные копии журналов транзакций с дифференциальными резервными копиями.
http://technet.microsoft.com/en-us/library/aa337534%28SQL.100%29.aspx