SQL Server-成長するデータベースファイルのベストプラクティス


16

私は、SQL Server 2008 r2のデータコレクターを介して2週間、ファイルの増加を監視しています。データベースは、約35(MB)/日で一貫して成長しています。DBは初期サイズの2 GBにまだ達していません。

DBファイルの自動拡張は5MBに設定されています。別のアプローチを試してみたいので、提案やコメントを探しています。

毎週日曜日の夜1:30 AMに実行されるチューニングタスクがあります。タスクは:

  • データベースの整合性を確認する
  • ログファイルを圧縮する-(ログモードがシンプルなので、これは問題ありません)
  • データベースの縮小
  • インデックスの再編成
  • インデックスを再構築
  • 統計を更新する
  • 履歴をクリーンアップする

毎週の調整計画にさらに2つのステップを追加したいと思います。

  1. 使用領域が特定のしきい値または合計サイズに達した場合、データベースファイルを500 MB増やします。
  2. 使用されているスペースが合計サイズの特定のしきい値に達すると、ログファイルを250 MB(縮小後)増やします。

オフラインの時間に成長の負担をかけることにより、高負荷時の自動成長イベントの数を減らしてパフォーマンスを向上させたいと考えています。

自動拡張ファイルに関する質問が2つあります。

  • ファイルの成長ステップを配置する最適な場所は、現在のステップの前か後ですか?
  • を使用しALTER DATABASE|MODIFY FILEてファイルを拡大すると、どうすれば判断できSpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)ますか?

2
DBには、成長しない十分なサイズが必要です。それでも、Instant File Initializationが有効になっていることを確認してください。
レムスルサヌ

3
@Remusは理想的ですが、キャリアを通じてすべてのデータベースを完全にサイズ調整したと言っていますか?常に推測作業が行われ、調整が行われます。私は成長をコントロールする必要があることに同意しますが、それを1日に7回行うだけではありません。
アーロンバートランド

3
@AaronBertrand:私は単純で誇張されたアドバイスを好みます。やがて、私はそれがよりうまくいくことを学びました。ほとんどのユーザーは、「それが依存」扱いと...黒と白の間のグレーの色合いがあることを自分自身で把握することができないものはできません
レムスRusanu

3
@DanAndrews:過剰な割り当ては、「下流」に影響を及ぼす可能性があります。...それは、データ1GBのための2台の新しい1TBのドライブを必要と発見するだけで自分のマシン上でDBを復元しようとDEVを考えて
レムスRusanu

2
私は悪魔の支持者だけを演じています。ただし、HDは安価です。再構成のための実稼働での損失時間とパフォーマンスの損失は高価です。
ダンアンドリュース

回答:


24

自動成長をできるだけ少なくすることを目指してください。インスタントファイルの初期化でも、1日に7回は耐え難いものです。

データベースの縮小は行わないでください。今まで。Shrinkfile、おそらく、しかし、異常なイベントの後のみ。再び成長するためにそれを縮小することは無益さの練習であり、実際には自動フラグメントと呼ばれるべきです。

復旧モデルが単純な場合、ログファイルを250 GB増やす必要があるという方法はありません。ファイル内の使用済みスペースは、1か月前にトランザクションを開始し、コミットまたはロールバックする意図がない限り、時間とともに自動的に消去されます。

だから私のアドバイスは:

静かな期間中に手動でデータファイルを自動拡張して、数か月の拡張に対応できるサイズにします。それまでは何のために保存していますか?

データファイルの自動成長増分を比較的小さい値に設定し(発生時にユーザーに割り込まないようにします)、このイベントでアラートを出します(たとえば、デフォルトのトレースで、または拡張を通じてキャッチできます)イベント)。これは、あなたが推定した最高​​点に達していること、そして手動で再び成長する時が来たことを伝えることができます。この時点で、スペースを収容するために別のドライブに新しいファイル/ファイルグループを追加する場合に備えて、最終的に現在のドライブがいっぱいになるため、このマニュアルを保持する必要があります。

たとえば、ログファイルをこれまでで最大の2倍に自動拡張します。何らかの異常なトランザクションが物事を保留していない限り、それ以上自動成長するべきではありません。このイベントについても監視する必要があります。


入力をありがとう...ログファイルを大きくしてしばらく監視するためのアドバイスをお伝えします。autgrowサイズのMBに対して誤ってGBを使用しました。私は同意し、Shrink Databaseは意図したとおりに動作していないと思います。年の終わりに、DBは15GBに達し、ジョブが作成された時点で、バックアップのためのスペースがなくなっていました。

+1は自動フラグメントと呼ばれるべきです:-)既にそのための接続の問題を開始しましたか?:-)
marc_s

10

自動成長は、可能な場合は回避する必要があるものです。問題は、成長がいつ発生するかを制御できないことであり、成長中にシステムが深刻な打撃を受ける可能性があります。

ファイルサイズを1か月程度に適切な値に設定し、そこから成長率を監視して、X時間の推定サイズを計算し、その値に+誤差を設定します。

自動成長の前にファイルサイズが事前に定義された最大値に達すると警告する簡単な監視ジョブを設定しました。次のようなものを使用できます。

SELECT instance_name,
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
       into ##Logsize
FROM
(
   SELECT *
   FROM sys.dm_os_performance_counters
   WHERE counter_name IN
   (
       'Data File(s) Size (KB)',
       'Log File(s) Size (KB)',
       'Log File(s) Used Size (KB)',
       'Percent Log Used'
   )
     AND instance_name = 'database your interested in' 
) AS Src
PIVOT
(
   MAX(cntr_value)
   FOR counter_name IN
   (
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
   )
) AS pvt 
go
declare @logsize int
Select @logsize = [Percent Log Used] from ##Logsize

If @logsize > the maximum percent you want the log to fill too i.e 90
    BEGIN
        --Do your thing here
    END

Drop table ##Logsize

もちろん、これはジョブとしてスケジュールできます。


「AND instance_name = '関心のあるデータベース」を削除して、すべてのデータベースが返されるようにします。次に、IFステートメントでログサイズがしきい値を超えるカウントを使用します。カウントが1よりも大きい場合、一時テーブルからselect nameステートメントを使用してsp_send_dbmailを実行し、制限を超えるログの名前を電子メールで送信します。
ニックウィンスタンリー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.