Início / dba / Perguntas / 154203
Accepted
Jason
Asked: 2016-11-04 13:33:56 +0800 CST

Atualização de valor eficiente com banco de dados grande

  • 772

Eu tenho uma tabela tão grande quanto 8 GB e com 20 milhões de registros. Existe um campo int chamado mth. O campo mth armazena informações de data na forma de AAAAMM, desejo transformar o campo mth em inteiros consecutivos. Então eu uso uma fórmula para pegar o ano e o mês do campo mth e calcular a ordem do mês, especificamente, eu uso o seguinte código:

create function mth_to_num(@month int)
returns int
as 
begin
   return(round(@month/100,0)*12+@month-100*round(@month/100,0))
end

Então eu uso o seguinte código para atualizar o valor na tabela enorme

update full_orig_month_Q1_1999 
set mth_order = dbo.mth_to_num(period)
Go

No entanto, o código demorou muito para ser executado, cerca de 2 a 3 minutos. Meu sistema é windows 10 64 bits com SQL Server 2016. Existe alguma maneira de acelerar?

Outro problema é que encontrei o SQL Server ocupando até 8 GB no banco de dados após executar a consulta acima. Precisa de tanta memória? Como posso libertá-los?

Obrigado por sua ajuda com antecedência!

jasão

sql-server performance

2 respostas

  1. Best Answer

    Quando possível, não use funções escalares definidas pelo usuário (UDF) em consultas. Eles forçam todo o plano a ser serial, podem fazer com que muitos recursos adicionais da CPU sejam usados, são uma caixa preta para o otimizador e podem levar a problemas de estimativa de cardinalidade em outras partes do plano e podem resultar em grandes concessões de memória.

    Tente executar sua consulta UPDATE sem o UDF. Basta pegar o código que você possui e colocá-lo diretamente na consulta UPDATE. Algo assim:

    update full_orig_month_Q1_1999 
set mth_order = round(period/100,0)*12+period-100*round(period/100,0);

    Isso melhora o tempo de execução e o uso de memória?

    • 5

  2. Você pode tentar usar o script de Paul Randall para capturar as estatísticas de espera que ocorrem durante a execução do seu script.

    Com base nos resultados retornados, você pode pesquisar os principais tipos de espera e interpretar os problemas de desempenho.

    Os resultados da amostra podem ter esta aparência:

    WaitType    Wait_S  Resource_S  Signal_S    WaitCount   Percentage  AvgWait_S   AvgRes_S    AvgSig_S
ASYNC_NETWORK_IO    0.00    0.00    0.00    2   100.00  0.0005  0.0005  0.0000

    A pesquisa por ASYNC_NETWORK_IO revelaria, por exemplo:

    Esse tipo de espera é onde o SQL Server enviou alguns dados para um cliente por meio do TDS e está aguardando que o cliente reconheça que consumiu os dados e também pode aparecer com a replicação da transação se o trabalho do Log Reader Agent estiver sendo executado lentamente por alguns razão. (Descrição do Books Online: “Ocorre em gravações de rede quando a tarefa é bloqueada atrás da rede. Verifique se o cliente está processando dados do servidor.”)

    Em resposta ao seu comentário:

    Os sites de Paul Randall e Brent Ozar são bons pontos de partida para ajuste e otimização de desempenho. E ainda acho que os Manuais Online do SQL Server 2008 R2 (que ainda podem ser baixados ) contêm muitas informações sobre os componentes internos do banco de dados, embora algumas delas estejam desatualizadas.

    Aaron Bertrand tem boas informações sobre ajuste de desempenho e muitas outras pessoas também.

    • 0

relate perguntas