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 :

  • au début de l'extraction récupérer le plus grand ora_rowscn de la table source et placer ce résultat dans une colonne temporaire de la table paramètre (au cas ou il y ai des modifications en source pendant le traitement d'extraction)
  • le prédicat de restriction devra être poussé sur la source de données par l'ETL (le filtrage ne devra pas être réalisé sur l'ETL: donc pas de cache). Cela implique l'utilisation de variable définie dynamiquement sur l'ETL et qui récupéreront la valeur du dernier ora_rowscn de la table traité par le dataflow.
  • à la fin du traitement si tout c'est bien passer pour la table il faudra mettre le dernier ora_rowscn récupéré en étape 1 comme étant la nouvelle valeur "officielle" de dernier ora_rowscn pour la table traitée.

Nota : la colonne ora_rowscn n'est pas indexable, donc les tables sources seront scannées en full sur la base source, mais les données qui vont transiter sur le réseau et surtout le nombre de lignes traitées par l'ETL seront bien en delta donc avec un volume faible.
Cela réduit donc cette technique a des bases relativement petites en source et on préférera une technique de CDC (Change Data Capture) via journaux pour des volumes plus importants.

 

Nota2 : la mise à jour du scn est activé par défaut au niveau du block. Pour avoir un niveau de mise à jour du ora_rowscn au niveau de la ligne il faut reconstruire la table (ou le snapshot) avec ROWDEPENDENCIES activé.
C'est possible via le package dbms_redefinition.