Vote utilisateur: 4 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles inactives
Il est très fréquents dans les entrepôt de données de vouloir récupérer seulement les données modifiées depuis le dernier traitement de chargement ETL.
Comme alternative à l'utilisation d'une colonne de dernière mise à jour dans certaines tables sources, si l'application opérationnel ne met pas à jour systématiquement cette colonne, cela signifie que l'extraction ETL va manquer certaines modifications.
Pour pallier ce manque coté application opérationnelle il est possible d'utiliser le ora_rowscn :
Petite explication de ce qu'est le ora_rowscn :
ora_rowscn est une pseudo-colonne comme la pseudo-colonne rowid.
Cette colonne peut-être interrogé via sql
exemple :

 

requête récupérant les 5 dernières lignes modifiées dans une table
SELECT
ROWIDTOCHAR(ROWID) row_id, ora_rowscn, num_0
FROM soh_dev.sx3_pinvoice
WHERE ROWNUM < 6
ORDER BY ora_rowscn DESC;

renvoi

ROW_ID             ORA_ROWSCN NUM_0
AAAR6nAAJAAAAQUAAF 18553598   OFAF07030000578
AAAR6nAAJAAAAQVAAJ 18553598   OFAF07030000914
AAAR6nAAJAAAAQVAAI 18553598   OFAF07030000913
AAAR6nAAJAAAAQVAAH 18553598   OFAF07030000767
AAAR6nAAJAAAAQVAAG 18553598   OFAF07030000765

Le SGDB estampille chaque ligne avec un ora_rowscn à chaque modification de la ligne. La précision est d'environ 3 secondes entre 2 SCNs consécutifs.


En utilisant cette colonne pour n'extraire que les lignes en sources avec un ora_rowscn supérieur ou égal au dernier ora_rowscn utilisé dans le dernier traitement d'extraction pour une table il serait donc possible de récupérer uniquement les lignes ayant subit une modification depuis le dernier traitement.

Cela impliquerait de mettre en place une nouvelle table de paramètres pour conserver le dernier ora_rowscn de chaque table traitée.

Le mécanisme d'extraction sera légèrement plus complexe qu'avec une date de dernier traitement commune à toutes les tables car il faudra :

Commentaire (0) Clics: 6392

Vote utilisateur: 5 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles actives

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

 

Commentaire (0) Clics: 2970

Vote utilisateur: 5 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles actives

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 :

    Commentaire (0) Clics: 9835

Vote utilisateur: 3 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles inactivesEtoiles inactives

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 :

Creation d'un index invisible
CREATE INDEX IX1 ON TABLE T1(cola,colb) INVISIBLE;

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

Modification d'un index pour le rendre invisible/visible
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.

Modification de OPTIMIZER_USE_INVISIBLE_INDEXES
ALTER SESSION SET OPTIMIZER_USE_INVISIBLE_INDEXES=TRUE;

 

Commentaire (0) Clics: 4825

Sous-catégories

Des tutoriaux et cours gratuits sur Oracle

Articles traitant de l'intégration de données

Tutoriaux sur Unix et les shells scripts