Sabemos que todos os softwares estão sempre em continua evolução, sejam elas alteração da versão anterior instalada, melhorias de usabilidade, correção de falhas internas, melhora na confiabilidade, brechas de segurança além de novas funcionalidades.
Um Sistema de Gerenciamento de Banco de Dados(SGDB) é um dos sistema de software que mais sofre ataque de pessoas mal intencionadas e nos dias de hoje existem diversos tipos de virus tais como malwares, Ransomware dentre uma lista que a cada dia só faz crescer.
Para manter seu Banco de Dados com o maior nivel de segurança possível é uma prática recomendada aplicar a atualização regular ao SQL Server com o service pack (SP) ou os pacotes cumulativos (CU). Aqui está uma visão geral rápida das atualizações do SQL Server.
• Service Pack: um service pack contém um único pacote de hotfixes e atualizações lançados anteriormente
• Cumulative Update (CU): os pacotes cumulativos (CU) são o hotfix, pequenas melhorias de recursos
• Versão de distribuição geral (GDR): a Microsoft lança a versão GDR, e está especialmente relacionada à segurança do SQL Server
Até o SQL Server 2016, a Microsoft lança service packs regulares e atualizações cumulativas. Por exemplo, nas versões do SQL Server 2016, você vê as seguintes sequências.
• Versão RTM
• Atualizações cumulativas (CU1 a CU9)
• Service Pack 1
• Pacotes cumulativos (CU1 a CU15)
• Service Pack 2
A partir do SQL Server 2017, a Microsoft muda seu modelo de serviço. Ele não fornece mais os service packs. Em vez disso, ele lança os Pacotes Cumulativos a cada 2 meses. Cada CU contém também o pacote cumulativo anterior. Por exemplo, no SQL Server 2019, a Microsoft lançou o mais recente CU7 em setembro de 2020.
Portanto, se você está na versão RTM, você pode aplicar diretamente a CU7 para estar na mais recente versão de compilação.
Um comando muito utilizado para analisar qual versão o seu SQL Server esta seria o:
select @@version
Abaixo segue um exemplo de resultado em um ambiente que ainda não recebeu nenhum tipo de atualização, isto fica claro pelo texto “RTM”.
Microsoft SQL Server 2019 (RTM) – 15.0.2000.5 (X64) Sep 24 2019 13:48:23 Copyright (C) 2019 Microsoft Corporation Enterprise Evaluation Edition (64-bit) on Windows Server 2016 Standard 10.0 <X64> (Build 14393: ) (Hypervisor)
Abaixo Segue o resultado em um ambiente que já teve alguma atualização.
“Microsoft SQL Server 2019 (CTP2.4) – 15.0.1400.75 (X64) Mar 16 2019 11:53:26 Copyright (C) 2019 Microsoft Corporation Enterprise Evaluation Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 17763: )”
Um site que eu sempre recomendo para a pesquisa quais as atualizações estão disponiveis para a sua versão do SQL Server seria o https://sqlserverbuilds.blogspot.com/
Neste site conseguimos ver as atualizações disponiveis sejam ela Service Pack ou Cumulative Update lembrando que SP(Service Pack) somente ate a versão 2016, e ainda temos um link direto para o download do pacote de atualização.
Há uma diferença no processo de patching entre ambientes Single Instance, failover cluster e o Grupo de Alta Disponibilidade (O AlwaysOn Availability Group)
No Grupo de Disponibilidade Always On do SQL Server, usamos várias instâncias do SQL e as chamamos de réplica primária e secundária. Você pode ter uma única réplica primária e várias réplicas secundárias, dependendo da versão do SQL Server.
Neste artigo irei focar na aplicação de patch em um ambiente sem nenhum tipo de recurso de alta disponibilidade.
Podemos dividir o patching SQL Server em três fases.
• Pré trabalho
• Aplicar Patches
• Pós trabalho
Vamos passar por cada fase e entendê-la em detalhes.
1 – Fase Preparatória ou Pré trabalho
Na fase preparatória , precisamos para as seguintes tarefas,
• Determine o nível de patch atual e o nível de patch a ser aplicado. Para o nível de patch de destino, você pode escolher o nível de patch N-1 (N = patch mais recente). No caso de você querer ir com o patch mais recente, sempre procure os blogs do SQL Server para quaisquer problemas conhecidos após aplicar o patch específico
• Você não deve aplicar o patch diretamente ao ambiente de produção. Teste o patch em ambientes de homologação e aguarde as validações dos aplicativos por pelo menos 1 semana e passe para o patch de produção
• Você também deve ler as notas de lançamento do patch. Informações sobre as correções de bugs, melhorias
• Antes de aplicar os patches verifique o seguinte:
◦ Verifique se você possui os backups mais recentes dos bancos de dados do sistema, bem como dos bancos de dados do usuário
É bom fazer backups completos, no entanto se você tiver bancos de dados grandes, você pode fazer um backup diferencial ou o backup do log de transações antes de aplicar os patches.
• Verifique a integridade dos Banco de Dados e consistência atraves do comando (DBCC CHECKDB).
◦ Verifique se os serviços SQL estão online
◦ Validação de versão do SQL Server
◦ Verifique os logs de erro do SQL Server para quaisquer erros.
2 – Aplicação de Patch
3 – Pós Trabalho
• Verifique se você tem a versão atualizada da instância do SQL atraves do comando “select @@version”.em todas as réplicas que participam do grupo de disponibilidade Always On do SQL Server
• Revise os logs de erro
• Peça a sua equipe de aplicação para validar a funcionalidade dos software rodam naquele ambiente.
Conclusão
O patch do SQL Server é uma tarefa essencial para profissionais de banco de dados. Neste artigo, exploramos a aplicação de patches do SQL Server em um ambiente com apenas uma instancia, caso você tenha mais de uma instancia em seu ambiente este processo deve ser executado em cada instancia.
Você deve se lembrar que cada ambiente pode ser diferente dependendo das configurações e dos recursos do SQL Server. Portanto, você deve planejar antes de aplicar qualquer patch para evitar pressa de última hora. Sempre aplique patches nos ambientes de desenvolvimento e teste.
