Brent Ozar's questions

Tenho uma cópia pública do banco de dados Stack Overflow aqui no AWS Aurora Postgres 15.5:

• Servidor: query.smartpostgres.com
• Nome de usuário: somente leitura
• Senha: 511e0479-4d35-49ab-98b1-c3a9d69796f4

A tabela de usuários possui este índice:

create index users_length_displayname on users(length(displayname));

Mas quando executo uma destas consultas:

select * from users where length(displayname) > 35;
select length(displayname) from users where length(displayname) > 35;

Eles não usam o índice funcional, como evidenciado pelos seus planos de consulta :

Então, por quê?

Quando executo esta consulta em um servidor SQL Server 2022 com uma conexão de servidor vinculada ao PostgreSQL:

SELECT TOP 1 * 
FROM PGSTACK.stackoverflow.[public].users 
WHERE Id = 1;

O SQL Server busca todo o conteúdo da tabela de usuários remotos – todas as linhas – pela rede e filtra tudo localmente. A consulta leva >3 minutos para ser executada.

O plano de consulta real não mostra um filtro local – isso implica que o SQL Server está obtendo apenas 1 linha do servidor remoto:

• Pergunta 1: Isso (obter todo o conteúdo da tabela remota) pode ser evitado sem reescrever a consulta para usar OPENQUERY?
• Pergunta 2: Mesmo apenas tentar obter o plano de execução estimado, na verdade, busca todas as linhas da tabela remota e leva> 3 minutos apenas para obter o plano estimado. Isso pode ser evitado?

Detalhes técnicos adicionais:

• O servidor remoto possui uma chave primária no id e a consulta é executada em milissegundos no Postgres
• O pg_stat_activity do servidor Postgres remoto mostra que o SQL Server está executando esta consulta: select * from "stackoverflow"."public"."users"- observe a falta de qualquer filtro na tabela
• Driver Postgres ODBC 16.00 2023/09/16, versão mais recente aqui
• SQL Server 2022 compilação 16.0.4095.4
• O painel de controle da rede mostra até mesmo a taxa de transferência disparando assim que a consulta é iniciada - e, novamente, estou puxando apenas uma linha aqui:

O SQL Server 2022 introduziu a inicialização instantânea de arquivo para eventos de crescimento de arquivo de log de transações. Na página O que há de novo em 2022 , a Microsoft observa:

Em geral, os arquivos de log de transação não podem se beneficiar da inicialização instantânea de arquivo (IFI). A partir do SQL Server 2022 (16.x) (todas as edições) e no Banco de Dados SQL do Azure, a inicialização instantânea de arquivo pode beneficiar eventos de crescimento de log de transação de até 64 MB. O incremento de tamanho de crescimento automático padrão para novos bancos de dados é de 64 MB. Os eventos de crescimento automático do arquivo de log de transações maiores que 64 MB não podem se beneficiar da inicialização instantânea do arquivo.

Para testar isso, tentei aumentar repetidamente o arquivo de log em tamanhos diferentes (digamos, 50 e 70 MB), mas ... nenhum deles foi instantâneo.

DROP DATABASE LogGrowthTest;
GO
CREATE DATABASE [LogGrowthTest]
 CONTAINMENT = NONE
 ON  PRIMARY 
( NAME = N'LogGrowthTest', FILENAME = N'Z:\MSSQL\Data\LogGrowthTest.mdf', 
    SIZE = 8192KB , FILEGROWTH = 60000KB )
 LOG ON 
( NAME = N'LogGrowthTest_log', FILENAME = N'Z:\MSSQL\Data\LogGrowthTest_log.ldf' , 
    SIZE = 8192KB , FILEGROWTH = 60000KB )
GO
DECLARE @TestStartTime DATETIME2 = GETDATE(), @i INT = 1,
    @StringStarter NVARCHAR(4000) = N'ALTER DATABASE [LogGrowthTest] MODIFY FILE ( NAME = N''LogGrowthTest_log'', SIZE = ',
    @StringToExec NVARCHAR(4000);   
WHILE @i < 101
    BEGIN
    /* CHANGE THE 63 IN THE BELOW LINE TO CHANGE FILE GROWTH SIZE: */
    SET @StringToExec = @StringStarter + CAST((@i * 63) AS NVARCHAR(10)) + N'MB );';
    PRINT(@StringToExec)
    EXEC(@StringToExec);
    SET @i = @i + 1;
    END
SELECT DATEDIFF(millisecond,@TestStartTime, GETDATE()) AS TestDurationSeconds
GO

Tentei 63 MB, 65 MB e não pareceu fazer muita diferença - os testes levaram cerca de 15 a 16 segundos para 100 eventos de crescimento.

Portanto, a questão é: a inicialização instantânea de arquivo simplesmente não funciona para crescimentos manuais de arquivos de log, mesmo em tamanhos pequenos? Apenas eventos de autocrescimento? (Ainda não consegui provar que funciona para eventos de autocrescimento.)

Estou executando a configuração do SQL Server 2022 RC1 em um AWS i3.16xlarge com 2 soquetes, 2 nós NUMA, 32 processadores lógicos por nó, 64 processadores lógicos no total.

A configuração está recomendando MAXDOP 8:

Mas se você clicar nesse link para configurar o MAXDOP , as recomendações dizem:

Com base nesse artigo da KB, MAXDOP deve ser 16, não 8. Claro, tecnicamente 8 é menor que 16 - mas também é 2, ou 4, ou 15. De onde vem o 8?

Após a conclusão da instalação do SQL Server e a inicialização do serviço, o log mostra que o SQL Server está implementando automaticamente o Soft-NUMA com 4 nós, cada um com 16 processadores lógicos:

Então, novamente, isso indica que MAXDOP deve ser 16.

Isso é um bug, ou eu perdi algo óbvio? Existe outra regra não escrita em algum lugar que a configuração irá parar no MAXDOP 8?

Eu preciso aplicar uma dica de consulta (como NOWAITou NOLOCK) CROSS APPLYnesta consulta. Como eu faço isso:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

SELECT *
FROM sys.objects obj WITH (NOLOCK) 
INNER JOIN sys.stats stat WITH (NOLOCK) ON stat.object_id = obj.object_id  
CROSS APPLY sys.dm_db_stats_properties(stat.object_id, stat.stats_id) sp

Não tenho acesso ao conteúdo da função (por motivos óbvios).

Eu fui em frente e removi a reprodução da pergunta para torná-la mais clara. Estou menos preocupado com a capacidade de reproduzir o bloqueio. (Também está acontecendo em ambientes de clientes e no First Responder Kit na edição nº 2548.)

Eu quero criar um logon que não tenha a capacidade de gravar em qualquer banco de dados - não apenas bancos de dados que existem hoje, mas qualquer banco de dados recém-criado ou banco de dados restaurado de outros servidores.

Não posso usar funções somente de banco de dados (nem mesmo no modelo), porque elas não terão efeito em bancos de dados recém-restaurados.

(Propósito comercial: estou escrevendo uma postagem no blog sobre como as pessoas podem configurar um novo login para si mesmas com baixo privilégio e podem garantir que não tenham acidentalmente um momento "oops" ao copiar/colar código ou execute-o sem uma cláusula where.)

O SQL Server 2019 CTP 2.3 adicionou algumas novas colunas a sys.databases, incluindo is_result_set_caching_on:

Ainda não está documentado nas Novidades do SQL Server 2019 , nem na página ALTER DATABASE .

Eu tentei usar a mesma sintaxe do Accelerated Database Recovery apenas para rir:

ALTER DATABASE StackOverflow2013 SET RESULT_SET_CACHING ON;

Mas sem sorte:

Msg 5058, Level 16, State 12, Line 8
Option 'RESULT_SET_CACHING' cannot be set in database 'StackOverflow2013'.

Tudo isso funciona:

CREATE DATABASE [¯\_(ツ)_/¯];
GO
USE [¯\_(ツ)_/¯];
GO
CREATE SCHEMA [¯\_(ツ)_/¯];
GO
CREATE TABLE [¯\_(ツ)_/¯].[¯\_(ツ)_/¯]([¯\_(ツ)_/¯] NVARCHAR(20));
GO
CREATE UNIQUE CLUSTERED INDEX [¯\_(ツ)_/¯] ON [¯\_(ツ)_/¯].[¯\_(ツ)_/¯]([¯\_(ツ)_/¯]);
GO
INSERT INTO [¯\_(ツ)_/¯].[¯\_(ツ)_/¯]([¯\_(ツ)_/¯]) VALUES (N'[¯\_(ツ)_/¯]');
GO
CREATE VIEW [¯\_(ツ)_/¯].[vw_¯\_(ツ)_/¯] AS SELECT [¯\_(ツ)_/¯] FROM [¯\_(ツ)_/¯].[¯\_(ツ)_/¯];
GO
CREATE PROC [¯\_(ツ)_/¯].[sp_¯\_(ツ)_/¯] @Shrug NVARCHAR(20) AS SELECT [¯\_(ツ)_/¯] FROM [¯\_(ツ)_/¯].[vw_¯\_(ツ)_/¯] WHERE [¯\_(ツ)_/¯] = @Shrug;
GO
EXEC [¯\_(ツ)_/¯].[¯\_(ツ)_/¯].[sp_¯\_(ツ)_/¯] @Shrug = N'[¯\_(ツ)_/¯]';
GO

Mas você provavelmente pode ver onde estou indo com isso: eu não quero @Shrug, eu quero @¯\_(ツ)_/¯.

Nenhum deles funciona em qualquer versão de 2008-2017:

CREATE PROC [¯\_(ツ)_/¯].[sp_¯\_(ツ)_/¯] @[¯\_(ツ)_/¯] NVARCHAR(20) AS SELECT [¯\_(ツ)_/¯] FROM [¯\_(ツ)_/¯].[vw_¯\_(ツ)_/¯] WHERE [¯\_(ツ)_/¯] = @[¯\_(ツ)_/¯];
GO
CREATE PROC [¯\_(ツ)_/¯].[sp_¯\_(ツ)_/¯] [@¯\_(ツ)_/¯] NVARCHAR(20) AS SELECT [¯\_(ツ)_/¯] FROM [¯\_(ツ)_/¯].[vw_¯\_(ツ)_/¯] WHERE [¯\_(ツ)_/¯] = [@¯\_(ツ)_/¯];
GO

Então, existe uma maneira de usar nomes de parâmetros de procedimento armazenado unicode?

O SQL Server 2017 tem alguns novos procedimentos armazenados:

• sp_refresh_single_snapshot_view – parâmetro de entrada para @view_name nvarchar(261), @rgCode int
• sp_refresh_snapshot_views – parâmetro de entrada para @rgCode int

E novas entradas em sys.messages:

• 10149 – O índice que tem SNAPSHOT_MATERIALIZATION não pode ser criado na exibição '%.*ls' porque a definição da exibição contém tabelas com otimização de memória.
• 10642 – SNAPSHOT_MATERIALIZATION não pode ser definido para o índice '%.*ls' em '%.*ls' porque só é aplicável a índices em exibições.
• 10643 – SNAPSHOT_MATERIALIZATION não pode ser definido para '%.*ls' em '%.*ls' porque é aplicável apenas a índices clusterizados em exibições.
• 10648 – SNAPSHOT_MATERIALIZATION não pode ser definido para o índice particionado '%.*ls' em '%.*ls'.
• 10649 – O índice não clusterizado '%.*ls' não pode ser criado em '%.*ls' que tenha o índice clusterizado '%.*ls' com SNAPSHOT_MATERIALIZATION.
• 10650 – A atualização de visualizações de instantâneos requer que o isolamento de instantâneos seja habilitado no banco de dados.
• 3760 – Não é possível descartar o índice '%.*ls' na exibição '%.*ls' que possui SNAPSHOT_MATERIALIZATION.
• 4524 – Não é possível alterar a visualização '%.*ls' porque possui materialização de instantâneo.
• 4525 – Não é possível usar a dica '%ls' na exibição '%.*ls' que tem materialização de instantâneo antes que a exibição seja atualizada.

E novos Eventos Estendidos:

Então, como podemos criar uma visão materializada por instantâneo? (A Microsoft ainda não documentou isso, obviamente.) Aqui está um resumo das coisas que tentei até agora que não funcionaram.