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 comportamento do JD Edwards EnterpriseOne no SQL Server
A lógica de negócios do EnterpriseOne é tratada principalmente nas aplicações. 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 o EnterpriseOne tende a ser mínimo, enquanto as características de E/S de rede e disco são os principais fatores da performance do processo. O ajuste do banco de dados do EnterpriseOne se concentra fortemente na minimização da latência da 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 essa abordagem é usada com o 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 processo do EnterpriseOne gera um grande número de operações de gravação comunicativas, a performance pode ser limitada 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 processos do EnterpriseOne criam conjuntos de registros que podem se sobrepor a outros conjuntos de registros abertos, habilite o isolamento de snapshots com confirmação de leitura (RCSI) em cada banco de dados do EnterpriseOne 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 em memória não volátil expressa (NVMe) na instância local é a melhor opção para o tempdb.
As seções a seguir deste guia exploram essas e outras práticas recomendadas para otimizar o SQL Server para JD Edwards EnterpriseOne.
