Compartilhar via

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

  • Artigo

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Antes de iniciar o processo de atualização do Microsoft Office SharePoint Server 2007 para o Microsoft SharePoint Server 2010, convém testar o processo de atualização para verificar se você sabe exatamente o que precisa fazer para ter uma atualização bem-sucedida. Ao usar uma atualização de verificação para testar o processo, é possível 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 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 mensurar 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 definiçõ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 precisará 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 Office SharePoint Server 2007, 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 ambiente atual e as copie para o ambiente de teste. Para obter mais informações sobre os tipos de personalização a serem identificados, consulte Determinar como lidar com personalizações (SharePoint Server 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 site. Ele também salva informações de definição de cada lista. Você pode examinar 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 Office SharePoint Server 2007, o verificador de pré-atualização é uma ferramenta somente leitura e não altera os seus sites. Para obter mais informações sobre essa ferramenta e conhecer as etapas para executá-la, consulte o artigo sobre verificação de pré-atualização e geração de relatórios para versões futuras (Office SharePoint Server) e Executar o verificador de pré-atualização (SharePoint Server 2010).

  • Use a operação Stsadm –o enumallwebs em todos os bancos de dados de conteúdo no ambiente do Office SharePoint Server 2007 para identificar personalizações específicas em subsites. Essa operação lista uma ID para cada conjunto de sites e subsite no seu ambiente, bem como os modelos dos quais o site depende. Ela foi inicialmente introduzida no Office SharePoint Server 2007 com Service Pack 2 (SP2). Para obter mais informações, consulte Enumallwebs: operação de Stsadm (Office SharePoint Server).

  • 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 Ferramenta de Diagnóstico do SharePoint (SPDiag).

  • Crie uma lista de todas as personalizações encontradas. Se possível, identifique a origem delas. Por exemplo, há suplementos de terceiros ou modelos que tenham sido personalizados internamente? Depois de identificar a origem, verifique se há versões atualizadas das personalizações. Há uma planilha que pode ser usada para preencher informações do ambiente, com base nos dados apurados nos resultados do verificador de pré-atualização e na pesquisa sobre personalizações. Baixe a planilha em https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x416 e adapte-a de acordo com as 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 apropriados no farm de teste. Use o cmdlet do Windows PowerShell, test-spcontentdatabase, antes de anexar um banco de dados ao SharePoint Server 2010, para determinar se há alguma personalização faltando no ambiente. Execute esse comando para cada banco de dados após a restauração no servidor de banco de dados, porém antes de executar a atualização. Observe que o cmdlet será executado silenciosamente; ou seja, não retornará nenhuma saída, exceto em caso de 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 você 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 o backup e a restauração de um farm inteiro (Office SharePoint Server 2007).

  3. Execute o verificador de pré-atualização. Anote todos os problemas detectados. Convém solucioná-los no 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 Server 2010).

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

  5. Revise os resultados.

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

  1. Crie um backup do SQL Server dos seus bancos de dados de conteúdo e dos bancos de dados SSP (Provedor de Serviços Compartilhados).

  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 o backup e a restauração de bancos de dados (Office SharePoint Server).

  3. Execute o verificador de pré-atualização. Anote todos os problemas detectados. Convém solucioná-los no 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 Server 2010).

  4. Siga as etapas em Preparar o novo ambiente do SharePoint Server 2010 para uma atualização de anexação do banco de dados 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 Server 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 para 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 encontrar essas entradas, a instalação terá êxito.

Se não encontrar as entradas da etapa anterior, identifique as questões específicas 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 ficou faltando ou foi ignorado durante a atualização, execute a operação stsadm -o localupgradestatus do Stsadm em cada servidor Web front-end do seu farm de servidores do SharePoint Server 2010. Para obter mais informações sobre essa operação, consulte Localupgradestatus: operação de Stsadm (Office SharePoint Server)..

Caso a atualização tenha ignorado algum conjunto de sites, reinicie o processo de atualização do banco de dados com o 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 Server 2010).

Revisar sites atualizados

Revise os sites atualizados para identificar problemas que devem 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 revisar os sites atualizados (Office SharePoint Server).

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.