Mark Storey-Smith's questions

Implementando um esquema de partição rotativa, por kejser.org/table-pattern-rotating-log-ring- . Tive um problema com DATEDIFF arredondando valores:

DECLARE @Partitions INT = 15;

SELECT
    a1.dt
    , dtTrunc 
    , dtDiff
    , PartitionKey = CAST(DATEDIFF(DAY, 0, dtDiff) % @Partitions AS TINYINT)
FROM
    (
    VALUES
        ('2024-08-17 23:59:59.997')
        , ('2024-08-17 23:59:59.998')
        , ('2024-08-17 23:59:59.999')
        , ('2024-08-18 00:00:00.000')
    )
    AS v(dt)
CROSS APPLY
    (
    SELECT
        dt = CAST(v.dt AS DATETIME2(3))
    ) a1
CROSS APPLY
    (
    SELECT
        dtTrunc = CAST(a1.dt AS DATE)
        , dtDiff = DATEDIFF(day, 0, a1.dt)
    ) a2

Problema resolvido com elenco até o momento:

DECLARE @Partitions INT = 15;

SELECT
    a1.dt
    , dtTrunc 
    , dtDiff
    , PartitionKey = CAST(DATEDIFF(DAY, 0, dtDiff) % @Partitions AS TINYINT)
FROM
    (
    VALUES
        ('2024-08-17 23:59:59.997')
        , ('2024-08-17 23:59:59.998')
        , ('2024-08-17 23:59:59.999')
        , ('2024-08-18 00:00:00.000')
    )
    AS v(dt)
CROSS APPLY
    (
    SELECT
        dt = CAST(v.dt AS DATETIME2(3))
    ) a1
CROSS APPLY
    (
    SELECT
        dtTrunc = CAST(a1.dt AS DATE)
        , dtDiff = DATEDIFF(day, 0, CAST(a1.dt AS DATE))
    ) a2

Esse é um comportamento esperado/documentado? Se sim, onde?

Esta é uma questão puramente acadêmica, na medida em que não está causando nenhum problema e estou apenas interessado em ouvir alguma explicação para o comportamento.

Pegue uma tabela de contagem CTE de junção cruzada padrão de Itzik Ben-Gan:

USE [master]
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

CREATE FUNCTION [dbo].[TallyTable] 
(   
    @N INT
)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN 
(
    WITH 
    E1(N) AS 
    (
        SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
        SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
        SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1
    )                                       -- 1*10^1 or 10 rows
    , E2(N) AS (SELECT 1 FROM E1 a, E1 b)   -- 1*10^2 or 100 rows
    , E4(N) AS (SELECT 1 FROM E2 a, E2 b)   -- 1*10^4 or 10,000 rows
    , E8(N) AS (SELECT 1 FROM E4 a, E4 b)   -- 1*10^8 or 100,000,000 rows

    SELECT TOP (@N) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS N FROM E8 
)
GO

Emita uma consulta que criará uma tabela de número de linha de 1 milhão:

SELECT
    COUNT(N)
FROM
    dbo.TallyTable(1000000) tt

Dê uma olhada no plano de execução paralela para esta consulta:

Observe que a contagem de linha 'real' antes do operador de coleta de fluxos é 1.004.588. Após o operador de coleta de fluxos, a contagem de linhas é de 1.000.000 esperados. Mais estranho ainda, o valor não é consistente e varia de execução para execução. O resultado da CONTAGEM é sempre correto.

Emita a consulta novamente, forçando o plano não paralelo:

SELECT
    COUNT(N)
FROM
    dbo.TallyTable(1000000) tt
OPTION (MAXDOP 1)

Desta vez, todos os operadores mostram as contagens de linha 'reais' corretas.

Eu tentei isso em 2005SP3 e 2008R2 até agora, mesmos resultados em ambos. Alguma ideia do que pode causar isso?

Estou planejando a migração ao vivo de um banco de dados de 2 TB para tabelas particionadas. O sistema é basicamente um armazenamento de documentos, sendo a maior parte do espaço alocado para LOBs entre 50kb e 500kb, com uma pequena porcentagem na faixa de 500kb a 1MB. Parte da migração envolverá dados BCPing do banco de dados antigo para o novo.

O BCP é a abordagem preferida, pois a divisão atual/histórica nos dados permite extrair os dados mais antigos em estágios (durante períodos mais silenciosos) antes de uma troca final, minimizando o impacto no sistema ativo. O volume de dados e a disponibilidade de armazenamento impedem uma reconstrução in-situ para um esquema de partição .

Suspeito que haja alguns ganhos de desempenho ao experimentar KILOBYTES_PER_BATCH em vez de ROWS_PER_BATCH, devido ao conteúdo BLOB. É sugerido na documentação do BCP que o SQL pode otimizar as operações com base nesse valor.

O que não consigo encontrar é nenhuma orientação sobre a natureza dessas otimizações ou por onde começar meus testes. Na ausência de sugestões, tentarei corridas curtas nos limites de 4/8/16/32/64 MB para começar.

Provavelmente, alguns ganhos são decorrentes da alteração do tamanho do pacote (parâmetro BCP -a, em vez da configuração do nível do servidor), mas estou inclinado a aumentar isso para o máximo de 65535, a menos que alguém tenha uma abordagem mais estereotipada.

Tenho um estoque de definições de rastreamento com script que uso para diferentes níveis de diagnóstico, nenhum dos quais é filtrado por HostName. Eu precisava filtrar o tráfego por host hoje, então:

1. Perfilador acionado
2. Criou um traço vazio
3. Adicionado SP: Iniciar/Concluir
4. Defina um filtro no nome do host
5. Script para o arquivo test.sql

Arquivo aberto no SSMS, sem sinal do filtro. Enxágue, repita, o mesmo novamente. Supondo que eu estava fazendo algo estúpido , procurei o valor a ser usado (mais difícil de encontrar do que deveria ser!) E adicionei à minha definição de rastreamento manualmente, o que funcionou.

EXEC sp_trace_setfilter @TraceId, 8, 0, 6, N'MyHostName'

Voltei para verificar por que não consegui fazer isso funcionar no Profiler e no mesmo resultado. Eu encontrei a menção de que isso é um problema ao criar scripts para 2000 do SSMS, mas nenhuma menção a essa situação com os servidores SSMS2005/2008 a 2005/2008. Isso é um bug no Profiler?