adam.g's questions

Não consigo encontrar detalhes sobre como SNAPSHOT ISOLATIONfunciona. Testei a seguinte consulta no SQL Server 2019 (com o ADR desabilitado):

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRAN;
WAITFOR DELAY '00:00:20'; -- insert of one record to dbo.MARA_CT in different session
SELECT
    *
FROM dbo.MARA_CT AS mc;
WAITFOR DELAY '00:00:20'; -- insert of one record to dbo.Album in different session
SELECT
    *
FROM dbo.Album AS a;
WAITFOR DELAY '00:00:20';
SELECT
    *
FROM dbo.MARA_CT AS mc;
SELECT
    *
FROM dbo.Album AS a;
COMMIT;

Conforme observado no comentário, inseri uma linha em dbo.MARA_CTe, durante a segunda WAITFOR DELAY, inseri um registro em dbo.Album. De acordo com a documentação da Microsoft:

The term "snapshot" reflects the fact that all queries in the transaction see the same version, or snapshot, of the database, based on the state of the database at the moment in time when the transaction begins.

Os resultados que obtive da minha consulta são os seguintes:

1. dbo.MARA_CT contém o registro inserido durante o primeiro WAITFOR DELAY '00:00:20'.
2. dbo.Album não contém o registro inserido durante o segundo WAITFOR DELAY '00:00:20'.

Parece-me que o "primeiro contato" com qualquer tabela na consulta cria um "instantâneo" de toda a transação, em vez de capturar o estado do banco de dados no momento em que a transação começa. Em relação a isso SNAPSHOT ISOLATION, tenho perguntas adicionais:

1. O ISOLAMENTO DE SNAPSHOT armazena todas as versões desde o início da transação para todas as linhas do banco de dados ou apenas para as tabelas usadas na consulta? Como isso funciona?

2. Se o RCSI estiver habilitado e posteriormente habilitarmos o ISOLAMENTO DE SNAPSHOT, o SQL Server armazenará novos valores/versões no tempdb?

3. O objetivo do uso, SNAPSHOT ISOLATIONno meu caso, é testar novas versões de procedimentos e visualizações (novo esquema). Tanto os procedimentos novos quanto os antigos precisam retornar o mesmo número de registros e utilizar os mesmos dados, mesmo que as tabelas envolvidas passem por constantes inserções, atualizações e exclusões. Considerei usar um snapshot do banco de dados, mas agora vejo que SNAPSHOT ISOLATIONpode ser ainda mais vantajoso, já que o RCSI já está habilitado nos bancos de dados.

Tenho que criar o DACPAC a partir do banco de dados de produção. Gostaria de fazer isso por meio do Visual Studio 2022 (SQL Server Object Explorer e "Extract - Data-tier application"). É possível bloquear algum processo/consulta ou utilizar mais CPU/memória para fazer isso?

Temos SQL Servers com versões SQL Server 2016 e SQL Server 2019. Já verificamos que podemos fazer failover no SQL Server 2019 sem listener mas não consigo testar no SQL Server 2016. Sabe se também é possível?

Por enquanto, nosso SQL Server de produção é Standard_D96ds_v5uma máquina Azure VM.
Recebemos uma solicitação para verificar se podemos reduzir o tamanho do servidor para Standard_D48ds_v5.

Que medidas tomaremos em consideração para termos a confirmação de que podemos reduzir o tamanho do servidor?

Estamos usando o SQL Server 2016. Tivemos alguns problemas em termos de duração das consultas em 11/09/2023. Gostaria de verificar no QueryStore e vi no query store executado em 11/09/2023 às 17:00:

Que temos muito mais contagens de execução em 11/09/2023 (cerca de 1150 VS 800 em 08/09/2023). Eu executo a mesma verificação do Query Store em 12/09/2023 e vejo que a contagem de execuções de ontem é muito menor do que verifiquei ontem.

Você sabe por que temos tanta diferença? Além disso, ainda vejo que a contagem de execuções ainda está diminuindo em 11/09/2023.

As configurações do armazenamento de consultas foram adicionadas.

Execução da consulta 14/09/2023 às 9h52:

Execução da consulta 14/09/2023 às 10h53:

Execução da consulta 14/09/2023 12h36: Até 11/09/2023 foi alterado...

Eu gostaria de criar uma transação que irá:

1. DESATIVAR o rastreamento de alterações SE existir.
2. Partição TRUNCATE para tabela.
3. MUDE A PARTIÇÃO de uma tabela diferente para a tabela principal.
4. ATIVAR o rastreamento de alterações SE foi desativado antes.

Gostaria de criar um script com parâmetros, então usarei SQL dinâmico. Ideia:

/* OPS parameters */
DECLARE @schemaName sysname = 'dbo';
DECLARE @tableName sysname = 'TABLE';
DECLARE @partition INT = 90;  

/* DEV parameters */
DECLARE @tableNameSRP sysname = CONCAT(@tableName, '_SRP');
DECLARE @tableNameWithSchema sysname = CONCAT(QUOTENAME(@schemaName), '.', QUOTENAME(@tableName));
DECLARE @tableNameWithSchemaSRP sysname = CONCAT(QUOTENAME(@schemaName), '.', QUOTENAME(@tableNameSRP));
DECLARE @isCtReEnabled BIT = 0;
DECLARE @isDebug BIT = 1;


SET TRAN ISOLATION LEVEL READ UNCOMMITTED;
SET XACT_ABORT ON;
BEGIN TRAN;
BEGIN TRY
    IF EXISTS (
        SELECT
            1
        FROM sys.change_tracking_tables
        WHERE object_id = OBJECT_ID(@tableNameWithSchema)
    )
    BEGIN

        SET @statement = N'ALTER TABLE ' + @tableNameWithSchema + N' DISABLE CHANGE_TRACKING;';
        IF (@isDebug = 0)
        BEGIN
            EXEC sp_executesql @stmt = @statement;
        END;
        IF (@isDebug = 1)
        BEGIN
            RAISERROR('[INFO] SQL: %s', 0, 1, @statement) WITH NOWAIT;
        END;
        SET @isCtReEnabled = 1;
    END;

    SET @statement
        = N'TRUNCATE TABLE ' + @tableNameWithSchema + N' WITH (PARTITIONS (' + CAST(@partition AS NVARCHAR(5)) + N')) 
ALTER TABLE '        + @tableNameWithSchemaSRP + N' SWITCH PARTITION ' + CAST(@partition AS NVARCHAR(5)) + N' TO ' + @tableNameWithSchema + N' PARTITION '
          + CAST(@partition AS NVARCHAR(5));
    IF (@isDebug = 0)
    BEGIN
        EXEC sp_executesql @stmt = @statement;
    END;
    IF (@isDebug = 1)
    BEGIN
        RAISERROR('[INFO] SQL: %s', 0, 1, @statement) WITH NOWAIT;
    END;

    IF (@isCtReEnabled = 1)
    BEGIN
        SET @statement = N'ALTER TABLE ' + @tableNameWithSchema + N' ENABLE CHANGE_TRACKING;';
        IF (@isDebug = 0)
        BEGIN
            EXEC sp_executesql @stmt = @statement;
        END;
        IF (@isDebug = 1)
        BEGIN
            RAISERROR('[INFO] SQL: %s', 0, 1, @statement) WITH NOWAIT;
        END;
    END;
    COMMIT;

END TRY
BEGIN CATCH
    SET @errorMessage = ERROR_MESSAGE();
    RAISERROR('ERROR MESSAGE: %s', 0, 1, @errorMessage) WITH NOWAIT;
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
END CATCH;

Minhas perguntas:

1. Operações como ENABLE/DISABLE change tracking, TRUNCATE e PARTITION SWITCH funcionarão em uma transação? (quer executar tudo ou nada)
2. O SQL dinâmico é um problema neste caso?

Eu vi alguém trocando o código abaixo:

SELECT
    PK1
    , PK2
    , PK3
    , PK4
    , C
    , B
    , SUM(NUMERIC_1)
    , SUM(NUMERIC_2)
    , MAX(NUMERIC_3)
    , SUM(NUMERIC_4)
FROM MATDOC_EXTRACT
WHERE A = ''
      AND (
          (
              (
              B = ''
              OR B = 'K'
          )
              AND (
                  C = '01'
                  OR C = '02'
                  OR C = '07'
                  OR C = '08'
              )
          )
          OR (
              B = ''
              AND (
                  C = '03'
                  OR C = '04'
              )
          )
      )
GROUP BY PK1
         , PK2
         , PK3
         , PK4
         , C
         , B;

para este

SELECT
    PK1
    , PK2
    , PK3
    , PK4
    , C
    , B
    , SUM(NUMERIC_1)
    , SUM(NUMERIC_2)
    , MAX(NUMERIC_3)
    , SUM(NUMERIC_4)
FROM sap.MATDOC_EXTRACT
WHERE A = N''
      AND B = N''
      AND C IN (N'01', N'02', N'07', N'08', N'03', N'04')
GROUP BY PK1
         , PK2
         , PK3
         , PK4
         , C
         , B
UNION ALL
SELECT
    PK1
    , PK2
    , PK3
    , PK4
    , C
    , B
    , SUM(NUMERIC_1)
    , SUM(NUMERIC_2)
    , MAX(NUMERIC_3)
    , SUM(NUMERIC_4)
FROM sap.MATDOC_EXTRACT
WHERE A = N''
      AND B = N'K'
      AND C IN (N'01', N'02', N'07', N'08')
GROUP BY PK1
         , PK2
         , PK3
         , PK4
         , C
         , B;

eles são iguais?

Estou construindo um aplicativo que precisa ter a opção de configurar (desativar/ativar) o controle de alterações em tabelas em um banco de dados específico. Estou me conectando ao banco de dados via usuário SQL. Quais permissões de banco de dados precisam ser adicionadas para o usuário SQL para desativar/ativar o rastreamento de alterações nas tabelas e a opção de executar a consulta abaixo:

SELECT DISTINCT
       sct1.name                                             AS CT_schema
       , sot1.name                                           AS CT_table
       , ps1.row_count                                       AS CT_rows
       , sct2.name                                           AS tracked_schema
       , sot2.name                                           AS tracked_name
       , CHANGE_TRACKING_MIN_VALID_VERSION(sot2.object_id)   AS min_valid_version
       , itt.create_date                                     AS change_tracking_table_creation_date
       , CAST(ps1.reserved_page_count * 8. / 1024 AS BIGINT) AS CT_reserved_MB
       , CAST(ps2.reserved_page_count * 8. / 1024 AS BIGINT) AS tracked_base_table_MB
       , ps2.row_count                                       AS tracked_rows
FROM sys.internal_tables            it
JOIN sys.objects                    sot1
  ON it.object_id = sot1.object_id
JOIN sys.schemas                    AS sct1
  ON sot1.schema_id = sct1.schema_id
JOIN sys.dm_db_partition_stats      ps1
  ON it.object_id = ps1.object_id
     AND ps1.index_id IN (0, 1)
LEFT JOIN sys.objects               sot2
       ON it.parent_object_id = sot2.object_id
LEFT JOIN sys.schemas               AS sct2
       ON sot2.schema_id = sct2.schema_id
LEFT JOIN sys.dm_db_partition_stats ps2
       ON sot2.object_id = ps2.object_id
          AND ps2.index_id IN (0, 1)
INNER JOIN sys.internal_tables      itt
        ON itt.name = sot1.name
WHERE it.internal_type IN (209, 210);

No SQL Server 2016 (13.0.6300.2) temos uma tabela com duas colunas XML e cerca de 1 500 000 linhas. O tamanho da tabela é de cerca de 150 GB. Qual é a melhor opção para comprimir esta tabela? Eu estava verificando a compactação PAGE no ambiente de desenvolvimento, mas economiza apenas 3%. É possível que no Sql Server 2019 (atualização planejada em um futuro próximo) seja melhor?

Existe alguma opção para ver sessões encerradas no Query Store?

Estou perguntando, porque temos uma ferramenta adicional que está encerrando as sessões se elas demorarem mais de 30 minutos para serem executadas ( KILLcomando).

Gostaria de verificar os planos de execução no Repositório de Consultas para consultas que foram encerradas. Não consigo encontrar sessões/consultas de armazenamento de consultas que foram eliminadas por este aplicativo adicional.

Eu forço o plano no armazenamento de consultas. O plano está conectado ao procedimento em um trabalho que é executado uma vez por dia. Uma das etapas deste trabalho é apenas:

EXEC [schema].[LoadData]

O procedimento [esquema].[LoadData] se parece com

TRUNCATE TABLE [schema].[Data];
     
    INSERT INTO [schema].[Data]
           ([A1],
           [A2],
          .
          .
          .,
          [A49]
    )                
    SELECT *
        ,CURRENT_TIMESTAMP AS [Insert TimeStamp] 
    FROM [schema].[View]   

onde view é uma view que contém alguns CTEs e usa sinônimos (conectar a tabelas de diferentes bancos de dados).

Na execução do armazenamento de consultas se parece com:

Para testar se o plano de forçar está funcionando, sigo as etapas abaixo:

1. Executar consulta no SSMS ->EXEC [schema].[LoadData]
2. A execução acima foi tratada como uma consulta diferente, portanto, não viu nada de novo no Query Store para a consulta = 7
3. O DBA cria um novo trabalho apenas com a etapa que está executando a consulta ->EXEC [schema].[LoadData]
4. Execução do trabalho recém-criado acima causa ID do plano = 29800

Pergunta por que o plano de execução não foi forçado? Na coluna "contagem de falhas de plano forçado" é 0.

Preciso simular erro no Sql Server:

“Msg 0, Level 20 A severe error occurred on the current command”

porque nossos desenvolvedores precisam lidar com isso no aplicativo.

Como posso simular/acionar esse tipo de erro? (Também posso tentar no meu localhost).

Gostaria de perguntar porque não consigo encontrar esta informação.

O plano de força do Repositório de Consultas persiste após a reinicialização do servidor?

Em quais casos, forçar um plano por meio do armazenamento de consultas não permanecerá em vigor?

Recebemos um ticket do cliente que está relatando que às vezes obtém dados parciais da consulta. Na consulta de palavras simples, há uma consulta em exibição:

SELECT column1, column2, column3, column4, column5, column6 ... column50 
from [dbo].[view]

Ver retorno de cerca de 3 milhões de registros. No servidor temos algumas regras que matam a consulta após 30 minutos de execução. Em situação normal esta consulta demora cerca de 5 minutos mas em casos de grande carga de trabalho esta consulta demora mais de 30 minutos. Nesta situação, o cliente pode obter dois tipos de erros:

• Uma consulta eliminada que retorna

“Msg 596, Level 21 Não é possível continuar a execução porque a sessão está no estado kill”

o que faz com que o nó de importação do aplicativo falhe e, portanto, é a situação “ideal”, porque eles não dependem de um fluxo de trabalho com conjunto de dados de entrada parcial.

• Um cenário relacionado ao processo de morte com um

“Msg 0, Level 20 Ocorreu um erro grave no comando atual”

que de uma perspectiva ODBC parece o mesmo que uma execução bem-sucedida e, portanto, terminamos com um conjunto de dados parcial - essa é a situação mais perigosa.

Você sabe talvez como evitar esse tipo de problema?