SQL Server에서 JD Edwards EnterpriseOne 동작 개요

EnterpriseOne 비즈니스 로직은 주로 애플리케이션 내에서 처리됩니다. 기본 데이터 조작 언어(DML) 문이 애플리케이션에서 데이터베이스로 전달됩니다. 표준 처리에서 레코드 세트는 데이터베이스에서 열리지만 애플리케이션에 의해 관리됩니다. 그러면 애플리케이션은 일반적으로 레코드 세트의 각 레코드에 대해 여러 DML 작업을 수행합니다. 이 접근 방식은 데이터베이스에 대해 상당한 양의 복잡한 DML 작업을 생성합니다. 각 DML 작업의 지연 시간은 성능의 주요 동인 중 하나입니다. 이 아키텍처로 인해 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(Read Committed Snapshot Isolation)를 활성화하여 차단을 최소화해야 합니다. 이 기능을 활성화하면 tempdb에 대한 상당한 I/O 요구 사항이 발생할 수 있습니다. tempdb는 본질적으로 일시적이며 표준 블록 스토리지의 내구성을 필요로 하지 않습니다. 대부분의 경우 로컬 인스턴스 NVMe(Non-Volatile Memory express) 스토리지가 tempdb에 가장 적합합니다.

이 가이드의 다음 섹션에서는 이러한 모범 사례와 JD Edwards EnterpriseOne에 SQL Server를 최적화하기 위한 기타 모범 사례를 살펴봅니다.