Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
SQL ServerBanco de Dados SQL do AzureInstância Gerenciada 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 riscos de compatibilidade de aplicativos.
O mesmo Mecanismo de Banco de Dados alimenta o SQL Server e o Banco de Dados SQL do Azure (incluindo a Instância Gerenciada SQL do Azure). Esse Mecanismo de Banco de Dados compartilhado significa que um banco de dados de usuário pode ser movido diretamente entre o SQL Server local e o Banco de Dados SQL do Azure, enquanto o código do aplicativo que é executado no banco de dados como Transact-SQL continua a funcionar como funcionaria em seu sistema de origem.
Para cada nova versão do 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 das versões anteriores é preservado para compatibilidade contínua dos aplicativos existentes. Esta matriz de compatibilidade pode ser vista aqui. Portanto, um aplicativo que foi certificado para funcionar com uma determinada versão do SQL Server foi, de fato, certificado para funcionar no nível de compatibilidade padrão dessa versão.
Por exemplo, o nível de compatibilidade de banco de dados 130 era o padrão no SQL Server 2016 (13.x). Como os níveis de compatibilidade forçam comportamentos específicos Transact-SQL funcionais e de otimização de consultas, um banco de dados certificado para funcionar no SQL Server 2016 (13.x) foi implicitamente certificado no nível de compatibilidade de banco de dados 130. Esse banco de dados pode funcionar as-is em uma versão mais recente do SQL Server (como o SQL Server 2019 (15.x)) e do 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 para o modelo de operação de integração contínua do Banco de Dados SQL do Microsoft 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 a funcionar conforme projetado, mesmo após atualizações para o Mecanismo de Banco de Dados subjacente.
É também assim que o SharePoint Server 2016 e o SharePoint Server 2019 certificam no SQL Server e na Instância Gerenciada 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, consulte Requisitos de hardware e software para o SharePoint Server 2016 e Requisitos de hardware e software para o SharePoint Server 2019.
Gerencie o risco de upgrade com certificação de compatibilidade
O uso da Certificação de Compatibilidade é uma abordagem valiosa para a 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 separa 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 conectando aplicativos que mantêm seu 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 tranquilidade em termos de gerenciamento desses riscos de atualização:
No que diz respeito ao comportamento Transact-SQL, qualquer alteração significa que um aplicativo precisa ser recertificado para correção. No entanto, a configuração de nível de compatibilidade de banco de dados fornece compatibilidade com versões anteriores do SQL Server somente para o banco de dados especificado, não para o servidor inteiro. Manter o nível de compatibilidade do banco de dados as-is garante que as consultas de aplicativos existentes continuem a exibir o mesmo comportamento antes e depois de uma atualização do Mecanismo de Banco de Dados. Para obter mais informações sobre comportamento Transact-SQL e níveis de compatibilidade, consulte Usando níveis de compatibilidade para compatibilidade com versões anteriores.
No que diz respeito ao desempenho, como as melhorias no Otimizador de Consultas são introduzidas com cada versão, pode-se esperar que ele encontre diferenças no plano de consulta entre diferentes versões do Mecanismo de Banco de Dados. As diferenças do 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 é o que geralmente impulsiona a necessidade de recertificação de aplicativos, o que pode atrasar upgrades e colocar desafios de ciclo de vida e suporte.
Reduzir os riscos de atualização é o motivo pelo qual as melhorias do Query Optimizer estão limitadas ao nível de compatibilidade padrão de uma nova versão (em outras palavras, o mais alto nível de compatibilidade 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 a manutenção de 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 no uso do mesmo modelo de otimização de consulta na nova versão que era antes da atualização, e a forma do plano de consulta não deve ser alterada.
Para obter mais informações, consulte a seção Por que consultar a forma do plano? neste artigo.
Para obter mais informações sobre níveis de compatibilidade, consulte Usando 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 de banco de dados anterior. Não há necessidade de recertificar um aplicativo nesse cenário. Para obter mais informações, consulte Níveis de compatibilidade e atualizações do Mecanismo de Banco de Dados mais adiante neste artigo.
Para novos trabalhos de desenvolvimento, ou quando um aplicativo existente exigir o uso de novos recursos, como o processamento inteligente de consultas e alguns novos Transact-SQL, planeje atualizar o nível de compatibilidade do banco de dados para o mais recente disponível no SQL Server e recertificar 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, consulte Práticas recomendadas para atualizar o nível de compatibilidade do banco de dados.
Porquê consultar a forma do plano?
A 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, varreduras, 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 devem ser executadas para produzir o conjunto de resultados pretendido. A forma do plano de consulta é determinada pelo Otimizador de Consulta.
Para manter o desempenho da consulta previsível durante uma atualização, um dos objetivos fundamentais é garantir que a mesma forma de plano de consulta seja usada. Isso pode ser conseguido não alterando 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 da consulta, como alterações significativas nos recursos disponíveis ou distribuição de dados nos 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 fizer alterações ambientais, poderá introduzir fatores que tenham 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 do servidor ou do banco de dados ou alterações na distribuição de dados que afetam como um plano de consulta é criado. É por isso que é 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 aspetos ambientais que influenciam o desempenho da consulta, alguns dos quais são alterações iniciadas pelo usuário.
Para obter mais informações, consulte o Guia de Arquitetura de Processamento de Consultas.
Benefícios da certificação de compatibilidade
Há vários benefícios imediatos na certificação de banco de dados como uma abordagem baseada em compatibilidade, em vez de uma abordagem de versão nomeada:
Desacople a certificação de aplicativos da plataforma. Devido ao seu Mecanismo de Banco de Dados compartilhado, para aplicativos que só precisam executar consultas Transact-SQL, não há necessidade de manter processos de certificação separados para o Azure e no 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 de aplicativo e banco de dados podem ser separados para menos interrupções e melhor gerenciamento de alterações.
Atualize sem alterações de código. A atualização para uma nova versão do SQL Server ou do Banco de Dados SQL do Azure pode ser feita sem alterações de código, mantendo o mesmo nível de compatibilidade do sistema de origem e sem necessidade imediata de recertificação até o momento em que o aplicativo precisa usar aprimoramentos que só estão disponíveis em um nível de compatibilidade de banco de dados mais alto.
Melhore a capacidade de gerenciamento e a escalabilidade sem exigir alterações no aplicativo, usando aprimoramentos que não são limitados pelo nível de compatibilidade do banco de dados. No SQL Server, eles incluem, por exemplo:
Melhorias avançadas de monitoramento e solução de problemas, com novas exibições de gerenciamento dinâmico do sistema, eventos estendidos e ajuste automático.
Escalabilidade aprimorada, por exemplo, com Soft-NUMA automático, recuperação acelerada de banco de dados ou metadados tempdb otimizados para memória.
Novas bases de dados são ainda configuradas para o nível de compatibilidade padrão da versão do Motor de Base de Dados. Mas quando um banco de dados é restaurado ou anexado de qualquer versão anterior do SQL Server a uma nova versão do SQL Server ou do Banco de Dados SQL do Azure, o banco de dados mantém seu nível de compatibilidade existente.
Verificar o nível de compatibilidade suportado
Antes de mover um banco de dados para uma nova versão do SQL Server ou do Banco de Dados SQL do Azure, verifique se o nível de compatibilidade do banco de dados ainda é suportado. A matriz de suporte do nível de compatibilidade do banco de dados pode ser vista nos argumentos do nível de compatibilidade ALTER DATABASE.
A atualização de um banco de dados com um nível de compatibilidade inferior ao nível permitido (por exemplo, 90, que era o padrão no SQL Server 2005 (9.x)), define o banco de dados para o nível de compatibilidade mais baixo 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 capacidade de suporte, você deve executar a validação estática da área de superfície funcional 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 de quaisquer regressões funcionais na nova versão de destino. Se forem necessárias alterações para garantir que seu 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, porque o código do aplicativo pode estar usando Transact-SQL descontinuados que não estão protegidos pelo nível de compatibilidade do banco de dados. Mas ao mudar 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 descontinuados com os quais se preocupar. Para obter mais informações sobre o Transact-SQL descontinuado, consulte Usando o nível de compatibilidade para compatibilidade com versões anteriores.
Observação
O componente de migração do SQL Server oferece suporte ao nível de compatibilidade de banco de dados 100 e superior. SQL Server 2005 (9.x) como 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 o que o teste mínimo significa para seu próprio aplicativo e cenário.
Proteção do plano de consulta
A Microsoft fornece proteção de forma de plano de consulta quando:
A nova versão do SQL Server (destino) é executada em hardware comparável ao hardware em que a versão anterior do SQL Server (origem) estava sendo executada.
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 de forma de plano de consulta (em comparação com o SQL Server de origem) que ocorra nessas condições será abordada. Neste caso, contacte o Suporte ao Cliente da Microsoft.