boot4life's questions

O controle de versão de linha mantém 14 bytes de informações de versão interna para cada linha. Mas isso é realmente um custo por linha ou é um custo que também se aplica a cada índice na tabela?

Parece que os 14 bytes também devem ser adicionados a todos os registros de índice para que as varreduras somente de índice (e outros acessos somente de índice) possam ver as informações de versão e perceber um instantâneo pontual dos dados.

Todas as informações que pude encontrar na web falam apenas sobre uma sobrecarga por linha de 14 bytes.

Observando a execução de consultas com estatísticas de consulta ao vivo, notei que parece que o SQL Server está construindo preguiçosamente uma tabela de hash a partir da entrada de compilação de uma junção de hash.

Esta é uma diferença significativa no caso de 0 linhas de sondagem. Ele potencialmente salva toda a árvore do lado da compilação.

Eu sempre pensei que um hash funcionasse assim:

1. Crie uma tabela de hash do lado da compilação.
2. Combine todas as linhas do probe com ele.

Mas é o seguinte?

1. Puxe a primeira linha de sonda.
2. Conclua a operação se nenhuma linha estiver disponível (curto-circuito).
3. Combine todas as linhas do probe com ele.

Não tenho certeza de como testar conclusivamente de que maneira é. Não tenho certeza se a saída das Estatísticas de consulta ao vivo pode ser confiável dessa maneira. Alguém sabe como isto funciona?

Estou no meio de um enorme REORGANIZE. A fim de acelerá-lo eu configurei DELAYED_DURABILITY = FORCED.

Isso afetará a instrução em execução? Observei os números de E/S e CPU no servidor e não consegui distinguir a diferença. Também não tenho certeza se haveria alguma diferença, então não posso dizer.

Minha tabela está assim:

GroupID INT NOT NULL
SomeValue INT NOT NULL

Eu gostaria de manter as linhas com o mesmo GroupIDconjunto no conjunto de resultados. Os próprios grupos devem ser ordenados aleatoriamente, no entanto. SomeValueé suposto ser o critério de classificação secundário. Assim:

GroupID, SomeValue
13, 1
13, 2
7, 1
7, 2
11, 1
11, 2
...

ORDER BY GroupID, SomeValuenão ordena os grupos aleatoriamente. ORDERBY NEWID()é totalmente aleatório. ORDER BY SomeHash(GroupID), SomeValuevem à mente, mas preciso de uma nova ordem aleatória a cada vez.

Como isso pode ser feito?

O Banco de Dados SQL do Azure dá suporte a exibições indexadas? Ele oferece suporte à correspondência automática de exibição indexada sem NOEXPAND? A resposta depende do tipo de preço?

Não consegui encontrar respostas definitivas para essas perguntas. O guia de diferenças de recursos não menciona exibições indexadas.

A documentação da exibição indexada não contém a palavra "Azure".

Quando você diz a + bem T-SQL e ae bsão do tipo string (por exemplo , varchar(...)ou nvarchar(...)): Como o tipo resultante é determinado?

Não encontrei regras claras para isso ao experimentar. Parece depender se literais estão envolvidos.

Além disso, como o comprimento é determinado? Eu descobri que o tipo de 'x' + 'y'é varchar(2). Aparentemente, o comprimento do literal está sendo rastreado.

Aqui está um pequeno experimento que fiz:

USE tempdb

DECLARE @v VARCHAR(400) = 'x'
DECLARE @n NVARCHAR(400) = 'x'

SELECT
    '' AS [varchar]
    , N'' AS [nvarchar]

    , ('x' + N'x') AS ['x' + N'x']
    , (N'x' + 'x') AS [N'x' + 'x']
    , (ISNULL('x', N'x')) AS [ISNULL('x', N'x')]
    , (ISNULL(N'x', 'x')) AS [ISNULL(N'x', 'x')]
    , (COALESCE('x', N'x')) AS [COALESCE('x', N'x')]
    , (COALESCE(N'x', 'x')) AS [COALESCE(N'x', 'x')]

    , (@v + @n) AS [@v + @n]
    , (@n + @v) AS [@n + @v]
    , (ISNULL(@v, @n)) AS [ISNULL(@v, @n)]
    , (ISNULL(@n, @v)) AS [ISNULL(@n, @v)]
    , (COALESCE(@v, @n)) AS [COALESCE(@v, @n)]
    , (COALESCE(@n, @v)) AS [COALESCE(@n, @v)]
INTO StringConversionTest

A documentação chama o comportamento de ISNULLe COALESCEentão eu entendo essa parte. Mas o +operador parece se comportar sob um conjunto mais complexo de regras.

Para economizar custos de licenciamento, estou avaliando se posso usar a Standard Edition para um VLDB. Vou delinear o cenário:

• Aqui, "VLDB" significa 5 TB.
• Espera-se que o tamanho seja estável ao longo do tempo.
• Quase todos os dados estariam em uma única tabela.
• A consulta e o padrão DML são um tipo de cenário de valor-chave. Existem apenas acessos de linha única por chave primária.

Eu me pergunto para que eu precisaria da Enterprise Edition. Eu não obteria nenhum benefício do particionamento porque não quero alternar partições ou colocá-las em armazenamentos diferentes. A compactação de dados pode nos economizar talvez 50%, mas usamos armazenamento barato. A economia seria insignificante em comparação com a licença cara.

Para HA, não vejo por que não poderia usar o espelhamento obsoleto, mas ainda funcionando. Isso não é o ideal, mas a Enterprise Edition é um preço alto a pagar por um benefício pouco claro.

Ainda assim, fico nervoso ao usar a Standard Edition aqui porque não é o que geralmente é recomendado e parece vagamente arriscado. Procurando alguns conselhos sobre esta situação. Obrigado!

Estou usando um ORM que executa consultas da forma:

SELECT Columns
FROM T
WHERE Col LIKE @p0 ESCAPE '~'

Colé indexado e o índice está cobrindo. O predicado é muito seletivo. As tabelas têm 500.000 linhas.

Estou sempre consultando um prefixo de string (por exemplo 'prefix%'). Claramente, isso não é conhecido estaticamente pelo SQL Server aqui. Mas sei que o SQL Server basicamente é capaz de buscar com base em um LIKEpadrão com um prefixo.

Gostaria que o SQL Server descobrisse em tempo de execução o intervalo relevante do índice a ser verificado e apenas verificasse esse intervalo. O plano de execução que estou obtendo tem uma varredura de índice, no entanto.

O ORM não suporta OPTION (RECOMPILE)e não tenho certeza se seria uma boa opção já que as consultas são executadas em cerca de 20 milissegundos. (No entanto, gostaria que essa consulta fosse mais rápida. Com uma busca, isso deve ser executado em ~ 1 ms).

Posso de alguma forma fazer o SQL Server realizar uma busca aqui?

Tenho uma consulta no seguinte formulário:

SELECT ...
FROM ColumnstoreTable cs
CROSS APPLY (
    SELECT *
    FROM (VALUES
        ('A', cs.DataA)
        , ('B', cs.DataB)
        , ('C', cs.DataC)
    ) x(Col0, Col1)
) someValues

Isso pega cada linha de uma subconsulta suportada por Columnstore ( ColumnstoreTable) e multiplica essas linhas. Este é essencialmente um arquivo UNPIVOT. A consulta real é maior do que isso. Essa parte da consulta alimenta outro processamento.

O problema aqui é que isso CROSS APPLYé implementado como uma junção de loop, o que é uma escolha razoável. Infelizmente, junções de loop não suportam o modo de lote.

Essa parte da consulta é muito crítica para o desempenho e suspeito que executá-la em modo de lote pode ser muito benéfica para o desempenho.

Como posso reescrever esta consulta para não sair do modo de lote?

Eu tentei usar uma tabela temporária em vez de VALUES, mas isso não mudou o fato de que não há condição de junção de igualdade para junção de hash.

A sintaxe normal JOIN ... ON ...é bem conhecida. Mas também é possível posicionar a ONcláusula separada daquela a JOINque corresponde. Isso é algo que raramente é visto na prática, não é encontrado em tutoriais e não encontrei nenhum recurso da web que sequer mencione que isso é possível.

Aqui está um script para brincar:

SELECT *
INTO #widgets1
FROM (VALUES (1), (2), (3)) x(WidgetID)


SELECT *
INTO #widgets2
FROM (VALUES (1, 'SomeValue1'), (2, 'SomeValue2'), (3, 'SomeValue3')) x(WidgetID, SomeValue)

SELECT *
INTO #widgetProperties
FROM (VALUES
    (1, 'a'), (1, 'b'),
    (2, 'a'), (2, 'b'))
x(WidgetID, PropertyName)


--q1
SELECT w1.WidgetID, w2.SomeValue, wp.PropertyName
FROM #widgets1 w1
LEFT JOIN #widgets2 w2 ON w2.WidgetID = w1.WidgetID
LEFT JOIN #widgetProperties wp ON w2.WidgetID = wp.WidgetID AND wp.PropertyName = 'b'
ORDER BY w1.WidgetID


--q2
SELECT w1.WidgetID, w2.SomeValue, wp.PropertyName
FROM #widgets1 w1
LEFT JOIN #widgets2 w2 --no ON clause here
JOIN #widgetProperties wp
 ON w2.WidgetID = wp.WidgetID AND wp.PropertyName = 'b'
 ON w2.WidgetID = w1.WidgetID
ORDER BY w1.WidgetID


--q3
SELECT w1.WidgetID, w2.SomeValue, wp.PropertyName
FROM #widgets1 w1
LEFT JOIN (
    #widgets2 w2 --no SELECT or FROM here
    JOIN #widgetProperties wp
    ON w2.WidgetID = wp.WidgetID AND wp.PropertyName = 'b')
ON w2.WidgetID = w1.WidgetID
ORDER BY w1.WidgetID

q1 parece normal. q2 e q3 têm esses posicionamentos incomuns da ONcláusula.

Este script não necessariamente faz muito sentido. Foi difícil para mim inventar um cenário significativo.

Então, o que esses padrões de sintaxe incomuns significam? Como isso é definido? Percebi que nem todas as posições e ordenações para as duas ONcláusulas são permitidas. Quais são as regras que regem isso?

Além disso, é sempre uma boa ideia escrever consultas como esta?

Eu tenho um índice espacial para o qual DBCC CHECKDBrelata corrupções:

DBCC CHECKDB(MyDB) 
WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS

O índice espacial, índice XML ou exibição indexada 'sys.extended_index_xxx_384000' (objeto ID xxx) não contém todas as linhas que a definição de exibição produz. Isso não representa necessariamente um problema de integridade com os dados desse banco de dados.

O índice espacial, índice XML ou exibição indexada 'sys.extended_index_xxx_384000' (objeto ID xxx) contém linhas que não foram produzidas pela definição de exibição. Isso não representa necessariamente um problema de integridade com os dados desse banco de dados.

CHECKDB encontrou 0 erros de alocação e 2 erros de consistência na tabela 'sys.extended_index_xxx_384000' (objeto ID xxx).

O nível de reparo é repair_rebuild.

Eliminar e recriar o índice não remove esses relatórios de corrupção. Sem EXTENDED_LOGICAL_CHECKS, mas com DATA_PURITYo erro não é relatado.

Além disso, CHECKTABLEleva 45 minutos para esta tabela, embora seu CI tenha 30 MB de tamanho e haja cerca de 30 mil linhas. Todos os dados nessa tabela são geographydados pontuais.

Esse comportamento é esperado em alguma circunstância? Ele diz "Isso não representa necessariamente um problema de integridade". O que eu deveria fazer? CHECKDBestá falhando, o que é um problema.

Este script reproduz o problema:

CREATE TABLE dbo.Cities(
    ID int  NOT NULL,
    Position geography NULL,
 CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    ID ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

GO
INSERT dbo.Cities (ID, Position) VALUES (20171, 0xE6100000010C4E2B85402E424A40A07312A518C72A40)
GO
CREATE SPATIAL INDEX IX_Cities_Position ON dbo.Cities
(
    Position
)USING  GEOGRAPHY_AUTO_GRID 
WITH (
CELLS_PER_OBJECT = 16, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

Esta é a versão 12.0.4427.24 (SQL Server 2014 SP1 CU3).

Eu criei o script da tabela com esquema e dados, banco de dados fresco, execute. Mesmo erro. CHECKDB também tem esse tempo de execução incrível de 45min. Eu capturei o plano de consulta CHECKDB usando o SQL Profiler. Ele tem uma junção de loop equivocada, aparentemente causando tempo de execução excessivo. O plano tem tempo de execução quadrático no número de linhas da tabela! Junções de loop de varredura duplamente aninhadas.

Limpar todos os índices não espaciais não altera nada.

Uma CHECKDBexecução relata corrupção em arquivos sys.extended_index_1066482673_384000. Que tipo de índice é representado pelo padrão de nome sys.extended_index_...? A mensagem é:

O índice espacial, índice XML ou exibição indexada 'sys.extended_index_1066482673_384000' (ID do objeto...) não contém todas as linhas produzidas pela definição da exibição. Isso não representa necessariamente um problema de integridade com os dados desse banco de dados. Para obter mais informações sobre como solucionar erros de DBCC em índices espaciais, índices XML e exibições indexadas, consulte os Manuais Online do SQL Server.

Os arquivos de instantâneo do banco de dados são arquivos esparsos. Somente quando uma página é modificada, o arquivo esparso está sendo gravado. As leituras do instantâneo devem ser capazes de saber se o arquivo esparso contém uma página copiada ou não. Como o SQL Server sabe de onde ler? Onde essas informações são armazenadas?

Na minha dev box, tenho meu SQL Server configurado com uma quantidade máxima de memória alta (8 GB de 16 GB). Isso é necessário para muitas tarefas de desenvolvimento.

Às vezes eu quero minha memória de volta, no entanto. Não quero deixar 8 GB consumidos permanentemente.

Qual é uma boa maneira de fazer com que o SQL Server libere repentinamente toda a memória para o sistema operacional?

DBCC DROPCLEANBUFFERSnão faz isso . Ele apenas marca buffers limpos como disponíveis.

Reiniciar o SQL Server é um problema porque isso faz com que uma recuperação de banco de dados de 1 minuto seja executada devido a este bug/recurso: Parar o serviço SQL Server faz com que os bancos de dados não sejam desligados corretamente (por favor, vote nesse item de conexão; parece um bug grave) .