Yano_of_Queenscastle's questions

Quando escrevi alguns comentários antes do CREATE PROCEDUREcomando, esses comentários parecem ser preservados como parte da definição do procedimento.

Por exemplo, quando eu crio um procedimento como este

/*Comment header*/
CREATE OR ALTER PROCEDURE example_procedure
AS 
SELECT 1 AS Id

O /*Comment header*/é armazenado como parte da definição.

Violino

Esse é um comportamento documentado, posso sempre contar com isso? Ou é apenas uma peculiaridade não confiável do SQL Server?

Meu entendimento ingênuo é que a definição do procedimento começa com CREATEpalavra-chave, então hesito em confiar em comportamento que vai contra minha intuição.

Existe algum significado para o SQL Server ter BITdatatype em vez de BOOLEAN? É apenas uma maneira estranha de chamar a mesma coisa, ou existe alguma diferença conceitual sutil?

A documentação sobre BITo tipo de dados menciona:

O tipo de dados bit pode ser usado para armazenar valores booleanos.

Isso parece sugerir que, na verdade, elas não são a mesma coisa.

Estou ciente de que [a coisa que a MS chama de boolean] e [a coisa que a MS chama de bit] são diferentes, MAS do ponto de vista do programador, bité a melhor aproximação do booleanconceito platônico que a linguagem T-SQL oferece. E eu luto para acreditar que seja apenas uma casualidade e não uma intenção. O tipo de dado numérico que aceita apenas 0 e 1 parece pouco prático para outros usos.

Está documentado que a atribuição recursiva de variáveis ​​(como esta ↓↓↓↓) pode às vezes retornar resultados incorretos:

SELECT @var = @var + [Name]
FROM dbo.People
...

Mas isso se aplica mesmo no caso em que tenho certeza de que apenas uma linha será retornada?

Exemplo ( Fiddle ):

CREATE TABLE dbo.People
(
  Id INT IDENTITY PRIMARY KEY,
  [Name] varchar(50) NOT NULL
);

INSERT INTO dbo.People([Name]) VALUES ('Bob');

DECLARE @var varchar(50) = '';


/*Is this bad even if the query always returns only one row?*/
SELECT @var = @var + [Name]
FROM dbo.People
WHERE Id = 1;

SELECT [@var] = @var;

A documentação diz que " Nesse caso, não há garantia de que @Var seria atualizado linha por linha. " o que (para mim) sugere que a seleção de uma única linha deve ser suficiente, certo?

Outro exemplo em que se pode querer usar isso é ao calcular alguns valores agregados e adicioná-los a algum lugar:

SELECT @Total = @Total + SUM(InvoiceTotal) /*single row, aggregate of several values*/
FROM dbo.Invoice
WHERE ...;
/*Notice no GROUP BY*/

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.)