Usar uma atualização de avaliação para encontrar possíveis problemas (SharePoint Foundation 2010)

 

Aplica-se a: SharePoint Foundation 2010

Tópico modificado em: 2016-11-30

Antes de iniciar o processo de atualização do Windows SharePoint Services 3.0 para o Microsoft SharePoint Foundation 2010, teste o processo para verificar se você sabe exatamente o que precisa fazer para ter êxito em uma atualização. Ao utilizar uma atualização de avaliação para testar o processo, você poderá descobrir:

  • Quais são as personalizações em seu ambiente, para que você possa planejar a forma de lidar com elas durante a atualização.

  • Se você deve atualizar o seu hardware para fazer com que a atualização seja executada com mais eficiência e rapidez.

  • O intervalo da sua atualização, ou quanto tempo ela levará em seu ambiente.

  • O que você precisa planejar, operacionalmente — por exemplo, recursos à sua disposição.

Além disso, você pode usar a atualização de verificação para conhecer melhor as ferramentas de atualização e o próprio processo, para que você saiba o que esperar quando passar pelo processo real. Por meio de testes, é possível descobrir:

  • Que casos especiais se aplicam ao seu ambiente e que abordagem de atualização será a mais eficiente para você?

  • Como é a aparência da interface do usuário de atualização? Como você sabe quando concluiu uma fase e está mudando para outra?

  • Onde estão os arquivos de log e como você os lê? Quais são as informações que eles oferecem?

  • Que técnicas você pode usar para reduzir o tempo de inatividade?

Este artigo oferece as etapas básicas da atualização de teste e oferece recomendações para a revisão dos resultados e o ajuste dos seus planos de atualização com base no que você aprendeu durante os testes.

Neste artigo:

  • Configurar um ambiente de teste

  • Identificar e instalar personalizações

  • Copiar os dados reais no ambiente de teste e tentar a atualização

  • Revisar os resultados

  • Ajustar seu planejamento e tentar novamente

Além disso, os seguintes recursos poderão ser úteis quando você testar o processo de atualização:

Configurar um ambiente de teste

Você pode usar hardware virtual ou físico para testar o processo de atualização. Todos os ambientes são exclusivos e, portanto, não há diretrizes gerais para a duração da atualização e o grau de dificuldade da atualização de uma determinada personalização. A melhor maneira de avaliar como será a sua atualização é executar uma série de atualizações de verificação.

Quando você criar o seu ambiente de teste:

  • Faça com que o seu farm de teste seja o mais similar possível ao seu farm real — por exemplo, hardware, software e espaço disponível.

  • Use as mesmas URLs do seu farm de teste no seu farm real. (Caso contrário, você perderá tempo com o diagnóstico de problemas relacionados às URLs que não aparecerão na atualização real.)

  • Lembre-se de transferir todas as suas configurações e personalizações para o ambiente de teste. A seção Identificar e instalar personalizações descreve como coletar essas informações.

Usando um ambiente de teste virtual

Ao executar um teste em um ambiente virtual, você não precisa de muito hardware. É possível replicar seu ambiente usando apenas dois servidores com o Hyper-V em execução. Um servidor terá as imagens dos servidores Web front-end e dos servidores de aplicativos, enquanto o outro terá as imagens dos servidores de banco de dados.

Ambiente de teste virtual para atualização de avaliação

Usando um ambiente de teste físico

Ao executar um teste em um ambiente físico, é necessário replicar todo o seu ambiente de farm de servidores da forma mais parecida possível. Se você simplificar muito o número de servidores Web front-end, servidores de aplicativos ou servidores de banco de dados, não terá uma estimativa confiável do tempo de duração do processo de atualização e talvez não possa especificar as possíveis complicações inerentes às interações entre servidores de mesma função (por exemplo, transações do SQL Server). Se tiver vários servidores em uma função no farm original, use pelo menos dois servidores dessa função no farm de teste para verificar esses problemas.

Farm de teste físico para uma atualização de avaliação

Ambientes de teste adicionais para atualização com anexação de banco de dados

Se estiver usando a abordagem de atualização com anexação de banco de dados, talvez seja necessário criar um ambiente de teste adicional: um farm de servidores simples que execute o Windows SharePoint Services 3.0, para que você possa usá-lo para executar o verificador de pré-atualização antes de tentar atualizar os dados.

Você pode evitar essa etapa executando o verificador de pré-atualização no farm de produção existente.

Identificar e instalar personalizações

Para obter um processo de teste preciso, localize todas as personalizações do seu ambiente atual e copie-as para o ambiente de teste. Para obter mais informações sobre os tipos de personalizações que precisam ser identificadas, consulte Determinar como lidar com personalizações (SharePoint Foundation 2010).

  • Use o verificador de pré-atualização para identificar definições de site, modelos de site e recursos do ambiente.

    O verificador de pré-atualização percorre cada conjunto de sites e gera um relatório sobre o estado de cada um. Ele também salva informações de definição de cada lista. Você pode analisar os relatórios para localizar problemas e solucioná-los antes de iniciar o processo de atualização. Ao contrário da ferramenta de verificação de pré-atualização do Windows SharePoint Services 3.0, o verificador de pré-atualização é uma ferramenta somente leitura que não altera seus sites. Para obter mais informações sobre essa ferramenta e etapas para executá-la, consulte o artigo sobre exame e relatório de pré-atualização para versões futuras (Windows SharePoint Services) e Executar o verificador de pré-atualização (SharePoint Foundation 2010).

  • Use a operação Stsadm –o enumallwebs em todos os bancos de dados de conteúdo do ambiente do Windows SharePoint Services 3.0 para identificar personalizações específicas em subsites. Essa operação foi apresentada pela primeira vez no Windows SharePoint Services 3.0 com Service Pack 2 (SP2). Para obter mais informações, consulte Enumallwebs: operação do Stsadm (Windows SharePoint Services).

  • Use uma ferramenta como WinDiff (fornecida com a maioria dos sistemas operacionais Windows) para comparar os servidores do seu ambiente de produção com os servidores do farm de teste. É possível usar essa ferramenta para ver quais arquivos existem nos servidores e as diferenças entre eles.

  • Verifique se há alterações nos arquivos web.config e se há controles personalizados no elemento SafeControls.

  • Use a Ferramenta de Diagnóstico do SharePoint (SPDiag) para localizar soluções implantadas. Para obter mais informações, consulte o artigo sobre a Ferramenta de Diagnóstico do SharePoint (SPDiag).

  • Crie uma lista de todas as personalizações encontradas. Identifique a origem das personalizações, se possível. Por exemplo, há suplementos de terceiros ou modelos que tenham sido personalizados internamente? Depois de identificar a origem, você poderá verificar se há versões atualizadas das personalizações. Existe uma planilha disponível que poderá ser preenchida com as informações sobre o seu ambiente, com base nos dados encontrados nos resultados do verificador de pré-atualização e na pesquisa de suas personalizações. Baixe a planilha de https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x416 e personalize-a para que atenda às suas necessidades.

Dica

Quem você contata para obter informações sobre as personalizações que não criou?

  • Contate a Microsoft se tiver problemas com um modelo baixado do site da Microsoft (por exemplo, modelos de aplicativo do Windows SharePoint Services 3,0).

  • Contate o fornecedor da solução de terceiros se tiver problemas com um modelo ou componente fornecido para a versão anterior. É possível que haja uma versão atualizada.

Após identificar todas as personalizações, copie-as para os servidores adequados do farm de teste. Você pode usar o cmdlet do Windows PowerShell, test-spcontentdatabase, antes de anexar um banco de dados ao SharePoint Foundation 2010 para determinar se alguma personalização está faltando no ambiente. Execute esse comando para cada banco de dados após a restauração dos bancos de dados no seu servidor de banco de dados, mas antes de fazer a atualização. Observe que esse cmdlet é executado silenciosamente — ele não retornará nenhuma saída, a menos que ocorra um erro.

Copiar os dados reais no ambiente de teste e tentar a atualização

Você só atingirá os objetivos do teste se usar dados reais. Os seguintes métodos podem ser usados para criar uma cópia dos dados:

Não há maneira melhor de identificar o que pode surgir durante uma atualização do que a execução de um teste em uma cópia de todos os seus dados. Entretanto, isso nem sempre é uma opção viável para o teste inicial. Você pode dividir o teste em fases e testar um banco de dados de cada vez (caso os bancos de dados sejam grandes) para garantir que tudo o que for exclusivo no conjunto de dados será testado. Ou pode montar um subconjunto de dados de sites representativos no seu ambiente. Se quiser testar primeiro com um subconjunto de dados, verifique se o subconjunto tem estas características:

  • O subconjunto de dados contém sites que são típicos dos sites que você aceita no seu ambiente.

  • O tamanho e a complexidade do subconjunto de dados são muito semelhantes ao tamanho e à complexidade reais do seu ambiente.

Importante

O teste de um subconjunto de dados não produz um parâmetro de comparação válido sobre a quantidade de tempo que será necessária para processar todo o volume de dados do seu ambiente.

Depois de copiar os dados, faça uma primeira experiência do processo de atualização para ver o que acontece. Esta é apenas uma sessão preliminar.

Tentar a atualização in-loco

Se quiser tentar uma abordagem de atualização in-loco, use as etapas a seguir para testar o processo de atualização:

  1. Crie um backup do seu farm.

  2. Restaure o backup do farm de teste.

    Para obter mais informações, consulte Fazer backup e restaurar o farm inteiro (tecnologia Windows SharePoint Services 3.0).

  3. Execute o verificador de pré-atualização. Anote todos os problemas detectados. Convém solucionar esses problemas no seu ambiente original antes de executar a atualização real do farm de produção. Para obter mais informações, consulte Executar o verificador de pré-atualização (SharePoint Foundation 2010).

  4. Siga as etapas indicadas em Executar uma atualização in-loco (SharePoint Foundation 2010) para tentar a atualização in-loco.

  5. Revise os resultados.

Tentar uma atualização com anexação de banco de dados

  1. Crie um backup do SQL Server dos seus bancos de dados de conteúdo.

  2. Use o SQL Server para restaurar os backups no farm de teste de servidor único e anexe os bancos de dados de conteúdo a esse ambiente.

    Para obter mais informações, consulte Fazer backup e restaurar bancos de dados de conteúdo (Windows SharePoint Services 3.0).

  3. Execute o verificador de pré-atualização. Anote todos os problemas detectados. Convém solucionar esses problemas e fazer essas alterações no seu ambiente original antes de executar a atualização real do farm de produção. Para obter mais informações, consulte Executar o verificador de pré-atualização (SharePoint Foundation 2010).

  4. Execute as etapas indicadas em Preparar o novo ambiente do SharePoint Foundation para configurar o ambiente de teste para uma atualização com anexação de banco de dados.

  5. Siga as etapas em Anexar bancos de dados e atualizar para o SharePoint Foundation 2010 para tentar o processo de atualização com anexação de banco de dados.

Revisar os resultados

Depois de concluída a atualização de teste, você poderá revisar os resultados e rever seu planejamento. Analise os arquivos de log, examine os sites atualizados e verifique suas personalizações. Como a atualização funcionou no seu ambiente? O que você detectou? O que precisa ser repensado no seu planejamento de atualização?

Revisar os arquivos de log

Revise os seguintes arquivos de log:

  • Arquivo de log do verificador de pré-atualização.

    Os arquivos de log do verificador de pré-atualização (stsadm -o preupgradecheck) estão localizados em %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS. Os arquivos de log são nomeados neste formato: PreUpgradeCheck_AAAAMMDD-HHMMSS-SSS-random-number.log, onde AAAAMMDD é a data e HHMMSS-SSS é a hora (formato de relógio 24 horas, com minutos, segundos e milissegundos), e o número aleatório é usado para diferenciar possíveis tentativas simultâneas de execução do verificador de pré-atualização.

  • Arquivo de log do Assistente de Configuração de Produtos do SharePoint (Psconfig.exe) (gerado quando você executa este assistente como parte da sua tentativa de atualização in-loco).

    Os arquivos de log PSCDiagnostics estão localizados em %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS.

  • Arquivo de log atualizado e arquivo de log de erro de atualização (gerados quando você executa a atualização).

    O arquivo de log de atualização (.log) e o arquivo de log de erro de atualização (.err) estão localizados em %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. Os arquivos de log são nomeados neste formato: Upgrade-AAAAMMDD-HHMMSS-SSS.log, onde AAAAMMDD é a data e HHMMSS-SSS é a hora (formato de relógio 24 horas, com minutos, segundos e milissegundos).

Para analisar os arquivos de log de modo a localizar e solucionar problemas, comece na parte superior dos arquivos. Erros ou avisos poderão se repetir se eles ocorrerem em vários conjuntos de sites do ambiente ou se, juntos, bloquearem o processo de atualização. Por exemplo, se você não puder se conectar ao banco de dados de configuração, o processo de atualização tentará (e falhará) várias vezes, e essas tentativas serão listadas no arquivo de log.

Pesquise ou verifique visualmente as seguintes entradas:

  • Atualização concluída SPFarm Name= <Nome do Banco de Dados de Configuração>

  • Sessão de atualização in-loco concluída. Objeto raiz = SPFarm= <Nome do Banco de Dados de Configuração> , recursivo = True. 0 erros e 0 avisos encontrados.

Se você encontrar essas entradas, significa que a instalação teve êxito.

Se não encontrar as entradas da etapa anterior, identifique os problemas específicos que possivelmente contribuíram para a falha, pesquisando ou verificando visualmente os seguintes termos do arquivo Upgrade.log:

  • Pesquise ERROR nos arquivos de log para localizar todas as falhas (por exemplo, componentes com falhas ou conexões defeituosas de bancos de dados).

  • Pesquise WARNING para localizar problemas, como recursos ou componentes que estejam faltando.

Para localizar os problemas de atualização, um analisador de log pode ser bastante útil para a execução de consultas nos arquivos de log.

Reiniciar a atualização, se necessário

Durante uma atualização com anexação de banco de dados, todos os sites que não puderem ser atualizados serão ignorados. Durante uma atualização in-loco, se o servidor for reiniciado ou se a atualização falhar, você precisará recomeçar o processo de atualização para atualizar o restante dos sites.

Para ver se algum site foi perdido ou ignorado durante a atualização, execute a operação Stsadm stsadm -o localupgradestatus em cada servidor Web front-end do farm de servidores do SharePoint Foundation 2010. Para obter mais informações sobre essa operação, consulte Localupgradestatus: operação Stsadm (Windows SharePoint Services).

Se a atualização tiver ignorado algum conjunto de sites, você poderá reiniciar o processo de atualização do banco de dados que contém esse conjunto de sites em questão usando o seguinte cmdlet do Windows PowerShell: upgrade-spcontentdatabase -id <GUID>. Para obter mais informações sobre esse cmdlet, consulte Upgrade-SPContentDatabase.

Para obter mais informações, consulte Continuar a atualização (SharePoint Foundation 2010).

Revisar sites atualizados

Examine os sites atualizados para identificar problemas que precisam ser solucionados antes da execução do processo de atualização no seu ambiente de produção. Para obter mais informações sobre o que analisar especificamente, consulte Verificar a atualização e examinar os sites atualizados (SharePoint Foundation 2010).

Ajustar seu planejamento e tentar novamente

Repita o processo de teste até ter certeza de que você localizou todos os possíveis problemas e de que sabe como lidar com eles. Sua meta é saber o que seu planejamento prevê caso a situação não esteja bem, e já sejam 16 horas do domingo, e você precise estar online novamente na segunda-feira pela manhã. Há algum ponto sem retorno? Teste seu plano de reversão e verifique se ele funciona antes de começar a atualização real.