Práticas recomendadas para desempenho de pesquisa (Search Server 2008)
Atualizado em: 2009-07-30
.gif "Observação") Observação: |
|---|
Exceto quando especificado, as informações neste artigo aplicam-se tanto ao Microsoft Search Server 2008 como ao Microsoft Search Server 2008 Express. |
Este artigo descreve algumas práticas recomendadas que você pode usar para manter um sistema de pesquisa íntegro e eficiente no Servidor de Pesquisa da Microsoft 2008.
Neste artigo:
Motivos para iniciar um rastreamento completo
Monitorando servidores Web
Monitorando servidores de bancos de dados
Monitorando servidores de índice
Monitorando o Servidor de Pesquisa com Diagnósticos do SharePoint
Usando os logs de Serviço de Log Unificado para diagnosticar afunilamentos de consulta
Otimizando o SQL Server para Search Server 2008
Mantendo os bancos de dados do SQL Server para pesquisa
Evitando 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 Search Server 2008 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.
| Observação: |
|---|
Para obter mais informações sobre como planejar agendas de rastreamento, consulte Planejar para rastrear conteúdo (Search Server 2008). |
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 tiver ocorrido falhas consecutivas de rastreamento incremental. Se o rastreamento incremental falhar 100 vezes consecutivamente, em qualquer nível do repositório, o servidor de índice removerá o conteúdo afetado do índice.
Quando os administradores corrigiram um índice corrompido.
Quando os administradores tiverem criado 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 Search Server 2008 realizará um rastreamento completo quando um rastreamento incremental tiver sido agendado ou manualmente iniciado:
Quando um administrador de SSP tiver parado manualmente o rastreamento anterior.
Quando um administrador restaurou um banco de dados de conteúdo a partir de um backup.
Observação:Você pode especificar se uma operação de restauração causará um rastreamento completo usando as opções na ferramenta stsadm.exe.
Quando um administrador de farm tiver desanexado e reanexado um banco de dados de conteúdo.
Quando o Servidor de Pesquisa 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 de usuário usada para acessar o conteúdo tiver sido alterada. Essa conta de usuário pode ser a conta padrão de acesso ao conteúdo ou uma conta especificada em uma regra de rastreamento.
Quando um índice foi corrompido.
Você deve analisar cuidadosamente suas ações nessas circunstâncias porque, se você iniciar um rastreamento manualmente ou via agenda, o rastreamento completo poderá exigir muitos recursos a mais do que o rastreamento incremental exigiria. Isso poderá afetar o serviço recebido pelos usuários.
Monitorando servidores Web
| Observação: |
|---|
As informações nesta seção não se aplicam ao Microsoft Search Server 2008 Express. Estas informações aplicam-se apenas à versão completa do Microsoft Search Server 2008. |
Para maximizar o desempenho de pesquisa do Search Server 2008, analise todo o sistema. Crie uma linha de base investigando completamente os servidores. Reexecute periodicamente os testes de desempenho para observar antecipadamente qualquer alteração ou problema de diagnóstico. Ao fazer uma otimização, você poderá usar a linha de base para caracterizar as melhorias resultantes. As seções a seguir listam contadores de monitoramento de desempenho e os dados disponíveis em outras ferramentas, os quais são relevantes ao desempenho do Search Server 2008.
| Observação: |
|---|
Para obter mais informações sobre o monitoramento geral do sistema, consulte Monitorando o desempenho (em inglês) (https://go.microsoft.com/fwlink/?linkid=105584&clcid=0x416) (em inglês). |
No Search Server 2008, os servidores Web enviam respostas para as consultas de pesquisa dos usuários. O desempenho do servidor Web, portanto, tem efeito direto no desempenho da pesquisa. Os servidores Web também afetam a indexação. Isso porque o rastreador indexa o conteúdo enviando solicitações aos 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 do processador. Ele mede a proporção de tempo que os processadores usam para executar threads não ociosos. Se esse contador atingir uma média acima de 80% durante períodos prolongados, os processadores poderão encontrar afunilamentos e você precisará 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 para o serviço Web. Nos servidores do Search Server 2008, essa contagem inclui todos os usuários simultâneos e, durante a indexação, o rastreador. Use esse contador para criar o perfil de padrões de uso e determinar os horários de pico. Não há nenhum limite para esse contador; valores muito altos podem indicar desempenho excelente.
Observação:Em um farm do Servidor de Pesquisa com vários servidores Web, esse contador mede as conexões em apenas um servidor. Para obter informações sobre como monitorar atividades de usuários no farm inteiro, consulte Monitorando o Servidor de Pesquisa com Diagnósticos do SharePoint.
Monitorando servidores de banco de dados
| Observação: |
|---|
As informações nesta seção não se aplicam ao Microsoft Search Server 2008 Express. Estas informações aplicam-se apenas à versão completa do Microsoft Search Server 2008. |
O Search Server 2008 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 de tempo decorrido e que o disco utilizou atendendo as solicitações de leitura e gravação. Monitore esse contador no disco que contém o banco de dados de pesquisa. Se o contador atingir frequentemente uma média superior a 90%, o disco poderá representar um afunilamento para a pesquisa.
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.
Observação: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 em que uma página de banco de dados permanece no pool de buffers sem referências. Ele deve permanecer acima dos 300 segundos. Valores menores que 300 segundos representam um diagnóstico de afunilamento de memória e devem sustentar a análise de um aumento de memória no servidor.
| Observação: |
|---|
Uma descrição completa da otimização geral do SQL Server está além do escopo deste artigo sobre o Search Server 2008. Para obter mais informações, consulte os seguintes recursos:
|
Monitorando servidores de indexação
| Observação: |
|---|
As informações nesta seção não se aplicam ao Microsoft Search Server 2008 Express. Estas informações aplicam-se apenas à versão completa do Microsoft Search Server 2008. |
No Search Server 2008, 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.
| Observação: |
|---|
O servidor de indexação nem sempre pode ser colocado em um servidor separado, dependendo do número de servidores disponíveis. |
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 Servidor de Pesquisa com Diagnósticos do SharePoint
| Observação: |
|---|
As informações nesta seção não se aplicam ao Microsoft Search Server 2008 Express. Estas informações aplicam-se apenas à versão completa do Microsoft Search Server 2008. |
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.
| Observação: |
|---|
O SPDiag faz parte do Microsoft SharePoint Administration Toolkit v3.0 (em inglês) (https://go.microsoft.com/fwlink/?linkid=141504&clcid=0x416) (em inglês). |
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.
| Observação: |
|---|
Para usar o SPDiag eficientemente, leia o artigo sobre o guia do usuário da Ferramenta de Diagnóstico do SharePoint (SPDiag) (em inglês) (https://go.microsoft.com/fwlink/?linkid=141204&clcid=0x416) (em inglês). |
Use os seguintes contadores no âmbito de todo o farm para investigar a rapidez de resposta do farm do Search Server 2008:
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.
Observação: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 no período de 1 segundo. Em um farm com 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 Search Server 2008. 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 os logs ULS para diagnosticar atrasos no desempenho de pesquisas. Nos logs ULS, é possível diagnosticar quais estágios do processo de pesquisa consomem a maior parte do tempo e atrasam o retorno de resultados para o usuário. Use os logs ULS também para avaliar as melhorias de desempenho obtidas por meio de pequenas alterações na configuração do sistema.
| Observação: |
|---|
Use os logs ULS com parcimônia, para não prejudicar o desempenho nem o uso do espaço em disco. Após diagnosticar problemas de desempenho com o ULS, você pode maximizar o desempenho desabilitando os logs ULS. Armazene os logs ULS em um disco que tenha bastante espaço. |
| Observação: |
|---|
Para obter mais informações e exemplos adicionais de consultas para usar no Log Parser 2.2, consulte o artigo sobre como explorar os logs ULS para detectar latência de consultas (em inglês) (https://go.microsoft.com/fwlink/?linkid=148540&clcid=0x416) (em inglês) no Microsoft Enterprise Search Blog. |
Configurando o Serviço de Log Unificado
Comece pela configuração do ULS no site de Administração Central do Search Server 2008.
.gif "Importante") Importante: |
|---|
A associação ao grupo Administradores de Farm é necessária para a conclusão do procedimento a seguir. |
Para configurar o Serviço de Log Unificado de modo a diagnosticar problemas de desempenho de pesquisa
Clique em Iniciar, em Todos os Programas, em Microsoft Search Server e, por fim, em Administração Central do SharePoint 3.0.
Clique na guia Operações.
Na seção Log e Relatório, clique em Log de diagnóstico.
Na seção Otimização de Evento, na lista Selecionar uma categoria, clique em MS Search Query Processor.
Em Evento menos crítico a ser relatado no log de rastreamento, clique em Alto.
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 Search Server 2008 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:%'
| Observação: |
|---|
Você pode digitar o texto da consulta SQL diretamente no prompt de comando do Log Parser. Como alternativa, é possível salvar a consulta em um arquivo de texto e usar o parâmetro file: para passar o local da consulta ao Log Parser. Isso é útil para consultas mais longas ou complexas e para aquelas que você espera usar com frequência. |
Pesquisar mensagens nos logs ULS
Quando o ULS é configurado conforme descrito anteriormente, as seguintes mensagens serão exibidas 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, com exceção da 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:%'
É possível importar o arquivo CSV resultante no Microsoft Office Excel ou em outra ferramenta de análise para criar gráficos e relatórios. Considere que, em um sistema ocupado, ocorrem muitas consultas. Por isso, você talvez precise obter as médias sobre os muitos resultados para gerar uma análise que faça sentido.
Analisando repetições
Os dados de tempo disponíveis na mensagem Execução de consulta concluída com intervalos não incluem nenhuma informação sobre repetições — por exemplo, repetições causadas pela filtragem de segurança. Para analisar a quantidade de tempo que o processador gasta com repetições, compare o número total de consultas com o número de repetições de diferentes tipos.
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 o atraso provocado pelas repetições nos resultados da consulta. Quando o número de repetições é uma proporção significativa do número total de consultas, você deve considerar a revisão da configuração. Por exemplo, se apenas uns poucos usuários podem acessar os documentos nas fontes de conteúdo, isso pode aumentar o número de repetições por filtragem de segurança. Considere a remoção dessa fonte de conteúdo do índice.
Otimizando o SQL Server para Search Server 2008
O Servidor de Pesquisa da Microsoft 2008 usa o Microsoft SQL Server para armazenar conteúdo, informações de configuração e propriedades de conteúdo indexado. Otimize o SQL Server para garantir um ótimo desempenho no Search Server 2008.
| Observação: |
|---|
O Search Server 2008 pode usar bancos de dados armazenados no SQL Server 2008 ou no SQL Server 2005. |
Otimização geral do SQL Server
| Observação: |
|---|
As informações nesta seção não se aplicam ao Microsoft Search Server 2008 Express. Estas informações aplicam-se apenas à versão completa do Microsoft Search Server 2008. |
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 Search Server 2008.
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.
| Observação: |
|---|
Uma descrição completa da otimização geral do SQL Server está além do escopo deste artigo sobre o Search Server 2008. Para obter mais informações, consulte os seguintes recursos:
|
Otimizando o SQL Server para indexação e consultas de pesquisa
Uma prioridade alta para administradores do Search Server 2008 é a otimização de rastreamento, indexação e consultas. O índice de conteúdo do Servidor de Pesquisa é armazenado no sistema de arquivos, fora de qualquer banco de dados do SQL Server. Entretanto, o banco de dados de pesquisa armazena metadados de arquivos indexados e ACLs. Como consequência, o desempenho do SQL Server afeta diretamente duas operações de pesquisa:
Indexação, quando o Servidor de Pesquisa armazena metadados e ACLs.
Consultas. Todas as consultas do Servidor de Pesquisa envolvem a filtragem de segurança, durante a qual o Servidor de Pesquisa 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.
Você deve começar cumprindo as recomendações gerais de otimização do SQL Server, fornecidas anteriormente neste artigo. No entanto, as seguintes otimizações beneficiam especificamente a indexação e a 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.
| Observação: |
|---|
Para obter mais informações sobre a otimização de tempdb, consulte o artigo sobre otimização do desempenho de tempdb (https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x416). |
Use grupos de arquivos para aprimorar o desempenho.
O processo de rastreamento e indexação do Search Server 2008 usa E/S com intensidade e grava um volume grande de dados no banco de dados de pesquisa. Se o sistema apresentar horários de pico significativos, agende a execução da indexação durante esses períodos para garantir que a indexação não dispute recursos com as consultas de usuários. Entretanto, em algumas organizações com atividades globais ou ininterruptas, não há quedas substanciais da demanda. Se o servidor de banco de dados que hospeda o banco de dados de pesquisa se aproximar da capacidade de E/S, considere outras maneiras de separar as operações de E/S da indexação daquelas associadas às consultas do usuário.
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 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 obter a melhoria de desempenho. Mova as tabelas envolvidas na indexação para o grupo de arquivos usando o seguinte procedimento. Esse procedimento pode exigir um tempo considerável, dependendo do tamanho do banco de dados de pesquisa. Conclua o procedimento quando a demanda estiver baixa.
| Observação: |
|---|
Para obter mais informações sobre como usar grupos de arquivos para o banco de dados de pesquisa, inclusive scripts Transact-SQL para mover tabelas, consulte o artigo sobre pesquisa e grupos de arquivos SQL (em inglês) (https://go.microsoft.com/fwlink/?linkid=132066&clcid=0x416) (em inglês). |
Para separar tabelas de indexação em um grupo de arquivos dedicado
No SQL Server Management Studio, clique com o botão direito do mouse no banco de dados de pesquisa e clique em Propriedades.
Na lista Selecionar uma página, clique em Grupos de arquivos.
Clique em Adicionar e nomeie o novo grupo de arquivos como "GrupodeArquivosdeRastreamento”.
Na lista Selecionar uma página, clique em Arquivos.
Clique em Adicionar e forneça um nome para o novo arquivo.
Na célula Grupo de Arquivos, selecione CrawlFileGroup.
Na célula Caminho, selecione um caminho em um disco físico separado no grupo de arquivos PRIMARY.
Clique em OK.
No SQL Server Management Studio, clique em Nova Consulta.
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 endNo SQL Server Management Studio, clique em Nova Consulta.
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
Assim como qualquer sistema complexo, os bancos de dados do SQL Server exigem manutenção regular para preservar o desempenho no nível mais alto. Nessa seção, você verá algumas práticas recomendadas para manter o máximo 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 regularmente a rotina Transact-SQL do
DBCC CHECKDBem todos os bancos de dados. Entretanto, essa rotina acarreta uma carga significativa no computador que executa o SQL Server e pode afetar a capacidade de resposta. Portanto, use a opçãoPHYSICAL_ONLYe agendeDBCC CHECKDBpara os horários de pico. Não execute essa rotina durante um rastreamento.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 Servidor de Pesquisa. 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 Servidor de Pesquisa. 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.
| Observação: |
|---|
Para obter o script |
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 Servidor de Pesquisa. 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.
| Observação: |
|---|
Para obter o script |
Se você diagnosticar um afunilamento de disco ou de RAID em um servidor de banco de dados do farm, as seguintes ações poderão reduzir o efeito do problema:
Realoque arquivos de dados e logs de transação para separar discos ou matrizes RAID. Como descrito anteriormente neste artigo, o uso de grupos de arquivos maximiza o desempenho.
Adicione discos à matriz RAID, se houver uma.
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 Search Server 2008. 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 obstáculo importante à velocidade de indexação é a privação do rastreador. O rastreador fica em um estado de privação quando ele não pode alocar outro thread para recuperar o próximo documento 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, esses hosts são conhecidos como "monopolizadores" porque consomem muitos recursos.
Backups executados simultaneamente ao rastreamento
Hosts que consomem muitos 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
Você pode minimizar a privação do rastreador usando as seguintes 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 que consome muitos recursos.
Como ponto de partida, agende quatros rastreamentos simultâneos. É possível aumentar esse número para alguns servidores de índice. Consulte a próxima seção para obter mais informações.
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 no Search Server 2008, crie a configuração do rastreador adicionando novas fontes de conteúdo durante vários dias ou semanas. Monitore o desempenho do sistema à medida que adicionar cada fonte de conteúdo para evitar a privação e facilitar a solução de problemas. Dessa forma, você obtém um amplo entendimento 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 |
4 vezes o número de processadores |
Número de processadores mais 4 |
Máximo |
16 vezes o número de processadores |
Número de processadores mais 4 |
No Search Server 2008, 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. É possível diagnosticar isso por meio do 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 em 500 para a instância Portal_Content ou em 50 para a instância ProfileImport, o rastreador estará em privação. Considere o ajuste do servidor de banco de dados, conforme descrito em Otimizando o SQL Server para Search Server 2008, 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 Search Server 2008 rastreia e indexa uma fonte de conteúdo, ele verifica as ACLs (Listas de Controle de Acesso) e as armazena no banco de dados de pesquisa. Quando os usuários pesquisam o índice, o banco de dados de pesquisa é verificado para cada resultado, para garantir que o usuário esteja autorizado a acessar o resultado. Esse processo é conhecido como filtragem de segurança. ACLs grandes com muitos níveis de aninhamento podem afetar negativamente o desempenho do processo de rastreamento e das pesquisas no Servidor de Pesquisa. Esta seção descreve como minimizar essa degradação de 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 Servidor de Pesquisa:
Contas de usuário
Grupos globais
Grupos locais de domínios
Grupos universais
No Servidor de Pesquisa, também há grupos do SharePoint. Esse sistema é muito flexível e pode incluir várias camadas de aninhamento. No entanto, se você usá-lo sem muito cuidado, as entidades de segurança poderão afetar negativamente o desempenho da pesquisa.
Para garantir o desempenho máximo do rastreador e das pesquisas do Servidor de Pesquisa, 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 nos grupos universais e os grupos universais no grupos locais de domínio.
Coloque os grupos locais de domínio nos Grupos do SharePoint para atribuir permissões para sites e outros recursos do SharePoint.
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 da pesquisa e devem ser evitadas:
Não atribua permissões de site do Servidor de Pesquisa a usuários individuais.
Os sites do Servidor de Pesquisa ficam lentos quando mais de 2.000 entidades de segurança estão listadas na DACL do site. Entretanto, um grupo do Active Directory ou um grupo do SharePoint corresponde a uma única entidade de segurança, independentemente do número de usuários que ele contenha. Assim, use grupos do SharePoint para atribuir permissões de site e coloque os usuários ou os grupos do Active Directory nos 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 Servidor de Pesquisa, 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.
Contatos do Active Directory podem ser adicionados a grupos para, por exemplo, distribuição de emails. Os contatos, porém, não são entidades de segurança e não estão envolvidos em autorização. O desempenho poderá ser reduzido se você atribuir permissão a um grupo que contém contatos.
No Servidor de Pesquisa, o proprietário de cada site pode adicionar usuários e grupos à DACL do site. É importante que os proprietários de sites sejam instruídos sobre como usar as associações de maneira responsável para evitar a criaçã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 Search Server 2008 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 com 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 Servidor de Pesquisa, devido a uma interrupção no serviço ou porque os administradores o colocaram offline.
Consulte também
Preparando-se para rastrear conteúdo (Search Server 2008)
Ajudando os usuários a fazerem consultas bem-sucedidas (Search Server 2008)
Protegendo e restaurando o farm (Search Server 2008)
Permissões para operações administrativas comuns (Search Server 2008)
Planejar para rastrear conteúdo (Search Server 2008)