y a-t-il des différences significatives avec plus de 500 millions de tables de lignes dans Oracle?

Je suis concepteur de bases de données dans un environnement d'entrepôt de données. J'ai l'habitude de traiter des tableaux avec un maximum de 1 million de lignes et je suis maintenant confronté à des tableaux avec plus d'un demi-milliard de lignes. Existe-t-il des différences significatives avec les outils de la "boîte à outils efficacité"? Puis-je faire confiance à mes connaissances antérieures sur les index, les partitions, etc., ou certains de ces outils spécifiques sont-ils plus un obstacle qu'une aide avec des données aussi volumineuses? D'autres conseils pour gérer les tables?

(Déjà trouvé un excellent article sur la mise à jour de 700 millions de lignes avec la même valeur )

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.

La quantité a une qualité qui lui est propre.

Lorsqu'il s'agit de tables de cette taille, il est utile de ne pas penser la table de faits comme une table, mais de la considérer au niveau du segment ou comme une collection de tables discrètes. (Être assez vieux pour se souvenir de rouler mon propre partitionnement avec des vues de partition aide.)

Le papier Scaling to Infinity de Tim Gorman est une ressource inestimable.