Les services de base de données prennent en charge
WebSphere
Business Monitor
via deux services 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. Ces services de transfert de données sont
complètement indépendants les uns des autres. Chacun de ces
services prend en charge un ou plusieurs
modèles de mesure métier.
Pour
chaque
modèle de mesure métier
pris en charge par un service de transfert de données, un ensemble de serveurs
Capture et Apply est créé.
Dans l'architecture en cours, il existe, par défaut, un serveur Capture et
un serveur Apply pour chaque modèle de mesure métier.
Vous pouvez cependant avoir plusieurs serveurs Capture ou Apply ; pour ce
faire, vous devez modifier des paramètres dans les groupes de paramètres
suivants : paramètres de stratégie Capture, paramètres de stratégie Apply
et paramètres de stratégie de groupe Apply.
Si
les
modèles de mesure métier
sont de grande taille, l'utilisation d'un seul serveur Capture et Apply
par modèle et par service de transfert de données peut affecter les
performances ; il
s'agit là d'une situation où la modification de ces paramètres peut permettre
d'améliorer les performances. Avec un matériel, un espace table et une
planification de pool de mémoire tampon adéquats, il est possible d'améliorer
les performances en ajoutant des serveurs Capture et Apply
supplémentaires.
Un plus grand
nombre de serveurs Capture peut contribuer à augmenter la vitesse de
capture des données pour les tables d'un modèle de mesure métier.
Il est possible de diminuer la valeur de l'un ou de l'ensemble des paramètres
de stratégie Capture. Chaque serveur Capture supplémentaire utilise, en
revanche, de l'espace de base de données supplémentaire pour le stockage de
ses informations de contrôle ainsi que davantage de temps processeur et d'E-S. Néanmoins, l'augmentation du nombre de serveurs peut rendre les informations
plus rapidement accessibles pour les composants Apply et améliorer le
débit système global.
Un
plus grand nombre de serveurs Apply peut également présenter d'autres
avantages. Dans l'architecture actuelle, les serveurs Apply agissent sur
les tables qui leur sont affectées en série. Plus le nombre de groupes de
mesures métier et de tables affectées à un seul serveur Apply est élevé,
plus long est le traitement de toutes les entrées. L'ajout de serveurs Apply supplémentaires peut permettre d'améliorer les
performances grâce à un traitement de ces groupes de mesures métier en
parallèle. Un matériel adéquat et suffisamment
d'espace table et de pools de mémoire sont nécessaires pour éviter un conflit
des E-S.
Il est déconseillé de
modifier les valeurs par défaut des paramètres de stratégie de groupe Apply.
Pour
indiquer des paramètres de stratégie, procédez comme suit :
Localisez
le répertoire d'installation de Monitor sur la machine qui héberge Monitor
Server. Exemple : 'C:\IBM\WebSphere\Monitor' sous Windows. Ce
sous-répertoire doit comporter un répertoire nommé 'rm' lequel doit contenir
une autre répertoire nommé 'config'. Dans cet exemple, 'C:\IBM\WebSphere\Monitor\rm\config'
est le chemin d'accès absolu au répertoire.
Créez un nouveau fichier appelé
'DS_Replication_Policy_Defaults.properties' dans le répertoire config. Si ce
fichier existe déjà, il sera lu par les composants de services de données
pour les substitutions utilisateur des paramètres relatifs aux stratégies de
performances.
Les paramètres
sont indiqués comme suit :
- Valeur par
défaut pour tous les services de transfert de données : POLICY_NAME=<POLICY_VALUE>
- Valeur
spécifique pour un service de transfert de données particulier : <SERVICE_NAME>.POLICY_NAME=<POLICY_VALUE>
- Les
noms de service actuellement corrects sont les suivants : State_to_Runtime
et Runtime_to_Historical.
Au
cours du traitement du service de transfert de données, le système recherche
d'abord des valeurs spécifiques au service, puis des valeurs par défaut
explicites, et enfin des valeurs par défaut internes ou implicites.
Paramètres
de stratégie Capture
Ces
paramètres permettent de modifier le mode d'affectation des
groupes de mesures métier aux serveurs Capture. Il y a toujours un serveur
Capture pour chaque
modèle de mesure métier,
mais à la différence de l'architecture précédente, il est désormais
possible d'affecter plusieurs groupes de mesures métier au même serveur
Capture, au lieu d'un serveur distinct pour chaque groupe.
- POLICY_CAPTURE_MAX_GROUPS_PER_SERVER
- Cette
stratégie permet essentiellement de contrôler le nombre de groupes pouvant
être alloués à un serveur Capture particulier qui est affecté au
modèle de mesure métier
parent.
Au cours de la phase d'affectation, si le système n'a pas pu trouver un
serveur Capture existant qui puisse accueillir un groupe de mesures métier
supplémentaire tout en respectant cette stratégie, un nouveau serveur
Capture est créé pour le nouveau groupe de mesures métier.
Remarque : Au cours de la gestion des
modifications, ces serveurs ne sont pas rééquilibrés. Pour cela, vous devez annuler le déploiement de tous les
artefacts de réplication prenant en charge ce
modèle de mesure métier
puis les régénérer en tant que nouveau modèle. Cette stratégie n'empêche pas l'affection d'un groupe de mesures métier
à un nouveau serveur Capture. Cette stratégie n'a en outre aucune incidence
sur l'affectation d'un groupe de mesures métier au cours de la gestion des
modifications si ce groupe est déjà affecté à un serveur Capture.
- La
valeur par défaut est actuellement 50.
- Les
valeurs admises sont affichées dans le tableau ci-après.
Valeurs
POLICY_CAPTURE_MAX_GROUPS_PER_SERVER
Valeur |
Description |
-1 |
La stratégie est désactivée. |
0 |
A
le même effet que 1 ; crée toujours un nouveau serveur Capture pour chaque
groupe de mesures métier. |
> 1 |
Applique
la stratégie en fonction de ce nombre. |
- POLICY_CAPTURE_MAX_TABLES_PER_SERVER
- Cette
stratégie contrôle le nombre de tables pouvant être affectées à un serveur
particulier quel que soit le nombre de groupes. Si l'on suppose que 10 tables
sont associées à un groupe de mesures métier, qu'un serveur Capture existant
comporte 10 tables et que la stratégie est définie par la valeur 19, un nouveau
serveur Capture sera créé, par stratégie, pour le nouveau groupe de mesures
métier.
Remarque : Même si un groupe de mesures métier
dépasse à lui seul cette stratégie, celle-ci n'empêchera pas son affectation à
un nouveau serveur Capture. Cette stratégie n'a en outre aucune incidence sur
l'affectation d'un groupe de mesures métier au cours de la gestion des
modifications si ce groupe est déjà affecté à un serveur Capture.
- La valeur par défaut est actuellement -1.
- Les valeurs admises sont affichées dans le tableau ci-après.
Valeurs
POLICY_CAPTURE_MAX_TABLES_PER_SERVER
Valeur |
Description |
< 0 |
La stratégie est désactivée. |
-1 |
La stratégie est désactivée. |
0 |
Identique à 1 ; crée toujours un nouveau serveur Capture pour
chaque nouveau groupe de mesures métier. |
> 1 |
Applique la stratégie en fonction de ce nombre. |
- POLICY_CAPTURE_MIN_PERCENT_FREE_AFTER_GROUP_ADD
- Cette
stratégie permet de contrôler le nombre de tables qui doivent être libres (par
comparaison avec POLICY_CAPTURE_MAX_TABLES_PER_SERVER)
après qu'un
modèle de mesure métier
est affecté à un serveur Capture.
Remarque : Même si
un groupe de mesures métier dépasse à lui seul cette stratégie, celle-ci
n'empêchera pas son affectation à un nouveau serveur Capture.
Cette stratégie
n'a en outre aucune incidence sur l'affectation d'un groupe de mesures métier
au cours de la gestion des modifications si ce groupe est déjà affecté à un
serveur Capture.
- La valeur par défaut est actuellement -1.
- Les valeurs admises sont affichées dans le tableau ci-après.
Valeurs
POLICY_CAPTURE_MIN_PERCENT_FREE_AFTER_GROUP_ADD
Valeur |
Description |
< 0 |
La stratégie est désactivée. |
-1 |
La stratégie est désactivée. |
0 |
Identique à 1 ; crée toujours un nouveau serveur Capture pour chaque nouveau
groupe de mesures métier. |
>1
et < 100 |
La stratégie sera appliquée en fonction de ce seuil. |
>=100 |
Identique à 1 ; crée toujours un nouveau serveur Capture pour chaque nouveau
groupe de mesures métier. |
Paramètres de stratégie Apply
Ces paramètres permettent de modifier le mode d'affectation des groupes de
mesures métier aux serveurs Apply. Il y a actuellement toujours un serveur Apply
pour chaque modèle de mesure métier, mais à la différence de l'architecture
précédente, il est désormais possible
d'affecter plusieurs groupes de mesures métier au même serveur Apply, au lieu
d'un serveur distinct pour chaque groupe.
- POLICY_APPLY_IS_CONSISTENT_WITH_CAPTURE
- POLICY_APPLY_MAX_GROUPS_PER_SERVER
- Cette stratégie permet de contrôler le nombre de groupes
pouvant être alloués à un serveur Apply particulier qui est affecté au
modèle de mesure métier
parent.
Si, au cours de la phase d'affectation, aucun serveur
Apply n'a atteint le seuil, un nouveau serveur Apply est créé pour le
nouveau groupe de mesures métier.
Remarque : Au cours de la gestion des
modifications, ces serveurs ne sont pas rééquilibrés.
Pour cela, vous devez annuler le déploiement de tous les artefacts de
réplication prenant en charge ce
modèle de mesure métier
puis les regénérer en tant que nouveau modèle. Cette stratégie n'empêche pas l'affection d'un groupe de mesures métier à un
nouveau serveur Apply. Cette stratégie n'a en outre aucune incidence sur
l'affectation d'un groupe de mesures métier au cours de la gestion des
modifications si ce groupe est déjà affecté à un serveur Apply.
- Valeur par défaut =50.
- Les
valeurs admises sont affichées dans le tableau ci-après.
Valeurs
POLICY_APPLY_MAX_GROUPS_PER_SERVER
Valeur |
Description |
< 0 |
La stratégie est désactivée. |
-1 |
La stratégie est désactivée. |
0 |
Identique à 1 ; crée toujours un nouveau serveur Apply pour chaque nouveau
groupe de mesures métier. |
>1 |
Applique la stratégie en fonction de ce nombre. |
- POLICY_APPLY_MAX_APPLYGROUPS_PER_SERVER
- Cette stratégie contrôle l'allocation de groupes Apply à un serveur
particulier.
Elle est généralement utilisée conjointement avec des stratégies
de groupe Apply pour contrôler la distribution de mesures métier à un serveur. Les
groupes Apply dans
DB2
sont appelés ensemble d'abonnements.
Remarque : Au cours de la gestion des
modifications, ces serveurs ne sont pas rééquilibrés. Pour cela, vous devez annuler le déploiement de tous les artefacts de
réplication prenant en charge ce
modèle de mesure métier
puis les regénérer en tant que nouveau modèle. Cette stratégie n'empêche pas l'affection d'un groupe de mesures métier à un
nouveau serveur Apply. Cette stratégie n'a en outre aucune incidence sur
l'affectation d'un groupe de mesures métier au cours de la gestion des
modifications si ce groupe est déjà affecté à un serveur Apply.
- Valeur par défaut =1.
- Les valeurs
admises sont affichées dans le tableau ci-après.
Valeurs
POLICY_APPLY_MAX_APPLYGROUPS_PER_SERVER
Valeur |
Description |
<0 |
La stratégie est désactivée. |
-1 |
La stratégie est désactivée. |
0 |
Identique à 1 ; crée toujours un nouveau serveur Apply pour chaque nouveau
groupe de mesures métier. |
>1 |
Applique la stratégie en fonction de ce nombre. |
- POLICY_APPLY_MAX_TABLES_PER_SERVER
- Cette stratégie contrôle l'allocation de groupes de mesures métier en fonction
du nombre de tables allouées par serveur.
Remarque : Au cours de la gestion des modifications, ces serveurs ne sont pas
rééquilibrés. Pour cela, vous devez annuler le déploiement de tous les artefacts de
réplication prenant en charge ce
modèle de mesure métier
puis les regénérer en tant que nouveau modèle. Cette stratégie n'empêche pas l'affection d'un groupe de mesures métier à un
nouveau serveur Apply. Cette stratégie n'a en outre aucune incidence sur
l'affectation d'un groupe de mesures métier au cours de la gestion des
modifications si ce groupe est déjà affecté à un serveur Apply.
- Valeur par défaut =1.
- Les valeurs
admises sont affichées dans le tableau ci-après.
Valeurs
POLICY_APPLY_MAX_TABLES_PER_SERVER
Valeur |
Description |
<0 |
La stratégie est désactivée. |
-1 |
La stratégie est désactivée. |
0 |
Identique à 1 ; crée toujours un nouveau serveur Apply pour chaque nouveau
groupe de mesures métier. |
>1 |
Applique la stratégie en fonction de ce nombre. |
Paramètres de stratégie de groupe Apply
Ces
stratégies ont une incidence sur le mode d'allocation des groupes de mesures
métier aux groupes Apply ; dans
DB2,
on parle d'ensembles d'abonnements. Consultez la documentation relative à la réplication DB2
pour en savoir plus sur les meilleures façons d'allouer des
tables au sein d'ensembles d'abonnements. Replication Manager choisit toujours d'allouer un groupe de mesures métier par
ensemble d'abonnements.
- POLICY_APPLY_MAX_TABLES_PER_APPLYGROUP
- Cette stratégie contrôle l'allocation de groupes de mesures métier en fonction
du nombre de tables allouées par groupe Apply.
- Valeur par défaut =1.
- Les valeurs
admises sont affichées dans le tableau ci-après.
Valeurs
POLICY_APPLY_MAX_TABLES_PER_APPLYGROUP
Valeur |
Description |
<0 |
La stratégie est désactivée. |
-1 |
La stratégie est désactivée. |
0 |
Identique à 1 ; crée toujours un nouveau groupe Apply pour chaque nouveau
groupe de mesures métier. |
>1 |
Applique la stratégie en fonction de ce nombre. |
- POLICY_APPLY_MAX_GROUPS_PER_APPLYGROUP
- Cette stratégie contrôle l'allocation de groupes de mesures métier en fonction
du nombre de groupes de mesures métier par groupe Apply.
- Valeur par défaut =1.
- Les valeurs
admises sont affichées dans le tableau ci-après.
Valeurs
POLICY_APPLY_MAX_GROUPS_PER_APPLYGROUP
Valeur |
Description |
<0 |
La stratégie est désactivée. |
-1 |
La stratégie est désactivée. |
0 |
Identique à 1 ; crée toujours un nouveau groupe Apply pour chaque nouveau
groupe de mesures métier. |
>1 |
Applique la stratégie en fonction de ce nombre. |