読者です 読者をやめる 読者になる 読者になる

SQL Serverの自動拡張を使用するうえでの7つのヒント

引用は主に以下から。

[INF] SQL Server における自動拡張および自動圧縮の構成に関する注意事項
http://support.microsoft.com/kb/315512/ja

SQL Server データベースのいっぱいになったトランザクション ログからの回復
http://support.microsoft.com/kb/873235/ja


1.自動拡張を行っている間、トランザクションが停止する。

ログを拡張する必要がある大規模なトランザクションを実行する場合、そのトランザクション ログに書き込む必要がある他のトランザクションも、拡張操作が完了するまで待機する必要があります。

これによりクエリタイムアウトも起きやすくなりそうです。


2.ファイルの断片化が招きやすくなり、パフォーマンスに影響が出る。

データ ファイルまたはログ ファイルのサイズ変更に起因する物理的な断片化は、パフォーマンスに深刻な影響を与える可能性があります。


3.そもそもMicrosoftが日常的な使用を推奨していない。

予期しない拡張が発生した場合に備えた非常時対策としてのみ、自動拡張を考える必要があります。自動拡張を日常的に使用して、データおよびログの拡張を管理しないようにしてください。

あくまで要領不足の緊急回避として使うのが大事。初期サイズを予め設定しておくなどの対策が必要。


4.を設定しておく。

の設定を有効にして、使用可能なすべてのディスク領域が 1 つのファイルの拡張によって使い果たされないようにします。


5.1回の拡張は大きめに。

データベースを少量ずつ拡張する場合、またはデータベースを拡張した後圧縮する場合、ディスクの断片化が発生する可能性があります。ディスクの断片化が発生すると、環境によっては、パフォーマンス上の問題が発生する場合があります。

拡張の回数が少ないとディスクの断片化が発生しやすくなります。可能な限り1回の拡張で余裕が持てるようにしましょう。


6.拡張幅は%ではなくMBで。

最適なメモリ サイズを綿密に検討した後、パーセンテージではなく MB 単位で、トランザクション ログ ファイルを自動的に拡張するように構成します。

最適なメモリサイズは様々な要因で決定されるので一概には言えませんが、%で拡張した場合、予想外のファイルサイズになる可能性があります。


7.自動圧縮は極力使用せず、DBの監視を行い手動で拡張する。

警告や監視プログラムを使用してファイル サイズを監視し、事前にファイルを拡張することができます。これにより、断片化を避け、ピーク時を外して保守作業を行うことができます。

最終的にはこれに尽きますw パフォーマンスを低下させることもなく計画的なDB運用ができますね。