Para saber mais sobre o SQLOS acesse o link abaixo:

When new partitions are added to a large table, statistics should be updated to include the new partitions. However the time required to scan the entire table (FULLSCAN or SAMPLE option) might be quite long. Also, scanning the entire table isn't necessary because only the statistics on the new partitions might be needed. The incremental option creates and stores statistics on a per partition basis, and when updated, only refreshes statistics on those partitions that need new statistics

ALTER DATABASE SANDBOX SET AUTO_CREATE_STATISTICS ON (INCREMENTAL = ON)

UPDATE STATISTICS [PartitionTable] ([PK__Partitio__357D0D3ED0CC792E]) WITH FULLSCAN, INCREMENTAL = ON

------------------------------------------------------------------------------------------------------------------------------ --GENERATE INCREMENTAL UPDATE STATISTICS FOR 1 TABLE SELECT 'UPDATE STATISTICS ' + QUOTENAME(object_name(object_id)) + ' (' + QUOTENAME(name) + ') WITH FULLSCAN, INCREMENTAL = ON' FROM sys.stats where object_id = object_id('[dbo].[PartitionTable]') and is_incremental = 0 ------------------------------------------------------------------------------------------------------------------------------ --GENERATE INCREMENTAL UPDATE STATISTICS FOR ALL PARTITIONED TABLES SELECT 'UPDATE STATISTICS ' + QUOTENAME(object_name(S.object_id)) + ' (' + QUOTENAME(s.name) + ') WITH FULLSCAN, INCREMENTAL = ON' FROM sys.tables T INNER JOIN sys.indexes I ON T.object_id = I.object_id INNER JOIN sys.data_spaces DS ON I.data_space_id = DS.data_space_id INNER JOIN sys.stats S ON I.object_id = S.object_id WHERE DS.type = 'PS' -- PARTITION_SCHEME -- PARTITION TABLE AND S.is_incremental = 0

1. UPDATE para tabelas não particionadas
2. UPDATE para tabelas particionadas, mas sem incremental
3. UPDATE para tabelas particionadas com incremental (2 ultimas partições)

DECLARE @RESAMPLE BIT = 1 DECLARE @PERCENT_SAMPLE INT = 100 -- IF @RESAMPLE = 0 SET @PERCENT_SAMPLE DECLARE @PROCESS_LAST_X_NONEMPTY_PARTITIONS INT = 2 ------------------------------------------------------------------------------ SELECT SQL_COMMAND = 'UPDATE STATISTICS ' + QUOTENAME(T.Name) + ' (' + QUOTENAME(S.name) + ') ' + IIF (@RESAMPLE = 1, 'WITH RESAMPLE', 'WITH SAMPLE ' + CONVERT(VARCHAR(3), @PERCENT_SAMPLE) + ' PERCENT') + CHAR(10) ,INFO = ' -- NON PARTITIONED TABLES' FROM sys.tables T INNER JOIN sys.indexes I ON T.object_id = I.object_id INNER JOIN sys.data_spaces DS ON I.data_space_id = DS.data_space_id INNER JOIN sys.stats S ON I.object_id = S.object_id WHERE DS.type = 'FG' -- ROWS_FILEGROUP -- NON PARTITION TABLE AND S.stats_id IS NOT NULL -- FILTER TABLES WITH NO STATISTICS ------------------------------------------------------------------------------ SELECT SQL_COMMAND = 'UPDATE STATISTICS ' + QUOTENAME(T.Name) + ' (' + QUOTENAME(S.name) + ') ' + IIF (@RESAMPLE = 1, 'WITH RESAMPLE', 'WITH SAMPLE ' + CONVERT(VARCHAR(3), @PERCENT_SAMPLE) + ' PERCENT') + CHAR(10) ,INFO = ' -- PARTITIONED TABLES NON INCREMENTAL' FROM sys.tables T INNER JOIN sys.indexes I ON T.object_id = I.object_id INNER JOIN sys.data_spaces DS ON I.data_space_id = DS.data_space_id INNER JOIN sys.stats S ON I.object_id = S.object_id WHERE DS.type = 'PS' -- PARTITION_SCHEME -- PARTITION TABLE AND S.is_incremental = 0 ------------------------------------------------------------------------------ IF (OBJECT_ID ('tempdb..#TEMP_LAST2PARTITIONS') IS NOT NULL) DROP TABLE #TEMP_LAST2PARTITIONS ;WITH AUX_LAST2PARTITIONS AS ( SELECT T.object_id ,TableName = T.Name ,I.index_id ,IX_Name = COALESCE(I.Name,'[HEAP]') ,P.partition_number ,P.rows ,i.data_space_id ,ROW_NUMBER = ROW_NUMBER() OVER ( PARTITION BY T.object_id, I.index_id ORDER BY P.partition_number DESC) FROM sys.tables T INNER JOIN sys.indexes I ON T.object_id = I.object_id INNER JOIN sys.data_spaces DS ON I.data_space_id = DS.data_space_id INNER JOIN sys.partitions P ON I.object_id = P.object_id AND I.index_id = P.index_id WHERE DS.type = 'PS' -- PARTITION_SCHEME -- PARTITION TABLE AND P.rows > 0 -- filter empty partitions ) SELECT * INTO #TEMP_LAST2PARTITIONS FROM AUX_LAST2PARTITIONS WHERE [ROW_NUMBER] <= @PROCESS_LAST_X_NONEMPTY_PARTITIONS CREATE CLUSTERED INDEX #IX_TEMP_LAST2PARTITIONS ON #TEMP_LAST2PARTITIONS (object_id, index_id, partition_number) ;WITH AUX AS ( SELECT AUX.object_id ,AUX.TableName ,AUX.index_id ,AUX.IX_Name ,StatsName = S.name ,AUX.partition_number ,AUX.rows ,PARTITION_VALUE = ISNULL(CAST(left_prv.value AS VARCHAR(MAX))+ CASE WHEN pf.boundary_value_on_right = 0 THEN ' > ' ELSE ' >= ' END , '-INF > ') + 'X' + ISNULL(CASE WHEN pf.boundary_value_on_right = 0 THEN ' >= ' ELSE ' > ' END + CAST(right_prv.value AS NVARCHAR(MAX)), ' > INF') FROM #TEMP_LAST2PARTITIONS AUX INNER JOIN sys.stats S ON aux.object_id = S.object_id LEFT JOIN sys.partition_schemes ps ON aux.data_space_id = ps.data_space_id LEFT JOIN sys.partition_functions pf ON ps.function_id = pf.function_id LEFT JOIN sys.partition_range_values left_prv ON left_prv.function_id = ps.function_id AND left_prv.boundary_id + 1 = aux.partition_number LEFT JOIN sys.partition_range_values right_prv ON right_prv.function_id = ps.function_id AND right_prv.boundary_id = aux.partition_number WHERE S.is_incremental = 1 ) SELECT SQL_COMMAND = 'UPDATE STATISTICS ' + QUOTENAME(TableName) + ' (' + QUOTENAME(StatsName) + ') WITH RESAMPLE ON PARTITIONS (' + CONVERT(VARCHAR(20), partition_number) + ')' + CHAR(10) ,INFO = ' -- PARTITIONED TABLES INCREMENTAL LAST (' + CONVERT(VARCHAR, @PROCESS_LAST_X_NONEMPTY_PARTITIONS) + ') PARTITIONS ON (' + PARTITION_VALUE + ')' FROM AUX ORDER BY TableName, IX_Name, StatsName, partition_number desc

Conclusão

• SCRIPT UPDATE STATS SET INCREMENTAL - FIRST TIME
• SCRIPT UPDATE STATS INCREMENTAL - MANUAL UPDATES
• SCRIPT UPDATE STATS INCREMENTAL - JOB SCRIPT

This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment. THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. We grant You a nonexclusive, royalty-free right to use and modify the Sample Code and to reproduce and distribute the object code form of the Sample Code, provided that You agree: (i) to not use Our name, logo, or trademarks to market Your software product in which the Sample Code is embedded; (ii) to include a valid copyright notice on Your software product in which the Sample Code is embedded; and (iii) to indentify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits, including attorneys' fees, that arise or result from the use or distribution of the Sample Code.

Please note: None of the conditions outlined in the disclaimer above will supersede the terms and conditions contained within the Premier Customer Services Description.

O SQL Server coleta e armazena dados  de estatísticas sobre as colunas utilizadas em predicados de consulta e sobre os índices que são criados para as colunas da tabela. As estatÍsticas são informações utilizadas pelo de otimizador consulta para ajudar a escolher qual algorítmo que será utilizado pelo SQL Server,  e como estimar a quantidade de linhas que serão processadas por essas operações; baseado nessa informação o SQL Server pode tomar a melhor decisão para criar um plano de execução.

Conceitos

Quando estamos falando de estatísticas e estimativa de registros dentro do SQL Server, geralmente esbarramos em alguns conceitos que são utilizados com bastante frequência, sendo assim, saber os conceitos o ajudará bastante a absorver o conteúdo a seguir neste artigo. Vamos para alguns conceitos:

Predicado: Uma condição que avalia para "Verdadeiro" e "Falso". Predicados aparecem em cláusulas JOINs e WHERE dentro de uma consulta.

Seletividade: Uma fração de um input de dados que safistaz um predicado específico. Quanto maior a seletividade menor será a quantidade de linhas que serão retornadas em uma consulta. Por exemplo, sabemos que no territorio nacional, temos dois tipos de sexo, sendo eles: masculino e feminino. Sendo assim, utilizar a coluna de sexo para criar um indice não é uma boa escolha, pois, ela NÃO é seletiva. Nesse caso, o valor de CPF é um excelente candidato, por ser bastante seletiva pelo fato de não haver duas pessoas com o mesmo CPF.

Cardinalidade: O número de linhas que atende uma determinada condição ou basicamente podemos dizer que é a porcentagem de linhas que serão estimadas para serem retornadas de uma determinada tabela.

Densidade: Se uma coluna é densa, ela retornará mais linhas para uma determinada consulta, pois, ela retornará mais valores duplicados para uma determinada coluna.Imagine o cenário: Uma tabela de clientes possui as colunas de BairroID e CidadeID (ambas colunas são chaves estrangeiras das tabelas Bairro e Cidade). Existe a possibilidade que a coluna CidadeID possua mais valores duplicados (ou menos valores únicos) do que a coluna BairroID, isso que dizer que, a coluna CidadeID teria uma densidade maior do que a coluna BairroID. Para calcular a densidade de uma coluna no SQL Server, basta apenas utilizar o comando abaixo:

SELECT (1.0 / COUNT(DISTINCT NomeDaColuna)) FROM NomeDaTabela

Obs: Sempre utilize comandos em ambientes de desenvolvimento para questões de análise.

Filtro: Uma condição que  é utilizada para avaliar se um registro deve ser parte de um indice filtrado ou estatistica filtrada. Após o SQL Server 2008 é possivel criar índices e estatísticas filtradas utilizando a cláusula WHERE, assim como fazemos hoje nas consultas. Por exemplo, imagine que o sistema XYZ possui uma tabela de Pedidos que possui um alguns milhões de registros. No entanto, a maioria das consultas do sistema fazem referência a data de cadastro do pedido e se os pedidos estão ativos, conforme a seguir: 

SELECT * FROM Pedidos WHERE dataPedido = 'XXXXX' and Ativo = 1

Sendo que o filtro citado acima representa apenas 10% do total da minha tabela. Talvez criar um índice ou estatística filtrada ajudaria no que diz respeito a armazenamento, influenciando diretamente em nossas rotinas de manutenção.

Obs: Não se preocupe muito se os conceitos não fazem total sentido nesse momento, mas, quando começarmos a analisar as estatísticas e seus respectivos resultados dentro do SQL Server, as coisas vão se tornar mais claras.

A estatísticas dentro do SQL Server

As estatísticas são estruturas que mantem uma amostragem de dados de uma determinada coluna ou um conjunto de colunas. Essa amostra das estatísticas no SQL Server são criadas e atualizadas automaticamentes dentro da engine do SQL Server se a propriedade Auto Create Statistics e Auto Update Statistics estiver habilitada. Por padrão, essas features já vem habilitadas, até mesmo porque é uma boa prática, fazendo com que o SQL Server faça boas escolhas para criar  planos de execução mais eficientes.  Como podemos ver através da consulta abaixo na view de sistema sys.databases, conforme a seguir:

Vale lembrar que quando as estatisticas são criada automaticamentes dentro do SQL Server, o SQL Server cria estatísticas apenas para uma coluna e não para um conjunto de colunas se a consulta possuir diversos predicados. Por exemplo: Se a consulta abaixo for realizada e a tabela não possuir estatísticas, o SQL Server criará uma estatística para cada coluna de forma independente, no caso, uma estatística para TransactionDate e outra para Quantity vejamos a seguir:

Execução da Consulta.

SELECT * FROM Production.TransactionHistory
WHERE TransactionDate = '20070906' and Quantity > 10

Se executarmos as consultas nas DMVs (sys.stats e sys.stats_columns) para identificar quais estatísticas foram criadas, podemos ver que o SQL Server criou duas novas estatísticas que é identificado através da coluna auto_created, conforme a seguir:

Consulta de metadados das estatísticas:

USE AdventureWorks2014
GO
SELECT OBJECT_NAME(a.object_id) AS Objeto, a.name, a.auto_created
FROM sys.stats a
WHERE OBJECT_NAME(a.object_id) = 'TransactionHistory'

O resultado da consulta anterior retorna as estatísticas que foram criadas automaticamentes e suas respectivas colunas: 

Como interpretar e ler o Histograma? 

Agora que sabemos o que é são as estatísticas no SQL Server, alguns conceitos básicos e como identifica-lás nas nossas tabelas e colunas, vamos aprender como ler o nosso histograma que é criado para cada estatística.

Histograma é uma amostragem dos dados que são representados em forma de tabela, a quantidade de valores que podem ser representadas nessa determinada tabela podem chegar até 200 passos/amostras. Fazendo uma analogia, imagine que o sistemo XYZ possui uma tabela no SQL Server que possuem alguns milhões de registros, e para uma determinada coluna dessa sua tabela existe uma estatística. A estatística dessa coluna é apenas uma amostragem de como os dados estão distribuidos e como o SQL Server pode consultar essa distribuição para estimar a quantidade de linhas que possui para um determinado valor ou em um intervalo de registros.

Para ver o histograma  de uma estatística nós vamos utilizar o comando DBCC SHOW_STATISTICS, conforme comando abaixo:

USE AdventureWorks2014
GO
DBCC SHOW_STATISTICS("Production.TransactionHistory", _WA_Sys_00000005_22401542)

 Após o comando ser executado, teremos como retorno o seguinte resultado:

Como pode ser visto, foram retornados três results, sendo eles na seguinte ordem: STAT_HEADER, DENSITY_VECTOR e HISTOGRAM. O maior foco desse artigo é trabalhar em cima do HISTOGRAMA, no entanto, as demais informações serão vistas em um outro momento.

STAT HEADER é o primeiro retorno que possuem algumas informações pertinentes a estatistica em si que veremos em um outro artigo.

DENSITY_VECTOR é o segundo conjunto de informações que temos  sobre nossas estatísticas. O Otimizador usa informações do vetor de densidade para melhorar a cardinalidade das consultas que irão rertonar muitos valores. Existe uma densidade para cada coluna (ou conjunto de coluna) da estatística, por exemplo, se nós tivéssemos uma estatística criada manualmente para as colunas: PedidoId e ClienteID. Teríamos uma informação de densidade da coluna  PedidoId e uma outra informação de densidade das colunas PedidoId e ClienteId.

HISTOGRAM é Terceira e última informação sobre as nossas estatísticas, esse resultado de fato é a distribuição dos dados em si de uma estatísticas e possuem as seguintes colunas:

RANGE_HI_KEY - Mostra o valor chave da coluna. Por exemplo, se a coluna da estatística é a data do pedido, você verá uma data nessa coluna.

RANGE_ROWS - A quantidade de linhas que está no range de um determinado valor. O Range Rows começa no RANG_HI_KEY + 1 da linha atual até o RANGE_HI_KEY -1 da linha atual. Por exemplo, dado a imagem anterior (colocar o número da figura) se olharmos para a linha 4 temos 466 registros no RANGE_ROWS. Essas 466 linhas existem do valor 2013-08-04 (que é a mesma coisa que o RANGE_HI_KEY + 1 da linha 3) e vai até o valor 2013-08-05(que é a mesma coisa que o RANGE_HI_KEY -1 da linha 4).

EQ_ROWS - A quantidade de valores exatos para os registros que aparecem na coluna RANGE_HI_KEY.

DISTINCT_RANGE_ROWS - A quantidade de valores distintos dentro do RANGE_ROWS. Isso significa que de 466 registros do RANGE_ROWS da linha 4, dois desses valores sao DISTINTOS, provavelmente um valor 2013-08-04 e outro valor 2013-08-05.

AVG_RANGE_ROWS - Esse valor basicamente  é o valor do RANGE_ROWS / DISTINCT_RANGE_ROWS.

Obs: Não se preocupe se parece confuso, agora iremos fazer essa leitura na pratica, isso tornará nosso exemplo muito mais simples de entender.

Se executarmos a consulta a seguir, o SQL Server deve estimar um total de 374 linhas, pois, esse e o valor que existe para a coluna EQ_ROWS dentro do HISTOGRAMA para o valor ‘2013-080-03’ na linha três.

USE AdventureWorks2014
GO
SELECT * FROM Production.TransactionHistory 
WHERE TransactionDate = '2013-08-03'

Plano de Execução

 Como o SQL Server chegou nesse valor? 

Agora vamos fazer uma consulta sobre um valor que não está no RANGE_HI_KEY, isso significa que o registro só pode estar entre algum outro intervalo do histograma. Se executarmos a consulta a seguir, o SQL Server deve estimar um total de 233 linhas.

USE AdventureWorks2014
GO
SELECT * FROM Production.TransactionHistory 
WHERE TransactionDate = '2013-08-04'
 

Plano de execução:

Como o valor utilizado como parâmetro, não aparece no RANGE_HI_KEY, o SQL Server utilizou o valor que está de maneira “oculta” na linha de número 4 (olhar a explicação contida sobre RANGE_ROWS discutido anteriormente).

Basicamente o SQL Server pegou o valor da coluna RANGE_ROWS do HISTOGRAMA e dividiu pelo valor DISTINCT_RANGE_ROWS, sendo 466/2. Conforme imagem a seguir:

Conclusão:

Nesse artigo podemos aprender um pouco sobre conceitos sobre estatísticas e de como o SQL Server utiliza as estatísticas para estimar uma quantidade de linhas que serão retornadas por uma operação. No próximo artigo discutiremos mais como as estatísticas funcionam em consultas utilizando valores de um determinado intervalo.

Referências:

https://msdn.microsoft.com/en-us/library/ms174384.aspx

https://technet.microsoft.com/en-us/library/dd535534(v=sql.100).aspx

http://blogs.msdn.com/b/bartd/archive/2011/01/25/query_5f00_tuning_5f00_key_5f00_terms.aspx

Primeiramente vamos criar algumas tabelas, ainda sem FKs e inserir alguns dados

USE [SANDBOX]
 GO
 
 ----------------------------------------------------------------------
 IF OBJECT_ID('[dbo].[tCliente]') IS NOT NULL
 DROP TABLE [dbo].[tCliente]
 GO
 IF OBJECT_ID('[dbo].[tEstado]') IS NOT NULL
 DROP TABLE [dbo].[tEstado]
 GO
 
 ----------------------------------------------------------
 CREATE TABLE [dbo].[tEstado]
 (
 [id_Estado] [int] NOT NULL,
 [Estado] [varchar](50) NOT NULL,
 CONSTRAINT [PK_tEstado] PRIMARY KEY CLUSTERED 
 (
 [id_Estado] ASC
 ) ON [PRIMARY]
 ) ON [PRIMARY]
 
 GO
 
 CREATE TABLE [dbo].[tCliente]
 (
 [Id] [int] NOT NULL,
 [Nome] [varchar](50) NOT NULL,
 [Id_Estado] [int] NOT NULL,
 CONSTRAINT [PK_tCliente] PRIMARY KEY CLUSTERED 
 (
 [Id] ASC
 ) ON [PRIMARY]
 ) ON [PRIMARY]
 GO
 
 ----------------------------------------------------------
 INSERT INTO [dbo].[tEstado] 
 VALUES (1,'SP'), (2,'RJ'), (3,'MG')
 GO
 INSERT INTO [dbo].[tCliente] 
 VALUES (1,'SERGIO',1), (2,'FERNANDO',2), (3,'MARIA',3)
 GO

Após a criação vamos fazer um SELECT simples. (Obs: Só retornamos dados da tabela cliente "C.Id, C.Nome, C.Id_Estado")

SELECT C.Id, C.Nome, C.Id_Estado 
 FROM [dbo].[tCliente] C
 INNER JOIN [dbo].[tEstado] E
 ON C.Id_Estado = E.id_Estado
 

 E vemos o plano:

Apesar de NÃO TER UTILIZADO os campos da tabela Estado no SELECT, o SQL precisa consultar a tabela estado para garantir que não referenciamos na tabela Cliente nenhum dado fora do domínio.

Para que o SQL saiba que não precisa consultar a tabela, ele tem que CONFIAR em algo como uma Foreign Key

ALTER TABLE [dbo].[tCliente] ADD CONSTRAINT
 FK_tCliente_tEstado FOREIGN KEY
 ( Id_Estado ) REFERENCES dbo.tEstado ( id_Estado ) 
 
 GO
 SELECT C.Id, C.Nome, C.Id_Estado 
 FROM [dbo].[tCliente] C
 INNER JOIN [dbo].[tEstado] E
 ON C.Id_Estado = E.id_Estado
 GO

Analisando novamente o plano, vemos que o SQL confia na FK e não precisa consultar uma tabela se os dados não são retornados.

Mas calma ! Não acabou.

O que acontece em sistemas de produção, principalmente em migrações? CARGA DE DADOS.

Qual técnica é usada para acelerar a carga?

1. Desligar FK
2. Carregar dados
3. Religar FK

Algo como o comando abaixo:

ALTER TABLE [dbo].[tCliente] 
 NOCHECK CONSTRAINT FK_tCliente_tEstado;
GO
INSERT INTO [dbo].[tCliente] 
 VALUES (4,'AAAA',1), (5,'BBBB',2), (6,'CCCC',3)
GO
ALTER TABLE [dbo].[tCliente] 
 CHECK CONSTRAINT FK_tCliente_tEstado;
 

Tudo OK? Não ! Na verdade, utilizando o comando acima, você ativa a constraint, mas apenas para o que for inserido a partir de agora. 

Logo, tudo o que foi inserido entre o momento que foi desligado e religado a FK, fica sem verificação. Ou seja, o SQL perde a confiança na FK, voltando ao estado inicial

Nos ambientes que tenho analisado, encontro muito este cenário, que pode levar a problemas de performance onde você não recebe um alerta, ou em caso de dados sem domínio valido, um UPDATE poderia gerar um erro.

Para verificar tudo o que está errado, use os comandos abaixo:

SELECT * FROM sys.foreign_keys 
WHERE is_not_trusted = 1
 
SELECT * FROM sys.check_constraints 
WHERE is_not_trusted = 1

Pegue todos as FKs e Check Constraints não confiáveis e ligue novamente utilizando o comando abaixo

OBS: Planeje o melhor horário esta atividade, pois o SQL terá que varrer toda tabela para validar os dados.

ALTER TABLE [dbo].[tCliente] 
 WITH CHECK CHECK CONSTRAINT FK_tCliente_tEstado;

REF: https://technet.microsoft.com/en-us/library/ms190273.aspx

"WITH CHECK | WITH NOCHECK               

Specifies whether the data in the table is or is not validated against a newly added or re-enabled FOREIGN KEY or CHECK constraint. If not specified, WITH CHECK is assumed for new constraints, and WITH NOCHECK is assumed for re-enabled constraints.

If you do not want to verify new CHECK or FOREIGN KEY constraints against existing data, use WITH NOCHECK. We do not recommend doing this, except in rare cases. The new constraint will be evaluated in all later data updates. Any constraint violations that are suppressed by WITH NOCHECK when the constraint is added may cause future updates to fail if they update rows with data that does not comply with the constraint.  

The query optimizer does not consider constraints that are defined WITH NOCHECK. Such constraints are ignored until they are re-enabled by using ALTER TABLE table WITH CHECK CHECK CONSTRAINT ALL."

Anexo o script utilizado para este exemplo.

Espero que tenham gostado e que seja útil para mais alguém, até a próxima!

SCRIPT_FK_NOT_TRUSTED.sql

Sintomas: Uma consulta a uma tabela de fila está lenta, chegando a dar timeout. Detalhe é a quantidade de linhas normalmente varia entre 0 e 30, com muitos INSERTs e DELETEs. Mesmo com o processamento da fila parado um select simples continuava lento.

• Select COUNT(*) =0.

• Sp_spaceused
  Rows = 0 / Data = 76.101.144KB ???    Hein ¯\_(ツ)_/¯ ...  Como ???

 
 
  
Deve ter algo desatualizado…

• EXEC sp_spaceused @updateusage = N'TRUE';

• “When updateusage is specified, the SQL Server Database Engine scans the data pages in the database and makes any required corrections to the sys.allocation_units and sys.partitions catalog views regarding the storage space used by each table. There are some situations, for example, after an index is dropped, when the space information for the table may not be current. updateusage can take some time to run on large tables or databases. Use updateusage only when you suspect incorrect values are being returned and when the process will not have an adverse effect on other users or processes in the database. If preferred, DBCC UPDATEUSAGE can be run separately.”. Ref https://msdn.microsoft.com/en-us/library/ms188776.aspx

• NADA :(

• Após alguma pesquisa cheguei em alguns problemas relacionados a heaps, ainda achei que não, pois jurava ter visto uma chave primária de relance. Mas ao olhar com mais detalhes verifico que é uma PK (Non-Clustered)

Agora vamos a simulação e ver se o problema é reproduzível.

Iniciando por um teste com índice cluster.

USE SANDBOX
 GO
 SET NOCOUNT ON
 
 GO
 IF OBJECT_ID('TABLE_CLUSTER') IS NOT NULL
 DROP TABLE TABLE_CLUSTER
 GO
 
 CREATE TABLE TABLE_CLUSTER
 (
 ID INT IDENTITY(1,1) PRIMARY KEY
 ,COL VARCHAR(8000)
 )
 GO
 ----------------------------------------------------------------------------------------------
 --INSERT 1 ROW
 ----------------------------------------------------------------------------------------------
 INSERT INTO TABLE_CLUSTER
 VALUES (REPLICATE('A',8000))
 GO
 SELECT total_pages, used_pages, data_pages FROM sys.allocation_units where container_id = ( SELECT partition_id FROM sys.partitions where object_id = object_id('TABLE_CLUSTER') )
 GO
 EXEC sp_spaceused 'TABLE_CLUSTER'
 GO
 ----------------------------------------------------------------------------------------------
 --INSERT +1000 ROWs
 ----------------------------------------------------------------------------------------------
 INSERT INTO TABLE_CLUSTER
 VALUES (REPLICATE('B',8000))
 GO 5000
 
 SELECT total_pages, used_pages, data_pages FROM sys.allocation_units where container_id = ( SELECT partition_id FROM sys.partitions where object_id = object_id('TABLE_CLUSTER') )
 GO
 EXEC sp_spaceused 'TABLE_CLUSTER'
 GO
 
 ----------------------------------------------------------------------------------------------
 --DELETE ROWS 1 by 1
 ----------------------------------------------------------------------------------------------
 DELETE TOP (1) FROM TABLE_CLUSTER
 GO 5001
 
 WAITFOR DELAY '00:00:05' -- WAITING FOR ASYNC CLEAN UP (*GHOST CLEAN UP)
 GO
 
 SELECT total_pages, used_pages, data_pages FROM sys.allocation_units where container_id = ( SELECT partition_id FROM sys.partitions where object_id = object_id('TABLE_CLUSTER') )
 GO
 EXEC sp_spaceused 'TABLE_CLUSTER'
 GO

OK. Tudo normal.

USE SANDBOX
 GO
 SET NOCOUNT ON
 
 GO
 IF OBJECT_ID('TABLE_HEAP') IS NOT NULL
 DROP TABLE TABLE_HEAP
 GO
 
 CREATE TABLE TABLE_HEAP
 (
 ID INT IDENTITY(1,1)-- PRIMARY KEY
 ,COL VARCHAR(8000)
 )
 GO
 ----------------------------------------------------------------------------------------------
 --INSERT 1 ROW
 ----------------------------------------------------------------------------------------------
 INSERT INTO TABLE_HEAP
 VALUES (REPLICATE('A',8000))
 GO
 SELECT total_pages, used_pages, data_pages FROM sys.allocation_units where container_id = ( SELECT partition_id FROM sys.partitions where object_id = object_id('TABLE_HEAP') )
 GO
 EXEC sp_spaceused 'TABLE_HEAP'
 GO
 ----------------------------------------------------------------------------------------------
 --INSERT +1000 ROW
 ----------------------------------------------------------------------------------------------
 INSERT INTO TABLE_HEAP
 VALUES (REPLICATE('B',8000))
 GO 5000
 
 SELECT total_pages, used_pages, data_pages FROM sys.allocation_units where container_id = ( SELECT partition_id FROM sys.partitions where object_id = object_id('TABLE_HEAP') )
 GO
 EXEC sp_spaceused 'TABLE_HEAP'
 GO
 
 ----------------------------------------------------------------------------------------------
 --DELETE ROWS 1 by 1
 ----------------------------------------------------------------------------------------------
 DELETE TOP (1) FROM TABLE_HEAP
 GO 5001
 
 WAITFOR DELAY '00:00:05' -- (*THERE IS NO GHOST CLEAN UP FOR HEAP) LET IT HERE JUST TO BE LIKE CLUSTER SCRIPT
 GO
 
 SELECT total_pages, used_pages, data_pages FROM sys.allocation_units where container_id = ( SELECT partition_id FROM sys.partitions where object_id = object_id('TABLE_HEAP') )
 GO
 EXEC sp_spaceused 'TABLE_HEAP'
 GO

 
 
 
 
Como assim 0 linhas e 40.008Kb.

Após várias pesquisas acabei chegando na resposta.

Segue também um KB

Space that a table uses is not completely released after you use a DELETE statement to delete data from the table in SQL Server

https://support.microsoft.com/en-us/kb/913399

No caso a solução a mais longo prazo é CRIAR UM INDICE CLUSTER e deixar ele lá. Mas uma solução que não está na documentação é fazer um REBUILD. (Recomendei a alteração na documentação e agora esta lá)

----------------------------------------------------------------------------------------------
--SOLUTION
----------------------------------------------------------------------------------------------

 ALTER TABLE TABLE_HEAP REBUILD
 
 SELECT total_pages,
 used_pages, data_pages FROM sys.allocation_units where container_id = ( SELECT partition_id
 FROM sys.partitions where object_id = object_id('TABLE_HEAP') )
 
 GO
 
 EXEC sp_spaceused 'TABLE_HEAP'
 
 GO
 

 Espero que tenham gostado e que seja útil para mais alguém, até a próxima!

*[UPDATE] Só para complementar, este problema aconteceu no SQL 2008 R2, provavelmente nas anteriores também, mas o mesmo comportamento se mantem até SQL 2014.

*[UPDATE 2] Books Online alterado com REBUILD (https://msdn.microsoft.com/en-us/library/ms189835.aspx)

TESTE_SCRIPT.sql

O Transaction Log é responsável por gravar todas as modificações realizadas por uma transação. Ele é essencial para o caso de uma falha (ex. falta de energia) o arquivo de Log é fundamental no processo de Recovery e trazer o banco de dados a um estado consistente.

Podemos ainda dizer que a capacidade de gravação de um banco de dados é limitada pela capacidade de gravação dos dados no Transaction Log.

O SQL Server 2014 introduziu uma série de melhorias com relação ao transaction log, para que fosse possivel manter a consistencia dos dados das tabelas In-Memory. Isso se deve ao fato de que as tabelas na memória precisam persisitir no Log da mesma maneira que é feito hoje nas tabelas no disco.

A feature In-Memory do SQL Server 2014 foi criada principalmente para resolver problemas de concorrência física quando vários usuários ao mesmo mesmo tempo fazem alterações em uma mesma Página/Estrutura Física em memória, o que chamamos de concorrência por Latch.

As operações nas tabelas In-Memory são operações muito rápidas e para que a performance do In-Mermory não fosse prejudicada foram feitas uma série de melhorias com relação ao transacion Log, essas melhorias são as seguintes:

• As operações de Insert e delete requerem menos espaço de gravações do que as tabelas em disco.

• In-Mermoy OLTP tenta agupar os registros de Log em um grande registro de Log com até 24KB, e com isso reduzir a quantidade de escritas.

• Agora o  In-Memory utiliza um modelo de concorrência otimista e as operações são gravadas apenas no momento do Commit, ao contrário das tabelas de disco que todos os passos erram gravados para possiblitar o Rollback das operações. Ou seja ele efetua todas alterações passo a passo e só grava no log no momento do Commit e isso reduz o número de vezes que uma transação precisa escrever no Log Buffer.

• As alterações nos índices In-Memory não são Logadas, com isso há um número muito menor de registros gerados no Transaction Log, caso ocorra restart da instância os índices das tabelas In-Memory são criados no processo de Recovery.

O ponto que gostaria de chamar atenção nesse artigo, é que além das melhorias citadas acima que ocorreram no produto, é recomendado que sejam utilizados discos SSD no volume onde é armazenado o arquivo de Log, caso contrário o ganho de performance com as tabelas In-Memory podem ser impossilitados ou suprimidos, porque mesmo as operações In-Memory (muito rápidas e sem Latch) precisam persistir no disco e quanto mais rapido a gravação no log ocorrer, melhor.

Veja agora uma DEMO que ilustra uma grande redução de Log nas transações das tabelas In-Memory:

O trecho abaixo irá criar um banco de dados com o nome de Demolog

USE master

GO

IF EXISTS (SELECT * FROM sys.databases WHERE name='DemoLog')

DROP DATABASE DemoLog;

GO

CREATE DATABASE DemoLog ON 

 PRIMARY (NAME= [DemoLog_data], FILENAME ='C:\DataHK\DemoLog_data.mdf'),

 FILEGROUP [DemoLog_FG] CONTAINS MEMORY_OPTIMIZED_DATA

 (NAME= [DemoLog_InMemory1],  FILENAME = 'C:\DataHK\StorageDemo_DemoLog_InMemory1')

 LOG ON (name = [DemoLog_log], Filename='C:\DataHK\StorageDemoLog_InMemory_log.ldf', size=100MB);

GO

--Agora vamos criar duas tabelas uma em Memoria com o nome de InMemoryLog e outra no disco com nome de DiscoLog.

USE DemoLog

GO

IF EXISTS (SELECT * FROM sys.objects WHERE name='InMemoryLog')

DROP TABLE [dbo].[InMemoryLog]

GO

-- Cria uma tabela In-Memory

CREATE TABLE [dbo].[InMemoryLog]

( [Campo1] int NOT NULL,

  [Campo2] char(100) NOT NULL, 

  CONSTRAINT [pk_InMemoryLog_campo1] PRIMARY KEY NONCLUSTERED HASH ([campo1])

  WITH(BUCKET_COUNT = 1000000)

) WITH (MEMORY_OPTIMIZED =ON,

 DURABILITY = SCHEMA_AND_DATA);

GO

IF EXISTS (SELECT * FROM sys.objects WHERE name='DiscoLog')

                   DROP TABLE [dbo].[DiscoLog]

GO

--Vamos criar uma tabela similar no disco.

 CREATE TABLE [dbo].[DiscoLog]

( [Campo1] int NOT NULL,

  [Campo2] char(100) NOT NULL)

GO

CREATE UNIQUE NONCLUSTERED INDEX ix_discoLog_campo1 on DiscoLog(Campo1);

GO

--Agora vamos inserir alguns registros na tabela e examinar o log com a função fn_dblog().

BEGIN TRAN

DECLARE @i int = 0

WHILE (@i < 100)

BEGIN

     INSERT INTO DiscoLog VALUES (@i, replicate ('1', 100))

      SET @i = @I + 1

END

COMMIT

--Veja que foram inseridos 200 registros no log.

SELECT *
FROM sys.fn_dblog(NULL, NULL)

WHERE PartitionId IN

     (SELECT partition_id FROM sys.partitions

      WHERE object_id=object_id('DiscoLog'))

ORDER BY [Current LSN] ASC;

GO

--Agora vamos rodar um script similar para inserir os dados nas tabelas In-Memory

 BEGIN TRAN

DECLARE @i int = 0

WHILE (@i < 100)

BEGIN

      INSERT INTO InMemoryLog VALUES (@i, replicate ('1', 100))

      SET @i = @i + 1

END

COMMIT

-- Olhe o Log

SELECT *
FROM sys.fn_dblog(NULL, NULL) order by [Current LSN] DESC;

GO

 Veja na imagem acima que há apenas um registro de LOG para todos os 100 Inserts com o tipo de LOP_HK, LOP indica que é uma operação lógica e HK é a inicial do do nome Hekaton que era o nome do projeto do In-Memory.

Agora utilize a query abaixo para visualizar o registros agrupados In-Memory (Veja o LSN da operação).

SELECT [current lsn], [transaction id], operation,

       operation_desc, tx_end_timestamp, total_size,

       object_name(table_id) AS TableName

FROM sys.fn_dblog_xtp(null, null)

WHERE [Current LSN] = '00000020:0000015f:0004';

Com isso, termino minha explicação sobre Log no In-Memory, espero que tenham gostado, até a próxima!

Alberto Lima - SQL Server PFE

A configuração de "Min Server Memory" é usada para atribuir o mínimo de memória que você imagina que seja necessário para uma instância SQL Server. Ao contrário do que muita gente pensa, logo após a configuração do “Min Server Memory” no sp_configure o SQL Server não irá utilizar essa memória imediatamente. Isso ocorrerá conforme os usuários utilizando os bancos de dados da instância e lendo as páginas do disco, até que o consumo de memória atinja o valor do "Min Server Memory".

Após o consumo de memoria superar o “Min Server Memory” e se estabeleça entre Min e Max , quando ocorrer uma pressão de memória externa, o Memory Manager do Sistema Operacional irá solicitar ao SQL Server que reduza seu consumo de memória em uma situação de pressão de memória externa o SQL Server não reduzirá sua utilização  abaixo do no estabelecido no "Min Server Memory" ou seja, não cederá esse espaço para o sistema operacional ou qualquer outro processo que esteja rodando no Windows.

Há alguma situação que SQL Server pode reduzir a utilização de memória RAM para abaixo do que o estabelecido em Min Server Memory?

Caso o sistema operacional precise que o SQL Server ceda mais memória além do mínimo e isso não ocorrer, o SQL Server poderá ter uma parte da memória alocada em PagingFile, que funciona como uma extensão da memória RAM, porém no disco. Essa extensão em disco que por sua vez, possui o acesso muito mais lento.

Nos contadores do SQL Server, mais especificamente no objeto "Memory Manager" do Performance Monitor, podemos visualizar esse consumo. Nele encontraremos os contadores:

• "Total Server Memory": demonstra o total que a instância utiliza como memória Committed pelo Memory Manager (representado na cor verde).
• "Target Server Memory": demonstra o total de memória que o SQL Server pretende atingir e normalmente ele está alinhado com o "Max Server Memory" que foi atribuido à instância
• "Stolen Server Memory" : é a quantidade de páginas "roubadas" do BufferPool.

Observe o seguinte raciocínio:

Imagine que você possui uma instância SQL Server 2012, rodando em Windows Server 2012, com 100 GB de Memória RAM e você teve que reiniciar a instância após efetuar atividade de manutenção à meia noite. Os bancos de dados dessa instância possuem uma grande atividade durante o horário regular do expediente de trabalho entre as 09:00 e 18:00 horas. Imagine também que você configurou o "Min Server Memory" da instância para 30GB e o "Max Server Memory" para 80GB, consequentimente deixando 20GB para outros componentes, threads stack e outros processos no sistema operacional.

Observe a imagem abaixo que ilustra o cenário descrito acima:

No gráfico acima, o “Total Server Memory” é o total de memória que o SQL está utilizando no momento. Observe que devido ao restart da instância que ocorreu a  meia-noite, a utilização da memória começou em zero e foi aumentando gradualmente de acordo com atividades que foram sendo executadas nos bancos. Podemos observar também que a quantidade de memória sendo utilizada, atinge o estabelecido em “Min Server Memory” apenas quando o horário de expediente começa, por volta das 9:00. Nesse nosso ambiente hipotético, após o início dos trabalhos, a quantidade de páginas lidas aumentou e atingiu o “Target Server Memory” ao meio dia - vale relembrar que comumente encontramos o “Target Server Memory” com o valor igual ao de “Max Server Memory”.

Voltando a análise, imagine agora que um processo externo ao SQL começou a ser executado ao meio dia, este processo consome muita memória, o “Memory Manager” do Sistema operacional irá solicitar que o SQL reduza seu consumo para dar espaço para esse processo. Uma vez que essa ação seja tomada pelo SO, o SQL irá devolver memória até que o limite de “Min Server Memory” seja atingido. Quando isso ocorrer, você verá que o “Target Server Memory” será reduzido e terá um novo valor (no caso, 60GB). O SQL então fará um flush de suas páginas em memória e fará com que a memória utilizada por ele chegue ao valor de “Target Server Memory” – o que ocorre as 16:00.  

Por fim, o processo externo que vinha consumindo muita memória, termina sua execução. Ao término, o SQL poderá utilizar novamente o espaço solicitado anteriormente pelo SO e preencher o cache de dados com outras páginas. Essa ação fará com que o “Target Server Memory” volte a crescer, até que atinja o valor de “Max Server Memory” novamente.

Como estimar a quantidade de memória física para uma instância SQL Server?

Essa é não uma pergunta simples de responder. Em um mundo perfeito, a quantidade ideal de memória para uma instância SQL Server seria fazer com que a instância tenha espaço suficiente para colocar em cache de dados todas as páginas so seu banco de dados. Desta forma a instância não precisará em momento algum trazer as páginas de dados do disco, pois as mesmas já estariam no BufferPool. No ambiente corporativo e maior parte dos casos, obviamente não temos memória suficiente para tal, porém quanto mais memória eu tiver para cache, melhor.

O contador do Perfmon "Page Life Expectancy" é um 'indicador para visualizarmos quando há uma pressão de memória. Esse contador mostra uma média de segundos em que suas páginas de dados permanecem em memória, ou seja, por quanto tempo essas páginas estão sendo reaproveitadas por outras consultas sem precisar ir ao sistema de discos. Há vários documentos que citam o número mágico de 300 segundos para esse contador. Na realidade não existe um número exato, o que eu não se pode esperar deste contador é que haja quedas muito bruscas. O fato deste tempo diminuir é um indício de que houve uma pressão interna ou externa de memória, fazendo com que novas páginas tenham que vir de disco e varrendo as antigas do BufferPool.

Quando habilito Lock Pages In-Memory (LPIM) o processo SQL Server pode ir para o PagingFile?

Quando é concedida de permissão de "Lock Pages In Memory" para conta de serviço, o SQL Server utilizará memória AWE (Address Windowing Extention) para alocação de páginas de até 8KB e neste caso a memória adquirida via AWE NÃO poderá ir para PagingFile pois não faz parte do WorkingSet do processo do SQL Server.

Para maiores informações sobre Lock Pages In-Memory em 64 bits, veja o link abaixo:

http://blogs.msdn.com/b/slavao/archive/2005/04/29/413425.aspx

Devo sempre atribuir o Min e Max Server Memory da minha instância?

A resposta é depende. Quando em um servidor a instância SQL Server não é compartilhada com mais nada, é muito mais difícil que os cenários de pressão de memória mencionados aqui ocorram. No entanto, em uma instância SQL Server em cluster, é bastante importante que sejam atribuídos o Max e principalmente o Min Server Memory. Suponha que voce possua dois servidores cada um com a instancia SQL Server, uma chamada de InstA e a outra de InstB e que possam fazer Failover entre eles. Em um dado momento occorre uma falha no Servidor da InstA e foi feito o Failvover para InstB. Após o failover, as duas instâncias terão que compartilhar a mesma memória. Caso o "Min Server Memory" tenha sido atribuido com um valor muito alto na InstB, poderá faltar uma memória mÍnima para que a InstA consiga ser operacional. (Ex: Uma maquina de 100GB  de Memória RAM que possui uma instância com o "Min Server Memory" de 70GB e o "Max Server Memory" também com 70GB, o que chamamos de Memória Estática), a instância InstA terá apenas 30GB para dividir com as threads da outra instância e entre os processos do sistema operacional, porque a InstB já utilizou 70GB e sobrará pouca memória para a instância e o servidor operarem.

Espero essa série de atigos tenha auxiliado a um melhor entendimento do que levar ou não em consideração ao se configurar o Min e Max Server Memory de suas instâncias SQL Server.

Até a próxima pessoal.

Para quem não viu a primeira parte:

Configurando o Min e Max Server Memory – Parte 1

Alberto Lima

Pessoal, gostaria de compartilhar minha apresentação sobre Troubleshooting com DMVS, que fiz no SQL Saturday #325.

A idéia foi demonstrar de forma rápida quais DMVS mais utilizadas, entender como definir uma estratégia eficaz de troubleshooting, para isso eu demonstrei inicialmente como os componentes do SQL Server estão distribuídos e onde as DMVS entram nisso…

https://skydrive.live.com/redir?resid=A909ABAAAF1D7D57!35163

Queria agradecer àqueles que puderam assistir minha palestra, e àqueles que não conseguiram … podem ter uma idéia do conteúdo.

Abraços

Hoje o acesso as páginas de dados em disco estão na casa dos milissegundos, enquanto o acesso em memória está na casa dos nanossegundos. Partindo desse pressuposto, podemos dizer que o acesso a páginas em memória é mais bem mais rápido do que o acesso a disco, o que não é nenhum mistério para nós. O SQL Server também sabe disso e tentará o máximo possível efetuar cache e colocar suas páginas em memória. O BufferPool normalmente é o componente do SQL Server que mais utiliza memória, pois nele ficam armazenadas as páginas de dados.

Quando efetuamos uma Query(consulta) o Storage Engine utiliza o Access Methods para retornar as páginas de dados necessárias para atender essa requisição, essas páginas podem estar no cache de dados, ou seja, no BufferPool, caso as páginas da tabela ou índice da operação (leitura/alteração) não estiverem no BufferPool, o SQL Server acessará o disco (Storage) e irá trazer essas páginas para o BufferPool.

O BufferPool é formado por buffers de 8KB para armazenar páginas de dados e ao contrário do que muitos pensam NÃO é lugar se armazena o Procedure Cache.
Conforme os usuários acessam os dados em suas tabelas e índices, as páginas de dados vão sendo armazenadas no BufferPool e com isso o consumo de memória aumenta, até chegar bem próximo do limite físico da máquina. Cada página no SQL Server tem o tamanho de 8KB, se você acessar 1.000.000 de páginas (diferentes), você terá algo em torno de 7812 MB de cache de dados, sem um limitador, essas páginas consumirão memória do cache até que ocorra uma pressão interna ou externa. Tal limitador é chamado de Max Server Memory. Além do Max Server Memory, que limita o máximo de memória RAM que poderá ser consumida pelo BufferPool, temos o  Min Server Memory", que limita o mínimo de memória, cujo qual irei explicar a seguir.

Min Server Memory e Max Server Memory.

Em uma instância SQL Server podemos configurar por meio do sp_configure o Min e Max Server Memory. Quando os configuramos estamos atribuindo o “mínimo” e o "máximo" de memória que umainstância SQL Server poderá utilizar, porém existem algumas diferenças entre versões do SQL Server que irei explicar com mais detalhes a diante.

É comum configurarem o "Max Server Memory" próximo do total de memória física do servidor, deixando um pouco de espaço para que o sistema operacional opere de forma satisfatória, sem que ocorra pressão de memória externa por parte do OS. Para atribuir o "Min Server Memory" e o "Max Server Memory", devemos levar em conta as seguintes considerações de acordo com as seguintes versões do SQL Server.

SQL Server 2008 R2 - Max Server Memory.

Das versões anteriores até a versão SQL Server 2008 R2, quando configuramos o "Max Server Memory" estamos atribuindo o total de memória que o SQL Server utilizará como cache de dados, ou seja, estamos atribuindo o total de memória que apenas o BufferPool utiliza e também memória que ele fornece para outras alocações (até 8KB) que são para outro propósito ou para componentes na Engine que não são "Database Pages". Essas páginas são chamadas de Stolen Pages, que traduzindo ao pé da letra são páginas roubadas, exatamente porque foram páginas roubadas do BufferPool para outras "funcionalidades" no SQL Server. Esse valor pode ser visualizado na stolen_pages_kb da DMV sys.dm_os_memory_clerks e esse consumo faz parte do Max Server Memory. Porém há uma outra série de alocações de memória, além das descritas acima que não faz parte da memória que foi atribuída no Max Server Memory e essas alocações são as seguintes:

• Alocações Multi-Page, que são alocações que utilizam mais que 8K. Essas duas alocações podem ser visualizadas na coluna multi_pages_kb da DMV sys.dm_os_memory_clerks.
• Alocações de CLR, que inclui as Heaps.
• Alocações feitas para threads dentro do processo do SQL Server.
• Alocações de Extended Store Procedures, objetos criados usando OLE Automation procedures(sp_OA calls) e Alocações de Linked Server.

SQL Server 2012 - Max Server Memory.

No SQL Server 2012 o "Max Server Memory" não limita somente o total de memória que o BufferPool utiliza, as alocações de memória mudaram, este funcionamento tomaria uma outra série de posts para explicar, mas basicamente o BufferPool é apenas um consumidor de memória como todos os outros “Memory Clerks”. Desde do SQL Server 2012 todas essas alocações podem ser visualizadas através da coluna pages_kb da sys.dm_os_memory_clerks, que inclui as alocações de “Stolen pages” de “Multipage” das versões anteriores.

Hoje o “Max Server Memory” limita "quase" toda a memória do SQL Server e as exceções são as seguintes:

• Alocações feitas para threads dentro do processo do SQL Server.
• Alocações de Extended Stored Procedures, objetos criados usando OLE Automation procedures(sp_OA calls) e Alocações de Linked Server.

Cada Thread tem 2MB de Stack Size, para calcular o máximo de Worker Threads que uma instância SQL Server poderá utilizar há a seguinte formula:

Maximum worker threads = (512+ (NumerodeProcessadoresdaMaquina - 4) * 16)

SQL Server 2014 – Max Server Memory

Os valores referentes a utilização de memória SQL Server 2012 também são válidos para o SQL Server 2014. Quando utilizamos a feature In-Memory OLTP adicionando uma tabela em memória “Memory Optimized Tables”. Observe como ficaria uma divisão de memória na Imagem 1 do diagrama abaixo.
 
 


Conforme adicionamos outras tabelas em memória, essas tabelas vão ocupando espaço, porém não devemos esquecer que mais tabelas virão do disco para memória. Por isso, quando se for criar uma tabela In-Memory não se pode esquecer de provisionar seu tamanho inicial, dimensionando também seu crescimento para não causar um cenário como a imagem 2, na qual se possui algumas tabelas In-Memory que ocupam um grande espaço, porque nestes casos as tabelas ficam inteiras na memória e pode faltar espaço para outras páginas que virão do disco.

Veja um exemplo de como configurar “Max Server Memory” de uma instância com 40GB via linha de comando abaixo:

sp_configure 'show advanced options', 1;

GO

RECONFIGURE;

GO

sp_configure 'max server memory', 40960;

GO

RECONFIGURE;

GO

Para maiores informações de como configurar o Max Server Memory acesse o link:

http://msdn.microsoft.com/en-us/library/ms178067.aspx

No próximo post continuarei com Min Server Memory e alguns exemplos de como isso acontece em algumas instâncias.

Configurando o Min e Max Server Memory – Parte 2

Alberto Lima