SQL Server での JD Edwards EnterpriseOne の動作の概要

EnterpriseOne のビジネスロジックは主にアプリケーション内で処理されます。基本的なデータ操作言語 (DML) ステートメントのみが、アプリケーションからデータベースに渡されます。標準処理では、レコードセットはデータベースで開かれますが、アプリケーションによって管理されます。その後、アプリケーションは通常、レコードセット内の各レコードに対して複数の DML オペレーションを実行します。このアプローチでは、データベースに対する、雑音の多い大量の DML オペレーションが発生します。各 DML オペレーションのレイテンシーは、パフォーマンスを左右する重要な要因の 1 つです。このアーキテクチャにより、EnterpriseOne をサポートするデータベースの CPU 使用率は最小限に抑えられがちですが、ネットワークとディスク I/O の特性は、プロセスのパフォーマンスを左右する主な要因です。EnterpriseOne データベースのチューニングは、DML レイテンシーの最小化に重点を置きます。

ディスク読み取り I/O によるレイテンシーの影響を軽減するために、大容量のバッファキャッシュがよく使用されます。これを SQL Server のデータ圧縮と組み合わせることで、バッファキャッシュの効果を大幅に高めることができます。データ圧縮を使用すると CPU に影響しますが、EnterpriseOne でこのアプローチを使用すると、オーバーヘッドを最小限に抑えることができます。バッファキャッシュのサイズが適切であれば、通常、ディスク読み取り I/O のレイテンシーは問題になりません。

SQL Server のバッファキャッシュは書き込み I/O のレイテンシーに対応していないため、EnterpriseOne のプロセスが雑音の多い大量の書き込みオペレーションを生成した場合、トランザクションログにコミットする各書き込みオペレーションのレイテンシーによって、パフォーマンスが制限されることがあります。このレイテンシーを最小限に抑えるには、LDF ファイル用の io2 および/または io2 Block Express ボリュームを使用します。io2 または io2 Block Express だけでは十分なパフォーマンスを発揮できない場合、またはコストがかかりすぎる場合は、遅延耐久性を設定することでパフォーマンスを改善できます。

多くの EnterpriseOne のプロセスでは、開いている他のレコードセットと重複する可能性のあるレコードセットが作成されるため、各 EnterpriseOne データベースでコミット済みのスナップショットアイソレーション (RCSI) を有効にして、ブロックを最小限に抑える必要があります。この機能を有効にすると、tempdb の I/O 要件が大きくなる可能性があります。tempdb は本質的にエフェメラルなものであり、標準のブロックストレージのような耐久性は不要です。ほとんどの場合、ローカルインスタンスの不揮発性メモリエクスプレス (NVMe) ストレージが tempdb の最適な選択です。

このガイドの以下のセクションでは、SQL Server for JD Edwards EnterpriseOne を最適化する、さまざまなベストプラクティスについて説明します。