Il est possible de configurer le comportement et la planification de chaque composant de service de transfert de données
afin de répondre aux différents besoins d'un environnement de développement, de test et de production. Modifier la configuration d'un composant peut avoir un impact direct sur le comportement des autres composants qui en dépendent.
Ces dépendances sont généralement de deux types :
- Le
composant Capture appelle régulièrement le composant Source Life Cycle.
Si le composant Capture n'est pas en cours
d'exécution, aucun composant Source Life Cycle n'est mis en oeuvre. Il est possible de configurer le délai entre les appels du composant Life Cycle.
Dans
la figure ci-dessus, le composant Source Life Cycle est appelé toutes les 3 unités de temps, exécute certaines activités,
puis rend le contrôle au composant Capture qui poursuit le traitement.
- Le
composant ETL et le composant Target Life Cycle sont appelés par le composant Apply, une fois que les données ont été
transférées de la base de données source vers la base de données cible. Les composants ETL et Target Life Cycle sont
uniquement appelés si le composant Apply est lancé.
Etant donné que les composants dépendants doivent fonctionner suivant un planning différent
du composant dont ils dépendent, un appel ne se traduit pas nécessairement par une exécution. Chaque composant dépendant
vérifie ainsi son planning lors de l'appel, et rend le contrôle au composant appelant s'il n'est pas encore temps
d'exécuter les tâches. Dans l'exemple ci-dessus, les composants ETL et Target Life Cycle ne peuvent être exécutés que
deux fois si le planning des deux composants les empêche d'être appelés plus d'une fois toutes les
5 unités de temps.

Le
composant ETL (et le composant Target Life Cycle) est appelé et exécuté à T2 (et T3 respectivement). L'appel suivant a lieu à environ T6. Etant donné que moins de 5 unités de temps se sont écoulées depuis la dernière exécution,
le contrôle est immédiatement rendu au composant Apply. Les appels suivants à environ T8 (et T9 respectivement)
se traduisent par une exécution car plus de 5 unités de temps se sont écoulées. Chaque composant est mis en oeuvre par une ou plusieurs instances de composant. Vous pouvez configurer chacune de ces instances séparément afin de permettre un
contrôle plus granulaire.
Remarque : Si des modifications sont apportées, elles prennent
effet immédiatement, sauf indication contraire.
Vous pouvez modifier la configuration par défaut des composants Capture et Apply en modifiant les tables
de contrôle appropriées ou en les remplaçant à l'aide de paramètres de ligne de commande dans les scripts
de démarrage. Vous pouvez configurer les composants de mise en oeuvre ETL et Life Cycle en mettant à jour l'une des
tables de contrôle.
Vous devez suivre la procédure suivante pour personnaliser
les composants du service de transfert de données de sorte qu'ils répondent aux impératifs des environnements de
développement, de test et de production.
Configuration des instances de composant Capture (source)
Une instance de composant Capture est équivalente à un utilitaire de réplication
DB2
Capture. Par défaut, cet utilitaire est configuré pour capturer de façon continue les modifications des tables source
et enregistrer ces modifications dans des tables de travail internes. En général, il n'est pas nécessaire de modifier
la configuration par défaut des instances de composant Capture.
- Identification des instances de composant Capture.
Plusieurs instances de composant Capture (en d'autres termes des
utilitaires DB2
Capture) sont utilisées pour capturer des données associées à un
modèle de mesure métier. Pour déterminer les utilitaires Capture affectés en vue de fournir des services à un
modèle de mesure métier,
vous devez :
- Identifiez le service de transfert de données pour lequel vous voulez modifier la configuration de l'utilitaire Capture.
- Vérifiez la table de métadonnées WBIRMADM.RMMETADATA dans la base de données d'état (pour le service de transfert
de données de la base de données d'état vers la base de données d'exécution) ou dans la base de données d'exécution
(pour le service de transfert de données de la base de données d'exécution vers la base de données d'historique) et
identifiez tous les noms d'utilitaire Capture (colonne SRC_RM_CAP_SVR_NAME).
Exemple : la requête "SELECT OM_NAME, SRC_TAB_NAME, SERVICE_NAME,
SRC_RM_CAP_SVR_NAME FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime' " peut générer le résultat
suivant :
Dans l'exemple ci-dessus, l'utilitaire Capture CAPTURE_1 est
affecté à la capture de toutes les modifications apportées aux deux tables source associées au modèle de mesure métier
STEW_S dans la base de données d'état.
- Modification de l'intervalle d'élagage de la table de travail Capture.
Les utilitaires Capture élaguent automatiquement les tables de travail toutes les 300 secondes (valeur par défaut du
paramètre prune_interval) si l'élagage auto est activé (paramètre autoprune égal à "y"). Chaque
activité d'élagage se traduit automatiquement par l'appel d'une instance de composant Source Life Cycle, laquelle est
mise en oeuvre par un déclencheur de base de données. Le fait de modifier le paramètre d'intervalle d'élagage pour un
utilitaire Capture a un impact direct sur la fréquence d'élagage des tables source par le composant
Source Life Cycle. Les figures ci-après illustrent la manière dont l'intervalle d'élagage pour l'utilitaire Capture peut
affecter l'appel de l'instance de composant Source Life Cycle.
Le fait d'accroître le paramètre prune_interval de l'instance Capture
de 2 unités de temps (300 secondes, par exemple) à 3 unités de temps (450 secondes, par exemple)
a pour effet :
- De faire en sorte que les lignes des
tables de travail Capture, qui peuvent être supprimées, soient toujours plus longues dans la table de
travail, et donc d'accroître les besoins en termes d'espace.
La taille des tables de travail augmente mais la charge système et le risque de contingence peut être moindre.
- De faire en sorte que les lignes des tables source, qui peuvent être
supprimées en fonction des stratégies de conservation Life Cycle, soient toujours plus longues que prévu dans la
table source.
De manière générale, si la valeur du paramètre prune_interval du composant
Capture est supérieure à celle du paramètre prune_interval du composant Life Cycle, priorité est donnée
au paramètre Capture. Si aucun utilitaire Capture n'est lancé ou si la fonction d'élagage automatique est désactivée, la mise en oeuvre du composant Source Life n'est pas effectuée.
Configuration du composant Source Life Cycle
Plusieurs instances de composant Life Cycle sont utilisées dans chaque base de données source (base de données d'état
et base de données d'exécution). Chaque instance, implémentée par un déclencheur,
met en oeuvre les stratégies de conservation comme défini dans la table de contrôle WBIRMADM.RMPRUNECTRL
située dans la base de données source pour ce service de transfert de données. Les stratégies de conservation Life Cycle
sont spécifiées en fonction d'une table. Ainsi, une ligne de WBIRMADM.RMPRUNECTRL
correspond à une table nécessitant un élagage.
- Identification des instances de composant
Source Life Cycle.
Pour déterminer les déclencheurs affectés à la mise en
oeuvre des stratégies de conservation pour un
modèle de mesure métier donné,
vous devez :
- Identifier le service de transfert de données pour lequel vous voulez modifier la configuration ETL.
- Vérifier la table WBIRMADM.RMMETADATA dans la base de
données d'état (pour le service de transfert de données de la base de données d'état vers la base de données d'exécution)
ou dans la base de données d'exécution (pour le service de transfert de données de la base de données d'exécution vers la
base de données d'historique) et rechercher les noms de déclencheur associés dans la colonne SRC_RM_PRUNE_TRG_NAME.
Exemple : la requête "SELECT OM_NAME,
SRC_TAB_NAME, SERVICE_NAME, SRC_RM_PRUNE_TRG_NAME FROM WBIRMADM.RMMETADATA
WHERE SERVICE_NAME='State to Runtime'" peut générer le résultat suivant :
Dans cet exemple, deux déclencheurs (WBIRMADM.MCPruneTrig_8
et WBIRMADM.MCPruneTrig_9) mettent en oeuvre la stratégie de conservation Life Cycle pour les tables source STEW_S du
modèle de mesure métier dans la
base de données d'état. Dans la mesure où les stratégies de conservation sont définies par des noms d'instance de
table et non par des noms d'instance de composant Life Cycle, vous devez conserver le suivi de la colonne SRC_TAB_NAME
lors de la planification de modification du comportement de la mise en oeuvre du composant Life Cycle.
- Modification des configurations
d'instance de composant Source Life Cycle.
- Activation et désactivation d'instances de composant Life Cycle :
L'élagage peut grandement
affecter les performances de votre système. Lorsque la fonction d'élagage est activée, elle permet de réduire la
quantité d'informations que doivent traiter les serveurs de information (état) et de génération de rapports
(exécution). Elle permet également d'ajouter une faible charge supplémentaire sur ces mêmes tables lors de chaque appel
en fonction des paramètres du composant Life Cycle. Lorsque la fonction d'élagage est désactivée, la taille des tables
source augmente au fil du temps, ce qui peut entraîner une dégradation des performances.
Par défaut, les tables source sont automatiquement élaguées en fonction de la stratégie de conservation de leur composant Life Cycle. Pour désactiver de
manière temporaire la fonction d'élagage, modifiez les entrées WBIRMADM.RMPRUNECTRL correspondantes :
attribuez la valeur 1 à la colonne PRUNE_ENABLED pour activer la fonction d'élagage,
et toute autre valeur numérique (zéro de préférence) pour la désactiver.
Des
lignes seront supprimées de la table source wbi.CTX_TQ4MUFT42JOT5F6R3KSDQDE2UI, mais aucune ne ne le sera de la
table wbi.AI_BVSOYAP1DRWFD5HNQJR5HFQQQE si la configuration ci-après est utilisée. La requête
"SELECT TABLE_NAME, PRUNE_ENABLED FROM WBIRMADM.RMPRUNECTRL" peut générer les résultats suivants :
- Modification de la stratégie de conservation :
Il est possible de modifier les stratégies de
conservation pour les tables source dans la base de données d'exécution uniquement. Pour toutes les tables de la base
de donnés d'état, la durée de conservation mise en oeuvre est égale à 0, quels que soient les paramètres de
WBIRMADM.RMPRUNECTRL. Une durée de conservation se définit comme la durée minimum pendant laquelle une ligne peut
demeurer dans une table source avant de pouvoir être supprimée, si elle répond à deux critères. De ces deux critères,
un seul peut être personnalisé via la table de contrôle : il s'agit de la durée de conservation (exprimée en minutes). Les
lignes marquées comme prêtes pour suppression et présentes dans la table source depuis au moins RETENTION_IN_MINUTES
remplissent les conditions pour être supprimées.
Suivant la configuration
par défaut des tables source dans la base de données d'exécution, les lignes qui sont marquées comme prêtes pour
suppression par le serveur doivent être conservées pendant un jour (1440 minutes) avant de pouvoir
être supprimées. La requête "SELECT TABLE_NAME, RETENTION_IN_MINUTES FROM WBIRMADM.RMPRUNECTRL"
peuvent générer les résultats suivants :
Les modifications apportées aux entrées de la table de
contrôle WBIRMADM.RMPRUNECTRL sont prises en compte à chaque appel du composant Source Life Cycle.
- Planification d'élagage des données source :
Il existe une dépendance entre l'intervalle
d'élagage de la table de travail Capture et l'appel du composant Source Life Cycle.
Un appel ne se traduit pas par une
exécution si la durée écoulée n'est pas suffisante entre les appels d'instance de composant Source Life Cycle,
comme l'illustre la figure ci-dessous.
En supposant que le composant Source Life Cycle soit planifié pour s'exécuter toutes les 4 unités de temps et que
l'élagage des tables de travail du composant Capture soit prévu toutes les 2 unités de temps, l'appel au temps T4 ne se traduira pas par une exécution.
Pour modifier la planification par défaut,
recherchez les entrées appropriées dans WBIRMADM.RMPRUNECTRL et remplacez la valeur de la colonne PRUNE_INTERVAL,
laquelle représente le délai minimum, en minutes, entre les exécutions.
Une augmentation de cette valeur se traduit par des exécutions
moins fréquentes (mais le nombre d'appels reste le même). Chaque exécution détermine les lignes de table source qui sont éligibles pour suppression et les supprime.
Contrôlez régulièrement vos bases de données source afin d'identifier et d'éliminer les éventuels incidents de
performance dus à des verrouillages, suite à ces suppressions.
Configuration du composant APPLY (cible)
Une instance de composant Apply est un utilitaire de réplication
DB2
Apply. Les modifications capturées par les utilitaires Capture sont appliquées en continu aux tables de
transfert dans la base de données cible par défaut. Les paramètres de configuration par défaut de l'utilitaire doivent
être suffisants pour la plupart des environnements et ne doivent pas être modifiés.
- Identification des instances de composant Apply.
Plusieurs instances de composant Apply
(utilitaires DB2 Apply)
sont utilisées pour l'application des modifications de données aux tables de transfert internes associées à un
modèle de mesure métier. Pour
déterminer les utilitaires Apply affectés en vue de fournir des services à un
modèle de mesure métier,
procédez comme suit :
- Identifiez le service de transfert de données pour lequel vous voulez modifier la configuration de l'utilitaire Apply.
- Vérifiez la table de métadonnées WBIRMADM.RMMETADATA dans la base de données d'exécution (pour le service de transfert de
données de la base de données d'état vers la base de données d'exécution) ou dans la base de données d'historique
(pour le service de transfert de données de la base de données d'exécution vers la base de données d'historique)
et identifiez tous les noms d'utilitaire Apply (colonne TGT_RM_APP_SVR_NAME). La requête "SELECT OM_NAME,
SRC_TAB_NAME, SERVICE_NAME, TGT_RM_APP_SVR_NAME FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime'"
peut générer les résultats suivants :
Dans cet exemple, toutes les modifications de données du
modèle de mesure métier STEW_S capturées dans la base de données d'état sont appliquées aux tables de transfert de la base de données d'exécution
par l'utilitaire Apply APPLY_4.
A l'issu de chaque traitement par le composant Apply de
toutes les modifications (validées) enregistrées par l'utilitaire Capture, une ou plusieurs instances de composant ETL et
Target Life Cycle sont appelées.
Configuration du composant ETL
Les composants ETL sont mis en oeuvre dans WebSphere
Business Monitor en tant que procédures mémorisées de base de données. Ces procédures mémorisées résident toujours dans la base de données cible pour un service de transfert de données spécifique. Par conséquent, toutes les procédures mémorisées ETL affectées au
service de transfert de données de la base de données d'état vers la base de données d'exécution figurent dans la
base de données d'exécution, et celles affectées au service de transfert de données de la base de données d'exécution
vers la base de données d'historique résident dans la base de données d'historique.
- Identification des instances de composant ETL.
Plusieurs instances de composant ETL sont définies pour traiter les
données ajoutées aux tables de transfert internes associées à un
modèle de mesure métier.
Afin de déterminer les procédures mémorisées qui sont affectées en vue de fournir des services à un
modèle de mesure métier, procédez comme suit :
- Identifiez le service de transfert de données pour lequel vous voulez modifier la configuration ETL.
- Vérifiez la
table de métadonnées WBIRMADM.RMMETADATA dans la base de données d'exécution (pour le service de transfert de données
de la base de données d'état vers la base de données d'exécution) ou dans la base de données d'historique (pour le
service de transfert de données de la base de données d'exécution vers la base de données d'historique)
et identifiez tous les noms de procédure mémorisée ETL (colonne TGT_RM_SPETL_NAME). La requête
"SELECT OM_NAME, SRC_TAB_NAME, TGT_TAB_NAME, SERVICE_NAME, TGT_RM_SPETL_NAME FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime'"
génère les résultats suivants :
Dans cet exemple, toutes les modifications de données du
modèle de mesure métier STEW_S capturées dans la base de données d'état et appliquées aux tables de transfert dans la base de données
d'exécution vont être traitées par les procédures mémorisées nommées WBIRMADM.WBIRMSP_10 et WBIRMADM.WBIRMSP_14. Les
données dont le traitement a abouti sont stockées dans les tables cible (identifiées par la colonne TGT_TAB_NAME) dans
la base de données d'exécution.
- Modification de configurations d'instances de composant ETL.
Les configurations d'instances de composant ETL sont stockées dans la table de contrôle WBIRMADM.RMCONTROL.
Les instances affectées au service de transfert de données de la base de données d'état vers la base de données
d'exécution gèrent leur configuration dans la base de données d'exécution. Les autres instances gèrent leur
configuration dans la base de données d'historique. Les procédures mémorisées ne prennent en compte les modifications
apportées à une configuration qu'au démarrage suivant. Trois options peuvent être configurées par l'intermédiaire
de la table de contrôle :
- Temps écoulé minimum entre
deux exécutions ETL (ETLSCHEDMETHOD, ETL_0_MINUTES)
- Granularité de la
sortie de journalisation (LOGLEVEL)
- Durées de transaction (COMMITINTERVAL)
Chaque ligne de la table fait pendant à une instance de composant ETL correspondant à exactement une
table cible qui doit être alimentée. L'exemple de configuration ci-après illustre la manière dont les modifications
de configuration peuvent avoir une incidence sur le comportement des instances.
- Modification du planning ETL
Des instances de composant ETL sont appelées chaque fois qu'une instance de composant Apply a terminé de traiter un ensemble d'abonnements. Lors de l'appel, une instance ETL vérifie son planning et démarre le traitement ou rend immédiatement le contrôle à l'instance de composant Apply.
Elle utilise les informations stockées dans la table de contrôle WBIRMADM.RMCONTROL afin de déterminer si l'exécution
est nécessaire. La figure ci-après illustre les différences entre un appel et une exécution : la première et la troisième fois, l'instance de composant ETL est exécutée en fonction du planning. Le deuxième appel est effectué en dehors
du planning et n'entraîne aucun traitement.
Différents facteurs permettent de déterminer la fréquence d'exécution des instances de composant ETL dans le service de
transfert de données de la base de données d'état vers la base de données d'exécution et de la base de données
d'exécution vers la base de données d'historique.
- Disponibilité : indique si les données vont bientôt être accessibles dans les tables cible.
Le choix d'un intervalle
moins important permet de rendre les données accessibles plus tôt mais augmente également la charge du système.
- Volume de données : Les utilitaires de réplication fournissent de manière continue (ou selon la configuration) des
données aux tables de transfert, que ces dernières soient ou non traitées par des instances de composant ETL. Le volume
de données traité est proportionnel à celui des ressources de base de données utilisées. Un traitement plus fréquent des données permet de réduire l'utilisation maximale de ressources.
- Temps de traitement : Le traitement ETL prend moins de
temps pour les données de la base de données d'exécution que pour celles de la base de données d'historique. Vous devez tenir compte de ces éléments lorsque vous définissez des plannings. L'utilisation d'un petit délai entre les exécutions ne permettra pas d'obtenir de meilleures performances si une exécution dure plus longtemps que le délai prévu. Par exemple,
si le traitement d'une instance de composant ETL prend 60 secondes, un intervalle planifié de 30 secondes devient en
fait un intervalle d'au moins 60 secondes car les instances de composant ETL s'exécutent de manière séquentielle.
Deux modes de planning sont actuellement pris en charge :
- Modification du niveau de consignation.
Deux niveaux de consignation sont pris en charge par les procédures mémorisées : minimum (0) et maximum (1). Pour
modifier le paramètre par défaut (minimum), indiquez une autre valeur dans la colonne LOGLEVEL de WBIRMADM.CONTROL pour
les procédures mémorisées (TGT_RM_SPETL_NAME) dont le niveau de journalisation doit être modifié. Toutes les sorties du journal de consignation sont ajoutées dans WBIRMADM.RMLOG. Les procédures mémorisées WBIRMADM.WBIRMSP_10 et
WBIRMADM.WBIRMSP_14 des deux exemple procèdent à une consignation minimale :
La table de journalisation n'est pas automatiquement élaguée et
doit donc être contrôlées régulièrement par l'administrateur de base de données. La sortie de journalisation doit être maintenue à un niveau minimum sauf instruction contraire.
- Modification des durées de transaction.
Les données qui sont transformées par la procédure mémorisée sont ensuite copiées immédiatement dans les tables cible.
Néanmoins, en fonction du paramètre d'intervalle de validation (colonne COMMITINTERVAL dans WBIRMADM.RMCONTROL),
aucune des mises à jour de la table cible n'est permanente tant que le nombre de lignes spécifié n'a pas été traité ou
qu'il reste des lignes à traiter. Une augmentation de la valeur de COMMITINTERVAL (1500, par exemple) force la procédure
mémorisée à traiter davantage de données afin de valider toute modification. Les verrouillages sur la table cible sont maintenus plus longtemps et peuvent avoir un impact négatif sur d'autres composants qui essaient d'accéder à la même table.
Une diminution de la durée (500, par exemple) réduit le nombre de lignes à traiter avant leur mise à disposition dans
la table cible et annule plus tôt le verrouillage.
Configuration du composant Target Life Cycle.
Les tables de travail ETL s'accroissent de manière continue au fur et à mesure de l'application de données nouvelles
ou mises à jour par les instances de composant Apply. Une instance de composant Target Life Cycle, implémentée par une
procédure mémorisée, est affectée à une table de travail dans chaque base de données cible (base de données d'exécution
et base de données d'historique). Chaque instance applique les stratégies de conservation internes telles qu'elles sont définies dans la table de contrôle WBIRMADM.RMPRUNECTRL. Comme dans les tables source, les stratégies de
conservation Life Cycle pour les tables de travail ETL sont indiquées table par table. Ainsi, une ligne
de WBIRMADM.RMPRUNECTRL correspond à une table nécessitant un élagage.
Résumé des paramètres de configuration des services de transfert
de données
Le tableau ci-après récapitule les paramètres les plus couramment utilisés fournis pour chacun des composants
de service de transfert de données.
Pour plus d'informations sur ces paramètres de configuration, voir le manuel de réplication
DB2.
Composant |
Nom du paramètre |
Valeurs par défaut |
Valeurs admises |
Emplacement du paramètre |
Capture |
autoprune |
O |
|
|
Capture |
prune_interval (secondes) |
300 |
|
|
Source Life Cycle |
PRUNE_ENABLED |
1 |
0 - Désactivé
1 - Activé
|
Base de données source du service de transfert de données : WBIRMADM.RMPRUNECTRL
|
Source Life Cycle |
RETENTION_IN_MINUTES |
0 - Etat vers exécution
1440 - Exécution vers historique
|
Limite 0 de
DB2
pour BIGINT |
Base de données source du service de transfert de données : WBIRMADM.RMPRUNECTRL
|
Source Life Cycle |
PRUNE_INTERVAL (minutes) |
5 |
Limite 0 de
DB2
pour BIGINT |
Base de données source du service de transfert de données : WBIRMADM.RMPRUNECTRL
|
ETL |
ETLSCHEDMETHOD |
1 |
0 - Planning flexible
1 - Planning d'intervalle strict
Autre - Désactivation ETL
|
Base de données cible du service de transfert de données : WBIRMADM.RMCONTROL
|
ETL |
ETL_0_MINUTES |
5 - Etat vers exécution
1440 - Exécution vers historique
|
Limite 0 de
DB2
pour INTEGER |
Base de données cible du service de transfert de données : WBIRMADM.RMCONTROL
|
ETL |
LOGLEVEL |
0 |
0 - Pour consignation normale
1 - Pour consignation de trace
|
Base de données cible du service de transfert de données : WBIRMADM.RMCONTROL
|
ETL |
COMMITINTERVAL (nombre d'enregistrements.) |
1000 |
0 - Désactivation des validations jusqu'à la fin
1 - Valider chaque enregistrement.
n - Limite
DB2
pour BIGINT
|
Base de données cible du service de transfert de données : WBIRMADM.RMCONTROL
|
Target Life Cycle |
PRUNE_ENABLED |
1 |
0 - Désactivé
1 - Activé
|
Base de données cible du
service de transfert de données : WBIRMADM.RMPRUNECTRL
|
Target Life Cycle |
RETENTION_IN_MINUTES |
0 |
Limite 0 de
DB2
pour BIGINT |
Base de données cible du
service de transfert de données : WBIRMADM.RMPRUNECTRL
|
Target Life Cycle |
PRUNE_INTERVAL (minutes) |
1440 |
Limite 0 de
DB2
pour BIGINT |
Base de données cible du
service de transfert de données : WBIRMADM.RMPRUNECTRL
|
Remarque : IBM
se réserve le droit de modifier les tables de base de données et les colonnes référencées ci-dessus.
Certaines tables et colonnes peuvent ainsi être modifiées, supprimées ou ajoutées d'une version à l'autre. Toute utilisation des données ou de la structure référencée d'une version à l'autre se fait donc aux risques et périls
du client. IBM
fournira des informations concernant les modifications effectuées au fur et à mesure.