Não é possível buscar uma linha do provedor OLE DB "SQLNCLI11" para o servidor vinculado

Eu tenho dois SQL Servers em duas máquinas diferentes em algum lugar na nuvem (talvez Azure).

Um deles é o Microsoft SQL Server 2012 (SP3-CU10) (KB4025925) - 11.0.6607.3 (X64) 8 de julho de 2017 16:43:40 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows NT 6.3 (Build 9600: ) (Hipervisor)

Neste servidor existe um link para o segundo servidor.

O segundo servidor ( aae-sqldw-02) é o Microsoft SQL Server 2016 (SP1-CU15-GDR) (KB4505221) - 13.0.4604.0 (X64) 15 de junho de 2019 07:56:34 Copyright (c) Microsoft Corporation Enterprise Edition: licenciamento baseado em núcleo (64 -bit) no Windows Server 2016 Datacenter 10.0 (Build 14393: ) (Hypervisor)

No primeiro servidor estamos executando uma consulta "simples":

TRUNCATE TABLE [dbo].[LocalTable]

INSERT INTO [dbo].[LocalTable]
    ([DatabaseName]
    ,[SalesContractNumber]
    ,... 60 columns
    )
SELECT
    convert(varchar(128), DatabaseName) collate Latin1_General_CI_AS
    ,convert(varchar(60), SalesContractNumber) collate Latin1_General_CI_AS
    ,... 60 columns
FROM [aae-sqldw-02].[Fin_DWH].[dbo].[RemoteView]
WHERE DatabaseName = 'somename'

Esta consulta às vezes falha com um erro:

Cannot fetch a row from OLE DB provider "SQLNCLI11" for linked server "aae-sqldw-02".

ou com este erro:

Cannot fetch the rowset from OLE DB provider "SQLNCLI11" for linked server "aae-sqldw-02". .

Eu sei que o segundo servidor está sob uma carga muito pesada a maior parte do dia. Ele literalmente maximiza sua E/S de disco (255 MB/s). A solução de força bruta é simplesmente movê-lo para um plano mais caro com mais IO. Essa mudança precisa de muita burocracia e levará muito tempo. Além disso, não há garantia de que o próximo nível será suficiente.

Existe alguma coisa que eu possa fazer com os recursos fornecidos agora?

Quando uma consulta é concluída com êxito, pode levar de 1 a 3 horas. A consulta retorna cerca de 3 milhões de linhas, cerca de 4 GB de dados, portanto, não muito.

Quando uma consulta falha com Cannot fetch a row, nas últimas vezes ela falhou após 9.294 segundos (2,5 horas), 12.326 segundos (3,5 horas).

Quando uma consulta falha com Cannot fetch the rowset, ela falhou após 606 segundos, 611 segundos.

Portanto, 600 segundos sugerem algum tempo limite padrão de 10 minutos (para conexão?) Nos casos em que a conexão foi bem-sucedida, ela começou a buscar os dados, mas falhou no processo. Talvez o servidor vinculado não tenha conseguido enviar a próxima linha com rapidez suficiente e algum outro tempo limite foi ativado.

Quando uma consulta foi bem-sucedida, levou 3841 segundos da última vez.

Aqui estão as configurações para o servidor vinculado:

EXEC master.dbo.sp_addlinkedserver @server = N'aae-sqldw-02', @srvproduct=N'SQL Server'
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'aae-sqldw-02',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
GO

EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'collation compatible', @optvalue=N'false'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'data access', @optvalue=N'true'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'dist', @optvalue=N'false'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'pub', @optvalue=N'false'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'rpc', @optvalue=N'true'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'rpc out', @optvalue=N'true'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'sub', @optvalue=N'false'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'connect timeout', @optvalue=N'0'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'collation name', @optvalue=null
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'lazy schema validation', @optvalue=N'false'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'query timeout', @optvalue=N'0'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'use remote collation', @optvalue=N'true'
EXEC master.dbo.sp_serveroption @server=N'aae-sqldw-02', @optname=N'remote proc transaction promotion', @optvalue=N'true'

O que você acha, faria alguma diferença se eu definir explicitamente a query timeoutopção para algo como 5 horas? Pode piorar as coisas?

Obviamente, a correção adequada seria observar o que está acontecendo no servidor e otimizar as consultas para reduzir a carga geral, mas há algo que eu possa fazer em um nível de servidor / banco de dados mais alto, para que a consulta seja concluída, mesmo que leva muito tempo?

Precisamos executar essa consulta uma vez por semana e agora temos que tentar novamente várias vezes até que ela seja concluída com sucesso.