Discussion :

[tipeh]

Bonjour,

Je souhaiterais engager des travaux d'optimisation sur une base de données. Et l'un des axes d'amélioration que j'ai repéré c'est de réduire la largeur des tables. Mais avant de m'engager dans ça, je souhaiterai m'assurer que l'impact vaut bien l'effort.

En l'occurrence, il s'agit d'une table de faits, donc j'ai plutôt besoin qu'elle soit performante en lecture.

En consultant les statistiques de ma table de fait, je constate que, actuellement, la taille moyenne d'une ligne est de : AVG_ROW_LEN = 186 Byte. En faisant certains reformatages et en supprimant certaines colonnes inutiles, je peux réduire cette valeur de quasiment 50%. Est ce qu'en faisant cela, je gagnerai aussi 50% en performance de lecture ? Par exemple, si avant optimisation, un full table scan se faisait en 2 min, est ce qu'après optimisation, il se ferait en 1 min ?

Merci.

[mnitu]

Faite un test et vous allez avoir la réponse ! En théorie si la taille des enregistrements est réduite Oracle pourrait stocker plusieurs enregistrement dans un même block ce qui fera moins des blocks nécessaires à stocker la même quantité des données et par conséquence un full table plus rapide. Mais en aucun cas de 50%. Et cela reste de la théorie parce que dans un full table scan Oracle peut être amené à lire bien plus des blocks que le nombre « minimum nécessaire » pour stocker les enregistrements.
Mais je pense que vous vous prenez-mal dans votre démarche d’optimisation.

[pachot]

Bonjour,

Oui la durée du Full Table Scan est proportionnelle à la taille de la table.
C'est de toute façon une bonne chose de supprimer les colonnes inutiles.

Toute l'idée du modèle dimensionnel est bien de réduire la taille de la table de faits.

Cordialement,
Franck.

[ora-2013]

bonjour ,

Avez-vous pensé à compresser la table pour réduire les blocs lus en full scan ?

sinon j'ai une question :

Existe-il une technique permettant de monitorer / détecter les colonnes non utilisées de toutes les tables d'une base de données ?

A+

[doc malkovich]

Bonjour,

C'est quoi les reformatages et comment connaissez-vous les colonnes inutiles ?

Si vous parlez d'une table de faits, c'est ce que c'est une table pour le décisionnel.
Généralement elles sont dénormalisées ; on pense que certaines colonnes sont inutiles mais c'est en fait une astuce pour éviter les jointures. Il faut donc faire attention.

[tipeh]

Faite un test et vous allez avoir la réponse ! En théorie si la taille des enregistrements est réduite Oracle pourrait stocker plusieurs enregistrement dans un même block ce qui fera moins des blocks nécessaires à stocker la même quantité des données et par conséquence un full table plus rapide. Mais en aucun cas de 50%. Et cela reste de la théorie parce que dans un full table scan Oracle peut être amené à lire bien plus des blocks que le nombre « minimum nécessaire » pour stocker les enregistrements.
Mais je pense que vous vous prenez-mal dans votre démarche d’optimisation.

Est-il possible d'aller un peu plus loin et me dire pourquoi je m'y prends mal ?

Bonjour,

Oui la durée du Full Table Scan est proportionnelle à la taille de la table.
C'est de toute façon une bonne chose de supprimer les colonnes inutiles.

Toute l'idée du modèle dimensionnel est bien de réduire la taille de la table de faits.

Cordialement,
Franck.

C'est bien ce qui me semblait. En tout cas, vous me rassurez dans mon approche.

bonjour ,

Avez-vous pensé à compresser la table pour réduire les blocs lus en full scan ?

A+

Non je n'ai pas encore essayer ça. Merci pour le conseil.

Bonjour,

C'est quoi les reformatages et comment connaissez-vous les colonnes inutiles ?

Si vous parlez d'une table de faits, c'est ce que c'est une table pour le décisionnel.
Généralement elles sont dénormalisées ; on pense que certaines colonnes sont inutiles mais c'est en fait une astuce pour éviter les jointures. Il faut donc faire attention.

En parlant de reformattage, je me suis probablement mal exprimé. Ce que je voulais dire, c'était de changer le format des clés etrangères stockées dans la table de fait : Actuellement, ils stockent des clés naturelles (c'est à dire les même clés que dans l'appli opérationnelle). Pour les clients par exemple, c'est des clés de type CHAR (15 CHAR) qui occupent énormément de places pour chaque ligne de la table de fait. Je projette de remplacer ça par des clés artificielles qui seraient des séquences.

Pour les colonnes inutiles, justement c'est lié à une trop grande dénormalisation. Par exemple, ils stockent dans cette table de fait le code postal, le département et le pays du client. Et vous avez raison, cela a été fait dans le but d'éviter des jointures. Mais non seulement, cela élargit de trop la table de fait qui sera pénalisée en lecture pour les requêtes qui n'utilisent pas ces infos de géographie, mais en plus ça détruit la vue référentielle. C'est à dire que les même infos de géographie ne pourront pas être réutilisées pour d'autres objets métiers, par exemple les fabricants. Ce que je projette de faire, c'est de supprimer ces colonnes de géographie et de remplacer ça par une clé etrangère vers une table de géographie (et donc normaliser un peu plus la table).

Je suis hyper interessé par avoir des critiques sur l'aspect modélisation car, mis à part des livres que j'ai lu, je n'ai pas une grande expérience professionnelle la dedans. Donc n'hésitez pas à infirmer ou confirmer ce que je dis.

Merci pour vos réponses.