Les hints de jointure et du parallélisme

Les hints de jointure :

• LEADING : Permet de spécifier la table menante dans une jointure                                             select /*+leading (cmd cli) */ cli.noclient,nom, cmd.datecommande                              from clients cli,cmd                                                                        where cli.noclient=cmd.noclient                                                              and cli.noclient between 100000 and 100020 ;

• ORDERED:  Permet de spécifier que les jointures doivent être faites dans l’ordre d’apparition dans la clause FROM.

• USE_NL,NO_USE_NL: Force ou interdit une jointure par boucles imbriquées (Nested Loop).

• USE_NL_WITH_INDEX: Force une jointure par boucles imbriquées seulement si unindex est présent sur la table jointe. Ce hint sera sans effet si l’index disparaît ou est invalidé. En effet, l’impossibilité d’utiliser un index pourrait avoir des conséquences désastreuses en termes de performances : une boucle imbriquée sur une grosse table non indexée a des performances catastrophiques car elle provoque un parcours complet de la table pour chaque valeur de la table menante.
• USE_MERGE, NO_USE_MERGE. Force ou interdit une jointure par Sorted Merge.
• USE_HASH, NO_USE_HASH. Force ou interdit une jointure par table de hachage.

Les hints de parallélisme :

• PARALLEL(table_alias , degré //): Permet de spécifier un niveau de parallélisme pour les accès à une table.
• NO_PARALLEL (table_alias):  Permet de désactiver le parallélisme pour les accès à une table.
• PARALLEL_index (table_alias , idx,degré):  Permet de spécifier un niveau de parallélisme sur les Index Scan.
• NO_PARALLEL_index (table_alias):  Permet de désactiver le parallélisme sur les Index Scan.

Les hints Access Path

il existe différents types de hints Access Path :

• Full (table_alias). Permet de forcer un parcours complet d’une table au lieu d’utiliser un index.
• Index (table_alias Nom_index). Permet de forcer l’utilisation d’un index en particulier lors de l’accès à une table. Ce hint est le plus utilisé car il empêche l’optimiseur d’écarter, à tort, un index s’il y a des erreurs d’estimation des cardinalités:                                                                                 select /*+index(TAB IDX_COL1) */  * from MYTABLE TAB where id >500000;
• No_Index (table_alias Nom_index). Interdit l’utilisation d’un index particulier lors de l’accès à une table : select /*+no_index(TAB IDX_COL1) */  * from MYTABLE TAB where id >500000;
• Index_FFS (table_alias Nom_index). Permet de forcer un Fast Full Scan sur un index.
• No_Index_FFS (table_alias Nom_index). Interdit un Fast Full Scan sur un index.
• Index_SS (table_alias Nom_index). Permet de forcer un Skip Scan sur un index.
• No_Index_SS (table_alias Nom_index). Interdit un Skip Scan sur un index.
• Index_RS (table_alias Nom_index). Permet de forcer un Range Scan sur un index (n’apparaît pas dans la documentation officielle).
• INDEX_COMBINE(table_alias Nom_index1 Nom_index2 …). Force une combinaison de type bitmap de plusieurs index B*Tree.
• INDEX_JOIN (table_alias Nom_index1 Nom_index2 …). Force une combinaison par jointure de plusieurs index.

Migration vers Exadata

La migration de vos bases de données vers une machine Exadata :

Vous avez votre machine Exadata et vous avez terminé la phase de mise en place et de configuration. Vous devez maintenant passer à l’essentiel et migrer vos bases de données vers votre nouvelle machine. Cette action est l’aboutissement de toute un travail et une étape très attendu par votre entreprise. Alors comment faire?

Globalement il y a deux catégories de migration :

·         Migration logique

·         Migration Physique

Il y a certainement des facteurs liés à votre contexte qui font que l’une des deux catégories soit plus adapté : Par exemple le temps d’indisponibilité.

La migration logique consiste à extraire les données de la base de données d’origine et les charger dans la base cible. La migration physique elle consiste à faire une copie bloc par bloc.

Les caractéristique de la base à migrer influence sur la stratégie à adopter. En effet sur Exadata la méthode d’accès aux données à son importance :

Dans un contexte OLTP par exemple on va plutôt avoir des petite transaction et le besoin d’accéder à une quantité limité de blocs dans toutes les tables. En revanche dans une base de type Data Warehouse on accède a une grande quantité de données et la base est optimisé pour les full scan. Exadata utilise les caches flash au niveau des cellules de stockage pour améliorer les performances d’un environnement OLTP. Pour un environnement Data Warehouse il va plus utiliser Smart Scan technologie pour optimiser les full scan. Quelle différence entre les deux catégories de Migration :

Migration Logique :

La migration logique peu importe la technologie utilisée consiste à extraire des objets d’une bases de données source et les charger dans une base de données cible.  Plus fastidieuse que la migration physique elle donne beaucoup plus de possibilités d’opérer des changements. Voici une liste non exhaustive des avantages de la migration logique dans le contexte Exadata:

·         Changement de plateforme: Les données sont automatiquement adaptés à la taille de bloc de la base de données cible. La conversion de Big-endiane vers Little-endiane est automatique. La compression HCC (Exadata hybrid columnar compression) peut être configuré avant le chargement des données : sur la base cible on compresse une table avec HCC et on charge les données à partir de la table d’origine. Les  données seront ainsi compressées lors du chargement.

·         La taille des Extent :  Les tables, indexes et partitions cible peuvent être définies avec une taille d’extent optimisée pour le type de bases : plus grande pour les Data Warehouse et plus petite pour OLTP.

·         Filtre des objets à migrer : Les objets de la base d’origine qui ne sont plus utilisés peuvent être ignorés durant la migration.

·         Fusionner des bases de données : sur les serveurs ou nous avons un grand nombre de bases de données on peut dans la mesure du possible fusionner plusieurs bases dans une seule sur Exadata et optimiser ainsi l’utilisation de la SGA.

Pour la migration logique nous avons généralement deux techniques :

1.       Extraction/chargement: les outils utilisés sont Data pump, Import/Export et create table as (select …) ou Insert as (select…) via un @DBLINK.

2.       Réplication : faire une réplication de la base à migrer sur un serveur de base de données sur la machine Exadata. Quand on souhaite finaliser la migration on arrête la réplication on redirige les applications clients vers la base cible. Les outils utilisés sont: Oracle Dataguard (Logical standby), Oracle Goldengate.

A suivre…