Rick's questions

Eu estava tentando restaurar meu banco de dados e o SQL Server continuava travando. Eu receberia uma mensagem no SSMS que dizia que havia um erro de transporte de rede (a conexão caiu devido à falha). Verifiquei os logs e não encontrei nada além do SQL Server fechado inesperadamente. Eu teria então que ir e reiniciar o serviço.

Eu reduzi o problema ao script que a GUI estava tentando executar. O problema é que quando ele vai fazer um backup do tail log, o caminho para os arquivos de backup está errado. Deveria serD:\mapbenefits\...

BACKUP LOG [mapbenefits]
TO  DISK = N'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak'
WITH NOFORMAT, NOINIT,  NAME = N'mapbenefits_LogBackup_2019-02-21_13-58-24',
    NOSKIP, NOREWIND, NOUNLOAD,  NORECOVERY ,  STATS = 5

Eu tenho duas perguntas.

1. Como faço para corrigir esse caminho? Eu tentei entrar nas configurações do servidor e o caminho de backup está D:sem barra. Se eu adicionar a barra, o gui a remove. Este é o SSMS v17.9.1. Eu posso escolher D:\mapbenefits\e isso funciona, mas eu queroD:\DATABASE\...

2. Isso é um inseto? O servidor SQL deve travar apenas porque um caminho foi digitado incorretamente? Depois de corrigir o caminho do arquivo, não há problemas. Eu posso reproduzir a qualquer momento apenas bagunçando o caminho do arquivo.

Se eu executar uma consulta para verificar a versão, recebo CU13, mas se eu entrar nas configurações, vejo a versão 14.0.1000.169.

Parece que isso é um bug e é reproduzível, então eu postei aqui: https://feedback.azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-filepath-with-backup-log-command- causas

Então, estou ajustando essa consulta e tenho certeza de que, nesse caso, posso substituir uma junção interna por uma junção esquerda sem afetar os dados. No entanto, não sei ao certo por que isso é mais rápido. Aqui está a consulta:

SELECT DISTINCT  cl.NAME                            AS company_name,
                     cl.id                              AS company_id,
                     ep.Plan__c                           AS plan_id,
                     ep.Employee__c,
                     ep.id,
                     do.Subcategory__c,
                     ep.Plan_Type__c,
                     pt.SubType,
                     Sum((pt.[shares] * fvh.[ValuePerShare])) AS TotalValue,
                     ppe.Deferral_Option__c,
                     dt.Defer_type_Code,
                     do.Short_Code__c,
                     pt.ContributionYear
  FROM   dbo.ParticipantTrades pt WITH (NOLOCK) 
        INNER JOIN dbo.PayoutPathElection ppe WITH (NOLOCK) 
                ON pt.payoutPathElectionID = ppe.Id 
        INNER JOIN dbo.DeferralOption do WITH (NOLOCK) 
                ON ppe.Deferral_Option__c = do.id 
        INNER JOIN dbo.EmployeePlan ep WITH (NOLOCK) 
                ON pt.employeePlan = ep.Id 
        LEFT JOIN dbo.DeferralType dt WITH (NOLOCK) 
                ON pt.deferralType = dt.defID
        INNER JOIN dbo.Fnc_lastfundvalue('2019-01-30') AS fvh 
                ON pt.fund = fvh.Fund
        INNER JOIN dbo.Clients cl with (NOLOCK)
                ON ep.Company__c = cl.Id
  WHERE ep.Company__c = '0017000001WL1HfAAL' AND ep.Plan_Type__c  LIKE '%' AND pt.tradeDate <= '2019-01-30'
  Group by   cl.NAME,
             cl.id,
             ep.Plan__c,
             ep.Employee__c,
             ep.id,
             do.Subcategory__c,
             ep.Plan_Type__c,
             pt.SubType,
             ppe.Deferral_Option__c,
             dt.Defer_type_Code,
             do.Short_Code__c,
             pt.ContributionYear

O gargalo está na junção da função de valor da tabela (Fnc_lastfundvalue). Meu palpite de por que alterá-lo para uma junção à esquerda é mais rápido é que ele pode reordenar as junções e causa menos derramamento no tempdb? Aqui está o plano de consulta antes e depois de alterar INNER JOIN dbo.Fnc_lastfundvalue.. para LEFT JOIN dbo.Fnc_lastfundvalue..

Antes (29 segundos): https://www.brentozar.com/pastetheplan/?id=Bk1Y-WqEE

Depois (3 segundos): https://www.brentozar.com/pastetheplan/?id=B1hoW-544

NB: Os planos de execução acima são criados em uma caixa de desenvolvimento. O servidor de produção ainda está no SQL Server 2008.