A etapa principal a ser executada é executar o Supervisor de Atualização no banco de dados SQL Server 2000 e solucionar todos os problemas relatados por ele.
Como prática recomendada, use a ferramenta Upgrade Advisor no banco de dados herdado do SQL Server 2000 e importe um arquivo de rastreamento para a ferramenta Upgrade Advisor para análise. O arquivo de rastreamento permite que o Supervisor de Atualização detecte problemas que podem não aparecer em uma simples varredura do banco de dados, como o TSQL incorporado nos aplicativos. Você pode capturar traços de TSQL usando o SQL Profiler no servidor SQL Server 2000 durante o horário normal e analisá-los usando o Supervisor de Atualização.
Portanto, o restante das etapas seria:
No dia da migração:
- script nossos logins no servidor 2000 usando sp_help_revlogin .
- Script fora de trabalhos e servidores vinculados do sql 2000 server.
- pare os servidores da web que se conectam ao servidor 2000. Verifique se nenhum aplicativo está se conectando ao servidor 2000.
- faça backup de seus bancos de dados e restaure no servidor sql 2008 R2 de destino.
- Depois que seus backups forem restaurados no servidor 2008 R2, execute a saída de sp_help_revlogin no servidor 2008 R2 para recriar logins.
- Sincronize usuários órfãos (se houver) e recrie trabalhos de agentes sql e servidores vinculados no novo servidor.
- altere o nível de compatibilidade nos bancos de dados restaurados para 100.
- Dbcc checkdb com as opções all_errormsgs e data_purity ativadas:
DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
- execute DBCC UPDATEUSAGE nos bancos de dados restaurados
DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
- Atualize as estatísticas em todas as tabelas com varredura completa:
Update Statistics table_name with FULLSCAN
- Opcional: Verifique os níveis de fragmentação e, dependendo do nível de fragmentação, execute uma reorganização / reconstrução de todos os índices. Você pode usar os scripts do Ola .
- Recompile todos os SPs usando
sp_recompile 'procedureName'
- Atualize suas visualizações
SP_REFRESHVIEW view_name
- certifique-se de alterar a opção do banco de dados: página, verifique para CHECKSUM.
- Altere o modelo de recuperação (se diferente do sql 2000) para COMPLETO. Se você mudar para o modelo de recuperação COMPLETO, certifique-se de fazer backups do log de transações com freqüência. Isso o ajudará a recuperar o point-in-time, além de não inchar seu T-Log.
No SQL Server 2005 e versões posteriores , o Database Mail foi introduzido. Então você precisa migrar do SQLMail para o Database Mail.
USE [master]
GO
sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO
Além disso, se você tiver alguma replicação, precisará redefini-la. Se algum DR, como loggingping ou Mirroring (novo em 2005 e posteriores, mas depreciado em 2012), você também precisará redefini-lo.
Os pacotes antigos do DTS precisam ser migrados para o SSIS usando C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTSMigrationWizard.exe(linha de comando) ou usando o Assistente de Migração de Pacotes .
Além disso, você pode usar meu script encontrado em /dba//a/36701/8783 . No entanto, ele usa o método desanexar / anexar, eu recomendo que você use o método BACKUP / RESTORE . Mude o script de acordo.
Como uma nota rodapé:
- ative a Inicialização instantânea de arquivos no novo servidor.
- Tem vários arquivos de dados tempdb com tamanho igual.
- Ativar sinalizador de rastreamento 1118
- Configure a memória máxima e mínima corretamente. Especialmente memória máxima longe do padrão.
- Ajuste corretamente as configurações do MAXDOP. Consulte /dba//a/36578/8783 para obter mais detalhes.
- O melhor é instalar o sp_Blitz do Brent Ozar. Execute-o e resolva os problemas críticos e de alta prioridade relatados por ele.
- Você pode até usar o SQL Power Doc da kendalvandyke - o SQL Power Doc funciona com todas as versões do SQL Server do SQL Server 2000 a 2012 e todas as versões do Windows Server e Windows Operating Systems do Windows 2000 e Windows XP ao Windows Server 2012 e Windows 8. Também útil para o planejamento de atualizações - veja quais recursos ocultos estão em uso em uma instância.
- Ative Otimizar para cargas de trabalho ad-hoc e opções de compactação de backup padrão.
Vamos resolver suas perguntas ...
O que mais devo fazer para concluir a migração?
Consulte a minha resposta. Isso ajudará você a elaborar adequadamente um plano de migração. Sempre teste seu plano de migração em um UAT (não produção) junto com o teste de aplicativo adequado por usuários corporativos.
use novos recursos, como soma de verificação e modelo de recuperação completa.
CHECKSUMé novo no SQL Server 2005 e superior. Eu o cobri como parte das etapas de migração descritas acima.
full recovery modelnão é novo. Depende do seu tipo de negócio e determina a quantidade de dados que você pode perder em caso de desastre.
O modo de recuperação completa com backups freqüentes do log de transações permitirá restaurar o ponto no tempo e o local, reduzindo a quantidade de perda de dados.
torne esse banco de dados exatamente como foi criado no SQL Server 2008 R2.
torne esse banco de dados totalmente compatível, correto e perfeito para o novo mecanismo de banco de dados SQL 2008 R2.
Não entendo isso completamente! Mas as etapas de migração acima ajudarão você. Você só precisa restaurar o banco de dados e alterar o nível de compatibilidade 10, 100juntamente com as etapas acima.
Eu só quero saber como converter correta e completamente o banco de dados antigo do SQL Server 2000 para o novo banco de dados 2008 R2, ter a calma de que tudo está bem e ser feliz com todos os novos recursos.
Você deve ter cuidado com isso, pois isso também exigirá alterações no código do aplicativo. Se o código do seu aplicativo for alterado para usar os novos recursos do SQL Server 2008 R2, você não encontrará nenhum problema - FORNECIDO que você fez um teste de regressão completo do seu aplicativo em um ambiente UAT ou DEV. Isso lhe dará mais confiança quando você faz a migração real no PROD.
Nota: Acima estão as etapas que eu lembro e tenho certeza de que nada foi deixado de fora. Se perceber que perdi algumas coisas, adicionarei ou outros especialistas neste site - fique à vontade para adicionar!
Tudo o que foi descrito acima precisa primeiro ser reproduzido em um ambiente de NÃO PRODUÇÃO para evitar surpresas durante a migração real.
----------
Mais algumas perguntas:
Você recomenda o uso do método de backup / restauração, mas fiz como descrito acima; posso encontrar problemas agora? Tudo funcionou sem nenhum problema.
Se tudo funcionou bem e você conseguiu anexar o banco de dados, NÃO, você não terá problemas. Desanexar / Anexar vs Backup / Restauração é apenas um método de como você move seus bancos de dados para um local diferente. Apenas para sua informação. O backup / restauração é mais seguro e confiável, como se algo desse errado (nos piores casos), então você tem um backup para restaurar e recuperar seus bancos de dados.
Sobre o modelo de soma de verificação e recuperação completa: ele não estava disponível / ativado no SQL Server 2000, por isso quero usá-los agora. Você disse que a única coisa que preciso fazer é ativar essas opções nas propriedades do banco de dados? Eu li em algum lugar, que não é suficiente e também devo reconstruir índices ou algo assim. Eu realmente não sei, só estou perguntando.
Como eu disse, a soma de verificação é nova na versão 2005 e posteriores. É um mecanismo pelo qual o SQL Server detectará corrupção de página, principalmente devido a E / S. Consulte a minha resposta aqui para mais detalhes.
Para ativar o CHECKSUM e alterar o modelo de recuperação para COMPLETO, você pode fazer isso usando o código T-SQL abaixo:
USE master;
GO
ALTER DATABASE [your_database_name] -- change this !!
SET RECOVERY FULL, PAGE_VERIFY CHECKSUM;
GO
Nota: Depois de definir as opções do banco de dados, elas serão mantidas quando você fizer a migração de 2008R2 para 2012.
Estou me preparando para migrar esse banco de dados para o SQL Server 2012 - então, primeiro, foi de 2000 a 2008 R2, agora será de 2008 R2 a 2012 (era impossível fazer isso diretamente devido à falta de suporte aos bancos de dados 2000 no SQL Server 2012). Então eu entendo que devo seguir seu guia: faça backup em 2008 R2 e restaure em 2012, e faça o resto de suas dicas, certo?
Sim por favor. Como eu disse, a restauração de backup é o método preferido , a menos que você tenha um bom motivo para não fazer isso.
Por favor, explique-me o método de backup / restauração: É como um despejo de banco de dados para consultas SQL e, em seguida, restaurando-o executando várias consultas? Esse método, a propósito, "desfragmentará" meu banco de dados? Caso contrário, como desfragmentar / otimizar manualmente?
O backup / restauração é ... semelhante ao dump and load usado no Sybase, Oracle ou provavelmente no MySQL também. É apenas o SQL Server o chama .. backup / restore.
A deve ler: Noções básicas sobre backups do SQL Server por Paul Randall.
Sintaxe simples (para sintaxe completa, consulte BOL ):
backup database database_name
to disk = 'D:\backup\database_name_full.bak'
with init, stats =10
Em seguida, a restauração pode ser feita no servidor de destino como:
- supondo que o layout do disco do destino não corresponda ao do servidor de origem
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
move 'logical_data_fileName' to 'physical_path\database_name.mdf'
move 'logical_log_fileName' to 'physical_path\database_name_log.ldf'
with recovery, stats = 10
- supondo que o layout do disco do destino corresponda ao do servidor de origem
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
with recovery, stats = 10
Esse método, a propósito, "desfragmentará" meu banco de dados? Caso contrário, como desfragmentar / otimizar manualmente?
O backup / restauração não desfragmentará seu banco de dados. Você precisa usar o Alter Index Reorganize ou Rebuild, dependendo do seu nível de fragmentação.
Como você é novo no SQL Server, recomendo que você use o Ola Hallengren's:
Como estávamos usando o SQL Server 2000 Express por anos (sem interface de gerenciamento), estávamos fazendo backups simplesmente parando o mecanismo e RAR o diretório DATA. Por enquanto, como estamos no SQL Server 2008, isso ainda não é melhor do que usar a função de backup no Management Studio?
Parar o mecanismo é a pior coisa que você pode fazer para fazer um backup!
Leia o link de Paul sobre os backups que mencionei e use o script de Ola. A Microsoft possui um artigo da KB com o script para fazer backups automatizados - Como agendar e automatizar backups de bancos de dados do SQL Server no SQL Server Express
Modo de recuperação completa com backups freqüentes do log de transações - onde está armazenado o log de transações - é o arquivo LDF? Como devo fazer o backup corretamente?
Todo banco de dados do SQL Server possui um log que registra todas as transações e modificações no banco de dados feitas por cada transação. O log de transações é um componente crítico de qualquer banco de dados.
A extensão de convenção de nomenclatura usual para o log de transações é '.LDF', mas pode ser qualquer.
Não vou escrever mais sobre isso, pois isso tornará a resposta muito enxuta. Consulte
Gerenciamento de log de transações e minha resposta aqui também possui excelentes links.
EDIT: 24/08/2016. Isso ajudará futuros leitores:
Se você estiver migrando toda a instância de uma versão para outra, eu recomendo usar a solução baseada no PowerShellStart-SqlMigration
