Usuário com melhor resposta
Migração Sql Server x86 para x64

Pergunta
-
Olá galera...
Daqui alguns dias vou realizar uma migração de Sql Server 2005 da plataforma x86 para a x64.
A principio li em alguns foruns que somente um backup/restore resolve o problema sem mais dores de cabeça...porém resolvi perguntar a voçês se é só isso mesmo...
Não existe nenhum outro impacto?
Outro ponto é o seguinte...além da migraçao de versão...vamos tirar os bancos dos de discos locais e coloca-los em Storage....e obviamente que os endereços físicos dos arquivos dos bancos irão mudar....
Como se trata de uma migraçao...para facilitar o processo...pretendo fazer o restore dos bancos de sistema tb...(Master..Msdn..etc..)...
Como o master leva os endereços físicos dos arquivos dos bancos da maquina antiga para a nova...estou pensando em primeiro subir os bancos com a mesma estrutura de dicos que tinha na maquina antiga para a nova..e depois disso....desmonta-los e monta-los no storage...o que acham?Existe uma idéia melhor?
Desde já agradeço!!!
Daniel
Daniel- Movido Gustavo Maia Aguiar terça-feira, 15 de dezembro de 2009 19:29 (De:SQL Server - Desenvolvimento Geral)
Respostas
-
Olá Daniel,
Vamos por partes então...
O Windows não sabe como o storage funciona internamente. Como você vai organizar as Luns, os Raids, etc não diz respeito ao Windows. O que importa é que ao término, haja uma unidade disponível para ele. A questão de ser //alguma coisa ou D: é um detalhe de SO e não de storage então não fará diferença. Para mover da máquina local para o storage faça o seguinte:
- Tire um backup por emergência
- Pare o SQL Server
- Configure as Luns do Storage e entregue um disco para o Windows
- Crie uma nova letra para o volume (Digamos E:)
- Move todos os MDFs e LDFs para o E: (mesma estrutura de pastas)
- Renomeie a letra para D:
- Suba novamente o SQL Server
- Rode um DBCC CHECKDB contra todos os bancos de dados
No momento em que você desligou o SQL Server, os arquivos estão liberados e como ele não está ativo, ele não tem "ciência" do que está acontecendo. Quando você subir o serviço ele procurará pelo Driver D: que já foi configurado. Uma vez que o storage seja transparente para o Windows, o SQL Server não fará nenhuma crítica do tipo "Você trocou o disco local por um storage" e tudo funcionará perfeitamente.
Essa estratégia só não pode ser utilizada para o C:\Program Files\Microsoft SQL Server e nem para os arquivos de dados dos bancos de sistema (Master, Model, TempDb, ResourceDB e MSDB). Se o disco só tem banco de dados de negócio então não tem nenhum problema.
Vale a pena lembrar que essa estratégia é para modificar os discos utilizados. Quando você for migrar para a estrutura X64, você terá que reinstalá-lo do zero e restaurar os backups. O que descrevi não servirá para migração de SQL Server (apenas para migração de FileSystem). Recomendo que você faça dessa forma para não misturar as mudanças e tornar um plano de retorno mais complicado.
[ ]s,
Gustavo Maia Aguiar
http://gustavomaiaaguiar.spaces.live.com
SQL Server Saturday Night
http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!878.entry
Classifique as respostas. O seu feedback é imprescindível- Sugerido como Resposta Gustavo Maia Aguiar terça-feira, 15 de dezembro de 2009 20:59
- Marcado como Resposta Daniel Zaitz quarta-feira, 16 de dezembro de 2009 11:41
-
Boa Tarde Daniel,
Um simples backup / restore resolve (assim como attach). Só não é possível a instalação de forma a sobrepor a arquitetura x86, ou seja, você não pode instalar por cima. É necessário desinstalar a x86 e utilizar a x64.
O que eu recomendaria no seu caso é dividir as mudanças, pois, se tudo for feito junto, o plano de retorno é mais complicado. No caso do storage faça o seguinte:
- Pare o SQL Server
- Faça as trocas de storage
- Mantenha as letras
- Suba o SQL Server
Se a mudança for transparente para o SO, apenas parar, trocar as luns e subir o SQL Server é suficiente.
Já fiz isso várias vezes e nunca tive problemas.
[ ]s,
Gustavo Maia Aguiar
http://gustavomaiaaguiar.spaces.live.com
SQL Server Saturday Night
http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!878.entry
Classifique as respostas. O seu feedback é imprescindível- Sugerido como Resposta Gustavo Maia Aguiar terça-feira, 15 de dezembro de 2009 19:28
- Marcado como Resposta Daniel Zaitz quarta-feira, 16 de dezembro de 2009 11:41
Todas as Respostas
-
Boa Tarde Daniel,
Um simples backup / restore resolve (assim como attach). Só não é possível a instalação de forma a sobrepor a arquitetura x86, ou seja, você não pode instalar por cima. É necessário desinstalar a x86 e utilizar a x64.
O que eu recomendaria no seu caso é dividir as mudanças, pois, se tudo for feito junto, o plano de retorno é mais complicado. No caso do storage faça o seguinte:
- Pare o SQL Server
- Faça as trocas de storage
- Mantenha as letras
- Suba o SQL Server
Se a mudança for transparente para o SO, apenas parar, trocar as luns e subir o SQL Server é suficiente.
Já fiz isso várias vezes e nunca tive problemas.
[ ]s,
Gustavo Maia Aguiar
http://gustavomaiaaguiar.spaces.live.com
SQL Server Saturday Night
http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!878.entry
Classifique as respostas. O seu feedback é imprescindível- Sugerido como Resposta Gustavo Maia Aguiar terça-feira, 15 de dezembro de 2009 19:28
- Marcado como Resposta Daniel Zaitz quarta-feira, 16 de dezembro de 2009 11:41
-
Ola Gustavo...
Antes de mais nada obrigado pelas dicas!
Estou com uma duvida na parte do Storage ainda...
Vamos la...
Hoje tenho bancos em discos locais em uma maquina...ou seja...d:\meubanco\meubanco.mdf por exemplo....
Vou mudar essa estrutura para storage...eu consigo criar uma lun com esse mesmo endereço?Desculpe...eu sempre trabalhei com storage em Solaris ou Linux...e eles começam com //alguma coisa
Outro detalhe.....pretendo colocar os bancos de sistema em uma lun diferente dos bancos de usuario assim como log separado de dados e uma lun diferente para o tempdb...
Correto?
Não devo manter o crescimento automatico desses bancos como se eu tivesse usando discos de máquinas locais...ou não tem problema?
Agradeço,
Daniel
Daniel -
Olá Daniel,
Vamos por partes então...
O Windows não sabe como o storage funciona internamente. Como você vai organizar as Luns, os Raids, etc não diz respeito ao Windows. O que importa é que ao término, haja uma unidade disponível para ele. A questão de ser //alguma coisa ou D: é um detalhe de SO e não de storage então não fará diferença. Para mover da máquina local para o storage faça o seguinte:
- Tire um backup por emergência
- Pare o SQL Server
- Configure as Luns do Storage e entregue um disco para o Windows
- Crie uma nova letra para o volume (Digamos E:)
- Move todos os MDFs e LDFs para o E: (mesma estrutura de pastas)
- Renomeie a letra para D:
- Suba novamente o SQL Server
- Rode um DBCC CHECKDB contra todos os bancos de dados
No momento em que você desligou o SQL Server, os arquivos estão liberados e como ele não está ativo, ele não tem "ciência" do que está acontecendo. Quando você subir o serviço ele procurará pelo Driver D: que já foi configurado. Uma vez que o storage seja transparente para o Windows, o SQL Server não fará nenhuma crítica do tipo "Você trocou o disco local por um storage" e tudo funcionará perfeitamente.
Essa estratégia só não pode ser utilizada para o C:\Program Files\Microsoft SQL Server e nem para os arquivos de dados dos bancos de sistema (Master, Model, TempDb, ResourceDB e MSDB). Se o disco só tem banco de dados de negócio então não tem nenhum problema.
Vale a pena lembrar que essa estratégia é para modificar os discos utilizados. Quando você for migrar para a estrutura X64, você terá que reinstalá-lo do zero e restaurar os backups. O que descrevi não servirá para migração de SQL Server (apenas para migração de FileSystem). Recomendo que você faça dessa forma para não misturar as mudanças e tornar um plano de retorno mais complicado.
[ ]s,
Gustavo Maia Aguiar
http://gustavomaiaaguiar.spaces.live.com
SQL Server Saturday Night
http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!878.entry
Classifique as respostas. O seu feedback é imprescindível- Sugerido como Resposta Gustavo Maia Aguiar terça-feira, 15 de dezembro de 2009 20:59
- Marcado como Resposta Daniel Zaitz quarta-feira, 16 de dezembro de 2009 11:41
-