Code de la résilience

Définir les procédures de nettoyage automatique

La définition des procédures de nettoyage automatisées vous aidera dans la résilience du code.

Lorsque vous développez votre code et exécutez vos tests, vous devez réinitialiser votre environnement à plusieurs reprises pendant la résolution de bogues, l'amélioration des performances et l'optimisation des stratégies de chargement. Créer des procédures de nettoyage en avance vous permettra d'améliorer ces procédures au fur et à mesure de l'évolution de votre code, et de là où elles devraient être suffisamment flexibles pour vous permettre de réinitialiser votre environnement sur l'état de votre choix :

Tout réinitialiser, aucune donnée du système cible
Réinitialisez l'environnement sur l'état dans lequel il se trouvait avant le dernier chargement (y compris les variables, le statut ou les tables d'audit, etc.)
Réinitialiser l'environnement afin que les données d'un chargement particulier (batch_id ou run_id) soient réinitialisées dans l'environnement sans affecter les autres données

En général, l'automatisation du processus de nettoyage rend le processus plus efficace (inutile de rechercher la liste des tables à réinitialiser ou des requêtes SQL à exécuter). L'automatisation permet également de réduire considérablement le risque qu'une personne réinitialise la mauvaise partie de l'environnement, en particulier lorsque le débogage frustrant et que les personnes se retirent.

Au fur et à mesure que ces procédures de nettoyage deviennent plus détaillées, elles peuvent être incluses dans les processus d'intégration. Vous pouvez bénéficier des avantages suivants :

Exécutez toujours un nettoyage préemptif avant de charger les données. Si vous chargez des données qui peuvent être facilement identifiées (avec un ID de batch ou une date spécifique), vous pouvez facilement remplacer les chargements précédents de cet ensemble de données ayant échoué
Utilisez ces procédures de nettoyage dans les workflows en cas d'erreur. Vous ne souhaitez pas abandonner l'intégralité de la charge car, pendant un court laps de temps, vous avez perdu la connexion à l'environnement source ou cible. Supposons que vous chargez des centaines de fichiers et que vous exécutez des transformations complexes sur ces fichiers. Avez-vous abandonné tout ce qui se passe parce que les données ont été fractionnées en raison d'un problème d'accès à un seul des fichiers ou voulez-vous effectuer tout, réessayer le fichier dès que possible et prendre des mesures plus graves seulement si ce fichier ne peut toujours pas être chargé ? En fonction de la stabilité de l'environnement sur lequel vous êtes en cours d'exécution, vous pouvez choisir de tester plusieurs fois avant d'alerter les personnes appropriées. De même, en fonction du type de coupure rencontré dans votre environnement, vous pouvez imposer une pause avant de réessayer.

Prenez en compte différents types de procédure de récupération. Pour les tâches simples, il est souvent suffisant pour réessayer l'opération qui a échoué sans autre nettoyage ou réinitialisation. Mais comme les évolutions de code et deviennent plus complexes, le type des erreurs que vous rencontrerez sera également modifié. Après avoir résolu les erreurs de chargement (le chargement ne fonctionne pas), vous pouvez exécuter les erreurs métier (les données sont chargées, mais vous chargez les données incorrectes ou certains calculs sont erronés). Vous devez enquêter sur la façon dont vous souhaitez traiter ces types de correction. Lors des premières étapes, il peut être valide pour tout réinitialiser lorsque des erreurs d'activité se produisent. Vous voudrez néanmoins augmenter de façon plus précise au fur et à mesure de l'évolution du code afin de disposer de davantage d'efficacité dans vos corrections.

Des boucles peuvent être définies dans Oracle Data Integrator pour inclure des procédures de nettoyage et des compteurs d'incréments qui effectuent le suivi du nombre de tentatives. Pour une traçabilité accrue des coupures, les meilleures pratiques incluent l'enregistrement des erreurs rencontrées, afin que des actions appropriées puissent être prises si des erreurs deviennent plus fréquentes : vous ne voulez pas construire la résilience jusqu'au coût de masquage des problèmes croissants. Vous pouvez utiliser l'approche décrite dans la section Extraire les erreurs à partir des étapes en échec.

Si vous savez qu'une étape particulière de vos processus est incapable de rencontrer des erreurs bien (par exemple, un système distant qui passe régulièrement hors ligne sans un temps défini pour la coupure), vous pouvez tirer parti de la capacité intégrée Oracle Data Integrator pour réessayer une étape dans vos packages. Le chapitre Automated Retries décrit la manière de paramétrer la fonction de nouvelles tentatives automatiques pour une étape.

Deux points à garder si vous utilisez cette approche :

Oracle Data Integrator ne vous avertira pas que le processus a échoué si sa valeur est définie pour réessayer. Si l'une des autres tentatives réussit, l'étape est journalisée comme réussie dans les journaux d'Oracle Data Integrator (vous pouvez toujours effectuer le suivi de ces tentatives dans vos propres tables d'audit).
Le nombre de tentatives et l'attente augmentent la durée d'exécution de cette étape. Gardez à l'esprit les performances de vos processus d'intégration.

Identifier le dérive de performances

Les performances se décrètent graduellement dans le temps. Il est important de surveiller les performances et de s'assurer que pour le même volume de données traité, vous obtenez toujours les performances d'origine.Plus de temps pour traiter davantage de données a de sens. Plus de temps pour traiter la même quantité de données peut être un avertissement.

Vous voudrez connaître l'origine des retards et les causes de ces retards. Ces informations peuvent être liées à l'augmentation de l'activité réseau qui réduit la bande passante disponible, les statistiques obsolètes de vos bases de données qui ont un impact négatif sur l'exécution de votre code SQL ou une utilisation des fichiers sur un serveur où vous n'êtes intéressé que par des éléments sélectionnés.

Dans Oracle Data Integrator, la meilleure pratique consiste à purger les journaux (et les rapports de scénario) aussi souvent que possible afin d'améliorer les performances. Il est donc très utile d'archiver les journaux ou de copier les informations afférentes aux performances afin que vous puissiez vérifier les performances dans le temps.

Lors de l'examen du déclin relatif aux performances, consultez les différentes étapes d'Oracle Data Integrator (ne pas arrêter avec les performances globales) : il s'agit du meilleur moyen de savoir à quel moment les retards sont effectués. Assurez-vous également que vous disposez d'un processus automatisé pour purger les journaux Oracle Data Integrator. Vous pouvez en fait créer un travail Oracle Data Integrator qui effectue ces purges, y compris les rapports de scénario. Pour plus de détails, reportez-vous à Purger les journaux avec OdiPurgeLog.

Comme Oracle Data Integrator propose uniquement de purger les rapports de scénario liés aux sessions présentes dans l'opérateur, la purge des rapports de scénario après la purge des sessions nécessite une assistance d'Oracle Support. Si vous avez oublié de purger les rapports de scénario avant de purger les sessions, contactez le support technique Oracle. Oracle peut vous guider tout au long de la procédure appropriée.

Pour une longue durée d'exécution, il est crucial de surveiller les performances en continu. La dégradation des performances est souvent un avertissement indiquant la dégradation de l'environnement. Oracle recommande notamment de contrôler les plans d'exécution à l'aide de SQL Plan Management (SPM). Les modifications du plan d'exécution en production peuvent entraîner des échecs et les chargements de table peuvent entraîner des risques de modification des plans d'exécution.

Purger les journaux avec OdiPurgeLog

Si vous regardez dans le tiroir Utilitaires de vos packages Oracle Data Integrator, vous verrez un outil appelé OdiPurgeLog. Vous pouvez l'utiliser dans un scénario conçu pour purger les journaux Oracle Data Integrator et programmer l'exécution régulière de ce scénario afin de vous assurer de conserver autant de journaux que possible.

Voici les meilleures pratiques :

Vous devez également purger les rapports. Ils sont plus difficiles à supprimer seuls d'eux que lors de la purge des journaux.
Vous pouvez définir un certain niveau de latence dans la purge : vous pouvez utiliser des variables pour stocker une heure antérieure ou une date antérieure avant laquelle tous les éléments doivent être purgés (vous utilisez cette option avec le paramètre End Date).
Vous pouvez choisir de purger les journaux de scénario (et les rapports) uniquement, ou de purger les journaux de scénario et de plan de chargement.

Extraire les erreurs à partir des étapes en échec

L'API getPrevStepLog() est généralement utilisée dans une procédure Oracle Data Integrator. Il est très pratique si une étape échoue et que vous souhaitez extraire les erreurs signalées au cours de cette étape avant de tenter d'effectuer des actions correctives.

Cette API est appelée avec un nom de propriété qui renverra les informations appropriées. Par exemple, pour obtenir le nom de la session, celui de l'étape ayant échoué et celui du message d'erreur associé, vous pouvez utiliser le code suivant pour extraire l'erreur liée à la procédure :

Session:
        <%=odiRef.getInfo("SESS_NAME")%> encountered the following
        error at step: <%=odiRef.getPrevStepLog("STEP_NAME")%>Error Message:
        <%odiRef.getPrevStepLog("MESSAGE")%>

Vous devez encapsuler cet extrait dans du code supplémentaire qui stocke ces informations dans un emplacement, ou envoyer ces informations pour un traitement approprié.

Utiliser les tentatives automatiques

Les tentatives automatiques permettent de gagner du temps car le processus complet peut se terminer par rapport à l'annulation en raison de liens hypertextes ou temporaires.

Dans votre package, sélectionnez l'étape à laquelle vous voulez autoriser les nouvelles tentatives. Dans la zone de propriétés, cliquez sur l'onglet Avancé. Dans la zone Traitement après un échec :

Définissez le nombre de tentatives d'exécution de cette étape
Définir le délai d'attente entre chaque nouvelle tentative

Utiliser des noms uniques ou dynamiques pour les sessions de scénario

Lorsque le même scénario est exécuté plusieurs fois pour charger différents ensembles de données, la vue Opérateur d'Oracle Data Integrator n'est pas très utile si elle présente une liste de nombreuses instances du même scénario, avec éventuellement une erreur occasionnelle.

L'une des méthodes élégantes de cette opération lors de l'appel du scénario consiste à tirer parti du paramètre Nom de session (SESS_NAME). Si le même scénario exécute plusieurs fois, vous avez probablement déjà un paramètre indiquant à ce scénario les données qu'il doit traiter (tranche de données, load_id, date, etc.). Vous pouvez utiliser cette variable pour construire un nom unique pour chaque exécution du scénario. Si vous définissez le nom de session dans l'appel du scénario, des sessions supplémentaires d'un package génèrent des journaux plus lisibles dans l'opérateur Oracle Data Integrator. Il est ainsi plus facile de comprendre le jeu de données problématique en cas de défaillance d'un jeu.

Utiliser les outils orientés événement

Oracle Data Integrator fournit un certain nombre d'outils que vous pouvez utiliser dans vos packages pour attendre la disponibilité de nouvelles données.

Tous ces outils permettent de définir le taux d'interrogation, ainsi que le délai d'expiration :

OdiFileWait attend que le fichier soit disponible dans un répertoire (n'oubliez pas que votre agent Oracle Data Integrator devra consulter ce répertoire !).
OdiWaitForData attend que de nouvelles données soient disponibles dans une table à partir d'une requête que vous fournissez.
OdiWaitForTable attend qu'une table soit créée dans votre base de données.

Configurer le délai d'expiration du cache de modèle de base de l'agent

Avec Oracle Data Integrator 12c, l'efficacité de l'agent a été améliorée par la mise en cache de la définition des scénarios exécutés. Vous pouvez contrôler la durée de mise en mémoire cache des scénarios dans la définition de l'agent physique dans la topologie Oracle Data Integrator.

La mise en mémoire cache du scénario dans l'agent est utile pour les travaux en temps réel ; l'agent n'a donc pas besoin d'obtenir les informations dans le référentiel pour chaque exécution. Cette relève est qu'un déploiement d'une nouvelle version d'un scénario n'est pas immédiatement repris. Le délai d'expiration par défaut jusqu'à ce qu'une nouvelle version d'un scénario mis en cache soit sélectionnée est de 600 secondes (10 minutes) et 100 entrées sont mises en cache par défaut.

Vous pouvez gérer ces valeurs. Dans la définition d'agent, dans l'onglet Définition, utilisez la section Gestion de cache de modèle de base de session pour définir le nombre maximal d'entrées de cache et la durée de vie du modèle de base inutilisé (s).