Elaskanator's questions

Verificou-se que esse erro de código causou um loop infinito na produção:

DECLARE @BatchID INT
DECLARE MyCursor CURSOR FOR
    SELECT BatchID = ...
OPEN MyCursor
FETCH NEXT FROM MyCursor INTO @BatchID
WHILE @@FETCH_STATUS = 0
BEGIN
    ...
    IF [condition]
    BEGIN
        ...
        FETCH NEXT FROM MyCursor INTO @BatchID
    END
END
CLOSE MyCursor
DEALLOCATE MyCursor

Supondo que a necessidade de um cursor seja garantida , existe alguma maneira de se proteger contra esse erro (além de mais testes/revisão de código)?

Em outras linguagens, temos FOREACHloops que gerenciam o progresso da iteração para nós, ou FORloops que têm uma reflexão tardia , então existe algum equivalente no SQL Server que evite erros desleixados como extraviar (ou esquecer!)?

Eu nunca vi loops personalizados no SQL precisarem fazer algo sofisticado com o cursor, e WHILEos loops têm o mesmo risco (junto com casos como DELETE #WorkData WHERE ID = @BatchID@BatchID isNULL ), então como esse risco pode ser mitigado programaticamente/limpamente para o caso de uso típico?

Uma abordagem como esta é muito desagradável:

DECLARE @BatchID INT
DECLARE MyCursor CURSOR FOR
    SELECT BatchID = -1--dummy entry to always be skipped
    UNION ALL SELECT BatchID = ...
OPEN MyCursor
FETCH NEXT FROM MyCursor INTO @BatchID
WHILE @@FETCH_STATUS = 0
BEGIN
    FETCH NEXT FROM MyCursor INTO @BatchID
    IF @@FETCH_STATUS = 0
    BEGIN
        ...
    END
END
CLOSE MyCursor
DEALLOCATE MyCursor

Parece-me que verificar @@FETCH_STATUSduas vezes seguidas sem nenhuma instrução de posição/controle do cursor no meio pode ser uma maneira eficaz para o SQL Server adivinhar se houve esse erro, pois minha experiência com cursores nunca viu duas verificações seguidas intencionalmente (sem cursores aninhados pelo menos, mas aqueles ainda têm instruções de controle como OPENe CLOSEentre verificações do @@FETCH_STATUScursor externo).

_{PS O [condition]desta vez foi equivalente a "não é o dia de transição do horário de verão" (que foi neste domingo). Mais erros de fuso horário!}

Estou mais interessado em recursos de linguagem para obter a mesma garantia fornecida automaticamente de como outras linguagens lidam com a cláusula de reflexão tardia de um loop for (por exemplo, o i++infor (int i = 0; i < myArray.Length; i++) ). Quanto menos coisas o indivíduo é responsável, menos lugares existem para cometer um erro, e seria uma tarefa monumental auditar literalmente milhares de procedimentos armazenados em nosso sistema, especialmente porque muitos deles estão iterando dados de forma inadequada em vez de usar lógica baseada em conjunto já.

Minhas tentativas de publicação estão falhando com este erro

Msg 205, Level 16, State 1, Line 7572 Todas as consultas combinadas usando um operador UNION, INTERSECT ou EXCEPT devem ter um número igual de expressões em suas listas de destino.

Seguindo o conselho da velha escola para imprimir mensagens de status entre a execução do script de implantação, reduzi-o a isso:

_{O número da linha não combina por causa de peculiaridades do SQL Server, e é por isso que você precisa fazer PRINTcoisas como um pagão (veja o link acima)}

Observe como não houve literalmente nenhuma instrução executada. Eu também tive um rastreamento detalhado em execução que confirma que nada foi executado:

Como as instruções de fluxo de controle entre duas PRINTinstruções podem causar um erro?!

Como posso escrever código protegido que invoque o CATCHbloco de código em todos os casos esperados * (sem fazer lixo estranho como envolver tudo em SQL dinâmico)?

Por exemplo, isso não funciona:

1. Definir um trabalho do SQL Agent sem etapas

2. Tente iniciar o trabalho dentro de umTRY/CATCH

   BEGIN TRY
       EXEC msdb.dbo.sp_start_job @job_name = 'my_empty_job'
   END TRY
   BEGIN CATCH
       SELECT [MyError] = 'Error caught: ' + ISNULL(ERROR_MESSAGE(), 'NULL')
   END CATCH
   

Msg 22022, nível 16, estado 1, linha 0 SQLServerAgent Erro: solicitação para executar o trabalho my_empty_job (do usuário xyz) recusada porque o trabalho não tem etapas de trabalho.

Observe que a gravidade do erro é 16, portanto, não deve ter ignorado o bloco CATCH. pq?!?

Ele também ignora meu CATCHbloqueio se o trabalho estiver ocupado lidando com uma solicitação (estou enviando spam para solicitações de parada e início em meus testes).

Msg 22022, nível 16, estado 1, linha 0 SQLServerAgent Erro: solicitação para executar o trabalho my_simple_job (do usuário xyz) recusada porque o trabalho já tem uma solicitação pendente do usuário xyz.

Caso relacionado: referência de servidor vinculado inválida

PS Por favor, não assuma que eu só quero uma solução de escopo restrito para lidar com a invocação de trabalho. Estou procurando uma solução genérica que possa reutilizar no futuro.

PPS Eu sou capaz de pegar o caso de tentar iniciar/parar um trabalho que não existe ("O @job_name especificado ('missing_job') não existe."). Por que isso se comporta de forma diferente?

* _{O que TRY/CATCH não lida (tl; dr gravidades de erro fora do intervalo (10, 20))}

Toda vez que algo falha na publicação, supondo que ele passe na geração de visualização , a linha de erro e a amostra de script executado são completamente inúteis para me ajudar a rastrear a origem do erro, pois o número da linha é relativo à última GOinstrução e o script executado não nem sempre aparecem no script de publicação.

Neste caso, ele falha com este erro:

O script executado não existe no script de publicação:

E é aqui que ele navega no script de publicação ao clicar duas vezes na mensagem de erro:

Normalmente, consigo rastreá-lo com base nas informações de erro, mas desta vez estou perdido porque as únicas palavras-chave relevantes que consigo pensar são tão comuns que parece impossível.

Parece que o registro é hackish e os erros às vezes vêm antes do script pós-implantação (por exemplo, gatilhos de tabela executando em dados incompletos, pois as configurações de publicação incluem apenas uma opção para desabilitar gatilhos DDL ).

Tentei executar o SQL Server Profiler durante a publicação, mas essa ferramenta omite informações de depuração ainda mais cruciais (e fica sobrecarregada com meu grande projeto de banco de dados). _{Talvez outro motivo para atualizar para obter o Extended Events Profiler?}

(Verifiquei que esta declaração não era a culpada)

Eu estava martelando minha instância do SQL Server ontem por cerca de 3 horas executando um cálculo intensivo que estava consumindo toda a RAM física alocada _{(tenho limitada a 2 GB devido ao meu hardware de estação de trabalho limitado)} e de repente (e muitas outras coisas?) sua memória em uma mudança aparente para usar exclusivamente o arquivo de paginação.

Meu computador estava ficando tão incrivelmente atrasado que fui forçado a reiniciar (o que levou 10 minutos apenas para acessar as opções de energia).

Consegui obter uma captura de tela do gerenciador de tarefas antes de reiniciar (que deixo rodando em segundo plano com baixa velocidade de atualização). Com a janela redimensionada para mostrar o histórico máximo, ficou assim:

Esse comportamento surpreendente causou tempo de inatividade. Este é um recurso documentado?

Estou executando o Windows Server 2008 R2 com um mecanismo de banco de dados Enterprise 2014.

Obrigado.

Eu gosto de ser detalhado na minha codificação, então minha instrução de inserção típica se parece com isso:

INSERT INTO MyTable
(
     Column1
    ,Column2
    ,Column3
    ,Column4
    ,Column5
    ,Column6
)
SELECT
     Column1 = 'some value'
    ,Column2 = 'some value'
    ,Column4 = 'some value'
    ,Column3 = 'some value'
    ,Column5 = 'some value'
    ,Column6 = 'some value'
....

Se você não percebeu o problema com esta afirmação, então você foi enganado, assim como eu fui inúmeras vezes.

E a parte realmente insidiosa desse tipo de falha é que pode funcionar por muito tempo antes de causar qualquer problema e, quando falhar, se houver um erro, não indicará o verdadeiro erro.

Por exemplo, se as colunas 3 e 4 forem do tipo numérico e de string, respectivamente, apenas alguns valores causarão erros de tempo de execução para a coluna 4 (e nenhum para a coluna 3) com uma falha de conversão de tipo (por exemplo, '0' converte para um número perfeitamente mas 'asdf' não).

_{(No meu caso, isso foi enterrado dentro de um procedimento de ativação do Service Broker fora da seção de código protegido (era uma instrução de log), então, em vez desse erro, eu estava recebendo o erro de transação órfão mascarado como uma mensagem suspeita desativando minha fila.)}

Existe alguma maneira de validar tal declaração que não exija revisão manual?

PS Eu sei que você pode dar os aliases que quiser, mas em um contexto completamente opcional, como uma INSERTdeclaração, seria extremamente útil ter algum tipo de ferramenta automatizada (ou seja, IntelliSense) para apontar código acidental provável.

Atualização: abri este item de feedback para a Microsoft, por essa funcionalidade claramente ausente.

O SQL Server fornece a STDEVfunção , mas não pode ser usada em conjunto com funções de janela .

Por exemplo

SELECT
     TestName
    ,[BatchSize]
    ,[NumIterations] = COUNT(*)
    ,[Min] = MIN(RuntimeMs)
    ,[Average] = AVG(RuntimeMs)
    ,[Max] = MAX(RuntimeMs)
    ,[StdDev] = STDEV(RuntimeMs)
FROM #TimingResult
GROUP BY TestName, [BatchSize]

Como posso calcular percentis e desvio padrão ao mesmo tempo?

Percebi um comportamento estranho de arredondamento no SQL Server (pelo menos 2008R2) ao converter a base de log 10 de 1000 para um inteiro. A resposta é claramente o valor exato 3, mas deve haver alguns decimais que o SQL Server está ocultando da saída:

SELECT LOG(1000, 10)--returns 3 with no visible decimals
SELECT CONVERT(INT, LOG(1000, 10))--returns 2

Eu fiz engenharia reversa do epsilon mínimo para obter o valor correto quando adicionado ao resultado de LOGantes da conversão como aproximadamente:

SELECT CONVERT(INT, LOG(1000, 10)+0.0000000000000002220446049250313)
SELECT CONVERT(INT, LOG(1000, 10)+0.0000000000000002220446049250312)

Parece que eu poderia ficar o dia todo tornando esse valor mais preciso.

Isso só parece ser necessário para o caso de 1000, pois obtenho os valores inteiros adequados para 1, 10, 100 e 10000 e maiores sem usar nenhum termo épsilon.

O termo de erro parece ser a cauda da série Taylor expandida em 16 termos (conforme esta página ), mas por que o SQL Server está se comportando repentinamente como esperado (sem erro de precisão de máquina oculto) quando tento isso para o caso de 10000 e maiores ?

Por que o SQL Server está demonstrando inconsistentemente um erro de precisão da máquina?

Obrigado.

Devido à lógica de negócios, precisamos de uma nova coluna em uma tabela que seja essencial para garantir que ela seja sempre preenchida. Portanto, deve ser adicionado à tabela como NOT NULL. Ao contrário das perguntas anteriores que explicam como fazer isso manualmente , isso precisa ser gerenciado pela publicação do SSDT.

Eu tenho batido minha cabeça contra a parede por um tempo por causa dessa tarefa que parece simples devido a algumas realizações:

1. Um valor padrão não é apropriado e não pode ser uma coluna computada. Talvez seja uma coluna de chave estrangeira, mas para outras não podemos usar um valor falso como 0 ou -1 porque esses valores podem ter significado (por exemplo, dados numéricos).
2. Adicionar a coluna em um script de pré-implantação falhará na publicação quando tentar criar automaticamente a mesma coluna, uma segunda vez (mesmo que o script de pré-implantação seja escrito para ser idempotente) _{(este é realmente agravante, pois posso de outra forma pense em uma solução fácil)}
3. A alteração da coluna para NOT NULL em um script pós-implantação será revertida toda vez que ocorrer a atualização do esquema SSDT (portanto, no mínimo, nossa base de código não corresponderá entre o controle de origem e o que está realmente no servidor)
4. Adicionar a coluna como anulável agora com a intenção de mudar para NOT NULL no futuro não funciona em várias ramificações/bifurcações no controle de origem, pois os sistemas de destino não necessariamente terão a tabela no mesmo estado na próxima vez que forem atualizados _{( não que esta seja uma boa abordagem de qualquer maneira IMO)}

A abordagem que ouvi de outras pessoas é atualizar diretamente a definição da tabela (para que a atualização do esquema seja consistente), escrever um script de pré-implantação que mova todo o conteúdo da tabela para uma tabela temporária com a nova lógica de preenchimento de coluna incluída e, em seguida, mova as linhas de volta em um script pós-implantação. Isso parece arriscado como o inferno, e ainda irrita o Publish Preview quando detecta que uma coluna NOT NULL está sendo adicionada a uma tabela com dados existentes (já que a validação é executada antes do script de pré-implantação).

Como devo adicionar uma nova coluna não anulável sem arriscar dados órfãos ou mover dados para frente e para trás em cada publicação com longos scripts de migração que são inerentemente arriscados?

Obrigado.

Eu tenho um processo de watchdog que é executado por meio de um trabalho do SQL Agent para gerenciar algumas tarefas personalizadas. Uma das verificações é que o processo não existe mais:

UPDATE R
SET IsOrphaned = 1, DebugTimestampUtc = GETUTCDATE()
FROM
    RequestTable AS R
    LEFT JOIN sys.sysprocesses AS P ON
        P.spid = R.SPID
WHERE P.spid IS NULL

No SSMS, executo esta instrução e fecho a janela de consulta antes que ela seja concluída (cancelando a consulta):

INSERT INTO RequestTable(SPID, CreateTimestampUtc, ...)
SELECT @@SPID, GETUTCDATE(), ...
WAITFOR DELAY '00:00:30.000'

Quando executo manualmente a consulta para sinalizar órfãos no SSMS, ela corresponde na linha, mas meu trabalho não , como é evidenciado pela RequestTablenão marcação da linha como órfã. O histórico da tarefa mostra a execução conforme programado sem erros, com tempo de execução insignificante (< 1 segundo).

Além disso, quando eu aumento a instrução de detecção de órfãos para também encontrar registros onde P.status = 'sleeping'ela detecta imediatamente quando eu cancelo a INSERT ... WAITFOR ...consulta (e mantenho a janela de consulta aberta).

Existe algum comportamento sutil do SQL Server causando esse estado aparentemente inconsistente da sys.sysprocessestabela entre o SSMS e o SQL Agent? Eu também tentei com e sem uma dica de consulta NOLOCK no RequestTable.

Estou executando o SQL Server 2014 em modo de compatibilidade para 2008R2.

(Observe que usar sys.dm_exec_sessionsem vez disso ainda se comporta da mesma forma)

Obrigado.

PS O objetivo disso é serializar processos assíncronos que têm problemas de simultaneidade. Talvez haja também uma maneira melhor de fazer isso (sem poder corrigir os processos assíncronos)?