Início / dba / Perguntas / 18648
Accepted
syneticon-dj
Asked: 2012-06-01 10:37:58 +0800 CST

sqlcmd lento em relação ao SQL Server 2008 R2

  • 772

Estou tentando importar um script SQL longo (3,5 milhões de linhas, 1,5 GB de tamanho) contendo principalmente instruções INSERT INTO curtas com dados usando sqlcmd -E -d <database> -S 127.0.0.1 -i <scriptfile>e está quase parando (aproximadamente 150 linhas por segundo) sem inferir qualquer perceptível carga no host do servidor SQL (todos os núcleos da CPU estão quase ociosos, a taxa de transferência do disco é de cerca de 200 KB/s).

Como o arquivo de origem está localizado em um compartilhamento NFS, primeiro suspeitei que esse fosse o culpado, mas um script idêntico disponível localmente é executado na mesma velocidade.

O banco de dados está basicamente vazio, as tabelas são criadas pelo mesmo script, sem gatilhos ou outras fantasias - apenas os dados brutos, principalmente numéricos ou varchar.

O que o SQLCMD está esperando? Existe alguma maneira de agilizar?

Editar:

estamos limitados em nossos meios para alterar os dados nos arquivos de script SQL. Os dados são fornecidos por um terceiro para um procedimento de importação. Acredito que foi exportado originalmente usando o recurso "Tabela de script como..." do Management Studio 2005.

Editar o arquivo é tedioso devido ao tamanho - qualquer operação leva uma eternidade com editores de texto comuns, embora o prefixo "SET NOCOUNT ON" tenha sido feito copiando dois arquivos juntos - e trouxe uma aceleração de aproximadamente 50%.

Devido à codificação de texto (Unicode-LE), é impossível editar com o conjunto comum de textutils GNU (que de outra forma funcionaria bem com arquivos grandes) sem converter - e estou relutante em converter devido a problemas de fidelidade de dados que provavelmente venha com ele.

Portanto, estou um pouco preso em como aplicar as sugestões sobre como inserir os blocos BEGIN TRAN/COMMIT TRAN ou converter as inserções individuais em conjuntos maiores.

sql-server-2008 insert

1 respostas

  1. Best Answer

    Algumas ideias:

    • Injete alguns GOcomandos a cada mil ou alguns milhares de linhas. Então, em vez de um lote gigantesco, ele é dividido em vários lotes.
    • Altere suas INSERTdeclarações individuais para INSERT ... VALUES ()mil conjuntos cada.
    • Use transações e commit e/ou ponto de verificação gratuitamente (novamente, a cada 1.000 inserções ou mais é provavelmente um bom lugar para começar, em combinação com GO). Seu relógio e o registro agradecerão.
    • É uma coisinha boba e trivial, mas certifique-se de que seu script tenha SET NOCOUNT ON- caso contrário, a interface do usuário, o SQL Server e a rede entre eles gastam muito tempo enviando 1 row(s) affectedmensagens para frente e para trás para cada inserção.
    • O melhor é provavelmente usar BULK INSERT , BCP ou talvez até SSIS em vez do Management Studio. Parte do problema é provavelmente a sobrecarga de memória em sua própria máquina apenas carregando aquele arquivo enorme, não importa tentar analisá-lo/executá-lo. Eu ficaria curioso para ver bytes privados para ssms.exe enquanto isso está acontecendo ...
    • Com base na discussão offline com o OP, adicionamos outra opção: peça ao fornecedor um backup em vez de um script. Em seguida, você pode restaurá-lo para algum sistema de teste ou fictício e gerar inserções manualmente (ou usar importação/exportação ou a ferramenta de comparação de dados do Red Gate). Isso pode acabar levando a mesma quantidade de tempo, mas não vai matar o log com aquele script enorme de milhões de inserções ...
    • 12

relate perguntas