Certificação de compatibilidade

  • Artigo

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do Azure

A certificação de compatibilidade permite que as empresas atualizem e modernizem um banco de dados SQL Server local, na nuvem e na borda, eliminando os riscos de compatibilidade do aplicativo.

O mesmo Mecanismo de Banco de Dados alimenta o SQL Server e o Banco de Dados SQL do Azure (incluindo a Instância Gerenciada de SQL do Azure). Esse Mecanismo de Banco de Dados compartilhado significa que um banco de dados do usuário pode ser movido diretamente entre SQL Server e Banco de Dados SQL do Azure locais, enquanto o código do aplicativo executado no banco de dados como Transact-SQL continua funcionando como ele faria em seu sistema de origem.

Para cada nova versão de SQL Server, o nível de compatibilidade padrão é definido como a versão do Mecanismo de Banco de Dados. Mas o nível de compatibilidade de versões anteriores é preservado para garantir a compatibilidade contínua dos aplicativos existentes. Essa matriz de compatibilidade pode ser vista aqui. Portanto, um aplicativo que foi certificado para funcionar com uma determinada versão do SQL Server estava, de fato, certificado para funcionar no nível de compatibilidade padrão dessa versão.

Por exemplo, o nível de compatibilidade do banco de dados 130 era o padrão em SQL Server 2016 (13.x). Como os níveis de compatibilidade forçam comportamentos de otimização de consulta e funcionais do Transact-SQL específicos, um banco de dados certificado para trabalhar no SQL Server 2016 (13.x) foi certificado implicitamente no nível de compatibilidade do banco de dados 130. Esse banco de dados pode funcionar no estado em que se encontra em uma versão mais recente de SQL Server (como SQL Server 2019 (15.x)) e Banco de Dados SQL do Azure, desde que o nível de compatibilidade do banco de dados seja mantido como 130.

Esse é um princípio fundamental do modelo de operação de integração contínua do Microsoft Banco de Dados SQL do Azure. O Mecanismo de Banco de Dados é continuamente aprimorado e atualizado no Azure, mas como os bancos de dados existentes mantêm seu nível de compatibilidade atual, eles continuam funcionando conforme projetado após as atualizações no Mecanismo de Banco de Dados subjacente.

Essa também é a maneira como o SharePoint Server 2016 e o SharePoint Server 2019 certificam SQL Server e Instância Gerenciada do Azure SQL, permitindo que você implante qualquer Mecanismo de Banco de Dados do SQL Server que possa usar os níveis de compatibilidade de banco de dados com suporte nessas versões do SharePoint Server. Para obter mais informações, confira Requisitos de hardware e software para o SharePoint Server 2016 e Requisitos de hardware e software para o SharePoint Server 2019.

Gerenciar risco de atualização com a certificação de compatibilidade

Usar a Certificação de Compatibilidade é uma abordagem valiosa à modernização do banco de dados. Ao certificar com base no nível de compatibilidade, os desenvolvedores definem os requisitos técnicos de um aplicativo com suporte no SQL Server e no Banco de Dados SQL do Azure, mas desacoplam o ciclo de vida do aplicativo do ciclo de via da plataforma do banco de dados. Isso permite que as empresas mantenham o Mecanismo de Banco de Dados do SQL Server atualizado conforme necessário pelas políticas de ciclo de vida, usando novos aprimoramentos de escalabilidade e desempenho que não dependem de código, e os aplicativos em conexão mantêm o status funcional por meio de atualizações.

A possibilidade de afetar negativamente a funcionalidade e o desempenho é o principal fator de risco de qualquer atualização. A Certificação de Compatibilidade representa a tranquilidade em termos de gerenciamento destes riscos de atualização:

  • No que se refere ao comportamento do Transact-SQL, qualquer alteração significa que um aplicativo precisa ser recertificado quanto à exatidão. No entanto, a configuração de nível de compatibilidade do banco de dados oferece compatibilidade com versões anteriores do SQL Server apenas para o banco de dados especificado, não para todo o servidor. Manter o nível de compatibilidade do banco de dados no estado em que se encontra faz as consultas de aplicativo existentes continuarem exibindo o mesmo comportamento antes e depois de uma atualização Mecanismo de Banco de Dados. Para saber mais sobre o comportamento Transact-SQL e níveis de compatibilidade, confira Usar níveis de compatibilidade para compatibilidade com versões anteriores.

  • Em relação ao desempenho, como as melhorias no Otimizador de Consulta são introduzidas com cada versão, poderia ser esperado encontrar diferenças de plano de consulta entre diferentes versões do Mecanismo de Banco de Dados. As diferenças de plano de consulta no escopo de uma atualização geralmente representam risco quando há potencial de que algumas alterações possam ser prejudiciais para uma determinada consulta ou carga de trabalho. Por sua vez, esse risco é geralmente uma motivação para a recertificação do aplicativo, que pode atrasar atualizações e gerar desafios de ciclo de vida e de suporte.

    A mitigação de riscos de atualização é o motivo pelo qual os aprimoramentos do Otimizador de Consulta estão restritos ao nível de compatibilidade padrão de uma nova versão (ou seja, o nível de compatibilidade mais alto disponível para qualquer nova versão). A Certificação de Compatibilidade inclui a proteção de formato do plano de consulta: a noção de que manter um nível de compatibilidade do banco de dados no estado em que se encontra imediatamente após uma atualização do Mecanismo de Banco de Dados significa usar na nova versão o mesmo modelo de otimização de consulta que era usado antes da atualização, e que o formato do plano de consulta não deve ser alterado.

    Para obter mais informações, confira a seção Por que usar a forma do plano de consulta? neste artigo.

Para saber mais sobre os níveis de compatibilidade, confira Usar níveis de compatibilidade para compatibilidade com versões anteriores.

Importante

Para um aplicativo existente que já foi certificado para um determinado nível de compatibilidade, atualize o Mecanismo de Banco de Dados do SQL Server e mantenha o nível de compatibilidade do banco de dados anterior. Não é necessário certificar novamente um aplicativo nesse cenário. Para saber mais, confira Níveis de compatibilidade e Atualizações do Mecanismo de Banco de Dados mais adiante neste artigo.

Para um novo trabalho de desenvolvimento ou quando um aplicativo existente exige o uso de novos recursos, como o Processamento de Consulta Inteligente, bem como um novo Transact-SQL, planeje atualizar o nível de compatibilidade do banco de dados para a versão mais recente disponível em SQL Server e certifique novamente o aplicativo para que ele funcione com esse nível de compatibilidade. Para obter mais informações sobre como atualizar o nível de compatibilidade do banco de dados, confira Melhores práticas para atualizar o nível de compatibilidade do banco de dados.

Por que usar a forma do plano de consulta?

Forma do plano de consulta refere-se à representação visual dos vários operadores que compõem um plano de consulta. Isso inclui operadores como buscas, verificações, junções e classificações, bem como as conexões entre eles que indicam o fluxo de dados e a ordem das operações que precisam ser executadas e o conjunto de resultados pretendidos. A forma do plano de consulta é determinada pelo otimizador de consulta.

Para manter o desempenho de consultas previsível durante uma atualização, uma das metas fundamentais é garantir que a mesma forma de plano de consulta seja usada. Isso pode ser feito ao não alterar o nível de compatibilidade do banco de dados imediatamente após uma atualização, mesmo que o Mecanismo de Banco de Dados subjacente tenha versões diferentes. Se nada mais for alterado no ecossistema de execução de consultas, como alterações significativas em recursos disponíveis ou na distribuição de dos dados subjacentes, o desempenho de uma consulta deverá permanecer inalterado.

No entanto, manter o formato de um plano de consulta não é o único fator que pode ter implicações de desempenho após uma atualização. Se mover o banco de dados para um Mecanismo de Banco de Dados mais recente e também fizer alterações ambientais, você poderá estar introduzindo fatores que terão impacto imediato no desempenho de uma consulta, mesmo se o plano de consulta mantiver a mesma forma entre as versões. Essas alterações ambientais podem incluir o novo Mecanismo de Banco de Dados ter mais ou menos recursos de memória e CPU disponíveis, alterações nas opções de configuração do servidor ou do banco de dados ou alterações na distribuição de dados que afetam o modo como um plano de consulta é criado. Por isso, é importante entender que manter o nível de compatibilidade do banco de dados protege contra alterações na forma do plano de consulta, mas não oferece proteção contra outros aspectos ambientais que influenciam o desempenho da consulta, alguns dos quais são alterações iniciadas pelo usuário.

Para obter mais informações, confira o Guia da Arquitetura de Processamento de Consultas.

Benefícios da certificação de compatibilidade

Há vários benefícios imediatos para a certificação do banco de dados como uma abordagem baseada em compatibilidade, em vez de uma abordagem de versão nomeada:

  • Dissociar a certificação do aplicativo da plataforma. Por causa de seu Mecanismo de Banco de Dados, para aplicativos que só precisam executar consultas Transact-SQL, não há necessidade de manter processos de certificação separados para o Azure e o local.
  • Reduza os riscos de atualização porque, durante a modernização da plataforma de banco de dados, os ciclos de atualização da camada de plataforma do banco de dados e do aplicativo podem ser separados para que haja menos interrupções e melhor gerenciamento de alterações.
  • Atualizar sem alterações no código. A atualização para uma nova versão de SQL Server ou de Banco de Dados SQL do Azure pode ser feita sem alterações no código por meio da manutenção do mesmo nível de compatibilidade que o sistema de origem e sem a necessidade imediata de recerificação até o momento em que o aplicativo precisa usar os aprimoramentos que só estão disponíveis em um nível de compatibilidade do banco de dados mais alto.
  • Aprimore a capacidade de gerenciamento e a escalabilidade sem exigir alterações no aplicativo, usando aprimoramentos que não estão restringidos pelo nível de compatibilidade do banco de dados. No SQL Server, eles incluem, por exemplo:

Novos bancos de dados ainda são definidos como o nível de compatibilidade padrão da versão Mecanismo de Banco de Dados. Mas, quando um banco de dados é restaurado ou anexado de qualquer versão anterior de SQL Server para uma nova versão de SQL Server ou Banco de Dados SQL do Azure, o banco de dados mantém seu nível de compatibilidade existente.

Importante

Antes de mover um banco de dados para uma nova versão de SQL Server ou Banco de Dados SQL do Azure, verifique se ainda há suporte para o nível de compatibilidade do banco de dados. A matriz de suporte do nível de compatibilidade do banco de dados pode ser vista aqui.

A atualização de um banco de dados com um nível de compatibilidade menor do que o permitido (por exemplo, 90 que era o padrão em SQL Server 2005 (9.x)), define o banco de dados como o menor nível de compatibilidade permitido (100).

Para determinar o nível de compatibilidade atual, consulte a coluna compatibility_level de sys.databases.

Níveis de compatibilidade e atualizações do mecanismo de banco de dados

Para atualizar o Mecanismo de Banco de Dados para a versão mais recente, mantendo o nível de compatibilidade do banco de dados que existia antes da atualização e o status de capacidade de suporte, é recomendável executar a validação de área de superfície funcional estática do código do aplicativo no banco de dados (objetos de capacidade de programação como procedimentos armazenados, funções, gatilhos e outros) e no aplicativo (usando um rastreamento de carga de trabalho que captura o código dinâmico enviado pelo aplicativo).

Isso pode ser feito facilmente usando a ferramenta DMA (Assistente de Migração de Dados da Microsoft). A ausência de erros na saída da ferramenta AMD, sobre a funcionalidade ausente ou incompatível, protege o aplicativo de qualquer regressão funcional na nova versão de destino. Se for necessário realizar alterações para garantir que o seu banco de dados funcione na nova versão, o DMA permitirá que você identifique quando as alterações são necessárias e quais soluções alternativas estão disponíveis. Para obter mais informações, confira Visão geral do Assistente de Migração de Dados.

Dica

Essa validação funcional é especialmente importante ao migrar um banco de dados de uma versão herdada, como o SQL Server 2008 R2 (10.50.x) ou o SQL Server 2012 (11.x), para uma nova versão do SQL Server ou do Banco de Dados SQL do Azure, porque o código do aplicativo pode usar um Transact-SQL descontinuado que não está protegido pelo nível de compatibilidade do banco de dados. Mas, quando estiver migrando de uma versão mais recente (como SQL Server 2016 (13.x)) para SQL Server 2019 (15.x) ou Banco de Dados SQL do Azure, não precisará se preocupar com nenhum Transact-SQL descontinuado. Para saber mais sobre o Transact-SQL descontinuado, confira Usar níveis de compatibilidade para compatibilidade com versões anteriores.

Observação

O AMD é compatível com o nível de compatibilidade do banco de dados de 100 ou mais. SQL Server 2005 (9.x) como a versão de origem é excluído.

Importante

A Microsoft recomenda que alguns testes mínimos sejam realizados para validar o sucesso de uma atualização, mantendo o nível de compatibilidade do banco de dados anterior. Você deve determinar quais testes mínimos são importantes para seu próprio aplicativo e cenário.

Importante

A Microsoft fornece proteção de forma do plano de consulta quando:

  • A nova versão do SQL Server (destino) é executada no hardware que é comparável ao hardware em que a versão anterior do SQL Server (origem) estava em execução.
  • O mesmo nível de compatibilidade do banco de dados compatível é usado no SQL Server de destino e no SQL Server de origem.
  • Os mesmos banco de dados e carga de trabalho são usados no SQL Server de destino e no SQL Server de origem.

Qualquer regressão de forma do plano de consulta (em comparação com o SQL Server de origem) que ocorre nas condições acima será tratada. Entre em contato com o atendimento ao cliente da Microsoft se esse for o caso.

Veja também