Matthew McGiffen's questions

No SQL Server podemos ter muitos threads de trabalho por núcleo de CPU. Alguém sabe se o mesmo é verdade no PostgreSQL e pode me indicar uma referência? (assuma a versão 11).

O pano de fundo é que temos algumas cargas de trabalho OLTP atualmente no SQL Server que estão sendo migradas para o PostgreSQL. Gostaria de saber se existe o risco de ficar sem threads se o paralelismo estiver habilitado e as conexões serem recusadas (o que pode acontecer no SQL Server quando ficarmos sem threads) e se devo recomendar que o paralelismo seja desabilitado por padrão.

Alguém tem algum conhecimento (interno?) de como a compactação de backup funciona com TDE no SQL Server (versão 2016+).

Em geral, eu esperaria que a compactação de dados criptografados tivesse um benefício mínimo, no entanto, notamos que com o TDE, quando fazemos um backup completo com compactação, ainda vemos uma redução significativa no tamanho do arquivo de backup. Isso nos fez pensar se o processo de backup descriptografa os dados, os compacta, criptografa esse resultado e depois faz o backup em disco. Obviamente, isso aumentará o consumo de CPU para o processo de backup devido à necessidade de descriptografar e recriptografar os dados.

Detalhes

select @@version

Microsoft SQL Server 2017 (RTM) - 14.0.1000.169 (X64) 22 de agosto de 2017 17:04:49 Copyright (C) 2017 Microsoft Corporation Developer Edition (64 bits) no Windows 10 Enterprise 10.0 (Build 17763: ) (Hypervisor)'

Código TSQL

BACKUP DATABASE TestTDE TO DISK = 'c:\Test\TestTDE_Compressed.bak' WITH COMPRESSION, MAXTRANSFERSIZE = 65537

Ou a economia de espaço é alcançada de uma maneira diferente?

Andei investigando limites de amostragem com atualizações de estatísticas no SQL Server (2012) e notei um comportamento curioso. Basicamente, o número de linhas amostradas parece variar em algumas circunstâncias - mesmo com o mesmo conjunto de dados.

Eu executo esta consulta:

--Drop table if exists
IF (OBJECT_ID('dbo.Test')) IS NOT NULL DROP TABLE dbo.Test;

--Create Table for Testing
CREATE TABLE dbo.Test(Id INT IDENTITY(1,1) CONSTRAINT PK_Test PRIMARY KEY CLUSTERED, TextValue VARCHAR(20) NULL);

--Insert enough data so we have more than 8Mb (the threshold at which sampling kicks in)
INSERT INTO dbo.Test(TextValue) 
SELECT TOP 1000000 'blahblahblah'
FROM sys.objects a, sys.objects b, sys.objects c, sys.objects d;  

--Create Index on TextValue
CREATE INDEX IX_Test_TextValue ON dbo.Test(TextValue);

--Update Statistics without specifying how many rows to sample
UPDATE STATISTICS dbo.Test IX_Test_TextValue;

--View the Statistics
DBCC SHOW_STATISTICS('dbo.Test', IX_Test_TextValue) WITH STAT_HEADER;

Quando olho para a saída do SHOW_STATISTICS, estou descobrindo que o "Rows Sampled" varia com cada execução completa (ou seja, a tabela é descartada, recriada e repovoada).

Por exemplo:

Linhas amostradas

• 318618
• 319240
• 324198
• 314154

Minha expectativa era que esse valor fosse o mesmo toda vez que a tabela fosse idêntica. A propósito, não recebo esse comportamento se apenas excluir os dados e reinserir.

Não é uma pergunta crítica, mas eu estaria interessado em entender o que está acontecendo.