SQL Serverのクラスター化インデックスとOracleのインデックス構成テーブル
私はSQL ServerからOracleへのデータベース開発者としての移行を行っており、ここですでにすばらしいリソースを見つけました（ SQL Server DBAからOracleへの移行方法 および DBAとして、 OracleからSQL Serverに移行するにはどうすればよいですか？ ）が、Oracleでのインデックス構成テーブルの使用に関する適切な情報を見つけるのに苦労しています。
私の前の人生では、OLTP風のデータマートでSQL Serverのクラスター化インデックスを広範囲に使用して大きな成功を収めました。索引構成表は、Oracleの便利なツールですか？
SQL ServerからOracleに移行する場合は、最初にヒープテーブルを試すことをお勧めします。ヒープテーブルは、Oracleにデータを格納する標準的な形式であるためです。ほとんどのワークロードでは、Oracleの通常のインデックスを持つヒープテーブルが、DMLとクエリのパフォーマンスに関して最もバランスの取れたストレージ形式です。
後でパフォーマンスの問題やボトルネックがあることがわかった場合は、IOT、パーティショニング、クラスター、リバースキーインデックスなどの特殊な高度なストレージ方法を検討する必要があります。
特にIOTに関しては、初心者としては使いたくないかもしれない「落とし穴」がたくさんあるので、それらの一般的な使用はお勧めしません。
OracleのIOTはSSのクラスター化インデックスとまったく同じではありません。これは、Oracleの統計には行の物理的な分散が含まれているのに対し、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とcustomerのインデックスは、優れたIOTになります。
Vincentは、IOTの警告のいくつかの優れた点を指摘していますが、それらからもいくつかの重要な利点を得ることができます。
個人的には、これらはOracleでは十分に活用されていないため、パフォーマンスの問題に対する可能な限りの解決策ではなく、より広く検討する必要があります。 IOTとヒープの間で変換するためにテーブルを再作成する必要があるため、これは変更であり、パフォーマンスの問題が深刻でない限り、常に使用頻度の高いデータベースでは起こりそうにありません。
Martin WidlakeにはIOTに関する 一連の素晴らしい記事 があります。それらを使用することで得られるいくつかの重要な利点があります。
- 物理的および論理的IO読み取りを大幅に削減
- システム全体のパフォーマンスを向上させるバッファキャッシュのより効率的な使用
- （オーバーフローセグメントがない限り）テーブルではなく、インデックスを維持するだけで保存されるスペース
ただし、これらのメリットを得るには、クエリに主キーの先頭列を常に（ほぼ）含めるテーブルが必要であり、一度に複数の行をフェッチする可能性があります。このようなテーブルのいくつかの一般的な例は次のとおりです。
- 注文によく見られる複数のマスター詳細-注文アイテム、請求書-請求書明細など.
- 通常「一方向」で照会される多対多の解決テーブル。例えば
customer_addressesテーブルでは、住所のすべての顧客ではなく、顧客のすべての住所を検索する方がはるかに一般的です。
欠点は、データの挿入が遅いため、コストとメリットを比較検討する必要があることです。結局のところ、それはあなたのデータを理解し、それをどのように使用するかを理解することにかかっています。