SQL Server 2019 IQP – Parte 1 – Table Variable Deferred Compilation

Olá pessoal, vem aí uma série de posts sobre o IQP, recém lançado com o SQL Server 2019.

O IQP ( Intelligent Query Processing) é uma família de features lançadas no SQL Server 2019 para endereçar uma série de problemas conhecidos de performance. Com um comportamento By Default da Engine, há um esforço mínimo (migrar para o SQL 2019) ou inexistente para começar a utilizá-lo.

Iniciando hoje no primeiro Post sobre IQP, a feature Table Variable Deferred Compilation.

Só lembrando que no SQL Server 2017 foi lançado o AQP (Adaptative Query Processing), que hoje faz parte do IQP, mas tudo que for discutido é relativo ao SQL Server 2019.

Table Variable Deferred Compilation

Essa feature do IQP permite a geração de melhores planos de execução em consultas que usam Table Variable. Durante a compilação e otimização do plano de execução será feito um Count Rows da Table Variable, que será utilizado para escolher os melhores operadores ao gerar o plano de execução.

O famoso problema do Estimated = 1

Mas qual é o risco ao utilizar Table Variables? Em versões anteriores ao SQL Server 2019 estima-se apenas 1 linha para a Table Variable ao gerar o plano de execução, que pode causar alguns problemas, principalmente quando se insere milhares de linhas na Table Variable e faz-se joins com outras tabelas. Vamos demonstrar no exemplo abaixo.

Obs: Para o nosso lab utilizamos a base do AdventureWorks.

Vamos criar também um índice para auxiliar o nosso lab, alterar o nível de compatibilidade para o SQL Server 2017 e simular a chamada de uma procedure que utiliza Table Variable.

/* CONSIDERANDO O COMPATIBILITY DO SQL SERVER 2017 */
ALTER DATABASE [AdventureWorks] SET COMPATIBILITY_LEVEL = 140
GO

/* INDICE AUXILIAR */
USE [AdventureWorks]
GO
CREATE NONCLUSTERED INDEX [IX_SalesOrderDetail_OrderQty]
ON [Sales].[SalesOrderDetail] ([OrderQty])
GO

/* PROCEDURE PARA RETORNAR VENDAS */
create procedure RetornaVendasQtde (
	@OrderQty int
) as
begin

	declare @TempIDs as table (SalesOrderId int)

	insert into @TempIDs
	select SalesOrderID
	from Sales.SalesOrderDetail
	where OrderQty > @OrderQty

	select oh.SalesOrderID, OrderDate, PurchaseOrderNumber, AccountNumber, SubTotal
	from Sales.SalesOrderHeader oh
	inner join @TempIDs t on oh.SalesOrderID = t.SalesOrderId

end
go

A procedure utilizada como exemplo recebe o parâmetro OrderQty, que representa a quantidade de itens na venda. Para simular o problema será feito duas chamadas, uma com um parâmetro mais restritivo (40) e outra com um parâmetro menos restritivo (1). O SELECT abaixo representa a parte do código onde inserimos os registros na table variable. Observe que passando o parâmetro 40 serão inseridos 2 registros na Table Variable, enquanto com o valor 1, serão 46363 registros.

select  (  select COUNT(SalesOrderID)
           from Sales.SalesOrderDetail
           where OrderQty > 40 ) as PrimeiraChamada
,       (  select COUNT(SalesOrderID)
           from Sales.SalesOrderDetail
           where OrderQty > 1 ) as SegundaChamada

Agora executando a procedure com o parâmetro @OrderQty = 40 e analisando o seu plano de execução.

Obs: Estamos usando a opção Include Actual Execution Plan para coletar o plano de execução estimado e atual; e também o SET STATISTICS IO, TIME ON para coletar as estatísticas de execução de logical reads e cpu time.

set statistics io, time on
exec dbo.RetornaVendasQtde @OrderQty = 40
Procedure retornou 2 registros com o parâmetro @OrderQty = 40

Pelo tempo de resposta, muito bom! 0 ms o tempo de resposta fazendo ao todo apenas 7 logical reads. O único porém aqui é o Estimated Number of Rows = 1. É o comportamento antigo discutido acima. Para toda Table Variable estima-se 1 linha até o SQL Server 2017.

Vamos fazer outro teste então, com outro parâmetro menos restritivo, @OrderQty = 1.

Procedure retornou 46363 registros com o parâmetro @OrderQty = 1

Apesar do retorno da procedure ser em 0.5 segundos, há um problema grave. Foi estimado de 1 linha onde foram retornadas 46363, o que fez o otimizador optar pelo Nested Loops e provocou um alto número de Logical Reads na tabela SalesOrderHeader, maior até mesmo que o número de páginas da própria tabela.

Obs: pra quem não lembra como funciona os algoritmos de joins, acessar esse link.

Como funciona no SQL Server 2019

Agora, executando novamente o último exemplo no SQL Server 2019, com o compatibility level = 150.

/* CONSIDERANDO O COMPATIBILITY DO SQL SERVER 2019 */
ALTER DATABASE [AdventureWorks] SET COMPATIBILITY_LEVEL = 150
GO

set statistics io, time on
exec dbo.RetornaVendasQtde @OrderQty = 1
Retornou os mesmos 46363. Nenhuma alteração de código foi realizada.

Com a nova feature Table Variable Deferred Compilation, o comportamento é outro. Agora é feito a estimativa correta do número de linhas na Table Variable e permite usar um algoritmo mais adequado para a situação. No novo plano de execução, é utilizado o Hash Match ao invés do Nested Loops, o que gerou um ganho expressivo na quantidade de Logical Reads e custo de CPU.

Abaixo tabela comparativa com os custos das execuções da procedure.

Compatibility LevelCPU Time MsElapsed Time MsLogical Reads
140 (SQL 2017)203454139164
150 (SQL 2019)313441454

Os resultados acima consideram apenas uma chamada única. O próximo passo é simular um cenário de várias chamadas simultâneas com o SQLQueryStress. Serão feitas 1000 chamadas através de 50 iterações com 20 threads em paralelo.

Abaixo os resultados com execuções no COPATIBILITY_LEVEL 140 e 150.

32 segundos pra executar 1000 chamadas. Tempo médio de 1.15 segundos por chamada.
20 segundos pra executar 1000 chamadas. Tempo médio de 0.71 segundos por chamada.

Abaixo o gráfico do Perfmon considerando CPU Time e Batch Requests/sec. Destaque para a média de Batch Requests/sec que chegou a 760 no COMPATIBILITY_LEVEL 140 e a 1000 no COMPATIBILITY_LEVEL 150. Levando esses números para um cenário pesado, significa dizer maior poder de processamento e ganho de performance com a nova feature habilitada.

Como habilitar \ desabilitar?

Por DEFAULT essa feature vem habilitada no SQL Server 2019, porém é possível desabilitar a nível de database ou a nível de query.

-- Database Scope
ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;
ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON; 

-- Query Scope -> OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));
use [AdventureWorks]
go

declare @TempIDs as table (SalesOrderId int)

insert into @TempIDs
select SalesOrderID
from Sales.SalesOrderDetail
where OrderQty > 1

select oh.SalesOrderID, OrderDate, PurchaseOrderNumber, AccountNumber, SubTotal
from Sales.SalesOrderHeader oh
inner join @TempIDs t on oh.SalesOrderID = t.SalesOrderId
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'))

Referência

Documentação Microsoft

Webinar IQP with Joe Sack

IQP Custumer Questions and Answers

Ignite Tour SP – PPT Fabiano Amorim

Performance com LOBs no SQL Server

É bastante comum nos deparamos com databases que utilizam Large Objects. XML, armazenamento de arquivos (planilhas, imagens, documentos, etc) e logs gigantescos de aplicação são exemplos de utilização de LOBs.

Em termos práticos no SQL Server, podemos utilizar os seguintes tipos de dados para trabalhar com LOBs.

  • varchar(max)
  • nvarchar(max)
  • varbinary(max)
  • xml
  • text
  • ntext
  • image

Ok, mas quais os cuidados eu devo ter ao estar utilizando campos LOB? Vamos rodar uma pequena demonstração para tocar alguns pontos importantes sobre performance com LOBs no SQL Server.

Para o nosso exemplo, vamos criar um database e uma tabela utilizando campo VARCHAR(max). Após isso, vamos fazer uma carga de 1 milhão de linhas com dados aleatórios para começar os testes de performance.

-- Create database
create database LobData

-- Cria tabela com campo varchar(max)
drop table if exists dbo.InventarioDB_Varchar
go
create table dbo.InventarioDB_Varchar (
	Id			int identity(1,1) not null primary key
,	DtCriacao	date not null
,	TipoObjeto	varchar(32)
,	Texto		varchar(max)
)
go

-- Realiza carga na tabela InventarioDB_Varchar (~23 segundos)
insert into 
			dbo.InventarioDB_Varchar (DtCriacao, TipoObjeto, Texto)
select top 1000000
			convert(date, c.create_date), c.type_desc, a.definition
from 
			sys.all_sql_modules a
cross join	sys.all_objects c

Ótimo, inserimos os registros na tabela. Vamos agora fazer uma consulta?

set statistics io, time on

-- Vamos fazer uma consulta para retornar quantidade de objetos por tipo.
select
	TipoObjeto
,	count(TipoObjeto) as [Count]
from
	dbo.InventarioDB_Varchar
group by
	TipoObjeto
order by 
	count(TipoObjeto) desc

A consulta rodou em menos de 1 segundo, mas vamos analisar o número de logical reads e o tempo de CPU gasto.

A consulta rodou bem rápido (143 ms), mas algo está estranho. Foi necessário ler 267 mil páginas de dados pra retornar a consulta. É um número bastante alto para uma tabela de 1 milhão de linhas, não? Vamos entender como funciona o armazenamento dos dados pra tentar melhorar isso.

Para começar, vamos conferir como ficou a distribuição dos dados dentro da tabela? Pra isso, estou criando uma procedure que realiza a consulta em DMVs com informações das estruturas internas dos dados nas tabelas (links da documentação das DMVs no final do post).

-- Cria procedure para retornar distribuição das páginas na tabela
create or alter procedure dbo.GetPagesAllocation (@object sysname)
as
begin

	SELECT
		OBJECT_NAME ([sp].[object_id])	AS [Object Name]
	,	[au].[type_desc]				AS [Alloc Unit Type]
	,	[fg].name						as [FileGroup]
	,	[au].total_pages				AS TotalPages
	,	[au].data_pages					AS DataPages
	,	[au].used_pages					as UsedPages
	,	sp.[rows]						AS [Rows]
	FROM
				sys.partitions AS [sp]
	inner join	sys.system_internals_allocation_units [au]
				on  [au].container_id = sp.[partition_id]
	inner join	sys.filegroups [fg]
				on [fg].data_space_id = [au].filegroup_id
	WHERE
		[sp].[object_id] =	(	CASE WHEN (@object IS NULL)
									THEN [sp].[object_id]
									ELSE OBJECT_ID (@object)
								END )

end		
go

-- Verifica alocação dos dados nas tabelas
exec dbo.GetPagesAllocation @object = 'InventarioDB_Varchar'

Ao executar a procedure, obtivemos o resultado abaixo. Perceba que a distribuição das páginas no nosso exemplo é feita entre IN_ROW_DATA e LOB_DATA. O que é isso?

Cada partição de uma tabela é alocada em um tipo de Allocation Unit, que pode ser IN_ROW_DATA, ROW_OVERFLOW_DATA ou LOB_DATA. Se quiser ler mais sobre Allocations Units, alguns links: Link1 | Link2

O SQL Server trata os objetos LOBs de forma distinta, considerando uns como Large User-Defined Type (varchar(max), nvarchar(max), varbinary(max) e xml) e outros como BLOB (text, ntext e image). Mas o que isso implica em termos práticos?

Por exemplo, se você usa VARCHAR(MAX), o SQL Server por default vai tentar armazenar o conteúdo LOB dentro da página de dados (IN_ROW_DATA), respeitando o limite de 8000 bytes. Caso o valor seja maior então a coluna é armazenado no LOB Storage (LOB_DATA) tendo apenas um ponteiro dentro do IN_ROW_DATA.

No exemplo de um campo TEXT, o SQL Server por default armazena o conteúdo LOB diretamente no LOB Storage (LOB_DATA).

Mas é possível alterar esse comportamento. Existem duas Table Options específicas pra armazenamento LOBs. Você pode alterá-las através do comando sp_tableoption. Segue abaixo parte da documentação do site da Microsoft, disponível também nesse link. Mas prestem atenção, cada configuração vale para tipos de dados distintos.

text in rowWhen OFF or 0 (disabled, the default), it does not change current behavior, and there is no BLOB in row.

When specified and @OptionValue is ON (enabled) or an integer value from 24 through 7000, new textntext, or image strings are stored directly in the data row. All existing BLOB (binary large object: textntext, or image data) will be changed to text in row format when the BLOB value is updated. For more information, see Remarks.
large value types out of row1 = varchar(max)nvarchar(max)varbinary(max)xml and large user-defined type (UDT) columns in the table are stored out of row, with a 16-byte pointer to the root.

0 = varchar(max)nvarchar(max)varbinary(max)xml and large UDT values are stored directly in the data row, up to a limit of 8000 bytes and as long as the value can fit in the record. If the value does not fit in the record, a pointer is stored in-row and the rest is stored out of row in the LOB storage space. 0 is the default value.

Large user-defined type (UDT) applies to: SQL Server 2008 through SQL Server 2017.

Use the TEXTIMAGE_ON option of CREATE TABLE to specify a location for storage of large data types.

Alguém percebeu que mesmo a configuração “large value types out of row” igual a 0, eu ainda tenho páginas no LOB_DATA? Por quê?

Conforme explicado acima o SQL Server armazena no ROW_DATA apenas os valores até 8000 bytes. Caso seja maior, ele utiliza um ponteiro para uma página LOB_DATA.

No meu exemplo, tenho 96399 linhas com mais de 8000 bytes e por isso foram armazenadas ao LOB_DATA.

-- Retorna registros com Texto maior que 8000 bytes
select
	count(Id) as [Count]
from 
	dbo.InventarioDB_Varchar 
where 
	DATALENGTH(Texto) > 8000


-- Count
-- -----------
-- 96399

Agora que entendemos o armazenamento de LOBs, como fica a performance ao buscar os dados? Vamos voltar ao nosso exemplo.

Lembrando que a consulta utilizada não necessita do valor da coluna Texto (varchar(max)). Pensando nisso, seria uma boa alternativa deixar os registros LOBs em um Allocation Unit exclusivo para LOB_DATA, certo? Dessa maneira teríamos menos páginas de dados IN_ROW_DATA e consequentemente menas leituras necessárias para retornar nossa consulta. Então vamos fazer esse teste.

-- Vamos habilitar o "large value types out of row" para a tabela
EXEC sp_tableoption 'InventarioDB_Varchar', 'large value types out of row', 1;

Ao alterar o modo de armazenamento da tabela InventarioBD_Varchar ele vai considerar apenas as novas operações. O que já está armazenado continua do mesmo jeito. Qual a solução então? Forçar uma operação em todas as linhas sem alterar o conteúdo. Após isso, vamos rodar um Rebuild e consultar como ficou a distribuição das páginas de dados na tabela.

-- Necessário atualizar todo o campo blob simplesmente pra assumir a nova configuração de armazenamento.
update InventarioDB_Varchar set Texto = Texto

-- Realiza o REBUILD pra eliminar eventual fragmentação
alter index all on InventarioDB_Varchar rebuild

-- Por fim, verifica alocação dos dados com novo modelo de armazenamento
exec dbo.GetPagesAllocation @object = 'InventarioDB_Varchar'

Uouuuu! A diferença é bem grande. Antes haviam 262396 páginas IN_ROW_DATA e agora temos 7091. Porém o número de páginas LOB_DATA aumentou para 483605 comparado a 244524. Vamos rodar novamente a consulta e comparar os resultados.

set statistics io, time on

-- Vamos fazer uma consulta para retornar quantidade de objetos por tipo.
select
	TipoObjeto
,	count(TipoObjeto) as [Count]
from
	dbo.InventarioDB_Varchar
group by
	TipoObjeto
order by count(TipoObjeto) desc

Obtivemos uma melhora significativa de performance, principalmente no número de Logical Reads. Conforme comparativo entre as duas execuções ANTES \ DEPOIS.

Logical ReadsCPU Time MsElapsed Time Ms
ANTES267398312143
DEPOIS70767881

OBSERVAÇÕES IMPORTANTES

Pessoal, por favor se atentem as observações abaixo.

  • O nosso exemplo é uma consulta leve, mas considerando um caso com tabelas maiores e alto volume de chamadas simultâneas, isso pode dar um fôlego grande para o ambiente e salvar a sua pele.
  • Cuidado, a consulta apresentada não retorna a coluna TEXTO (varchar(MAX)) e devido a isso ele não acessa as páginas LOB_DATA. Se o seu cenário for diferente, estude muito bem o seu ambiente para saber se essa alteração faz sentido ou não, pois o seu custo pode ficar maior.
  • Faça o mesmo teste com uma coluna TEXT e observe que por default ele já separa os valores LOBs em LOB_DATA. Não estou falando que TEXT é melhor, apenas notem o comportamento default. E não esqueçam: TEXT já está marcado como DEPRECATED.

Alguma dúvida, correção, crítica, sugestão? Por favor respondam nos comentários ou diretamente por email: guilherme@datatuning.com.br

REFERÊNCIAS

https://docs.microsoft.com/pt-br/sql/relational-databases/system-stored-procedures/sp-tableoption-transact-sql?view=sql-server-2017

https://docs.microsoft.com/pt-br/sql/t-sql/data-types/data-types-transact-sql?view=sql-server-2017

https://docs.microsoft.com/pt-br/sql/relational-databases/system-catalog-views/sys-allocation-units-transact-sql?view=sql-server-2017

https://docs.microsoft.com/pt-br/sql/relational-databases/system-catalog-views/sys-partitions-transact-sql?view=sql-server-2017

https://www.microsoftpressstore.com/articles/article.aspx?p=2225060

SQL Server – Understanding Allocation Units – In Row Data, LOB Data & Row Overflow Data

Antigo post do Luti (site da Nimbus que saiu do ar) e tenho apenas ele em modelo PDF, graças ao acervo digital do meu amigo Igor rs.

Dica: removendo arquivos do tempdb

Recentemente ao realizar o acerto dos arquivos do tempdb em instâncias do SQL Server 2012 e superiores, me deparei com uma situação que ainda não tinha visto nas versões anteriores ao SQL Server 2012.

Vamos a simulação do problema!

Ao executar o comando abaixo:

ALTER DATABASE tempdb REMOVE FILE temp03

O erro abaixo é apresentado:

Msg 5042, Level 16, State 1, Line 2
The file ‘temp03’ cannot be removed because it is not empty.

Com a mensagem acima, executei o comando abaixo:

USE tempdb
GO
DBCC SHRINKFILE(temp03,EMPTYFILE)

DBCC SHRINKFILE: Page 3:32 could not be moved because it is a work table page.

Msg 2555, Level 16, State 1, Line 4
Cannot move all contents of file “temp03” to other places to complete the emptyfile operation.

E agora? O SQL Server informa que não é possível remover o arquivo do tempdb porque o mesmo não está vazio e ao tentar realizar o shrink o SQL informa que não consegue mover todo o conteúdo para outro arquivo.
Confesso que a primeira vez que vi o erro fiquei confuso!

Abaixo, eu mostro como está a distribuição dos arquivos do tempdb da instância.

Trace Flag 3608

Para a simulação desse problema, estou utilizando o SQL Server 2017.
Uma das formas que eu encontrei para contornar esse comportamento é utilizando a Trace Flag 3608.
A TF 3608 faz com que não ocorra o start e recovery de nenhuma base de dados, exceto a master. Nessa situação as bases de dados só passarão pelo start e recovery ao serem acessadas e com isso é possível executar o comando de exclusão dos arquivos do tempb sem receber o erro “The file xxx cannot be removed because it is not empty”.

https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-2017

Habilitando a Trace Flag 3608

A primeira coisa a fazer é acessar o SQL Server Configuration Manager, ir nas propriedades do serviço do SQL Server e selecionar a aba Startup Parameter.

SQLServerConfigurationManagerStartupParameter

No campo Specify a startup parameter adicione o parâmetro -T3608 e clique no botão Add.

3608

Feito isso, basta realizar stop/start do serviço do SQL Server e com o SQL Server reiniciado, podemos observar no ERRORLOG que a engine fez o recovery apenas na base de dados master.

Com isso podemos observar que ao listar os arquivos do tempdb novamente, apenas os arquivos padrão de quando o SQL Server foi instalado será listado.

tempdb3608

Porém se listarmos os arquivos do tempdb pela sys.master_files iremos observar que os demais arquivos estão configurados, porém como o tempdb não foi realizado o recovery eles não estão em uso.

sysmasterfile3608

Feito isso agora iremos conseguir realizar a exclusão dos arquivos do tempdb com sucesso.

tempdb_removefile

Agora iremos remover a TF 3608 e dar stop/start no serviço do SQL Server para verificarmos se a remoção do arquivo temp03 de fato ocorreu e analisar que sem a TF 3608 todas as bases são startadas e o recovery é executado após o restart do serviço.

tempdb files

tempdb2

ERRORLOG

ERRORLOG após remoção da TF 3608.

Bom pessoal, espero que isso possa ajudá-los no dia a dia. Remover arquivos do tempdb não é uma tarefa que se realiza com frequência nos ambientes, mas é importante sempre checar essas configurações para que o tempdb não esteja configurado de forma errada.
Até a próxima.

1º Meetup da Data Tuning

Fala galera! No dia 30/05 às 20Hrs estaremos apresentando nosso primeiro Meetup online! Falaremos um pouco sobre as novas Features de Performance que estão vindo no Microsoft SQL Server 2019. Todos estão convidados para participar deste evento que é totalmente gratuito e online! Para se inscrever e ver mais detalhes é só clicar no link abaixo:

https://www.meetup.com/pt-BR/Data-Tuning-Group/events/261596790