Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Présentation du EnterpriseOne comportement de JD Edwards sur SQL Server
EnterpriseOne la logique métier est principalement gérée au sein des applications. Seules les instructions de langage de manipulation de données (DML) sont transmises à la base de données depuis l'application. Dans le cadre du traitement standard, l'ensemble d'enregistrements est ouvert dans la base de données, mais est géré par l'application. L'application effectue ensuite généralement plusieurs opérations DML pour chaque enregistrement de l'ensemble d'enregistrements. Cette approche génère un volume important d'opérations DML bavardes sur la base de données. La latence de chaque opération DML est l'un des principaux facteurs de performance. En raison de cette architecture, l'utilisation du processeur par la base de données prise en charge EnterpriseOne a tendance à être minimale, tandis que les caractéristiques du réseau et des E/S du disque sont les principaux déterminants des performances des processus. EnterpriseOne le réglage des bases de données met fortement l'accent sur la minimisation de la latence DML.
Pour atténuer l'impact de latence des E/S de lecture de disque, un cache de tampon de grande taille est souvent utilisé. Cela peut être combiné à la compression des données de SQL Server pour améliorer considérablement l'efficacité du cache de tampon. Bien que l'utilisation de la compression des données affecte le processeur, la surcharge est minime lorsque vous utilisez cette approche avec EnterpriseOne. Lorsque le cache de tampon est correctement dimensionné, la latence des E/S de lecture de disque n'est généralement pas un problème.
Le cache tampon de SQL Server ne règle pas la latence des E/S d'écriture. Lorsqu'un EnterpriseOne processus génère un grand nombre d'opérations d'écriture bavardes, les performances peuvent être limitées par la latence de chaque opération d'écriture validée dans le journal des transactions. Pour réduire cette latence, vous pouvez utiliser io2 et/ou des volumes io2 Block Express pour le fichier LDF. Si io2 ou io2 Block Express ne suffit pas à fournir les performances requises ou si son coût est prohibitif, vous pouvez utiliser une configuration de durabilité retardée pour améliorer les performances.
Étant donné que de nombreux EnterpriseOne processus créent des ensembles d'enregistrements susceptibles de se chevaucher avec d'autres ensembles d'enregistrements ouverts, vous devez activer l'isolation des instantanés en lecture validée (RCSI) sur chaque EnterpriseOne base de données afin de minimiser le blocage. Lorsque cette fonctionnalité est activée, elle peut créer une exigence d'E/S considérable pour tempdb. tempdb est éphémère par nature et ne nécessite pas la durabilité d'un stockage par blocs standard. Dans la plupart des cas, le stockage express (NVMe) en mémoire non volatile en instance locale est le meilleur choix pourtempdb.
Les sections suivantes de ce guide explorent ces meilleures pratiques ainsi que d'autres pour optimiser SQL Server pour JD Edwards EnterpriseOne.