Eu tenho trabalhado com o SQL Server dentro e fora desde o SQL Server 6.5, o velho conselho que ainda soa na minha cabeça era nunca fazer uma atualização in-loco.
Atualmente estou atualizando meus sistemas 2008 R2 DEV e TEST para SQL Server 2012 e preciso usar o mesmo hardware. A ideia de não ter que restaurar a configuração do meu Reporting Services é muito atraente e estou realmente contra a parede em termos de tempo. Não há serviços de análise envolvidos ou qualquer coisa incomum ou fora do padrão - apenas o mecanismo de banco de dados e os serviços de relatórios são instalados.
Alguém já teve problemas sérios com atualizações in-loco? Ou devo reavaliar minha posição sobre atualizações no local?
Resposta realmente curta - No lugar está tudo bem. Você pode revisar sua configuração posteriormente e implementar as práticas recomendadas para o SQL Server 2012.
Uma resposta mais longa sobre atualizações/migrações do SQL Server
Portanto, isso é uma questão de opinião e não há uma resposta necessariamente errada ou certa, mas prefiro atualizações de estilo de migração no local por vários motivos. Dito isto - alguns dos meus clientes, por várias razões, não tiveram escolha a não ser fazer um in-loco e, desde o SQL Server 2005, as atualizações in-loco não são tão ruins quanto costumavam ser.
Por que prefiro uma migração para uma atualização in-loco
Lembre-se que não estou dizendo que você tem que fazer isso como uma migração. O In-Place funciona e funciona bem se você não estiver planejando comprar um novo hardware em seu orçamento e não puder fazer isso para esta atualização. O suporte no processo de atualização é muito melhor do que nos 6,5 dias, então você não está se colocando em uma posição ruim fazendo isso.
Se você planeja fazer in-loco para desenvolvimento/teste, mas deseja fazer uma migração para produção, considere fazer pelo menos uma migração antes da produção. Dessa forma, você pode elaborar sua lista de verificação com antecedência e lidar com possíveis problemas nos quais não estava pensando.
Anexar/Desanexar vs. Backup/Restauração para Migrações
Se você decidir seguir a abordagem de migração, ainda há mais uma decisão sobre a qual você ainda pode debater e é como você move seu banco de dados para o novo ambiente. Você pode desanexar seu banco de dados do servidor antigo e anexá-lo ao novo ou fazer backup e restaurá-lo lá.
Eu prefiro backup/restauração. A maior vantagem que ouvi sobre detach/attach é que economiza algum tempo. Para mim, backup/restauração ganha por alguns motivos:
Se você decidir fazer o backup/restauração - isso significa que seu banco de dados de origem antigo ainda estará online. Eu gosto de deixar esse banco de dados offline depois de fazer o backup. Às vezes, dou um passo adiante e coloco toda a instância do SQL offline depois de criar scripts de segurança, trabalhos, servidor vinculado, certificados, configurações de correio de banco de dados e outras informações de toda a instância. Isso evita um problema durante o teste em que alguém diz "Tudo parece ótimo!" apenas para perceber um ou dois dias depois que eles estavam conversando com o banco de dados antigo no servidor antigo. Colocar esses bancos de dados offline ou toda a instância offline permite que você evite esses falsos positivos e a bagunça que eles fazem.
Como tornar a abordagem de migração mais rápida
Você pode minimizar o tempo de inatividade necessário para a transição de um ambiente antigo para um novo para um ambiente de produção ocupado com pouco tempo de inatividade utilizando o modelo de recuperação completo. Basicamente - prepare o ambiente para o qual você está migrando restaurando o backup completo mais recente, quaisquer backups diferenciais e quaisquer backups de log já feitos especificando
NORECOVERY
- então tudo o que você terá que fazer para o corte final é restaurar os backups de log que ainda não foram restaurados e o backup de log final que você deseja restaurar especificandoWITH RECOVERY
. Dessa forma, para um banco de dados grande, a janela de tempo de inatividade de cutover real pode ser drasticamente minimizada pagando o custo das restaurações completas, diferenciais e da maioria dos logs antes da janela de tempo de inatividade. Obrigado ao Tao por apontar isso nos comentários!Como tornar a atualização in-loco mais segura
Algumas coisas que você pode fazer para melhorar sua experiência e resultados ao escolher a abordagem no local.
A importância das listas de verificação de atualização ou migração
Se você decidir fazer uma atualização (seja no local ou migração), considere seriamente criar uma lista de verificação e usá-la em cada ambiente. Você deve incluir um monte de coisas nesta lista de verificação, entre as quais:
E então faça com que a pessoa que fará a atualização de produção siga a lista de verificação em algum ambiente diferente da produção - especialmente um que se pareça com a produção, se possível ("Sul da produção", como eu digo ...) e anote quaisquer problemas ou pontos onde eles tiveram que desviar da lista de verificação ou improvisar devido a uma falta na lista de verificação. Em seguida, junte as alterações e divirta -se com sua alteração de produção.
Eu não posso enfatizar a importância de testar completamente após a migração ou atualização e antes de sua migração o suficiente. Tomar uma decisão de reversão no meio de uma atualização deve ser fácil - especialmente durante uma migração. Se houver algo desconfortável, reverta e descubra se você não puder solucioná-lo de maneira eficaz e confiável no calor da migração. Quando você estiver ao vivo nesse novo ambiente e os usuários se conectarem, a reversão se tornará uma tarefa difícil. Você não pode restaurar um banco de dados SQL Server para uma versão anterior. Isso significa trabalho manual e migrações de dados. Eu sempre espero algumas semanas para matar o ambiente antigo, mas você deve fazer todo o possível para evitar a necessidade desse ambiente antigo, encontrando todos os seus problemas antes que seus usuários ativos toquem no novo ambiente. De preferência antes mesmo de iniciar a atualização/migração.
Nota rápida sobre migração/atualização do SQL Server Reporting Services Migrar uma instalação do SSRS não é uma tarefa hercúlea que muitos pensam que é. Este artigo online de technet/books é realmente bastante útil . Uma das advertências mais importantes nesse artigo é "Faça backup das chaves de criptografia" , especialmente se você tiver muitas informações confidenciais salvas, como endereços de e-mail de destinatários de e-mail de relatório agendado, informações de conexão para várias conexões, etc. posso perguntar a um dos meus clientes de algum tempo atrás o quão importante isso é. Eles sabem porque eu estraguei essa etapa e gastei muito tempo modificando agendas de relatórios e permissões de string de conexão.
Na minha experiência, o mesmo processo de tomada de decisão deve ser feito anteriormente. AFAIK não houve 'mudanças de mundo' com a instalação do SQL Server, dentro do produto MS SQL Server em si, e os problemas potenciais que você tem ao lançar software com milhões de linhas de código. Algo ruim pode acontecer e agora você está preso sem a opção 'ROLLBACK'.
No entanto, você tem outras alternativas no lugar. Você pode considerar fazer um instantâneo do sistema, restaurar em outro lugar, realizar a atualização e ver o que acontece. Este teste deve lhe dar muito conforto, mas não garante absolutamente nenhum problema na caixa do produto. No entanto, essa é uma opção que não estava disponível nos dias do SQL 6.5.
Eu apenas assumiria o pior cenário. Você faz uma atualização no local e falha miseravelmente. Você precisa se recuperar disso dentro do seu RTO e RCO. A empresa entende os riscos e você tem planos para mitigá-los?
Se o negócio não está bem com isso, então não faça isso seria meu conselho.
Se você tiver seus servidores em execução em um ambiente virtual, poderá executar um instantâneo em um clone e, em seguida, aplicar a atualização in-loco e testar a instância para verificar se a atualização foi bem-sucedida. Se funcionar, você pode aplicar o instantâneo e tornar o clone o servidor de produção. Se tudo der errado, você pode excluir o instantâneo e voltar para a imagem de pré-atualização para tentar novamente ou excluir o clone e fazer uma migração completa.
Devido a um grande investimento em hardware, fomos obrigados a atualizar apenas o SO, mantendo a versão atual do SQL Server (2012, 3 servidores, 22 instâncias, ~300 bancos de dados). Sem configurações complexas como espelhamento, etc.
Este exemplo não corresponde exatamente à pergunta, pois o SQL Server não está sendo atualizado. Eu acho que essa ainda é uma boa resposta porque as etapas mostradas seriam realmente mais simples do que uma migração verdadeira no local.
Visão geral: Uma unidade externa foi anexada para fazer backups completos principalmente como precaução. Apenas o modelo e o msdb serão realmente restaurados da unidade externa. O ldf/mdf foi deixado no lugar para desanexar/anexar. Algumas contas locais foram referenciadas nos BDs. Depois que eles foram recriados no SO, as referências dentro do banco de dados foram recriadas (já que os SIDs podem mudar).
Então, aqui estão as etapas que funcionaram para nós:
1) Anote as configurações de nível de servidor que serão restauradas nas etapas 12 (Funções de servidor) e 18 a 23.
2) Patch SQL Server 2012 para SP3 (consistência necessária se quisermos restaurar qualquer banco de dados do sistema).
3) Verifique se as versões correspondem em cada instância. "Selecione @@versão"
4) Gere esses 6 scripts executando este script. Redgate SQL Multiscript é uma economia de tempo enorme se houver muitas instâncias (Ajuste as Ferramentas -> Opções => Comprimento da Linha ao máximo (8192) e use a Saída de Texto).
Revincular usuários a logins
5) Execute o script para fazer backup de todos os bancos de dados, incluindo o sistema (master, msdb, modelo) para a unidade externa.
6) Execute o script para desanexar todos os bancos de dados
7) O Drive C será reformatado. Preserve os LDF/MDFs se eles NÃO estiverem em C.
8) O Windows Server 2012 está instalado em C
9) Mova o LDF/MDF para arquivos originais do sistema para fora do caminho se eles não estiverem na unidade C.
10) O SQL Server 2012 será reinstalado e corrigido para o SP3 a. Recriar contas de usuário/grupo do sistema
11) Faça backup dos BDs do sistema para um NOVO local ou nome de arquivo (cuidado para não substituir os originais!).
12) Run recreate roles snippet. Something like:
13) Run recreate login script (doesn't do anything if logins were restored)
14) Stop SQL AGENT.
(Could restore Master here, we chickened out).
15) Attach mdf/ldf using script from above. a. If fail manually restore from bak using script from above.
16) Attempt Restore of Model
17) Ensure SQL Agent is stopped. Restore MSDB (link) a. If fails, need to re-create jobs + maintenance plan + mail configuration + operators
18) Open User To Login script...
19) Enable service broker to match original value SELECT name, is_broker_enabled FROM sys.databases;
20) Start SQL Agent
21) Set Parallelism threshold to original value
22) Adjust any database settings to their original values:
23) Check job ownership:
If the SQL Server Version had also been upgraded I don't believe the model and msdb databases could have been restored so jobs would have been lost due to https://support.microsoft.com/en-us/kb/264474
What's missing:
Nada está errado com nenhuma das abordagens em si - eu fiz as duas e ambos os resultados são tipicamente bons.
Se houver um problema com a abordagem de migração, não é técnico: é preguiça. Muitas vezes, acho que a razão pela qual uma empresa ainda não foi totalmente para a versão xxxx é porque eles escolheram uma migração swing e nunca conseguiram fazer o trabalho duro para se mudar completamente. Agora eles têm dois ou mais conjuntos de servidores em vez de um.