Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Überblick über das EnterpriseOne Verhalten von JD Edwards auf SQL Server
EnterpriseOne Geschäftslogik wird hauptsächlich innerhalb von Anwendungen behandelt. Von der Anwendung werden nur grundlegende DML-Anweisungen (DML) an die Datenbank übermittelt. Bei der Standardverarbeitung wird der Datensatz in der Datenbank geöffnet, aber von der Anwendung verwaltet. Die Anwendung führt dann in der Regel mehrere DML-Operationen für jeden Datensatz in der Datensatzgruppe aus. Dieser Ansatz generiert ein beträchtliches Volumen von chatty DML-Operationen gegen die Datenbank. Die Latenz jedes DML-Vorgangs ist einer der wichtigsten Leistungstreiber. Aufgrund dieser Architektur ist die CPU-Auslastung der unterstützten Datenbank in der EnterpriseOne Regel minimal, wohingegen Netzwerk- und Festplatten-I/O-Eigenschaften die Haupttreiber der Prozessleistung sind. EnterpriseOne Die Datenbankoptimierung konzentriert sich stark auf die Minimierung der DML-Latenz.
Um die Latenzauswirkungen von Festplatten-Lese-I/O zu minimieren, wird häufig ein großer Puffercache verwendet. Dies kann mit der SQL-Server-Datenkomprimierung kombiniert werden, um den Puffercache wesentlich effektiver zu gestalten. Die Verwendung der Datenkomprimierung wirkt sich zwar auf die CPU aus, der Aufwand ist jedoch minimal, wenn Sie diesen Ansatz mit verwenden. EnterpriseOne Wenn der Puffercache ausreichend dimensioniert ist, ist die I/O-Latenz beim Lesen der Festplatte normalerweise kein Problem.
Der SQL Server-Puffercache berücksichtigt nicht die Latenz von I/O-Schreibvorgängen. Wenn ein EnterpriseOne Prozess eine große Anzahl von unübersichtlichen Schreibvorgängen generiert, kann die Leistung durch die Latenz jedes Schreibvorgangs eingeschränkt werden, der in das Transaktionslog eingeht. Um diese Latenz zu minimieren, können Sie io2 und/oder io2-Block-Express-Volumes für die LDF-Datei verwenden. Wenn io2 oder io2 Block Express allein nicht ausreicht, um die erforderliche Leistung zu liefern, oder anderweitig zu teuer ist, können Sie eine Konfiguration mit verzögerter Haltbarkeit verwenden, um die Leistung zu verbessern.
Da viele EnterpriseOne Prozesse Datensätze erstellen, die sich mit anderen offenen Datensätzen überschneiden können, sollten Sie die Read Committed Snapshot Isolation (RCSI) für jede EnterpriseOne Datenbank aktivieren, um Blockierungen zu minimieren. Wenn dieses Feature aktiviert ist, kann sie zu erheblichen I/O-Anforderungen für tempdb führen. tempdb ist von Natur aus kurzlebig und erfordert nicht die Haltbarkeit eines Standard-Blockspeichers. In den meisten Fällen ist der nichtflüchtige Speicher (ExpressNVMe) für lokale Instanzen die beste Wahl. tempdb
In den folgenden Abschnitten dieses Handbuchs werden diese und andere bewährte Methoden zur Optimierung von SQL Server für JD EnterpriseOne Edwards untersucht.
