Atenção: Este documento está sendo elaborado e suas informações ainda estão sendo revisadas. Não o utilize como referência até o momento de sua publicação.
No banco de dados do Protheus, as seguintes opções devem estar habilitadas:
|
A atualização de estatísticas é uma das manutenções que deve ser feita no banco de dados. Para tal, realizamos diversos testes de estresse para identificar pontos que possam ser ofensores na performance do Protheus.
Para os testes, utilizamos o banco de dados SQL Server 2019 com uma ferramenta para testes de estresse desenvolvida pela Engenharia de Dados Protheus. Também utilizamos o dicionário padrão do Protheus 12.1.27, com dicionário no banco de dados. Os quatro processos utilizados no teste foram: Pedido de venda, documentos de entrada, movimentações internas e produtos.
As tabelas preenchidas foram: SA1 (Clientes), SA2 (Fornecedores), SB1 (Produtos), SF1 (Documentos de entrada), SF2 (Documentos de saída), SD3 (Movimentos internos) e a SE1 (Títulos a receber).
Quando realizamos uma query no banco de dados, o SGBD procura trazer os dados da forma mais rápida possível. O SQL Server Query Optmizer realiza uma análise, verifica se existe um plano e se o mesmo precisa ser atualizado. Se não houver, ele criará um novo plano de acordo com a query. Podemos chamar o plano de consulta de caminho mais rápido para chegar à informação desejada, e para isso ele utiliza dois fatores principais.
O primeiro fator é a cardinalidade que, em resumo, significa a quantidade de linhas que serão acessadas pela query. O segundo fator são os operadores usados na query que mudam, e muito, o plano de execução.
Realizamos uma consulta de exemplo em uma base de testes, na tabela SD3990, que possuía 1 milhão de registros.
SELECT SD3.* FROM SD3990 SD3 where SD3.D3_DOC >= '000648000' AND SD3.D3_DOC <= '000648050'; |
Não utilize consultas com * em bases de produção ou em fontes customizados, pois isto impacta a performance da aplicação. Este é apenas um exemplo executado em uma base de testes. |
Essa query demorou 1503 ms. Analisando o plano de execução, o SQL Server nos indica a criação de um índice:
Porém, a criação do índice não irá resolver a situação. Esta criação até pode melhorar a situação da query naquele momento, mas criar um índice é indicado somente em último caso, se a query for utilizada de forma recorrente e não houver outra possibilidade de melhorá-la.
Criar muitos índices no banco de dados pode gerar lentidão nas rotinas de Insert, Update e Delete. |
No exemplo acima, o próprio SQL Server dá um alerta no Clustered Index Scan:
Ao analisar o alerta, temos o seguinte:
Neste Warning, o SQL Server indica a falta de estatística no campo D3_DOC.
Habilitamos o parâmetro Auto Create Statistics na base de dados analisada. Este parâmetro pode ser habilitado nas propriedades do banco de dados, na aba Options. O alteramos de FALSE para TRUE:
Ou por linha de comando:
USE [master] go ALTER DATABASE [statistic_teste3] SET auto_create_statistics ON go |
| OBS: altere o “statistic_teste3” para o nome do seu banco de dados. |
Após alterar o parâmetro, executamos novamente a query. É possível ver a alteração no plano de execução do SQL Server: agora, ele começa a utilizar índices já existentes no banco de dados, sem solicitar a criação de um novo índice:
Ao comparar o tempo da execução após habilitar este parâmetro, verificamos a redução do tempo de 1489 ms para 274 ms, uma redução de aproximadamente 81,6% no tempo da execução.
O percentual apresentado neste documento é referente às condições específicas do teste, com fatores que englobam a versão do banco de dados, a quantidade de registros na base de dados, os índices já existentes. Este valor não é fixo, e pode variar de acordo com as configurações de seu ambiente. |
Com o seguinte DBCC, é possível verificar a criação de uma nova estatística logo após executarmos a query de exemplo. Ela foi criada pelo SQL Server automaticamente, e demorou alguns milissegundos para ser criada.
DBCC SHOW_STATISTICS (SD3990, D3_DOC) |
Estatística criada:
