База данных всегда запускается в режиме восстановления

Каждый раз, когда я перезагружаю свой сервер, база данных всегда находится в режиме восстановления, и для ее нормальной работы требуется около 20 минут. Это всегда и только происходит, когда я перезагружаю сервер, поэтому у меня есть несколько вопросов ...

Мне сказали, что это может быть вызвано большим файлом журнала? Может ли это быть правильным? Если нет, то какие могут быть другие причины?
Мне нужно уменьшить пространство файла журнала, чтобы предотвратить восстановление. Что лучше: сжатие или усечение?
Как я могу сжать или обрезать файл журнала / базу данных, чтобы уменьшить размер? Какой синтаксис?

В настоящее время я использую Microsoft SQL Server 2008.

sql-server-2008

У вас, как правило, большие транзакции в полете, когда вы выключаетесь? Какой интервал восстановления установлен?

— Мартин Смит

за 20 минут до перезапуска сервера никакие действия не выполняются, кроме операторов выбора, интервал установлен на 0.

Как часто вы начинаете? Как часто вы делаете резервную копию базы данных? Мне интересно, почему вы запускаете сервер на регулярной основе? Чтобы завершить, вы можете вручную проверить контрольную точку базы данных (которая очищает журнал), если это необходимо.

— Линн Лангит

«Чтобы завершить, вы можете вручную проверить контрольную точку базы данных (которая очищает журнал), если это будет необходимо». как это можно сделать? и когда вы говорите «очистить журнал», вы имеете в виду не использовать или просто стирать журнал?

Мало информации. Модель восстановления? Используете ли вы такие функции, как зеркалирование или репликация? Размер базы данных и файлов, участвующих? Обрабатывать ли база данных какие - либо крупные сделки?

— Джон Зигель

Ответы:

У меня та же проблема, и я думаю, что я решил ее, но я не смог полностью проверить ее, чтобы подтвердить.

Я полагаю, что проблема связана с количеством VLF, которые есть в вашем журнале, а не с их размером. Если у вас большой лог-файл, вполне вероятно, что он рос органически за счет событий автоматического роста и что это не был намеренный запланированный рост. Если это так, у вас могут быть тысячи VLF в файлах журналов.

Вот запрос, чтобы увидеть, сколько VLF у вас есть, которые я использовал здесь :

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

Для дальнейшего объяснения того, что такое VLF, смотрите эту ссылку .

Я считаю, что проблема заключается в том, что с таким количеством VLF-серверов SQL-серверу требуется много времени, чтобы оценить их состояние и вывести базу данных из восстановления. Если вы уменьшите размер файла журнала до наименьшего возможного размера, часто до размера первого VLF, который был создан в файле журнала, то вы можете сразу же намеренно увеличить его снова и тем самым создать нужное количество VLF (что-то меньше 16).

Как только это будет завершено, я полагаю, вы сможете увидеть, что ваша база данных выходит из восстановления гораздо быстрее.

У меня не было возможности проверить отказоустойчивость наших производственных экземпляров после того, как я решил наши собственные проблемы с VLF, поэтому мне было бы очень любопытно, если бы вы могли подтвердить, что это является основной причиной проблемы. Экспериментально я видел, что время, необходимое для восстановления нашей промежуточной среды, значительно сократилось из-за этого, надеюсь, так оно и есть.

— Крис Магнусон
источник

Подробнее об этой проблеме в блоге PSS

— Martin Smith

Из этой статьи MSDN :

Длительные незафиксированные транзакции увеличивают время восстановления для всех типов контрольных точек.

Как правило, не рекомендуется запускать какие-либо сжатые файлы DBCC в производственных базах данных. Также поведение усечения журнала изменилось с более ранних версий на 2008 (спасибо @Edward) - за этот блог :

Журнал резервного копирования с trucate_only больше не поддерживается в SQL 2008. Если ваша база данных находится в модели массового или полного восстановления, то запланируйте резервное копирование T-Log через регулярные промежутки времени, и он сохранит форму t-log.

Опять же, я упомяну, как часто вы делаете резервную копию базы данных? Как правило, регулярные резервные копии лучше всего управляют размером журнала.

— Линн Лангит
источник

Уменьшение размера онлайн-журнала транзакций может решить проблему, т. Е. Ускорить подключение базы данных к сети, но вам следует подумать об аварийном восстановлении, прежде чем сделать это. Обратите внимание, что если вы используете простую модель восстановления, вы не сможете выполнить восстановление на определенный момент времени. С другой стороны, если вы используете модель полного восстановления, лучший способ сохранить размер оперативного журнала транзакций - это регулярно создавать резервные копии журнала транзакций (запланировать это).

Усечение журнала транзакций не освобождает пространство на физическом жестком диске, а только позволяет SQL Server повторно использовать это пространство для транзакций, которые произошли со времени последнего CHEKPOINT (с момента последнего резервного копирования журнала транзакций).

Если вы уменьшите базу данных, вы уменьшите размер файлов. Чтобы уменьшить базу данных MyDB на 15 процентов:

DBCC SHRINKDATABASE (MyDB, 15); ИДТИ

— Кэрол Бейкер Вест
источник