Les principes de base de l'indexation, etc. fonctionnent tous exactement de la même manière, donc à proprement parler, la seule différence est le coût d'une erreur!
Cela dit, voici une liste (pas nécessairement complète) de choses à retenir:
- Les index B-tree sont susceptibles d'avoir un niveau supplémentaire en eux, donc le coût de leur utilisation est légèrement plus élevé. Cependant, dans un DW, vous devez utiliser des index bitmap (en supposant que vous ayez l'édition entreprise)
- Il faudra beaucoup plus de temps pour calculer les statistiques de l'ensemble du tableau - au point où cela peut ne pas être possible dans la fenêtre de nuit normale. Cela peut être surmonté en
- Utiliser un plus petit
estimate_percentlors de la collecte des statistiques, donc moins de table est échantillonnée.
- Utilisation de la collecte de statistiques incrémentielles (pertinente uniquement si vous avez des index globaux sur les tables partitionnées cependant)
- Les histogrammes des index sont limités à 254 seaux. Plus de lignes signifient probablement des valeurs plus distinctes, ce qui signifie que les valeurs "presque populaires" peuvent être un problème plus important pour les données asymétriques.
- Les chances que votre table entière tienne dans le cache tampon approche de zéro, ce qui signifie que vous êtes plus susceptible d'avoir plus de lectures physiques (disque). Votre jeu de travail normal peut également être trop volumineux pour être mis en cache.
- Le partitionnement peut être votre ami - si vous le faites bien! Si vous modifiez et interrogez généralement des données sur plusieurs partitions, cela peut vous coûter plus cher que les tables ordinaires.
- Les vues matérialisées peuvent être très utiles pour réduire votre ensemble de travail. Par exemple, si vous avez plus de 10 ans de données, mais que la grande majorité des requêtes des utilisateurs ne concernent que les 2 dernières années, la création d'un MV limité à ces seules données peut être d'une grande aide.
- Plus la base de données est grande, moins il est probable que l'entreprise financera (pourra) financer une base de données de test qui est un double complet de l'environnement réel. Cela rend plus difficile la reproduction des problèmes de performances dans le test, car les requêtes lentes peuvent être dues à l'échelle et / ou au stockage physique des données. Vous ne pouvez pas compter sur la possibilité d'extrapoler les résultats des requêtes d'une base de données de test beaucoup plus petite aux performances correspondantes en direct.
Si vous n'êtes pas déjà familier avec la lecture et la compréhension des plans d'exécution, je passerais un peu de temps à les apprendre: vous êtes obligé de rencontrer des problèmes de performances à un moment donné, alors savoir comment diagnostiquer correctement le problème deviendra plus important car il est plus difficile d'en ajouter de nouveaux. indexez ou modifiez le schéma lorsque le nombre de lignes est plus important.
