Recentemente, a Microsoft lançou o Service Pack 1 para o SQL Server 2012 e rapidamente deu continuidade à atualização cumulativa 1 para o Service Pack 1. das correções das atualizações cumulativas RTM 3 e 4. Como muitas pessoas esperaram - com base principalmente no viés especulativo neste momento - até mesmo começar a testar o SQL Server 2012 até o lançamento do Service Pack 1, pensei que poderia ser útil cobrir algumas dos cenários que você pode encontrar. Esta não é uma postagem estritamente relacionada ao desempenho, mas algumas das informações envolvem interrupções no serviço, que podem ou não afetar seus negócios, SLAs etc.
ATUALIZAÇÃO – A atualização cumulativa 2 do SQL Server 2012 Service Pack 1 (11.0.3339) foi lançada em 24/01/2013.
Se o SQL Server 2012 ainda não estiver instalado…
Ao instalar uma nova instância do SQL Server, você deseja executar o menor número de etapas possível. A configuração do SQL Server 2012 é muito melhor em relação ao slipstream de service packs e atualizações cumulativas do que o SQL Server 2008/2008 R2 (descrito por Peter Saddow aqui e aqui). Este método está obsoleto, mas ainda é suportado no SQL Server 2012. Portanto, enquanto você ainda pode usar o método antigo, se quiser:
D:\setup.exe /Action=Install /PCUSource=C:\SP1ExtractedFolder /CUSource=C:\CU1ExtractedFolder
O novo método, que você deve usar, é muito mais simples – e não requer que você extraia manualmente os pacotes usando o
/x argumento primeiro:D:\setup.exe /Action=Install /UpdateSource=C:\AllUpdatesFolder
Você só precisa colocar todas as atualizações relevantes na mesma pasta. Observe que qualquer atualização obtida com o nome de arquivo
[...]_zip.exe , você precisa extrair para obter o executável principal. Por exemplo, quando você baixa o Service Pack 1 e a Atualização Cumulativa 1 pela primeira vez, a pasta de download terá esta aparência:
Você precisa extrair
455715_intl_x64_zip.exe clicando duas vezes nele e escolhendo o caminho de saída (usando /x na linha de comando é válido, mas ignorado). Uma vez feito, a pasta deve ficar assim. (Nesse ponto, você pode excluir o 455715... file - embora, considerando o quão "compactado" ele é, eu tenho que me perguntar por que eles continuam a colocar este pacote em um arquivo de extração automática em primeiro lugar.) 
Agora, quando você executar a linha de comando acima, quando chegar à tela de atualizações do produto na configuração, verá que ela incluiu SP1 e CU1:
Bob Ward faz um trabalho muito bom ao descrever esse cenário com muito mais detalhes aqui:
Blog CSS:A instalação do SQL Server 2012 ficou mais inteligente…
Observe que você pode manter todos os seus Service Packs e Atualizações Cumulativas ao longo do tempo na mesma pasta - se você usar o
/UpdateSource argumento, a instalação do SQL Server será inteligente o suficiente para escolher o SP mais recente e sua CU mais recente, independentemente do que mais possa existir nessa pasta. Se o SQL Server 2012 já estiver instalado…
Novamente, todas essas informações se aplicam se você estiver instalando uma nova instância do SQL Server. Eu, por outro lado, tenho várias instâncias do SQL Server 2012 RTM que queria corrigir – e como não queria perder nenhuma das correções das atualizações cumulativas 3 e 4, queria aplicar o Service Pack 1 e atualização cumulativa 1. Eu esperava que a mesma inteligência do slipstream fosse incorporada ao executável de instalação do Service Pack 1, para que ele pudesse simplesmente incluir as atualizações CU1. Eu tentei o lógico:
C:\AllUpdatesFolder\SQLServer2012-SP1-KB2674319-x64-ENU.exe /UpdateSource=C:\AllUpdatesFolder
Mas isso acabou gerando o seguinte erro:
Para a bondade do mecanismo de pesquisa:
The setting 'UpdateSource' is not allowed when the value of setting 'ACTION' is 'Patch'. Error code 0x84B40005.
(E sim, tentei colocar a pasta de atualização CU1 extraída em um local diferente.)
Confirmei com a Microsoft que, embora o SP1 obviamente contenha parte do código e da lógica do setup.exe principal, ele não foi criado para permitir a incorporação de atualizações cumulativas. Em outras palavras, você não pode fazer o slipstream ao instalar um service pack, apenas ao instalar o produto principal.
Isso também significa que você precisará realizar a instalação em duas etapas . Abri uma nova sugestão do Connect, já que o slipstreaming é sem dúvida * mais * valioso durante a manutenção do que durante a instalação inicial:
Connect #774109:Permitir /UpdateSource para instaladores do Service Pack
Então, eu continuei a fazer isso em duas etapas. Instalei o Service Pack 1 e observei que nenhum arquivo estava em uso que pudesse exigir uma reinicialização:
E depois que o SP1 foi concluído, iniciei o instalador do SP1 CU1. Porém me deparei com este erro:
Portanto, não apenas tive que dar dois passos para aplicar esses patches, mas também tive que reiniciar no meio. Procurei nos arquivos de log de cada instalação (
Detail.txt ) e posso ver que, quando executei o SP1, não havia indicação de que o Windows estava esperando uma reinicialização:(07) 2012-12-12 06:46:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=True
Mas quando executei o CU1 e obtive o erro, apenas alguns minutos após a conclusão do SP1, vi no novo
Detail.txt que agora o Windows * estava * esperando uma reinicialização:(07) 2012-12-12 06:53:38 Slp: Windows Update requires a reboot (07) 2012-12-12 06:53:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=False
ATUALIZAÇÃO:Graças a Shau Phang da Microsoft, descobrimos em
%SystemRoot%\WindowsUpdate.log que uma atualização automática do Windows foi iniciada após o início do SP1 e concluída antes de eu iniciar a atualização do CU. Presumo que seja porque acordei o computador e mergulhei imediatamente para iniciar a instalação do service pack; a verificação "deve reiniciar" deve ter sido acionada no meio. Eu aceitaria total responsabilidade por isso se tivesse acabado de ativar o Windows Update e aceitado o padrão; mas eu não fiz. Aqui estão minhas configurações:
Portanto, tenha cuidado lá fora.
Conclusão
A moral da história é que, se você ainda não instalou o SQL Server 2012, fazer o slipstream para obter a atualização mais recente em uma ação – independentemente de quando você fizer isso e de quais atualizações estão disponíveis no momento – vai ser simples e indolor.
Se você já tem uma instância instalada, caso em que a interrupção do serviço e o tempo de inatividade quase sempre serão um problema mais crítico do que durante uma nova instalação, você precisará abordar sua metodologia de correção com cuidado e certificar-se de que sua janela de manutenção permitirá para uma reinicialização do servidor, caso seja necessário. Isso também significa:esteja ciente das configurações do Windows Update e se alguma atualização foi instalada desde a última reinicialização.
Se você acha que essa é uma questão importante, vote nesses itens do Connect e, mais importante, comente sobre como o cenário atual pode afetar o seu negócio.
