Fim do Suporte SQL Server 2008. Você está preparado?

Então 2018 já acabou, e já passamos o carnaval, então de fato o ano começou, e você sabe o que vai acontecer em Julho?

R: Não?

Então leia o post… rsrsrsrs =D

O suporte da família SQL Server 2008 e SQL Server 2008 R2 será encerrado em Julho de 2019.

O que significa o fim do suporte do produto?

O suporte oficial do SQL Server 2008 e SQL Server 2008 R2, foi encerrado em 2014, quando a Microsoft parou de disponibilizar novas atualizações de segurança e correção de bugs, a partir desta data foi disponibilizado apenas o suporte estendido.

Para conhecer mais sobre o suporte básico e suporte estendido basta acessar esse link.

Como podemos ver na tabela abaixo, a última atualização liberada para o SQL Server 2008 foi em 06/01/2018.

Então e agora o que devo fazer?

Bom, OU você vai aceitar o risco de ficar desprotegido e sem suporte da Microsoft, OU vai migrar o seu SQL Server.

Ok… entendi os riscos, mas como convencer o meu gestor a aprovar a migração do SQL Server?

Bom, pelo simples fato da questão da segurança já seria suficiente para ele se convencer, mas se ainda for necessário mais argumentos, podemos colocar a inovação tecnológica, como por exemplo, a partir do SQL Server 2012 foi implementado o AlwaysOn, que é uma nova feature de High Availability, também foram lançados os índices columnstore, que ajudam na otimização de consultas e espaço em disco. Além disso, a partir do Service Pack 3 foi disponibilizado a possibilidade de ser fazer backup do banco de dados direto para uma URL (nuvem).

No SQL Server 2014, o otimizador de consultas foi melhorado. Também foi introduzido o In-memory que é um armazenamento de dados em memória, além de melhorias no AlwaysOn.

No SQL Server 2016, vieram a maioria das inovações tecnológicas do produto, novas features como o Query Store, Strech Database, suporte a JSon, entre outros.

Novas features de segurança como Always Encrypted, Row Level Security e Dynamic Data Masking.

Além de todas as novas features, também tivemos algumas melhorias no AlwaysOn, nos índices columnstore, entre outras.

Além de todas as features novas e melhorias, a partir do Service Pack 1 (SP1), muitas das features que antes eram liberadas somente para a edição Enterprise do SQL Server, foram disponibilizadas para todas as versões do SQL Server (Standard, Web e Express). Por exemplo, a possibilidade de compactar os dados, essa feature era restrita somente para a edição Enterprise. Em alguns casos, as bases de dados chegam a ser reduzidas em até 1/3. Empresas que utilizam o Protheus vibram quando pegamos bases de 600 GB, compactamos e o seu tamanho é reduzido para 200 GB!!! WOW!!!! Já vão economizar espaço em disco por um bom tempo!

Por fim, temos o SQL Server 2017 que foi a maior inovação tecnológica de todos os tempos, pois o SQL Server passou a ser compatível com o Linux! Isso mesmo, Microsoft e Linux juntos!

Ok… mas como posso realizar a migração?

Como os bancos que estão no SQL Server 2008 já podem ter sido migrados de outras versões mais antigas do SQL Server, podemos ter alguns problemas de compatibilidade, mas a Microsoft nos ajuda a realizar algumas validações, através de uma ferramenta chamada Data Migration Assistant (DMA). Essa ferramenta é FREE e está disponível para download nesse link.

O que essa ferramenta faz é varrer todos os objetos das databases e validar se tem alguma feature ou comando que não são mais suportados.

Como utilizar o DMA?

Neste post vou utilizar uma VM com o SQL Server 2008 R2 com uma base de teste da StackOverFlow.

No DMA, vamos selecionar “New Project” -> “Assessment”

Agora precisamos dar um nome ao nosso projeto e selecionar o destino que vamos migrar o banco de dados, se é para o Azure ou para um SQL Server On-Premisses.

Neste primeiro momento, vamos selecionar outro SQL Server.

No próximo passo, vamos selecionar para qual versão vamos migrar o SQL Server, se é para o SQL Server 2012, 2014, 2016 ou 2017. Neste post, vamos realizar a migração para o SQL Server 2017 on Windows.

Também vamos selecionar se queremos que o DMA gere apenas o report de compatibilidade ou também de novas features que podemos utilizar na base de dados.

Agora precisamos informar em qual instância vamos realizar a validação. Devemos informar o nome do servidor e instância. Caso seja a instância default, basta apenas colocar o nome do servidor e também as credenciais. Lembrando que será necessário um usuário que tenha permissão de VIEW SERVER STATE e VIEW ANY DEFINITION.

Após o DMA conectar na instância, podemos escolher quais bases vamos efetuar as validações. No nosso caso, vamos validar somente a base StackOverflow.

Agora estamos prontos para executar a validação.

Como podemos observar, a ferramenta gerou um report com as informações que precisamos ficar atentos. Neste caso específico não temos nenhum alerta de “Breaking changes”, que são aqueles que seriam os problemas que “impedem” uma migração.

No report que foi gerado, na base Stackoverflow temos apenas alertas de tipo de dados que estão marcados como “deprecated”. Isso não impede de realizar a migração, mas em uma edição futura do SQL Server isso pode ser impeditivo. Como podemos observar, ele até nos indica onde está o problema.

Agora vamos validar se o DMA nos indicou alguma feature que podemos utilizar.

O DMA nos recomendou 2 features de segurança: a utilização do “Always Encrypted”, que está disponível desde o SQL Server 2016, se você quiser saber mais dessa feature veja o post “SQL Server 2016 – Always Encrypted”, com a nova Lei Geral de Proteção de Dados, essa é uma feature muito interessante. E também sugeriu a utilização do TDE.

Na sessão de “Storage”, o DMA identificou dados que podem ser migrados para um “Strech Database”, que é você mandar os dados antigos para o Azure, deixando apenas os dados recentes no seu servidor local, se você quiser conhecer mais sobre o “Strech Database”, o Dirceu Resende tem um excelente artigo sobre “SQL Server 2016 – Como arquivar tabelas históricas no Azure com o Stretch Database”.

Como podemos ver o DMA, nos auxilia retornando uma grande quantidade de informações, para que possamos realizar a nossa migração com segurança.

Bom pessoal, por hoje é isso. No próximo post vou mostrar como podemos realizar a migração do banco de dados para o SQL Server On-premisses utilizando o DMA.

Abraços,

Tiago Neves