У меня есть экземпляр SAP ECC, который работает на SQL Server 2000. База данных настроена с использованием модели полного восстановления, но резервная копия журнала транзакций никогда сделано (не мой выбор). Вместо этого ежедневно сохраняется полная резервная копия.
Это, конечно, означает, что файл журнала транзакций продолжает расти. Чтобы контролировать его размер, раз в месяц журнал транзакций усеченный, а потом сжался с участием dbcc shrinkfile (опять же, не мой выбор).
Как вы можете легко догадаться, это работает не очень хорошо, потому что иногда файл журнала растет слишком быстро, заполняет свой раздел, и база данных зависает. Меня попросили исправить эту ситуацию.
Если бы выбор был за мной, я бы делал резервную копию журнала транзакций несколько раз в день, но лицо, которое на самом деле отвечает, этого не хочет.
Второй очевидный выбор - чаще запускать задание усечения и сжатия. Но насколько я понимаю, это не лучший выбор. Я прочитал одну вещь Вот беспокоит меня больше всего:
усекая журнал в (время), вы только что полностью лишили законной силы целостность журнала, и НЕТ способа восстановить ЛЮБЫЕ данные, прошедшие (время последней полной резервной копии).
Это правда? Означает ли это, что используемый сейчас файл журнала совершенно бесполезен? Если бы я начал регулярное резервное копирование сейчас, можно ли было бы использовать его для восстановления на определенный момент времени? Будут ли резервные копии журналов согласованы? Мне лучше использовать простую модель восстановления?
Спасибо.
Лучше использовать простую модель восстановления. файл журнала, для которого не создается резервная копия, в любом случае бесполезен. Можно восстановить ТОЛЬКО резервные копии. Итак, если вы не сделаете резервную копию, что хорошего в журнале?
Кто бы ни решил, что работать в IT не должно, но это не твоя прибмэ. Когда что-то происходит, ваша компания становится историей.
Это в основном правильно, если вы усекаете журнал, тогда любые резервные копии журнала, которые вы пытаетесь сделать впоследствии, совершенно бесполезны (я не знаю, позволит ли SQL Server даже сделать резервную копию журнала после этого - вполне может, что нет, просто потому что это было бы бесполезно). Вам необходимо сделать еще одну полную или дифференциальную резервную копию, чтобы перезапустить цепочку журналов, после чего вы можете снова начать делать резервные копии журналов.
И даже если вы никогда не создадите резервную копию журнала, он все равно может оказаться полезным. Если том, на котором размещен файл данных, умирает, вы можете выполнить резервную копию журнала (предположительно довольно большого размера) и использовать эту самую резервную копию после восстановления полной резервной копии с помощью NORECOVERY и иметь небольшую потерю данных или ее отсутствие. Однако, если том, на котором размещен файл журнала, умирает, вы в основном останетесь без резервных копий журнала.
Учитывая указанные вами ограничения (то есть отсутствие регулярных резервных копий журналов), я бы продолжил ваш текущий подход, но убедитесь, что полное резервное копирование выполняется сразу после усечения. Это по-прежнему паршивый способ работы, но он безопаснее, чем использование простого восстановления или более частого усечения журнала без последующего полного резервного копирования.
Но если вы сможете убедить ответственных сотрудников, даже ежедневное резервное копирование журнала станет значительным улучшением. Возможно, запланируйте, чтобы это происходило непосредственно перед полным резервным копированием.