Сегодня я получил запрос в службу поддержки от моего хостинг-провайдера (они его создали), в котором говорилось, что мой журнал транзакций SQL заполнился, и они усекли его, уменьшили и сбросили до модели полного восстановления.
Я не понимаю, почему они позволяют журналам транзакций заполняться до такой степени, что веб-сайт падает и требует ручного вмешательства. Я спросил их, делают ли они резервные копии баз данных, и они ответили (на немного ломаном английском)
Мы делаем резервные копии каждый день и храним резервные копии в течение недели. Журнал транзакций необходимо вести, потому что мы не знаем, какую транзакцию вы совершаете, и он может содержать важную информацию. Журнал самой резервной копии усечен.
Смущает последнее предложение. Кажется, это подразумевает, что они не делают резервные копии журналов, что, я думаю, нормально, если они запускают полное резервное копирование каждый день, но тогда, если это так, почему журналы транзакций не усекаются каждый день?
Я попытался вежливо посоветовать им, вероятно, обрезать журналы, но я не уверен, что они правильно понимают, как работают журналы. Я могу придерживаться SQL Server, но я не эксперт и не уверен в себе, чтобы называть их по этому поводу. Также я не знаю, какое программное обеспечение для резервного копирования они используют и как оно настроено.
Итак, оправданы ли они в том, что никогда не усекают журналы? Есть какой-нибудь сценарий, где это поможет? Кажется, у них есть система, с помощью которой они получают предупреждение, когда журнал заполнен, и они входят и вручную запускают сценарий усечения. Это работает, но неэлегантно, и означает, что мой веб-сайт падает каждые несколько недель, пока они не заметят проблему и не исправят ее, после чего они удаляют журнал, который, как они сказали мне ранее, мне нужно было сохранить. Аххххх!
Что бы вы сделали, о эксперт по SQL Server?
Кажется, у них есть система, с помощью которой они получают предупреждение, когда журнал заполнен, и они входят и вручную запускают сценарий усечения. Это работает, но неэлегантно, и означает, что мой веб-сайт падает каждые несколько недель, пока они не заметят проблему и не исправят ее, после чего они удаляют журнал, который, как они сказали мне ранее, мне нужно было сохранить.
Ага, это нехорошо.
Предполагая, что ваша база данных находится в процессе полного восстановления (потому что, как указывает Крис Маккеун, если бы это было просто, она бы автоматически усекала), вот что происходит:
Когда вы / они запускаете полное резервное копирование, оно включает текущее состояние базы данных на данный момент. Оно делает не обрезать журнал.
Когда вы / они запускаете резервную копию журнала, она выполняет резервное копирование транзакций и, если контрольная точка произошла, обрезает (не сжимает) журнал, освобождая место для дополнительных транзакций. Таким образом, журнал транзакций должен иметь более или менее стабильный размер и оставаться в нем, исключая странное поведение или недостаточно частое резервное копирование ваших журналов.
Они сказали:
Мы делаем резервные копии каждый день и храним резервные копии в течение недели. Журнал транзакций необходимо вести, потому что мы не знаем, какую транзакцию вы совершаете, и он может содержать важную информацию. Журнал самой резервной копии усечен.
Гм. Да. Я не уверен в этом.
Я бы попросил их пояснить, какие виды резервного копирования они запускают ежедневно: полное, дифференциальное или резервное копирование журналов. Если они запускают ночные журналы и никогда не запускают полный, ну, выбросив на прошлой неделе, они нарушили свою цепочку восстановления и никогда не смогут восстановить в случае сбоя. Они также, как указывает Крис Маккеон, разорвали свою цепочку восстановления, усекая журналы.
Я не могу сказать наверняка, основываясь на предоставленной информации, но похоже, что они вообще не создают резервные копии журналов. Если это так, то еженощное резервное копирование вам не подходит, и журнал нужно создавать чаще.
Я также не знаю, что Соглашение об уровне обслуживания для восстановления SQL связано с вашим контрактом на хостинг, но вы, возможно, захотите вернуться к нему, чтобы выяснить, соответствуют ли они на основе этой информации.
Если база данных использует модель ПОЛНОГО восстановления и журнал транзакций постоянно увеличивается, это означает, что они действительно не делают регулярных резервных копий журнала транзакций.
Это проблема? Это зависит от того, что ваш интернет-провайдер ожидает от восстановления в случае аварии. Если они говорят, что могут восстановить на определенный момент времени между полными резервными копиями, они в настоящее время лгут. Усечение журналов вручную нарушит цепочку резервных копий журналов и сделает восстановление на определенный момент времени невозможным.
Если они гарантируют возможность восстановления только до последней полной резервной копии, им следует просто переключиться в режим ПРОСТОГО восстановления, и тогда журналы будут автоматически усечены.
Смущает последнее предложение. Кажется, это означает, что они не делают резервные копии журналов,
Все в порядке. Когда вы выполняете ПОЛНУЮ РЕЗЕРВНУЮ РЕЗЕРВНУЮ КОПИЮ, стандартно обрезать журнал, поскольку в этот момент у вас есть резервная копия данных.
В основном они полагаются на ежедневные полные резервные копии и локальный журнал tx на данный момент, который в данном случае просто недостаточно велик. Затем они должны расширять журнал (и вы платите за это) или переходить к резервному копированию журнала через регулярные интервалы (15 минут, ежечасно).
Если они не усекают журнал после полного резервного копирования, они - «не умные». Нет смысла хранить полный журнал после создания полной резервной копии. Но это не так - как говорится: «Сама резервная копия имеет усеченный журнал».
Случилось так, что вы использовали больше места для дневного журнала, чем было выделено. Скорее всего, вы перерастете их настройку с низким уровнем использования.