タグ付けされた質問 「index-maintenance」

1
フルテキストインデックスメンテナンスのガイドライン
フルテキストインデックスを維持するには、どのガイドラインを考慮する必要がありますか？ フルテキストカタログを再構築または再編成する必要があります（BOLを参照）。合理的なメンテナンスケイデンスとは何ですか？どのようなヒューリスティック（10％および30％の断片化しきい値に類似）を使用して、メンテナンスが必要かを判断できますか？ （以下はすべて、質問について詳しく説明し、これまでに考えたことを示す追加情報です。） 追加情報：最初の調査 Bツリーインデックスのメンテナンスに関するリソースは多数あります（たとえば、この質問、Ola Hallengrenのスクリプト、および他のサイトの主題に関する多数のブログ投稿）。ただし、これらのリソースのいずれも、フルテキストインデックスを維持するための推奨事項またはスクリプトを提供していないことがわかりました。 ベーステーブルのBツリーインデックスを最適化し、フルテキストカタログでREORGANIZEを実行するとパフォーマンスが向上する可能性があることを記載したMicrosoftのドキュメントがありますが、それ以上の具体的な推奨事項については触れていません。 私もこの質問を見つけましたが、それは主に変更追跡（基になるテーブルへのデータ更新がフルテキストインデックスに伝播される方法）に焦点を当てており、インデックスの効率を最大化できるタイプの定期的なメンテナンスではありません。 追加情報：基本的なパフォーマンステスト このSQL Fiddleには、AUTO変更追跡を伴うフルテキストインデックスを作成し、テーブル内のデータが変更されたときのインデックスのサイズとクエリパフォーマンスの両方を調べるために使用できるコードが含まれています。（フィドルの人工的に製造されたデータとは対照的に）生産データのコピーでスクリプトのロジックを実行すると、各データ変更ステップの後に表示される結果の概要は次のとおりです。 このスクリプトの更新ステートメントはかなり不自然でしたが、このデータは定期的なメンテナンスによって多くのことが得られることを示しているようです。 追加情報：最初のアイデア 毎晩または毎週のタスクを作成することを考えています。このタスクは、REBUILDまたはREORGANIZEを実行できるようです。 フルテキストインデックスは非常に大きい（数千または数億行）可能性があるため、カタログ内のインデックスがREBUILD / REORGANIZEが保証されるほど十分に断片化されていることを検出できるようにしたいと思います。ヒューリスティックがそのために何を意味するのか、私には少しわかりません。
6
インデックスの再編成中にトランザクションログがいっぱいになるのを防ぐ方法
この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 トランザクションログのサイズを50 GBに事前に割り当てた複数のマシンがあります。再編成しようとしているテーブルのサイズは55〜60 GBですが、継続的に増加します。私が再編成したい主な理由は、スペースを再利用することであり、それによるパフォーマンス上の利点は追加のボーナスです。 テーブルの断片化レベルは30〜35％です。これらのマシンの一部では、「トランザクションログがいっぱいです」エラーが発生し、再編成が失敗します。トランザクションログのサイズは最大48GBに達します。これに対抗する良い方法は何ですか？自動インクリメントをオンにしていません。これを行うのは嫌です。 ログサイズをより大きな値に増やすことはできますが、将来テーブルサイズが大きくなると、値が十分ではなくなる可能性があります。また、ログサイズを均等に増やしようとすると、スペースを再利用するために再編成を行う目的が無効になります。これに効果的に対処する方法についてのアイデアはありますか？データ損失は許容されないため、バルクモードの使用はオプションではありません。
3
IndexOptimize後のクエリと更新が非常に遅い
データベースSQL Server 2017 Enterprise CU16 14.0.3076.1 最近、デフォルトのIndex RebuildメンテナンスジョブからOla Hallengrenへの切り替えを試みましたIndexOptimize。デフォルトのインデックス再構築ジョブは問題なく数か月間実行されており、クエリと更新は許容可能な実行時間で機能していました。IndexOptimizeデータベースで実行した後： EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y' パフォーマンスが極端に低下しました。IndexOptimize100ミリ秒かかった更新ステートメントは、その後78.000ミリ秒かかり（同じプランを使用）、クエリのパフォーマンスも数桁悪化していました。 これはまだテストデータベースであるため（Oracleから運用システムを移行しています）、バックアップにIndexOptimize戻り、無効にしてすべてを通常に戻しました。 ただし、この極端なパフォーマンスの低下を引き起こす可能性のIndexOptimizeある「通常」Index Rebuildとは何が異なるのかを理解して、本番環境に移行したときにそれを回避できるようにします。何を探すべきかについての提案は大歓迎です。 遅い場合の更新ステートメントの実行計画。すなわち、 IndexOptimizeの実際の実行計画の後 （できるだけ早く） 違いを見つけることができませんでした。 高速な場合は同じクエリを計画する 実際の実行計画
2
MySQLインデックスのメンテナンス
MySQLでインデックスを維持して断片化を防ぎ、いくつかのクエリの実行を何らかの方法で最適化する方法について、多くの調査を行いました。 テーブルで使用可能な最大スペースとデータとインデックスで使用されるスペースの比率を計算する式に精通しています。 しかし、私の主な質問はまだ答えられていません。おそらく、これはSQL Serverでのインデックスのメンテナンスに精通しているためであり、MySQLでもそれはある程度似ているはずだと思う傾向があります。 SQLサーバーでは、いくつかのインデックスを設定でき、それぞれに異なるレベルの断片化を設定できます。次に、1つをピックアップして、残りに影響を与えることなく、その特定のインデックスで「REORGANIZE」または「REBUILD」操作を実行できます。 私の知る限りでは、このような「テーブルの断片化」はなく、SQL Serverは「テーブルの断片化」を修正するためのツールを提供していません。それが提供するのは、内部および外部の断片化だけでなく、インデックスの断片化（インデックスによって使用されるページ数とそのページの完全性と連続性の間の比率のように理解される）をチェックするツールです。 少なくとも私にとっては、そのすべてを理解するのは非常に簡単です。 MySQLでインデックスを維持する番になると、前述のように「テーブルの断片化」の概念しか存在しません。 MySQLのテーブルには複数のインデックスを含めることができますが、その有名な式で「断片化率」を確認すると、各インデックスの断片化が表示されず、テーブル全体が表示されます。 MySQLでインデックスを最適化したい場合、（SQL Serverのように）操作する特定のインデックスを選択しません。代わりに、テーブル全体で「OPTIMIZE」操作を実行します。これは、おそらくすべてのインデックスに影響します。 MySQLでテーブルが最適化されると、データ+インデックスVS全体のスペースによって使用されるスペースの比率が減少します。これは、ハードドライブでのある種の物理的な再編成を示唆し、物理スペースの減少につながります。ただし、インデックスの断片化は、物理的なスペースだけでなく、挿入と更新によって時間の経過とともに変更されたツリーの構造に関するものです。 最後に、InnoDB / MySQLにテーブルを取得しました。このテーブルには、300万レコード、105列、55インデックスがあります。2.1GBのインデックスを除いて1.5GBです。 このテーブルは、更新、挿入のために毎日何千回もヒットしています（実際にはレコードを削除しません）。 そのテーブルは何年も前に作成されており、誰もインデックスを維持している人はいません。 そこに巨大な断片化を見つけることを期待していましたが、規定どおりに断片化計算を実行すると free_space / (data_length + index_length) 断片化が0.2％しかないことがわかります。私見はかなり非現実的です。 したがって、大きな質問は次のとおりです。 テーブル全体ではなく、MySQLの特定のインデックスの断片化をチェックするにはどうすればよいですか SQL Serverのように、OPTIMIZE TABLEは実際にインデックスの内部/外部断片化を修正しますか？ MySQLでテーブルを最適化すると、実際にテーブルのすべてのインデックスが再構築されますか？ （ツリー自体を再構築せずに）インデックスの物理スペースを減らすと、実際にパフォーマンスが向上すると考えるのは現実的ですか？
6
インデックスの再構築時間は断片化レベルに依存しますか？
インデックスの再構築に必要な時間は、断片化のレベルに依存していますか？ 80％フラグメント化されたインデックスの再構築は、40％フラグメント化された同じインデックスの再構築に1分かかる場合、約2分かかりますか？ 特定の状況でどのアクションが必要かについてではなく、必要なアクションを実行するために必要となる可能性があるRUNTIME（たとえば、秒単位）を求めています。インデックスの再編成または再構築/統計の更新を行う必要がある場合の基本的なベストプラクティスを知っています。 この質問では、REORGおよびREORGとREBUILDの違いについては尋ねられません。 背景：さまざまなインデックスメンテナンスジョブ（毎晩、週末は重いジョブ）のセットアップのため、毎日の「非常に負荷の高い」オフラインインデックスメンテナンスジョブは、中程度の断片化されたインデックスでより適切に実行して、オフタイムが小さい-またはそれは問題ではなく、80％フラグメント化されたインデックスでの再構築は、40％フラグメント化された同じインデックスでの同じ操作と同じオフタイムを取る可能性があります。 私は提案に従い、何が起こっているのかを自分で見つけようとしました。私の実験的なセットアップ：他にNOTHINGを実行し、他の誰にも使用されていないテストサーバーで、いくつかの追加の列と異なるデータ型[2つの数値、9つの日時、 2 varchar（1000）]と単純に行を追加しました。提示されたテストでは、約305,000行を追加しました。 次に、更新コマンドを使用して、整数値でフィルタリングする行の範囲をランダムに更新し、文字列値を変更してVarChar列の1つを変更し、断片化を作成しました。その後、で現在のavg_fragmentation_in_percentレベルを確認しましたsys.dm_db_index_physical_stats。ベンチマークに「新しい」断片化を作成するたびに、この値を含めてこの値を追加しました。これにphysical_page_countは、次の図を構成する記録が含まれています。 それから私は走りました：そして私の録音に使用することによってAlter index ... Rebuild with (online=on); つかみましCPU timeたSTATISTICS TIME ON。 私の期待：私は少なくとも、断片化レベルとCPU時間の間の依存関係を示す一種の線形曲線の兆候を見ることを期待していました。 これはそうではありません。この手順が良い結果に本当に適切かどうかはわかりません。行/ページの数が少なすぎるのではないですか？ しかし、結果は、私の元の質問に対する答えが間違いなくNOになることを示しています。SQL Serverがインデックスを再構築するために必要なCPU時間は、断片化レベルにも基になるインデックスのページ数にも依存していないようです。 最初のグラフは、以前の断片化レベルと比較した、インデックスの再構築に必要なCPU時間を示しています。ご覧のとおり、平均線は比較的一定であり、断片化と必要なCPU時間の間に観察可能な関係はまったくありません。 再構築に多少の時間を必要とする可能性がある、更新後のインデックス内のページ数の変化の影響を尊重するために、FRAGMENTATION LEVEL * PAGES COUNTを計算し、必要なCPU時間の関係を示す2番目のグラフでこの値を使用しました対断片化とページ数。 ご覧のとおり、これは、ページ数が変わっても、再構築に必要な時間がフラグメント化の影響を受けることを示していません。 これらのステートメントを作成した後、巨大で高度にフラグメント化されたインデックスを再構築するために必要なCPU時間は行の数によってのみ影響を受ける可能性があるため、手順が間違っていると思います。私はこの理論を本当に信じていません。 だから、私は本当にこれを絶対に知りたいので、それ以上のコメントや提案は大歓迎です。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.