Estimar a duração do processo de atualização e o espaço necessário (SharePoint Foundation 2010)

  • Artigo

 

Aplica-se a: SharePoint Foundation 2010

Tópico modificado em: 2016-11-30

Uma parte importante do planejamento da sua atualização do Windows SharePoint Services 3.0 para o Microsoft SharePoint Foundation 2010 é determinar quanto tempo o processo de atualização levará e quanto espaço de armazenamento 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 a execução de uma atualização irão variar bastante dependendo do seu ambiente. A melhor maneira de estimar esses fatores é executar uma atualização de avaliação e examinar o espaço e o tempo utilizados. 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 Foundation 2010).

Neste artigo:

  • Estimar o espaço de que você precisa para a atualização

  • Estimar a duração da atualização

Estimar o espaço de que você precisa para a atualização

Nas abordagens de atualização in-loco e com anexação de banco de dados, os bancos de dados poderão se expandir durante a atualização. Além disso, existem muitas transações acontecendo durante o processo de atualização; portanto, é necessário verificar se os arquivos de log terão espaço para acomodar as alterações que estiverem acontecendo. É preciso planejar o crescimento dos bancos de dados e dos arquivos de log.

Ao planejar a atualização, verifique se o seu ambiente atual segue as práticas recomendadas de armazenamento para o Windows SharePoint Services 3.0, para que você tenha o maior desempenho e a melhor experiência possíveis durante a atualização. Para obter mais informações, consulte o artigo de recomendações sobre armazenamento físico (Office SharePoint Server). Também convém rever as práticas recomendadas para o SharePoint Foundation 2010 e fazer todos os ajustes necessários no seu 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 tempo limite do processo de atualização poderá se esgotar e haverá falha na atualização.

  • Os arquivos de log da atualização.

  • Os arquivos de log de transação para os bancos de dados. Esses arquivos de log devem crescer rapidamente para acomodar o número de alterações ocorrendo nos bancos de dados.

    Observação

    Em ambientes muito grandes, existe uma possibilidade de que a taxa de crescimento padrão para os arquivos de log de transação (10%) não seja suficiente para acompanhar o processo de atualização; isso pode causar expiração de tempo limite. Novamente, uma atualização de avaliação é a melhor forma de determinar se os arquivos de log de transação podem acompanhar o processo de atualização. Se o seu ambiente for muito grande ou se o processo atingiu o tempo limite durante a atualização de avaliação, considere a expansão prévia dos arquivos de log de transação do SQL Server para garantir espaço para o número de transações que terão de ser processadas. Para obter mais informações sobre como expandir os logs de transação 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 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 a estimativa do espaço em disco em mãos e alguns testes realizados, agora você pode calcular uma estimativa aproximada de quanto tempo o processo de atualização real levará. Os tempos de atualização variam muito entre os ambientes. O desempenho de uma atualização depende bastante do hardware que está sendo usado, da complexidade dos sites e das características específicas da sua implementação. Por exemplo, se você tiver muitas bibliotecas de documentos grandes, elas poderão levar mais tempo para serem atualizadas do que um site mais simples.

Fatores que influenciam o desempenho estão descritos na tabela a seguir.

Fatores de conteúdo Fatores de hardware

O número de:

  • Conjuntos de sites

  • Subwebs

  • Listas

  • Versões de documento (número e tamanho)

  • Documentos

  • Links

Mais o tamanho geral do próprio banco de dados.

  • Entrada/saída de disco por segundo do SQL Server

  • Layout de banco de dados do SQL Server para disco

  • Otimizações de banco de dados temporárias do SQL Server

  • Características de memória e CPU do SQL Server

  • Características de memória e CPU do servidor Web

  • Largura de banda e latência da rede

A forma como os dados estã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 ter um grande efeito no 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 na duração do processo. A execução de uma atualização com anexação de banco de dados é o método mais rápido (no entanto, as etapas de pré-atualização e de pós-atualização para essa abordagem são mais demoradas do que as da atualização in-loco). Uma atualização in-loco demora um pouco mais porque você está atualizando o ambiente além dos sites, mas não tem tantas etapas de pré-atualização e de pós-atualização.

A melhor forma de estimar o tempo total é fazer uma atualização de avaliação de uma pequena parte dos dados e examinar os arquivos de log de atualização. Os arquivos de log contêm a duração da sua atualização — procure Tempo Total Decorrido na parte inferior do arquivo de log da atualização. Use esse tempo para projetar uma duração para todo o seu conteúdo. Você também pode usar os arquivos de log para verificar o andamento durante o processo de atualização. O arquivo upgrade.log está localizado em %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS.

A estimativa encontrada com base na sua atualização de avaliação serve para o processo de atualização real dos dados; ela não inclui todas as etapas que deverão ser executadas antes e após essa etapa, o que pode levar mais tempo do que a própria atualização dos dados. Ao estimar a duração da atualização, além do tempo necessário para que os dados sejam processados, você também terá de estimar a duração das atividades durante as fases anteriores e posteriores à atualização.

Para as etapas de pré-atualização, considere os fatores a seguir:

  • Criando elementos personalizados   A atualização de Web Parts ou a recriação de modelos personalizados para tirar proveito de novos recursos leva algum tempo. O processo de criação de elementos personalizados deve começar cedo, durante a fase de avaliação de seu projeto.

  • Fazendo backup dos bancos de dados   Para a atualização in-loco, é preciso executar um backup completo — e não um backup diferencial — de todo o seu ambiente para garantir que você poderá se recuperar na remota possibilidade de uma falha na atualização, com a consequente recriação do seu farm de servidores. Para ambientes grandes, essa etapa pode levar um tempo significativo. Em particular, se você estiver fazendo backup em um local de rede, problemas de latência de rede poderão tornar esse processo mais lento.

Para as etapas de pós-atualização, considere os fatores a seguir:

Fatores adicionais em seu ambiente também podem contribuir para atualizações que levam mais tempo, incluindo o seguinte:

  • Bibliotecas de documentos muito grandes   Uma biblioteca de documentos com mais de 250.000 documentos, todos na raiz (e não em pastas), levará um longo tempo para ser atualizada, e a atualização talvez não seja bem-sucedida. Seguir as diretrizes do Windows SharePoint Services 3.0 para o uso de pastas na divisão de grandes bibliotecas de documentos pode 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ê tem bancos de dados de conteúdo com mais de 100 GB, convém dividi-los em bancos de dados menores antes de executar a atualização. Bancos de dados maiores não só levam mais tempo para serem atualizados, como também podem dificultar a recuperação se a atualização não for concluída com êxito.
    Você pode usar mergecontentdbs ou as operações de backup e restauração do Stsadm.exe para mover sites entre bancos de dados. Para obter mais informações, consulte os artigos sobre Mergecontentdbs: operação do Stsadm (Windows SharePoint Services) e backup e restauração: operações do Stsadm (Windows SharePoint Services).

    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 da versão anterior e da nova antes de tentar fazer a atualização. Se você excedeu as diretrizes para melhor desempenho, o processo de atualização poderá levar mais tempo ou não ser concluído com êxito (por exemplo, o processo pode atingir o tempo limite repetidamente na mesma biblioteca grande de documentos). Se sua implantação não cumprir as diretrizes de capacidade recomendadas, verifique se você precisa tomar alguma providência para cumpri-las antes de tentar fazer a atualização. Novamente, um teste de atualização pode ajudá-lo a tomar sua decisão.

  • Requisitos de comunicações

    É necessário notificar os usuários e a sua equipe sobre o cronograma de atualizações e lhes dar tempo suficiente para concluírem suas tarefas. Para obter mais informações, consulte Criar um plano de comunicação (SharePoint Foundation 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 da atualização e reativá-los depois de garantir que o ambiente esteja em execução corretamente ao final desse processo. Convém não executar o espelhamento ou o envio de logs durante a atualização, pois isso gera carga adicional nos servidores que executam o SQL Server e também desperdiça recursos com o espelhamento ou o envio de dados temporários

Teste seu processo de atualização para descobrir quanto tempo ele pode demorar e depois crie um cronograma para suas operações de atualização e teste-o para determinar a programação. Você deve incluir o tempo necessário para realizar as etapas de pré e pós-atualização na programação de operações: se forem necessárias 5 horas para fazer o backup do ambiente antes de você começar, inclua esse tempo na sua janela de interrupção. Inclua também um tempo de reserva caso seja necessário restaurar ou recuperar o ambiente — você precisa determinar as programações de interrupção planejada (caso realista) e de interrupção de emergência (pior caso).