Index clusterisé dans SQL Server vs tables organisées par index dans Oracle

Je fais la transition en tant que développeur de base de données de SQL Server vers Oracle et j'ai déjà trouvé des ressources fantastiques ici ( Comment faire une transition de SQL Server DBA à Oracle? Et En tant que DBA, comment pourrais-je faire la transition d'Oracle à SQL Server ? ) mais j'ai du mal à trouver de bonnes informations sur l'utilisation des tables organisées par index dans Oracle.

Dans ma vie antérieure, nous avons fait un usage intensif des index clusterisés dans SQL Server dans notre datamart OLTP-ish avec grand succès. Les tables organisées par index sont-elles un outil pratique dans Oracle?

Si vous passez de SQL Server à Oracle, je vous conseille d'essayer les tables de tas dans un premier temps car elles sont la forme standard de stockage des données dans Oracle. Pour la plupart des charges de travail, les tables de tas avec des index réguliers dans Oracle sont les formes de stockage les plus équilibrées en ce qui concerne les performances DML et les requêtes.

Si vous constatez plus tard que vous rencontrez des problèmes de performances ou un goulot d'étranglement, vous devez rechercher des méthodes de stockage avancées spécialisées telles que l'IOT, le partitionnement, les clusters, les index à clé inversée, etc.

En ce qui concerne l'IOT en particulier, je déconseille leur utilisation généralisée car il existe de nombreux "pièges" dans lesquels vous ne voudrez peut-être pas vous lancer en tant que débutant:

• IOT n'a pas de véritable rowid (car il n'y a pas de table en soi).
• par conséquent, les index secondaires sur IOT n'ont pas de vrais pointeurs vers les lignes mais seulement de simples suppositions qui peuvent conduire à des analyses d'index inefficaces.
• Certaines fonctionnalités sont désactivées sur les IOT tels que les colonnes virtuelles , la compression de table , le partitionnement composite.
• Vous devez décider à la création où stocker les colonnes non indexées (en ligne ou dans un segment de débordement), ce qui peut entraîner des performances désastreuses pour certaines requêtes.

Les IOT dans Oracle ne sont pas tout à fait les mêmes que les index clusterisés dans SS, car les statistiques Oracle incluent la dispersion physique des lignes, tandis que SS n'inclut pas l'emplacement physique dans ses statistiques. Voir ce débat entre Lewis et Fritchey sur les statistiques dans Oracle et Sql Server pour plus d'informations. ( http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/education/webinars/webinar-statistics-oracle-sql-server-jonathan-lewis ) C'est pourquoi un cluster index en SS est meilleur qu'un tas. L'index cluster ajoute des données de localisation physique aux statistiques. Les IOT sont bons lorsque vous savez que l'index fournit la colocation des lignes de données qui seront recherchées, par exemple, un index à la date de commande et le client pour une table de commande ferait un bon IOT.

Vincent fait de grands points sur les mises en garde des IOT, mais vous pouvez également en tirer des avantages importants.

Personnellement, je pense qu'ils sont considérablement sous-utilisés dans Oracle et devraient être considérés beaucoup plus largement - et pas seulement comme une solution possible aux problèmes de performances. Comme vous devez recréer la table pour convertir entre IOT et tas, il s'agit d'un changement qui ne se produira probablement pas sur une base de données toujours active et fortement utilisée, sauf si les problèmes de performances sont graves.

Martin Widlake a une grande série de messages sur les IOT. Il y a quelques avantages significatifs que vous pouvez obtenir en les utilisant:

• Réduit considérablement les lectures d'E / S physiques et logiques
• Utilisation plus efficace du cache de tampon, ce qui peut améliorer les performances à l'échelle du système
• Espace économisé car vous ne faites que maintenir un index, pas une table également (sauf si vous avez des segments de débordement)

Cependant, pour obtenir ces avantages, vous avez besoin de tables dans lesquelles vous incluez (presque) toujours la ou les colonnes de tête de la clé primaire dans les requêtes et vous êtes susceptible de récupérer plusieurs lignes à la fois. Voici quelques exemples courants de ces tableaux:

• Maîtrisez les détails multiples que l'on trouve souvent dans les commandes - postes de commande, factures - lignes de facture, etc.
• Tables de résolution plusieurs à plusieurs qui sont généralement interrogées "à sens unique". Par exemple, dans un customer_addressestableau, il est beaucoup plus courant de trouver toutes les adresses d'un client, plutôt que tous les clients d'une adresse.

Un inconvénient est que l'insertion de données est plus lente, vous devez donc peser les coûts et les avantages. En fin de compte, il s'agit de connaître vos données et de comprendre comment elles doivent être utilisées, ce qui devrait guider la décision.