krystah's questions

Há duas razões que me levam a fazer esta pergunta:

tSQLt
A estrutura de teste T-SQL tSQLt considera um problema de "Alta Gravidade" quando existem colunas com um agrupamento não padrão. O autor do teste afirma o seguinte:

NÃO estou sugerindo que cada coluna de string deva ter um agrupamento que corresponda ao agrupamento padrão do banco de dados. Em vez disso, estou sugerindo que, quando for diferente, deve haver uma boa razão para isso.

No entanto, a gravidade do teste reprovado é, como mencionado, considerada alta.

Octopus Deploy
Ao configurar o Octopus Deploy Server, a configuração falha com um erro FATAL durante a inicialização da instância OctopusServer. O artigo relacionado à mensagem de erro não explica por que isso é um requisito, mas simplesmente afirma que será um requisito para implantações futuras, incluindo o Octopus versão 3.8.

Como uma observação lateral, o pacote de ferramentas CI da RedGate, o DLM Automation Suite , oferece suporte a implantações com agrupamentos variados sem reclamações.

A recomendação de manter todos os agrupamentos de colunas no padrão do banco de dados parece mais diretrizes ou práticas recomendadas para mim. Por que é considerado um erro tão grave por alguns?

Estou tentando construir consultas TSQL para substituir várias ferramentas GUI fornecidas pelo SQL Server Management Studio. Uma dessas ferramentas é o Job Activity Monitor, acessível pela Object Explorerjanela.

Nosso ambiente de banco de dados atual inclui um cluster com 3 nós (um primário e duas réplicas somente leitura), bem como um único servidor independente próximo ao cluster.

Por brevidade, chamarei os nós de N1, N2 e N3 e o servidor independente S1 .

Recentemente, configuramos Multi-Server Job Administrationnossos servidores, usando S1 como servidor MSX (mestre) e N1, N2 e N3 como servidores TSX (destino).

Isso significa que os trabalhos do SQL Agent que operam nos nós de cluster são criados e gerenciados a partir de S1.

Os servidores TSX relatam seu estado, resultado etc para o servidor MSX, que pode ser acessado usando o referido arquivo Job Activity Monitor. A partir do Job Activity Monitor, o histórico de tarefas de cada servidor inscrito (TSX) pode ser acessado selecionando View history:

O que nos leva a esta janela:

Esta é a informação que estou tentando recriar, usando uma consulta TSQL no servidor MSX. Eu quero ver o resultado e o histórico dos trabalhos de todos os servidores inscritos, semelhante ao que é exibido pela janela da GUI.

Eu tentei vasculhar as tabelas e visualizações relacionadas ao trabalho do banco de msdbdados, mas sem sorte. A msdb.dbo.sysjobhistorytabela no servidor MSX não contém nenhum histórico de servidores inscritos, e eu não consigo encontrar nenhuma boa documentação sobre como mais eu faria para coletá-la. Esses dados são acessíveis através do TSQL? Qualquer recurso relevante é muito apreciado.

Pergunta : No SQL Server 2016, atualizar uma coluna com o mesmo valor (por exemplo, atualizar uma coluna de 'john'to 'john') produz a mesma quantidade de log de transações que ao atualizar uma coluna com um valor diferente? Leia abaixo para mais detalhes.

Temos vários trabalhos do SQL Agent em execução em uma programação. Esses trabalhos selecionam dados de uma tabela de origem (dados replicados, servidores vinculados), transformam-nos e inserem/atualizam/excluem as linhas da tabela de destino local de acordo.

Passamos por várias estratégias enquanto tentamos encontrar a melhor maneira de conseguir isso. Nós tentamos

• Atualizando destino da origem usando MERGE
• Atualizando o destino da origem usando UPDATE para atualizar todas as colunas
• Atualizando o destino da origem usando uma única instrução UPDATE por coluna de destino

Agora, sou apenas um DBD júnior e meu entendimento de como o log de transações funciona é muito limitado. Dito isto, meus superiores concluíram que não podemos usar as instruções MERGE ou UPDATE onde todas as colunas são processadas na mesma instrução, pois isso cria um log excessivo. O argumento para isso é que quando você executa uma UPDATE-instrução no SQL Server, quando você define um valor de coluna e o novo valor é igual ao valor antigo, ele ainda é marcado como uma atualização no log de transações. Isso aparentemente se torna caro quando você executa muitas e muitas operações SET inúteis.

No exemplo a seguir, atualizamos o first_nameand last_nameda tabela de destino usando valores da tabela de origem, unidos por id.

-- create source- and target-table
CREATE TABLE [#tgt] (
    [id] Int PRIMARY KEY,
    [first_name] NVarchar(10),
    [last_name] NVarchar(10)
)
CREATE TABLE [#src] (
    [id] Int PRIMARY KEY,
    [first_name] NVarchar(10),
    [last_name] NVarchar(10)
)

-- fill some dummy-data
INSERT INTO [#tgt]([id], [first_name], [last_name])VALUES(1, 'john', 'lennon')
INSERT INTO [#src]([id], [first_name], [last_name])VALUES(1, 'john', 'cena')

-- update target-table with values from source-table
UPDATE 
    [T]
SET 
    [T].[first_name] = [S].[first_name],
    [T].[last_name] = [S].[last_name]
FROM
    [#tgt] AS [T]
    JOIN [#src] AS [S] ON [S].[id] = [T].[id]

DROP TABLE [#tgt]
DROP TABLE [#src]

Este exemplo não verifica se algum valor foi realmente alterado. Se ignorarmos NULL-checking e fallbacks sãos por um momento, isso pode ser verificado de uma das seguintes maneiras:

-- Example #1: updates all rows where first-name or last-name has changed
UPDATE ..
SET ..
FROM ..
WHERE [T].[first_name] <> [S].[first_name] OR [T].[last_name] <> [S].[last_name]

-- Example #2: updates all rows, sets target-value to source-value if value has changed
UPDATE ..
SET 
    ISNULL(NULLIF([S].[first_name], [T].[first_name]), [T].[first_name]),
    ISNULL(NULLIF([S].[last_name], [T].[last_name]), [T].[last_name])
FROM ..

No Exemplo #1, a operação SET atualizará todas as colunas, mesmo que apenas 1 coluna tenha sido alterada.

No Exemplo #2, a operação SET atualizará todas as colunas de todas as linhas, retornando ao valor antigo se o valor não for alterado.

Em ambos os exemplos, todas as colunas são atingidas pela operação SET e, de acordo com meus superiores, isso cria uma quantidade desnecessária/problemática de log de transações quando feito com frequência.

O mesmo se aplica para a MERGEinstrução -. Mesmo se você verificar uma linha correspondente para alterações, todas as colunas serão atingidas pela atualização.

MERGE [#tgt] AS tgt
USING [#src] AS src
ON (tgt.id = src.id)  
WHEN MATCHED AND ([tgt].[first_name] <> [src].[first_name] OR [tgt].[last_name] <> [src].[last_name])
THEN UPDATE SET 
        [tgt].[first_name] = [src].[first_name], 
        [tgt].[last_name] = [src].[last_name];

Então, o que fazemos? Use uma única instrução UPDATE para cada coluna que desejamos atualizar. Nesse caso:

-- first_name
UPDATE [T]
SET [T].[first_name] = [S].[first_name]
FROM
    [#tgt] AS [T]
    JOIN [#src] AS [S] ON [S].[id] = [T].[id]
    WHERE [T].[first_name] <> [S].[first_name]

-- last_name
UPDATE [T]
SET [T].[last_name] = [S].[last_name]
FROM
    [#tgt] AS [T]
    JOIN [#src] AS [S] ON [S].[id] = [T].[id]
    WHERE [T].[last_name] <> [S].[last_name]

Agora, existem alguns contras nessa abordagem:

• Todas as instruções de atualização devem ser executadas na mesma transação para garantir que uma linha não seja deixada pela metade.
• É realmente uma merda escrever todo o código (imagine tabelas com mais de 50 colunas)

Parece que deve haver uma maneira mais inteligente de contornar isso, e eu apreciaria qualquer esclarecimento e correção nas declarações feitas neste post. Como mencionado anteriormente, estou apenas tentando o meu melhor para entender por que tem que ser assim.

Peço desculpas pelo post longo e obrigado desde já.

Estou experimentando um comportamento THROWque não consigo entender. Considere o seguinte procedimento armazenado:

CREATE PROCEDURE usp_division_err AS 
SET NOCOUNT ON;
BEGIN TRY
    EXEC('select 1/0')
END TRY
BEGIN CATCH
    THROW;
END CATCH 

Quando o procedimento é executado, o seguinte erro é gerado:

Msg 8134, Nível 16, Estado 1, Linha 1
Erro de divisão por zero encontrado.

Observe que nenhuma informação sobre em qual procedimento o erro foi gerado está incluída. Isso ocorre porque o SQL dinâmico e incorreto é executado em outro escopo, e tudo bem. No entanto, altere o CATCH-block para ficar assim

BEGIN CATCH
    THROW 50000, 'An error occurred.', 1;
END CATCH 

e a execução do procedimento gerará este erro:

Msg 50000, Nível 16, Estado 1, Procedimento usp_division_err, Linha 7 [Batch Start Line 0]
Ocorreu um erro.

O erro ainda é encontrado durante a execução do SQL dinâmico, mas quando eu especifico manualmente o número do erro e a mensagem de erro (o primeiro e o segundo parâmetro de THROW), o nome do procedimento do procedimento em execução aparece de alguma forma.

Por que o nome do procedimento aparece na segunda mensagem de erro, mas não na primeira?

Estou consultando dados de um servidor vinculado por meio de uma exibição no servidor de origem. A visualização deve incluir algumas colunas padronizadas, como Created, Modifiede Deleted, mas, neste caso, a tabela no servidor de origem não possui nenhuma informação adequada. As colunas são, portanto, explicitamente convertidas para seus respectivos tipos. Atualizei a visualização, alterando uma coluna de

NULL AS Modified

para

CAST(NULL as DateTime) as Modified

No entanto, após realizar esta atualização, a visualização está acionando a seguinte mensagem de erro:

Msg 7341, Nível 16, Estado 2, Linha 3 Não é possível obter o valor da linha atual da coluna "(expressão gerada pelo usuário).Expr1002" do provedor OLE DB "SQLNCLI11" para o servidor vinculado "".

Fizemos essa mudança de "conversão explícita" geralmente no servidor de origem sem preocupações e suspeito que o problema possa estar relacionado à versão dos servidores envolvidos. Não precisamos realmente aplicar esse elenco, mas parece mais limpo. No momento, estou apenas curioso para saber por que isso está acontecendo.

Versão do servidor (origem):

Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 14 de maio de 2014 18:34:29 Copyright (c) Microsoft Corporation Enterprise Edition (64 bits) no Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor)

Versão do servidor (vinculado):

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 17 de junho de 2011 00:54:03 Copyright (c) Microsoft Corporation Enterprise Edition (64 bits) no Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor )

Editar
Acabei de perceber que cometi um erro ao não postar todas as colunas em questão e devo me desculpar por deixar de fora um detalhe importante. Não sei como não percebi isso antes. A questão ainda permanece, no entanto.

A conversão errada não acontece com a conversão para DateTime, mas com uma coluna sendo convertida para UniqueIdentifier.

Este é o culpado:

CAST(NULL AS UniqueIdentifier) AS [GUID]

UniqueIdentifiers são suportados no SQL Server 2008 R2 e, conforme mencionado nos comentários, a consulta executada pela exibição é executada corretamente no servidor vinculado.

Estou tentando criar uma tabela de log para armazenar eventos em um company-object e estou com medo de estar seguindo o caminho errado. Cheguei à conclusão de que devo registrar diferentes tipos de dados na mesma coluna e não parece certo. Vou explicar o caso de uso básico com 2 tabelas; companye user.

company
- id int
- name nvarchar
- description

user
- id int
- name nvarchar
- company int (references company.id)

Agora, digamos que eu queira registrar diferentes tipos de eventos no company-object. Eu faria uma tabela de log chamada company_loge company_log_typearmazenaria eventos lá. Essas tabelas ficariam assim:

company_log
- id int
- old_value nvarchar
- new_value nvarchar
- log_type int (references company_log_type.id)

company_log_type
- id int
- name

Exemplos de eventos interessantes são

• O nome da empresa foi alterado
• A descrição da empresa foi alterada
• Um usuário foi adicionado à empresa
• Um usuário foi removido da empresa

Para os dois eventos anteriores, eu armazenaria o tipo de evento, o valor antigo e o novo valor. Isso funciona bem, desde que eu pare aqui. No entanto, se eu quiser registrar os 2 eventos anteriores, precisarei armazenar diferentes tipos de dados na mesma coluna. As mudanças ficariam mais ou menos assim:

old_value     new_value     log_type
----------------------------------------------
Acme          PiedPiper     CompanyNameChanged
NULL          132           UserAdded
97            NULL          UserRemoved

Neste ponto, eu precisaria armazenar o valor textual antigo/novo do nome da empresa, bem como a id do usuário adicionado recentemente. Você pode ver que já estou indo na direção errada, e é aqui que Eu peço ajuda. Eu tenho 2 perguntas:

Devo usar apenas sql_variant-datatype ou, se isso for considerado um design ruim, qual seria uma maneira sensata de armazenar esses eventos de log?

Desde já, obrigado.

Eu me encarei cegamente com isso. Começou como um procedimento mais complexo, mas eu o reduzi ao mínimo, tentando fazê-lo funcionar. Este é o código atual:

DECLARE @sql NVarchar(MAX) = '
CREATE PROCEDURE dbo.Test
AS
BEGIN
    SELECT 1, @num;
END'

EXEC [sp_executesql] @sql, N'@num int', @num = 1;

Ele simplesmente se recusa. Vale ressaltar que, se eu executar o código sem a parte do parâmetro ( @sqlsendo o único parâmetro da sp_executesqlfunção), ele funcionará bem. Eu tentei outras alternativas de sintaxe, como

EXEC [sp_executesql] @sql, N'@num int', 1;

e

DECLARE @params NVarchar(1000) = '@num int';
EXEC [sp_executesql] @sql, @params, 1;

O que há de errado com minha especificação de parâmetro?

Editar 1 : mensagem de erro incluída

Msg 156, Level 15, State 1, Line 2
Incorrect syntax near the keyword 'PROCEDURE'.

Temos várias tabelas que "atualizamos" com frequência, reconstruindo-as em uma tabela de preparação e, em seguida, realizando uma troca de metadados para a tabela de produção usando a ALTER TABLE <source> SWITCH INTO <target>instrução.

Essas operações estão causando uma grande quantidade de registros e não temos certeza de como lidar com isso. Por enquanto, apenas movemos essas tabelas e operações para um novo banco de dados usando o SIMPLEmodelo de recuperação, mas adoraria ouvir soluções alternativas para esse problema.

Como você sugere lidarmos com a geração massiva de logs como resultado de reconstruções frequentes de tabelas?

Atualmente, tenho uma tabela bastante grande (5 a 7 milhões de linhas). Essa tabela é reconstruída regularmente por um procedimento que cria os dados em uma tabela de preparação e, em seguida, alterna os dados para a tabela de produção usando a ALTER TABLE .. SWITCH TO ..instrução.

Exemplo:

BEGIN TRAN;

-- Rebuild indexes
ALTER INDEX IX_NC_GroupEvent_staging_GroupName on [dbo].[GroupEvent_staging]
   REBUILD;

ALTER INDEX IX_NC_GroupEvent_staging_Created ON [dbo].[GroupEvent_staging]
   REBUILD;

-- Empty production table
TRUNCATE TABLE [dbo].[GroupEvent];

-- Switch data from staging-table into production table
ALTER TABLE [dbo].[GroupEvent_staging] SWITCH TO [dbo].[GroupEvent]

COMMIT;

Quando esta operação é executada, o estado atual dos índices (ou dados de índice, se preferir) também é alterado? Pergunto por 2 motivos:

1) Para executar uma SWITCH TOinstrução, um requisito é que tanto a tabela de origem quanto a de destino devem conter índices idênticos. Isso me leva a acreditar que os dados do índice também podem ser trocados, mas não sei como verificar isso.
2) O principal benefício de construir a mesa dessa maneira é evitar o trabalho excessivo na mesa de produção durante o uso. Naturalmente, ficaria muito feliz se eu pudesse reconstruir os índices na tabela de preparação e fazer com que os índices reconstruídos fossem trocados para os índices de produção junto com a tabela.

Ao escrever procedimentos, ocasionalmente encontro situações nas quais desejo abortar o procedimento, mesmo que a situação não tenha necessariamente acionado um erro.

Digamos que, se eu não quiser que John execute este procedimento, eu faria algo assim:

IF @UserName = 'John'
BEGIN
    RAISERROR('John, get out', 16, 1);
    RETURN 1;
END

Eu realmente não tenho um bom motivo para retornar 1, é principalmente um resquício do script de shell e estou aberto a melhores maneiras de fazer isso.

Existe uma maneira melhor de retornar uma mensagem de erro e retornar o controle ao chamador para situações indesejadas que não sejam erros estritamente falando? Não estou interessado em reduzir a quantidade de caracteres ou linhas de código. Eu apenas tive um pressentimento dizendo "esta provavelmente não é a melhor maneira de resolver este problema" e fiquei curioso para saber se havia maneiras mais inteligentes de fazer isso.

Uma alternativa poderia ser sempre usar TRY/CATCH, já que RAISERRORcom uma severidade de 1-19 passará o controle para a cláusula catch.

Exemplo:

BEGIN TRY
    PRINT 'Before RAISERROR';
    RAISERROR('Time for errors', 16, 1);
    PRINT 'After RAISERROR'
END TRY
BEGIN CATCH
    DECLARE @Msg NVARCHAR(255) = ERROR_MESSAGE()
    PRINT 'Inside CATCH'
    RAISERROR(@Msg, 16, 1)
END CATCH

Resultado:

Before RAISERROR
Inside CATCH
Msg 50000, Level 16, State 1, Line 13
Time for errors

Con: Requer a presença de TRY/CATCHblocos.

Temos uma tabela um pouco pesada que é semi-freqüentemente (a cada ~ 5 minutos) sendo recriada por um procedimento. Eu me perguntei se havia algo que poderia ser feito para minimizar o tempo de inatividade durante a reconstrução da tabela e pensei em duas possibilidades até agora (vamos chamar a tabela de "Dispositivo"):

Opção A
1) Crie a nova tabela no procedimento, nomeie-a Device_new
2) Renomeie a tabela antiga de Devicepara Device_old
3) Renomeie a nova tabela de Device_newparaDevice

Opção B
Igual à Opção A, exceto pelo uso de Troca de Partição.
Advertência : a troca de partição é significativamente mais complexa de configurar e possui requisitos bastante rígidos para uso.

Essas opções são soluções ruins, se sim, como você resolveria esse caso de uso? Obrigada.

Recentemente, escrevi um script T-SQL para realizar algumas atualizações e inserções em 3 tabelas diferentes. Eu queria que isso fosse feito em uma única transação, então li a documentação da Microsoft sobre como usar transações explícitas com try/catch.

De acordo com a documentação , pode ser feito assim:

BEGIN TRANSACTION;

BEGIN TRY
    -- Generate a constraint violation error.
    DELETE FROM Production.Product
    WHERE ProductID = 980;
END TRY

BEGIN CATCH
    SELECT 
        ERROR_NUMBER() AS ErrorNumber
        ,ERROR_SEVERITY() AS ErrorSeverity
        ,ERROR_STATE() AS ErrorState
        ,ERROR_PROCEDURE() AS ErrorProcedure
        ,ERROR_LINE() AS ErrorLine
        ,ERROR_MESSAGE() AS ErrorMessage;

    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
END CATCH;

IF @@TRANCOUNT > 0
    COMMIT TRANSACTION;
GO

Portanto, implementei esse padrão e coloquei todas as minhas atualizações e inserções na cláusula TRY. O problema é que o código conseguiu deixar uma transação aberta após o término da consulta, e não vejo como isso aconteceria. Independentemente do trabalho feito dentro da cláusula TRY, quais cenários possíveis poderiam fazer com que uma consulta como essa deixasse uma transação aberta?

O fluxo de controle do meu pacote SSIS não está se comportando como esperado.

O que eu quero alcançar :

1. Teste se o CLR está ativado no SQL Server usando

   SELECT value
   FROM   sys.configurations
   WHERE  name = 'clr enabled'
   

2. Se value == 0, tente ativar o CLR e exibir a mensagemServer is configured.
3. Se value == 1, exibir mensagemServer is configured.

Esse fluxo funciona conforme o esperado. No entanto, gostaria de, se value == 0, continuar no MessageBox após Enable CLR on Server.

Eu tentei mudar o fluxo de controle para isso

Agora, o que acontece é o seguinte:

• value == 0[CLR ativado no servidor] passa o controle para [Ativar CLR no servidor], que é concluído e encerrado.
• value == 1[CLR ativado no servidor] é concluído e encerrado.

[MessageBox-Server is Configured] nunca é atingido.

Alguém pode me ajudar a entender isso e/ou me indicar um bom recurso sobre o fluxo de controle condicional do SSIS?