タグ付けされた質問 「fragmentation」

このT-SQLを実行して、すべてのテーブルを一度に最適化しようとしたデータベースがあります。 SELECT 'ALTER INDEX all ON ' + name + ' REORGANIZE;' + CHAR(10) + 'ALTER INDEX all ON ' + name + ' REBUILD;' FROM sys.tables 次に、出力を新しいクエリウィンドウにコピーアンドペーストして実行します。エラーは発生しませんでしたが、まだ断片化しています。私も両方のコマンドを別々に実行しようとしましたが、まだ断片化しています。注：REORGANIZEアーロンはこれが不要であることを認識しており、動的SQLを使用してこれを自動化できることを認識しています。 私はこれを実行して、まだ断片化があることを確認しました： SELECT * FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, NULL) WHERE avg_fragmentation_in_percent > 0 そして私は得た： database_id object_id index_id partition_number index_type_desc alloc_unit_type_desc …

41 sql-server-2008  index  fragmentation 

ALTER INDEX REBUILDを使用して、インデックスの断片化を削除しました。場合によっては、REBUILDはこのフラグメンテーションを削除しないようです。REBUILDがフラグメンテーションを削除しない理由は何ですか？これは特に小さなインデックスで発生するようです。

30 sql-server  index  clustered-index  fragmentation 

私は毎日1つのテーブルで約36Kレコードを変更する必要があるプロジェクトを作成しています。私は何が良くなるのだろうかと思っています： 行を削除して新しい行を挿入する、または 既存の行を更新する 私にとっては、すべての行を削除して新しい行を挿入する方が簡単ですが、これがテーブルとインデックスを断片化し、パフォーマンスに影響を与える場合、可能な限り更新を行い、必要な場合にのみ削除/挿入することをお勧めします。 これは毎晩のサービスになりますが、プロセス自体の速度を改善するつもりはありません。私は、このテーブルに対するクエリのパフォーマンスについて、私が既に8,900万件のレコードを持っている場合と、この夜間のプロセスがどのように影響するかについてより懸念しています。 この夜間のプロセスのために、レコードを削除/挿入するか、既存のレコードを更新する必要がありますか（可能な場合）？

27 sql-server  sql-server-2005  performance  fragmentation  application-design 

多数のテーブルが作成および削除されるデータベースがいくつかあります。SQL Serverはシステムベーステーブルの内部メンテナンスを行っていないため、時間の経過とともに非常に断片化し、サイズが肥大化する可能性があります。これにより、バッファプールに不必要な圧力がかかり、データベース内のすべてのテーブルのサイズの計算などの操作のパフォーマンスにも悪影響が及びます。 これらのコア内部テーブルの断片化を最小限に抑えるための提案はありますか？明らかな解決策の1つは、非常に多くのテーブルの作成を回避する（またはtempdbですべての一時テーブルを作成する）ことですが、この質問の目的のために、アプリケーションには柔軟性がないとしましょう。 編集：さらなる研究により、この未回答の質問が示されてALTER INDEX...REORGANIZEいます。これは密接に関連しているように見え、何らかの形での手動メンテナンスがオプションである可能性があることを示しています。 初期調査 これらのテーブルに関するメタデータは、次で表示できますsys.dm_db_partition_stats。 -- The system base table that contains one row for every column in the system SELECT row_count, (reserved_page_count * 8 * 1024.0) / row_count AS bytes_per_row, reserved_page_count/128. AS space_mb FROM sys.dm_db_partition_stats WHERE object_id = OBJECT_ID('sys.syscolpars') AND index_id = 1 -- row_count: 15,600,859 -- …

15 sql-server  sql-server-2014  fragmentation  system-tables 

私の質問には2つの部分があります。 PostgreSQLのデータベースの初期サイズを指定する方法はありますか？ 存在しない場合、データベースが時間の経過とともに大きくなった場合の断片化にどのように対処しますか？ 最近、MSSQLからPostgresに移行しました。データベースを作成するときにMSSQLの世界で行ったことの1つは、データベースとトランザクションログの初期サイズを指定することでした。これにより、特にデータベースの「通常の」サイズが事前にわかっている場合、断片化が減少し、パフォーマンスが向上します。 サイズが大きくなると、データベースのパフォーマンスが低下します。たとえば、私がそれを実行しているワークロードは通常10分かかります。データベースが大きくなると、この時間が長くなります。VACUUM、VACUUM FULL、およびVACUUM FULL ANALYZEを実行しても問題は解決しないようです。パフォーマンスの問題を解決するのは、データベースを停止し、ドライブの断片化を解消してから、VACUUM FULL ANALYZEを実行すると、テストのパフォーマンスが元の10分に戻ります。これは、断片化が痛みの原因であると疑うことにつながります。 Postgresでテーブルスペース/データベーススペースを予約するための参照を見つけることができませんでした。間違った用語を使用しているため何も見つからないか、Postgresでファイルシステムの断片化を緩和する別の方法があります。 ポインタはありますか？ ソリューション 提供された回答は、私が疑い始めたことを確認するのに役立ちました。PostgreSQLはデータベースを複数のファイルに保存します。これにより、断片化の心配なしにデータベースを拡張できます。デフォルトの動作では、これらのファイルをテーブルデータでいっぱいにパックします。これは、ほとんど変更されないテーブルには適していますが、頻繁に更新されるテーブルには適していません。 PostgreSQLはMVCCを使用して、テーブルデータへの同時アクセスを提供します。このスキームでは、更新ごとに更新された行の新しいバージョンが作成されます（これはタイムスタンプまたはバージョン番号を使用している可能性があります）。古いデータはすぐには削除されませんが、削除のマークが付けられます。実際の削除は、VACUUM操作が実行されるときに発生します。 これは曲線因子とどのように関係しますか？テーブルのデフォルトのフィルファクター100はテーブルページを完全にパックします。つまり、テーブルページ内に更新された行を保持するスペースがないことを意味します。つまり、更新された行は元の行とは異なるテーブルページに配置されます。私の経験が示すように、これはパフォーマンスに悪いです。サマリーテーブルは非常に頻繁に更新されるため（最大1500行/秒）、20のFILL FACTORを設定することを選択しました。つまり、テーブルの20％が挿入行データ用で、80％が更新データ用です。これは過度に思えるかもしれませんが、更新された行のために予約された大量のスペースは、更新された行が元のページと同じページ内に留まり、autovacuumデーモンが古い行を削除するまでにテーブルページがいっぱいにならないことを意味します。 データベースを「修正」するために、次のことを行いました。 サマリーテーブルのFILL FACTORを20に設定します。作成時にこれを行うには、パラメーターをCREATE TABLEに渡すか、ALTER TABLEを介してファクトの後に渡します。次のplpgsqlコマンドを発行しました。ALTER TABLE "my_summary_table" SET (fillfactor = 20); VACUUM FULLを発行しました。これにより、完全に新しいバージョンのテーブルファイルが書き込まれ、含意により新しいフィルファクターで新しいテーブルファイルが書き込まれます。 テストを再実行すると、数百万行のデータベースが必要な大きさであっても、パフォーマンスの低下は見られません。 TL; DR-ファイルの断片化は原因ではなく、表スペースの断片化でした。これは、特定のユースケースに合わせてテーブルのFILL FACTORを調整することで軽減されます。

12 sql-server  postgresql  fragmentation  database-size 

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でテーブルを最適化すると、実際にテーブルのすべてのインデックスが再構築されますか？ （ツリー自体を再構築せずに）インデックスの物理スペースを減らすと、実際にパフォーマンスが向上すると考えるのは現実的ですか？

12 mysql  fragmentation  index-maintenance 

1日2回挿入される100.000プレーヤー用のハイスコアテーブルがあり、プレーヤーごとに1つのレコードがあります。1日の終わりに、そのテーブルのインデックスのインデックスの断片化は99％です。設定を微調整してこれを防ぐ方法はありますか？ CREATE TABLE HighScore( [id] [int] IDENTITY(1,1) NOT NULL, [user] [int] NULL, [player] [int] NULL, [round] [tinyint] NULL, [group] [int] NULL, [rank] [int] NULL, [delta] [int] NULL, [roundpoints] [int] NULL, [totalpoints] [int] NULL, PRIMARY KEY CLUSTERED ( [id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS …

11 sql-server-2008  index  fragmentation 

私の雇用主は、Windows MoveFile APIを使用して開いているファイルを最適化するNTFS最適化ソフトウェアの展開を検討しています。これは、2005-2012のSQLバージョンと2003および2008 R2のWindowsバージョンを実行する何千ものSQL Serverサーバーに展開されます。重要なのは、私が話している製品はPerfectDiskですが、同じように機能する同様のプログラムがあると思います。 これまでのテストでは、偶発的なI / Oパフォーマンスの問題を除いて、多くの問題が判明していません。これは驚くべきことではなく、デフラグの再スケジュールとチューニングによって回避できます。しかし、私はデータ破損のリスクについてより懸念しています。 このタイプのソフトウェアをデータベースサーバーの運用環境で実行した経験がある人はいますか？データ破損が発生しましたか？ それが問題を引き起こしているという確固たる証拠を見つけることができなくても、私はこれについてはむしろ不安です。 返信ありがとうございます。 追加のために編集：この恐ろしいアイデアはありがたいことに、おそらく一部は私が出した警告のせいで忘れられていました。

11 sql-server  fragmentation 

SQL Server 2005 900Mのレコードテーブルで約350Mのレコードを継続的に処理できる必要があります。処理するレコードを選択するために使用しているクエリは、処理中に著しく断片化され、インデックスを再構築するために処理を停止する必要があります。疑似データモデルとクエリ... /**************************************/ CREATE TABLE [Table] ( [PrimaryKeyId] [INT] IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, [ForeignKeyId] [INT] NOT NULL, /* more columns ... */ [DataType] [CHAR](1) NOT NULL, [DataStatus] [DATETIME] NULL, [ProcessDate] [DATETIME] NOT NULL, [ProcessThreadId] VARCHAR (100) NULL ); CREATE NONCLUSTERED INDEX [Idx] ON [Table] ( [DataType], …

10 sql-server  sql-server-2005  fragmentation 

私は最近、1つのヒープテーブルに70％以上の断片化があることがわかりました。だから私はすることにしました ALTER TABLE dbo.myTable REBUILD 面白いことに、その後20％の断片化がありました。それ以来、そのテーブルへの書き込みはありませんでした。だから私はもう一度リビルドをすることにしました。 2回目以降は、テーブルハットの断片化が50％増えるため、さらに多くのことを実現できます。 どうしてこんなことが起こるのか本当にわかりません...

10 sql-server  fragmentation  heap 

これに関する決定的なリソースをどこでも見つけるのに苦労しているので、グルがここで答えを出してくれるといいのですが。 列を追加する必要がある非常に大きなテーブルがあります。クラスタ化インデックスはかなり高度に断片化されておりALTER INDEX REBUILD、クリーンアップするために実行したいと思います。 また、通常はALTER TABLE REBUILD列を変更するときにも行います。これにより、その操作からのポインターまたは分割がクリーンアップされるためです。 クラスター化インデックス（基本的にはテーブル）について話しているので、両方を実行する必要がありますか？ 私の疑いは、ALTER INDEX REBUILDクラスター化された意志が意志のすべてを更新するわけではないALTER TABLEことですがALTER TABLE、インデックスの断片化がクリーンアップされないことも心配です。

9 sql-server  sql-server-2008-r2  optimization  fragmentation 

インデックスの再構築に必要な時間は、断片化のレベルに依存していますか？ 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時間は行の数によってのみ影響を受ける可能性があるため、手順が間違っていると思います。私はこの理論を本当に信じていません。 だから、私は本当にこれを絶対に知りたいので、それ以上のコメントや提案は大歓迎です。

8 sql-server  sql-server-2008-r2  fragmentation  index-maintenance 

IDENTITY型の列など、常に単調に増加する値のBツリーインデックスについて考えます。従来のBツリーの実装では、ノードがいっぱいになると常に50％/ 50％に分割され、（ほとんど）すべてのノードが50％だけいっぱいになるBツリーになります。 私は、Oracleが値が増加し続けるときを発見し、そのような場合にOracleが90％/ 10％の分割を実行することを知っています。そうすれば、（ほぼ）すべてのノードが90％満たされ、これらの非常に一般的なケースではるかに優れたページ使用率が得られます。 SQL Serverの同様の機能に関するドキュメントを見つけることができませんでした。ただし、N個のランダムな整数とN個の連続した整数をそれぞれインデックスに挿入する2つの実験を実行しました。前者のケースは後者をはるかに多くのページを使用しました。 SQL Serverは同様の機能を提供しますか？もしそうなら、あなたは私にこの機能に関するいくつかのドキュメントを教えてもらえますか？ 更新： 以下の実験では、リーフノードは分割されず、内部ノードは50％/ 50％に分割されているようです。これにより、増加するキーのBツリーは、ランダムキーよりもコンパクトになります。ただし、Oracleによる90％/ 10％アプローチはさらに優れており、実験で確認された動作を検証できる公式ドキュメントを探しています。

8 sql-server  fragmentation  index  page-splits