Estimar quanto tempo o processo de atualização levará e o espaço necessário (SharePoint Server 2010)
Aplica-se a: SharePoint Server 2010
Tópico modificado em: 2016-11-30
Uma parte importante do planejamento da atualização do Microsoft Office SharePoint Server 2007 para o Microsoft SharePoint Server 2010 consiste em determinar o tempo que o processo de atualização levará e o espaço de armazenamento que será necessário. Cada ambiente é exclusivo e inclui diferentes recursos de hardware e diferentes características de site. O espaço e o tempo necessários para executar uma atualização variarão bastante dependendo do ambiente. A melhor maneira de estimar esses fatores é executar uma atualização de avaliação e, depois, examinar o espaço e o tempo que foram necessários. Para obter mais informações sobre como executar uma atualização de avaliação, consulte Usar uma atualização de avaliação para encontrar possíveis problemas (SharePoint Server 2010).
Neste artigo:
Estimar o espaço necessário para a atualização
Estimar a duração da atualização
Estimar o espaço necessário para a atualização
Os bancos de dados podem ser expandidos durante as abordagens de atualização in-loco e de atualização com anexação de banco de dados. Além disso, muitas transações ocorrem enquanto o processo de atualização é executado; portanto, você deve garantir que os arquivos de log tenham espaço para se expandir, de modo a acomodar as alterações que ocorrerem. É necessário planejar o crescimento nos bancos de dados e nos arquivos de log.
Ao planejar a atualização, verifique se o ambiente atual segue as práticas recomendadas de armazenamento para o Office SharePoint Server 2007, de modo a obter o melhor desempenho e a melhor experiência possíveis durante a atualização. Para obter mais informações, consulte o artigo sobre recomendações para armazenamento físico (Office SharePoint Server). Examine também as melhores práticas para o SharePoint Server 2010 e faça todos os ajustes necessários no ambiente atualizado.
Devido às alterações em estruturas de tabelas na nova versão, os bancos de dados crescem temporariamente enquanto os dados são reorganizados. Esse espaço pode ser recuperado após a atualização, mas você deve garantir que exista espaço suficiente para os bancos de dados se expandirem em até 50% em relação a seus tamanhos atuais durante uma atualização in-loco ou com anexação de banco de dados (lembre-se de que, após a atualização, é possível reduzir novamente o banco de dados para recuperar grande parte desse espaço). Verifique também se há espaço nos servidores de bancos de dados para comportar o crescimento típico dos bancos de dados com o passar do tempo. Para saber o tamanho atual de seus bancos de dados, use o Enterprise Manager no Microsoft SQL Server. Além do espaço para bancos de dados, também é preciso ter espaço para os seguintes itens:
Os bancos de dados temporários. Verifique se há espaço suficiente no banco de dados para permitir o crescimento rápido dos bancos de dados temporários. Se o espaço for insuficiente, o processo de atualização poderá atingir o tempo limite e haverá falha na atualização.
Arquivos de log de atualização.
Arquivos de logs de transações para os bancos de dados. Esses arquivos de log devem crescer rapidamente para acomodar a quantidade de mudanças que ocorrem nos bancos de dados.
Observação
Em ambientes muito grandes, existe a possibilidade de que a taxa de crescimento padrão para os arquivos de logs de transações (10 %) não seja suficiente para acompanhar o processo de atualização; isso pode causar um tempo limite. Novamente, uma atualização de avaliação é a melhor forma de determinar se os arquivos de logs de transações podem acompanhar o processo de atualização. Se o seu ambiente for muito grande ou se o processo tiver atingido o tempo limite durante a atualização de avaliação, considere a possibilidade de expandir os arquivos de logs de transações do SQL Server com antecedência, de modo a garantir espaço para o número de transações a serem processadas. Para obter mais informações sobre como expandir os logs de transações do SQL Server, consulte o artigo sobre expansão de um banco de dados (SQL Server 2005) (https://go.microsoft.com/fwlink/?linkid=182619&clcid=0x416) ou o artigo sobre expansão de um banco de dados (SQL Server 2008) (https://go.microsoft.com/fwlink/?linkid=182620&clcid=0x416).
Estimar a duração da atualização
Com as estimativas de espaço em disco em mãos e já tendo realizado alguns testes, agora você pode fazer uma estimativa bruta da duração real do processo de atualização. Os tempos de atualização variam bastante entre os ambientes. O desempenho de uma atualização depende muito do hardware que está sendo usado, da complexidade dos sites e das características específicas da implementação. Por exemplo: se você tiver muitas bibliotecas de documentos grandes, elas poderão demorar mais para serem atualizadas do que um site mais simples.
Os fatores que influenciam o desempenho são descritos na tabela a seguir.
| Fatores de conteúdo | Fatores de hardware |
|---|---|
O número de:
Além do tamanho geral do próprio banco de dados. |
|
A forma como os dados são estruturados pode afetar o tempo necessário para a sua atualização. Por exemplo, 10.000 listas com 10 itens cada terão um tempo de atualização maior do que 10 listas com 10.000 itens. As ações necessárias para atualizar a infraestrutura de lista devem ser realizadas para cada lista, independentemente do número de itens. Portanto, mais listas equivalem a mais ações. O mesmo vale para a maioria dos itens na coluna "Fatores de conteúdo" da tabela acima.
A estrutura do seu hardware também pode afetar bastante o desempenho. Em geral, o desempenho do servidor de banco de dados é mais importante do que o desempenho do servidor Web. No entanto, problemas de conectividade ou hardware com potência insuficiente em uma dessas camadas podem afetar significativamente o desempenho da atualização.
A abordagem de atualização escolhida também fará uma grande diferença para a duração do processo. A atualização com anexação de banco de dados é o método mais rápido (porém, as etapas de pré-atualização e pós-atualização dessa abordagem demoram mais do que as da atualização in-loco). Uma atualização in-loco demora um pouco mais porque você atualiza o ambiente, além dos sites, mas não há tantas etapas de pré-atualização e pós-atualização nessa abordagem.
A melhor forma de estimar o tempo geral é fazer uma atualização de avaliação de uma pequena parte dos dados ou de todos eles e, depois, examinar os arquivos de log de atualização. Os arquivos de log contêm a duração da atualização — procure a indicação de Tempo Total Decorrido na parte inferior do arquivo de log de atualização. Use essa indicação de tempo para projetar uma duração para o conjunto completo de conteúdo. Você também pode usar os arquivos de log para verificar o andamento do processo de atualização. O arquivo upgrade.log está localizado em %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS.
A estimativa a que se chega com base na atualização de avaliação refere-se ao processo de atualização real dos dados; ela não inclui todas as etapas que você precisa executar antes e depois dessa etapa, que podem levar mais tempo do que a própria atualização de dados. Ao estimar a duração da atualização, além do tempo necessário para o processamento de dados, estime também a duração das atividades das fases de pré-atualização e pós-atualização.
Para as etapas de pré-atualização, considere os seguintes fatores:
Criação de elementos personalizados A atualização de Web Parts ou a recriação de modelos personalizados para tirar proveito de novos recursos levarão algum tempo. O processo de criação de elementos personalizados deve começar cedo, durante a fase de avaliação do projeto.
Backup dos bancos de dados Para a atualização in-loco, você deve realizar um backup completo — não um backup diferencial — de todo o ambiente, de modo a garantir a recuperação na possibilidade remota de que haja falha na atualização e você precise recriar o farm de servidores. Em grandes ambientes, essa etapa pode levar muito tempo. Especificamente, se você estiver fazendo o backup em um local de rede, problemas de latência de rede poderão reduzir a velocidade do processo.
Para as etapas de pós-atualização, considere os seguintes fatores:
Verificação de sites e realização de alterações Reserve tempo suficiente para que os usuários validem seus sites após a atualização. Isso pode levar vários dias. Para obter mais informações, consulte Verificar a atualização e revisar os sites atualizados (Office SharePoint Server).
Criação de aplicativos de serviço e configuração de serviços Essa etapa é aplicável somente durante uma atualização com anexação de banco de dados (em uma atualização in-loco, os aplicativos de serviço são criados como parte do processo de atualização). A criação de aplicativos de serviço e a configuração de serviços não levam muito tempo; no entanto, se for necessário contatar um administrador de banco de dados para pré-criar os bancos de dados, você poderá precisar de um dia ou dois para concluir o processo.
Convertendo propriedades de perfil em dados de taxonomia e atualizando o repositório de fotos para serviços de Perfil de Usuário Você deve converter propriedades de perfil de usuário que incluam listas de opções para usar recursos de taxonomia fornecidos pelo serviço de Metadados Gerenciados. Dependendo do número de perfis de usuário no ambiente, essas etapas poderão adicionar uma ou mais horas ao processo de atualização.
Executando um rastreamento de pessoas Em grandes organizações, esta etapa pode durar mais de 24 horas.
Executando um rastreamento de pesquisa em todo o conteúdo Em grandes sites, esta etapa pode demorar mais de 24 horas.
Outros fatores do ambiente também podem contribuir para aumentar o tempo de atualização, como:
Bibliotecas de documentos muito grandes Uma biblioteca com mais de 250.000 documentos, todos na raiz da biblioteca (não em pastas) levará um longo tempo para ser atualizada, e a atualização talvez não tenha êxito. Se você adotar as diretrizes do Microsoft Office SharePoint Server 2007 para usar pastas para dividir grandes bibliotecas de documentos, isso poderá ajudá-lo a gerenciar o tamanho da biblioteca. Por exemplo, se você reorganizar a mesma biblioteca de documentos para que os 250.000 documentos sejam divididos em 125 pastas, ela deverá ser atualizada mais facilmente.
Bancos de dados muito grandes Bancos de dados com mais de 100 GB podem levar muito tempo para serem atualizados.
Observação
Se você tiver bancos de dados de conteúdo com mais de 100 GB e que incluam tipos de sites mistos (como Meus Sites e sites de equipes, juntamente com sites publicados), antes de fazer a atualização, é recomendável dividi-los em bancos de dados menores que contenham um tipo de dados consistente. Além de demorarem mais para serem atualizados, bancos de dados maiores dificultam a recuperação caso a atualização não seja concluída com êxito.
Você pode usar as operações mergecontentdbs ou backup e restore de Stsadm.exe para mover sites entre bancos de dados. Para obter mais informações, consulte o artigo sobre Mergecontentdbs: operação do Stsadm (Office SharePoint Server) e o artigo sobre backup e restauração: operações do Stsadm (Office SharePoint Server).Se você tiver um banco de dados muito grande (com mais de 100 GB) que não possa ser dividido porque a maior parte do conteúdo está em um único conjunto de sites, convém reconsiderar sua abordagem de atualização. Uma abordagem de atualização com anexação de banco de dados é mais difícil de ser executada com bancos de dados muito grandes, pois o backup e a restauração destes são problemáticos.
Aviso
Verifique se você está seguindo as diretrizes de planejamento de capacidade das versões antiga e nova antes de tentar fazer a atualização. Se você tiver excedido as diretrizes de desempenho ideal, o processo de atualização poderá demorar mais ou não ser concluído com êxito (por exemplo, o processo pode atingir o tempo limite repetidamente na mesma grande biblioteca de documentos). Se sua implantação não atender às diretrizes de capacidade recomendadas, verifique se é necessário tomar alguma providência para atendê-las antes de tentar fazer a atualização. Novamente, uma atualização de avaliação pode ajudá-lo a tomar a decisão.
Requisitos de comunicações
É necessário notificar os usuários e a equipe sobre o cronograma de atualização e lhes dar tempo suficiente para concluírem suas tarefas. Para obter mais informações, consulte Criar um plano de comunicação (SharePoint Server 2010)
Gerenciando alertas e alarmes do System Center
Você precisa monitorar o desempenho do sistema durante a atualização, mas não precisa monitorar recursos específicos. Pause todos os alarmes e alertas desnecessários do Microsoft Systems Center Operations Manager ou do Microsoft Operations Manager e reative-os após a atualização.
Ativando/desativando o espelhamento de SQL e o envio de logs
Você deve desativar o espelhamento e o envio de logs antes do processo de atualização e reativá-los depois que comprovar a execução correta do ambiente após a atualização. Convém não executar o espelhamento nem o envio de logs durante a atualização, pois isso gera carga adicional para os servidores que executam o SQL Server e desperdiça recursos com o espelhamento ou o envio de dados temporários.
Teste seu processo de atualização para saber quanto tempo ele pode levar. Em seguida, crie um cronograma para as operações de atualização e teste-o para determinar a linha do tempo. Inclua o tempo necessário para realizar as etapas de pré-atualização e pós-atualização na linha do tempo de operações: se forem necessárias cinco horas para fazer o backup do ambiente antes de começar, inclua esse tempo na janela de interrupção. Inclua também tempo de reserva, caso seja necessário restaurar ou recuperar o ambiente — você precisa determinar as linhas do tempo de interrupção planejada (caso realista) e de interrupção de emergência (a pior das hipóteses).