Журнал транзакций и зеркалирование - ищите самое глупое объяснение


8

Прежде всего, я должен признать, что я борюсь с концепцией журнала транзакций. Я имею в виду - я понимаю, что это журнал всех транзакций, которые происходят в базе данных, но когда дело доходит до правильного помещения его в контекст какой-то задачи, мне явно чего-то не хватает. Итак, всем, кто ответит на вопрос - пожалуйста, не стесняйтесь углубляться в теорию, лежащую в основе журнала транзакций.

Главный вопрос - у меня есть база данных SQL Server 2008 и 2 ГБ, которые мне нужно отразить (имеет журнал транзакций 12 ГБ). Если бы я не зеркалировал эту базу данных, я полагаю, что я мог бы либо переключиться в простой режим, либо обрезать журнал после резервного копирования. Но в этом случае - что мне делать, если я хочу держать этот журнал транзакций под контролем? Как я понимаю - мне нужно вести весь этот журнал транзакций, если я хочу иметь возможность легко зеркалировать базу данных (просто сделайте полное резервное копирование).

Есть ли способ обойти это? В идеале хотелось бы, чтобы было возможно сделать резервное копирование, в котором и MDF, и LDF хранятся в 1 файле каждый раз, и после того, как резервное копирование выполнено, журнал транзакций (LDF) для базы данных уменьшен до 0. Проблема с этим сценарием - инкрементное резервное копирование - если моя первая резервная копия усеченный журнал, я предполагаю, что вторая резервная копия должна будет ссылаться на первую, если я захочу сделать зеркалирование позже (то есть, я застряну с сохранением множества файлов вместо одного).

Итак, может ли кто-нибудь просветить меня на эту тему? Я понимаю, что я пытаюсь заполнить множество пробелов здесь и что мои предложенные «решения» могут быть не самыми лучшими, но я был бы искренне признателен, если бы кто-то мог подтолкнуть меня в правильном направлении в журналах транзакций, как они влияют на зеркалирование и лучше всего практики с этими двумя.

Ответы:


5

Журнал транзакций является важным методом для восстановления вашей базы данных в определенное время. Если у вас большая база данных> 500 ГБ и вам необходимо восстановить базу данных из полной резервной копии, это будет стоить очень много времени. Также, если вы выполняете полное резервное копирование базы данных каждый раз, подумайте, сколько времени может занять это резервное копирование.

Очень простой концепцией для SQL Server может быть: Установить полную модель восстановления базы данных

Создайте план обслуживания (1) в SQL Server:

  • Делайте FullBackup каждую неделю, может быть, в D: \ yourbackup \ FullDBBackup.bak
  • Делайте дифференциальное резервное копирование каждые два дня в D: \ yourbackup \ DiffBackup.bak
  • Делайте каждые 2 часа Резервное копирование журнала транзакций в D: \ Yourbackup \ Tranlogbackup.trn

Создайте план обслуживания (2) в SQL Server:

  • Удалите все старые файлы 8 дней из D: \ yourBackup * .bak
  • Удалите все старые файлы 3 дня из D: \ yourBackup * .trn

В этом случае вы можете восстановить свою базу данных в указанное время, очень быстро и очень просто. SQL Server будет автоматически управлять вашими «резервными» файлами, более старые файлы будут удалены по истечении определенного времени.

Я бы посоветовал вам прочитать о журнале транзакций SQL Server здесь:

http://www.sqlservercentral.com/articles/Design+and+Theory/63350/

Для использования планов обслуживания в SQL Server просто спросите BING / Google: D

Вы должны создать небольшой тестовый БД и проверить это, прежде чем идти в производство


У меня нет проблем с полным резервным копированием и временем, так как я могу остановить всю систему, пока они не закончат работу. Один вопрос на ваш ответ - обрезать ли журнал транзакций в этом сценарии? Если нет, то я понимаю, что мне нужен только последний FullDBBackup.bak для восстановления базы данных? Меня не волнуют конкретные моменты времени - все, что меня волнует, - это последняя версия БД, которую я получаю при резервном копировании. Смысл - мне не нужны журналы транзакций; Я просто держу их только из-за зеркалирования. Есть ли способ обойти это?
nikib3ro

2
1. вы не можете обрезать свой журнал: D 2. Если вы сделаете резервную копию вашего журнала, SQL Server предоставит это пространство для повторного использования в вашем файле журнала. просто протестируйте dbcc sqlperf ('logpsace') перед резервным копированием, а затем сделайте то же самое после резервного копирования. и в конце вам нужен журнал транзакций ... просто протестируйте мой пример

Я наконец-то смог реализовать ваши предложения в тестовой среде, и пока мне нравится то, что я вижу. Просто, пожалуйста, дайте мне знать, если я правильно понимаю - если мне теперь нужно восстановить базу данных, я сначала использовал бы полное резервное копирование, которое я сделал, а затем, используя комбинацию разностных резервных копий и журналов транзакций, я смог бы восстановить свою базу данных до определенный момент времени? Я прав? И также я предполагаю, что для зеркалирования мне просто нужно остановить сервер и сделать полную резервную копию? Или мне понадобятся журналы транзакций для настройки зеркалирования? Еще раз спасибо за вашу помощь и ответы!
nikib3ro

3

Чтобы воспользоваться преимуществами зеркального отображения, вы должны иметь базу данных в режиме полного восстановления и делать резервные копии журнала транзакций, чтобы не допустить роста файла журнала. Если вам не нужны резервные копии журналов, просто очистите их через x часов с планом обслуживания, но их нужно взять.

Чтобы очистить среду, вы должны удалить зеркалирование, переключить режим восстановления на простой, уменьшить размер файла журнала с помощью рекомендованного Пола Рэндала пути , вернуться в режим полного восстановления, настроить полное резервное копирование и резервное копирование журнала, а затем повторно инициализировать зеркало. Вы можете попытаться уменьшить размер журнала, когда зеркальное отображение установлено, но сначала будет проще удалить его. 1 ГБ не должен быть слишком плохим для повторной инициализации.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.