Práticas recomendadas para desempenho de pesquisa (Office SharePoint Server 2007)

Atualizado em: 2009-07-30

Este artigo descreve algumas práticas recomendadas que você pode usar para manter um sistema de pesquisa íntegro e eficiente no Microsoft Office SharePoint Server 2007.

Neste artigo:

• Motivos para iniciar um rastreamento completo

• Monitorando servidores Web

• Monitorando servidores de banco de dados

• Monitorando servidores de indexação

• Monitorando o Office SharePoint Server com Diagnósticos do SharePoint

• Usando logs do Serviço de Log Unificado para diagnosticar afunilamentos de consulta

• Otimizando o SQL Server para pesquisa no Office SharePoint Server 2007

• Mantendo bancos de dados do SQL Server para pesquisa

• Evitando a privação do rastreador

• Evitando afunilamentos causados por Listas de Controle de Acesso

• Solucionando problemas de Web Parts de Caixa de Pesquisa ausentes

Motivos para iniciar um rastreamento completo

Rastrear e indexar um volume muito grande de informações, documentos e páginas da Web exige um nível alto de processamento do computador. O processo de rastreamento também consome recursos de rede, entre vários outros. Você precisa configurar um farm do Office SharePoint Server 2007 com atenção, para garantir que o processo de rastreamento e indexação não prejudique o serviço disponível para os usuários. Por exemplo, o conteúdo é geralmente rastreado e indexado fora do horário de pico (quando os servidores não são muito utilizados), de modo a manter os serviços no horário de pico para os usuários.

Uma maneira de reduzir o impacto do rastreamento é agendar rastreamentos incrementais em vez de completos. Um rastreamento incremental apenas indexa os itens que sofreram alterações e, por isso, o processo exige muito menos recursos do computador. É possível agendar rastreamentos completos e incrementais em cada fonte de conteúdo. Por exemplo, considere a execução de rastreamentos incrementais à meia-noite nos dias da semana e de rastreamentos completos aos sábados à meia-noite.

Para garantir que o índice esteja completo, você deve iniciar um rastreamento completo manualmente nas seguintes circunstâncias:

• Quando os administradores aplicaram uma atualização ou um service pack aos servidores no farm.

• Quando os administradores adicionaram uma nova propriedade gerenciada à configuração de pesquisa.

• Quando os administradores adicionaram ou modificaram uma regra de rastreamento.

• Quando você deseja reindexar páginas ASP.NET em sites do Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 ou Search Server 2008. O rastreador não consegue detectar quando essas páginas da Web foram alteradas. Portanto, apenas um rastreamento completo poderá reindexá-las.

• Quando ocorreram falhas consecutivas no rastreamento incremental. Se o rastreamento incremental falhar uma centena de vezes consecutivas em qualquer nível do repositório, o servidor de indexação removerá o conteúdo afetado do índice.

• Quando os administradores corrigiram um índice corrompido.

• Quando um administrador criou um mapeamento de nome de servidor.

• Quando você alterou as permissões para uma parte do conteúdo, mas o conteúdo propriamente dito não foi alterado e você não possui o pacote de hotfix Pós-Service Pack 1 (KB941442), ou um service pack posterior, aplicado nos servidores. Sem esse pacote de hotfix, os rastreamentos incrementais não verificam ACLs (Listas de Controle de Acesso). Se essas ACLs não forem verificadas, um usuário poderá visualizar um item nos resultados de pesquisa mesmo que um administrador tenha removido a permissão desse usuário desde o último rastreamento completo.

Nas seguintes circunstâncias, o Office SharePoint Server 2007 realizará um rastreamento completo quando um rastreamento incremental tiver sido agendado ou manualmente iniciado:

• Quando um administrador interrompeu manualmente o rastreamento anterior.

• Quando um administrador restaurou um banco de dados de conteúdo a partir de um backup.

  Dica

  Se você tiver instalado o Atualização de infraestrutura para os Microsoft Office Servers, poderá especificar se uma operação de restauração causa um rastreamento completo, usando opções na ferramenta de linha de comando Stsadm.

• Quando um administrador desanexou e reanexou um banco de dados de conteúdo.

• Quando o Office SharePoint Server nunca executou um rastreamento completo no conteúdo.

• Quando o log de alterações não contém informações referentes aos endereços no rastreamento. O log de alterações é usado para determinar se um item sofreu alterações desde o último rastreamento. Sem as informações desse log, não é possível executar rastreamentos incrementais.

• Quando a conta usada para acessar o conteúdo foi alterada. Ela pode ser a conta de acesso padrão ou uma conta especificada em uma regra de rastreamento.

• Quando um índice foi corrompido.

Considere suas ações com muita cautela nessas circunstâncias. Isso porque, se você iniciar um rastreamento manualmente ou com um cronograma, o rastreamento completo poderá exigir muito mais recursos em comparação ao rastreamento incremental. Isso pode afetar o serviço que os usuários recebem.

Monitorando servidores Web

Para maximizar o desempenho de pesquisa do Office SharePoint Server 2007, analise o sistema a fundo. Você deve criar uma linha de base fazendo uma investigação completa dos servidores. Periodicamente, repita os testes de desempenho para observar alterações e diagnosticar problemas com antecedência. Ao fazer uma otimização, é possível usar a linha de base para caracterizar as melhorias resultantes. As seções a seguir listam contadores de monitor de desempenho e dados disponíveis de outras ferramentas que são relevantes para o desempenho do Office SharePoint Server 2007.

No Office SharePoint Server 2007, os servidores Web hospedam todos os sites e conjuntos de sites. Eles obtêm o conteúdo armazenado nos servidores de banco de dados e respondem a solicitações dos usuários. Como esses servidores Web enviam respostas a consultas de pesquisa dos usuários, seu desempenho tem efeito direto sobre o desempenho da pesquisa. Os servidores Web também afetam a indexação porque o rastreador indexa o conteúdo do Office SharePoint Server enviando solicitações a servidores Web.

Para monitorar a integridade dos servidores Web, use os seguintes contadores do Monitor de Desempenho:

• Processador/% de Tempo do Processador/_Total

  Esse contador é o principal indicador de atividade dos processadores, medindo a proporção de tempo que os processadores passam executando threads não ociosos. Se esse contador atingir uma média acima de 80% por períodos prolongados, significa que os processadores podem ser um afunilamento, e convém considerar uma atualização.

• Memória/Mbytes Disponíveis

  Esse contador mede a memória física imediatamente disponível para processos ou para o sistema. Se ele cair para um nível muito baixo, o sistema ficará mais lento, pois estará utilizando mais paginação. Convém adicionar mais memória ao servidor.

• Serviço Web/Conexões Atuais

  Esse contador mede o número de conexões com o serviço World Wide Web. Em servidores Web do Office SharePoint Server 2007, essa contagem inclui todos os usuários simultâneos e, durante a indexação, o rastreador. Use esse contador para formar um perfil de padrões de uso e determinar horários de pico. Não já limite para esse contador. Valores muitos altos podem indicar um excelente desempenho.

  Dica

  Em um farm do Office SharePoint Server com vários servidores Web, esse contador mede conexões em apenas um servidor. Para obter informações sobre como monitorar a atividade dos usuários por todo o farm, consulte Monitorando o Office SharePoint Server com Diagnósticos do SharePoint.

Monitorando servidores de banco de dados

O Office SharePoint Server 2007 usa o Microsoft SQL Server 2005 ou o Microsoft SQL Server 2008 para armazenar bancos de dados de conteúdo. Embora o servidor de indexação armazene o índice de conteúdo no sistema de arquivos (e não em um banco de dados), ele armazena permissões e metadados de documentos no banco de dados de pesquisa. Como muitas pesquisas verificam metadados e todas elas envolvem filtragem de segurança, o desempenho dos servidores de banco de dados afeta diretamente o desempenho da pesquisa.

Para monitorar a integridade dos servidores de banco de dados, use os seguintes contadores do Monitor de Desempenho:

• Processador/% de Tempo do Processador/_Total

  Esse contador é o principal indicador da atividade do processador e, portanto, é tão importante em servidores de banco de dados quanto em servidores Web.

• **Disco Lógico/% de Tempo de Disco/**Nome do Disco

  Esse contador mede a proporção do tempo decorrido que o disco passou atendendo a solicitações de leitura ou gravação. No caso de pesquisas, monitore esse contador para o disco que comporta o banco de dados de pesquisa. Se esse contador atingir com frequência uma média superior a 90%, talvez o disco represente um afunilamento para pesquisas.

• Sistema: Comprimento da Fila de Processador

  A média desse contador deve ser inferior a dois multiplicado pelo número de núcleos de CPU no servidor.

• Memória: Mbytes Disponíveis

  Verifique se a média desse contador é de pelo menos 20% do total de RAM física.

• Memória: Páginas/s

  A média desse contador deve ser inferior a 100.

• Disco Lógico: Transferências de Disco/s

  Esse contador mede a taxa de transferência geral para uma partição.

• Disco Lógico: Bytes de Leitura de Disco/s e Bytes de Gravação de Disco/s

  Esse contador mede a largura de banda total de um disco específico.

• Disco Lógico: Média de Disco s/Leitura

  Também conhecido como latência de leitura, esse contador indica o tempo necessário para o disco recuperar dados. Uma baixa latência de leitura é importante para uma rápida resposta às consultas dos usuários.

• Disco Lógico: Média de Disco s/Gravação

  Também conhecido como latência de gravação, esse contador indica o tempo necessário para o disco gravar os dados. Uma baixa latência de gravação melhora o desempenho da indexação.

• **Disco Lógico/% de Tempo de Leitura de Disco/**Nome do Disco

  Esse contador mede a proporção do tempo decorrido que o disco passou atendendo a solicitações de leitura. Uma proporção muito grande de solicitações de leitura para o disco do banco de dados de pesquisa pode indicar que os usuários estão executando muitas pesquisas.

• **Disco Lógico/% de Tempo de Gravação de Disco/**Nome do Disco

  Esse contador mede a proporção do tempo decorrido que o disco passou atendendo a solicitações de gravação. Uma proporção grande de solicitações de gravação para o banco de dados de pesquisa é esperada durante o processo de indexação.

  Dica

  Quando possível, otimize o desempenho da pesquisa colocando o banco de dados de pesquisa em um disco separado dos outros bancos de dados. Se o banco de dados de pesquisa for separado dessa maneira, esses contadores de Disco Lógico serão um recurso de diagnóstico bastante preciso para o desempenho de pesquisa, pois o disco estará especialmente dedicado a pesquisas.

• SQLServer:Gerenciador de Buffer/Expectativa de vida da página

  Esse contador mede o número de segundos durante os quais uma página do banco de dados permanece no pool de buffer sem referências. Ela deve permanecer mais de 300 segundos. Valores inferiores a 300 segundos são sintomas de um afunilamento de memória. Considere a inclusão de mais memória no servidor.

Monitorando servidores de indexação

No Office SharePoint Server 2007, servidores de indexação rastreiam o conteúdo e criam um arquivo de índice. Quando o processo de rastreamento termina, o índice é propagado aos servidores de consulta, que respondem às solicitações de pesquisa dos usuários.

Se o desempenho do servidor de indexação for insatisfatório, é possível que isso não tenha um efeito direto sobre os usuários. No entanto, o processo de rastreamento se torna mais demorado, às vezes chegando ao ponto de não ser possível limitá-lo ao horário fora de pico ou separá-lo de outras atividades que ocorrem fora do horário de pico, como backups.

Para monitorar a integridade do servidor de indexação, use os seguintes contadores do Monitor de Desempenho durante um rastreamento:

• Plug-in de Arquivamento do Office Server Search/Total de documentos na primeira fila/Conteúdo_Portal

  Esse contador mede o número de documentos na primeira fila do plug-in de arquivamento. Esse número deve ser inferior a 500 durante um rastreamento e significativamente baixo em outras ocasiões. Se o contador estiver acima de 500, isso significa que a unidade do banco de dados de pesquisa no servidor de banco de dados é provavelmente um afunilamento.

• Plug-in de Arquivamento do Office Server Search/Total de documentos na segunda fila/Conteúdo_Portal

  Esse contador mede o número de documentos na segunda fila do plug-in de arquivamento. De maneira semelhante ao contador anterior, esse número deve ser inferior a 500 durante um rastreamento.

• Gatherer do Office Server Search/Threads Ociosos

  Esse contador mede o número de threads no processo do gatherer à espera de documentos. Se for igual a 0, isso significa que o gatherer está com privação de recursos. Convém reduzir o número de rastreamentos simultâneos.

• Gatherer do Office Server Search/Threads Acessando a Rede

  Esse contador mede o número de threads no processo do gatherer que enviaram solicitações a um repositório de dados remoto e estão aguardando ou processando a resposta. Se ele estiver constantemente alto, talvez a largura de banda da rede seja um afunilamento, ou o servidor de indexação pode estar conectado a um ou mais hosts lentos para indexar o conteúdo.

• Gatherer do Office Server Search/Threads de Filtragem

  Esse contador mede o número de threads que recuperaram conteúdo e estão filtrando esse conteúdo. Se o número estiver alto, é possível que os recursos no servidor de indexação estejam atuando como um afunilamento.

• Gatherer do Office Server Search/Threads em Plug-Ins

  Esse contador mede o número de threads que recuperaram conteúdo e estão processando esse conteúdo através de plug-ins, como IFilters. Esse é o estágio do processo de rastreamento quando o índice e o banco de dados de pesquisa são populados.

• Projetos do Gatherer do Office Server Search/Rastreamentos em andamento

  Esse contador mede o número de rastreamentos em andamento. Esse valor deve corresponder ao número de fontes de conteúdo com rastreamentos agendados, a menos que um administrador tenha iniciado um rastreamento manualmente.

Monitorando o Office SharePoint Server com Diagnósticos do SharePoint

A Ferramenta de Diagnóstico do SharePoint v1.0 (também conhecida como SPDiag) é uma avançada ferramenta de análise e diagnóstico que apresenta uma grande variedade de informações sobre qualquer servidor ou farm que executa Produtos e Tecnologias do SharePoint. Você pode usar o SPDiag para ver instantâneos bastante detalhados das configurações de farms e servidores. Também pode usá-lo para mesclar e exibir informações do IIS (Serviços de Informações da Internet), logs do ULS (Serviço de Log Unificado) e logs de Eventos, além de investigar problemas de desempenho, como solicitações lentas.

O SPDiag pode apresentar gráficos de contadores de desempenho de qualquer servidor no farm. Entretanto, também inclui vários contadores que medem dados no âmbito de todo o farm com base em logs do IIS. Essa análise no âmbito do farm não é possível apenas com o Monitor de Desempenho.

Use os seguintes contadores no âmbito de todo o farm para investigar a rapidez de resposta do farm do Office SharePoint Server 2007:

• Solicitações do SharePoint/Número de IPs de clientes exclusivos

  Esse contador mede o número de clientes exclusivos que fizeram solicitações no período de tempo especificado. Observe que os clientes que acessam o farm através de um servidor proxy constam como um único endereço IP.

• Solicitações do SharePoint/Número de agentes de clientes exclusivos

  Esse contador mede o número de agentes de clientes — navegadores — exclusivos que fizeram solicitações no período de tempo especificado. Ele é capaz de diferenciar entre clientes que acessam o farm através de um servidor proxy, pois se baseia no agente especificado nas solicitações HTTP dos navegadores.

  Dica

  Os contadores a seguir medem números de solicitações. Essas solicitações incluem consultas de pesquisa e solicitações de conteúdo.

• SharePointRequests/Total de solicitações

  Esse contador mede o número total de solicitações à medida que esse número varia ao longo do período de tempo especificado. Você deve sempre monitorar esse contador em conjunto com os contadores a seguir para determinar a proporção de solicitações rápidas e lentas.

• SharePointRequests/Número de solicitações com tempo de < 1 segundo

  Esse contador mede o número de solicitações atendidas em 1 segundo. Em um farm de bom desempenho, esse contador se aproxima do contador Total de solicitações.

• SharePointRequests/Número de solicitações com tempo de 1-5 segundos

  Esse contador mede o número de solicitações atendidas no período de 1 a 5 segundos. Esse desempenho geralmente é aceitável para os usuários. Porém, se houver uma proporção crescente dessas solicitações com o passar do tempo, isso poderá indicar que um afunilamento está se desenvolvendo.

• SharePointRequests/Número de solicitações com tempo de 5-10 segundos

  Esse contador mede o número de solicitações atendidas no período de 5 a 10 segundos. Antes que os resultados sejam retornados, os usuários podem clicar fora de uma página.

• SharePointRequests/Número de solicitações com tempo de > 10 segundos

  Esse contador mede o número de solicitações atendidas em mais de 10 segundos. Se elas consistirem em uma proporção significativa do Total de solicitações, isso indicará que o farm não está respondendo, e você deverá investigar se há afunilamentos, além de considerar a possibilidade de atualizar o hardware.

Usando logs do Serviço de Log Unificado para diagnosticar afunilamentos de consultas

Você pode usar o Serviço de Log Unificado (ULS) para monitorar e otimizar o desempenho do sistema do Office SharePoint Server 2007. Você deve usar o ULS como um método para otimizar o sistema. Outros métodos são o uso do Monitor de Desempenho, Logs de Eventos e logs da Web.

Nesta seção, você verá como usar logs ULS para diagnosticar atrasos no desempenho de pesquisas. Usando logs ULS, é possível diagnosticar que estágios do processo de pesquisa consomem a maior parte do tempo e atrasam o retorno de resultados para os usuários. Você também deve usar esses logs para avaliar as melhorias de desempenho ocasionadas por pequenas alterações na configuração do sistema.

Configurando o Serviço de Log Unificado

Comece pela configuração do ULS no site de Administração Central do Office SharePoint Server 2007.

Para configurar o Serviço de Log Unificado de modo a diagnosticar problemas de desempenho de pesquisa

1. Clique em Iniciar , em Todos os Programas, em Microsoft Office Server e depois em Administração Central do SharePoint 3.0.

2. Clique na guia Operações.

3. Na seção Log e Relatório, clique em Log de diagnóstico.

4. Na seção Otimização de Evento, na lista Selecionar uma categoria, clique em MS Search Query Processor.

5. Em Evento menos crítico a ser relatado no log de rastreamento, clique em Alto.

6. Na parte inferior da página, clique em OK.

Usando a ferramenta Log Parser

Assim como os logs do Serviços de Informações da Internet (IIS), os logs ULS do Office SharePoint Server 2007 são arquivos de texto muito grandes. Para analisar o conteúdo desses arquivos, use um utilitário de análise de logs para se concentrar nos rastreamentos interessantes e formatar os dados. A ferramenta Microsoft Log Parser 2.2 (em inglês) (https://go.microsoft.com/fwlink/?linkid=148542\&clcid=0x416) (em inglês) é gratuita e é ideal para essa finalidade.

A ferramenta Log Parser é um programa de linha de comando. Você deve usar os parâmetros a seguir para indicar que os logs ULS são arquivos de texto em formato Unicode separados por tabulações:

logparser -i:TSV -iCodepage:-1 -fixedSep:ON

Além desses parâmetros, você deve fornecer uma consulta em estilo Transact-SQL que informe ao Log Parser como analisar o arquivo de log. Por exemplo, para se concentrar em mensagens de timer de processador de consultas, use a seguinte cláusula WHERE:

WHERE Category = 'MS Search Query Processor' AND Message LIKE '%Execução de consulta concluída com intervalos:%'

Pesquisar mensagens nos logs ULS

Quando o ULS for configurado conforme a descrição acima, as seguintes mensagens aparecerão nos arquivos de log à medida que os usuários executarem consultas:

• Execução de consulta concluída com intervalos

  Essa mensagem indica que uma consulta foi concluída e inclui seis intervalos que descrevem a consulta em milissegundos. Os seis intervalos são os seguintes:

  • v1. O tempo total gasto para processar a consulta.

  • v2. A latência da consulta, medida após a detecção de duplicatas.

  • v3. A latência da consulta, medida após a filtragem de segurança.

  • v4. A latência da consulta, medida após a adição dos resultados do índice aos resultados do banco de dados de pesquisa.

  • v5. O tempo gasto à espera dos resultados do servidor de indexação.

  • v6. O tempo gasto em chamadas ao banco de dados, excluindo a busca de propriedades no banco de dados de pesquisa.

  Com esses seis intervalos, você pode calcular as seguintes informações:

  • v1 – v2. O tempo gasto para recuperar propriedades e realçar ocorrências.

  • v2 – v3. O tempo gasto para detectar duplicatas.

  • v3 – v4. O tempo gasto na filtragem de segurança.

  • v4 – v5. O tempo gasto na adição dos resultados no índice aos resultados do banco de dados de pesquisa.

• Repetição de adição

  Essa mensagem indica que ocorreu uma repetição, pois os resultados retornados pelo banco de dados de pesquisa não correspondiam aos resultados retornados do índice de texto completo e, assim, não puderam ser adicionados.

• Repetição de Filtragem de Segurança

  Essa mensagem indica que um usuário executou uma consulta e não está autorizado a ler os resultados retornados. Essa consulta é repetida, com um maior número de resultados solicitado, até que resultados suficientes sejam retornados.

• Repetição de remoção de quase duplicatas

  Essa mensagem indica que muitos documentos praticamente idênticos foram filtrados dos resultados e, assim, o processador de consultas não teve resultados suficientes para exibir. Essa consulta é repetida, com um maior número de resultados solicitado, até que resultados suficientes sejam retornados.

Analisando intervalos de consulta

Dentre as mensagens descritas anteriormente nesta seção, a mensagem Execução da consulta concluída com intervalos é mais útil no diagnóstico de atrasos no processamento de consultas. Por exemplo, se a filtragem de segurança estiver lenta, o cálculo v3 – v4 será uma grande proporção do tempo de processamento total v1.

Para analisar intervalos, passe a consulta SQL a seguir à ferramenta Log Parser. A ferramenta criará um arquivo separado por vírgulas que incluirá os intervalos v1 a v6 e suas diferenças.

Select  Timestamp,
TO_INT(Extract_token(Message,7, ' ')) as TotalQPTime,
      TO_INT(Extract_token(Message,8, ' ')) as v2,
      TO_INT(Extract_token(Message,9, ' ')) as v3,
      TO_INT(Extract_token(Message,10, ' ')) as v4,
      TO_INT(Extract_token(Message,11, ' ')) as TimeSpentInIndex,
      TO_INT(Extract_token(Message,12, ' ')) as v6,
      SUB(v4, TimeSpentInIndex) as JoinTime,
      SUB(v3, v4) as SecurityTrimmingTime,
      CASE v2
           WHEN 0 THEN 0 
           ELSE SUB(v2, v3) 
      End as DuplicateDetectionTime,
      SUB(TotalQPTime, v2) as FetchTime
INTO QTiming
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Completed query execution with timings:%'

Você pode importar o arquivo CSV resultante para o Microsoft Office Excel ou outra ferramenta de análise para criar gráficos e relatórios. Considere que, em um sistema ocupado, várias consultas são executadas, e talvez seja necessário calcular uma média a partir de diversos resultados para que se possa gerar uma análise significativa.

Analisando repetições

Os dados de intervalos disponíveis na mensagem Execução da consulta concluída com intervalos não incluem informações sobre repetições — por exemplo, repetições causadas pela filtragem de segurança. Para analisar o tempo gasto pelo processador de consultas em repetições, é necessário comparar o número total de consultas com o número de repetições de tipos diferentes.

A consulta a seguir conta o número total de consultas executadas:

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Completed query execution%'

A consulta a seguir conta o número total de repetições causadas pela filtragem de segurança:

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Security trimming retry%'

A consulta a seguir conta o número total de repetições causadas pela remoção de resultados duplicados:

SELECT count (Message) 
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log' 
WHERE Category = 'MS Search Query Processor' 
AND Message LIKE '%Near duplicate removal retry%'

Use essas consultas para diagnosticar como as repetições atrasam os resultados de consultas. Quando o número de repetições for uma proporção significativa do número total de consultas, convém fazer uma revisão da configuração. Por exemplo, se apenas alguns usuários conseguirem acessar os documentos em uma das fontes de conteúdo, isso poderá aumentar o número de repetições de filtragem de segurança. Nesse caso, convém remover essa fonte do índice.

Otimizando o SQL Server para pesquisa no Office SharePoint Server 2007

O Microsoft Office SharePoint Server 2007 usa o Microsoft SQL Server para armazenar conteúdo, informações de configuração e propriedades de conteúdos indexados. É necessário otimizar o SQL Server para garantir o desempenho ideal a partir do Office SharePoint Server.

Otimização geral do SQL Server

Algumas otimizações aprimoram o desempenho do SQL Server, independentemente da finalidade do servidor. Você deve verificar se as otimizações estão em vigor para um banco de dados do Office SharePoint Server.

Ao planejar e implantar o servidor de banco de dados, leve em conta as seguintes recomendações:

• Quando possível, execute o SQL Server em um farm de servidores ou um servidor dedicado.

• Faça uma expansão para vários servidores de bancos de dados em um farm de servidores. Em geral, você deve instalar um servidor de banco de dados para cada quatro servidores Web que estão em execução com toda a sua capacidade.

• Use uma versão de 64 bits do SQL Server nos computadores, juntamente com sistemas operacionais de 64 bits.

• Use o número máximo de eixos de discos físicos que o orçamento de hardware permitir.

• Use discos de alta velocidade.

• Coloque os bancos de dados em matrizes de disco RAID 1+0 ou RAID 1.

• Separe os arquivos de log em um disco físico que não armazene os arquivos de dados primários e secundários.

Otimizando o SQL Server para indexação e consultas de pesquisa

Uma alta prioridade para vários administradores do Office SharePoint Server 2007 é a otimização do rastreamento, da indexação e das consultas. O índice de conteúdo do Office SharePoint Server é armazenado no sistema de arquivos, fora de qualquer banco de dados do SQL Server. No entanto, o banco de dados de pesquisa armazena metadados de arquivos indexados e de ACLs. Consequentemente, o desempenho do SQL Server afeta diretamente as duas operações de pesquisa a seguir:

• Indexação, quando o Office SharePoint Server armazena metadados e ACLs.

• Consultas. Todas as consultas do Office SharePoint Server envolvem a filtragem de segurança, durante a qual o Office SharePoint Server verifica as ACLs no banco de dados de pesquisa e remove os resultados que o usuário não tem permissão para exibir. Além disso, se o usuário tiver executado uma pesquisa de propriedades, metadados deverão ser recuperados do banco de dados de pesquisa.

Comece seguindo as recomendações gerais de otimização do SQL Server fornecidas anteriormente neste artigo. Além disso, as otimizações listadas nas seções a seguir trazem benefícios especificamente para operações de indexação e consulta.

Otimizar o desempenho do banco de dados tempdb.

Todas as consultas de usuários envolvem atividades no banco de dados tempdb do SQL Server. Portanto, a configuração desse banco de dados afeta diretamente a rapidez com a qual as respostas a consultas são exibidas para os usuários.

Execute os seguintes procedimentos para otimizar tempdb:

• Defina o modelo de recuperação como SIMPLE.

• Permita que os arquivos tempdb cresçam automaticamente conforme a necessidade.

• Defina o incremento de crescimento de arquivo como um valor razoável. Como regra, o incremento deve corresponder a aproximadamente 10% do tamanho de arquivo de tempdb.

• Pré-aloque espaço para arquivos tempdb definindo o tamanho de arquivo como um valor que possa acomodar toda a atividade durante rastreamentos e consultas.

• Use vários arquivos de dados para maximizar a largura de banda de disco. Como regra, use um arquivo de dados para cada núcleo de CPU no computador que está executando o SQL Server.

• Faça com que todos os arquivos de dados tenham o mesmo tamanho.

• Coloque o banco de dados tempdb em um disco físico separado daqueles que armazenam os bancos de dados de conteúdo, o banco de dados de configuração e o banco de dados de pesquisa.

Use grupos de arquivos para aprimorar o desempenho.

O processo de rastreamento e indexação do Office SharePoint Server 2007 exige muita E/S e grava um grande volume de dados no banco de dados de pesquisa. Se o sistema apresenta horas consideráveis fora de pico, convém agendar a indexação para execução durante esse período, para garantir que ela não dispute os recursos com consultas dos usuários. No entanto, em algumas organizações com atividade global ou 24 horas, não há reduções significativas na demanda. Se o banco de dados que hospeda o banco de dados de pesquisa estiver próximo de sua capacidade de E/S, convém planejar outras maneiras de separar as operações de E/S de indexação das operações associadas a consultas dos usuários.

O banco de dados de pesquisa pode ser dividido em tabelas envolvidas na indexação e tabelas basicamente envolvidas em consultas de usuários. Separando os grupos de tabelas em dois discos físicos, você garante que a indexação tenha efeito mínimo sobre o desempenho das consultas. Embora as tabelas de indexação e de consulta estejam em um único banco de dados, é possível usar o recurso de grupos de arquivos do Microsoft SQL Server para obter essa separação.

Para fazer isso, crie um grupo de arquivos de usuário contendo um arquivo de dados secundário. Esse arquivo de dados deve estar em um disco físico dedicado para proporcionar uma melhoria de desempenho. Em seguida, mova as tabelas envolvidas na indexação até esse grupo de arquivos usando o procedimento a seguir. Esse procedimento pode levar um tempo significativo, dependendo do tamanho do banco de dados de pesquisa. Portanto, você deve realizá-lo quando a demanda estiver baixa.

Para separar tabelas de indexação em um grupo de arquivos dedicado

1. No SQL Server Management Studio, clique com o botão direito do mouse no banco de dados de pesquisa e clique em Propriedades.

2. Na lista Selecionar uma página, clique em Grupos de arquivos.

3. Clique em Adicionar e nomeie o novo grupo de arquivos como "GrupodeArquivosdeRastreamento”.

4. Na lista Selecionar uma página, clique em Arquivos.

5. Clique em Adicionar e dê um nome para o novo arquivo.

6. Na célula Grupo de arquivos, selecione GrupodeArquivosdeRastreamento.

7. Na célula Caminho, selecione um caminho em um disco físico separado do grupo de arquivos PRIMÁRIO.

8. Clique em OK.

9. No SQL Server Management Studio, clique em Nova Consulta.

10. Copie a consulta a seguir para a janela de consulta e clique em Executar. Esse código Transact-SQL cria um novo procedimento armazenado que move as tabelas para o novo grupo de arquivos.

    IF EXISTS (SELECT * FROM sysobjects WHERE type = 'P' AND name = 'proc_MoveTableToFileGroup')
       BEGIN
          DROP  Procedure  dbo.proc_MoveTableToFileGroup
       END
    GO
    CREATE PROCEDURE [dbo].[proc_MoveTableToFileGroup]
    (
       @fileGroup sysname,
       @tableName sysname
    )
    as
    begin
       declare @data_space_id int
       declare @object_id int
       declare @index_id int
       declare @index_name sysname
       declare @object_name sysname
       declare @fileGroupName sysname
       declare @index_cols nvarchar(4000)
       declare @sql nvarchar(4000)
       declare @key_ordinal int
       set @index_id = 0
       set @key_ordinal = 0
       select @data_space_id = data_space_id, @fileGroupName = name from sys.filegroups where name = @fileGroup
       if @data_space_id is null
       begin
          raiserror ('The specified filegroup does not exist.', 16, 1)
          return
       end
       while 1=1
       begin
          select top 1
                @object_id = i.object_id, 
                @index_id = i.index_id,
                @index_name = i.name,
                @object_name = o.name
             from 
                sys.indexes AS i
             inner join 
                sys.objects AS o
             ON
                i.object_id = o.object_id
             where 
                i.index_id > 0 and
                o.type = 'U' and
                o.name = @tableName and
                i.index_id > @index_id and
                i.data_space_id <> @data_space_id
             order by i.index_id
          if @@rowcount = 0 
          begin
             if @index_id = 0
                print 'There are no indexes to move to filegroup ' + @fileGroupName + ' for table ' + @tableName
             break
          end
          set @index_cols = null
          set @key_ordinal = 0
          while 1=1
          begin
             select top 1 
                @index_cols = case when @index_cols is null then '[' + c.name + ']' else @index_cols + ', [' + c.name + ']' end + 
                case when i.is_descending_key = 0 then ' asc' else 'desc' end, 
                @key_ordinal = i.key_ordinal
             from 
                sys.index_columns i 
             inner join 
                sys.columns as c
             on 
                i.object_id = c.object_id and
                i.column_id = c.column_id
             where 
                i.object_id = @object_id and 
                i.index_id = @index_id and 
                i.key_ordinal > @key_ordinal
             order by i.key_ordinal
             if @@rowcount = 0 
                break
          end
          select @sql = 
             case when i.is_primary_key = 1 then 
                N'begin try ' + 
                N'begin tran ' + 
                N'alter table [' + @object_name + '] drop constraint [' + i.name + '] ' + 
                N'alter table [' + @object_name + '] add constraint [' + i.name + '] ' + 
                'primary key ' +
                case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
                ' (' + @index_cols + ') ' + 
                'with (' +
                'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
                ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
                case when  i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + 
                ') ' + 
                'ON [' + @fileGroupName + ']' + 
                N' commit ' + 
                N'end try ' + 
                N'begin catch ' + 
                N'rollback ' + 
                N'end catch ' 
             else 
                N'create ' + 
                case when  i.is_unique = 1 then 'unique ' else '' end +
                case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
                'index [' + i.name + '] on [' + @object_name + '] (' + @index_cols + ') ' + 
                'with (' +
                'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
                ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
                case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ', DROP_EXISTING = ON ) ' + 
                'ON [' + @fileGroupName + ']'
             end
    from 
             sys.indexes AS i
          where 
             i.object_id = @object_id and
             i.index_id = @index_id
          print 'Moving index ' + @index_name + ' to filegroup ' + @fileGroupName 
          print @sql
          print ''
          exec sp_executesql @sql
       end
    end
    

11. No SQL Server Management Studio, clique em Nova Consulta.

12. Copie a consulta a seguir para a janela de consulta e clique em Executar. Esse código Transact-SQL executa o novo procedimento armazenado para cada tabela de indexação.

    declare @fileGroup sysname
    set @fileGroup = 'CrawlFileGroup'
    if not exists (select 1 from sys.filegroups where name = @fileGroup)
    begin
       raiserror ('The specified filegroup does not exist.', 16, 1)
       return
    end
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorChangeLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorPendingChangeLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorText'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorTransactions'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedSourceDocs'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedTargetDocs'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlContent'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedErrorList'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedURL'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlErrorList'
    begin try
       begin tran
       IF  EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_MSSCrawlContent_MSSCrawlHistory]') AND parent_object_id = OBJECT_ID(N'[dbo].[MSSCrawlContent]'))
       ALTER TABLE [dbo].[MSSCrawlContent] DROP CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory]
       exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHistory'
       ALTER TABLE [dbo].[MSSCrawlContent]  WITH CHECK ADD  CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] FOREIGN KEY([CrawlID])
       REFERENCES [dbo].[MSSCrawlHistory] ([CrawlID])
       commit
    end try
    begin catch 
       rollback
    end catch
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHostList'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlQueue'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURL'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURLLog'
    exec proc_MoveTableToFileGroup @fileGroup, 'MSSTranTempTable0'
    

Mantendo bancos de dados do SQL Server para pesquisa

Como qualquer sistema complexo, os bancos de dados do SQL Server exigem manutenção regular para garantir o nível mais alto de desempenho possível. Esta seção descreve algumas práticas recomendadas para se manter o máximo de desempenho.

Os seguintes procedimentos de manutenção de disco podem aprimorar o desempenho dos servidores de banco de dados:

• Mantenha pelo menos 25% de espaço em disco livre para permitir que os bancos de dados cresçam. Monitore regularmente o espaço livre e o tamanho do disco para evitar uma redução desse percentual. O banco de dados de pesquisa poderá aumentar significativamente de tamanho, e com muita rapidez, se os administradores adicionarem novas fontes de conteúdo.

• Se a controladora de disco usar Cache de Gravação em Disco, verifique se há uma bateria de reserva, para evitar que uma falha de energia resulte na interrupção do serviço.

Os seguintes procedimentos de manutenção do SQL Server podem aprimorar o desempenho dos servidores de banco de dados:

• Execute a rotina DBCC CHECKDB Transact-SQL regularmente em todos os bancos de dados do Office SharePoint Server. No entanto, essa rotina deposita uma carga significativa sobre o computador com SQL Server e pode afetar a capacidade de resposta. Por isso, use a opção PHYSICAL_ONLY e agende DBCC CHECKDB para horários fora de pico. Não execute essa rotina durante um rastreamento do Office SharePoint Server.

• Evite executar operações sem suporte nos computadores de produção que estão executando o SQL Server. Por exemplo, não altere o agrupamento de bancos de dados, nem adicione colunas a tabelas de bancos de dados do Office SharePoint Server. Para obter mais informações sobre operações sem suporte, consulte o artigo da Base de Dados de Conhecimento Microsoft 841057: sobre suporte a alterações nos bancos de dados que são usados pelos produtos de servidor do Office e pelo Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=105589\&clcid=0x416).

Com o passar do tempo, a fragmentação nos índices do SQL Server que dão suporte ao banco de dados de pesquisa pode afetar o desempenho de consultas e indexação. O artigo KB943345 da Base de Dados de Conhecimento Microsoft inclui um script Transact-SQL que cria um procedimento armazenado chamado proc_DefragmentIndices. Você pode usar proc_DefragmentIndices para desfragmentar bancos de dados de pesquisa e de conteúdo no farm do Office SharePoint Server. No entanto, esse procedimento armazenado consome muitos recursos do servidor. Portanto, você deve usá-lo com muito cuidado para não prejudicar a capacidade de resposta das consultas.

Além disso, está disponível um procedimento armazenado de desfragmentação chamado proc_DefragSearchIndexes, projetado especificamente para o banco de dados de pesquisa do Office SharePoint Server. Ele desfragmenta apenas os índices que fornecem máximo benefício em termos de desempenho, como IX_MSSDocProps e IX_MSSDocSdids. Isso minimiza a demanda de recursos do servidor de banco de dados. Agende o procedimento armazenado para ser executado fora do horário de pico e monitore cuidadosamente o efeito causado sobre os usuários.

Se você diagnosticar um afunilamento de disco ou RAID em um servidor de banco de dados no farm, as seguintes ações poderão reduzir o efeito do problema:

• Transfira arquivos de dados e logs de transações para matrizes RAID ou discos separados. O uso de grupos de arquivos, descrito anteriormente neste artigo, maximiza o desempenho.

• Adicione discos à matriz RAID.

• Substitua os discos mais lentos por outros mais rápidos.

Evitando a privação do rastreador

Em uma organização grande ou complexa, há desafios significativos a serem superados quando você configura o sistema de indexação do Office SharePoint Server 2007. Pode haver muitas fontes de conteúdo de diversos tipos, com conteúdo muito extenso que demore bastante para ser rastreado. Você também deve planejar cuidadosamente as metas de atualização das entradas no índice, de modo a garantir que os resultados de pesquisa reflitam o conteúdo atualizado. Para atingir as metas de atualização, é necessário otimizar o desempenho do indexador, para que ele possa rastrear todo o conteúdo regularmente.

Um grande obstáculo para a velocidade da indexação é a privação no rastreador. O rastreador encontra-se em um estado de privação quando não consegue alocar outro thread com o objetivo de recuperar o documento seguinte na fila. A privação pode ter estas causas:

• Contenção de recursos no servidor de banco de dados que hospeda o banco de dados de pesquisa

• Muitos hosts participando do rastreamento

• Hosts que não liberam rapidamente um thread. (Neste artigo, eles são chamados de "hosts monopolizadores de recursos".)

• Backups executados simultaneamente ao rastreamento

Hosts monopolizadores de recursos bloqueiam um thread e impedem que ele se mova para o próximo documento. Esse bloqueio pode ocorrer nas seguintes circunstâncias:

• Quando o host está lento devido à insuficiência de CPU, memória ou outros recursos.

• Quando o host requer trabalho adicional para rastreamentos incrementais. Por exemplo, se a fonte for um servidor Microsoft SharePoint Portal Server 2003, o rastreador deverá processar novamente um documento completo se as permissões tiverem sido alteradas.

• Hosts ou documentos que têm muitas propriedades. Quando há muitas propriedades para cada documento, o servidor de banco de dados que hospeda o banco de dados de pesquisa precisa trabalhar mais. Fontes de conteúdo do Catálogo de Dados Corporativos e de Meus Sites geralmente têm muitas propriedades.

Os rastreamentos mais eficientes geralmente ocorrem com os seguintes tipos de host:

• Servidores do Office SharePoint Server 2007. Esses servidores mantêm um log de alterações que o rastreador pode usar.

• Compartilhamentos de arquivos. O rastreador pode verificar se há alterações no nível de pasta e não examina cada documento.

• Pastas públicas do Exchange. O rastreador pode verificar se há alterações no nível de pasta e não examina cada postagem.

Diretrizes para evitar privação

É possível minimizar a privação do rastreador seguindo estas práticas recomendadas:

• Minimize o número de fontes de conteúdo. Você obterá maior eficiência se agrupar hosts de mesmo tamanho e tipo nas mesmas fontes de conteúdo.

• Rastreie os hosts grandes do Office SharePoint Server 2007 antes de adicionar outros tipos de host. O rastreamento desses hosts é muito eficiente, e rastreamentos incrementais liberam threads com bastante rapidez.

• Não agende rastreamentos simultaneamente para mais de um host monopolizador de recursos.

• Como ponto de partida, agende quatro rastreamentos simultâneos. Talvez seja possível aumentar esse número para alguns servidores de indexação. Para obter mais informações, consulte a seguinte seção neste artigo.

• Se o rastreador ficar em privação, pause o rastreamento para que os hosts que consomem muitos recursos liberem threads.

Como diagnosticar a privação

Ao instalar um novo sistema de pesquisa do Office SharePoint Server 2007, construa a configuração do rastreador adicionando novas fontes de conteúdo ao longo de vários dias ou semanas. Monitore o desempenho do sistema enquanto adiciona cada fonte de conteúdo para evitar a privação e facilitar a solução de problemas. Dessa maneira, é possível obter uma noção profunda do comportamento do sistema durante os rastreamentos.

O número de threads que o rastreador usa é determinado pela configuração Desempenho do Indexador. Para alterá-la, na Administração Central, clique na guia Operações, em Serviços no Servidor e em Office SharePoint Server Search. A tabela a seguir mostra como a configuração Desempenho do Indexador controla threads de rastreamento.

Configuração de Desempenho do Indexador	Número total de threads	Máximo de threads para cada host
Reduzido	Número de processadores	Número de processadores
Parcialmente reduzido	Quatro vezes o número de processadores	Número de processadores mais quatro
Máximo	16 vezes o número de processadores	Número de processadores mais quatro

No Office SharePoint Server 2007, o número de threads de rastreamento nunca excede 64.

A causa mais comum da privação é a contenção de recursos no servidor de banco de dados. Você pode diagnosticar isso monitorando o Plug-in de Arquivamento. No Monitor de Desempenho, use o objeto Plug-in de Arquivamento do Office Server Search e os contadores Total de documentos na primeira fila e Total de documentos na segunda fila. Se esses contadores estiverem indicando 500 para a instância Portal_Content ou 50 para a instância ProfileImport, isso significa que o rastreador está em estado de privação. Convém ajustar o servidor de banco de dados conforme descrito em Otimizando o SQL Server para pesquisa no Office SharePoint Server 2007, anteriormente neste artigo.

Estados de privação que não são causados pelo Plug-in de Arquivamento podem ser diagnosticados com o objeto Gatherer do Office Server Search no Monitor de Desempenho. Concentre-se nos contadores Threads Ociosos, Threads Acessando a Rede e Threads em Plug-ins e compare-os com o número total de threads do sistema. Para obter descrições completas dos contadores, consulte Monitorando servidores de indexação anteriormente neste artigo.

Evitando afunilamentos causados por Listas de Controle de Acesso

Quando o Office SharePoint Server 2007 rastreia e indexa uma fonte de conteúdo, ele verifica ACLs (Listas de Controle de Acesso) e as armazena no banco de dados de pesquisa. Quando os usuários pesquisam o índice, cada resultado é verificado nesse banco de dados, para garantir que os usuários tenham a devida autorização para acessar o resultado em questão. Esse processo é chamado de filtragem de segurança. ACLs extensas com muitos níveis de aninhamento podem prejudicar o desempenho do processo de rastreamento e das pesquisas no Office SharePoint Server. Esta seção descreve como minimizar essa degradação no desempenho.

O Active Directory fornece os tipos de entidades de segurança a seguir, que você pode usar para ajudar a proteger sites e conteúdo indexado do Office SharePoint Server:

• Contas de usuário

• Grupos globais

• Grupos locais de domínios

• Grupos universais

No Office SharePoint Server 2007, também existem grupos do SharePoint. Esse sistema é bastante flexível e pode incluir várias camadas de aninhamento. No entanto, entidades de segurança podem prejudicar o desempenho de pesquisa do Office SharePoint Server.

Para garantir o desempenho máximo do rastreador e das pesquisas do Office SharePoint Server 2007, observe as seguintes regras ao usar entidades de segurança do Active Directory e grupos do SharePoint:

• Coloque as contas de usuário em grupos globais, e os grupos globais em grupos locais de domínios. Atribua permissões a grupos locais de domínios. Essa é a prática recomendada para usar entidades de segurança no Active Directory. Ela garante que os controladores de domínio possam pesquisar associações de grupo rapidamente e que os usuários possam acessar recursos em toda a floresta.

• Se grupos universais forem necessários, use o mesmo sistema, mas coloque os grupos globais em grupos universais e os grupos universais em grupos locais de domínios.

• Coloque grupos locais de domínios em grupos do SharePoint para atribuir permissões a sites do SharePoint e outros recursos.

• Limite o número de níveis de aninhamento usados na associação de grupo.

As seguintes situações específicas prejudicarão o desempenho de pesquisa do Office SharePoint Server 2007 e também devem ser evitadas:

• Não atribua permissões de site do Office SharePoint Server a usuários individuais.

  Sites do Office SharePoint Server ficam mais lentos quando mais de 2.000 entidades de segurança estão listadas na DACL de um site. No entanto, um grupo do Active Directory ou do SharePoint é uma única entidade de segurança, independentemente do número de usuários que ele contém. Por isso, use grupos do SharePoint para atribuir permissões de site e coloque usuários e grupos do Active Directory nesses grupos do SharePoint.

• Não use grupos de segurança do Active Directory com aninhamento muito profundo.

  Quando um usuário tenta acessar um site do Office SharePoint Server, o servidor deve avaliar as associações de grupo para autorizar o usuário. Quando os grupos têm aninhamento muito profundo, são necessárias muitas consultas aos controladores de domínio. Além disso, podem ser necessárias consultas a domínios remotos na floresta. Essas consultas devem ser concluídas para que seja concedido acesso ao usuário.

• Não use listas de distribuição nem grupos de segurança que contenham contatos.

  Os contatos no Active Directory podem ser adicionados a grupos para, por exemplo, distribuir emails. No entanto, esses contatos não são entidades de segurança e não são envolvidos na autorização. O desempenho poderá ficar prejudicado se você atribuir permissão a um grupo que contenha contatos.

No Office SharePoint Server 2007, o proprietário de cada site pode adicionar usuários e grupos à DACL do site. É importante ensinar esses proprietários a usar associações de grupos com responsabilidade para evitar a introdução de afunilamentos.

Solucionando problemas de Web Parts de Caixa de Pesquisa ausentes

A Web Part de Caixa de Pesquisa não aparecerá no Centro de Pesquisa nem em outros locais da interface do usuário do Office SharePoint Server 2007 nas seguintes circunstâncias:

• Um desenvolvedor modificou a página de conteúdo do Centro de Pesquisa ou a página mestra do site, de modo a ocultar ou remover a Web Part de Caixa de Pesquisa.

• Um usuário que possui o nível de permissão Controle Total ou Design no site removeu ou ocultou a Web Part de Caixa de Pesquisa.

• O serviço de Pesquisa não está disponível no farm do Office SharePoint Server, devido a uma interrupção no serviço ou porque os administradores o colocaram offline.

Consulte também

Conceitos

Solução de problemas do Office SharePoint Server 2007
Práticas recomendadas para Pesquisa no Office SharePoint Server