孔夫子's questions

Isso está relacionado a um cenário de reversão de uma atualização de 2012 -> 2016.

O cenário é que o banco de dados SQL Server 2012 seja restaurado em 2016 e os arquivos de log sejam aplicados até que esteja atualizado. Em seguida, os sistemas de produção são cortados para 2016. O banco de dados é mantido no nível de compatibilidade para 2012. Subsequentemente, os logs incrementais da instância de 2016 são mantidos até a necessidade de reverter (digamos, 8 horas).

Os logs agora podem ser aplicados à instância do SQL Server 2012 para atualizá-la?

Considere estas consultas ( SQL Fiddle ):

Consulta 1:

SELECT * INTO #TMP1 FROM Foo
UNION
SELECT * FROM Boo
UNION
SELECT * FROM Koo;

Consulta 2:

SELECT * INTO #TMP2 FROM Foo
UNION
SELECT * FROM Boo
UNION ALL
SELECT * FROM Koo;

Observe que Koo não se sobrepõe a Boo/Foo, então o resultado final é o mesmo. A questão é por que a primeira combinação UNION / UNION não é mesclada em uma única operação SORT?

Eu tenho uma consulta que se parece com isso:

    SELECT *
      FROM TBLA A
 LEFT JOIN TBLB B ON A.Col1 = B.Col2
RIGHT JOIN TBLC C ON B.Col3 = C.Col4
      JOIN TBLD D ON C.Col5 = D.Col6

Em que ordem as junções serão resolvidas? Estou mais interessado no SQL Server e vou marcar uma explicação para ele como resposta, mas estou igualmente interessado no padrão ANSI/ISO e como ele funciona nos vários RDBMS.

O motivo dessa pergunta era descobrir por que os resultados diferiam dessa consulta

    SELECT *
      FROM TBLA A
CROSS JOIN TBLC C
 LEFT JOIN TBLB B ON A.Col1 = B.Col2 AND B.Col3 = C.Col4
      JOIN TBLD D ON C.Col5 = D.Col6

Normalmente, crio guias de plano construindo primeiro uma consulta que usa o plano correto e copiando-a para a consulta semelhante que não usa. No entanto, isso às vezes é complicado, especialmente se a consulta não for exatamente a mesma. Qual é a maneira correta de criar guias de plano do zero?

O SQLKiwi mencionou a elaboração de planos no SSIS, existe uma maneira ou ferramenta útil para auxiliar na elaboração de um bom plano para o SQL Server?

A instância específica em questão é esta CTE: SQLFiddle

with cte(guid,other) as (
  select newid(),1 union all
  select newid(),2 union all
  select newid(),3)
select a.guid, a.other, b.guid guidb, b.other otherb
from cte a
cross join cte b
order by a.other, b.other;

Existe ALGUMA maneira de fazer com que o resultado apareça com exatamente 3 guids distintos e não mais? Espero poder responder melhor às perguntas no futuro, incluindo guias de plano com consultas do tipo CTE que são referenciadas várias vezes para superar algumas peculiaridades do SQL Server CTE.

Isso está relacionado à contagem do número de registros que correspondem a uma determinada condição, por exemplo, invoice amount > $100.

eu costumo preferir

COUNT(CASE WHEN invoice_amount > 100 THEN 1 END)

No entanto, isso é tão válido

SUM(CASE WHEN invoice_amount > 100 THEN 1 ELSE 0 END)

Eu teria pensado que COUNT é preferível por 2 razões:

1. Transmite a intenção, que éCOUNT
2. COUNT provavelmente envolve uma i += 1operação simples em algum lugar, enquanto SUM não pode contar com sua expressão como um valor inteiro simples.

Alguém tem fatos específicos sobre a diferença em RDBMS específicos?

No final, há um script de teste para comparar o desempenho entre uma variável @table e uma tabela #temp. Acho que configurei corretamente - os tempos de desempenho são retirados dos comandos DELETE/TRUNCATE . Os resultados que estou obtendo são os seguintes (tempos em milissegundos).

@Table Variable  #Temp (delete)  #Temp (truncate)
---------------  --------------  ----------------
5723             5180            5506
15636            14746           7800
14506            14300           5583
14030            15460           5386
16706            16186           5360

Só para ter certeza de que estou são, isso mostra que CURRENT_TIMESTAMP (também conhecido como GetDate()) é obtido no momento da instrução, não do lote, portanto, não deve haver interação entre TRUNCATE/DELETE com a SET @StartTime = CURRENT_TIMESTAMPinstrução.

select current_timestamp
waitfor delay '00:00:04'
select current_timestamp

-----------------------
2012-10-21 11:29:20.290

-----------------------
2012-10-21 11:29:24.290

É bastante consistente no salto entre a primeira execução e as subsequentes quando DELETE é usado para limpar a tabela. O que estou perdendo em minha compreensão de DELETE ? Eu repeti isso muitas vezes, troquei a ordem, dimensionei o tempdb para não exigir crescimento, etc.

CREATE TABLE #values (
  id int identity primary key, -- will be clustered
  name varchar(100) null,
  number int null,
  type char(3) not null,
  low int null,
  high int null,
  status smallint not null
);
GO
SET NOCOUNT ON;

DECLARE @values TABLE (
  id int identity primary key clustered,
  name varchar(100) null,
  number int null,
  type char(3) not null,
  low int null,
  high int null,
  status smallint not null
);
DECLARE  @ExecutionTime  TABLE(      Duration bigINT    ) 
DECLARE  @StartTime DATETIME,  @i INT = 1; 
WHILE (@i <= 5) 
  BEGIN 
    DELETE @values;
    DBCC freeproccache With NO_InfoMSGS;
    DBCC DROPCLEANBUFFERS With NO_InfoMSGS;
    SET @StartTime = CURRENT_TIMESTAMP -- alternate getdate() 
    /****************** measured process ***********************/ 

    INSERT @values SELECT a.* FROM master..spt_values a join master..spt_values b on b.type='P' and b.number < 1000;

    /**************** end measured process *********************/ 
    INSERT @ExecutionTime 
    SELECT DurationInMilliseconds = datediff(ms,@StartTime,CURRENT_TIMESTAMP) 
    SET @i +=  1 
  END -- WHILE 

SELECT DurationInMilliseconds = Duration FROM   @ExecutionTime 
GO 

-- Temporary table
DECLARE  @ExecutionTime  TABLE(      Duration bigINT    ) 
DECLARE  @StartTime DATETIME,  @i INT = 1; 
WHILE (@i <= 5) 
  BEGIN 
    delete #values;
    -- TRUNCATE TABLE #values;
    DBCC freeproccache With NO_InfoMSGS;
    DBCC DROPCLEANBUFFERS With NO_InfoMSGS;
    SET @StartTime = CURRENT_TIMESTAMP -- alternate getdate() 
    /****************** measured process ***********************/ 

    INSERT #values SELECT a.* FROM master..spt_values a join master..spt_values b on b.type='P' and b.number < 1000;

    /**************** end measured process *********************/ 
    INSERT @ExecutionTime 
    SELECT DurationInMilliseconds = datediff(ms,@StartTime,CURRENT_TIMESTAMP) 
    SET @i +=  1 
  END -- WHILE 

SELECT DurationInMilliseconds = Duration FROM   @ExecutionTime 
GO

DROP TABLE  #values 
SET NOCOUNT OFF;

Consulte esta consulta relacionada: Qual é uma boa ferramenta para visualizar trabalhos do SQL Agent?

No entanto, não estou atrás de uma ferramenta visual, pois estou procurando construir minha própria visualização. Este é meu ponto de partida, mas você concordará que está faltando muito.

select TOP(1000)
       h.run_date, min(h.run_time), j.name, j.description, max(h.run_duration) run_duration
from msdb..sysjobhistory h
join msdb..sysjobs j on j.job_id = h.job_id
group by h.run_date, j.name, j.description, h.instance_id, j.job_id
having max(h.run_duration) > 1000  -- << -- 10 minutes encoded in HHMMSS (digits)
order by h.run_date desc, 2 desc

O ponto crucial é que não parece haver uma chave para a sysjobhistorytabela para identificá-la como uma "instância" específica de um arquivo sysjob. Por exemplo, uma tarefa iniciada às 12h30 com 4 etapas é inserida sysjobhistory4 vezes com diferentes instance_ids (exclusivos). Todos estão vinculados ao sysjob.job_idvalor, mas esse é o cronograma, não a invocação do trabalho. Existe outra tabela em que eu deveria olhar?

Isso provavelmente é bastante simples, já que o SSMS é capaz de fazer isso facilmente.

Escopo: Uma tabela de bilhões de registros que é indexada de 10 maneiras. A taxa de variação por dia é de 1/2 por cento.

Alguns dos índices estão aumentando monotonamente (datetime/timestamp), mas as consultas comuns provavelmente atingem o final. Presumo que as estatísticas precisem ser atualizadas com frequência para esse tipo, caso contrário, os dados recentes não serão representados no índice?

Outros índices são distribuídos de forma mais aleatória, por exemplo (chave do cliente, data e hora). Estes podem prescindir de atualizações menos frequentes, já que as estatísticas são bastante representativas do todo. Podemos deixar o índice mudar o suficiente para forçar atualizações automáticas de estatísticas neles, correto?

Para ambos os tipos, há algum benefício em aumentar a amostragem de 10% para 100%, se os dados a serem amostrados forem aleatórios e bastante representativos do todo?

Procurando as melhores práticas com dados de TB.

Isso está usando RC0 .

Eu configurei um Grupo de Disponibilidade AlwaysOn do SQL Server 2012 (ou mais precisamente, altamente provável, mas nem sempre ativado).

Eu coloco a Primária offline.

1. O Secundário leva até 25 segundos para assumir a função Primária.
2. Todas as consultas que estavam em execução no momento do failover retornam um erro ao cliente.

Qualquer pessoa que tenha testado esse novo recurso AlwaysOn pode validar meus resultados?

1. Em quanto tempo devo esperar que o failover seja executado e concluído?
2. Uma consulta em execução é reenviada para o novo Primário ou estou correto que isso causa um erro do tipo "falha na conexão" para o cliente?
3. A seguinte forma de string de conexão está correta, ou seja, sem "Failover_Partner" (porque isso não é espelhamento)?

ConnectionString=Provider=SQLOLEDB.1;Server=10.10.10.10;User ID=x;Password=y;Persist Security Info=True;Initial Catalog=z

Nota: tentei o seguinte, mas tudo o que recebo é "falha no link de conectividade" e nunca se recupera. Alguém poderia pensar que o cliente nativo funcionaria melhor?

ConnectionString=Provider=SQLNCLI11.1;Server=tcp:10.10.10.10,8888;User ID=x;Password=y;Persist Security Info=True;Initial Catalog=z