web-dev-qa-db-ja.com

自動成長-使用率？

自動拡張設定にパーセンテージファイル拡張を使用しないのが最善ですか？

以下では、500 GB未満のデータベースに対してパーセント値の増加を使用することを推奨していますが、これは推奨ですか？

http://performance-expert.blogspot.ie/2012/06/tuning-autogrow-settings-of-sql-server.html

ディスク容量が限られている場合、またはデータベースのサイズを変更できない場合は、> autogrowth値を一定の割合に構成する必要があります。たとえば、500 GB未満のデータベースの場合は自動拡張の値を10パーセント以上に、データベースが500 GBを超える場合はメガバイトの固定数に設定します。

ありがとう！

[〜＃〜] update [〜＃〜]：以下に、一部のデータベースで自動拡張のスナップショットを追加しました。これについて何かアドバイスはありますか？

また、データベースのサイズを予測する最良の方法は何ですか？

enter image description here

sql-serverauto-growth
5
K09

3つの答えがあり、いくつかのすばらしいアドバイスが各答えに部分的に含まれています。それは私が別の観点からもう少し追加したかったと言いました。

ここでデータベースファイルについて話します...

適切なサイズ設定が最適です

ほとんどの人が言ったり示唆したりしたように、現在および将来のニーズに合わせてデータベースを「適切なサイズ」にする方がはるかに優れています。 TomTomは、そこにパフォーマンスヒットがあることを指摘するのは正しいですが、KookieMonsterは、インスタントファイル初期化（私は怠惰だからIFI）がそれを助けることを指摘するのも正しいです。私のデータベースの展開時および将来の可能性におけるbestとしてのニーズ。そして、私はそのプロジェクトと私がプロジェクトについて知っている/成長する可能性について知っていることに基づいて「過剰」にサイズを設定しようとします...注：これは正確な科学ではなく、あなたがこれを間違えることもあるでしょう（多くの場合）それは大丈夫です..自動成長は良いことです。

なぜですか？SAN adminが不足し始めたときに、その厄介な会話をしたくないのでスペース。SAN管理者がスペースを確保するために舞台裏で醜いことをするためにその選択をする必要はありません。私は事前に割り当てて、時間の経過に伴うデータベースと使用

緊急ヘルパーとしての自動成長

データファイルの自動拡張は、特にIFIの場合は問題ありません。しかし、私はDBファイルの内部で使用されるスペースを監視し、バンドエイドとして自動的に拡大する機能を使用するのが好きです。この方法[〜＃〜] i [〜＃〜]は、私がDBAとして担当しているデータベースの成長を上回っています。監視連隊には、使用済みスペースのチェックとそれの確認を含める必要があります。

どの設定が最適ですか？

したがって、これを念頭に置いて、自分で成長の管理を支援しているので、何を使用しても問題にはなりません。スペースの使用曲線が希望よりも急である場合は、計算結果を確認し、1つの大きな成長でより多くのスペースを事前に割り当てることができます。それでも、私はパーセンテージの大ファンではありません。私にはそれは非決定論的であり、誰かが多くの状況で成長を管理していないことを示しています。私はそのレベルの制御が好きで、データベースのニーズに基づいて適切だと思うスペースを選びます。

大きな警告

「依存する」-データベースが小さく、ディスク上で大きな恩恵を受けることはおそらくないeverなら、それを維持することについては泣かないでしょうパーセンテージ、またはその設定に少し注意を払っています。クライアントに行って、750GBのデータベースがデフォルトの増加率のままで、ログファイル管理がないことを確認した場合、私は少し泣きました。 3年間使用されているが、デフォルトに設定されている1.25GBデータベースのクライアントに行くとどうなりますか？私はレポートでそれについて言及しましたが、「ベストプラクティスがあります。そして、どちらにしても大丈夫な状況があります」という彼らとの会話の全体を私は持っています。それは無効ですか？私はおそらく、より小さなデータベースに対してより深刻なことを言うでしょう、そして私は実際に「Let's gocrazyand grow this 4 times to preallocate some space」と2〜3 GBのディスク容量が「無駄」になるリスクがあります。

トランザクションログファイル

別の問題です。ログファイルはIFIを利用できません。そして、彼らは [〜＃〜] vlf [〜＃〜] 断片化と呼ばれる小さなものがあるため、自動成長を好まない（このリンクをクリックすると、トピックに関する多くのリンクに移動します）。私はトランザクションログのサイズを適切に調整して監視し、適切なサイズを再評価することを好みます。私は自動拡張をオンにしています（本番トランザクションログファイルがいっぱいになると、内部で泣きます。実際には外部でも泣きます）。そして、VLFに提供されているリンクのガイダンスに従って、「チャンク」でサイズを適切に設定します。

11
Mike Walsh

私の側では、私は通常、パーセンテージの成長を管理するのが少し簡単であることを認めなければなりません。そうは言っても、ここで覚えておきたいことをいくつか挙げておきます。

  • データベースは常になんとかしてサイズが大きくなりましたが、慎重に計画し、多くの小さなチャンクでデータベースを大きくしないようにする必要があります。これらの操作は非常にCPUに負荷がかかり、データベースが断片化することがよくあります。ログファイルには多数の仮想ログファイル（ http://www.brentozar.com/blitz/high-virtual-log-file-vlf-count/ および http： //www.sqlskills.com/blogs/kimberly/transaction-log-vlfs-too-many-or-too-few/ 追加情報が含まれます）。これにより、復元、バックアップ操作などが遅くなります。可能であれば、適切なサイズのチャンクで成長してみてください。エイドリアン・サリバンが上で述べたように、あなたはあなたのバランスを見つける必要があるでしょう。

  • 即時初期化を使用します。これにより、要求されたスペースをゼロで初期化する必要がなくなり、時間とCPUを大幅に節約できます。詳細は http://www.sqlskills.com/blogs/paul/how-to-tell-if-you-have-instant-initialization-enabled/ をご覧ください。

  • ディスク容量を監視してください！使用可能なディスク容量が特定のしきい値（10または20％など）を下回った場合でも、警告を送信することを恐れないでください。ディスクがいっぱいになると、かなりの数のユーザーとあなたに痛みが生じます。

5
KookieMonster

@MikeWalshと@KookieMonsterを考慮に入れて、自動拡張イベントを長期にわたって監視し、環境に適した数を使用することをお勧めします-データファイルとログファイルの両方に適用されます（監視と10％バッファを使用すると、自動拡張の設定が不適切なために発生する自動拡張イベントの数を最小限に抑えることができます）。

自動拡張イベントは、データベースのパフォーマンスを低下させる高価な操作です。常に、データベースのサイズを事前に設定し、データベースの成長プロファイルに基づいて、データベースの適切な自動拡張設定を確立します。

もう一度強調しますインスタントファイル初期化を有効にするデータファイルがその素晴らしさを活用できるようにします。

以下は、デフォルトのトレースを使用して自動拡張イベントをチェックする方法です（デフォルトで実行されています-オフにしていない場合を除きます。-- change this AS PER YOUR NEED !!を変更してスクリプトを調整できます）。

set nocount ON
if exists (SELECT 1 FROM ::fn_trace_getinfo(DEFAULT) WHERE traceid = 1 AND property = 2) 
begin
IF OBJECT_ID('tempdb..#autogrowthTotal') IS NOT NULL
    DROP TABLE #autogrowthTotal;
IF OBJECT_ID('tempdb..#autogrowthTotal_Final') IS NOT NULL
    DROP TABLE #autogrowthTotal_Final;

DECLARE @filename NVARCHAR(1000);
DECLARE @bc INT;
DECLARE @ec INT;
DECLARE @bfn VARCHAR(1000);
DECLARE @efn VARCHAR(10);

-- Get the name of the current default trace
SELECT @filename = CAST(value AS NVARCHAR(1000))
FROM ::fn_trace_getinfo(DEFAULT)
WHERE traceid = 1 AND property = 2;

-- rip apart file name into pieces
SET @filename = REVERSE(@filename);
SET @bc = CHARINDEX('.',@filename);
SET @ec = CHARINDEX('_',@filename)+1;
SET @efn = REVERSE(SUBSTRING(@filename,1,@bc));
SET @bfn = REVERSE(SUBSTRING(@filename,@ec,LEN(@filename)));

-- set filename without rollover number
SET @filename = @bfn + @efn

-- process all trace files
SELECT
  ftg.StartTime
,te.name AS EventName
,DB_NAME(ftg.databaseid) AS DatabaseName  
,ftg.[FileName]
,(ftg.IntegerData*8)/1024.0 AS GrowthMB
,(ftg.duration/1000)AS DurMS
into #autogrowthTotal
FROM ::fn_trace_gettable(@filename, DEFAULT) AS ftg
INNER JOIN sys.trace_events AS te ON ftg.EventClass = te.trace_event_id  
WHERE (ftg.EventClass = 92  -- Data File Auto-grow
    OR ftg.EventClass = 93) -- Log File Auto-grow
ORDER BY ftg.StartTime

select count(1) as NoOfTimesEventFired
        , CONVERT(VARCHAR(10), StartTime, 120) as StartTime
        , EventName
        , DatabaseName
        , [FileName]
        , SUM(GrowthMB) as TotalGrowthMB
        , SUM(DurMS) as TotalDurationMS
into #autogrowthTotal_Final
from #autogrowthTotal
group by CONVERT(VARCHAR(10), StartTime, 120),EventName,DatabaseName, [FileName]
having count(1) > 50    -- change this AS PER YOUR NEED !! 
or SUM(DurMS)/1000 > 60 -- change this AS PER YOUR NEED !! 
order by CONVERT(VARCHAR(10), StartTime, 120)

if exists (select * from #autogrowthTotal_Final)
begin
        select *  FROM #autogrowthTotal_Final
end
else
begin
        SELECT  ' There are minimal to none autogrowth events and these wont affect Database server performance. ' AS COMMENTS
            ,' Your databases are properly sized. Keep up the good work !! ' AS RECOMMENDATIONS
end
end
else
begin

        SELECT ' There is no Default trace enabled. Check [value_in_use = 1] for [sp_configure default trace enabled].  ' AS COMMENTS
            ,' Please enable the Default trace to do Detailed analysis for Auto Growth Events as no information could be obtained as Default trace is not enabled !! ' AS RECOMMENDATIONS
end
set nocount OFF

以下は、私がAutogrowthで遊んだサンドボックスの1つからの出力です。

enter image description here

2
Kin Shah

ほとんどのSQLと同様に、すべてに依存し、正しい自動拡張設定はありませんが、大きいほど良い傾向があります。

各成長イベントは、SQLサーバーに多大な労力を費やし、ログに書き込んでDBサイズを増加させるため、理想的には、イベントをできるだけ少なくする必要があります。 20MBのDBで1MBと500GBのDBで50％の成長の中間点を見つける必要があります。自分のバランスを見つけることがすべてです。

最善の方法は、現在の状況と今後30日または90日間で予想される成長を評価し、それらの数値を％または固定サイズとしてパンチして、1か月後にもう一度確認することです。すすぎ、繰り返します。

経験則として、デフォルトは10％の自動拡張で、10MBから0.7TBまでのほとんどのDBで正常に機能します。あなたはそれを管理する必要があるだけです。

0
Adrian Sullivan

通常、自家増殖はまったくありません。必要がある場合、percentagがデータベースのサイズに応じて増加する割合はなく、拡張は低速です。 1000GBデータベースの10％は、突然の100GBファイルの拡張です。これは、実際にパフォーマンスを低下させる可能性があります。

私は通常、実際のデータベースではautogrothを許可しません-使用量の少ない小規模なデータベースでのみです。

0
TomTom