Zane's questions

Ok, então eu tenho condensado arquivos de alguns arquivos minúsculos e os movendo para um FG que criei para essas tabelas diversas. Estou movendo essas tabelas recriando os índices com a WITH (DROP_EXISTING = ON)opção e tem funcionado muito bem. No entanto, esta última vez, deu-me um erro. Aqui está o script que estou executando

CREATE Unique CLUSTERED INDEX PK_MyTable 
    ON dbo.MyTable (MyTableID, RowStatus)  
    WITH (DROP_EXISTING = ON)  
    ON FG_Misc; 

Quando executo isso, recebo a seguinte mensagem de erro.

Msg 1902, Nível 16, Estado 3, Linha 1

Não é possível criar mais de um índice clusterizado na tabela 'dbo.MyTable'. Elimine o índice clusterizado existente PK_MyTable' antes de criar outro.

Não vejo nenhum motivo pelo qual isso esteja lançando esse erro nesta tabela em particular, mas não em outras nas quais estou trabalhando.

Portanto, tenho um trabalho básico de agente SQL que executa um script Robocopy para mover todos os arquivos de uma pasta para outra.

Job é uma configuração bastante básica.

Com uma programação bem básica.

E, no entanto, ainda não foi executado. Não quero dizer executar com sucesso, quero dizer executar. Existe alguma razão para este ser o caso?

Para obter informações adicionais, também criarei o script do trabalho.

USE [msdb]
GO

/****** Object:  Job [MoveMantisFilesToArchive]    Script Date: 12/23/2015 10:21:52 AM ******/
BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
/****** Object:  JobCategory [[Uncategorized (Local)]]]    Script Date: 12/23/2015 10:21:52 AM ******/
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
EXEC @ReturnCode =  msdb.dbo.sp_add_job @job_name=N'MoveMantisFilesToArchive', 
        @enabled=1, 
        @notify_level_eventlog=0, 
        @notify_level_email=2, 
        @notify_level_netsend=0, 
        @notify_level_page=0, 
        @delete_level=0, 
        @description=N'Moves Mantis files to archive. It''s a very descriptive title.', 
        @category_name=N'[Uncategorized (Local)]', 
        @owner_login_name=N'sa', 
        @notify_email_operator_name=N'MyEmailGroup', @job_id = @jobId OUTPUT
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
/****** Object:  Step [Move the files in the afformentioned title.]    Script Date: 12/23/2015 10:21:53 AM ******/
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Move the files in the afformentioned title.', 
        @step_id=1, 
        @cmdexec_success_code=0, 
        @on_success_action=1, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'CmdExec', 
        @command=N'robocopy MySoruce MyDestination /mov', 
        @flags=0, 
        @proxy_name=N'RunsAs'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule @job_id=@jobId, @name=N'M-F', 
        @enabled=1, 
        @freq_type=8, 
        @freq_interval=62, 
        @freq_subday_type=1, 
        @freq_subday_interval=0, 
        @freq_relative_interval=0, 
        @freq_recurrence_factor=1, 
        @active_start_date=20151218, 
        @active_end_date=99991231, 
        @active_start_time=170000, 
        @active_end_time=235959, 
        @schedule_uid=N'bcb83273-19e8-49fb-a456-8517642370e3'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
    IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:

GO

Então, eu tenho essa consulta que estou tentando ajustar e estou enfrentando um problema que estou tendo problemas para entender. A primeira é a consulta que estou usando.

SELECT  
    si.LoanNbr AS [LoanNumber],
    fi.[SvcClientNbr] AS ClientID,
    si.LoanMasterID,
    si.LoanSrcCode AS [LoanSourceCode],
    fi.LoanPurpCode,
    fi.[PropState] AS [Property State],
    im.ImagedocumentID AS [Image Document ID],
    -- im.requestID AS [Request ID],
    CONVERT(VARCHAR(10),im.[ImageDate],101) AS ImageDate,
    im.[PageCount],
    im.[SignatureInd]
FROM dbo.NotMybaseTable Si
INNER JOIN dbo.NotMyTableName fi
    ON si.LoanMasterID = fi.LoanMasterID
INNER JOIN [dbo].[ImagedDocument] im
    ON si.loanmasterid = im.loanmasterid
    AND im.[DocTypeCode] = '10112'
WHERE CASE WHEN si.loansrccode = 'CORE' AND  Im.[SignatureInd] IN ('Y') THEN 1
        WHEN si.FundingSysCode = 'LIS' and CASE WHEN si.loansrccode = 'CORE' THEN 0 ELSE 1 END = 1 THEN 1
    ELSE 0 END = 1
    AND [ImageDate] BETWEEN DATEADD(WK, DATEDIFF(WK, 0, GETDATE()) - 4, -30) AND DATEADD(WK, DATEDIFF(WK, 0, GETDATE()) - 4, 0) + 5

Quando executo esta consulta, o plano de execução que recebo é assim.

Portanto, a consulta está fazendo uma varredura muito grande nessa tabela grande, retornando 30 milhões de linhas apenas para reduzi-la a 3K. O índice que está usando se parece com isso.

CREATE NONCLUSTERED INDEX [IX_ImageDoc_DocType] ON [dbo].[ImageDoc]
(
    [LoanMasterID] ASC,
    [ImageDate] ASC,
    [ImageDocType] ASC
)

Alterei a consulta de uma maneira que oferece um desempenho muito melhor, movendo a parte da data do predicado para fora da consulta inicial dessa maneira.

select
    *
from (
    SELECT  
        si.LoanNbr AS [LoanNumber],
        fi.[SvcClientNbr] AS ClientID,
        si.LoanMasterID,
        si.LoanSrcCode AS [LoanSourceCode],
        fi.LoanPurpCode,
        fi.[PropState] AS [Property State],
        im.ImagedocumentID AS [Image Document ID],
        CONVERT(VARCHAR(10),im.[ImageDate],101) AS ImageDate,
        im.[PageCount],
        im.[SignatureInd]  
    FROM dbo.NotMybaseTable Si
    INNER JOIN dbo.NotMyTableName fi
      ON si.LoanMasterID = fi.LoanMasterID
    INNER JOIN [dbo].[ImagedDocument] im
      ON si.loanmasterid = im.loanmasterid
      AND im.[DocTypeCode] = '10112'
    WHERE CASE WHEN si.loansrccode = 'CORE' AND  Im.[SignatureInd] IN ('Y') THEN 1
            WHEN si.FundingSysCode = 'LIS' and CASE WHEN si.loansrccode = 'CORE' THEN 0 ELSE 1 END = 1 THEN 1
        ELSE 0 END = 1
        ) as F
WHERE [ImageDate] BETWEEN DATEADD(WK, DATEDIFF(WK, 0, GETDATE()) - 4, -30) AND DATEADD(WK, DATEDIFF(WK, 0, GETDATE()) - 4, 0) + 5

Isso resultou em um desempenho muito melhor e um plano de consulta obviamente superior.

O índice que está digitalizando agora se parece com isso.

CREATE NONCLUSTERED INDEX [IX_ImageLoanDoc_SystemName_ICMPDocTypeCode] ON [dbo].[ImageDoc]
(
    [SystemName] ASC,
    [ICMPDocTypeCode] ASC,
    [LoanMasterID] ASC,
    [ImageDate] ASC
)
INCLUDE (   [ImageDocumentID],
    [ImageDocType],
    [BatchName],
    [SignatureInd],
    [ICMPDocCategoryCode],
    [ICMPDocSubTypeCode])

Então aqui está a minha pergunta. Com ImageDate estando neste índice, por que tê-lo em minha consulta prejudica tanto o desempenho? A inclusão desse predicado não deveria facilitar a eliminação de linhas? O que estou fazendo/pensando incorretamente?

Eu tenho um pacote SSIS que está fazendo uma SELECTdeclaração simples e, em seguida, carregando em uma tabela. Eu anonimizei a instrução sql, que deve ser dolorosamente óbvia quando você olha para o nome da tabela. Eu também simplifiquei o pacote para fazer apenas uma contagem de linhas para esta demonstração.

O problema que estou tendo é que a consulta produz linhas no servidor SQL, mas não produz linhas no SSIS. A consulta é a seguinte.

DECLARE @CurrentBlahDate DATETIME
SET @CurrentBlahDate = ( SELECT MAX(BlahDate)
                                         FROM   dbo.ThisCoolTable SL
                                                WITH ( NOLOCK )
                                                INNER JOIN dbo.ThatCoolTable SLF
                                                WITH ( NOLOCK ) ON SL.CoolID = SLF.CoolID
                                                              AND SLF.TypeCode IN (
                                                              'ValueA',
                                                              'ValueB' ))
SELECT 
*
FROM dbo.Calendar
WHERE CAST(BaseDate AS DATE) = CAST(@CurrentBlahDate AS DATE)

Ignore o *, pois é apenas para fins desta demonstração. A consulta real tem o mesmo problema, embora não tenha o *. Quando executado no servidor SQL, retorna 1 linha da tabela de calendário conforme o esperado. No entanto, quando executado no mesmo ambiente no SSIS, não recebo nenhuma linha retornada.

Se eu transformar a consulta em um procedimento armazenado e executar o sproc no SSIS, obtenho uma contagem de linha de 1.

Se eu alterar a consulta para this.

SELECT 
*
FROM dbo.Calendar
WHERE CAST(BaseDate AS DATE) = CAST(( SELECT MAX(BlahDate)
                                         FROM   dbo.ThisCoolTable SL
                                                WITH ( NOLOCK )
                                                INNER JOIN dbo.ThatCoolTable SLF
                                                WITH ( NOLOCK ) ON SL.CoolID = SLF.CoolID
                                                              AND SLF.TypeCode IN (
                                                              'ValueA',
                                                              'ValueB' )) AS DATE)

Então eu mais uma vez recebo 1 linha.

Existe alguma razão para eu estar vendo esse comportamento?

ATUALIZAÇÃO: Antes de receber uma tonelada de críticas por isso, não tenho escolha sobre o absurdo do NOLOCK.

Ok, então eu tenho um relatório que faz uma comparação desta semana x semana passada e nosso cliente notou que seus dados eram "descolados". Após uma investigação mais aprofundada, descobrimos que não estava fazendo semanas corretamente de acordo com os padrões ISO. Eu executei este script como um caso de teste.

SET DATEFIRST 1
SELECT DATEPART(WEEK, '3/26/13')
    , DATEPART(WEEK, '3/27/12')
    , DATEPART(WEEK, '3/20/12')
    , DATEPART(WEEK, '1/2/12')
SELECT DATEPART(ISO_WEEK, '3/26/13')
    , DATEPART(ISO_WEEK, '3/27/12')
    , DATEPART(ISO_WEEK, '3/20/12')
    , DATEPART(ISO_WEEK, '1/2/12')

Ao executar, obtive esses resultados.

Achei que isso era peculiar e então pesquisei mais um pouco e descobri que o SQL Server conta 1º de janeiro como a primeira semana do ano, onde a ISO conta o primeiro domingo de janeiro como a primeira semana do ano.

A questão então acaba sendo dupla. Pergunta 1 por que isso? Pergunta 2 existe alguma maneira de mudar isso para não ter que modificar todo o meu código para usar ISO_Weekem todos os lugares?

Eu tenho quatro servidores idênticos 2 são usados ​​na produção e os outros dois são máquinas de demonstração/caixas de failover de emergência. A máquina mais poderosa, com 16 núcleos e 127 GB de Ram, hospeda nosso datawarehouse e nosso banco de dados OLTP. A caixa menos poderosa é uma caixa de 8 núcleos e 98 GB de RAM que usamos para ETL e nosso armazenamento de dados. O problema que estou tendo é que os serviços de integração de servidores de produção levam muito tempo para executar a validação do pacote. Para uma consulta que retorna em 6 segundos, leva 40 segundos para concluir a validação do pacote. Como você pode ver, é um pacote bastante simples.

Lembre-se de que este é apenas o pacote que estou usando como exemplo. Todos os meus pacotes têm o mesmo problema, embora alguns em menor grau. Quando executo isso, a parte de validação leva 40 segundos em média.

Para testar melhor isso, executei exatamente o mesmo pacote na caixa irmã que executa todos os mesmos trabalhos SQL desta caixa. Apenas para que a validação pré-execução leve 0 segundos e a consulta leve entre 4 e 6 segundos.

Para testar ainda mais, executei a consulta em ambas as instâncias do servidor SQL.

SELECT '{' + CAST(Store_Id AS CHAR(36)) + '}' AS Store_Id
      ,'{' + CAST(ItemGroupDetail_Id AS CHAR(36)) + '}' AS ItemGroupDetail_Id
      ,ItemGroupType_Id
      ,'{' + CAST(Concept_Id AS CHAR(36)) + '}' AS Concept_Id
      ,'{' + CAST(Company_Id AS CHAR(36)) + '}' AS Company_Id
      ,'{' + CAST(ItemGroup_Id AS CHAR(36)) + '}' AS ItemGroup_Id
      ,GroupName
      ,Sort
      ,NameOverride
      ,'{' + CAST(ParentGroup_Id AS CHAR(36)) + '}' AS ParentGroup_Id
      ,Active
      ,'{' + CAST(UserCreated AS CHAR(36)) + '}'  AS UserCreated
      ,'{' + CAST(UserModified AS CHAR(36)) + '}'  AS UserModified
  FROM bos_vAllItemGroups

A execução no servidor principal com data atualizada retorna 63326 linhas em 5 segundos em média e as 50527 linhas em 3 segundos. O que é de se esperar, este servidor tem muito menos atividade com as mesmas especificações que eu esperaria que fosse um pouco mais rápido. O que eu não esperaria é que o tempo de validação do pacote aumentasse muito mais do que o tempo real de execução da consulta.

Depois de muito cavar ontem, acho que descobri o problema, mas não tenho certeza de como prová-lo. O banco de dados OLTP de produção gerencia conteúdo para menus digitais em todo o país que estão ligando para casa constantemente para verificar se há novos conteúdos. Na maioria das vezes não há nada para mudar e as consultas para descobrir terminam em milissegundos. Por mais que eles enviem sobre esse processo acaba rodando em média 4500 consultas por segundo. Isso pode ser a causa do meu problema? O grande volume de transações provenientes do nosso servidor web. Se sim, como posso provar isso? Já tentei fazer com que esses bancos de dados fossem executados em máquinas separadas, pois esse banco de dados OLTP está crescendo muito rapidamente, assim como nosso datawarehouse e, de todas as minhas leituras, manter seus bancos de dados OLAP e OLTP no mesmo servidor é considerado uma prática ruim.

Eu tenho uma consulta que é usada para preencher uma tabela agregada para fins de relatório. A consulta vem de outro desenvolvedor aqui da empresa em que trabalho, mas é meu trabalho fazê-la rodar rápido. Até agora, todas as minhas primeiras tentativas falharam. Eu tentei várias coisas com esta consulta e é aqui que estou no momento. Já cortei cerca de meia hora do tempo de carregamento, mas estou preso e pensando que provavelmente terei que refazer tudo. Espero que alguém aqui possa ver se estou perdendo alguma coisa e me dê algumas dicas sobre como corrigir essa consulta.

SELECT P.CompanyID,
       P.CompanyName,
       P.StoreID,
       P.StoreName,
       P.ReportDate,
       Isnull((SELECT Sum(FT.GrossSales - Isnull(FP.PaymentAmount, 0)) AS PullNet
               FROM   FactSalesTransaction AS FT
                      LEFT JOIN (SELECT TransactionID,
                                        DimStoreID,
                                        DimBusinessDateID,
                                        Sum(PaymentAmount) AS PaymentAmount
                                 FROM   FactSalesPayment
                                 WHERE  DimPaymentTypeID <> 2
                                        AND ModStatusFlg <> 'D'
                                 GROUP  BY TransactionID,
                                           DimStoreID,
                                           DimBusinessDateID) AS FP
                        ON FP.TransactionID = FT.TransactionID
                           AND FP.DimStoreID = FT.DimStoreID
                      INNER JOIN DimCalendar AS C
                        ON FT.DimBusinessDateID = C.DimCalendarID
                           AND FP.DimBusinessDateID = C.DimCalendarID  AND C.CalendarDate >= '12/4/2012'
               WHERE  FT.DimStoreID = P.DimStoreID
                      AND FT.DimBusinessDateID = P.DimBusinessDateID

                      AND FT.ModStatusFlg <> 'D'), 0) AS StoreCash,
       SR.CashDeposit AS StoreResp,
       SN.StoreNet,
       P.DimEmployeeID AS EmpID,
       P.EmpName,
       P.RegisterID,
       P.PullNumber,
       Isnull((SELECT Sum(FT.GrossSales - Isnull(FP.PaymentAmount, 0)) AS PullNet
               FROM   FactSalesTransaction AS FT
                      LEFT JOIN (SELECT TransactionID,
                                        DimStoreID,
                                        DimBusinessDateID,
                                        Sum(PaymentAmount) AS PaymentAmount
                                 FROM   FactSalesPayment
                                 WHERE  DimPaymentTypeID <> 2
                                        AND ModStatusFlg <> 'D'
                                 GROUP  BY TransactionID,
                                           DimStoreID,
                                           DimBusinessDateID) AS FP
                        ON FP.TransactionID = FT.TransactionID
                           AND FP.DimStoreID = FT.DimStoreID
                      INNER JOIN DimCalendar AS C
                        ON FT.DimBusinessDateID = C.DimCalendarID
                           AND FP.DimBusinessDateID = C.DimCalendarID AND C.CalendarDate >= '12/4/2012'
               WHERE  FT.DimStoreID = P.DimStoreID
                      AND FT.DimRegisterID = P.DimRegisterID

                      AND FT.TransactionDateTime BETWEEN P.PullDrawerStartTime AND P.PullDrawerEndTime
                      AND FT.ModStatusFlg <> 'D'), 0) AS PullCash,
       P.PullResp + Isnull((SELECT Sum(SkimAmount)
                            FROM   FactSkims
                            WHERE  DimStoreID = P.DimStoreID
                                   AND DimRegisterID = P.DimRegisterID
                                   AND SkimDateTime BETWEEN P.PullDrawerStartTime AND P.PullDrawerEndTime), 0) AS PullResp,
       Isnull((SELECT Sum(NetSales) AS PullNet
               FROM   FactSalesTransaction AS FT
                      INNER JOIN DimCalendar AS C
                        ON FT.DimBusinessDateID = C.DimCalendarID AND C.CalendarDate >= '12/4/2012'
               WHERE  DimStoreID = P.DimStoreID
                      AND DimRegisterID = P.DimRegisterID
                      AND TransactionDateTime BETWEEN P.PullDrawerStartTime AND P.PullDrawerEndTime

                      AND ModStatusFlg <> 'D'), 0)                                                             AS PullNet
FROM   (SELECT C.CompanyID,
               C.CompanyName,
               S.StoreID,
               S.StoreName,
               F.DimEmployeeID,
               E.FirstName + ' ' + E.LastName                           AS EmpName,
               CASE
                 WHEN F.PullDrawerStartTime <> '1900-01-01' THEN F.PullDrawerStartTime
                 ELSE Isnull(Cast((SELECT TOP 1 Dateadd(SECOND, 1, PullDrawerEndTime)
                                   FROM   FactPullDrawer
                                   WHERE  PullDrawerEndTime < F.PullDrawerEndTime
                                          AND DimStoreID = F.DimStoreID
                                          AND DimRegisterID = F.DimRegisterID
                                          AND DimBusinessDateID = F.DimBusinessDateID
                                   ORDER  BY PullDrawerEndTime DESC) AS DATETIME), BD.CalendarDate + Isnull(Cast(Cast(ST.SiteSettingValue AS TIME) AS DATETIME), Cast('4:00:00 AM' AS DATETIME)))
               END AS PullDrawerStartTime,
               F.PullDrawerEndTime,
               BD.CalendarDate AS ReportDate,
               R.RegisterID,
               R.DimRegisterID,
               (SELECT Count(PullDrawerEndTime)
                FROM   FactPullDrawer
                WHERE  PullDrawerEndTime < F.PullDrawerEndTime
                       AND DimStoreID = F.DimStoreID
                       AND DimRegisterID = F.DimRegisterID
                       AND DimBusinessDateID = F.DimBusinessDateID) + 1 AS PullNumber,
               Isnull(F.Amount, 0)                                      AS PullResp,
               F.DimStoreID,
               F.DimBusinessDateID
        FROM   FactPullDrawer AS F
               INNER JOIN DimCompany AS C
                 ON C.DimCompanyID = F.DimCompanyID
               INNER JOIN DimStore AS S
                 ON S.DimStoreID = F.DimStoreID
               INNER JOIN DimCalendar AS BD
                 ON BD.DimCalendarID = F.DimBusinessDateID
                    AND BD.CalendarDate >= '12/4/2012'
               INNER JOIN DimEmployee AS E
                 ON F.DimEmployeeID = E.DimEmployeeID
               INNER JOIN DimRegister AS R
                 ON R.DimRegisterID = F.DimRegisterID
               LEFT JOIN DimSiteSettings AS ST
                 ON S.StoreID = ST.StoreID
                    AND C.CompanyID = ST.CompanyID
                    AND ST.SiteSettingFieldID = 1412) AS P
       INNER JOIN (SELECT DimStoreID,
                          DimBusinessDateID,
                          Sum(NetSales) AS StoreNet
                   FROM   FactSalesTransaction
                   WHERE  ModStatusFlg <> 'D'
                   GROUP  BY DimStoreID,
                             DimBusinessDateID) AS SN
         ON SN.DimStoreID = P.DimStoreID
            AND SN.DimBusinessDateID = P.DimBusinessDateID
       INNER JOIN (SELECT CompanyID,
                          StoreID,
                          ReportDate,
                          Sum(ValTotal) AS CashDeposit
                   FROM   AgtAccountingReport
                   WHERE  ReportCatOrder = 7
                          AND ReportElementOrder < 100
                          AND ReportElementOrder NOT IN ( 7, 9, 10, 16,17, 18, 19, 20, 21 )
                          AND ReportDate >= '10/28/2012'
                   GROUP  BY CompanyID,
                             StoreID,
                             ReportDate) AS SR
         ON SR.CompanyID = P.CompanyID
            AND SR.StoreID = P.StoreID
            AND SR.ReportDate = P.ReportDate 

Estou pensando em todos os aninhados SELECT, e é por isso que pensei em começar do zero. Qualquer ajuda seria apreciada.

Portanto, tenha um trabalho de ETL que seja executado por meio de serviços de integração que eu inicie com um nome de trabalho SQL StartStageStore. A última etapa deste trabalho é iniciar outro trabalho e relatar o sucesso. O trabalho para o qual isso chama é chamado de LoopStageStore. Tudo o que o LoopStageStore faz é executar um procedimento armazenado que reinicia o trabalho StartStageStore novamente desta forma, estamos constantemente puxando os dados de origem para o nosso sistema. Este trabalho está em execução há várias semanas sem falhas. Até as duas últimas noites eu comecei a receber este erro "Executado como usuário: AgentUser. SQLServerAgent Error: Request to run job Stage/Store AgentUser recusado porque o job já está sendo executado a partir de uma solicitação do User AgentUser. [SQLSTATE 42000] (Erro 22022) . A etapa falhou."

Isso não deve ser possível quando o trabalho de execução do StartStageStore for concluído e não estiver mais em execução quando o LoopStageStore for iniciado.

Aqui podemos ver a última etapa executada às 12:19:14.

E o próximo trabalho falha às 12:19:15 Dizendo que o StartStageStore está em execução no momento. Eu já tenho uma solução alternativa para isso, em que apenas lance um atraso no segundo trabalho. Eu só estou querendo saber se alguém sabe por que isso aconteceria.

BEGIN
WAITFOR DELAY '00:01';
    EXECUTE dbo.LoopStageStore
END; GO