Compartilhar via

Certificação de compatibilidade

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.

Também é assim que o SharePoint Server 2016 e o SharePoint Server 2019 são certificados no SQL Server e na Instância Gerenciada de SQL do Azure. Você pode implantar qualquer Mecanismo de Banco de Dados do SQL Server que use os níveis de compatibilidade de banco de dados com suporte para essas 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. Quando os desenvolvedores certificam com base no nível de compatibilidade, você define os requisitos técnicos para que um aplicativo tenha suporte no SQL Server e no Banco de Dados SQL do Azure, mas dissocia o ciclo de vida do aplicativo do ciclo de vida da plataforma de 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.

Os principais fatores de risco para qualquer atualização são a possibilidade de afetar negativamente a funcionalidade e problemas de desempenho. 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 se traduzem em 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 da forma do plano de consulta: a noção de que manter um nível de compatibilidade de banco de dados as-is, imediatamente após uma atualização do Mecanismo de Banco de Dados, se traduz em usar o mesmo modelo de otimização de consulta na nova versão como era antes da atualização e a forma do plano de consulta não deve ser alterada.

    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.

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 neste 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 exigir o uso de novos recursos, como processamento de consulta inteligente e algum novo Transact-SQL, planeje atualizar o nível de compatibilidade do banco de dados para o mais recente disponível no SQL Server e certificar seu aplicativo para trabalhar 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 a forma de um plano de consulta não é o único fator que pode ter implicações de desempenho após uma atualização. Se você mover o banco de dados para um Mecanismo de Banco de Dados mais recente e também fazer alterações ambientais, poderá introduzir fatores que têm um efeito imediato no desempenho de uma consulta, mesmo que o plano de consulta mantenha a mesma forma entre as versões. Essas alterações ambientais podem incluir o novo Mecanismo de Banco de Dados com mais ou menos recursos de memória e CPU disponíveis, alterações nas opções de configuração de servidor ou banco de dados ou alterações na distribuição de dados que afetam a forma 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, estes 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.

Examinar o nível de compatibilidade suportado

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 no nível de compatibilidade do banco de dados pode ser vista em argumentos de nível de compatibilidade ALTER DATABASE.

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 compatibility_level coluna em 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 seu status de suporte, você deve executar a validação da área de superfície funcional estática do código do aplicativo no banco de dados (objetos 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 o componente de migração do SQL Server no SQL Server Management Studio. A ausência de erros na saída do relatório, sobre funcionalidade ausente ou incompatível, protege o aplicativo contra quaisquer regressões funcionais na nova versão de destino. Se forem necessárias alterações para garantir que o banco de dados funcione na nova versão, a ferramenta permitirá que você identifique onde as alterações são necessárias e quais soluções alternativas estão disponíveis.

Essa validação funcional é especialmente importante ao mover 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, pois o código do aplicativo pode estar usando Transact-SQL descontinuada que não esteja protegida pelo nível de compatibilidade do banco de dados. No entanto, ao migrar de uma versão mais recente (como o SQL Server 2016 (13.x)) para o SQL Server 2022 (16.x) ou o Banco de Dados SQL do Azure, não há Transact-SQL descontinuada para se preocupar. Para saber mais sobre o Transact-SQL descontinuado, confira Usar níveis de compatibilidade para compatibilidade com versões anteriores.

Observação

O componente de migração do SQL Server dá suporte ao nível de compatibilidade do banco de dados 100 ou superior. SQL Server 2005 (9.x) como a versão de origem é excluído.

Recomendamos que você execute alguns testes mínimos 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.

Proteção do plano de consulta

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 de banco de dados com suporte é usado no SQL Server de destino e no SQL Server de origem.

  • O mesmo banco de dados e carga de trabalho é usado no SQL Server de destino e no SQL Server de origem.

Qualquer regressão da forma do plano de consulta (em comparação com o SQL Server de origem) que ocorre nessas condições será tratada. Entre em contato com o Suporte ao Cliente da Microsoft nesse caso.

Conteúdo relacionado

  • Last updated on