Início / dba / Perguntas / 114573
Accepted
eddie_cat
Asked: 2015-09-10 05:32:32 +0800 CST

Procedimento armazenado de repente muito lento, atualizando as estatísticas não ajudando

  • 772

Como diz o título, tenho um procedimento armazenado que de repente começou a ser executado muito lentamente. Anteriormente, levava cerca de 5 segundos para ser executado, agora leva sete minutos ou mais. Isso parece ter começado quando alterei o procedimento, mas a alteração que fiz não deveria ter afetado o desempenho, pois tudo o que fiz foi alterar o alias em duas colunas que estão sendo retornadas. Não tenho certeza se alterar o procedimento realmente causou isso, no entanto, porque um procedimento semelhante que também costumava ser muito rápido está tendo os mesmos problemas.

Tentei atualizar as estatísticas nas tabelas relevantes e não ajudou. Eu tive esse mesmo problema na semana passada e consegui consertá-lo fazendo isso, mas agora é impossível. Também tentei usar with recompilesem sucesso e excluí o procedimento e o adicionei novamente.

Esta é a linha que está demorando muito mais do que antes:

select PK_ShipDataSubsystemConfigID
,timestamp
,cast((
        select top 1 Longitude
        from [RemoteServer].[dbo].[Ships].LocationAttributes la
        inner join [RemoteServer].[dbo].[Ships].Locations l on l.ShipLocationId = la.ShipLocationId
        where l.SampleDateTime <= timestamp
            and l.SampleDateTime <= @ToDT
            and ShipId = @ShipId
        order by SampleDateTime desc
        ) as varchar(20)) as Longitude
,'Vessel Position Lng'
from FuelCalc
inner join ShipDataSubsystemConfig s on s.PK_ShipDataSubsystemConfigID =       FuelCalc.FK_ShipDataSubsystemConfigId
where timestamp > @FromDT
and timestamp < @ToDT
and FuelCalc.FK_ShipId = @ShipId
order by timestamp desc

A execução da seleção interna sozinha agora leva pelo menos 2 segundos, para que eu possa entender por que todo o procedimento está demorando tanto. Eu estou querendo saber se tem algo a ver com ser uma chamada para um servidor vinculado. Tentei criar uma view juntando as tabelas Locations e LocationAttributes para ver se fazia diferença, mas não deu.

Alguma ideia? Perguntei aos meus colegas de trabalho e eles estão apenas dizendo que preciso escrever uma consulta mais eficiente (o que pode ser verdade), mas realmente não acho que isso esteja causando meu problema específico, visto que estava funcionando bem até que de repente não estava . Eu olhei para o plano de execução, mas tudo o que diz é que a consulta remota está demorando 100% do tempo, mas não mostra o plano com mais detalhes do que isso.

sql-server t-sql

1 respostas

  1. Best Answer

    Sugiro que você crie uma tabela temporária ou use uma expressão de tabela comum para obter a lista de todas as longitudes necessárias de seu servidor remoto e use a nova tabela temporária ou expressão de tabela comum para junção interna com sua tabela FuelCalc.

    Algo como abaixo.

    WITH CTE as 
(
select Longitude, MAX(SampleDateTime) as SampleDateTime, ShipLocationId, SHIPiD
        from [RemoteServer].[dbo].[Ships].LocationAttributes la
        inner join [RemoteServer].[dbo].[Ships].Locations l on l.ShipLocationId = la.ShipLocationId
        where l.SampleDateTime <= timestamp
            and l.SampleDateTime <= @ToDT
            and ShipId = @ShipId
        GROUP BY Longitude
)
select PK_ShipDataSubsystemConfigID
,timestamp
,cte.Longitude
,'Vessel Position Lng'
from FuelCalc
inner join ShipDataSubsystemConfig s on s.PK_ShipDataSubsystemConfigID =       FuelCalc.FK_ShipDataSubsystemConfigId
left outer join cte on cte.SHIPiD = FK_ShipId
where timestamp > @FromDT
and timestamp < @ToDT
and FuelCalc.FK_ShipId = @ShipId
order by timestamp desc
    • 3

relate perguntas