4 votes

Comment prédire la taille des tables Oracle ?

J'essaie de faire une prédiction de croissance sur certains tableaux que j'ai et pour cela je dois faire des calculs sur la taille de mes lignes, le nombre de lignes que je génère par jour et bien les mathématiques.

Je calcule la taille moyenne de chaque ligne de mon tableau comme la somme de la taille moyenne de chaque champ. Donc, en gros :

SELECT 'COL1' , avg(vsize(COL1)) FROM TABLE union
SELECT 'COL2' , avg(vsize(COL2)) FROM TABLE

Faites le total, multipliez-le par le nombre d'entrées d'une journée et travaillez les prédictions à partir de là.

Il s'avère que pour l'une des tables que j'ai examinées, la taille résultante est beaucoup plus petite que je ne le pensais, ce qui m'a amené à me demander si ma méthode était correcte.

De plus, je n'ai pas tenu compte de la taille des indices pour mes prédictions - et bien sûr, je devrais le faire.

Mes questions sont les suivantes :

  1. La méthode que j'utilise est-elle fiable ?

  2. Des conseils sur la façon dont je pourrais travailler les prédictions pour les indices ?

J'ai fait des recherches sur Internet, mais les méthodes que j'ai trouvées concernent toutes les segments et les extensions, ou bien des calculs basés sur l'ensemble du tableau. J'ai besoin de l'étape avec la ligne réelle de mon tableau pour faire les prédictions (je dois analyser les données dans le tableau afin de déterminer combien d'enregistrements par jour).

Et enfin, il s'agit d'une approximation. Je sais qu'il me manque quelques octets ici et là avec les frais généraux et autres. Je veux juste m'assurer qu'il me manque seulement octets et non gigas :)

5voto

Vincent Malgrat Points 42899

1) Votre méthode est bonne pour calculer la taille moyenne d'une ligne. (Il faut cependant savoir que si votre colonne contient null, vous devez utiliser avg(nvl(vsize(col1), 0)) au lieu de avg(vsize(COL1)) ). Cependant, elle ne tient pas compte de la disposition physique des rangées.

Tout d'abord, il ne prend pas en compte les informations d'en-tête (des blocs et des lignes) : vous ne pouvez pas faire tenir 8k données dans 8k blocs. Voir la documentation sur format du bloc de données pour plus d'informations.

Ensuite, les rangs ne sont pas toujours rangés de manière ordonnée. Oracle laisse un peu d'espace dans chaque bloc pour que les lignes puissent s'agrandir lorsqu'elles sont mises à jour (régi par la fonction pctfree paramètre). De plus, lorsque les lignes sont supprimées, l'espace vide n'est pas récupéré immédiatement (si vous n'utilisez pas ASSM avec des tablespaces gérés localement, la quantité d'espace libre nécessaire pour qu'un bloc revienne dans la liste des blocs disponibles dépend de pctused ).

Si vous disposez déjà de quelques données représentatives dans votre tableau, vous pouvez estimer l'espace supplémentaire dont vous aurez besoin en comparant l'espace physiquement utilisé ( all_tables.blocks*block_size après avoir recueilli des statistiques) à la longueur moyenne des rangs.

D'ailleurs, Oracle peut facilement vous donner une bonne estimation de la longueur moyenne des lignes : rassemblez des statistiques sur la table et interrogez la requête suivante all_tables.avg_row_len .

2) La plupart du temps (lire : à moins qu'il y ait un bug ou que vous fassiez une utilisation atypique de l'index), l'index va croître proportionnellement au nombre de lignes.

Si vous disposez de données représentatives, vous pouvez avoir une bonne estimation de leur taille future en multipliant leur taille réelle par la croissance relative du nombre de lignes.

4voto

Adam Musch Points 8021

La dernière fois qu'Oracle ont publié leurs formules d'estimation de la taille des objets du schéma était dans Oracle 8.0, ce qui signifie que le document lié a dix ans de retard. Cependant, je ne pense pas que beaucoup de choses aient changé dans la façon dont Oracle réserve les informations d'en-tête de segment, d'en-tête de bloc ou d'en-tête de ligne.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X