Discussion :

[ukanoldai]

Bonjour,
le titre n'est pas très explicite mais je n'ai pas vraiment trouvé mieux.

je m'occupe en partie d'un datawarehouse, je cherche donc a améliorer le temps de certains traitements. Je suis en oracle 9.2.0.6

si l'on prend le cas suivants, cas pratiques dans la gestion de rendez-vous d'un hopital.

j'ai une table avec les horaires par défaut de mes ressources, qui sont un médecin, une salle, ou un appareil. l'horaire est associé a un examen qui est associé de manière unique a un service. pour une même tranche horaire une ressource peut avoir plusieurs examens définis.
En pratique je me retrouve souvent a aller chercher dans cette table pour un service, une ressource, pour une période sélectionnée.

Je pensais donc qu'il serait intéressant d'arriver a organiser la table suvant cette vue pour que le sgbd puisse retrouver les infos dans un nombre restreint de page, plutot que de devoir pratiquement charger toutes les pages de la table même si elle est correctement indexée.

y a t'il quelque chose qui m'assure que si je tronque ma table puis je réinsere dans l'ordre voulu, ce sera physiquement refleté au niveau stockage?

ou bien y a t'il une technique particulière?

merci pour votre aide

[deadoralive]

Bonjour,

J'utiliserais plutot un partitionnement pour la période et des index pour les autre données. Dans le cas ou l'index ne posséde qu'un nombre limité de valeurs, par exemple pour service, préférer un index bitmap.

Cdt

[pifor]

Avant d'envisager une modification de l'organisation physique des données, il est souhaitable d'analyser les performances globales de l'instance avec un outil comme Statspack ou OEM et les performances individuelles des requêtes avec la trace SQL et TKPROF. Il se peut très bien que les problèmes de performances aient d'autres causes.

Noter aussi que la partionnement est une option facturée séparément de la licence de la Enterprise Edition (même si cette option peut être installée sans vérification particulière).

[Wurlitzer]

Attention aux index Bitmap.

Si il s'agit effectivement d'un datawarehouse pas de soucis.

Mais si il s'agit d'un système de gestion des RDV dans un hôpital on est dans un système OLTP (Je dirais même très OLTP, car les temps de réponse sont primordiaux).

Or les index bitmap ont la réputation d'être très efficace pour combiner des colonnes à faible cardinalité mais ils ont aussi la réputation d'être très mauvais en mise a jour.

Sinon je suis (une fois de plus ) d'accord avec pifor. Il faut partir des problèmes remontés par les outils d'analyses pour trouver les solutions et non pas appliquer des solutions a priori pour voir si cela a un impact ou non.

Une dernière chose, en dehors du partitionnement, la seule solution que tu as pour organiser des données dans une table c'est d'utiliser des IOT http://oracle.developpez.com/guide/a...age=Chap1#L1.4

[deadoralive]

si par exemple il n'y a que quelques services, un index bitmap conviendra parfaitement.

Il faut les utiliser effectivement pour des données qui ne sont pas mises à jour souvent. Mais si un examen est affecté à un service, on changera peut-être l'heure, mais rarement le service, la restriction ne tient pas.

Pour les IOT (tables organizées en index) elles ne sont intéressantes que si la table ne contient que la clé ou alors un nombre restreint de données en plus. L'accés est du même ordre que celui fournit par un index b-tree, l'accés aux data en moins.