Visão geral do EnterpriseOne comportamento do JD Edwards no SQL Server - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Visão geral do EnterpriseOne comportamento do JD Edwards no SQL Server

EnterpriseOne a lógica de negócios é tratada principalmente em aplicativos. Somente instruções em linguagem de manipulação de dados (DML) básicas são passadas da aplicação para o banco de dados. No processamento padrão, o conjunto de registros é aberto no banco de dados, mas é gerenciado pela aplicação. Em seguida, a aplicação normalmente executa várias operações de DML para cada registro no conjunto de registros. Essa abordagem gera um volume substancial de operações de DML comunicativas no banco de dados. A latência de cada operação de DML é um dos principais fatores influenciadores da performance. Devido a essa arquitetura, o uso da CPU do banco de dados que suporta EnterpriseOne tende a ser mínimo, enquanto as características de E/S de rede e disco são os principais fatores do desempenho do processo. EnterpriseOne o ajuste do banco de dados se concentra fortemente na minimização da latência do DML.

Para mitigar o impacto da latência da E/S de leitura do disco, um grande cache de buffer geralmente é usado. Isso pode ser combinado com a compactação de dados do SQL Server para tornar o cache de buffer substancialmente mais eficaz. Embora o uso da compactação de dados afete a CPU, a sobrecarga é mínima quando você usa essa abordagem com EnterpriseOne. Quando o cache do buffer é dimensionado adequadamente, a latência de E/S de leitura do disco normalmente não é uma preocupação.

O cache de buffer do SQL Server não aborda a latência da E/S de gravação. Quando um EnterpriseOne processo gera um grande número de operações de gravação falantes, o desempenho pode ser limitado pela latência de cada operação de gravação que é confirmada no log de transações. Para minimizar essa latência, é possível usar volumes io2 e/ou io2 Block Express para o arquivo LDF. Se o io2 ou io2 Block Express sozinho for insuficiente para fornecer a performance necessária ou seu custo for proibitivo, você poderá usar uma configuração de durabilidade atrasada para melhorar a performance.

Como muitos EnterpriseOne processos criam conjuntos de registros que podem se sobrepor a outros conjuntos de registros abertos, você deve habilitar o isolamento de snapshot confirmado com leitura (RCSI) em cada EnterpriseOne banco de dados para minimizar o bloqueio. Quando esse recurso está habilitado, ele pode criar um requisito substancial de E/S para o tempdb. O tempdb é, por natureza, efêmero e não exige a durabilidade do armazenamento em bloco padrão. Na maioria dos casos, o armazenamento express (NVMe) de memória não volátil de instância local é a melhor opção para. tempdb

As seções a seguir deste guia exploram essas e outras práticas recomendadas para otimizar o SQL Server para JD Edwards. EnterpriseOne