none
Pré requisitos para migração. RRS feed

  • Pergunta

  • Bom dia,
    Fazem algumas semanas que postei aqui sobre uma possível migração. Bom, o dia se aproxima, pois decidimos migrar do 2000 para o 2008.

    O servidor em questão é um Windows Server 2003
    Alugém tem ciência dos pré requisitos os quais devo me preocupar antes mesmo de inserir a mídia para iniciar o processo?
    Memória, espaço em disco, updates do Windows?

    Obrigado.

    Vinicius Allil


    DBA Vini
    • Editado Vinicius Allil segunda-feira, 15 de agosto de 2011 13:03 erro digitação
    segunda-feira, 15 de agosto de 2011 12:48

Respostas

  • Vinicius,

     

    Então, bom, antes de tudo, saiba que para evitar muitos problemas logo de cara e não parar seu ambiente, é possivel manter o nivel de compatibilidade das bases no SQL Server 2008 em 80, cuja qual possuira os mesmo comandos do 2000, mas saiba que isso deve ser apenas preventivo e arrumado ao longo do tempo, pois no SQL Server 2011 o nivel de compatibilidade 80 referente ao sql server 2000 não existe mais.

     

    Em relação ao hardware, se for apenas o SQL sim, sem base nenhum voce precisara de no minimo 1GB de ram e 5 GB de hd, mas claro que isso não é uma informação util, eu diria que em um servidor com 200GB de hd, se sua base tiver 150GB de hd, não sera possivel realizar a migração side-by-side. Portanto, fica complicado dizer, em relação a memoria, não creio que voce deva se preocupar tanto, pois se existem por exemplo 100 usuarios conectados, os mesmo 100 continuaram porem o servidor tera 2 instancias, então nao tera uma perda de performance.

     

    Segue um post que escrevi sobre niveis de compatibilidade: http://fabrizziocaputo.wordpress.com/2011/07/15/sql-server-basico-2-niveis-de-compatibilidade/


    Fabrizzio A. Caputo
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    • Marcado como Resposta Vinicius Allil terça-feira, 16 de agosto de 2011 13:49
    segunda-feira, 15 de agosto de 2011 13:38
    Moderador
  • Oi Vinicius,

    Os whitepapers são muito bons e seguí-los de cabo a rabo é uma boa aposta. A questão é que ele é um Whitepaper para tratar de todas as situações e há particularidades que ele não trata:

    - Como migrar logins e senhas sem saber quais são as senhas ?
    - Como migrar os SIDs para evitar perda de mapeamentos ?
    - Que cuidados devem ser tomados em relação aos Linked Servers com milhares de mapeamentos ?

    São algumas situações que esses whitepapers não tratam, mas que em determinados ambientes eles aparecem (e dão muito trabalho).

    Como você vai fazer Side by Side, alguns passos que eu recomendaria:

    - Documente tudo o que você vai fazer em um CheckList
    - Monte uma VM com as mesmas configurações do ambiente definitivo
    - Siga o seu Checklist etapa por etapa e proceda com a migração
    - Quando migrar para a VM, não tire o 2000 do ar, deixe-o intacto e com as aplicações apontando para o 2000 (não mexa na produção)
    - Aponte algumas aplicações (teste, dev, homologação, etc menos produção) para o ambiente da VM
    - Teste essas aplicações (firewall, conectividade e as principais funcionalidades)

    Dando certo, repita o processo umas duas ou três vezes. Se funcionar, faça o procedimento em produção. Se der pau, que bom. Você encontrou problemas antes de migrar. Arrume seu checklist e repita tudo novamente até dar certo. Dando certo teste de novo e se der certo aí sim vá para a produção.

    A idéia é deixar o processo maduro o suficiente para que quando você for fazer o processo em produção, seja parecido com mais uma das tantas que você ensaiou. Importantíssimo também é testar seu plano de retorno.

    Claro que alguém lendo isso pode pensar "Meu Deus, que tempestade para fazer um upgrade". Como disse, em ambientes menos críticos com muito downtime, etc talvez não seja preciso todo esse ritual (um simples backup pode resolver). Entretanto, se a criticidade aumentar, prevenir é melhor que remediar.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Vinicius Allil terça-feira, 16 de agosto de 2011 13:49
    segunda-feira, 15 de agosto de 2011 21:07

Todas as Respostas

  • Vinicius,

     

    Tudo em relação a hardware é dificil de dizer, pois depende muito de seu ambiente, da sua base, exemplo, se estivermos falando de um ambiente olap teremos uma situação, de um ambiente oltp outra, alem de que o tamanho e quantidade de acesso cujo qual não temos conhecimento se torna um problema ao tentar te especificar hardware.

     

    Mas tome cuidado pois do 2000 pra o 2008 muitas coisas mudaram, se eu fosse voce, antes de tudo, executaria um profiler puxando as features cujas quais foram descontinuadas em versões mais recentes, existem muitos artigos na internet sobre upgrade de versão, creio que não sera problema encontrar algo.


    Fabrizzio A. Caputo
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    segunda-feira, 15 de agosto de 2011 13:22
    Moderador
  • Fabrizzio,

    Dei uma boa olhada nos manuais de migração, whitepaper e afins. Levantei a relação do que mudou (claro que não tudo, pois é muito dificil encontrar 100%) Tenho já em mente que enfrentarei problemas de compatibilidade, migração de alguns objetos, cubos enfim. A dúvida seria mais quanto ao espaço em disco que a instalação do 2008 ocupa. Tudo referente aos dados e objetos eu garanto que há espaço no disco o qual ficarão os mesmos.

    A grosso modo gostaria de perguntar se um servidor com 16GB de memória e 200gb de espaço em disco comportam uma migração Side-by-side

    Obrigado pelas dicas!!


    DBA Vini
    segunda-feira, 15 de agosto de 2011 13:28
  • Vinicius,

     

    Então, bom, antes de tudo, saiba que para evitar muitos problemas logo de cara e não parar seu ambiente, é possivel manter o nivel de compatibilidade das bases no SQL Server 2008 em 80, cuja qual possuira os mesmo comandos do 2000, mas saiba que isso deve ser apenas preventivo e arrumado ao longo do tempo, pois no SQL Server 2011 o nivel de compatibilidade 80 referente ao sql server 2000 não existe mais.

     

    Em relação ao hardware, se for apenas o SQL sim, sem base nenhum voce precisara de no minimo 1GB de ram e 5 GB de hd, mas claro que isso não é uma informação util, eu diria que em um servidor com 200GB de hd, se sua base tiver 150GB de hd, não sera possivel realizar a migração side-by-side. Portanto, fica complicado dizer, em relação a memoria, não creio que voce deva se preocupar tanto, pois se existem por exemplo 100 usuarios conectados, os mesmo 100 continuaram porem o servidor tera 2 instancias, então nao tera uma perda de performance.

     

    Segue um post que escrevi sobre niveis de compatibilidade: http://fabrizziocaputo.wordpress.com/2011/07/15/sql-server-basico-2-niveis-de-compatibilidade/


    Fabrizzio A. Caputo
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    • Marcado como Resposta Vinicius Allil terça-feira, 16 de agosto de 2011 13:49
    segunda-feira, 15 de agosto de 2011 13:38
    Moderador
  • A base tem uns 60 GB. Mensuramos já para o Side-by-Side, e acredito que espaço esteja OK. A memória continua 1 GB mínimo então tudo bem!
    É claro que quando a aplicação começar a se comunicar e surgirem as solicitações dos usuários, terei ai noção do que preciso melhorar ou não.

    Mas se eu manter o nível em 80, não terei acesso às novas e boas do 2008??

    Obrigado!


    DBA Vini
    segunda-feira, 15 de agosto de 2011 13:52
  • Boa Tarde,

    Não creio que haverá problemas com o Side By Side, pois, embora duas instâncias exijam mais recursos que uma, haverá apenas uma ativa (antes da migração no 2000 e após a migração no 2008). Ainda assim, faça um teste do Side By Side para validar a estratégia e seus procedimentos, check lists, etc. Se você faz o plano várias vezes e dá certo, no momento da migração, será apenas mais uma dessas vezes. Se você apenas elaborou a estratégia e vai fazer a primeira vez direto na produção... Prepare-se para imprevistos.

    A questão do modo de compatibilidade é um mito e por várias vezes um assunto muito mal explicado (sujeito a especulações). Já discorri sobre esse assunto em posts anteriores e recomendo a pesquisa prévia. De antemão adianto que mudar para o 2008 e manter a compatibilidade em 2000 não irá restringí-lo em utilizar as novas features e mesmo comandos que não existiam no 2000 (mas existem no 2008) podem ser usados no 2008 (mesmo com modo de compatibilidade 2000). O INCLUDE do CREATE INDEX, o tipo de dados XML e as CTEs são provas vivas, pois, não existiam no SQL Server 2000, mas podem ser usados no 2008 (mesmo que a base esteja em nível de compatibilidade 2000).

    O que acontecerá se você mantiver o nível de compatibilidade é que alguns comandos (poucos) não estarão disponíveis (PIVOT por exemplo) e alguns comandos podem mudar de comportamento (REPLACE no 2000 funciona de um jeito, no 2008 funciona de outro jeito). Alguns "atalhos" também não funcionam. Você não pode informar o DB_ID() como parâmetro em algumas DMFs se estiver na compatibilidade 2000.

    As features de infraestrutura (Mirroring, Database Snapshot, etc) você tem acesso sem restrições.

    Um mito que já vi ser muito difundido (por muita gente respeitada inclusive) é que o nível de compatibilidade permite restaurar um base 2008 em um SQL Server 2000 por exemplo (afinal a compatibilidade é 2000). Completamente falso...

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 15 de agosto de 2011 16:52
  • Olá Maia,

    Quero questionar apenas o último parágrafo, o resto está muito claro, obrigado.

    Restaurar uma base 2008 em 2000 é um mito certo? Não tem como!
    Ou seja, em outras palavras, voltar para o SQL Server 2000 após migrado para o 2008 não será nada fácil!!!

    Posso interpretar o parágrafo como, "dificil plano de rollback para a migração"????


    DBA Vini
    segunda-feira, 15 de agosto de 2011 17:43
  • Oi Vinícius,

    A partir do momento em que a base respirou o SQL Server 2008, ou seja, foi atachada ou restaurada, o SQL Server irá converter seus arquivos MDF e LDF contemplando as novas estruturas, bits de controle, metadados, etc e aí não será possível voltar esses arquivos para a estrutura antiga.

    Se você estivesse fazendo um upgrade, você teria que desinstalar o SQL Server 2008, reinstalar o SQL Server 2000 e restaurar os backups das bases de sistema e das bases de negócio. No Side By Side, se a atualização não der certo, basta que você reaponte as aplicações para o servidor 2000 antigo.

    Essa é a "teoria" que os MOCs, Webcasts e o próprio White Paper informam. Entretanto, há uma situação muito perigosa que não é bem abordada nesses documentos. Imagine que você migra para o 2008, e após um ou dois dias, as aplicações não comportam-se como deveriam e você precisa voltar para o SQL Server 2000 ? Nessa situação, você não pode voltar um backup do 2000 ou reapontar as aplicações, pois, transações caíram no 2008 e o backup do 2000 não as tinha. Como não dá pra voltar um backup do 2008 para o 2000 o que fazer então ? Essa é uma questão para pensar e é por isso que é bom fazer vários testes para que na hora de migrar não haja surpresas. É preciso ter o plano de retorno, mas o ideal é que ele não seja usado nunca.

    Essa é uma preocupação para bases críticas. Claro que uma ou outra base mais leve, dá pra contornar.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 15 de agosto de 2011 18:23
  • Opa Maia,

    Legal,
    Quer dizer, legal não, interessante saber dos riscos e "mitos". Já fiz algumas migrações, porém em pequenos ambientes, onde puder parar a base e os servidor, pois as empresas eram pequenas e não tão críticas.

    Hoje estou em um ambiente bem complexo, com mais de 40 bancos. Há alguns dias nós trocamos posts sobre o plano e tal. E como você mesmo disse, é bom testar.
    Existe alguma possibilidade de "SIMULAR" isto?
    Pensando aqui num contexto um pouco mais amplo, será que uma VM seria uma solução para teste?

    Quanto ao Whitepaper: você não recomenda segui-lo "de cabo à rabo"?

    Abraços


    DBA Vini
    segunda-feira, 15 de agosto de 2011 18:51
  • Oi Vinicius,

    Os whitepapers são muito bons e seguí-los de cabo a rabo é uma boa aposta. A questão é que ele é um Whitepaper para tratar de todas as situações e há particularidades que ele não trata:

    - Como migrar logins e senhas sem saber quais são as senhas ?
    - Como migrar os SIDs para evitar perda de mapeamentos ?
    - Que cuidados devem ser tomados em relação aos Linked Servers com milhares de mapeamentos ?

    São algumas situações que esses whitepapers não tratam, mas que em determinados ambientes eles aparecem (e dão muito trabalho).

    Como você vai fazer Side by Side, alguns passos que eu recomendaria:

    - Documente tudo o que você vai fazer em um CheckList
    - Monte uma VM com as mesmas configurações do ambiente definitivo
    - Siga o seu Checklist etapa por etapa e proceda com a migração
    - Quando migrar para a VM, não tire o 2000 do ar, deixe-o intacto e com as aplicações apontando para o 2000 (não mexa na produção)
    - Aponte algumas aplicações (teste, dev, homologação, etc menos produção) para o ambiente da VM
    - Teste essas aplicações (firewall, conectividade e as principais funcionalidades)

    Dando certo, repita o processo umas duas ou três vezes. Se funcionar, faça o procedimento em produção. Se der pau, que bom. Você encontrou problemas antes de migrar. Arrume seu checklist e repita tudo novamente até dar certo. Dando certo teste de novo e se der certo aí sim vá para a produção.

    A idéia é deixar o processo maduro o suficiente para que quando você for fazer o processo em produção, seja parecido com mais uma das tantas que você ensaiou. Importantíssimo também é testar seu plano de retorno.

    Claro que alguém lendo isso pode pensar "Meu Deus, que tempestade para fazer um upgrade". Como disse, em ambientes menos críticos com muito downtime, etc talvez não seja preciso todo esse ritual (um simples backup pode resolver). Entretanto, se a criticidade aumentar, prevenir é melhor que remediar.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Vinicius Allil terça-feira, 16 de agosto de 2011 13:49
    segunda-feira, 15 de agosto de 2011 21:07
  • Bom dia Maia,

    Obrigado pelas dicas, farei o checklist e migrarei os ambientes de teste e homolog. primeiro.

    Pra falar verdade, fiz algumas migrações já conforme conversamos, mas meu único medo dessa vez, é que existem alguns "cubos" e não tenho a mínima dos cuidados e do comportamento pós migração.

    Conceitualmente, acredito que, se os cubos provém de procedures, não terei problemas! Maaaaasss...você sabe melhor do que ninguém, Banco de Dados é uma "caixona" de surpresas! Cada ambiente é único e incomparável.
    Vou continuar tocando os processos aqui, levantamentos etc e tal. Vou avisando e postando conforme o andamento do projeto.

    Obrigado Caputo
    Obrigado Maia

     

    []'s


    DBA Vini
    terça-feira, 16 de agosto de 2011 13:49