Dois Bons Motivos para Migrar para o SQL Server 2014

Olá pessoal, nesta última semana tive a oportunidade de participar juntamente com meu amigo Fabiano Amorim (@mcflyamorim | blog | facebook) da migração de um SQL Server 2012 Cluster para o SQL Server 2014. O ambiente em questão é um cluster com 3 servidores ou nós, 3 instâncias de SQL sendo que duas delas ainda possuem configuradas 1 grupo do AlwaysOn Availabity Group para uma quarta instância, que também foi migrada.

Bom, mas o que realmente interessa aqui é que nossa migração tinha como foco logo após sua conclusão ativar duas novas funcionalidades do SQL Server 2014 que na nossa visão iria prover ótimos resultados para o ambiente, o NEW Cardinality Estimation (CE) e o DELAYED DURABILITY.

NEW Cardinality Estimation (CE)

Bom, não vou entrar no contexto de detalhar o CE aqui, mas colocarei logo abaixo alguns links para caso você queira se aprofundar no assunto. Por hora, o que você precisa saber é que o CE é uma importante parte do Query Optimizer (QO) e que no SQL Server 2014 ele foi significativamente redesenhado/reescrito para melhorar a qualidade dos “query plans” e consequentemente melhorar o desempenho das queries. E pelo que vimos, deu certo 🙂

O novo CE é ativado quando você altera o nível de compatibilidade do banco de dados para 120 (o nivel de compatibilidade do SQL Server 2014). Simples assim! Então, o Fabiano já tinha um belo alvo…um banco de dados que há tempos vinha lhe dando algumas dores de cabeça com algumas queries do LINQ….hummmmm LINQ…faz todo sentido né 🙂

Bom, então logo após a conclusão da migração das instâncias o nível de compatibilidade do banco de dados foi alterado e o resultado foi surpreendente, como mostro nos dois prints abaixo.

ANTES

DEPOIS

Fizemos outros testes depois utilizando o SQL Profiler e as diferenças em logical reads, CPU e Durantion quando se ativava o novo CE eram gritantes. É óbvio que cada caso é um caso, cada ambiente é um ambiente, mas acredito que no geral você terá bons resultados com a utilização do novo CE. Principalmente se você também tiver LINQ 🙂

Alguns link para caso você queira se aprofundar no conhecimento do novo CE:

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

http://blogs.technet.com/b/dataplatforminsider/archive/2014/03/17/the-new-and-improved-cardinality-estimator-in-sql-server-2014.aspx (não deixem de ler esse)

http://michaeljswart.com/2014/05/enabling_the_new_ce/

DELAYED DURABILITY

Outra excelente feature do SQL Server 2014 é o delayed durability! Caso você não saiba, quando uma transação é processada no SQL Server um “transaction log record” para as modificações de dados em questão é gravado no arquivo de LOG do banco de dados ANTES que o SQL Server envie para a aplicação a informação de que a transação foi efetivada com sucesso, o acknowledgement.

Bom, com isso, em ambientes onde se tem um grande volume transacional e a escrita no LOG é um gargalo, por exemplo, pelo uso de um disco de baixa performance, é muito comum a identificação do wait type WRITELOG (normalmente combinado com PAGEIOLATCH_) e também se ter um alto valor para o contador Log flush waits/sec.

Para o ambiente migrado, alguns bancos de dados estavam sofrendo muito com isso e não por acaso o WRITELOG era o TOP1 na lista de TOP waits :). Então, resolvemos ativar o delayed durability para 3 bancos de dados e acompanhar o comportamento.

O delayed durability pode ser ativado no nível de transação, no entanto, a maneira mais simples é ativá-lo no nível de banco de dados executando o comando “ALTER DATABASE dbname SET DELAYED_DURABILITY = FORCED”.

Os resultados também foram surpreendentes…

WRITELOG ANTES:

WRITELOG DEPOIS:

Log Flush waits/sec: a linha Azul mostra o comportamento após a ativação da feature para um dos bancos de dados. Bela redução não? 🙂

Novamente, cada ambiente é um ambiente e não acho que essa seja uma funcionalidade para se sair aplicando de forma “default” no ambiente. Por exemplo, ainda não sei como isso se comportaria em um banco de dados/aplicação que na necessidade de um restore precisa-se restaurar o arquivo de log no momento mais próximo da falha possível (point in time). De qualquer forma, considerando que o problema de escrita em LOG é um problema bastante comum em muitos ambientes, esta é um feature que pode valer muito a pena.

Por fim, tivemos ainda um belo ganho no consumo de CPU 🙂