データベースは常にリカバリモードで起動します

サーバーを再起動するたびに、データベースは常に回復モードになり、正常に動作するまでに約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に感謝）-このブログによると：

SQL 2008では、trucate_onlyを使用したバックアップログはサポートされなくなりました。データベースが一括ログモデルまたは完全復旧モデルの場合、T-Logバックアップを定期的にスケジュールすると、t-logの形状が維持されます。

繰り返しますが、データベースをバックアップする頻度はどれくらいですか？通常、定期的なバックアップはログサイズを「管理」するのに最適です。

オンライントランザクションログのサイズを小さくすると、問題を解決できます。つまり、データベースのオンライン化を高速化できますが、その前に災害復旧について検討する必要があります。単純復旧モデルを使用している場合は、特定の時点に復元することはできません。一方、完全復旧モデルを使用している場合、オンライントランザクションログのサイズを維持する最善の方法は、定期的にトランザクションログのバックアップを作成する（スケジュールする）ことです。

トランザクションログを切り捨てても、物理的なハードディスク領域は解放されません。SQLServerは、最後のCHEKPOINT（最後のトランザクションログバックアップ以降）以降に発生したトランザクションにその領域を再利用することだけができます。

データベースを縮小すると、ファイルのサイズが小さくなります。MyDBデータベースを15％縮小するには：

DBCC SHRINKDATABASE（MyDB、15）; 行く