問題タブ [database-fragmentation]

過去 1 年間、ゆっくりと成長している大規模なデータベース (90 GB のデータ、70 GB のインデックス) があり、その成長/変更により、インデックスだけでなく、テーブル自体にも大量の内部断片化が発生しています。

（多数の）非常に断片化されたインデックスを解決するのは簡単です-断片化の程度に応じて、REORGANIZEまたはREBUILDがそれを処理します-しかし、実際のテーブルの断片化をクリーンアップする際に見つけることができる唯一のアドバイスは、クラスター化されたインデックスを追加することですテーブルに。今後テーブルにクラスター化インデックスを作成したくないので、後ですぐに削除しますが、クラスター化インデックスを使用せずにこれを行う別の方法はありますか? これを行う「DBCC」コマンドは？

ご協力いただきありがとうございます。

シーケンシャル guid が通常の guid よりも優れたパフォーマンスを発揮する方法を理解しようとしています。

通常のGUIDでは、インデックスがGUIDの最後のバイトを使用してソートするためですか? ランダムなので、新しいデータを挿入するためにデータを別のページに移動することが多いため、多くの断片化とページ分割が発生しますか?

シーケンシャルガイドはシーケンシャルであるため、ページ分割と断片化が大幅に少なくなりますか?

私の理解は正しいですか？

誰かがこの主題にもっと光を当てることができれば、私はとても感謝しています.

ありがとうございました

編集：

順次 GUID = NEWSEQUENTIALID()、

通常の GUID = NEWID()

必要以上にスペースを取っているように見えるテーブルがあります。データを新しいテーブルにコピーし、新しいテーブルと古いテーブルの名前を変更してそれらを交換することをお勧めします。現在のテーブルが実際に断片化されているかどうかを確認するにはどうすればよいですか？同じデータを含む新しいテーブルの新しいサイズを推定または計算するにはどうすればよいですか？

列にクラスター化インデックスがある次のテーブルがあるとします (たとえば、a)

次に、テーブルに挿入する非常に多数の行のセットが 2 つあるとします。

• 1 番目のセット) 値は順次増加します (つまり、{0,1,2,3,4,5,6,7,8,9,..., 999999997, 999999998, 99999999})
• 2 番目のセット) 値は順次減少します (つまり、{99999999,999999998,999999997, ..., 3,2,1,0}

最初のセットと 2 番目のセットに値を挿入すると、パフォーマンスに違いがあると思いますか? もしそうなら、なぜですか？

ありがとう

「単純な述語の重要な側面は、それらの完全性です。もう 1 つは、それらの最小性です。一連の述語は、simple predicates Pr:すべてのアプリケーションによるアクセスの可能性が等しい場合にのみ、完全であると言われます。にPr2。

Example:-PROJで与えられた関係の断片化を考えてみましょうExample 3.8。アクセスする唯一のアプリケーションがPROJ場所に従ってタプルにアクセスしたい場合、各フラグメントの各タプルはPROJi (Example 3.8)同じ確率でアクセスされるため、セットは完全です。ただし、 が存在するプロジェクト タプルのみにアクセスする 2 つ目のアプリケーションがある場合budget is less than or equal to $200,000、Pr is not completeそれぞれのタプルの一部は、PROJiこの 2 番目のアプリケーションによりアクセスされる可能性が高くなります。述語のセットを完成させるには、以下を追加する必要があります(BUDGET <= 200000, BUDGET > 200000) to Pr。

Pr = {LOC=“Montreal”, LOC=“New York”, LOC=“Paris”, BUDGET <= 200000, BUDGET > 200000}"

図 3.3 と例 3.8 をアップロードしました: -

図 3.3

例 3.8

Prが完了したかどうかを知る方法がわかりません

したがって、「すべてのアプリケーションが任意の minterm フラグメントに属する任意のタプルにアクセスする確率が等しい」とはどういう意味ですか

各アプリケーションが任意のタプルにアクセスするための等確率を計算する方法の例はありますか?

データベースにいくつかのテーブル (User & UserRecord) があり、それらが極端に断片化 (99% など) し、データベース全体が停止するため、Web サイトが停止します。

UserRecord は、ある時点でのそのユーザーのスナップショットのようなものです。ユーザーは、そのユーザーのマスター レコードのようなものです。ユーザーには 0 から多数の UserRecords があります。ユーザーには約 100 万行あり、UserRecord には約 250 万行あります。これらのテーブルはたくさん書き込まれます。彼らもよく捜索されています。二人ともこれからどんどん大きくなっていきます。ひどく断片化されている主なインデックスは、User テーブルと UserRecord テーブルの主キーです。

DB は SQL Server 2012 で、Entity Framework を使用しており、ストアド プロシージャは使用していません。

テーブルは次のようになります。

(リストが重要かどうかはわかりませんが、User_Record に関連しているので含めたいと思いました。リストには 0 から多数の UserRecords があります)

毎日インデックスを再構築する SQL メンテナンス プランを設定しましたが、これは役に立ちますが、十分でない場合もあります。

友人は、2 つのデータベースを使用することを提案しました。1 つは読み取り用、もう 1 つは書き込み用です。読み取り DB を書き込み DB から同期します。これを行うことについて何も知らないというわけではありませんが、このソリューションで最初に目にする問題は、サイトを表示するときに最新のデータが必要だということです. たとえば、ユーザーの詳細または UserRecord を更新する場合、それらの変更をすぐに確認したいと考えています。

この問題が制御不能になる前に、この問題を修正する方法について何か提案はありますか?

テーブルの列に char/varchar2 データ型を選択し、テーブルでバッチの削除/挿入/更新を発行するとき、行の断片化は常に考慮する必要がありました。これは、Oracle が新しいデータを開いている空き領域に合わせようとするため、断片化が遅くなり始める可能性があるためです。一時的にパフォーマンスを低下させます。フラッシュテクノロジー自体により、データは可能な限り断片化されて書き込まれるため、フラッシュストレージディスクですべてが変わりました。断片化に注意する必要がない場合、テーブル データ ストレージの問題とデータの断片化に関する理解が完全に失われます。データベース ファイルをフラッシュ ストレージ ディスクに保存した経験のある人はいますか? フラグメンテーションの問題は SSD ディスクで解消されましたか?

たとえば、タスクを含むテーブルがあります。一部のタスクは新規または進行中の段階にありますが、他のタスクはアーカイブ段階にあります。つまり、それらのタスクは処理済みであり、元に戻る可能性は低いということです。「現在の」タスクへのクエリが高速になるように、アーカイブされたタスクを同じスキーマの別のテーブルに配置するのが賢明だと考えていました。そうですか？

(検索結果のように) アーカイブされたタスクを含む現在のタスクを表示する必要がある場合は、単純に 2 つのテーブルを結合します。

これは正しいですか？何かメリットはありますか？水平断片化と呼ばれるものだと思います。MySQL InnoDB を使用しています。パフォーマンス上の利点を実際に得るために、テーブル定義に何か特別なことをする必要がありますか?

ありがとう！！

テーブルで DBCC SHOWCONTIG を実行すると、論理スキャン フラグメンテーションは大きくないが、エクステント スキャン フラグメンテーションは大きいことがわかり、少し混乱しました。

MSDN のマニュアルから見ると、1 つはページの断片化に関するもので、もう 1 つはエクステントに関するものです。他に違いはありますか？エクステント スキャン フラグメンテーションが高いままで、論理スキャン フラグメンテーションが低いのはなぜですか?

また、「外部フラグメンテーション」について話すときは、結果の「論理スキャン フラグメンテーション」または SHOWCONTIG の結果の「エクステント スキャン フラグメンテーション」に関連していますか?

どんな答えでも本当に感謝します。