web-dev-qa-db-ja.com

データベースのサイズを縮小する

SQL Server初心者はこちら。私はMySQLの人です。 2008年のSQL Serverでクライアントのために何かを見ているので、アドバイスが必要です。データベースを設計した人は、非常に大量のデータを記録し、それらのログテーブルをフラッシュしないことを選択しました。

最大のテーブルには、アプリとeBayなどのサイトのAPI間のトランザクションからの完全なXMLドキュメントが格納されます。データベースが約230ギガバイトであると、パフォーマンスが低下するとしか思えません。これらのテーブルはアプリでクエリされないのではないかと思いますが、それでも、このような巨大なデータベースのアイデアは好きではありません。ログテーブルを削除した後、残りの合計サイズは約30GBになると予想します。

これについてのアドバイスをお願いします。この件について少し読んだところ、大量のデータを削除した後、データベースファイルのサイズが自動的に縮小されることはありません。また、縮小と再インデックスは悪いことだと私は読んだ。

  • この大規模なデータベースは他のテーブルのパフォーマンスを低下させていますか？
  • それについて何かすべきでしょうか？
  • パフォーマンスを向上させるために、どうすれば安全にそれを実行できますか？
sql-serversql-server-2008performancedisk-spaceshrink
5
Brett

このデータベースにデータを記録し続ける場合、地球上で最後に行うことは、データベースファイルを圧縮することです（その後、インデックスのメンテナンスを実行して、データベースを再度拡張する必要があります）。これらの縮小と拡大の操作はパフォーマンスに影響を与えることを気にしないでください。また、最終的な結果によって、開始時よりもずっと良い結果が得られるわけではありません。

ファイルは再び大きくなるだけなので、これは非常に無駄な操作です-シャワーを浴びている間に乾燥するのとよく似ています。一時的に解放したディスク領域を一時的にするにはどうしますか？データベースを再度拡張する必要があるまで、それを別のアプリケーションにリースしますか？もちろん違います。データベースが一度そのサイズまで大きくなった場合、再びそのサイズまで大きくなりますが、ファイル内のスペースを再利用する方がはるかに効率的ですこの不要な縮小をせずに -grow-shrink-growファイル自体のジェットコースター。

ロギングテーブルを別のデータベースに移動した場合でも、保存するロギングの量（1週間、1か月など）に対応できるサイズにデータファイルを事前に割り当てるためにできることを行う必要があります。 ）。毎日データをパージすることにより、このデータベースのトリムを維持し、縮小と再インデックス付けの心配をやめます。適切なサイズに設定する場合は、常にある程度の空き領域が必要ですが、過剰な空き領域はありません。また、インデックスを再作成する必要がある場合（実際には、クラスター化されたインデックスが日付時刻であるか、それ以外の場合は単調に基づく必要はありません）、縮小後ではなく、パージ後に（空き領域が最も多いときに）削除してください（あなたが最も少ないとき）。

アプリケーションに新しいデータベースを導入したり、アプリケーションまたはそのインターフェースをデータベースにまったく変更したりせずに、Markが提案することを実行できます（もちろん、重要な変更の1つは、外部キーやその他のデータベース依存機能の削除です）。 。新しいデータベースにテーブルを作成し、現在のデータベースのテーブルに INSTEAD OF INSERTトリガー を追加するだけです（ロギングテーブルには更新がないと想定していますが、パージを実行するプロセスを直接制御しない場合は、INSTEAD OF DELETEトリガーも必要です）。これは書き込みに役立ちますが、INSTEAD OF SELECTトリガーがないため、別の場所で読み取りをポイントする必要があります。別の方法としては、既存のテーブルの名前を変更し、 シノニムを作成 または新しいテーブルを指すビューを使用することもできます。

大きくなったログテーブルをクリーンアップする必要がある場合は、次のような単一のアトミックトランザクションを回避します。

DELETE dbo.logs_table WHERE [datetime] < '20121201';

これにより、ログが大幅に増加し、長い時間がかかります。代わりに、クリーンアップをチャンクに分割できます。

BEGIN TRANSACTION;

SELECT 1;

WHILE @@ROWCOUNT > 0
BEGIN
  COMMIT TRANSACTION;

  -- if in simple: CHECKPOINT
  -- otherwise: BACKUP LOG

  BEGIN TRANSACTION;

  DELETE TOP (1000) FROM dbo.logs_table WHERE [datetime] < '20121201';
END

私は1000と12月1日を勝手に選んだのですが、あなたのシナリオに最適なものがわかりません。重要なのは、トランザクションを短くして封じ込め、テーブルをクリーンアップしている間、長期的な影響を防ぎたいということです。過去に使用した別のオプションでは、テーブル内のジャンクの99％を削除する代わりに、保持する1％を新しいテーブルに移動して、古いテーブルを削除します。

BEGIN TRANSACTION;

SELECT * 
  INTO dbo.new_logs_table 
  FROM dbo.logs_table
  WHERE [datetime] >= '20121201'

COMMIT TRANSACTION;

-- create indexes/constraints/triggers on dbo.new_logs_table

BEGIN TRANSACTION;
  DROP TABLE dbo.logs_table;
  EXEC sp_rename N'dbo.new_logs_table', N'logs_table', N'OBJECT';
COMMIT TRANSACTION;

ログが一度も削除されていないと言った場合、データベースが今後再び必要になるとは思わないサイズになる可能性があります（たとえば、1週間しか保持しない場合）一度にログの）。この場合、縮小操作を実行することがありますが、本当に必要な場合のみです（たとえば、他の目的のためにスペースが本当に必要な場合など）。空のページの束がバックアップやその他の操作に影響を与えることはなく、ページは最終的に完全に割り当て解除され、再利用されます。

10
Aaron Bertrand

最大のテーブルには、アプリとeBayなどのサイトのAPI間のトランザクションからの完全なXMLドキュメントが格納されます。

現在、まったく同じように動作するシステムを使用しています。 230GBは今日の基準では大規模ではないというMatのコメントは公平ですが、システムが動作するために必要な量よりもまだ200GB多いです。それはバッファプールを占有している可能性があり、より大きくてより長いバックアップに確かに貢献しており、主な懸念事項であり、災害時により長い復元時間が必要になります。

好ましいのは（アプリケーションコードがアクセス可能で、変更を許容できる適切な状態にある場合）、重要でないログを別のデータベースにプッシュすることです。その後、それを単純なリカバリに切り替えて、トランザクションログのバックアップを省略できます。明らかに、これはポイントインタイムリカバリの損失が許容できると見なされるデータにのみ適しています。

私が見ている場合、ログに記録されているAPI要求/応答ドキュメントは事実上重複データです。トランザクションの詳細は、データベースの別の場所に保存されています。ドキュメントはデバッグ専用です。

または、データをより頻繁にパージします。

しかし...評価が正しく、関心のあるデータが30GBである場合、32GBサーバーはこのデータベース専用であり、それで十分です。ロギング/サイズの問題を早期に解決しようとするのではなく、問題の原因を詳しく分析することをお勧めします。

DMVクエリを分解します。 Glen BerryのDMV診断スクリプト には、最も多くのIOまたはCPU時間を消費している手順とアドホッククエリを識別するための例が含まれています。 sp_whoisactive は、ライブ分析に非常に役立ちます。

興味のあることがあれば、詳細を記載した新しい質問を投稿してください。

9
Mark Storey-Smith

断片化データベースはページを適切に整理していないため、パフォーマンスは断片化されたデータベースの影響を受け、情報を提供するのに長い時間がかかります。

データベースのパフォーマンスを向上させるには、最適化が必要です。

簡単に使用できるようにテーブルのページ順序を論理的および物理的に再配置し、サイズを縮小するため

0
megamind