La nouvelle base de données de SAP, HANA, nouveau cheval de bataille de l'éditeur allemand est disponible en version Cloud pour quelques partenaires et clients testeurs. Cette base de données approche le stockage avec une technologie "In-Memory" pour une atteindre une performance d'accès aux données améliorée. Certifiée pour certaines machines avec une configuration OS et Hardware optimisée, cette base de données prend donc logiquement l'appelation convoitée "d'Appliance" : à savoir un ensemble Hard+Soft combiné et paramétré pour des performances optimales.

SAP annonce le stockage de données BIG DATA sur cette base et des temps de réponses encore jamais vu. Pour en avoir le coeur net et pour pimenter l'essai j'ai intégré des données du réseau social professionnel LinkedIn dans cette base de données via un connecteur spécialisé pour Informatica PowerCenter, transformant ainsi le test HANA en un test multiple de connectivités.

Le socle ETL est une VM sous Windows 2008 R2 avec Informatica PowerCenter 9.1 64 bits SE.
Cotésconnecteurs :
- Les drivers ODBC 32 et 64 bits pour SAP HANA
- Le connecteur Informatica PowerExchange pour LinkedIn 9.1

Définition :

Les partitions permettent de découper les objets de base en petites parties plus faciles à manipuler.

• Très répandue dans les datawarehouses. Spécialement lorsque le volume de données augmente.

• C’est une approche de type « diviser pour mieux régner ». Les objets de base de données de type table, index et vue matérialisée peuvent être divisés en morceaux plus petits et plus gérables : les partitions.

• Rend possible des opérations de maintenance des données au niveau des partitions. Les opérations comme:
  • Le chargement de données,
  • La construction des index,
  • La mise à jour des statistiques de l’optimizer Oracle,
  • La purge des données (Truncate Partition),
  • La sauvegarde et la restauration
  • Peut améliorer la performance des requêtes lancées sur la table. L’optimizer Oracle est capable de déterminer si certaines requêtes peuvent obtenir une réponse en parcourant uniquement une ou quelques partitions. De cette manière un parcours complet et couteux de la table (full table scan) peut être évité. Cette caractéristique est appelée Partition Elimination ou Dynamic Partition Pruning.

  Dans des requêtes de type datawarehouse, le partitionnement de table à plusieurs grands avantages :

Avec la version 11g, il est possible de définir la caractéristique INVISIBLE pour un index. Cela signifie que l'index est physiquement présent, qu'il est tenu à jour si des opérations DML ont lieu sur la table mais que l'optimiseur ne prend pas en compte cet index du moment ou le paramètre OPTIMIZER_USE_INVISIBLE_INDEXES=FALSE (valeur par defaut).

Il est possible de créer un index invisible :

CREATE INDEX IX1 ON TABLE T1(cola,colb) INVISIBLE; 

Il est également possible de rendre un index invisible par alter:

ALTER INDEX IX1 VISIBLE;
 
ALTER INDEX IX1 INVISIBLE; 

Afin de tester la pertinance d'un index, il suffit pour le DBA de modifier le paramètre de session OPTIMIZER_USE_INVISIBLE_INDEXES à TRUE et de vérifier si le plan d'éxécution utilise bien l'index invisible. Si le plan est satisfaisant et que l'index est bien utilisé, le DBA peut alors rendre l'index VISIBLE.

ALTER SESSION SET OPTIMIZER_USE_INVISIBLE_INDEXES=TRUE;