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.

Introdução a Algoritmos de Joins no SQL Server

Pessoal, o post de hoje foi feito para explicar de maneira bem rápida os operadores de joins existentes no SQL Server. Entender cada tipo de join é essencial para uma boa análise de performance, pois os tempos de execução podem variar bastante de acordo com cada cenário.
Muitas pessoas perguntam. Qual o melhor operador de join? Não há. Cada um tem características específicas e são utilizados em cenários distintos. Por isso a importância de conhecer cada um deles.
Existem 3 operadores de JOIN no SQL Server: Nested Loops, Hash Join e Merge Join.

NESTED LOOPS

Como o próprio nome sugere, utiliza a ideia de loop. Para cada valor de uma tabela (outer input), faz-se uma busca de igualdade na outra tabela (inner input). É muito efetivo quando utilizado em cenários onde um input possui poucos registros e o inner input possui índice para a condição de igualdade.
No exemplo abaixo o Query Optimizer resolveu utilizar o NESTED LOOPS como solução para o INNER JOIN.

select top 1000
  SalesOrderID   = sor.SalesOrderID
, LineTotal      = sor.LineTotal
, OrderDate      = soh.OrderDate
, ShipDate       = soh.ShipDate
, TrackingNumber = sor.CarrierTrackingNumber
from       Sales.SalesOrderDetail sor
inner join Sales.SalesOrderHeader soh 
           on sor.SalesOrderID = soh.SalesOrderID
where    sor.CarrierTrackingNumber = '6431-4D57-83'
order by sor.SalesOrderID

Perceba que o número de linhas estimadas é pequeno, porque nesse caso foi utilizado o filtro “where sor.CarrierTrackingNumber = ‘6431-4D57-83′”.

Nesse cenário o plano de execução se mostrar muito bom, uma vez que necessitou de apenas 9 Logical Reads pra retornar o result set em microssegundos.
Table ‘SalesOrderHeader’. Scan count 0, logical reads 6 Table ‘SalesOrderDetail’. Scan count 1, logical reads 3.
CPU time = 15 ms, elapsed time = 0 ms.

MERGE JOIN

O Merge Join geralmente é utilizado para grandes volumes de dados. Ele necessita de dois inputs ordenados pelo valor de comparação (ON clauses), onde é feito o teste de igualdade linha a linha de cada output. Sua condição de parada é ao término dos dados do menor input.
Retirando a condição de busca por TrackingNumber, verifica-se uma alteração no plano de execução, onde o Query Optimizer opta por utilizar o MERGE JOIN.

select top 1000
  SalesOrderID   = sor.SalesOrderID
, LineTotal      = sor.LineTotal
, OrderDate      = soh.OrderDate
, ShipDate       = soh.ShipDate
, TrackingNumber = sor.CarrierTrackingNumber
from       Sales.SalesOrderDetail sor
inner join Sales.SalesOrderHeader soh 
           on sor.SalesOrderID = soh.SalesOrderID
order by sor.SalesOrderID

Como mencionado acima, o Merge Join utiliza inputs ordenados. No exemplo utilizado as duas tabelas possuem índices ordenados pela coluna SalesOrderID.

HASH JOIN

O Hash Join é geralmente utilizado para grandes volumes de dados, condições não indexadas, entre outros. É composto por duas fases: Build e Probe. Na primeira fase (Build), o Query Engine escolhe o menor input e gera uma Hash Table baseado nas Hash Keys. Na segunda fase (Probe), toda linha do segundo input é transformado em hash e comparado com a Hash Table gerado na fase Build, retornando assim todas as igualdades. Importante lembrar que se o Memory Grant da consulta não for suficiente, o SQL Server irá utilizar a TEMPDB para armazenar a Hash Table.

No exemplo abaixo, retirando-se o TOP 1000 e alterando a ordenação para ShipDate, o Query Optimizer decidiu por utilizar o Hash Match.

select 		
  SalesOrderID   = sor.SalesOrderID
, LineTotal      = sor.LineTotal
, OrderDate      = soh.OrderDate
, ShipDate       = soh.ShipDate
, TrackingNumber = sor.CarrierTrackingNumber
from       Sales.SalesOrderDetail sor
inner join Sales.SalesOrderHeader soh 
           on sor.SalesOrderID = soh.SalesOrderID
order by soh.ShipDate

FORCE JOIN (CUIDADO!)

É possível forçar a utilização de um algoritmo de join no seu código T-SQL, mas cuidado! Isso pode gerar dor de cabeça se não for bem utilizado. Basta colocar o nome do algoritmo entre o INNER | LEFT | RIGTH | FULL e o JOIN.
Exemplo:

select top 1000
  SalesOrderID   = sor.SalesOrderID
, LineTotal      = sor.LineTotal
, OrderDate      = soh.OrderDate
, ShipDate       = soh.ShipDate
, TrackingNumber = sor.CarrierTrackingNumber
from             Sales.SalesOrderDetail sor
inner MERGE join Sales.SalesOrderHeader soh 
                 on sor.SalesOrderID = soh.SalesOrderID
where    sor.CarrierTrackingNumber = '6431-4D57-83'
order by sor.SalesOrderID

É isso aí pessoal, se tiverem alguma dúvida por favor deixar um comentário.
Obs: os exemplos foram feitos em cima da base AdventureWorks, disponível nesse link.

REFERÊNCIA

Tipo de Joins no SQL Server

https://docs.microsoft.com/en-us/sql/relational-databases/performance/joins?view=sql-server-2017