Yano_of_Queenscastle's questions

Mudei alguns arquivos de backup para um novo destino. No entanto, o SQL Server parece pensar que ainda está no lugar antigo. (Ou seja, quando eu uso o assistente de restauração de banco de dados do SSMS, ele ainda apresenta um plano de restauração usando o local antigo.)

Existe uma maneira de mover os arquivos para que o SQL Server seja notificado sobre isso?

Atualmente estou dando uma olhada no Pro SQL Server 2019 Administration: A Guide for the Modern DBA e descobri uma coisa que me confunde um pouco.

No Capítulo 5: CONFIGURANDO A INSTÂNCIA , a seção Memória mínima e máxima do servidor (páginas 139-140) diz:

Em muitos ambientes, é provável que você deseje fornecer o mesmo valor para memória mínima e máxima do servidor. Isso evitará a sobrecarga do SQL Server gerenciando dinamicamente a quantidade de memória reservada.

No entanto, se você tiver várias instâncias, o gerenciamento dinâmico de memória poderá ser benéfico para que a instância com a carga de trabalho mais pesada em um determinado momento possa consumir mais recursos.

... Supondo que você tenha uma instância e nenhum outro aplicativo, como pacotes SSIS, em execução no servidor, normalmente você definiria as configurações de memória mínima e máxima como o valor mais baixo do

• RAM - 2 GB
• (RAM / 8) * 7

No entanto, o conselho para " fornecer o mesmo valor para memória mínima e máxima do servidor " está em contradição com a documentação , que diz:

Não é recomendado definir a memória máxima do servidor (MB) e a memória mínima do servidor (MB) como o mesmo valor ou próximo dos mesmos valores.

Em que situações seria uma boa ideia definir a memória máxima do servidor e a memória mínima do servidor com o mesmo valor (ish)?

Ou estou entendendo mal alguma coisa sobre o conselho?

A visualização do sistema sys.dm_db_index_usage_statspossui diversas colunas que refletem o uso do índice pelas consultas do sistema. Mas o que isso significa? Por que o sistema consulta minha tabela?

A documentação não é particularmente útil:

Tenho uma tabela com estrutura em árvore (definida por hierarchyidcoluna) e quero selecionar todos os descendentes de um determinado registro. Para isso, estou usando hiearchyid.IsDescendantOf()o método.

Eu esperava que, como não estou fazendo comparações simples, mas estou executando operações (neste caso, estou chamando o IsDescendantOf()método), obterei um plano de execução terrível com varreduras de índice e outros enfeites.

Mesmo assim, o SQL Server o otimizou para uma pequena busca de índice.

Estou intrigado por que e como.

A chamada de métodos em tipos CLR geralmente é otimizada? Presumi que o SQL Server vê os tipos CLR como uma caixa preta opaca e, portanto, não pode fazer sua mágica funcionar nele. (Uma vez que também não é possível fazer isso em funções SQL nativas.)

Ou isso é apenas para este método específico? (Como os hieararchyidvalores são ordenados em profundidade, eu poderia obter resultados semelhantes apenas fazendo comparações.)

Demonstração:

CREATE TABLE dbo.HierarchyExample (
    Id INT PRIMARY KEY,
    Hieararchy HIERARCHYID NOT NULL
);

INSERT INTO dbo.HierarchyExample(Id, Hieararchy)
VALUES
(1,  hierarchyid::Parse('/1/')),
(2,  hierarchyid::Parse('/1/1/')),
(3,  hierarchyid::Parse('/1/2/')),
(4,  hierarchyid::Parse('/1/3/')),
(5,  hierarchyid::Parse('/1/3/1/')),
(6,  hierarchyid::Parse('/1/3/2/')),
(7,  hierarchyid::Parse('/1/3/3/')),
(8,  hierarchyid::Parse('/1/4/')),
(9,  hierarchyid::Parse('/1/4/1/')),
(10, hierarchyid::Parse('/1/4/2/'));

CREATE INDEX IX_HierarchyExample_Hierarchy 
ON dbo.HierarchyExample (Hieararchy);

SELECT descendant.*
FROM HierarchyExample ancestor
    INNER JOIN HierarchyExample descendant
        ON descendant.Hieararchy.IsDescendantOf(ancestor.Hieararchy) = 1
WHERE ancestor.Id = 1

DROP TABLE IF EXISTS dbo.HierarchyExample;

O plano de execução

O violino

Estou tentando entender esse comportamento estranho.

1. Este lote seleciona 1 e, em seguida, falha porque a tabela não existe. Isso faz sentido.

SELECT 1;

SELECT  1
FROM NonexistentTable;

2. Se eu estivesse tentando escrever um script infalível, talvez pudesse verificar a existência da tabela primeiro. Isso seleciona 1 e termina sem gerar nenhum erro. Até agora tudo bem.

SELECT 1;

IF EXISTS (
    SELECT 1
    FROM INFORMATION_SCHEMA.TABLES
    WHERE TABLE_NAME = 'NonExistentTable'
)
BEGIN
    SELECT 1
    FROM NonExistentTable;
END

3. Este lote seleciona 1 e, em seguida, falha, porque o procedimento não existe. Que é razoável.

SELECT 1;

EXECUTE sp_nonexisting_procedure;

4. Este lote se recusa a executar imediatamente, o que é inconsistente com o cenário observado anteriormente. Por que?

SELECT 1;

SELECT NonexistentColumn
FROM sys.databases;

5. É ainda mais preocupante em scripts, onde tento verificar explicitamente a existência da coluna. Vamos criar a tabela para o experimento:

CREATE TABLE ExistingTable(Id INT, [Name] NVARCHAR(255));
GO

E então execute este ↓↓↓↓. Isso falha completamente, mesmo sem selecionar 1 também.

SELECT 1;

IF EXISTS (
    SELECT 1
    FROM INFORMATION_SCHEMA.COLUMNS
    WHERE TABLE_NAME = 'ExistingTable'
        AND COLUMN_NAME = 'NonexistingColumn'
)
BEGIN
    
    SELECT NonexistingColumn
    FROM ExistingTable;

END
GO

Por que a existência de colunas é verificada logo após o envio da consulta, sem nem mesmo tentar executar partes válidas da consulta primeiro?

O que torna ainda mais intrigante para mim é que as tabelas são verificadas apenas quando a execução as atinge. (E ingenuamente, eu esperaria que as tabelas fossem mais importantes, portanto, obtendo verificações mais rigorosas/anteriores.)