Gostaria de anunciar que o episódio 2 da série SQL em 5 minutos já está no ar! 
Nesse episódio, dou continuidade ao primeiro assunto que estou abordando na série: Wait Statistics, com foco em um segundo Wait Type, o LOGBUFFER. 

Você pode assistir o vídeo através do link: [View:https://youtu.be/1S0K14M0oIc] 

Se você curtir, compartilhe com sua rede de contatos e amigos que você acha que iriam se beneficiar do conteúdo e se inscreva no meu canal para ter acesso aos vídeos assim que forem publicados!

Como mencionei no post anterior sobre essa série, todos os feedbacks são bem vindos e eu gostaria que enviassem suas dúvidas sobre SQL Server, pois no futuro quero dedicar alguns vídeos dessa série para responder perguntas sobre o produto, funcionalidades, bem como outros aspectos que achem interessantes.

Espero que gostem!

Um abraço,

Thiago Caserta.

Há algumas semanas, porém, um desenvolvedor me trouxe uma situação interessante que eu não consegui explicar o motivo logo de cara. Talvez porque, como eu mencionei, há alguns meses tenho focado menos em desenvolvimento, ou talvez porque a grande maioria das tabelas que gerenciamos hoje em dia possuem bem mais do que 1000 registros.

O cliente me encaminhou o seguinte report do Connect e disse que após um Failover uma das tabelas com uma coluna identity saltou de 63 para 1001.

 https://connect.microsoft.com/SQLServer/feedback/details/739013/failover-or-restart-results-in-reseed-of-identity

Ele já me apontou de cara um Trace Flag, o 272, pois disse ter pesquisado o assunto e que com esse Trace Flag esse comportamento não acontecia. Ao mesmo tempo ele achou estranho e disse suspeitar de um bug no produto.

Bem, mais interessado do que no TF em si, já que se há um Trace Flag eu já entendo que se trata de uma alteração do comportamento padrão, eu queria entender o porque esse comportamento deveria ser então esperado.

 A primeira coisa, e talvez a mais óbvia, que eu fiz, foi ler a documentação sobre o Identity, e vi algo que me chamou a atenção e até então eu realmente desconhecia.

 “Consecutive values after server restart or other failures – SQL Server might cache identity values for performance reasons and some of the assigned values can be lost during a database failure or server restart. This can result in gaps in the identity value upon insert. If gaps are not acceptable then the application should use its own mechanism to generate key values. Using a sequence generator with the NOCACHE option can limit the gaps to transactions that are never committed.”

https://technet.microsoft.com/en-in/library/ms186775.aspx

Aqui já percebi uma coisa sobre o caso que ele me trouxe: Não, isso não é um bug, como ele havia sugerido inicialmente, e sim um comportamento esperado, apenas confirmando minhas suspeitas. Ao mesmo tempo isso talvez seja considerado um comportamente bem estranho para alguns. 

Relendo a documentação do SQL 2008 R2 por exemplo, há apenas um alerta com relação a possíveis gaps na sequência do identity, sempre causados por deleção de registros, algo esperado, mas não por uma falha, ou até mesmo um simples restart  como nesse cenário.

 Testando o comportamento, percebi que ele, de fato, acontece. Veja que interessante essa sequência após o restart da minha instância 2012.

A pergunta agora é: Em que situação esse comportamento, até então um pouco bizarro, faz sentido? Bem, seguindo a documentação do SQL 2012, aqui está, talvez, a principal razão:

"SQL Server might cache identity values for performance reasons and some of the assigned values can be lost during a database failure or server restart ... These restrictions are part of the design in order to improve performance.".

Analisando mais a fundo, a minha explicação final é de que a partir da versão 2012 o SQL Server utiliza um cache de 1000 entradas para colunas identity. Ou seja, há 1000 valores reservados que já estão em memória, ou seja, em cache, para que o desempenho seja superior em caso de novas escritas. Caso não seja utilizado todos os valores dentro daquele cache, no caso de um restart por exemplo, a sequência é reiniciada, porém como se trata de um cache de 1000 registros, não seria possível reinciciar o mesmo a partir do valor 0, já que existem registros inseridos, então ele reinicia, automaticamente, a partir do primeiro valor do próximo intervalo, de 1001 a 2000, por exemplo.

Existem dois "workarounds" para esse comportamento, que mais uma vez, é assim by design: 

1. Habilitar a TF272, como mencionei no começo, nos parâmetros de inicialização da instância
2. Utilizar o SEQUENCE, introduzido no SQL 2012, para tabelas que contém menos de 1000 registros

Qual o impacto de se utilizar o TF272?

Considerando que o cache de 1000 valores para colunas identity tem o objetivo de aumentar o desempenho durante a inserção de novos registros, habilitar o TF anula essa otimização do produto. Pra ser sincero, testando e simulando o desempenho das minhas escritas, eu não senti muita diferença, porém se você considerar milhares de inserções por minuto, talvez o comportamento padrão seja, de fato, benéfico.

Um abraço,

Thiago Caserta.

A idéia é complementar o conteúdo da série Fundamentos e lhe ajudar a se munir de informações para resolver problemas em seus ambientes SQL da melhor forma possível (mais rápido e mais assertivo).

O primeiro video da série, que chama SQL em 5 minutos, porque quero fazer diversos vídeos curtos, que geralmente são mais fáceis de digerir e não tomam muito do seu tempo, tem na verdade 13 minutos. Hahaha. O motivo é simples. Eu dei uma breve introdução à série e ao tópico que iremos abordar nos primeiros vídeos da série.

[View:https://www.youtube.com/watch?v=lAsR5EolYdA] 

Feedbacks são bem vindos e eu gostaria que enviassem suas dúvidas sobre SQL Server, pois no futuro quero dedicar alguns vídeos dessa série para responder perguntas sobre o produto, funcionalidades, bem como outros aspectos.

Espero que gostem!

Um abraço,

Thiago Caserta.

Infelizmente não poderia cobrir todos os aspectos do Storage Engine em um vídeo de 15 minutos, por isso acredito que teremos mais vídeos falando especificamente deste componente. Espero que gostem. 

STORAGE ENGINE

O Storage Engine é um dos componentes mais complexos do SQL Server. Ele é o principal componente, junto a Engine Relacional, dentro do SQL Server. Apesar de o Storage Engine e o Relational Engine serem totalmente independentes, eles interagem entre si através dos components de acesso nativo, como o OLE DB.

As principais responsabilidades do Storage Engine são:

• Gerenciar o armazenamento dos dados em discos e todo o IO necessário para acesso a essa estrutura
• Armazenar e gerenciar as estruturas físicas dos objetos, utilizando blocos, como páginas
• Prover a capacidade de manter dados em uma estrutura de memória, chamada de buffer, ou cache
• Controlar concorrência
• Gerenciar transações e locks
• Recuperar os dados em caso de falhas

Vamos falar um pouco sobre alguns dos itens mencionados. 

ARMAZENAMENTO

Assim como outras plataformas relacionais, o SQL Server possui uma estrutura de memória, parte do Storage Engine, conhecida como Buffer Pool, ou Buffer Cache. Essa estrutura armazena páginas de memória de 8k, o tamanho utilizado, por padrão no SQL Server, para armazenamento dos dados.

As páginas de 8k são armazenadas fisicamente nos arquivos de dados, os .mdf e .ndf, em grupos de 8 páginas. Essa estrutura de 8 páginas de 8k chama-se extents, o que forma uma estrutura com tamanho total de 64k. O SQL Server utiliza a estrutura de extents para otimizar as leituras e escritas por ler e escrever mais dados ao invés de apenas 8k, porém algumas operações fazem especificamente IOs de 8k, por lidarem com páginas específicas.

Vamos dar um pouco mais de foco agora em como ocorre a interação do Buffer Pool com os demais componentes e demais tarefas do SQL quando uma leitura é realizada.

PROCESSO DE LEITURA DOS DADOS

Quando efetuamos uma leitura a partir da nossa aplicação, por exemplo, uma dll C#, há um fluxo natural a ser seguido.

Sua aplicação se conecta ao SQL Server através da camada de Protocolos e sua consulta deve obrigatoriamente passar pela Engine Relacional. O Relational Engine então faz a validação, ou Parse da Query, e durante o processo de otimização gera um Plano de Execução para esta consulta. Este plano então é armazenado numa área de memória, conhecida como Plan Cache para otimizar as próximas execuções desta query. Não vou entrar em muitos detalhes sobre o otimizador de queries ou plan cache nesse momento, mas falaremos mais sobre isso quando entrarmos em Relational Engine.

Este plano de execução gerado pela Engine Relacional serve como um mapa para que o próximo componente, o Storage Engine, seja capaz de buscar os dados solicitados da melhor forma possível, ou quase isso, já que durante a otimização, o otimizador de queries não escolhe necessariamente o melhor plano mas sim um plano bom o suciente para a execução da Query. A Razão é simples, demandaria muito tempo escolher o melhor plano possível.

A partir deste plano o Storage Engine pode realizar as tarefas necessárias para buscar os dados que suas consultas solicitaram. O primeiro local no qual o Storage Engine tenta buscar os seus dados é no seu próprio cache, ou seja, o Buffer Pool. Todas as consultas passam obrigatoriamente por essa área de memória. Caso as páginas de dados que possuem os dados que você precisa estejam em memória (nesta área de cache), a sua consulta pode ser retornada com sucesso. Sem a necessidade de ler seus arquivos físicos, esse tipo de leitura, em memória, é muito mais rápida, é o que chamamos de leitura lógica ou logical read.

Caso os dados que você está buscando não estejam no Buffer Pool, o Storage Engine é responsável por iniciar e gerenciar a leitura em disco, nos arquivos de dados, buscando pela informação que você está procurando, obviamente levando em conta o plano de execução, ou o mapa, por assim dizer, que foi passado para ele pela Engine Relacional. Nesse momento, após o IO em disco ser efetuado, o Storage Engine armazena as páginas lidas no Buffer Pool para que possa otimizar as próximas leituras que solicitarem as mesmas páginas.

Nós chamamos esse processo de leitura em disco de Leitura Física dos dados, já que o SQL precisou realizar IO em disco para efetivamente encontrar os seus dados.

Uma vez os dados em memória, ou seja, nessa área de Cache, o Buffer Pool, o SQL Server não precisa mais realizar uma leitura Fïsical e, nesse caso, ele realiza, apenas, a Leitura Lógica, já mencionada

LAZY WRITER

Obviamente, o Buffer Pool, ou essa área de memória que comporta as páginas dos seus bancos de dados é limitada. Vamos imaginar que essa área de memória em um determinado servidor tenha a capacidade de armazenar 4GB e você já está utilizando efetivamente um total de 3.8GB. O que aconteceria se uma nova leitura de 400Mb ocorresse?

Nesse caso, o SQLOS, o sistema operacional do SQL Server, através de um dos seus componentes internos, chamado Resource Monitor, veria que uma pressão interna de memória está ocorrendo, afinal, 200Mb não são suficientes para acomodar os 400Mb. Ele então enviaria uma notificação para que esse pequeno problema de memória no Buffer Pool seja tratado por um agente de gerenciamento de recurso, ou uma tarefa interna. Esse “agente” ou tarefa interna, responsável por gerenciar a memória do Buffer Pool é chamado de Lazy Writer. O Lazy Write então acordaria, e limparia do cache páginas sujas, ou seja, páginas que já foram modificadas e já estão salvas em disco, nos seus arquivos de dados.

Essa tarefa é um pouco diferente do CHECKPOINT.

O CHECKPOINT é uma tarefa responsável por escrever páginas que foram modificadas no Buffer Pool para os arquivos de dados, porém o CHECKPOINT não necessariamente remove essas páginas dessa área de cache, ou seja, a quantidade de dados em memória não diminui após a execução de um CHECKPOINT. Vamos falar um pouco mais sobre CHECKPOINT quando detalharmos o processo de escrita.

Já o Lazy Writer é responsável pela limpeza dessa área de cache, utilizando um algoritimo chamado LRU2 (Least Recently Used), ou seja, as páginas mais antigas, ou as que foram utilizadas menos recentemente, são marcadas como disponíveis para serem reutilizadas por outras alocações.

No meu exemplo então, apesar de eu já ter 200Mb disponíveis, outros 200Mb serão disponibilizados em forma de páginas marcadas como disponíveis, já que elas foram limpas do meu Buffer Pool pelo Lazy Writer.

Essas páginas deixam de existir em memória, porém ainda estão em disco, uma vez que o SQL deve garantir a persistência dos dados.

Se uma nova leitura é realizada e busca por dados que estão nessas páginas que acabaram de ser removidas do Buffer Pool, ele não executa apenas leituras lógicas, como faria anteriormente quando minhas páginas ainda existiam em memória, mas também leitura física nos arquivos de dados em que essas páginas se encontram.
 

CONCLUSÃO

Nesse primeiro vídeo vou falar um pouco mais sobre um dos componentes do SQL Server: O Storage Engine. Este componente possui muitos outros aspectos a serem analisados.
No próximo vídeo vou analisar um pouco mais a fundo o processo de escrita e como o Storage Engine desempenha um papel importante para garantir a consistência e durabilidade dos dados.

Nessa oportunidade falei sobre um tema muito interessante, porém pouco falado em eventos e até mesmo em posts técnicos: A Distribuição de dados no SQL Server.

Se você tem interesse em entender como isso funciona na prática, convido você a assistir esse webcast no link: https://www.youtube.com/watch?v=XXbVLzfKwsQ

Lá, inclusive, você pode ver uma DEMO que cobre alguns pontos que vou destacar neste post.

Vou tentar resumir um pouco o que falei nessa ocasião.

Como todos os profissionais que trabalham com o SQL Server e outros bancos de dados relacionais sabem, uma das responsabilidades do sistema gerenciador de banco de dados (SGDB) é manter e gerenciar os dados em memória. Porém, apesar desses dados serem utilizados em memória, os mesmos devem persistir em disco, o que garante alguns dos atributos que todos os bancos de dados relacionais devem respeitar, entre eles a Durabilidade. O SQL Server basicamente usa dois tipos de arquivo para este propósito, o arquivo de Transaction Log, que possui a extensão .ldf, e o arquivos de dados, que possuem a extensão .mdf, para o arquivo primário, e .ndf para os arquivos que foram criados posteriormente, ou seja, os arquivos secundários. Nesse primeiro momento não vou me atentar ao arquivo de log, já que ele possui uma estrutura bem diferente dos arquivos de dados e é utilizado para outros propósitos, como a recoverabilidade dos dados em caso de falhas e por algumas features. Vamos focar aqui nos arquivos de dados, os .mdf e .ndf.

No SQL Server, algo que faz parte da arquitetura de arquivos é o que chamamos de Filegroup (FG), ou Grupo de arquivos. Ele basicamente é utilizado para agrupar os arquivos de forma "lógica". Do ponto de vista físico não há nenhuma mudança, porém o Filegroup é utilizado para alocação dos dados e administração dos arquivos.

Quando criamos um objeto, por exemplo uma tabela, não podemos simplesmente especificar em qual arquivo físico (.mdf ou .ndf) esta tabela será armazenada, porém podemos definir em qual Filegroup ela residirá, no momento da criação da mesma, como você pode ver na imagem abaixo. Uma vez em determinado Filegroup esta tabela poderia alocar dados em qualquer dos arquivos que fazem parte deste mesmo FG.

Se você trabalha com SQL Server, você já percebeu que um Filegroup é automaticamente gerado durante a criação de um banco de dados. Este é o Filegroup primário e o arquivo de dados primário (.mdf) é o único arquivo pertencente a este FG inicialmente. Neste arquivo até então não há dados de usuário e é por isso que muitos DBAs, como uma boa prática, as vezes criam um novo filegroup e novos arquivos de dados alocados neste novo FG para a alocação de dados de usuário. Dessa forma seu FG primário estaria sendo utilizado apenas para armazenar dados de sistema. 

Infelizmente não tive tempo de explicar, durante o webcast, como a alocação de dados funciona de forma detalhada, e na verdade pretendo fazer um post específico para falar sobre esse assunto, mas para resumir, podemos dizer que o SQL Server utiliza mapas de alocação para alocar dados, dessa forma o SQL pode encontrar de forma "rápida" quais extents/páginas estão disponíveis para novas alocações e o percentual de espaço disponível nessas páginas. Mas como eu disse, vamos falar sobre GAM, SGAM, PFS e IAM em uma próxima oportunidade.

Cada arquivo de dados possui suas próprias páginas de sistema e mapas de alocação. Por exemplo: O arquivo1.ndf possui mapas de alocação distintos do arquivo2.ndf, se ambos os arquivos pertencem ao mesmo Filegroup o SQL Server pode distribuir os dados do objeto que foi criado neste filegroup entre esses dois arquivos e ter como benefício o fato de ter mais mapas de alocação sendo utilizados paralelamente. Num banco de dados de usuário é muito raro ver problemas de desempenho causados por contenção nessas páginas de sistema, já que a alocação de novos objetos não é tão constante a ponto de causar isso. Por outro lado, um banco de dados que conhecemos muito bem, o tempdb, é utilizado não só quando criamos novos objetos temporários, mas durante outras operações, por isso não é raro casos em que por se ter apenas um arquivo de dados (.mdf) para o tempdb, essa contenção, por causa do acesso frequente a esses mapas de alocação, comece a gerar problemas de performance. Esse é um dos principais motivos para a recomendação de se criar mais arquivos de dados para o banco de dados tempdb, para evitar essa possível contenção dos mapas de alocação. 

Bem, voltando aos bancos de dados de usuário. Vamos usar um objeto como exemplo, para falar um pouco mais sobre a distribuição dos dados. 

Imagine que você criou a Tabela1.

Quando o SQL Server vai fazer alocação de dados nesta tabela, se a mesmo foi criada em um Filegroup em que há mais de um arquivo, os dados podem ser distribuídos entre eles.

Como então o SQL Server decide a quantidade de dados que será alocada em cada arquivo? Aqui entre em cena um algorítmo que é responsável por fazer essa distribuição: O Proportional Fill.

O Proportional Fill é utilizado para que todos os arquivos que pertençam a um mesmo filegroup cheguem ao seu limite, ou seja, termine o seu espaço disponível, "aproximadamente", ao mesmo tempo. É aproximadamente mesmo, porque dependendo da diferença de espaço disponível entre os arquivos, obviamente pode ser que um dos arquivos encha primeiro. A questão aqui é que se a distribuição é Proporcional, isso significa que o SQL Server irá distribuir os dados baseados em alguma métrica. 

Qual é esta métrica? É algo bem simples e lógico, na verdade: O percentual de espaço disponível em cada arquivo.

Para ficar mais fácil de entender, vamos imaginar o seguinte cenário.

Você tem a Tabela1 alocada no Filegroup1. O Filegroup1 possui os arquivos: arquivo1.ndf, arquivo2.ndf, arquivo3.ndf e arquivo4.ndf.

Se os arquivos possuem um percentual diferente de espaço disponível entre eles, a distribuição proporcional irá fazer com que mais dados sejam alocados no arquivo com mais espaço disponível. Obviamente, isso não significa que os outros arquivos não irão "receber" dados, mas eles irão receber proporcionalmente menos alocações.

Aqui está a quantidade de espaço disponível em cada arquivo:

Nesse cenário, o SQL Server faria um cáculo para determinar a proporção em que os dados devem ser distribuídos. Seria algo mais ou menos assim:

A soma do espaço disponível significa 100% do espaço. 
Ou Seja: 100Mb + 200Mb + 50Mb + 400Mb = 750Mb.

750Mb = 100%.

Quanto cada arquivo representa sobre o total de espaço disponível?

Utilizando o arquivo1.ndf como exemplo:

Arquivo1.ndf = 100Mb. 
(100/750)*100 = 13-14%.

Ou seja, o arquivo1.ndf deveria receber em torno de 14% dos novos dados alocados, assim como o Arquivo2.ndf receberia em torno de 26%, Arquivo3.ndf 6% e o Arquivo4.ndf 54%, já que ele é o arquivo com mais espaço disponível.

É claro que esses números começam a sofrer mudanças conforme as alocações forem feitas e, isso diretamente afeta o percentual de dados alocados em cada arquivo. Mas a idéia é que o SQL Server distribua os dados de forma proporcional para garantir aquilo que mencionei no início da explicação sobre o Proportional Fill: Que todos os arquivos cheguem ao seu fim, “aproximadamente” ao mesmo tempo.

Agora que você entendeu como funciona o Proportional Fill, a pergunta é: Há vantagens em se ter alocações distribuídas entre diversos arquivo? Sem dúvida, primeiramente estamos otimizando a utilização dos arquivos do ponto de vista de espaço disponível e, apesar de esses dados serem proporcionalmente distribuídos, eu estaria quebrando as alocações entre diversos arquivos. Se cada um deles estiver em um disco diferente, isso poderia até gerar uma certa medida de performance. 

Ótimo! Mas você não concorda que se eu conseguir fazer uma distribuição mais equitativa, ou seja, uma distribuição por igual entre os arquivos, eu não teria um desempenho ainda melhor? 
Bem, se todos os arquivos estiverem no mesmo disco, pra ser sincero, tanto faz, já que estaria compartilhando spindles ou seja, a mesma capacidade/velocidade de leitura/escrita do disco entre todos os arquivos. E lembre-se, apesar de eu ter mais mapas de alocação que podem ser utilizados em paralelo, bancos de usuário raramente apresentam problemas de contenção nessas páginas.

Agora, imagine cada um desses arquivos em um disco separado, ou melhor, o que realmente importa, eu tenha spindles diferentes pra cada arquivo. Sem dúvida os ganhos de desempenho poderiam ser bem interessantes.
Qual então seria a resposta para garantir uma distribuição equitativa?

Eu sei o que você pensou e, está correto! Garantir que todos os arquivos de dados deste filegroup possuam o mesmo percentual de espaço disponível.

Para isso eu preciso, primeiro, durante a criação do banco de dados, garantir o mesmo tamanho inicial dos meus arquivos de dados. Segundo, que as  configurações de Autogrowth, ou seja, de auto-crescimento, de todos os arquivos pertencentes àquele filegroup sejam idênticas. 

O que? Um PFE falando sobre auto-crescimento? Ok ok, eu sei que você está pensando: “Bem, mas não acho que eu deveria habilitar a opção de autogrowth, já que isso é um processo custoso. O SQL tem que preencher o espaço alocado no disco com zeros (0) e isso poderia afetar minhas transações durante esse período”. Isso é verdade, apesar de podermos otimizar este processo utilizando o instant file initialization que, por exemplo, poderia reduzir o tempo de alocação de “lixo” no espaço alocado em disco, uma boa prática é realizar crescimentos dos seus bancos de dados de forma manual em um horário mais conveniente. Porém, nós sabemos que há empresas que simplesmente não conseguem fazer isso. Se seu footprint, ou seja, a quantidade de ambientes SQL que você  administra é grande, você simplesmente vai optar pelo auto-crescimento e aqui sim minha recomendação é utilizar opções que podem transformar essa tarefa em algo mais otimizado (ou menos custoso), como configurar o crescimento em Mb ao invés de % e ter o Instant File Initialization habilitado (aqui vai mais um assunto pra outro post).

A questão é, garantindo que as configurações de auto-crescimento sejam idênticas entre seus arquivos, nos dá a certeza de que seus arquivos sempre terão o mesmo percentual de espaço disponível entre eles, e isso garante com que a distribuição dos dados para seus objetos sejam equitativa.

No exemplo que eu utilizei anteriormente, se os 4 aquivos possuissem 200Mb de espaço disponível, o SQL Server simplesmente distribuiria 25% do total de dados alocados em cada um dos arquivos. Coloque cada um desses arquivos em um disco diferente, sim, você teria mais desempenho. 

Há apenas um único detalhe a ser destacado com relação autogrowth. O evento de auto-crescimento em si é round-robin. 
Como assim Thiago? Isso mesmo. Se você encheu seus arquivos - aqui um detalhe importante, o auto-grow só ocorre após TODOS os arquivos daquele determinado FIlegroup terem chegado ao seu limite - o evento de auto-crescimento, por padrão, não ocorre simultaneamente em todos os arquivos. O SQL Server "aleatoriamente" escolhe um dos arquivos pertencentes a aquele Filegroup e dispara o evento de auto-crescimento. A partir daí você passa a utilizar apenas um dos arquivos para TODAS as alocações, já que os outros arquivos possuem 0% de espaço disponível. Este arquivo que cresceu chegou ao seu limite? O SQL Server dispara o auto-crescimento para o próximo arquivo, e assim por diante, até que todos os arquivos já tenham crescido e aí, esse ciclo se repete. Isso não é um problema, este é um comportamente esperado e é assim que o algoritmo funciona.

Ou seja, baseado no que vimos até agora,  você pode até tirar algumas vantagens em se ter uma distribuição equitativa entre vários arquivos, porém, quando TODOS os arquivos  de um determinado Filegroup chegam ao seu limite, por causa do evento de auto-crescimento utilizar um algoritmo round-robin, você pode simplesmente deixar de ver esse comportamento de distribuição das alocações em vários arquivos.

É claro que cada caso é um caso, talvez no seu cenário você nem queira fazer uso do Proportional Fill para distribuir seus dados entre diversos arquivos. Mas, vamos dizer que você queira. Nesse caso há uma forma de garantir que o evento de auto-crescimento ocorra simultaneamente em todos os arquivos, o que, consequentemente, garantiria que você continue a usar o Proportional Fill e, em um ambiente em que os arquivos possuam o mesmo percentual de espaço disponível e configurações de autogrowth idênticas, uma distribuição de dados mais equitativa entre os arquivos deste Filegroup.

Aqui entra em cena a Trace Flag 1117. Eu costumo dizer que Trace Flags são como Cheat Codes. Se você quer mudar algum comportamento padrão do SQL, você pode fazer uso delas, porém fica aqui um ponto de atenção: Todas elas devem ser cuidadosamente avaliadas antes de serem habilitadas.
Essa Trace Flag, ou TF, é bem interessante por sinal. Para o banco de dados Tempdb, ela é praticamente “mandatória”, afinal para eu garantir que não vou ter aqueles problemas de contenção nos mapas de alocação eu preciso garantir que todos os arquivos de dados do tempdb estejam sendo usados, e isso só é possível se todos tiverem espaço disponível. Esse é um dos motivos que levaram a Microsoft a transformar a TF1117 para o banco de dados tempdb em um comportamento padrão, a partir da versão 2016, ou seja, você não precisa habilitar essa TF por causa do tempdb, apenas se você quiser ter o mesmo comportamente para bancos de usuário, que é exatamente o que estamos falando aqui.

Habilitando essa TF, toda vez que o evento de auto-crescimento ocorre ele expande todos os arquivos de um determinado filegroup, simultaneamente.
Como todo TF, ou a maioria, varia muito a aplicabilidade em bancos de usuário. O TF 1117 é um deles.

Então resumindo essa parte: nós temos este algoritmo, que falamos aqui, o Proportional Fill, que é utilizado para garantir que todos os arquivos de um determinado FG cheguem ao seu limite "aproximadamente" ao mesmo tempo (FULL). A questão é, chegamos no limite de TODOS os arquivos, a distribuição dos dados deixa de ser proporcional e passa a utilizar apenas um dos arquivos, já que o event auto-grow é RR (round-robin), como eu já mencionei.

Mais uma vez, do ponto de vista de desempenho, distribuir os dados entre diversos arquivos que estão no mesmo disco, não faria muita diferença. A contenção de mapas de alocação em banco de dados de usuário é rara, por isso, a questão aqui são os benefícios de se compartilhar spindles, ou seja, a capacidade de IO dos discos, considerando que você possa alocar cada um desses arquivos em um discos distinto.

Habilitar essa TF e utilizar o Proportional Fill se aplica ao meu cenário?

Talvez.

Lembre-se de que temos funcionalidades muito bacanas que podem te ajudar do ponto de vista de performance e também distribuir os dados entre diversos arquivos e discos, como as Tabelas Particionadas, que inclusive fazem uso dos Filegroups para fazer isso acontecer. Contudo, em cenários que você simplesmente não pode utilizar determinadas soluções como essa, abusar do Proportional FIll não seria nenhum pecado.

Apenas para citar um exemplo de aplicabilidade. Eu visitei um cliente aqui nos EUA onde um determinado ambiente  tinha apenas um FG com diversos (muitos mesmo) arquivos de dados, distribuídos entre vários discos, e o banco já possuia aproximadamente 20TB de dados. Infelizmente neste cenário havia alguns problemas de design e acredito que 80% das minhas recomendações foram nesse sentido. Mas a dúvida do cliente era: Como eu posso distribuir melhor meus dados entre esses vários arquivos? Como garantir uma distribuição mais equitativa entre eles?

Infelizmente não teria como eu simplesmente fazer um DROP e CREATE de todas as tabelas. A menos que você opte por utilizar Tabelas Particionadas, o que não foi o caso desse cliente, seria impossível redistribuir esses dados. Porém os índices poderiam ser redistribuídos, afinal o REBUILD iria movimentar minhas páginas de índices de qualquer jeito, e aí dependendo de quanto espaço eu tenho disponível em cada arquivo, o SQL Server poderia redistribuir esses dados. E foi assim que fizemos a redistribuição dos dados entre os arquivos, para que pudessemos garantir um % de espaço disponível mais parecido entre os arquivos e utilizar uma distribuição mais equitativa no caso de novas alocações.

Não foi fácil, mas a idéia nesse caso foi brincar com o Proportional Fill. Aumentando o % de espaço disponível nos arquivos (alterando o tamanho inicial deles) que ele queria que mais dados fossem alocados. Após alguns Rebuilds nos índices isso ocorreu. Para as tabelas Heap, simplesmente criamos um índice clustered para fazer a mágica. Se ele resolveu o problem de design dele? Não. Mas o algoritmo Proportional Fill ajudou a resolver algo que para este cliente era um problema. Hoje ele tem um ambiente mais previsível e reportou um maior desempenho, inclusive, já que ele tem uma distribuição de dados equitativa entre vários arquivos que estão em discos distintos.

Deixando um pouco de lado o Proportional Fill e falando novamente do TF 1117. A grande questão é realmente o que você espera do seu ambiente.

Não vou aqui advogar a favor ou contra utilizar essa TF.
A questão  é: Você quer manter as distribuições entre mais de um arquivo de um determinado FG, habilite, simples assim. Ok, não é legal manter o auto-grow automático. Concordo plenamente, apesar de eu ter mencionado uma forma mais "suave" de se fazer (Instant File Initialization + crescimento em MB). Mas garanto uma coisa, há sim índicios claros de aumento de desempenho nas alocação dos dados em ambientes que possuem um cenário de distribuição por igual entre diversos arquivos, desde que pertencentes a um mesmo FG e, mais uma vez, desde que os spindles, ou seja, a capacidade de leitura e escrita dos discos sejam distintas, já que diferente do tempdb, não necessariamente temos um grande benefício em ter vários arquivos simplesmente focando na redução da contenção de mapas de alocação/PFS em bancos de usuário.

Dica final e um disclaimer sobre meu post:

Nunca mude configurações como essa sem antes testar e garantir que isso é o melhor para seu ambiente produtivo.

No final do post você econtra um link para alguns scripts que você pode utilizar para testar o Proportional FIll. O primeiro arquivo é uma demonstração de como seria a distribuição proporcional, quando temos arquivos com % de espaço disponível diferentes entre eles. O segundo mostra como, garantindo o mesmo espaço disponível, faz com que o SQL Server mantenha uma distribuição equitativa. Veja também como ocorre o evento de auto-crescimento, antes e após habilitar o TF1117. Se preferir ver a DEMO, ao invés de você mesmo testar, no webcast que citei no início do artigo eu utilizo esses scripts para a minha demonstração.

Boa sorte na administração dos seus dados!

Thiago Caserta.
 
 

LINK PARA DOWNLOAD DOS SCRIPTS: http://1drv.ms/1LzoOUR

SELECT Coluna1, Coluna2, Coluna3 FROM Tabela WHERE Coluna1 = 'A'

Aqui o SQL compilaria e guardaria no cache o plano de execução utilizado para encontrar registros onde o valor = A.

Query 2

SELECT Coluna1, Coluna1, Coluna1 FROM Tabela WHERE Coluna1 = 'B'

Bem, numa execução parametrizada (Uma stored procedure, por exemplo), o SQL Server simplesmente poderia reutilizar o plano da primeira query já que a mudança foi mínima (apenas o valor utilizado no filtro), porém a engine relacional entende como uma nova query, ou seja, durante o processo de otimização da query o Query Optmizer recebe um cache miss, que basicamente indica que não há um plano de execução existente para esta query e ele então é responsável por gerar e armazenar esse novo plano no cache, mesmo sendo praticamente igual ao plano anterior. É claro que se você executar a Query 1 novamente, como já existe um plano que satisfaça essa consulta em cache o SQL Server o reutilizaria.

A questão é, parâmetros podem afetar a efetividade da minha Query? A resposta: Sim, podem!
Imagine que para a a Query 1 existam 10 registros que correspondem ao filtro utilizado (A). Para a Query 2 há 10.000 registros. Nesse caso o plano de execução utilizado para a Query 1 pode ser ineficiente para a Query 2, o que poderia impactar a execução da Query 2 e consequemente degradar a performance da sua aplicação.

Isso é o que chamamos de Parameter Sniffing, muito comum em Stored Procedures. Por que em Stored Procedures? Simplesmente porque a grande diferença (ok! Há outras diferenças, claro) entre executar uma query Ad Hoc ou uma Stored Procedure é que o SQL Server otmiza a execução de Procedures por parametrizá-las, ou seja, reutilizar os planos de execução gerados na primeira execução da Procedure. Não vou falar muito sobre o Parameter Sniffing neste momento, pois o meu foco era pontuar a opção mencionada pelo Jack Li.

Quais opções eu tenho para diminuir o número de compilações? Bem, se você acredita que a grande maioria das suas queries utilizam planos similares para serem executadas, você poderia utilizar a opção que o Jack menciona no seu post, aqui também pode ser uma opção em ambientes os quais você não pode fazer mudanças nas queries em si.
Uma outra opção, que envolve mudança nas queries, seria a de executar suas queries utilizando a system stored procedure sp_executesql. Quando utilizada, você está basicamente forçando a parametrização da query. Por exemplo:

EXECUTE sp_executesql 
 N'SELECT Coluna1, Coluna2, Coluna3 FROM Tabela WHERE Coluna1 = @valor',
 N'@valor varchar(1)',
 @valor = 'A'; 

Nesta execução, se observarmos o plano armazenado em cache seria algo mais ou menos assim: SELECT Coluna1, Coluna2, Coluna3 FROM Tabela WHERE Coluna1 = @valor. Ou seja, não há um valor específico armazenado junto ao plano, o que faz com que a próxima execução, independente do parâmetro utilizado, encontre um plano satisfatório já armazenado em cache.

É claro que há muitos outros detalhes importantes a se avaliar.

Como eu mencionei na nossa discussão interna, há uma pequena linha entre essa opção ser boa ou não para um determinado ambiente, já que um plano pode ser realmente bom para várias queries e aí reduzir o número de compilações e consequentemente o tempo de CPU (e memória consumida) ou impactar várias das queries porque cada uma gosta de um plano específico.
 
O que eu realmente gostei do post do Jack Li foi o que ele mencionou no final: If things don’t work out, it’s easy to back it out. Over the course of troubleshooting performance issues, I have used this trick many times.

Muitas vezes a gente fica pensando, será que eu altero ou não?
Há coisas que só "testando" pra saber. A dica que eu dou é, investigue se a quantidade de queries Ad Hoc sendo executadas no seu ambiente está impactando o seu ambiente (alto consumo de CPU e/ou memória por elas é uma boa indicação + Avalie a quantidade de compilações por segundo).
Esses dois inputs geralmente vão determinar se mudanças como essas devem ser feitas ou não, Tenha sempre em mente que Procedures são preferíevis do que Ad Hoc - Best Practice.

Há outros aspectos que quero ir considerando nos meus posts futuros relacionados a performance, mas como eu disse, esse era pra ser um post rápido.   :)

Lembre-se performance é uma ciência "relativamente" exata, porém pode ser bem tricky, e varia consideravelmente dependendo do comportamente das suas aplicações.
 
Até o próximo post.

Um abraço,
Thiago Caserta,

Pra participar não precisa de inscrição, basta acessar o link do hangout no Youtube no dia e horário do evento: https://www.youtube.com/watch?v=XXbVLzfKwsQ

Descrição:
O SQL Server é um produto fascinante e relativamente complexo, principalmente quando avaliamos aspectos internos da plataforma de dados da Microsoft. Você já se perguntou como funciona a distribuição de dados no SQL Server quando você possui mais de um arquivo de dados (.mdf, .ndf) para o mesmo banco de dados? Talvez você tenha bem claro o conceito de arquivos, páginas e objetos, mas o que dizer sobre a distribuição de dados? Infelizmente não seria possível cobrir aspectos tão profundos como a alocação de registros em si (GAMs, SGAMs, IAM, PFS) mas espero falar disso numa próxima sessão. O que esperar desse webcast então? Uma visão geral sobre arquivos e páginas e como você pode otimizar as alocações de dados utilizando vários arquivos. Também vamos cobrir o papel do File Group em um banco de dados SQL Server. Vamos mostrar como funciona a distribuição de dados em vários arquivos e como um algorítimo chamado Proportional Fill pode ajudar, ou não, a aumentar a performance das suas alocações de dados e, consequentemente, suas aplicações.

Data: Dia 22 de Setembro de 2015 21:00 - Horário de Brasília

Local: Google Hangout - https://www.youtube.com/watch?v=XXbVLzfKwsQ

Palestrante: Thiago Caserta

Vejo você lá!

Thiago Caserta.

Bem, vamos tentar explicar o porque isso acontece.
Por padrão, quando um Availability Group Listener é criado, há uma opção chamada RegisterAllProvidersIP que é configurada com o valor 1 (True). Esta configuração é associada ao recurso Network Name (vinculado ao Listener) no Failover Cluster Manager. Isso significa que os endereços IP de ambas as localidades (Subnet 1 e 2) irão ser adicionados ao registro DNS do cliente (DNS A-record). Quando o cliente tenta acessar o Availability Group através do Listener ele, arbitrariamente ou ramdomicamente (se existisse essa palavra, hehe), tenta conectar a um dos dois endereços IP associados. Numa lógica rápida então, poderíamos dizer que aproximadamente 50% de todas os acessos irão receber erros de timeout e, por isso que você percebe que algumas conexões ocorrem com sucesso. A solução mais elegante e a que eu recomendo é a de utilizar um paramêtro adicional na string de conexão das suas aplicações. Este parâmetro se chama MultiSubnetFailover.
Explicando de forma simples, quando o cliente tenta acessar o AG através do Listener, com a opção MultiSubnetFailover ao invés de acessar um IP de forma arbitrário, o cliente realiza acesso simultaneo aos IP associados ao AG Listener (dependendo da forma que a conexão é feita ele pode simplesmente forçar o retry da conexão a ocorrer de forma mais rápida). O IP que responder é o que o cliente/aplicação irá utilizar. Esta é uma forma de acesso mais precisa e na minha conclusão irei dar mais alguns detalhes do porque esta opção é preferível comparada a uma outra opção disponível que irei comentar a seguir.
Ah! Mais um detalhe, para aplicações que fazem usam de drivers ao invés de conexões diretas através de string de conexão, o driver SQL Native Client, a partir da versão 11, suporta esta opção (MultiSubnetCluster)

RegisterAllProvidersIP + HostRecordTTL

Infelizmente, Há aplicações que não suportam a opção MultiSubnetFailover, por diversos motivos (uma aplicação legacy ou é aquela famosa caixinha fechada a qual a empresa que desenvolveu não existe mais ou não é favorável a fazer mudanças). Nesse caso você pode recorrer a mudanças nos parâmetros RegisterAllProvidersIP e HostRecordTTL.

Mudando a configuração RegisterAllProvidersIP para 0, o único IP que estiver Online será o IP registrado junto ao DNS do cliente. Há apenas uma consideração aqui que nos leva a falar do próximo parâmetro a ser alterado, o HostRecordTTL. Quando um failover ocorre entre instâncias de diferentes Subnets, as configurações de DNS podem impactar diretamente a conectividade das aplicações. Há uma propriedade relacionada ao DNS conhecida como TTL ou Time to Live, de forma simples podemos dizer que ela é responsável por dizer de quanto em quanto tempo o registro DNS de cada cliente será atualizado. Se o Listener mudar o endereço IP em que ele está respondendo (no caso de um Failover do AG entre Subnets distintas) isso não afeta diretamente na atualização do registro DNS do cliente, o que pode fazer com que ele ainda tente acessar o Availability Group utilizando o endereço TCP IP anterior (o IP utilizado na Subnet 1, por exemplo). Quando a replicação dos registros DNS ocorre para a máquina do cliente então, todos os registros são atualizados e seus clientes poderão utilizar o endereço IP correto (utilizado na Subnet 2).
Por padrão, essa atualização/replicação ocorre a cada 20 minutos, o que significa que você poderia ficar aguardando até 20 minutos para ser possível conectar com sucesso ao AG utilizando o Listener's Name. Para que essa replicação ocorra num tempo menor, é possível reduzir o parâmetro TTL, forçando essa atualização a ocorrer de forma mais frequente. Se você pesquisar em algumas documentações da Microsoft é recomendável diminuir esse parâmetro para, no mínimo, 5 minutos (ou 300 segundos - a configuração é em segundos), mas segundo a minha experiência e de acordo com a sua necessidade de negócios da sua empresa, você pode alterar até para um valor menor, talvez algo entre 2 e 3 minutos (120-180 segundos). Claro que quanto menor o valor para a configuração HostRecordTTL existe um leve aumento no tráfego da sua rede, devido a requisição constante de registros DNS.

Lembrando que essas configurações de HostRecordTTL e RegisterAllProvidersIP são feitas diretamente no recurso do Listener no Failover Cluster Manager, não no Active Directory ou no DNS, apesar de estarem relacionados. O time de AlwaysOn da Microsoft tem um artigo bem bacana sobre essas opções, incluindo um script Powershell que pode te ajudar a mudar essas configurações de forma mais simples e rápida.

http://blogs.msdn.com/b/alwaysonpro/archive/2014/06/03/connection-timeouts-in-multi-subnet-availability-group.aspx

Conclusão

Apesar de a opção de mudar os parâmetros RegisterAllProvidersIP e HostRecordTTL ser uma solução interessante para clientes que não possuem suporte a opção MultiSubnetFailover, o parâmetro MultiSubnetFailover é, sem dúvida, a melhor forma de acessar seu AG em um cluster Multi-Subnet através do Listener. Além de ser mais preciso, pois quando o cliente tenta acessar o AG através do Listener não irá acessar obrigatóriamente um IP aleatório, podemos evitar erros de timeout causados pela latência na replicação dos registros DNS devido as propriedades de TTL.

Espero poder trazer mais dicas e explicações focadas em Alta Disponibilidade em breve.

Até lá!

Um abraço,
Thiago Caserta.

• Tal erro persistia mesmo com a opção SET QUOTED_IDENTIFIER ON sendo definida no nível da sessão;
• A mensagem ocorre apenas quando o banco de dados está em Compatibility Level 100. Quando o banco de dados é reconfigurado para Compatibility Level 90 (SQL 2005) a procedure era executada com sucesso.

A feature filestream é requerida para utilização de tabelas persistentes com o In-Memory OLTP (durable tables)?
O Hekaton - não sei porque, mas ainda gosto de usar o code-name da feature :) - usa a tecnologia Filestream apenas por trás dos bastidores, não estamos aqui falando de um FILESTREAM filegroup, pois a feature utiliza o “Memory Optimized Data” (MOD) filegroup.  Você não precisa habilitar a feature FILESTREAM, e sim apenas adicionar um Memory-Optimized Data filegroup.

Falando sobre InMemory Databases, seria uma boa prática dedicar um disco específico para Filestream?
O armazenamento dos MOD filegroup é apenas crítico durante a inicialização do SQL Server (quando o banco de dados está sendo levado para o estado online). Neste momento, precisamos ler todas as informações daquele filegroup, com o objetivo de carregar todos os dados para memória.  Logo, dependendo de quão rápido você precisa que seja esta inicialização, você pode colocar num disco compartilhado, num disco dedicado, ou até mesmo em diversos discos (adicionando múltiplos containers) com o objetivo de paralelizar a leitura das informações dos containers. Discos SSD com toda certeza também seria de grande vantagem para que este processo ocorra de forma mais rápida.

A escrita nos containers (Schema_And_Data) é feita de forma râmdomica ou sequencial?
A escrita nos arquivos de checkpoint dos MOD filegroups devem ser estritamente sequencial. Desta maneira é possível fazer um melhor uso de IO de discos. Contudo, em algumas operações, veremos um pequeno percentual de escrita ramdomica causadas por escritas nos Delta files, mas podemos considerar esse percentual mínimo.

Em um cenário de Disaster Recovery com replicacao de storage, devo replicar meus discos Filestream?
Já que os Memory Optimized Data filegroups contém os dados "persistentes" de qualquer durable table, caso você não replique estes discos, os dados não estarão disponíveis no site remoto, e seus bancos de dados possivelmente não ficarão online. Até a versão CTP1 (Community Technical Preview) do SQL 2014 o AlwaysOn Availability Group não estava homologado para trabalhar com objetos In-Memory, porém a partir da versão RTM, com o AlwaysOn AG seria possível fazer a replicação destes dados utilizando uma tecnologia nativa do próprio SQL Server.

Um abraço,