Jānis's questions

Estou executando a consulta, que produz o plano:

Estatística IO:

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 128, logical reads 5952, physical reads 576, read-ahead reads 6080, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Table1'. Scan count 9, logical reads 90450, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Então, algumas perguntas

1. Por que o Statistics IO mostra leituras mais altas do que o Profiler? .

Quanto ao KB314648 , tudo bem se o Profiler relatar números mais altos do que o Statistics IO. Mas o Profiler mostra 92283as leituras na consulta descrita, na mesma execução. Isso significa que o Profiler não conta as leituras do arquivo de trabalho/tabela de trabalho?

2. Qual é a diferença entre "Worktable" e "Workfile"

Eu descobri que:

• arquivos de trabalho podem ser usados ​​para armazenar resultados temporários para junções de hash e agregações de hash.
• tabelas de trabalho podem ser usadas para armazenar resultados temporários para spool de consulta, variáveis ​​lob, variáveis ​​XML e cursores.

Existe alguma diferença física entre eles?

3. Por que existe "Worktable" neste caso particular?

Por que eu tenho uma mesa de trabalho, se houver 0 leituras lógicas? Está incluído nas estatísticas IO apenas porque pode ser necessário (no caso de estimativas incorretas)?

A descrição encontrada no technet parece vaga.

4. O que significa "leituras físicas" no arquivo de trabalho?

Isso significa que não havia memória suficiente concedida para a consulta, então os dados tiveram que ser gravados no disco enquanto a consulta é executada (aviso amarelo no Hash Match)? Posso presumir que sempre que vejo a tabela de trabalho/arquivo de trabalho no Statistics IO com leituras físicas, não há memória suficiente concedida para a consulta e alguns resultados intermediários da consulta tiveram que ser gravados no disco tempdb? E sempre que vejo apenas leituras lógicas, a RAM é usada?

5. Um "arquivo de trabalho" significa exatamente uma tabela que é usada para um propósito?

Se houver mais de um arquivo/mesa de trabalho, não posso saber para qual operação ele é usado.

Por que não há verificação completa (no SQL 2008 R2 e 2012)?

Dados de teste:

DROP TABLE dbo.TestTable
GO  
CREATE TABLE dbo.TestTable
(
   TestTableID INT IDENTITY PRIMARY KEY,
   VeryRandomText VarChar(50),
   VeryRandomText2 VarChar(50)
)
Go
Set NoCount ON
Declare @i int
Set @i = 0
While @i < 10000
Begin
   Insert Into dbo.TestTable(VeryRandomText, VeryRandomText2)
      Values(Cast(Rand()*10000000 as VarChar(50)), Cast(Rand()*10000000 as VarChar(50)));
   Set @i = @i + 1;
End
Go
CREATE Index IX_VeryRandomText On dbo.TestTable
(
    VeryRandomText
)
Go

Ao executar a consulta:

Select * From dbo.TestTable Where VeryRandomText = N'111' -- bad

Receba um aviso (como esperado, porque comparando os dados nchar com a coluna varchar):

<PlanAffectingConvert ConvertIssue="Cardinality Estimate" Expression="CONVERT_IMPLICIT(nvarchar(50),[DemoDatabase].[dbo].[TestTable].[VeryRandomText],0)" />

Mas então vejo o plano de execução e posso ver que ele não está usando a varredura completa como eu esperaria, mas sim a busca de índice.

Claro, isso é bom, porque neste caso particular a execução é muito mais rápida do que se houvesse varredura completa.

Mas não consigo entender como o SQL Server tomou a decisão de fazer esse plano.

Além disso, se o agrupamento do servidor fosse agrupamentos do Windows no nível do servidor e no nível do banco de dados de agrupamento do SQL Server, isso causaria uma verificação completa na mesma consulta.

Existe uma maneira de saber quando ocorre a limpeza das tabelas de controle de alterações? Como verificar a última ocorrência de um processo de limpeza?

FUNDO:

Eu tenho o Change Tracking no banco de dados com retenção definida para 1 minuto:

ALTER DATABASE [test] SET CHANGE_TRACKING = ON (CHANGE_RETENTION = 1 MINUTES)

Eu faço algumas atualizações em minha tabela de teste e espero um pouco mais do que o período de retenção (digamos 3 minutos). Como o processo de limpeza é assíncrono, entendo que NÃO há garantia de que as tabelas de controle de alterações serão limpas após 1 minuto. Pode acontecer a qualquer momento > 1 min.

Encontrei este procedimento para chamar o processo de limpeza manualmente:

EXEC sp_flush_commit_table_on_demand 100000

Mas não funciona como esperado. (As linhas de rastreamento de alterações ainda estão no local após o período de retenção)

MSDN " Missing Join Predicate Event Class " diz que " indica que uma consulta está sendo executada sem nenhum predicado de junção ".

Mas infelizmente não parece ser tão fácil assim.

Por exemplo, situação muito simples:

create table #temp1(i int);
create table #temp2(i int);
Select * from #temp1, #temp2 option (recompile);

Não há dados nas tabelas, também não há aviso, embora obviamente não tenha predicado de junção.

Se eu der uma olhada na documentação do SQL Server 2005 (o mesmo link, apenas outra versão do servidor), há uma frase extra: " Este evento é produzido apenas se ambos os lados da junção retornarem mais de uma linha. " perfeito sentido na situação anterior. Não há dados, então ambos os lados retornam 0 linhas e nenhum aviso. Insira linhas, receba um aviso. OK legal.

Mas para a próxima situação confusa, insiro os mesmos valores nas duas tabelas:

Insert into #temp1 (i) values (1)
Insert into #temp1 (i) values (1)
Insert into #temp2 (i) values (1)
Insert into #temp2 (i) values (1)

E eu recebo:

-- no warning:
Select * from #temp1 t1 
    inner join #temp2 t2 on t1.i = t2.i 
option (recompile)
-- has warning:
Select * from #temp1 t1 
    inner join (select 1 i union all select 1) t2 on t1.i = t2.i 
option (recompile)

Porque isto é assim?

Nota : alguns scripts que usei para detectar essas consultas ruins no meu servidor.

1. claro, plano de execução de procedimentos

2. usou o rastreamento de servidor padrão para encontrar avisos

   Declare @trace nvarchar(500);
   Select @trace = cast(value as nvarchar(500))
   From sys.fn_trace_getinfo(Null)
   Where traceid = 1 and property = 2;
   
   Select t.StartTime, te.name, *
   From sys.fn_trace_gettable(@trace, 1) t
       Inner join sys.trace_events te on t.EventClass = te.trace_event_id
       where EventClass = 80
   order by t.StartTime desc
   

3. cache do plano de execução, para encontrar esses planos com avisos (como este)

   WITH XMLNAMESPACES (default 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
   SELECT
       Cast('<?SQL ' + st.text + ' ?>' as xml) sql_text,
       pl.query_plan,
       ps.execution_count,
       ps.last_execution_time,
       ps.last_elapsed_time,
       ps.last_logical_reads,
       ps.last_logical_writes
   FROM sys.dm_exec_query_stats ps with (NOLOCK)
       Cross Apply sys.dm_exec_sql_text(ps.sql_handle) st
       Cross Apply sys.dm_exec_query_plan(ps.plan_handle) pl
   WHERE pl.query_plan.value('(//Warnings/@NoJoinPredicate)[1]', 'bit') = 1
   Order By last_execution_time desc
   OPTION (RECOMPILE);
   

Existe uma maneira de saber quantas tarefas externas (aplicativos de console) estão lendo a fila?

Estou usando o ativador externo do Service Broker.

O que eu quero é algo semelhante às informações que recebo de sys.dm_broker_activated_tasks , apenas para leitores de fila externos.

Eu tenho 2 esquemas, digamos sch1 e sch2 . Cada propriedade de um usuário diferente.

Eu quero conceder direitos SELECT em sch2.MyTable (mas apenas este objeto) para sch1 procedures/views E permitir fazer referência a sch2.MyTable em restrições de chave estrangeira sch1 .

Eu NÃO quero tornar o sch2.MyTable diretamente acessível para aqueles que usam procedimentos/visualizações do sch2 , mas deseja permitir o acesso indireto.

Basicamente sch2 é muito mais importante. Os proprietários de sch2 também têm controle de sch1, mas não vice-versa. Por outro lado, sch1 tem alguns dados que dependem de sch2 e eles devem poder vê-los e não devem permitir a exclusão de dados de sch2, enquanto sch1 ainda tem algumas dependências deles.

Isso é possível (talvez através de sinônimos)?

Pois não parece- não, não é possível. A menos que você fale sobre "Visualizações e restrições" OU "diferentes proprietários de esquema".

Estou usando a consulta para descobrir o tamanho do arquivo do banco de dados. Estou usando a visualização do sistema e o DMV, porque quero descobrir o tamanho real do arquivo e o tamanho teórico (no caso de arquivos esparsos ).

Select 
    DB_NAME(mf.database_id) AS [Database Name], 
    mf.Name,  
    mf.physical_name PhysicalName,
    cast(mf.size as bigint) * 8192 mfSize_bytes, 
    fs.size_on_disk_bytes fsSize_bytes
From sys.master_files mf
    Left Join sys.dm_io_virtual_file_stats(DEFAULT, DEFAULT) fs 
        On mf.database_id = fs.database_id and mf.file_id = fs.file_id
Order By DB_NAME(mf.database_id)

Estou confuso - converti os dois valores em "bytes", comparando-os. Mas em todas as instâncias que verifiquei, o tamanho do arquivo temdb (de sys.master_files) é menor que o tamanho do arquivo no disco (de sys.dm_io_virtual_file_stats).

Em todos os outros casos, se houver diferença, isso está correto (o tamanho no disco é realmente menor que o tamanho do arquivo - porque são arquivos esparsos).

Qual é a razão para esta diferença?

ATUALIZAÇÃO: Quando estou consultando

Select is_sparse, * From sys.database_files 

No instantâneo do banco de dados do SQL Server 2005, a coluna is_sparse = 0 (porque está mostrando as propriedades dos arquivos do banco de dados original, não do arquivo instantâneo. Portanto, há um bug na documentação ?).