Version imprimable
Bonjour,
Je suis en Oracle 10GR2, pourriez-vous me clarifier le paramètre star_transformation_enabled.
Je suis en datawarehouse et mes paramètres de la base sont initialisées comme suit :
Code:
2
Quel est votre avis sur la question ?
En vous remerciant,
LBO72
J'ai jamais vraiement compris, ce paramètre.
Cependant sur un datawarehouse mettre
Code:optimizer_mode = ALL_ROWS
Merci pour ta réponse.
C'est ce que j'ai vu aussi en lisant d'autres Doc.
Et pour le Set_tranformation_enable, tu l'as déjà manié :-)
A-t-il une influence sur l'utilisation des index bitmap ?
Cdlt,
Bonjour,
Ce paramètre comme d'autres paramètres de l'instance sont très sensibles pour aboutir au niveau DSS à la Star Transformation.
La "Star Query Transformation" est un élément de première importance pour la performance des entrepôts de données avec Oracle.
Ce mécanisme représente la capacité de l’optimizer Oracle à rechercher la jointure la plus rapide entre les tables de dimensions et une (des) table (s) de faits lors d’une requête SQL.
Oracle règle le problème des jointures multidirectionnelles, inhérent aux requêtes en étoile, en cherchant à optimiser le schéma en étoile.
Une requête standard attaquant un schéma dimensionnel en étoile doit commencer par les tables dimensionnelles sur lesquelles portent des conditions ; elle assemble une liste de combinaisons de clés dimensionnelles composites satisfaisant à ces conditions. Généralement, cette liste est relativement réduite par rapport au nombre total de clés de tables des faits afin d’extraire les lignes appropriées de la table des faits via l’index sur les clés de la table des faits.
Il est primordial de comprendre que des requêtes décisionnelles diffèrent à ce titre radicalement des requêtes OLTP.
Il faut aborder de manière particulière donc l’optimisation du modèle en étoile, l’indexation, le paramétrage de l’instance pour obtenir l’effet escompté.
Aboutir à la STAR QUERY TRANSFORMATION
Modèle de données (STAR SCHEMA)
Déterminer une clé primaire pour chaque table de dimension, sur une seule colonne, idéalement une clé de substitution et non une clé métier ; créer l’index unique associé à la PK
Déterminer une clé primaire pour chaque table de faits ; celle-ci doit être composée de toutes les clefs des tables de dimensions de la table de faits. La clé de la dimension temps sera idéalement placée en première position
Spécifier explicitement les contraintes de type Foreign Key au niveau de la table de faits – ATTENTION : pour les opérations de purge – désactiver au préalable les contraintes -
Eviter tant que possible le recours au floconnage (ajout de sous-dimensions) au modèle en étoile
Indexation avancée
Créer sur les colonnes des tables de dimensions comportant peu de valeurs distinctes des index de type bitmap. Idéalement créer au moins 2 index de ce type par table de dimension. Utiliser ces colonnes dans les critères de tri des dimensions (clause WHERE)
Paramètres de l’instance propres à la STAR TRANSFORMATION
Configurer les paramètres suivants pour permettre un fonctionnement optimal d’oracle au niveau de l’optimizer :
STAR_TRANSFORMATION_ENABLED : détermine si l’estimation du coût au niveau de l’optimizer doit s’appliquer pour des star query. . Cette valeur doit être positionnée à TRUE.
CURSOR_SPACE_FOR_TIME : garantie que l’instruction SQL reste fixée dans la SHARED_POOL le temps d’ouverture d’un curseur. Cette valeur doit être positionnée à TRUE.
DB_CACHE_SIZE : détermine la taille de buffer alloué aux blocs de données. Déterminer cette valeur manuellement. Ne pas positionner de valeur à SGA_TARGET. Doit correspondre à 70/80% de la valeur allouée à la SGA.
DB_BLOCK_SIZE : détermine la taille d’un bloc de données Oracle. Pour le décisionnel, une valeur de 16 ou 32 Ko doit être fixée (taille de bloc importante).
DB_FILE_MULTIBLOCK_READ_COUNT : détermine le nombre de blocs pouvant être lus lors d’un seul accès I/O. En fonction de l’OS, pour le décisionnel cette valeur peut aller jusque 64.
FILESYSTEMIO_OPTIONS : spécifie le type d’opération I/O réalisé au niveau FileSystem. La valeur conseillée pour le DSS est ASYNC.
PGA_AGGREGATE_TARGET : spécifie la taille de mémoire agrégée allouée aux connexions clients. Pour le décisionnel, cette valeur doit être égale à la taille allouée à la SGA.
OPTIMIZER_INDEX_COST_ADJ : indique le coût potentiel que l’optimiser doit intégrer pour favoriser les parcours d’index pour identifier les ROWID. Laisser cette valeur à 100 pour le moment. Envisager de diminuer cette valeur si le parallélisme venait à être employé pour des opérations DML
OPTIMIZER_INDEX_CACHING : indique à l’optimizer s’il doit favoriser les jointures imbriquées (NESTED LOOP). Pour le décisionnel, cette valeur doit être à 0.
QUERY_REWRITE_ENABLED : indique si l’optimizer peut procéder à une ‘ré-écriture’ de requête (INLINE VIEW par exemple) pour déterminer la méthode d’accès avec le plus faible coût. Cette valeur doit être à TRUE.
SHARED_POOL_SIZE : détermine la taille de la SHARED_POOL. Allouer cette valeur manuellement. Ne pas positionner de valeur à SGA_TARGET. Doit correspondre à 10/15% de la valeur allouée à la SGA.
WORKAREA_SIZE_POLICY détermine dans quel mode la zone de travail doit être optimisée pour les opérations intensives réalisées en mémoire. Cette valeur doit être à AUTO.
SESSION_CACHED_CURSORS : spécifie le nombre maximum de curseurs autorisés en cache. Cette valeur doit être à 100 minimum.
BITMAP_MERGE_AREA_SIZE : zone de mémoire allouée au parcours de grandes plages d’index bitmap. Cette valeur doit être de 1M minimum.
CREATE_BITMAP_AREA_SIZE : zone de mémoire allouée à la création d’index de type bitmap. Cette valeur doit être de 10M minimum.
En espérant que ce post (extrait d'une étude que j'avais mené il y a 1 an pourra t'aider)
Ok, je te remercie pour lexplication. Cela me m'a apporté plus de clarté. :ccool:
Cdlt,
LBO72