データベースと言っても、形、サイズ、スキーマは千差万別です。専門家が、データベースの圧縮、拡張、および再設計について役立つ情報を提供します。ディスクの空き容量が不足しているため、パフォーマンス上の問題を引き起こす可能性があるとわかっていても、データベースを圧縮せざるを得ない場合があります。圧縮後に、インデックスの断片化に対処しています。データベースによっては、サイズが同じくらいであるにもかかわらず、他のデータベースよりも、圧縮にかかる時間が大幅に長いと感じる理由を教えていただけませんか。データベースの圧縮を実行することによる副作用をご存じで、安心しています。私も、データベースを圧縮せざるを得ない場合があることは理解しています。データベースの同時操作とデータベースに含まれるテーブルのスキーマは、データベースの圧縮操作の実行時間に影響を与えることがあります。つのデータベースでは、圧縮にかかる時間が大きく異なります。ページを移動して、ファイルの最後に空き領域をまとめます。システムに返されます。ページ上で排他ロックをかける必要があります。他のユーザーは、そのページに対してロックや書き込みを行うことができません。データベースで、ロックを伴う同時操作が発生した場合、圧縮操作はブロックされ、ロックをかけられるようになるまで待機する必要があります。このような状況が発生すると、圧縮に必要な時間は、データベースで他の操作が行われていない場合よりも長くなります。つの考慮事項としては、他のデータベース構造に、移動するページ上のデータへの物理的なポインターが含まれている場合、この物理的なポインターを新しいページの場所に更新する必要があります。以上テーブルに含まれる場合、あるいはその両方の場合は例外です。レコードへの物理的なポインターが含まれます。ページが移動した場合は、非クラスター化インデックスを更新する必要があります。メンテナンスを実行して、インデックスを更新します。データをポイントします。ポインターはありません。レコードを更新する必要があります。レコードを特定する必要があります。データを含むテーブルでは、このプロセスは非常に低速になります。列で、進行状況レポートが提供されるようになりました。カウンターを監視して、圧縮の処理速度を確認することもできます。プラクティスについて、オンラインでたくさんの資料を読んでいるところです。自動拡張は有効にすべきであるかどうかについて、相反する見解に困惑しています。問題を起こさずに、自動拡張を無効にできますか。簡単にお答えすると、自動拡張は有効にする必要がありますが、この機能に依存しないようにしてください。(または、予期しない突然の拡張が行われた場合は、その原因を調査します)。ファイルのサイズと使用状況を管理している担当者が、すぐにファイルを管理できる状況ではないという緊急時に備えて自動拡張を有効にします。ログで使用可能な領域が確保されるまで、データベースに対する書き込み操作は実行できなくなります。メンテナンス操作は、失敗することがあります。難しいのは、自動拡張の設定を理解することです。割合ベースの自動拡張では、ファイルが拡張されると、自動拡張される領域も増加することになります。ファイルの瞬時初期化が有効になっていないと、自動拡張にかかる時間も増加します。そのため、どちらのファイルでもサイズを指定した自動拡張を利用することで、自動拡張の動作が予測可能になります。ファイルで問題が発生する可能性があります。ここではファイルの瞬時初期化は使用できないので、新しく割り当てられたファイル領域を、ゼロで初期化する必要があります。ログに対するすべての書き込み操作はブロックされます。ファイルの自動拡張のバランスを取る必要があります。操作がしばらく続行できる程度に拡張し、操作の流れが長い間中断されてしまうほど、大幅な拡張は避けるようにします。自動拡張を設定するのは、どう考えても少なすぎますが、適切な値を判断するのは容易ではありません。ファイルのサイズを手動で管理するように置き換えるのかによって異なります。データベースに挿入されるデータに対応するのに日々必要な新しい領域の量によっても異なります。結論は、自動拡張は有効にして、割合ではなく、適切な値を設定する必要があるということになります。スキーマを再設計しています。テーブルには、たくさんの文字データが格納されているものもあり、最も効率的な方法で、この文字データを格納できるようにしたいと考えています。プラクティスを教えていただけませんか。データを格納する方法は、クエリのパフォーマンスに大きく影響することがあるため、適切な方法を選択することは、きわめて重要です。すべてのオプションについて詳しく分析すると、このコラムで扱う範囲を超えてしまうので、ガイドラインをいくつか紹介します。バイトよりも小さいですか。データ型は使用しないようにします。廃止されたので使用しないでください。データ型ほど機能的ではありません。データを頻繁に使用する場合、クエリで効率的に取得できるので、行内に格納することをお勧めします。データを頻繁に使用しない場合は、通常、行外に格納する方が適切です。パフォーマンスの向上を実現できます。データしか格納できないことに注意してください。レコードの他の列を指定すると、自動的に行外に格納されるので、物理的に可能な範囲で格納できるデータ量に制限はなくなります。列を含むインデックスでは、オンラインのインデックス操作を実行できません。これはテーブルのクラスター化インデックスに影響があります。メンテナンス戦略の選択肢は増えます。アクセスが必要になることもあります。データ型の使用を検討する必要があります。ストレージ手法を選択することの重要性、英語)」を参照してください。チェックを実行するつもりです。各データベースでは、どのくらいの頻度でチェックを実行する必要がありますか。データベースにとって重要です。ページ検証手法を使用するのも重要です。以降のバージョンのデータベースでは、ページのチェックサムを有効にします。データベースでは、破損ページ検出を使用します。整合性チェックの実行頻度について絶対に正しい答えを出すのは容易ではありません。回、できるだけ頻繁に実行することをお勧めします。