SQL Serverのクラスター化インデックスとOracleのインデックス構成テーブル

私はSQL ServerからOracleへのデータベース開発者としての移行を行っており、ここですでに素晴らしいリソースを見つけました（ OracleへのSQL ServerのDBAからの移行を行うためにどのように？とDBAとして、どのように私は、OracleからSQL Serverへの移行については行くだろう？）しかし、Oracleでのインデックス構成テーブルの使用に関する適切な情報を見つけるのに苦労しています。

以前の人生では、OLTP風のデータマートでSQL Serverのクラスター化インデックスを広範囲に使用して大きな成功を収めました。索引構成表は、Oracleの便利なツールですか？

SQL ServerからOracleに移行する場合は、最初にヒープテーブルを試すことをお勧めします。ヒープテーブルは、Oracleにデータを格納する標準的な形式であるためです。ほとんどのワークロードでは、Oracleの通常のインデックスを持つヒープテーブルが、DMLとクエリのパフォーマンスに関して最もバランスの取れたストレージ形式です。

後でパフォーマンスの問題やボトルネックがあることがわかった場合は、IOT、パーティショニング、クラスター、リバースキーインデックスなどの特殊な高度なストレージ方法を調べる必要があります。

特にIOTに関しては、初心者としては使いたくないかもしれない「落とし穴」がたくさんあるので、それらの一般的な使用はお勧めしません。

• IOTには実際のROWIDはありません（テーブル自体がないため）。
• その結果、IOTのセカンダリインデックスには行への真のポインタがなく、単なる推測にすぎないため、非効率的なインデックススキャンにつながる可能性があります。
• 仮想列、テーブル圧縮などの一部の機能はIOTで無効になっています、コンポジットパーティション化。
• 非インデックス列（インラインまたはオーバーフローセグメント）を格納する場所を作成時に決定する必要があり、一部のクエリのパフォーマンスに致命的な影響を与える可能性があります。

Oracleの統計情報には行の物理的な分散が含まれているのに対し、SSの統計情報には物理的な場所が含まれていないため、OracleのIOTはSSのクラスター化インデックスとまったく同じではありません。詳細については、OracleとSQL Serverの統計に関するLewisとFritcheyの間のこの議論を参照してください。（http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/education/webinars/webinar-statistics-oracle-sql-server-jonathan-lewis ）これがクラスタ化された理由ですSSのインデックスはヒープよりも優れています。クラスター化インデックスは、物理的な位置データを統計に追加します。IOTは、インデックスが検索対象のデータ行のコロケーションを提供することがわかっている場合に適しています。たとえば、order_dateのインデックスと注文テーブルの顧客は、優れたIOTを作成します。

Vincentは、IOTの警告のいくつかの優れた点を指摘していますが、それらからもいくつかの重要な利点を得ることができます。

個人的には、これらはOracleでは十分に活用されておらず、パフォーマンスの問題に対する可能な限りの解決策ではなく、より広く検討する必要があると思います。IOTとヒープの間で変換するためにテーブルを再作成する必要があるため、これは変更であり、パフォーマンスの問題が深刻でない限り、常に使用頻度の高いデータベースでは起こりそうにありません。

Martin Widlakeには、IOTに関する一連の素晴らしい投稿があります。それらを使用することで得られるいくつかの重要な利点があります。

• 物理および論理IO読み取りを大幅に削減
• システム全体のパフォーマンスを向上させるバッファキャッシュのより効率的な使用
• （オーバーフローセグメントがない限り）テーブルではなく、インデックスを維持するだけで保存される領域

ただし、これらの利点を得るには、クエリに主キーの先頭列を常に（ほぼ）含めるテーブルが必要であり、一度に複数の行をフェッチする可能性があります。このようなテーブルの一般的な例は次のとおりです。

• 注文によく見られる複数のマスター詳細-注文アイテム、請求書-請求書明細など
• 通常「一方向」で照会される多対多の解決テーブル。たとえば、customer_addresses表では、住所のすべての顧客ではなく、顧客のすべての住所を検索する方がはるかに一般的です。

欠点は、データの挿入が遅いため、コストとメリットを比較検討する必要があることです。結局のところ、それはあなたのデータを知り、それがどのように使われるべきかを理解することにかかっています。