Комментарии 10
В погоне за мнимым выигрышем по месту, вы упускаете то, что SQL Server выделяет место страницами. Это я к тому, что transaction log не нужно сжимать после копирования. Файл будет прекрасно использоваться повторно и не вырастет более, чем вырос до бекапа. В тоже время, советуя использовать быстрый диск и сжимая файл transaction log вы обрекаете пользователей ждать пока SQL server обнулит страницы, которые он будет добавлять в конец transaction log.
Насчет идеи бекапа из собственного приложения я ни агитировать, ни возражать не буду, потому что каждой задаче своё решение, не всегда совпадающее с best practices. Каждый выбирает свой путь.
Насчет идеи бекапа из собственного приложения я ни агитировать, ни возражать не буду, потому что каждой задаче своё решение, не всегда совпадающее с best practices. Каждый выбирает свой путь.
Вы правы, я забыл про эту особенность. Внесу правки в статью.
Сейчас поясню почему у себя оставил такое решение с усечением журнала. Было приложение, которое не правильно отрабатывалось в автоматическом режиме и из-за него засирался журнал транзакций. Примерно за час работы объем журнала вырастал на 20-50 гигов. Чтобы отследить, исправлены ли ошибки в работе приложения, нужно было усекать файл транзакций и смотреть, что растет он или нет.
Сейчас поясню почему у себя оставил такое решение с усечением журнала. Было приложение, которое не правильно отрабатывалось в автоматическом режиме и из-за него засирался журнал транзакций. Примерно за час работы объем журнала вырастал на 20-50 гигов. Чтобы отследить, исправлены ли ошибки в работе приложения, нужно было усекать файл транзакций и смотреть, что растет он или нет.
Мы аналогичный самописный инструмент используем, т.к. его можно отдавать клиентам, у которых наше приложение работает на их собственном SQL Server'е, чтобы их не обучать настройке бэкапа средствами SQL.
>>Из-за нехватки времени модуль восстановления еще не реализован
А у нас реализован :-P
Собственно все восстанавливается быстро даже и вручную, если не нужно восстанавливать цепочку бэкапов журнала транзакций. Для журнала транзакций без автоматизации не знаю как жить, т.к. восстанавливать длинную цепочку (50+ файлов например) вручную — тот еще гемор (о чем думали в MS?)
>>Из-за нехватки времени модуль восстановления еще не реализован
А у нас реализован :-P
Собственно все восстанавливается быстро даже и вручную, если не нужно восстанавливать цепочку бэкапов журнала транзакций. Для журнала транзакций без автоматизации не знаю как жить, т.к. восстанавливать длинную цепочку (50+ файлов например) вручную — тот еще гемор (о чем думали в MS?)
Есть хорошая бесплатная вещь, частично имеющая отношение к теме — www.lazycoding.com/products.aspx. Называется SQL Scheduler.
СУБД начнет вести записи журнал транзакций
Для порядка отмечу, что MS SQL Server ведёт журналирование транзакций независимо от модели восстановления. И в случае сбоя сервера то, что было зафиксировано — сохранится, от того, что не было зафиксировано, не останется следа — и в случае простого восстановления тоже.
Полное восстановление имеет то преимущество, что при нём резервное копирование можно так настроить, что БД до почти-актуального состояния можно будет поднять в случае не просто сбоя, а полной потери сервера. Включая все его диски.
При потере сервера потеряна будет только та часть, которая не попала в последнюю резервную копию журнала. Поэтому, кстати, резервное копирование журнала имеет смысл проводить часто.
При переключении на полную модель восстановления СУБД не «начинает» вести журнал транзакций. Она перестаёт его очищать до того момента, как будет выполнено резервное копирование журнала. Запускается этот процесс созданием полной резервной копии — после этого место в журнале не помечается как свободное до тех пор, пока не создана резервная копия журнала. Это довольно сильная ловушка для неопытных администраторов, которые включают эту модель (ну например потому, что именно такая модель восстановления у БД model), не собираясь заниматься резервным копированием журналов вообще. Журналы начинают чрезвычайно пухнуть, и усмирить процесс их роста невозможно.
Для порядка отмечу, что MS SQL Server ведёт журналирование транзакций независимо от модели восстановления. И в случае сбоя сервера то, что было зафиксировано — сохранится, от того, что не было зафиксировано, не останется следа — и в случае простого восстановления тоже.
Полное восстановление имеет то преимущество, что при нём резервное копирование можно так настроить, что БД до почти-актуального состояния можно будет поднять в случае не просто сбоя, а полной потери сервера. Включая все его диски.
При потере сервера потеряна будет только та часть, которая не попала в последнюю резервную копию журнала. Поэтому, кстати, резервное копирование журнала имеет смысл проводить часто.
При переключении на полную модель восстановления СУБД не «начинает» вести журнал транзакций. Она перестаёт его очищать до того момента, как будет выполнено резервное копирование журнала. Запускается этот процесс созданием полной резервной копии — после этого место в журнале не помечается как свободное до тех пор, пока не создана резервная копия журнала. Это довольно сильная ловушка для неопытных администраторов, которые включают эту модель (ну например потому, что именно такая модель восстановления у БД model), не собираясь заниматься резервным копированием журналов вообще. Журналы начинают чрезвычайно пухнуть, и усмирить процесс их роста невозможно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация настройки резервного копирования MS SQL с помощью .NET приложения