Table of Contents
Esse artigo foi originalmente escrito em: SQL Server 2012 Upgrade and Application Compatibility (en-US)
Introdução
O SQL Server 2012 Developer Training Kit Content é projetado para desenvolvedores que desejam explorar todas as novas melhorias nesta versão. Mas o que dizer sobre todas as aplicções que foram desenvolvidos para versões anteriores do SQL Server? Este
wiki é para desenvolvedores, testadores e profissionais de serviços que são responsáveis por certificar que seu aplicativo tem suporte ao SQL Server 2012.
Em um mundo perfeito, aplicativos que foram desenvolvidos para versões anteriores devem funcionar perfeitamente no SQL Server 2012. Acredite em mim, a Microsoft investe um bom tempo e energia em fazer isto possível para uma ampla gama de aplicações. Se você
tiver um aplicativo relativamente simple que apenas usa o mecanismo de banco de dados e não usa um monte de recursos avançados, e você não está preocupado com a possibilidade de tempo de paralização relacionado atualização, então você pode querer apenas puxar
o gatilho e tentar um in-place upgrade de sua instância do SQL Server.
Departamentos de TI freqüentemente aproveitam a oportunidade de atualizações de versão para fazer upgrade ou consolidar o hardware. Se você quiser ser um pouco mais conservador, você pode fazer backup de bancos de dados SQL Server existentes e restaurá-los
em uma nova instalação do SQL Server 2012 e apenas realinhar suas seqüências de conexão para a nova instância. Você sempre poderá alternar novamente para a instância antiga ja que ela não foi alterada durante o processo de atualização.
Infelizmente, pó de fadas mágico não é sempre suficiente para aplicativos de missão crítica. Se as operações de negócios dependem da disponibilidade de um aplicativo de SQL Server que você pretende atualizar, você deve provavelmente criar um plano de teste
que garanta que seu aplicativo funcionará corretamente contra o SQL Server 2012. Você pode até querer fazer algumas execuções a seco da atualização real antes de fazer a atualização propriamente dita para evitar surpresas ou tempo paralização da aplicação.
Este wiki é para aquelas pobres almas paranóicas que não acreditam na poeira de fadas mágico. Se você quiser ser mais previsível e sistemático sobre a atualização, você realmente precisa testar os aplicativos que serão afetados. Chamamos esta atualização teste
de compatibilidade de aplicativos ou apenas AppCompat para abreviar. Desenvolvemos ferramentas e metodologias para fazer AppCompat teste mais fácil, mas você precisa entender, desde o início, que exigirá um compromisso significativo de tempo e recursos para
concluir o processo de teste. Você estará sujeito a uma curva de aprendizado bastante íngreme ao testar seu aplicativo primeiro, mas depois que você tiver o domínio do processo a próxima execução deve ser um moleza!
Testar aplicações críticas ao negócio para compatibilidade com o SQL Server 2012 é uma parte importante de qualquer plano abrangente de atualização. Se o aplicativo foi desenvolvido por você mesmo ou comprou de terceiros, há um amplo conjunto de ferramentas
e estratégias você pode usar para identificar potenciais bloqueadores de atualização para que eles podessam ser resolvidos antes que uma atualização seja tentada.
Este wiki é focado principalmente em SQL Server 2012 Upgrade e teste de aplicativo e compatibilidade (AppCompat) e descreve como identificar sistematicamente bloqueadores de atualização potenciais em aplicativos que têm uma dependência no mecanismo de banco
de dados do SQL Server. Fornecemos algumas orientações gerais atualização focada no mecanismo de banco de dados do SQL Server, mas talvez você precise encontrar alguns recursos adicionais ao planejar sua atualização se você estiver usando recursos avançados
como replicação, espelhamento de banco de dados ou o cluster de failover. Não abordamos atualizações do Integration Services, Reporting Services ou o Analysis Services neste wiki.
Aqui está uma descrição de alto nível das etapas envolvidas em uma atualização de mecanismo de banco de dados SQL Server 2012 típica:
- Identificar metas de atualização
- Identificar e corrigir bloqueadores de Upgrade
- Escolha Uma Estratégia de Atualização
- Realize sua Atualização
Identificar metas de atualização
Atualizando para o SQL Server 2012 pode ser tão simple como atualizar um par de instâncias para uma pequena empresa ou departamento, mas as grandes empresas podem ter centenas de instalações do SQL Server, que algumas das quais o departamento de TI pode
nem mesmo estar estar ciente. Assim o primeiro passo é obter um inventário de todas as instalações do SQL Server que são alvos potenciais de atualização. Se precisar de ajuda para identificar metas de atualização, confira o Microsoft
Assessment and Planning Toolkit (também conhecido como MAP Toolkit).
Depois de encontrar todas as instalações a serem atualizadas, você também precisará identificar os aplicativos que a utilizam. Aplicativos que são essenciais para as operações de negócios devem ser sinalizados para o teste de AppCompat.
Identificar e corrigir bloqueadores de Upgrade
Depois de identificadas as instalações do SQL Server e aplicativos associados que você pretende atualizar, a próxima etapa é identificar qualquer coisa que possam impedir uma atualização bem-sucedida. As seções a seguir descrevem três abordagens diferentes (e complementares) para a detecção de bloqueadores de atualização. Você pode decidir usar alguns, todos ou nenhum deles, a escolha é sua. A quantidade de testes e preparação que você fazer antecipadamente terá um resultado direto no quanto preparado está para resolver problemas que ocorrem quando o tempo vier para realizar sua atualização.
Executar Verificação de Saúde Inicial
Você pode começar com o básico, verificando a integridade física da instalação do SQL Server e seus bancos de dados associados com ferramentas como DBCC (verificador de consistência de banco de dados). Em seguida, você pode considerar reduzir o tamanho físico
do banco de dados o que pode ser útil se sua estratégia de atualização envolve mover o banco de dados para um novo armazenamento.
Você também pode considerar a utilização do
SQL Server 2008 R2 Best Practices Analyzer para encontrar em sua instância e bancos de dados possíveis violações das práticas recomendadas. É uma boa idéia solucionar estas violações antes de fazer um upgrade. Você também deve verificar também se alguma
instância esta iniciando com qualquer sinalizador de rastreamento especial e se você ainda precisa utilizá-los após a atualização. É uma boa idéia eliminar estes sinalizadores se possível.
Execute Upgrade Advisor
Em seguida, você deve verificar a instância e todos seus bancos de dados por potenciais bloqueadores de atualização usando SQL Server 2012 Upgrade Advisor. Esta ferramenta executa um conjunto de verificações baseadas em regras para identificar bloqueadores de atualização comuns e produz um relatório de recursos. Você deve então sistematicamente abordar todas as violações de regra antes de tentar atualizar. É importante observar que o Upgrade Advisor usa análise estática e não detectará problemas que estão ocultos no código fonte da aplicação ou que só pode ocorrer em tempo de execução.
Realizar testes de AppCompat
A etapa final é usar a ferramenta Upgrade Assistant Tool for SQL Server 2012 (UAFS) para realizar testes de AppCompat para aplicativos que são essenciais para as operações de negócios. UAFS permite que você capture a interação entre o aplicativo e o
SQL Server e salve-o como uma carga de trabalho de teste. A ferramenta então orienta a repetição da carga de trabalho de teste contra a versão original do SQL Server para estabelecer uma base execução e então novamente contra o SQL Server 2012.
A saída destas repetições de carga de dois trabalho sistemicamente é analisado em seguida as diferenças. Em alguns casos, as diferenças podem ser o resultado de um bloqueador de atualização que deve ser abordado no código de origem do aplicativo. Testes de
AppCompat com UAFS é tão boa como a carga de trabalho de teste. Se sua carga de trabalho cobre a maior parte dos diferentes tipos de interação que seu aplicativo tem com o SQL Server, ele deve ser bastante abrangente. Mas se você apenas testar uma carga de
trabalho de "hello world", você não vai ficar com muita informação útil do mesmo.
Para obter instruções sobre como criar uma configuração de máquina virtual para testes de AppCompat, consulte How to Build a VM for Application Compatibility Testing for SQL Server 2012 (WEKA build).
Importante: Para manter compatibilidade com versões anteriores, a instalação preservará o nível de compatibilidade existente de cada banco de dados durante uma atualização. O objetivo final dos
testes AppCompat é garantir que suas funções de aplicativo utilizem corretamente o nível de compatibilidade do banco de dados para SQL Server 2012 (110), por isso verifique se você está testando suas cargas de trabalho contra esse nível de compatibilidade.
Certifique-se de configurar seus bancos de dados de aplicativo para este novo post-upgrade nível de compatibilidade. Isso vai facilitar futuras migrações após SQL Server 2012, garantindo que você não está usando recursos descontinuados. Consulte este
artigo no SQL Server Books Online para uma discussão abrangente de compatibilidade com versões anteriores incluindo funcionalidades descontinuadas e substituídas no SQL Server 2012.
Escolha Uma Estratégia de Atualização
Há tão muitas estratégias de atualização ao longo do dia, e não é nossa intenção enumerar todas elas aqui, mas parações de aplicativo utilizem corretamente o nível de compatibilidade do banco de dados para SQL Server 2012 (110), por isso verifique se você está testando suas cargas de trabalho contra esse nível de compatibilidade. Certifique-se de configurar seus bancos de dados de aplicativo para este novo post-upgrade nível de compatibilidade. Isso vai facilitar futuras migrações após SQL Server 2012, garantindo que você não está usando recursos descontinuados. Consulte este artigo no SQL Server Books Online para uma discussão abrangente de compatibilidade com versões anteriores incluindo funcionalidades descontinuadas e substituídas no SQL Server 2012.
Importante: Fazer backup de todos seus bancos de dados antes de iniciar sua atualização! Fazer uma restauração de teste de backups para certificar-se de que eles são válidos!
In-Place Upgrade
Este é provavelmente o mais fácil de todas as estratégias de atualização. Contanto que o computador atende aos requisitos mínimos de sistema, instalação permitirá que você atualize um SQL Server realizando uma instalação no local do SQL Server 2012. O nome
da instância é preservado, assim você não precisa atualizar as seqüências de conexão de aplicativos dependentes. Você só pode atualizar para a edição de mesma ou superior do SQL Server usando essa abordagem.
In-place upgrade é suportado somente para as seguintes versões do SQL Server (note o service pack mínimo exigido):
- SQL Server 2005 (SP4)
- SQL Server 2008 (SP2)
- SQL Server 2008 R2
Se você estiver executando o SQL Server 2000, você precisará atualizar para SQL Server 2008 R2 antes de tentar atualizar para SQL Server 2012.
Observe que você não pode alterar a plataforma como parte do in-place upgrade. Por exemplo, se você estiver executando SQL Server 2008 R2 (x86) no Windows Server 2008 R2 (x64), você não pode executar uma atualização in-loco para SQL Server 2012 (x64). Você
pode atualizar para SQL Server 2012 (x 86).
A desvantagem dessa abordagem é que não há nenhuma volta a não ser desinstalar o SQL Server 2012 e reinstalar a edição anterior e restaurar todo o servidor de um backup, então isso provavelmente só é adequado para servidores que não afetam as operações de negócios
de forma substancial.
Atualização Side-By-Side
Esta abordagem também é bastante fácil. A idéia é instalar uma nova instância do SQL Server 2012 lado a lado com sua instância antiga no mesmo computador. Uma vez que sua Nova instância está em execução, você pode simplesmente desanexar os bancos de dados
de usuário da instância antiga, anexá-los na nova instância e conectar seus aplicativos no novo nome de instância.
Se você encontrou algum problema, você pode simplesmente restaurar backups os bancos de dados na instância antiga e reconectar os aplicativos. Depois que tiver certeza de que está tudo bem, você pode desinstalar a instância antiga.
Atualizar por Migração
Esta é a maneira ideal de fazer um upgrade se você tem os recursos para executá-lo. Basicamente você provisiona um novo computador e instala uma cópia nova do SQL Server 2012 nele, restaura os backups de bancos de dados do aplicativo e reconectar os aplicativos
na nova instância. Se encontrar problemas, você sempre pode voltar a utilizar o servidor antigo até que você tenha resolvido as coisas.
Esta abordagem é muito mais limpa, garantindo que somente os bits mais recentes estão em uso no servidor novo o que reduz a manutenção ja que você não precisa se preocupar sobre como manter os velho e novo bits. Há todos os tipos de truques que você pode jogar
para fazer o failover para o novo servidor tão rápido quanto possível para minimizar o tempo de inatividade resultante do upgrade.
Muitas empresas de TI preferem esse modelo para que possam atualizar o hardware e o software na mesma proposta e possivelmente consolidar servidores ao mesmo tempo.
Realize sua Atualização
Quando tiver concluído todas as etapas de pré-atualização planejamento e teste, é hora de executar! Esperamos que as ferramentas e estratégias constidas neste wiki garanta que você está preparados para quaisquer questões ou problemas que possam surgir. Assim
que terminar sua atualização, não se esqueça de aumentar o nível de compatibilidade do banco de dados dos bancos de dados usuário para SQL Server 2012 (110). Também é uma boa idéia para monitorar o desempenho e o comportamento de seus aplicativos mais estreitamente
do que o normal por um tempo depois da atualização. Até mesmo o melhor upgrade planejado pode perder algumas coisas sutis que podêm afetar o desempenho do aplicativo ou funcionalidade.
Retornar ao SQL Server 2012 Early Adoption Cook Book.
Outros Idiomas
Este artigo está igualmente disponível nos seguintes idiomas:
Inglês (en-US)
In-place upgrade é suportado somente para as seguintes versões do SQL Server (note o service pack mínimo exigido):
Observe que você não pode alterar a plataforma como parte do in-place upgrade. Por exemplo, se você estiver executando SQL Server 2008 R2 (x86) no Windows Server 2008 R2 (x64), você não pode executar uma atualização in-loco para SQL Server 2012 (x64). Você pode atualizar para SQL Server 2012 (x 86).
A desvantagem dessa abordagem é que não há nenhuma volta a não ser desinstalar o SQL Server 2012 e reinstalar a edição anterior e restaurar todo o servidor de um backup, então isso provavelmente só é adequado para servidores que não afetam as operações de negócios de forma substancial.
Se você encontrou algum problema, você pode simplesmente restaurar backups os bancos de dados na instância antiga e reconectar os aplicativos. Depois que tiver certeza de que está tudo bem, você pode desinstalar a instância antiga.
Esta abordagem é muito mais limpa, garantindo que somente os bits mais recentes estão em uso no servidor novo o que reduz a manutenção ja que você não precisa se preocupar sobre como manter os velho e novo bits. Há todos os tipos de truques que você pode jogar para fazer o failover para o novo servidor tão rápido quanto possível para minimizar o tempo de inatividade resultante do upgrade.
Muitas empresas de TI preferem esse modelo para que possam atualizar o hardware e o software na mesma proposta e possivelmente consolidar servidores ao mesmo tempo.