Как мой хостинг-провайдер должен обрабатывать журналы транзакций SQL Server?
Сегодня я получил билет поддержки от моего хостинг-провайдера (он его создал), который сказал, что мой журнал транзакций SQL заполнен и что они урезали его, сократили его и сбросили до полной модели восстановления.
Я не понимаю, почему они позволяют журналам транзакций заполняться до такой степени, что веб-сайт падает и требует ручного вмешательства. Я спросил их, резервируют ли они базы данных, и они ответили (на немного ломаном английском)
Мы выполняем резервное копирование каждый день и сохраняем резервные копии в течение недели. Необходимо вести журнал транзакций, потому что мы не знаем, какую транзакцию вы совершаете, и он может содержать важную информацию. Сама резервная копия имеет усеченный журнал.
Смущен последним предложением. Кажется, подразумевается, что они не создают резервные копии журналов, что, я думаю, нормально, если они выполняют полное резервное копирование каждый день, но тогда, если это так, почему журналы транзакций не усекаются каждый день?
Я пытался вежливо предположить, что они, вероятно, должны обрезать журналы, но я не уверен, что они правильно понимают, как работают журналы. Я могу справиться с SQL Server, но я не эксперт, и я не уверен в себе, чтобы вызвать их на это. Также я не знаю, какое программное обеспечение для резервного копирования они используют или как оно настроено.
Итак, оправданы ли они тем, что никогда не усекают журналы? Есть ли сценарий, где это помогает? Кажется, у них есть система, в которой они получают предупреждение, когда журнал полон, и входят и вручную запускают усеченный скрипт. Это работает, но это не элегантно, и означает, что мой веб-сайт падает каждые несколько недель, пока они не заметят проблему и не исправят ее, после чего они удаляют журнал, который они сказали мне ранее, который я должен был сохранить. Arghghghgh!
Что бы вы сделали, о эксперт по SQL Server?
3 ответа
Кажется, у них есть система, в которой они получают предупреждение, когда журнал полон, и входят и вручную запускают усеченный скрипт. Это работает, но это не элегантно, и означает, что мой веб-сайт падает каждые несколько недель, пока они не заметят проблему и не исправят ее, после чего они удаляют журнал, который они сказали мне ранее, который я должен был сохранить.
Да, это не хорошо.
Предполагая, что ваша база данных полностью восстановлена (потому что, как указывает Крис МакКаун, если бы она была простой, она бы автоматически усекалась), вот что происходит:
Когда вы / они запускаете полную резервную копию, она включает текущее состояние базы данных на данный момент. Он не усекает журнал.
Когда вы / они запускаете резервное копирование журнала, оно создает резервные копии транзакций и, предполагая наличие контрольной точки, усекает (а не сокращает) журнал, освобождая место для дополнительных транзакций. Таким образом, журнал транзакций должен найти более-менее стабильный размер и оставаться там, за исключением странного поведения или недостаточного резервного копирования журналов.
Они сказали:
Мы выполняем резервное копирование каждый день и сохраняем резервные копии в течение недели. Необходимо вести журнал транзакций, потому что мы не знаем, какую транзакцию вы совершаете, и он может содержать важную информацию. Сама резервная копия имеет усеченный журнал.
Um. Да уж. Я не уверен в этом.
Я бы попросил их уточнить, какие резервные копии выполняются ежедневно: выполняется ли полная, разностная или журнальная. Если они ведут ночные журналы и никогда не запускают полное, ну, выбросив на прошлой неделе, они разорвали свою цепочку восстановления и никогда не смогут восстановить в случае сбоя. Они также, как указывает Крис МакКаун, разорвали свою цепочку восстановления, укоротив логи.
Я не могу сказать наверняка, основываясь на предоставленной информации, но, похоже, похоже, что они вообще не выполняют резервное копирование журналов. Если это так, то ночное резервное копирование не сокращает его для вас, и необходимо чаще выполнять резервное копирование журнала.
Я также не знаю, что Соглашение об уровне обслуживания для SQL восстанавливается с вашим хостинг-контрактом, но вы можете вернуться к нему, чтобы выяснить, соответствуют ли они на основе этой информации.
Если база данных использует модель восстановления FULL и журнал транзакций постоянно растет, это означает, что они действительно не выполняют регулярное резервное копирование журнала транзакций.
Это проблема? Это зависит от ожиданий, которые ваш интернет-провайдер дает вам в отношении восстановления в случае бедствия. Если они говорят, что могут восстановить момент времени между полными резервными копиями, то они в настоящее время лгут. Усечение журналов вручную приведет к разрыву цепочки резервного копирования журналов и невозможности восстановления на определенный момент времени.
Если они гарантируют только возможность восстановления до последней полной резервной копии, им следует просто переключиться в режим восстановления SIMPLE, и тогда журналы будут автоматически обрезаны.
Смущен последним предложением. Кажется, это означает, что они не копируют журналы,
Все в порядке. Когда вы делаете полное резервное копирование, стандартным является усечение журнала, так как в этот момент у вас есть резервная копия данных.
В основном они полагаются на ежедневные полные резервные копии и локальный журнал передачи сообщений, что в данном случае просто недостаточно. Затем они должны расширить журнал (и вы платите за него) или перейти к резервному копированию журнала через равные промежутки времени (15 минут, каждый час).
Если они не усекают журнал после полного резервного копирования, они - "не умные". Нет смысла вести полный журнал после полного резервного копирования. Но это не так - как говорится: "У самой резервной копии есть усеченный журнал".
Случилось так, что вы использовали больше места для дневного журнала, чем они выделили. Скорее всего, вы перерастите их низкую настройку использования.