Início / dba / Perguntas / 165761
Accepted
nateirvin
Asked: 2017-03-01 10:30:14 +0800 CST

Por que INSERT INTO ... SELECT não está copiando todas as linhas?

  • 772

Eu tenho dois servidores, SERVER-01 e SERVER-00 (não são seus nomes reais). SERVER-00 é uma instância do SQL Server 2005 Standard, SERVER-01 é uma instância do SQL Server 2014 Standard. Eu tenho essa consulta que é executada em um SQL Agent Job todas as noites no SERVER-00:

truncate table DataWarehouse.dbo.documents
set identity_insert DataWarehouse.dbo.documents ON

INSERT INTO [DataWarehouse].[dbo].[documents]
    (
     [documentID]          
    ,[poNumber]
    ,[soldTo]
    ,[shipTo]
    )
SELECT 
     [documentID]
    ,[poNumber]
    ,[soldTo]
    ,[shipTo]      
FROM [server-01].[DataWarehouse].[dbo].[documents]

set identity_insert DataWarehouse.dbo.documents OFF

(A consulta real inclui mais colunas, eu a cortei para facilitar a leitura.)

No SERVER-01, documentsé uma view. No SERVER-00, documentsé uma tabela. Nesta consulta [server-01]há uma conexão de servidor vinculada no SERVER-00 (usa as credenciais de um sysadmin para se conectar ao SERVER-01).

Apenas cerca de metade das linhas estão sendo inseridas documentsno SERVER-00. Não há mensagens de erro ou avisos sendo registrados pelo trabalho - ele sempre é bem-sucedido. Como diabos isso pode estar acontecendo?

sql-server linked-server

3 respostas

  1. Best Answer

    Acontece que o culpado era nosso velho amigo ARITHABORT!

    Na view documents, poNumberé na verdade a saída de uma chamada de função escalar. Uma das entradas era um BIGINT que eu estava tentando passar para um parâmetro INT, então um erro de estouro estava sendo gerado para algumas linhas. Como a conexão do servidor vinculado do SERVER-00 ao SERVER-01 estava deixando ARITHABORTindefinida (e, portanto, OFF), o erro estava sendo engolido, então eu não o estava vendo ao executar a consulta desse lado.

    Depois de corrigir o problema com a função (expandido o parâmetro para ser um BIGINT), todas as linhas começaram a ser copiadas corretamente!

    Para referência, confirmei as opções da conexão do servidor vinculado executando esta consulta no SERVER-00:

    SELECT * 
FROM OPENQUERY([SERVER-01], '
    SELECT 
        CASE WHEN SESSIONPROPERTY(''ARITHABORT'') = 1 
        THEN ''ON'' 
        ELSE ''OFF'' 
        END AS [ARITHABORT]
')
    • 3

  2. parece que uma possibilidade pode ser o tempo limite, então fornecerei uma possível solução/dicas de solução de problemas com base nessa premissa.

    Verifique as propriedades do servidor (no Pesquisador de Objetos, clique com o botão direito do mouse em seu objeto de instância --> propriedades) na página de conexões e observe o número do Tempo Limite da Consulta Remota.

    Além disso, os Servidores Vinculados têm suas próprias conexões e propriedades de consulta (expanda seu objeto de instância --> Objetos de Servidor e clique com o botão direito em Servidores Vinculados --> Propriedades. Na página Opções do Servidor, verifique os valores de tempo limite de conexão e tempo limite de consulta. (Confira https://technet.microsoft.com/en-us/library/ms186839(v=sql.105).aspx para obter informações sobre as propriedades do servidor vinculado).

    Se algum dos três valores acima corresponder à hora em que sua consulta cair, você provavelmente precisará alterá-los.

    Se você estiver executando a consulta como um trabalho do SQL Server Agent, eu examinaria o histórico do trabalho para ver se a duração corresponde ao tempo limite.

    Isso deve lhe dar um começo para pelo menos verificar a possibilidade de ser um tempo limite.

    • 0

  3. Versões mais antigas do SQL 2005 têm vários bugs de servidor vinculados. Você está na versão mais recente?

    A tabela de destino tem IGNORE_DUP_KEY habilitado na chave primária? Isso pode fazer com que pareça 'soltar' linhas.

    Você tem certeza de que os dados de origem são COMMITTED antes da execução do trabalho do agente? Porque os níveis de isolamento podem torná-lo indisponível até então.

    • 0

relate perguntas