SQL Server 2005の巨大なDBの問題
私のDBファイルは非常に急速に成長しています（デザイナーは私ではなく、週に1度のレポートで7 GB増加します）。そして最後に、ディスクに十分なスペースがありません。そして、報告されていない週の数は数え上げます。
私にはいくつかのオプションがありますが、あなたの推奨が必要です：
データベースを縮小します（縮小するとOSにスペースが与えられますか？）
外部ディスクまたはネットワークストレージからDBを切り離して接続します。 （ネットワークストレージはSQL Server 2005でサポートされていますか？）
RAID構成を1から5に変更して、ディスクサイズを2倍にします。 （これは最も安全なオプションですが、RAID構成の変更も危険です。）
私の質問に関してこれらの素晴らしい、そして有用な回答をありがとう。ログファイルを確認したところ、99％の領域が未使用です。だから、縮小しました。 DBは、いくつかのレポートが必要なときに（時間どおりに、常にdbにアクセスする必要はない）使用されるので、パフォーマンスは問題にならないと思います。
データベースを圧縮すると、O/Sにスペースを戻すことができますが、そのスペースは、圧縮アクティビティによってデータベースが断片化されるため、パフォーマンスコストがかかります。これは、インデックスを再構築することで修正できますが、通常はスペースが再利用されます。そして、縮小が解決策であるという考えは誤りです。あなたは成長の問題自体に取り組んでいないので、吸う胸の傷に包帯を巻こうとしているだけです。
簡単に拡張できるディスクにファイルを配置するのが最善の策です。外部ストレージ（または、可能であればSAN）が適切に機能します。データベースファイルにUNCパスを使用することはできませんが、DFSを使用してドライブをマウントし、ネットワークの場所を指すようにすれば、すべて正常に機能します。
HTH
関連するバックアップ計画を実行している場合、ログファイルが無制限に大きくなることはありません。その中のスペースは主に割り当てられていないことに気付くでしょう-ログのページのブロックがバックアップされると（もちろん、バックアップ/リカバリモデルによって異なりますが、これらのオプションに慣れていない場合は、これらのオプションを読んでください）、次のようにマークされます。後で再び自由に使用できますが、OSにはリリースされていません。次に大きなプロセスが実行されると、多くの挿入/更新が発生するため、数GBのログスペースが必要です。MSSQLは、ログファイルにすでに割り当てられているブロックを使用するだけなので、OSに追加のスペースを要求する必要はありません。現在、上書きできないものは保持していません。
ログファイルに余分な増加のGBが表示される場合every毎週のプロセスが実行される時間バックアッププランを確認する必要があります。これは、SQLServerがログページを再利用可能として認識していないことを意味します。レジームはデータとアクティビティに対して正しくありません（または、バックアップを頻繁に作成しないほど簡単な場合もあります）。
データファイルの増加も同様です。ファイルに大きな空き領域がある場合、OSに追加の割り当てを要求する代わりに、追加の領域が必要になったときに、その空き領域が使用されます。データが予想外に大きい場合に注意しなければならないことの1つは、インデックスの過剰作成です。大きなテーブルには、実際には使用されないインデックスがある場合があります（まったく必要ないか、または別のインデックスよりも多くの利点がありません）。現在）。これの典型的な例は、ワイドテーブルのevery列に独自のインデックスがある（通常、常にではないが、テーブル/インデックスのデザインが悪いという兆候である）か、 "- column1とcolumn2 "と1つずつcolumn1の場合：クエリプランナーとランナーは、単純なだけでなく複合インデックスも使用できます1つはcolumn1に基づくクエリ用なので、追加のインデックスでスペースを使用する必要はありません。役に立たないインデックスを維持すると、書き込みパフォーマンスにも影響します。 この本 は、問題をさらに詳しく知りたい場合の一般的なインデックスの問題をカバーするセクションがいくつかあり、すべての開発者とDBAがいずれにせよIMOを読む価値があります。
ファイルを不必要に縮小すると、ファイル内で過度の断片化が発生し、パフォーマンスに悪影響を与える可能性があるため、この方法を使用する場合は注意してください。
RAID1からRAID5への切り替えに関して：私はそれをお勧めしません。 RAID5は、書き込みが多いデータベースの作業でパフォーマンスの問題を起こすことがよくあります（GBytes相当のデータとトランザクションログエントリを生成する巨大なプロセスが大幅に遅くなる可能性があります）。チェックサムの問題。 R1からR5に移動するために1つのドライブを追加するのではなく、2つの追加ドライブに移動してR10を使用します-スペースを2倍にしますが、書き込みパフォーマンスの問題はありません（もちろん、サーバーに2つの追加ドライブ用のスペースがあると想定しています） ！）。その領域で何をしても、あるRAID配置から別のRAID配置への変換は、データをバックアップし、アレイを再構築し、データをコピーして戻すのに長いダウンタイムを伴う可能性があります（まったく新しいセットを購入しない限り）。ドライブと新しいアレイと古いアレイの両方を同時に実行できるため、ダウンタイムが大幅に短縮されます）。別のオプションは、2つのドライブを新しいRAID1アレイとして追加し、Windowsのダイナミックボリュームを使用してこれら2つのアレイにまたがることです（RAID10のサイズを提供しますが、ストライピングから収集できるパフォーマンスの向上はありません）。 OR 2つのアレイを別々に維持し、データファイルを1つに、トランザクションログをもう1つに維持できます。この方法でデータとログを別々のスピンドルに維持すると、書き込みのパフォーマンスが大幅に向上します。ログとデータファイルの両方を更新するために必要なヘッドの動きを減らすことによる操作。この最後のオプションでは、ドライブが残りの状態になると「ライブ」で実行できるため、ダウンタイムが最小限になります。新しいボリュームに新しいログファイルを作成し、すべてのアクティブなページを既存のファイルからそこに移行し、古いファイルを削除するようにSQL Serverに指示します（この操作中にパフォーマンスが低下しますが、ダウンタイムは発生しません）。
どのテーブルが非常に速く成長しているかを確認する必要があります。
過去に発生したのと同様の問題が発生する可能性があります。テーブルデータが削除されても、スペースがテーブルによって解放されなかったため、テーブルは多くのGBを使用または報告していましたが、100,000行しかありませんでした。 （私たちの解決策はテーブルを再構築することでした）。
非表示のデータの問題がない場合は、別のドライブ（storage..etc）に新しいファイルグループを作成し、そこにデータファイルを作成できます。その後の解決策は、この新しいファイルグループに大きなテーブルとそのインデックスを再作成することです。
現在最も重要なのは、テーブルが成長する理由と理由を理解することです。この質問もご覧ください： スペースの問題に関するいくつかの情報については、DBCC CLEANTABLEを実行してスペースを再利用する必要があるかどうかを判断する信頼できる方法はありますか？ .
SQLRockstar でもここで述べられているように、別の角度から問題を処理することをお勧めします。あなたは問題を修正することに熱心で、間違ったアプローチである問題の原因を見つけないでください。原因が再び現れ、同じ問題を引き起こすからです。
確認/実行すること：
データベースは完全復旧モデルですか？レポートのためだけにDBを使用している場合は、復旧モデルを単純に変更することを検討する必要があります。このモデルでは、SQL Serverはトランザクションログに最小限の情報のみを保持します。 SQL Serverは、データベースがトランザクションチェックポイントに到達するたびにトランザクションログを切り捨てます。切り捨ては縮小とは異なります。切り捨て後、ログファイルはおそらく同じサイズになりますが、内部のスペースは次の拡張のために解放されます。また、ログファイルを拡張すると、ログファイルを拡張する必要があるたびに、ディスクに余分な負荷がかかるため、このままにしておくことをお勧めします。
データファイルも増加している場合は、その中で最大のオブジェクトを特定し、それらをスペースで削減できるかどうかを確認する必要があります。設計していない場合は、サイズが大きく、気づいていない未使用のインデックスがある可能性がありますか？
これを見つけるためのいくつかの有用なコードを以下に示します。 テーブルとインデックスのサイズ
最初に確認する必要があるのは、データファイルとログファイル内で利用可能な空き容量です。
SELECT name AS 'FileName' , physical_name AS 'PhysicalName', size/128 AS 'TotalSizeinMB',
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS 'AvailableSpaceInMB',
CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS 'ActualSpaceUsedInMB',
(CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0)/(size/128)*100. as '%SpaceUsed'
FROM sys.database_files;
ファイルに空き領域がない場合は、縮小を試しても効果はありません。データ+ログファイルの自動拡張設定も確認してください。いくつかのバグがあります+誤って大きな自動成長を設定し、時にはそれが多すぎます。
一般的に、あなたのようなケースでは、縮小することはお勧めしません。スペースを追加するのが正しい方法です。
約90 GBのデータファイル。ログファイルは約20 GBです。 – 19時間前のオルガンカヤ
私はそのsankarを2番目にします。
データベースを縮小しないでください。何度も拡大して断片化を引き起こします。
90 GBのデータファイルを20 GBのログファイルと比較すると、ログファイルが20 GBになった理由が大きすぎます。復旧モデルとバックアップ計画を確認してください。