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

Щоразу, коли я перезавантажую свій сервер, база даних завжди перебуває у режимі відновлення, і це потребує приблизно 20 хвилин, щоб вона поводилася як нормальна. Це завжди і відбувається лише коли я перезавантажую сервер, тому у мене є кілька питань ...

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

Зараз я використовую Microsoft SQL Server 2008.

У мене є те саме питання, і я вважаю, що я його вирішив, але не зміг повністю перевірити його для підтвердження.

Я вважаю, що проблеми пов'язані з кількістю 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, тому мені було б дуже цікаво, якщо ви можете підтвердити, що це першопричина проблеми. Експериментально я побачив, що час, необхідний для виходу з реставрації в нашому сценічному середовищі, різко скоротився через це, надіюсь, що це так.

З цієї статті MSDN :

Тривалі незапущені транзакції збільшують час відновлення для всіх типів контрольно-пропускних пунктів.

Зазвичай не рекомендується запускати будь-який вид скорочувальних файлів DBCC на виробничих базах даних. Також поведінка укорочення журналу змінилося з попередніх версій до 2008 року (спасибі @ Edward) - у цьому блозі :

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

Ще раз зазначу, як часто ви створюєте резервну копію бази даних? Зазвичай регулярні резервні копії найкраще "керують" розміром журналу.

Зменшення розміру онлайн-журналу транзакцій може вирішити проблему, тобто пришвидшити доступ до бази даних в Інтернеті, але слід подумати про відновлення після аварій, перш ніж це зробити. Зауважте, що якщо ви користуєтеся простою моделлю відновлення, ви не зможете відновитись до певного часу. З іншого боку, якщо ви перебуваєте в ПОЛІВНІЙ моделі відновлення, найкращий спосіб зберегти розмір онлайн-журналу транзакцій - це створювати резервні копії журналу транзакцій на регулярних базах (плануйте це).

Обрізання журналу транзакцій не звільняє фізичний простір на жорсткому диску, воно лише дозволяє SQL серверу повторно використовувати цей простір для транзакцій, що відбулися з моменту останнього CHEKPOINT (з моменту останньої резервної копії журналу транзакцій).

Якщо ви скоротите базу даних, ви зменшите розмір файлів. Щоб зменшити базу даних MyDB на 15 відсотків:

DBCC SHRINKDATABASE (MyDB, 15); ПОВЕРНУТИСЯ