Optimisation des performances pour le traitement parallèle

Cette annexe décrit l'optimisation des performances éventuellement requise pour exécuter la session Traitement CI (tccri7203m000) via le traitement parallèle.

Les performances réelles de la session Traitement CI (tccri7203m000) dépendent de plusieurs facteurs, dont le nombre d'UC disponibles et la configuration des serveurs d'application et de base de données. La quantité de données contenues dans les tables constitue un autre facteur majeur. En général, les tables suivantes contiennent d'importantes quantités de données :

  • Ecritures d'intégration (tfgld482)
  • Données de rapprochement (tfgld495)
  • Ecritures finalisées (tfgld106)
  • Transactions d'en-cours et de stock (JSC) (ticst300)
  • En-cours PCS et transactions de stock (tipcs 300)
  • Historique des commandes clients (tdsls450, tdsls451 et tdsls456)

Dans LN FP5 et les versions ultérieures, une fonctionnalité est disponible pour mettre à jour les tables directement via le SGBDR. Cette fonctionnalité est introduite dans les versions 8.7a.03 et ultérieures du jeu de ports.

Les mises à jours effectuées directement via le SGBDR sont plus efficaces que les mises à jour via bshell. La différence réside dans le fait que l'intégralité de l'écriture est transmise sur le SGBDR. Ce type de mise à jour se limite aux tables aux données qui n'exigent pas de recalcul des montants société et/ou des taux de change. Cette situation peut se présenter si, par exemple, les montants société d'une devise de reporting deviennent les montants en devise locale. La suppression des montants société est un autre exemple. Cela peut être le cas si les devises de reporting sont supprimées, ou si le système de devises des tables logistiques se transforme en système de devises standard.

La session Traitement CI (tccri7203m000) vérifiera l'existence de mises à jour directement à partir du SGBDR. La session utilisera les mises à jour conventionnelles (plus lentes) si la mise à jour directement via le SGBDR n'est pas autorisée.

L'utilisation possible ou non du SGBDR est déterminée par les facteurs suivants :

  • Dans la session Taux CI (tccri7100m000), la valeur du champ Exprimer en devise de référence doit correspondre à celle du champ correspondant dans la session Taux de change (tcmcs0108m000). Par exemple, dans les sociétés EURO, les taux de change de l'EUR (local) vers les devises d'écriture peuvent être conservés si le paramètre Exprimer en devise de référence en devise de base ne change pas pendant la conversion.

    Remarque : Cela s'applique à tous les types de taux de chaque devise de base dans la session Taux de change (tcmcs0108m000).

  • Limites techniques

    Les restrictions suivantes s'appliquent :

    • Le pilote DB doit être un pilote de niveau 2.

    • Les tables suivantes sont auditées :

      tfgld495, tfgld482, tdsls451 et tdsls456

  • La version 8.7a.03 ou ultérieure du jeu de ports doit être utilisée. Le niveau TIV du jeu de ports doit être 1744 ou ultérieur. Vous pouvez vérifier ce nombre en exécutant $BSE/bin/bshell6.2 –V sur la ligne de commande (dans Windows, utilisez %BSE\bin\ntbshell –V).

Si le processus d'initialisation de devise démarre dans la session Traitement CI (tccri7203m000), cette session accèdera au cluster de conversion et aux sociétés concernées, puis déterminera le type de conversion requis. Si les mises à jour directement via le SGBDR peuvent être appliquées, certaines données seront générées dans les Tables de conversion CI par sociétés de cluster (tccri725) et les Tables de conversion de cluster CI - groupes de mise à jour (tccri726).

Remarque

Les Tables de conversion de cluster CI - Groupes de mise à jour (tccri726) sont générées uniquement pour les entrées Ecritures d'intégration (tfgld482) dans la session Tables de conversion CI par sociétés de cluster (tccri7125m000).

Dans la session Tables de conversion CI par sociétés de cluster (tccri7125m000), le champ Mises à jour en masse sera sélectionné si Traitement CI (tccri7203m000) met à jour une table directement via le SGBDR.

La table Transactions d'intégration (tfgld482) peut contenir des écritures qui appartiennent à plusieurs sociétés financières. Les écritures d'intégration pouvant être gérées avec des mises à jour directement via le SGBDR seront regroupées dans les groupes de mise à jour. Les écritures d'un groupe de mise à jour peuvent être converties dans une mise à jour SGBDR. Si les Ecritures d'intégration (tfgld482) doivent être converties dans mises à jour directement via le SGBDR (également), la conversion de la table peut néanmoins être divisée. Ainsi, la mise à jour conventionnelle de la table sera traitée à l'aide des traitements parallèles.

Les Données de rapprochement (tfgld495) doivent être divisées uniquement si les mises à jour directement via le SGBDR ne peuvent être appliquées. Cela sera le cas, si par exemple, le recalcul des montants société ou des taux de change est requis.

Remarque
  • Si la conversion des Données de rapprochement (tfgld495) est divisée, la table ne sera pas mise à jour par le biais des mises à jour directement via le SGBDR.
  • La table Ecritures finalisées (tfgld106) peut être convertie à l'aide des traitements parallèles. Les mises à jour effectuées directement via le SGBDR ne sont pas prises en charge.

Exemple d'optimisation

Cet exemple s'applique aux tâches de conversion traitées sans mises à jour directement via les SGBDR et pouvant être réparties dans Tables de conversion CI par sociétés de cluster (tccri7125m000).

Une conversion interne avec traitement parallèle peut impliquer des conversions avec et sans mises à jour directement via le SGBDR, en fonction de la configuration des devises par société.

Supposez que les données de trois sociétés doivent être converties à l'aide de neuf bshells parallèles. L'image illustre cette situation avec des couleurs différentes pour les trois sociétés.

La table convertie dans la tâche 1.1 est très grande. Dans le même temps, trois autres tables importantes sont également converties (2.1, 2.2 et 3.1). Si la grande tâche de conversion 1.1 peut être divisée, vous pouvez choisir d'avoir six tâches de traitement bshells 1.1, tandis que trois bshells traiteront les tâches 2.1, 2.2 et 3.1. Après division de la tâche 1.1, les six tâches plus importantes qui prennent en charge cette tâche seront traitées avant les tâches plus petites (de couleur violette).

La même approche peut être appliquée si, par exemple, la conversion de table 2.3 et 2.4 peut être divisée. Si la table 2.3 est traitée par deux bshells en parallèle et 2.4 est traitée par trois bshells en parallèle, la capacité restante est suffisante pour permettre aux bshells parallèles restants de traiter simultanément les tâches plus petites (de couleur verte).

Après division des tâches, la charge des traitements parallèles semblera plus équilibrée.

La durée totale écoulée est réduite de 28 à 17 unités de temps.

Traitement CI (tccri7203m000) : conversion d'essai VS conversion réelle

En mode de simulation, les écritures de base de données des mises à jour effectuées directement via le SGBDR seront testées. Ce type de mises à jour peut être utilisé dans le cadre de la conversion des Données de rapprochement (tfgld495), Ecritures d'intégration (tfgld482), Lignes d'historique des commandes clients (tdsls451) et Lignes de livraison de l'historique des commandes clients (tdsls456). Les écritures seront annulées en mode d'essai. Cela peut prendre beaucoup plus de temps que l'écriture réelle dans une conversion réelle.

Dans la logique de conversion conventionnelle, la mise à jour des données de la table n'est pas effectuée pendant la conversion d'essai. Notez qu'en revanche, ces tables seront traitées dans un délai plus court pendant la conversion d'essai, leur traitement prenant plus de temps dans la conversion réelle.
Remarque

Lors de l'initialisation des devises, aucun autre utilisateur ou processus ne doit être actif dans les sociétés du cluster de conversion, même si la session Traitement CI (tccri7203m000) est utilisée pour réaliser une conversion d'essai.

Pour éviter tout problème de verrouillages de table ou de lecture d'écritures non attribuées, soyez attentif aux aspects suivants :
  • Les mises à jours directement via le SGBDR seront d'importantes écritures testées mais non attribuées pendant la conversion d'essai. Cela peut entraîner des verrouillages de table sur les Données de rapprochement (tfgld495), Ecritures d'intégration (tfgld482), Lignes d'historique des commandes clients (tdsls451) et Lignes de livraison de l'historique des commandes clients (tdsls456).
  • Serveur SQL : Par défaut, le pilote de base de données utilise le niveau d'isolation « Lecture non attribuée » pour prévenir les verrouillages partagés et le verrouillage exclusif pour les actions de mise à jour et de suppression. Pendant la conversion (d'essai), d'autres utilisateurs ou processus risquent de lire des écritures non attribuées dans les Données de rapprochement (tfgld495), Ecritures d'intégration (tfgld482), Lignes d'historique des commandes clients (tdsls451) et Lignes de livraison de l'historique des commandes clients (tdsls456). Pour plus d’informations, reportez-vous au Guide de référence technique d’Infor Enterprise Server pour le pilote de base de données SQL Server (U8173US).

Paramètres Oracle

Les mises à jours directement via le SGBDR seront des écritures importantes. Par conséquent, une grande quantité d'espace de table d'annulation sera requis. LN est testé avec un espace de table d'annulation de 32 Go. Nous vous recommandons de configurer l'espace de table d'annulation pour étendre automatiquement les fichiers de données de 8 Go à la fois par exemple. Cela évitera l'apparition d'erreur ORA-1555 (Instantané trop ancien). N'oubliez pas la taille maximale du fichier de données.

Il est difficile de prédire si la taille de l'espace de table d'annulation sera suffisant. Nous vous recommandons de rechercher les erreurs ORA-1555 dans les journaux d'événements d'LN lorsque la session Traitement CI (tccri7203m000) est en cours d'exécution.

En règle générale, pour que les requêtes aboutissent, la base de données Oracle requiert une optimisation adéquate.

LN a été testé avec les paramètres suivants appliqués à l'environnement LN via le fichier $BSE/lib/default/db_resource :

  • ora_init:0101000
  • ora_max_array_fetch:100
  • ora_max_array_insert:100
  • ora_alter_session: définissez " _optim_peek_user_binds "= false

Vous devez envisager de fusionner les lignes ci-dessus avec la ressource db en lots pour la conversion.

Dans certaines implémentations, des valeurs différentes de celles par défaut sont appliquées pour masquer les paramètres Oracle (les paramètres dits de soulignement). Ces paramètres peuvent influer sur les plans d'exécution des requêtes. Pensez à les réinitialiser sur les valeurs par défaut. Pour cela, vous pouvez les ajouter à la propriété ora_alter_session dans le fichier $BSE//lib/defaults/db_resource.

Paramètres serveur SQL

Vous devez envisager de changer la journalisation sur la base de données LN pendant l'initialisation de devise en Simple et de créer une sauvegarde complète à l'issue de l'initialisation de devise.

Configurez le fichier $BSE/lib/default/db_resource pour permettre la recherche par tableau, puis définissez la taille de recherche sur 100.

Paramètres DB2

Configurez le fichier $BSE/lib/default/db_resource pour permettre la recherche par tableau, puis définissez la taille de recherche sur 100.