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

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

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

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

11 голосов | спросил pick4pony 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 03 Sep 2012 18:39:11 +0400 2012, 18:39:11

3 ответа


6

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

Я считаю, что проблемы связаны с количеством 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, поэтому мне было бы очень любопытно, можете ли вы подтвердить, что это является основной причиной проблемы. Экспериментально я видел, как время, которое требуется для восстановления в нашей промежуточной среде, значительно сократилось из-за этого, так надеемся, что это так.

ответил Chris Magnuson 13 ThuEurope/Moscow2012-12-13T18:53:00+04:00Europe/Moscow12bEurope/MoscowThu, 13 Dec 2012 18:53:00 +0400 2012, 18:53:00
2

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

  

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

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

  

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

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

ответил Lynn Langit 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 04 Sep 2012 23:49:32 +0400 2012, 23:49:32
0

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

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

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

DBCC SHRINKDATABASE (MyDB, 15); GO

ответил Carol Baker West 5 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 05 Sep 2012 00:14:53 +0400 2012, 00:14:53

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132