none
Aplicação de Upgrade no SQL Server com bases offline RRS feed

  • Pergunta

  • Olá,

    Um determinado ambiente que minha equipe administra possui SQL Server em cluster. Vamos aplicar um Service Pack nas instâncias porém precisamos que determinada base esteja disponível pra uso antes das outras. Sabemos que pacotes de atualizações (tanto CU como SP) costumam ir de base em base para atualização de metadados (seguindo por ordem o database_id) e só libera a instância para uso depois que o Script Upgrade mode é aplicado em toda instância (ou seja, em todas as bases), e tivemos a ideia de deixar todas as bases offline para reduzir o tempo de indisponibilidade (causado pelo Script Upgrade mode), fazendo com que a instância esteja disponível mais rapidamente e abrindo a possibilidade de trazer as bases de volta para online de forma gradual aplicando a atualização sugerida pelo SQL Server (de acordo com a mensagem registrada no errorlog). 

    Pra facilitar a explicação da minha dúvida:

    Cenário:

    - Failover Cluster com dois nós e disco de quorum (NODE A e NODE B)

    - Uma instância SQL Server EE 2008R2

    - A nó principal da instância INST1 é o NODE A;

    - A instância INST1 possui cinquenta bases. Uma das bases é utilizada por todas as bases do ambiente, a BDMAIN. Precisamos que essa base fique disponível primeiro que todas as outras, e isso não vai acontecer do modo tradicional (graças ao modo que o Upgrade Script Mode opera).

    Passos:

    1) Realizo o move da INST1 do NODE A para o NODE B; (tempo de indisponibilidade: 5 min)

    2) Aplico o Service Pack no NODE A. 

    3) Seto todas as bases de usuário para OFFLINE;

    4) Realizo o move da INST1 do NODE B para o NODE A.

    Neste momento a instância será atualizada, o que demoraria aproximadamente 1h se eu não tivesse setado todas as bases para OFFLINE. Setando as bases OFFLINE, sofro uma  indisponibilidade de acesso à instância (causada pelo Script Upgrade mode) de apenas 10 minutos. Consultando o errorlog neste momento, percebo diversas mensagens conforme abaixo:

    Could not open database %s. Replication settings and system objects could not be upgraded. If the database is used for replication, run sp_vupgrade_replication in the [master] database when the database is available.

    5) Acesso a INST1 e deixo a BDMAIN online e executo a solicitada sp_vupgrade_replication;

    Neste momento, a base mais crítica do ambiente e que é compartilhada por várias outras instâncias está acessível.

    6) Gradualmente, subo as bases por ordem de importância e aplico a procedure já mencionada no passo 5.

    Minha dúvida é: o procedimento acima pode causar algum problema, seja relacionado à corrupção ou quaisquer outras inconsistências? 

    PS: Eu sei que poderíamos isolar o node B (sem instâncias) tirar do possible owners e atualizar lá, pra depois fazer os moves, etc, mas é apenas uma estratégia e não interfere diretamente na dúvida.

    []'s



    Se a resposta ajudou, classifique e ajude outros membros da comunidade.


    • Editado Renato Siqueira quinta-feira, 6 de novembro de 2014 11:45 Explicação corrigida. Coloquei INST2 sem querer.
    quarta-feira, 5 de novembro de 2014 18:35

Respostas

  • Olá Renato,

    Qual o build atual do SQL Server e qual o Service Pack/Cummulative Update que você está tentando instalar?

    Qual a versão do Windows? 2008? e qual o service pack?

    Existe um bug no SMB do Windows 2008 que afetava o setup SQL Server 2008, não lembro se também o 2008 R2, mas investigarei para você.

    O problema pode não ser o mesmo, mas vale a pena investigar se o teu ambiente está nessa situação descrita no artigo abaixo:

    SQL Server 2008 failover cluster installation can take a long time on Windows Server 2008

    https://support.microsoft.com/kb/2000219?wa=wsignin1.0

    Ou se estaria tendo esse problema descrito nesse outro artigo:

    FIX: SQL Server 2012 failover cluster installation takes an unexpectedly long time to validate clustered storage

    http://support.microsoft.com/kb/2686690

    Esses eram problemas mais relacionados ao período do Setup, não lembro de ter visto problemas desse tipo no momento em que o SQL está em Script Upgrade mode, mas talvez valha a pena você verificar se existe correlação. 

    Aguardo sua confirmação e te sugiro fazer um teste, se possível, já com versões posteriores a quando corrigimos esses erros tanto no Sistema Operacional, quanto no SQL Server.

    Caso nenhuma dessas opções funcione, podemos seguir te apoiando com a criação de um caso de suporte.

    As versões mais recentes do SQL Server 2008 R2 podem ser encontradas nesse site: http://sqlserverbuilds.blogspot.com/#sql2008r2

    aguardo teu retorno.

     

    atenciosamente,


    Roberto Cavalcanti | Sr. Support Escalation Engineer | Microsoft Latam

    sexta-feira, 7 de novembro de 2014 23:28
  • Obrigado pelo update Renato. Quando estiver pronto para fazer os novos testes, por favor entre em contato conosco para que possamos trabalhar contigo e possamos verificar se existe algum problema com o produto que possa estar causando esse demora durante a atualização.

    Roberto Cavalcanti | Sr. Support Escalation Engineer | Microsoft Latam

    Oi Roberto, trabalho junto com o Renato e descobrimos o problema.

    Ele ocorre pelo fato de o CDC está ativado e a procedure [sp_cdc_vupgrade] ser executada para cada base de dados.

    Identificamos que essa procedure recria alguns dos índices das tabelas internas do CDC, inclusive das capture instance. Assim se alguma tabela do CDC está muito grande, então pode ser que esse problema possa acontecer uma vez que a instância ficará em script upgrade mode até que o CREATE do index termine sua execução.


    []'s | Rodrigo Ribeiro Gomes | MCTS/MCITP Dev/DBA


    • Marcado como Resposta Renato Siqueira terça-feira, 9 de dezembro de 2014 13:13
    • Editado RodrigoRRG terça-feira, 9 de dezembro de 2014 13:34
    segunda-feira, 8 de dezembro de 2014 16:26
  •  

    Olá Roberto,

    Depois de pesquisar os links e procurar por problemas similares no connect/msdn, a princípio não localizei correlação... 
    Testamos em um cluster de testes (SQL Server 2008R2 EE + WS 2008R2 Enterprise) com dois nós, duas instâncias com bases iguais e idênticas. A única diferença é que em uma das instâncias, ativamos o CDC em todas as bases. Medimos o tempo que cada instância ficou indisponível (e contando o SMU) e vimos que a instância que estava com CDC ativado demorou três vezes mais pra ser disponibilizada pra uso.

    Suspeitamos que o CDC possa ter alguma relação com a demora. 

    Iremos fazer mais testes em outras oportunidades. 

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.



    quarta-feira, 12 de novembro de 2014 18:31
  • Oi pessoal,

    Complementando a resposta do Rodrigo, agora que temos evidências de que realmente o CDC tem relação com a demora (devido ao drop e create que ocorrem nos índices durante a execução da sp_cdc_vupgrade_databases dentro da sp_vupgrade_replication) vamos realizar mais testes reproduzindo o cenário da atualização em instâncias 2008R2 e 2012 (onde encontramos este KB que tem relação com o upgrade de longa duração mas não necessariamente com o cdc) e adicionalmente,  identificar se houve alguma mudança significativa.

    Desde já, agradeço a todos que participaram do tópico e qualquer informação adicional aqui será muito bem vinda!

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.


    terça-feira, 9 de dezembro de 2014 13:56

Todas as Respostas

  • Renato,

    A grosso modo a sua estratégia não é ruim e também não esta fora de uma possível solução!!!

    O que me preocupa é justamente o momento em que você vai fazer uso do sp_vupgrade_replication, onde as duas pontas precisam estar atualizações em relação a todos os possíveis níveis de correção e atualização.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com

    sexta-feira, 7 de novembro de 2014 13:52
    Moderador
  • Renato,

    A grosso modo a sua estratégia não é ruim e também não esta fora de uma possível solução!!!

    O que me preocupa é justamente o momento em que você vai fazer uso do sp_vupgrade_replication, onde as duas pontas precisam estar atualizações em relação a todos os possíveis níveis de correção e atualização.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com

    Pois é, essa é a única exigência que aparece no errorlog (rodar a proc) e me preocupo se só isso é o bastante para finalizar o upgrade sem risco de inconsistências.

    De resto, não entendi a parte sublinhada... Pode explicar melhor, por gentileza?

    Valeu!


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.

    sexta-feira, 7 de novembro de 2014 16:12
  • Olá Renato,

    Qual o build atual do SQL Server e qual o Service Pack/Cummulative Update que você está tentando instalar?

    Qual a versão do Windows? 2008? e qual o service pack?

    Existe um bug no SMB do Windows 2008 que afetava o setup SQL Server 2008, não lembro se também o 2008 R2, mas investigarei para você.

    O problema pode não ser o mesmo, mas vale a pena investigar se o teu ambiente está nessa situação descrita no artigo abaixo:

    SQL Server 2008 failover cluster installation can take a long time on Windows Server 2008

    https://support.microsoft.com/kb/2000219?wa=wsignin1.0

    Ou se estaria tendo esse problema descrito nesse outro artigo:

    FIX: SQL Server 2012 failover cluster installation takes an unexpectedly long time to validate clustered storage

    http://support.microsoft.com/kb/2686690

    Esses eram problemas mais relacionados ao período do Setup, não lembro de ter visto problemas desse tipo no momento em que o SQL está em Script Upgrade mode, mas talvez valha a pena você verificar se existe correlação. 

    Aguardo sua confirmação e te sugiro fazer um teste, se possível, já com versões posteriores a quando corrigimos esses erros tanto no Sistema Operacional, quanto no SQL Server.

    Caso nenhuma dessas opções funcione, podemos seguir te apoiando com a criação de um caso de suporte.

    As versões mais recentes do SQL Server 2008 R2 podem ser encontradas nesse site: http://sqlserverbuilds.blogspot.com/#sql2008r2

    aguardo teu retorno.

     

    atenciosamente,


    Roberto Cavalcanti | Sr. Support Escalation Engineer | Microsoft Latam

    sexta-feira, 7 de novembro de 2014 23:28
  • Olá Roberto,

    Seguem informações:

    Build atual: 10.50.4305 (SP2 CU12)
    Upgrade pretendido: 10.50.6000 (SP3)
    Versão do S.O: Windows Server 2008 R2 Datacenter SP1

    Agradeço pelos links. Vou usá-los para uma investigação mais refinada considerando com atenção as versões onde os bugs ocorriam.

    De segunda para terça que vem (10 e 11/11), terei condições de realizar os testes. 

    Desde já, muito obrigado pelo auxílio.

    Obs: Apenas para acrescentar informações, o que o tempo de startups está ok. O maior problema é no tempo de espera causado pelo S.U.M, que dura em média 2h (em algumas aplicações de CU, já chegou em 2h30min). Desconfiamos também de algum DBCC que é executado nesses upgrades possa ter relação com o problema, pois o tempo de espera parece ter relação com o tamanho dos bancos de dados (essa informação foi obtida associando tempo x mensagens no errorlog). 

    []'s



    Se a resposta ajudou, classifique e ajude outros membros da comunidade.



    sábado, 8 de novembro de 2014 04:38
  •  

    Olá Roberto,

    Depois de pesquisar os links e procurar por problemas similares no connect/msdn, a princípio não localizei correlação... 
    Testamos em um cluster de testes (SQL Server 2008R2 EE + WS 2008R2 Enterprise) com dois nós, duas instâncias com bases iguais e idênticas. A única diferença é que em uma das instâncias, ativamos o CDC em todas as bases. Medimos o tempo que cada instância ficou indisponível (e contando o SMU) e vimos que a instância que estava com CDC ativado demorou três vezes mais pra ser disponibilizada pra uso.

    Suspeitamos que o CDC possa ter alguma relação com a demora. 

    Iremos fazer mais testes em outras oportunidades. 

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.



    quarta-feira, 12 de novembro de 2014 18:31
  • Obrigado pelo update Renato. Quando estiver pronto para fazer os novos testes, por favor entre em contato conosco para que possamos trabalhar contigo e possamos verificar se existe algum problema com o produto que possa estar causando esse demora durante a atualização.

    Roberto Cavalcanti | Sr. Support Escalation Engineer | Microsoft Latam

    quinta-feira, 13 de novembro de 2014 12:53
  • Obrigado pelo update Renato. Quando estiver pronto para fazer os novos testes, por favor entre em contato conosco para que possamos trabalhar contigo e possamos verificar se existe algum problema com o produto que possa estar causando esse demora durante a atualização.

    Roberto Cavalcanti | Sr. Support Escalation Engineer | Microsoft Latam

    Oi Roberto, trabalho junto com o Renato e descobrimos o problema.

    Ele ocorre pelo fato de o CDC está ativado e a procedure [sp_cdc_vupgrade] ser executada para cada base de dados.

    Identificamos que essa procedure recria alguns dos índices das tabelas internas do CDC, inclusive das capture instance. Assim se alguma tabela do CDC está muito grande, então pode ser que esse problema possa acontecer uma vez que a instância ficará em script upgrade mode até que o CREATE do index termine sua execução.


    []'s | Rodrigo Ribeiro Gomes | MCTS/MCITP Dev/DBA


    • Marcado como Resposta Renato Siqueira terça-feira, 9 de dezembro de 2014 13:13
    • Editado RodrigoRRG terça-feira, 9 de dezembro de 2014 13:34
    segunda-feira, 8 de dezembro de 2014 16:26
  • Oi pessoal,

    Complementando a resposta do Rodrigo, agora que temos evidências de que realmente o CDC tem relação com a demora (devido ao drop e create que ocorrem nos índices durante a execução da sp_cdc_vupgrade_databases dentro da sp_vupgrade_replication) vamos realizar mais testes reproduzindo o cenário da atualização em instâncias 2008R2 e 2012 (onde encontramos este KB que tem relação com o upgrade de longa duração mas não necessariamente com o cdc) e adicionalmente,  identificar se houve alguma mudança significativa.

    Desde já, agradeço a todos que participaram do tópico e qualquer informação adicional aqui será muito bem vinda!

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.


    terça-feira, 9 de dezembro de 2014 13:56
  • Obrigado pelo update Renato,

    Quando você testar esse update do kb http://support.microsoft.com/kb/3013551 por favor nos avise. Acredito que essa seja a solução, mas gostaria de confirmar se o seu ambiente será impactado como esperado, pois caso o CDC seja a razão, e não o problema que foi corrigido nesse kb, gostaria de abrir um canal de contato direto contigo para que pudéssemos abrir um caso de suporte e investigar mais profundamente esse problema.

    atenciosamente,


    Roberto Cavalcanti | Sr. Support Escalation Engineer | Microsoft Latam

    terça-feira, 9 de dezembro de 2014 14:27
  • Ok Roberto,

    Muito obrigado pela presteza e assim que possível, vamos reportar os resultados dos teste... 

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.


    • Editado Renato Siqueira quarta-feira, 17 de dezembro de 2014 19:55 retirada de prazo
    terça-feira, 9 de dezembro de 2014 15:43
  • Senhores,

    Acredito que já temos vários indícios das causas da demora, e ao que tudo indica isto é "by design".

    Roberto, abrimos um caso de suporte, se você quiser / puder se envolver, seria de grande valia para nós...  

    Ficamos (Renato, Rodrigo e Eu) comprometidos em assim que o caso de suporte for encerrado, postar aqui a resposta / solução encontrada para o problema, para que demais pessoas que venham a enfrentar tal problema, possam encontrar a solução da thread no final da mesma... 

    quarta-feira, 10 de dezembro de 2014 12:07