En utilisant une commande DOS : imp HELP=y permet d'afficher les paramètres de cette commande.
Exemple d'import complet (schéma/données/objets):
IMP user/pwd file =C..../file.dump full=y commit=y
L'utilisateur utilisé doit avoir les droits DBA et c'est dans le schéma de ce même utilisateur que seront importées les données.
mardi 16 novembre 2010
lundi 15 novembre 2010
Débuter avec ODI - Les topologies
1. Le concept "Topologie" dans ODI
La topologie dans ODI correspond à la description exhaustive du système d'information mis en place ou à mettre en place. Elle comprend la description des serveurs de données, des schémas de données , technologies utilisées, le paramétrage des agents qui sont chargées de l'exécution des intégrations, la description du contexte (mapping entre les schémas physiques de données et les schémas logiques de données)
Topologie : Architecture physique
L'élément primaire dans la description d'une architecture physique sous ODI est le serveur de donnée; le serveur de donnée désigne dans le contexte ODI une machine capable de stocker et de rendre accessible des données (exemple : Instance Oracle, Access, XML, FileDB...).
ODI se connecte à ses serveurs de données via des drivers JDBC en utilisant les informations physique du serveur de donnée : nom de la machine, port, base de donnée, etc.
Du serveur de donnée au schéma physique : dans ODI, à un serveur de donnée peuvent être associé plusieurs schémas de données. Toute banque de données est stockée dans un schéma de données dans un serveur de données. Lors de la création de notre serveur de données nous allons lui affecter un ou plusieurs schéma de données. Et à chacun des schémas de données, nous définirons le schéma de donnée dit de travail. C'est à dire l'espace de stockage des objets temporaires.
Pour conclure cette partie sur les architectures physiques, il nous faut aborder la question d'une architecture fragmentée et répondre à la question de la modélisation de cette dernière dans ODI.
La règle à appliquer dans ce cas est que l'architecture physique décrite dans ODI doit refléter l'architecture la plus fragmentée.
Exemple : Les données sources à intégrer dans un magasin de données sont disponibles dans deux sites différents.
Le site A a la base de données du domaine VENTE sur un serveur Microsoft avec le SGBD SQL Server, et la base de données du domaine CLIENT sur un serveur de donnée ORACLE.
Le site B a les deux bases de données VENTE et CLIENT dans le même serveur ORACLE.
--> Architecture physique = 1 serveur de données par instance Oracle, le site A a deux serveurs de données et le site B a un serveur de données.
Mais nous avons vu précédemment que l'architecture doit correspondre à la réalité la plus fragmenté (ici le site B) donc le site B aura 2 serveurs de données.
Nous aurons alors 4 serveurs de données, avec 4 schéma de donnée : A-MICROSOFT-VENTE/A-ORACLE-CLIENT/B-ORACLE-VENTE/B-ORACLE-ळीण्ट
Topologie : Cas pratique Architecture physique
Le module qui permet de mettre en place la topologie d'un projet et le module "Topology Manager". Lancer le module avec un utilisateur ODI qui a le profil TOPOLOGY, après avoir créé un référentiel de travail pour ce petit exercice.
Faites un clique droit sur la technologie sous laquelle se trouve le serveur de donnée puis choisissez l'option ajouter un serveur de données.
Donnez un nom explicite au serveur de données, par exemple: nom de la machine puis nom de l'instance puis SRC pour signifier que c'est une source de données ou TRG pour cible de données.
L'utilisateur doit avoir les droits Administrateur dans le SGBD.
La fenêtre qui suit sert à définir les informations du schéma de données physiques qui sont à déclarer avec ce serveur de données.
La topologie dans ODI correspond à la description exhaustive du système d'information mis en place ou à mettre en place. Elle comprend la description des serveurs de données, des schémas de données , technologies utilisées, le paramétrage des agents qui sont chargées de l'exécution des intégrations, la description du contexte (mapping entre les schémas physiques de données et les schémas logiques de données)
Topologie : Architecture physique
L'élément primaire dans la description d'une architecture physique sous ODI est le serveur de donnée; le serveur de donnée désigne dans le contexte ODI une machine capable de stocker et de rendre accessible des données (exemple : Instance Oracle, Access, XML, FileDB...).
ODI se connecte à ses serveurs de données via des drivers JDBC en utilisant les informations physique du serveur de donnée : nom de la machine, port, base de donnée, etc.
Du serveur de donnée au schéma physique : dans ODI, à un serveur de donnée peuvent être associé plusieurs schémas de données. Toute banque de données est stockée dans un schéma de données dans un serveur de données. Lors de la création de notre serveur de données nous allons lui affecter un ou plusieurs schéma de données. Et à chacun des schémas de données, nous définirons le schéma de donnée dit de travail. C'est à dire l'espace de stockage des objets temporaires.
Pour conclure cette partie sur les architectures physiques, il nous faut aborder la question d'une architecture fragmentée et répondre à la question de la modélisation de cette dernière dans ODI.
La règle à appliquer dans ce cas est que l'architecture physique décrite dans ODI doit refléter l'architecture la plus fragmentée.
Exemple : Les données sources à intégrer dans un magasin de données sont disponibles dans deux sites différents.
Le site A a la base de données du domaine VENTE sur un serveur Microsoft avec le SGBD SQL Server, et la base de données du domaine CLIENT sur un serveur de donnée ORACLE.
Le site B a les deux bases de données VENTE et CLIENT dans le même serveur ORACLE.
--> Architecture physique = 1 serveur de données par instance Oracle, le site A a deux serveurs de données et le site B a un serveur de données.
Mais nous avons vu précédemment que l'architecture doit correspondre à la réalité la plus fragmenté (ici le site B) donc le site B aura 2 serveurs de données.
Nous aurons alors 4 serveurs de données, avec 4 schéma de donnée : A-MICROSOFT-VENTE/A-ORACLE-CLIENT/B-ORACLE-VENTE/B-ORACLE-ळीण्ट
Topologie : Cas pratique Architecture physique
Le module qui permet de mettre en place la topologie d'un projet et le module "Topology Manager". Lancer le module avec un utilisateur ODI qui a le profil TOPOLOGY, après avoir créé un référentiel de travail pour ce petit exercice.
Faites un clique droit sur la technologie sous laquelle se trouve le serveur de donnée puis choisissez l'option ajouter un serveur de données.
Donnez un nom explicite au serveur de données, par exemple: nom de la machine puis nom de l'instance puis SRC pour signifier que c'est une source de données ou TRG pour cible de données.
L'utilisateur doit avoir les droits Administrateur dans le SGBD.
La fenêtre qui suit sert à définir les informations du schéma de données physiques qui sont à déclarer avec ce serveur de données.
vendredi 12 novembre 2010
Débuter avec ODI - Référentiels
ODI pour Oracle Data Integrator est un ELT. Utile et utilisé dans des packages de mise en place d'un système d'information décisionnel, c'est le composant indispensable pour rendre disponible les données du système transactionnel (également appelé de production).
1. Un "ELT" basé sur les méta données : les référentiels
Sont appelées méta données toutes les informations décrivant le système d'information décisionnel sur lequel est réalisé votre projet ODI.
Le SID (système d'information décisionnel) est décrit avec:
- La description du réseau physique du SID : nom des machines, ports, nom des instances utilisés, utilisateurs, mots de passe,etc. (côté source de données/côté cible de données)
- La description logique des données : schémas de données, contraintes, traitements...
- La description des objets ODI créés, configurés ou utilisés dans le cadre d'un projet.
Ces méta données et on peux le constater sont de nature différentes :
-Les données nécessaires à l'infrastructure du projet (schéma physique et gestion des utilisateurs) = "Référentiel Maître"
-Les données au projet lui-même ="Référentiel de travail"
Pour un seul référentiel maître, on peux avoir plusieurs référentiel de travail (exemple développement/production ou encore appartenant à des projets sur des domaines fonctionnels différent Production Comptabilité/Production CRM).
Ces référentiels sont accessibles en Web (application JAVA J2EE) permettant la lecture des données de ces référentiels par les développeurs/administrateurs/gestionnaires d'un projet ODI.
2. Création des référentiels
Après avoir installé ODI, vous avez accès au module "Repository Management"
Il est également possible de migrer ou d'importer un référentiel.Dans notre cas c'est la création d'un référentiel maître qui nous intéresse.
Le référentiel ODI a besoin de stocker ces informations dans une base de données qui lui est propre. Il est donc nécessaire d'installer un SGBD sur votre machine ou de disposer d'un accès à une instance de base de données qui serviras à accueillir les données qui seront générés par ODI.
J'ai créé un utilisateur odi_ref sous oracle qui a des droits d'administrateur. C'est ce schéma que j'affecterais lors de la configuration du référentiel.
Il nous faut préciser les informations physiques de la base de donnée afin qu'une connexion soit établie : le pilote (liste disponible, à choisir en fonction de la technologie du SGBD), l'URL (template par technologie disponible, à compléter par le nom de la machine et le nom de l'instance),le nom d'utilisateur et le mot de passe qu'ODI doit fournir au SGBD pour y avoir accès.
Un test de la connexion est préférable avant de lancer la création du référentiel maître.
Création durant laquelle, ODI créé l'ensemble des tables nécessaires pour le stockage des méta données du projet (topologie, versionning et gestion des profils)
On peux également voir dans le script de création du référentiel qu'ODI importe des fichiers qui nous le verrons plus tard en détail, nous servirons à définir la topologie de notre projet = l'architecture technologique de la solution BI.
Si vous vous connectez à la base de donnée avec l'utilisateur choisi pour le référentiel, vous devez avoir une vue sur les tables créées, les données insérées, etc.
Ce référentiel maître ne serviras pas tant qu'il ne seras pas utilisé par ODI et qu'il ne géreras pas d'utilisateur ODI. En effet, lorsque nous commencerons notre développement d'objet ODI, nous nous connecterons à l'aide d'un utilisateur ODI qui pointeras vers un référentiel maître particulier.
ODI installe par défaut un référentiel maître qui sert notamment pour la démo: OracleDILocalRepository.
Pour utiliser notre référentiel, nous ajouter à l'utilisateur par défaut d'ODI une connexion vers notre référentiel.
Le composant qui nous seras utile est le : Security Manager (un des 5 composants d'ODI).
Lors de ce paramétrage, il ne faut pas confondre les utilisateurs à utiliser :
-nom de login: alias de vers notre référentiel
- le login/mdp de l'utilisateur ODI avec lequel on se connecte : nous n'avons pas encore créé d'utilisateur, nous utiliserons SUPERVISOR/SUNOPSIS (utilisateur par défaut)
-le login/mdp/informations physiques du référentiel maître précédemment créé dans lequel nous souhaitons inscrire notre nouvel utilisateur ODI.
A la fin de cette étape, nous avons créé le référentiel maître, puis nous avons fait pointer l'utilisateur DBA par défaut d'ODI sur notre référentiel.
A présent, nous nous connecterons avec ces informations à ODI pour créer un nouvel utilisateur.
Cet utilisateur ne dispose pas encore de droit dans le référentiel auquel nous l'avons ajouté.
Voici la correspondance entre les rôles dans un projet et les droits à affecter dans ODI:
Business User : CONNECT, NG REPOSITORY EXPLORER
Business Analyst : CONNECT, NG REPOSITORY EXPLORER, NG DESIGNER
Developer : CONNECT, DESIGNER
Metadata Administrator : CONNECT, METDATA ADMIN, VERSION ADMIN
Database Administrator : CONNECT, DESIGNER, METADATA ADMIN, TOPOLOGY ADMIN
System Administrator : CONNECT, OPERATOR
Security Administrator : CONNECT, SECURITY ADMIN
Operator :CONNECT, OPERATOR
Pour affecter les droit à l'utilisateur, affichez les deux fenêtres (Utilisateurs et profils) côte à côte et faites des glissez-déposez des droits que vous souhaitez lui affecter.
Notre utilisateur USER-ODI est à présent enregistré dans ce référentiel, il a le doit de ce connecter et d'accéder au module designer d'ODI (module de développement).
mercredi 10 novembre 2010
ODI CKECK
FLOW CONTROL
si cette option est activée, le CKM est appliqué avant le chargement dans target empêchant ainsi le chargement d'enregistrement erronés.
que ce passe dans ce flux et ceci, aprés le chargement, une table de vérification est crée (SNP_CHECK_TAB) en supprimant la table de vérification précédente et les erreurs précédentes comme le fait ODI en général.
maintenant il crée une nouvelle table d'erreur, et vérifie la contrainte de la clef primaire, les autres contraintes et conditions definis dans la base des données ou dans le model ODI.
si l'enregistrement ne respect pas la contrainte ou la condition, il est ajouter dans la table E$ et une entrée le concernat est ajouté dans la table SNP_CHECK_TAB avec des informations sur la schéma, le message d'erreur et le nombre, ect ...
Finalement les autres enregistrement sont enregistrée selon le KM et la logique
E$ table
Dans la table E$, l'ensemble des colones de la table source et le colonne erreur contenant le nom d'erreur sont associé avec un ROW_ID.
SNP_CHECK_TABLE
STATIC CONTROL
si cette option est activée, le CKM est appliqué aprés le chargement dans target.
Il y a une contrainte de PK sur la table, donc l'insertion echoue.
Regardant un exemple ou la table source n'as pas de contrainte et que la contrainte est appliqué dans niveau d'ODI.
la clef est appliqué au champs Employee_ID au niveau d'ODI.
Après l'insertion dans la table target, il utilise le CKM sélectionné et procède à la vérification de toutes les contraintes et conditions et finalement charge les enregistrements rejetés dans E$ et SNP_CHECK_TAB.
si cette option est activée, le CKM est appliqué avant le chargement dans target empêchant ainsi le chargement d'enregistrement erronés.
que ce passe dans ce flux et ceci, aprés le chargement, une table de vérification est crée (SNP_CHECK_TAB) en supprimant la table de vérification précédente et les erreurs précédentes comme le fait ODI en général.
maintenant il crée une nouvelle table d'erreur, et vérifie la contrainte de la clef primaire, les autres contraintes et conditions definis dans la base des données ou dans le model ODI.
si l'enregistrement ne respect pas la contrainte ou la condition, il est ajouter dans la table E$ et une entrée le concernat est ajouté dans la table SNP_CHECK_TAB avec des informations sur la schéma, le message d'erreur et le nombre, ect ...
Finalement les autres enregistrement sont enregistrée selon le KM et la logique
E$ table
Dans la table E$, l'ensemble des colones de la table source et le colonne erreur contenant le nom d'erreur sont associé avec un ROW_ID.
SNP_CHECK_TABLE
STATIC CONTROL
si cette option est activée, le CKM est appliqué aprés le chargement dans target.
Il y a une contrainte de PK sur la table, donc l'insertion echoue.
Regardant un exemple ou la table source n'as pas de contrainte et que la contrainte est appliqué dans niveau d'ODI.
Après l'insertion dans la table target, il utilise le CKM sélectionné et procède à la vérification de toutes les contraintes et conditions et finalement charge les enregistrements rejetés dans E$ et SNP_CHECK_TAB.
Gestion des erreurs ODI par envoi de mail.
Salut,
Voici un petit script qui permet de récuperer les details des erreurs des interfaces comme des erreurs de contraintes PK, FK, NOT NULL ect ...
Ce script permet de créer un fichier et de retourner les informations par la lecture de la table SNP_CHECK_TAB, nous pourrons par la suite l'attacher à OdiSendMail et l'envoyer à l'administrateur ou les développeurs afin qu'ils sachent qu'elle interface à obtenue des enregistrement d'erreurs.
NOTE : dans le script ci dessus, changer le chemin du fichier et du schéma (schéma de travail) en fonction de votre environnement.
Paramétrez la technologie et le schéma de travail ou le chemin nécessaire pour accéder à la table SNP_CHECK_TAB et mettez le code de la commande sur la cible.
Et pour chaque exécution vous obtiendrai le résultat ci-dessus :
joigniez ce fichier à OdiSendMail er vous obtiendrai un rapport quotidiens des erruers des interfaces.
A bientôt ...
Voici un petit script qui permet de récuperer les details des erreurs des interfaces comme des erreurs de contraintes PK, FK, NOT NULL ect ...
Ce script permet de créer un fichier et de retourner les informations par la lecture de la table SNP_CHECK_TAB, nous pourrons par la suite l'attacher à OdiSendMail et l'envoyer à l'administrateur ou les développeurs afin qu'ils sachent qu'elle interface à obtenue des enregistrement d'erreurs.
NOTE : dans le script ci dessus, changer le chemin du fichier et du schéma (schéma de travail) en fonction de votre environnement.
Paramétrez la technologie et le schéma de travail ou le chemin nécessaire pour accéder à la table SNP_CHECK_TAB et mettez le code de la commande sur la cible.
joigniez ce fichier à OdiSendMail er vous obtiendrai un rapport quotidiens des erruers des interfaces.
A bientôt ...
mardi 9 novembre 2010
Installation ODI 10.3 sur un WIN7
Cette version d'ODI (580Mb) est disponible sur le site d'Oracle, ici. (Un compte Oracle est nécessaire pour accéder au téléchargement).
ODI est non-conforme au système d'exploitation windows 7. Par défaut au lancement du programme d'installation d'ODI, une analyse du SE hôte est exécutée. C'est cette étape dont il faut empêcher
l'exécution afin de contourner cette limitation.
Une fois le dossier décompressé, il doit contenir les éléments suivant :
Dans le dossier setup se trouvent les fichiers d'installation. Nous allons exécuter ce fichier via une ligne de commande. Pour cela, lancer l'invite de commande windows et positionnez vous dans le dossier suivant :
CD_10.1.3.5.0_WINDOWS\setup\Windows\Disk1\install
puis exécutez la commande suivante:
setup -ignoresysprereqs
Choisissez l'outil Oracle Data Integrator dans la liste des produits disponible pour une installation.
Spécifier ensuite le dossier et nous sous lesquels vous souhaitez enregistrer votre installation.
L'extraction des fichiers et leurs copies sur votre machine prend quelques minutes.
L'installation est à présent terminée.
il est préférable d'installer jdk1.6 et de faire pointer ODI sur cet environnement, pour faire :
- Télécharger jdk1.6 et installez le.
- Changer ODI_JAVA_HOME, poste de travail > propriété > paramètres avancés > variables d'environnement.
- Clicker sur ODI_JAVA_HOME et changez le dossier pour mettre le dossier du nouveau jre fraîchement installer.
- Copiez le driver ojdbc6.jar dans $ODI_HOME/oracledi/drivers/
il est préférable d'installer jdk1.6 et de faire pointer ODI sur cet environnement, pour faire :
- Télécharger jdk1.6 et installez le.
- Changer ODI_JAVA_HOME, poste de travail > propriété > paramètres avancés > variables d'environnement.
- Clicker sur ODI_JAVA_HOME et changez le dossier pour mettre le dossier du nouveau jre fraîchement installer.
- Copiez le driver ojdbc6.jar dans $ODI_HOME/oracledi/drivers/
Oracle Database 10 g Installation détaillée
Procédure d'installation:
Une fois le téléchargement terminé, lancer l'exécutable ( à renommer en .exe si le fichier est chargé sans extension).
La procédure consiste à confirmer l'installation dans la suite des écrans ci-dessous :
Choisissez la partition de votre disque qui va accueillir l'installation ; sous réserve qu'elle dispose d'espace suffisant pour l'installation.
Configuration du mot de passe du Super Utilisateur SYSTEM d'Oracle.
Suite Installation (~2 min)
Accès en localhost à la base de donnée
Interface client léger de gestion de la base de donnée ORACLE.
L'installation est à présent terminé, Enjoy!
Une fois le téléchargement terminé, lancer l'exécutable ( à renommer en .exe si le fichier est chargé sans extension).
La procédure consiste à confirmer l'installation dans la suite des écrans ci-dessous :
Choisissez la partition de votre disque qui va accueillir l'installation ; sous réserve qu'elle dispose d'espace suffisant pour l'installation.
Configuration du mot de passe du Super Utilisateur SYSTEM d'Oracle.
Suite Installation (~2 min)
Accès en localhost à la base de donnée
Interface client léger de gestion de la base de donnée ORACLE.
L'installation est à présent terminé, Enjoy!
Inscription à :
Commentaires (Atom)