Procedure consigliate per ottimizzare le prestazioni di ricerca (Office SharePoint Server 2007)

In questo articolo sono illustrate alcune procedure consigliate che possono essere utilizzate per garantire un sistema di ricerca integro ed efficiente in Microsoft Office SharePoint Server 2007.

Contenuto dell'articolo:

• Motivi per avviare una ricerca per indicizzazione completa

• Monitoraggio dei server Web

• Monitoraggio dei server di database

• Monitoraggio dei server di indicizzazione

• Monitoraggio di Office SharePoint Server con lo strumento di diagnostica di SharePoint

• Utilizzo dei registri del Servizio di registrazione unificato per diagnosticare i colli di bottiglia delle query

• Ottimizzazione di SQL Server per la ricerca in Office SharePoint Server 2007

• Manutenzione dei database SQL Server per la ricerca

• Come evitare l'interruzione del crawler

• Come evitare i colli di bottiglia causati dagli elenchi di controllo di accesso

• Risoluzione dei problemi relativi alle web part Casella di ricerca mancanti

Motivi per avviare una ricerca per indicizzazione completa

La ricerca per indicizzazione e l'indicizzazione di un elevato volume di informazioni, documenti e pagine Web richiede una quantità significativa di elaborazione da parte del computer. Il processo di ricerca per indicizzazione utilizza inoltre le capacità di rete e altre risorse. È quindi necessario configurare con attenzione una farm Microsoft Office SharePoint Server 2007 per garantire che i processi di ricerca per indicizzazione e indicizzazione non influiscano negativamente sul servizio offerto agli utenti. Ad esempio, il contenuto viene solitamente sottoposto a ricerca per indicizzazione e indicizzazione durante le fasce orarie non di punta, quando l'utilizzo dei server è limitato, allo scopo di preservare i servizi nelle ore di punta per gli utenti.

Un modo per ridurre l'impatto della ricerca per indicizzazione consiste nel pianificare ricerche per indicizzazione incrementali anziché complete. In una ricerca per indicizzazione incrementale vengono indicizzati solo gli elementi che sono stati modificati, pertanto il processo richiede una quantità nettamente inferiore di risorse del computer. È possibile pianificare ricerche per indicizzazione complete e ricerche per indicizzazione incrementali in ogni origine del contenuto. Ad esempio, è possibile scegliere di eseguire le ricerche per indicizzazione incrementali a mezzanotte nei giorni lavorativi e le ricerche per indicizzazione complete a mezzanotte del sabato.

Per verificare che l'indice sia completo, è necessario avviare manualmente una ricerca per indicizzazione completa nelle circostanze seguenti:

• Quando gli amministratori hanno applicato un aggiornamento o un Service Pack ai server nella farm.

• Quando gli amministratori hanno aggiunto una nuova proprietà gestita alla configurazione della ricerca.

• Quando gli amministratori hanno aggiunto o modificato una regola di ricerca per indicizzazione.

• Quando si desidera indicizzare di nuovo pagine ASP.NET in siti Microsoft Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 o Server di ricerca 2008. Il crawler non è in grado di rilevare quando queste pagine Web vengono modificate, pertanto solo con una ricerca per indicizzazione completa è possibile indicizzarle di nuovo.

• Quando si sono verificati errori consecutivi nelle ricerche per indicizzazione incrementali. Se in una ricerca per indicizzazione incrementale si verifica un errore per cento volte consecutive a qualsiasi livello di un archivio, il server di indicizzazione rimuove il contenuto interessato dall'indice.

• Quando gli amministratori hanno riparato un indice danneggiato.

• Quando un amministratore ha creato un mapping di nomi server.

• Quando le autorizzazioni per il contenuto sono state modificate mentre il contenuto stesso non è cambiato e ai server non è stato applicato il pacchetto hotfix Post-Service Pack 1 (KB941442) o un Service Pack successivo. Senza questo pacchetto hotfix, le ricerche per indicizzazione incrementali non verificano gli elenchi di controllo di accesso (ACL). In questo caso un utente può visualizzare un elemento nei risultati della ricerca anche se l'amministratore ha rimosso l'autorizzazione per tale utente dopo l'ultima ricerca per indicizzazione completa.

Nelle circostanze seguenti Microsoft Office SharePoint Server 2007 esegue una ricerca per indicizzazione completa al posto di una ricerca per indicizzazione incrementale pianificata o avviata manualmente:

• Quando un amministratore ha interrotto manualmente la ricerca per indicizzazione precedente.

• Quando un amministratore ha ripristinato un database del contenuto da un backup.

  Nota

  Se è stato installato l'Aggiornamento dell'infrastruttura per Microsoft Office Servers, è possibile specificare se un'operazione di ripristino causerà l'esecuzione di una ricerca per indicizzazione completa utilizzando opzioni dello strumento da riga di comando Stsadm.

• Quando un amministratore ha scollegato e ricollegato un database del contenuto.

• Quando non è mai stata eseguita una ricerca per indicizzazione completa del contenuto in Office SharePoint Server.

• Quando il registro delle modifiche non contiene informazioni per gli indirizzi inclusi nella ricerca per indicizzazione. Il registro delle modifiche viene utilizzato per determinare se un elemento è stato modificato rispetto all'ultima ricerca per indicizzazione. Senza le informazioni del registro delle modifiche non è possibile eseguire ricerche per indicizzazione incrementali.

• Quando l'account utilizzato per accedere al contenuto è stato modificato. Tale account può essere quello di accesso predefinito o uno specificato nella regola di ricerca per indicizzazione.

• Quando un indice si è danneggiato.

È necessario valutare attentamente le azioni eseguite in queste circostanze, poiché se si avvia manualmente una ricerca per indicizzazione o tramite una pianificazione, è possibile che la ricerca per indicizzazione completa richieda una quantità nettamente superiore di risorse rispetto a una ricerca per indicizzazione incrementale. Ciò può incidere negativamente sul servizio offerto agli utenti.

Monitoraggio dei server Web

Per ottimizzare le prestazioni di ricerca di Microsoft Office SharePoint Server 2007, analizzare accuratamente il sistema. È consigliabile creare una linea di base eseguendo un esame approfondito dei server ed eseguire test periodici delle prestazioni per individuare eventuali modifiche e diagnosticare prontamente eventuali problemi. Quando si esegue un'ottimizzazione, è possibile utilizzare la linea di base per caratterizzare i miglioramenti risultanti. Nelle sezioni seguenti sono elencati i contatori del monitor di prestazioni e i dati disponibili da altri strumenti che sono pertinenti per le prestazioni di Microsoft Office SharePoint Server 2007.

In Microsoft Office SharePoint Server 2007 i server Web ospitano tutti i siti e le raccolte siti. Ottengono il contenuto archiviato nei server di database e rispondono alle richieste degli utenti. Le prestazioni dei server Web hanno un impatto diretto sulle prestazioni della ricerca poiché tali server inviano le risposte alle query di ricerca degli utenti. I server Web incidono anche sull'indicizzazione in quanto il crawler indicizza il contenuto di Office SharePoint Server inviando richieste ai server Web.

Per monitorare l'integrità dei server Web, utilizzare i contatori del monitor di prestazioni:

• Processore/% Tempo processore/_Totale

  Questo contatore è l'indicatore principale dell'attività del processore e misura la percentuale del tempo che il processore impiega per eseguire un thread attivo. Se la media di questo contatore è superiore all'80% per periodi di tempo prolungati, è possibile che i processori costituiscano un collo di bottiglia ed è consigliabile un aggiornamento.

• Memoria/MByte disponibili

  Questo contatore misura la memoria fisica immediatamente disponibile per i processi o il sistema. Se il valore di questo contatore diventa eccessivamente basso, il sistema si rallenterà in quanto utilizzerà una quantità maggiore di paging. È consigliabile aggiungere altra memoria al server.

• Servizio Web/Connessioni correnti

  Questo contatore misura il numero di connessioni al servizio Web. Nei server Web Microsoft Office SharePoint Server 2007 questo conteggio include tutti gli utenti simultanei e, durante l'indicizzazione, il crawler. Utilizzare questo contatore per delineare modelli di utilizzo e determinare le ore di punta. Non esiste un limite per questo contatore. Valori molto elevati possono indicare prestazioni eccellenti.

  Nota

  In una farm Office SharePoint Server con più server Web questo contatore misura le connessioni su un solo server. Per ulteriori informazioni sul monitoraggio dell'attività degli utenti nell'intera farm, vedere Monitoraggio di Office SharePoint Server con il servizio di diagnostica di SharePoint.

Monitoraggio dei server di database

Microsoft Office SharePoint Server 2007 utilizza Microsoft SQL Server 2005 o Microsoft SQL Server 2008 per archiviare i database del contenuto. Sebbene il server di indicizzazione archivi l'indice di contenuto nel file system anziché in un database, archivia i metadati del documento e le autorizzazioni nel database di ricerca. Poiché molte ricerche controllano i metadati e tutte le ricerche includono la limitazione per motivi di protezione, le prestazioni dei server di database incidono direttamente sulle prestazioni della ricerca.

Per monitorare l'integrità dei server di database, utilizzare i contatori del monitor di prestazioni:

• Processore/% Tempo processore/_Totale

  Questo contatore è l'indicatore principale dell'attività del processore ed è, pertanto, altrettanto importante nei server di database quanto nei server Web.

• **Disco logico/% Tempo disco/**Nome disco

  Questo contatore misura la percentuale del tempo che il processore impiega per eseguire le richieste di lettura o scrittura. Per la ricerca, monitorare questo contatore per il disco in cui è presente il database di ricerca. Se la media di questo contatore è superiore al 90%, è possibile che il disco costituisca un collo di bottiglia per la ricerca.

• Sistema: Lunghezza coda processore

  La media di questo contatore deve essere inferiore del numero di CPU core del server moltiplicato per due.

• Memoria: MByte disponibili

  Verificare che la media di questo contatore sia almeno il 20% della RAM fisica totale.

• Memoria: Pagine/sec

  La media di questo contatore deve essere inferiore a 100.

• Disco logico: Trasferimenti disco/sec

  Questo contatore misura la velocità effettiva totale per una partizione.

• Disco logico: Byte letti da disco/sec e Byte scritti su disco/sec

  Questo contatore misura la larghezza di banda totale di un disco specifico.

• Disco logico: Media letture disco/sec

  Anche definito come latenza di lettura, questo contatore indica il tempo necessario affinché il disco recuperi i dati. Una latenza di lettura bassa è importante per garantire buone velocità di risposta alle query degli utenti.

• Disco logico: Media scritture disco/sec

  Anche definito come latenza di scrittura, questo contatore indica il tempo necessario affinché il disco scriva i dati. Una latenza di scrittura bassa migliora le prestazioni dell'indicizzazione.

• **Disco logico/% Tempo lettura disco/**Nome disco

  Questo contatore misura la percentuale del tempo che il processore impiega per eseguire le richieste di lettura. Una percentuale elevata di richieste di lettura per il disco del database di ricerca può indicare che gli utenti eseguono un numero elevato di ricerche.

• **Disco logico/% Tempo scrittura disco/**Nome disco

  Questo contatore misura la percentuale del tempo che il processore impiega per eseguire le richieste di scrittura. Una percentuale elevata di richieste di scrittura per il disco del database di ricerca è prevista durante il processo di indicizzazione.

  Nota

  Se possibile, ottimizzare le prestazioni della richiesta spostando il database di ricerca in un disco diverso rispetto agli altri database. Se il database di ricerca viene separato in questo modo, i contatori del disco logico consentono di diagnosticare con efficacia le prestazioni della ricerca poiché il disco è dedicato esclusivamente alla ricerca.

• SQLServer:Gestione buffer/Permanenza presunta delle pagine

  Questo contatore misura il numero di secondi in cui una pagina del database resta nel pool del buffer senza riferimenti. Il valore di riferimento è di almeno 300 secondi. Valori inferiori a 300 secondi indicano un collo di bottiglia della memoria e rendono opportuna l'aggiunta di memoria al server.

Monitoraggio dei server di indicizzazione

In Microsoft Office SharePoint Server 2007 i server di indicizzazione eseguono la ricerca per indicizzazione e creano un file di indice. Quando il processo di ricerca per indicizzazione è completo, l'indice viene propagato ai server di query che rispondono alle richieste di ricerca degli utenti.

Se le prestazioni del server di indicizzazione sono insufficienti, è possibile che non si verifichino conseguenze dirette per gli utenti, tuttavia il processo di ricerca per indicizzazione si allungherà, in alcuni casi fino al punto di non poter limitare la ricerca per indicizzazione agli orari non di punta e separare la ricerca per indicizzazione da altre attività da eseguire in orari non di punta come il backup.

Per monitorare l'integrità dei server di indicizzazione, utilizzare i contatori del monitor di prestazioni durante una ricerca per indicizzazione:

• Plug-in di archiviazione servizio di ricerca di Office Server/Totale documenti prima coda/Portal_Content

  Questo contatore misura il numero di documenti nella prima coda del plug-in di archiviazione, che deve essere inferiore a 500 durante una ricerca per indicizzazione e molto basso in altri momenti. Se il valore del contatore è superiore a 500, è probabile che l'unità del database di ricerca nel server di database sia un collo di bottiglia.

• Plug-in di archiviazione servizio di ricerca di Office Server/Totale documenti seconda coda/Portal_Content

  Questo contatore misura il numero di documenti nella seconda coda del plug-in di archiviazione. Analogamente al contatore precedente, il valore di questo contatore deve essere inferiore a 500 durante una ricerca per indicizzazione.

• Servizio Gatherer del servizio di ricerca di Office Server/Thread inattivi

  Questo contatore misura il numero di thread nel processo del servizio Gatherer in attesa di documenti. Se il valore di questo contatore è 0, il servizio Gatherer è in attesa di risorse. Può essere opportuno ridurre il numero di ricerche per indicizzazione simultanee.

• Servizio Gatherer del servizio di ricerca di Office Server/Thread che accedono alla rete

  Questo contatore misura il numero di thread nel processo del servizio Gatherer che hanno inviato richieste a un archivio dati remoto e sono in attesa di risposta o stanno elaborando la risposta. Se il valore di questo contatore è spesso elevato, la larghezza di banda della rete potrebbe costituire un collo di bottiglia oppure il server di indicizzazione potrebbe essere connesso a uno o più host lenti per indicizzare il contenuto.

• Servizio Gatherer del servizio di ricerca di Office Server/Thread di filtraggio

  Questo contatore misura il numero di thread che hanno recuperato contenuto e lo stanno filtrando. Se questo numero è elevato, può indicare che le risorse nel server di indice stanno causando un collo di bottiglia.

• Servizio Gatherer del servizio di ricerca di Office Server/Thread per plug-in

  Questo contatore misura il numero di thread che hanno recuperato contenuto e lo stanno elaborando tramite plug-in quali i filtri IFilter. In questa fase del processo di ricerca per indicizzazione l'indice e il database di ricerca vengono popolati.

• Servizio Gatherer del servizio di ricerca di Office Server/Ricerche per indicizzazione in corso

  Questo contatore misura il numero di ricerche per indicizzazione in corso. Questo valore deve corrispondere al numero di origini di contenuto per cui sono pianificate ricerche per indicizzazione, a meno che un amministratore non abbia avviato manualmente una ricerca per indicizzazione.

Monitoraggio di Office SharePoint Server con il servizio di diagnostica di SharePoint

Lo strumento di diagnostica di SharePoint v1.0 (anche noto come SPDiag) è uno strumento avanzato di diagnostica e analisi che presenta una vasta gamma di informazioni relative a qualsiasi server o farm che esegue Prodotti e tecnologie SharePoint. È possibile utilizzare SPDiag per visualizzare snapshot molto dettagliate delle configurazioni del server e della farm. È inoltre possibile unire e visualizzare informazioni da IIS, dai registri ULS e dai registri eventi, nonché esaminare problemi legati alle prestazioni, ad esempio una gestione lenta delle richieste.

SPDiag può mostrare grafici dei contatori delle prestazioni da qualsiasi server della farm e include anche vari contatori che misurano i dati in tutta la farm sulla base dei registri IIS. Un'analisi di questo tipo per tutta la farm non è possibile utilizzando solo Performance Monitor.

Utilizzare i contatori seguenti in tutta la farm per valutare i tempi di risposta della farm Microsoft Office SharePoint Server 2007:

• SharePointRequests/Number of unique client IP

  Questo contatore misura il numero di client univoci che hanno effettuato richieste nel periodo di tempo specificato. I client che accedono alla farm tramite un server proxy risultano con un singolo indirizzo IP.

• SharePointRequests/Number of unique client agents

  Questo contatore misura il numero di agenti client univoci (browser) che hanno effettuato richieste nel periodo di tempo specificato. Questo contatore può risultare diverso nei client che accedono alla farm tramite un server proxy poiché è basato sull'agente specificato nelle richieste HTTP del browser.

  Nota

  I contatori seguenti misurano il numero di richieste, che includono sia le query di ricerca che le richieste di contenuto.

• SharePointRequests/Total requests

  Questo contatore misura la variazione del numero totale di richieste nel periodo di tempo specificato. Per poter determinare la percentuale di richieste veloci o lente, è necessario monitorare questo contatore insieme a quelli riportati di seguito.

• SharePointRequests/Number of requests with time taken < 1 second

  Questo contatore misura il numero di richieste soddisfatte entro 1 secondo. In una farm efficiente, il valore di questo contatore è vicino a quello del contatore Total requests.

• SharePointRequests/Number of requests with time taken 1-5 seconds

  Questo contatore misura il numero di richieste soddisfatte entro un intervallo da 1 a 5 secondi. Questo tipo di prestazioni è in genere considerato accettabile dagli utenti, ma una percentuale crescente di queste richieste nel tempo può indicare lo sviluppo di un collo di bottiglia.

• SharePointRequests/Number of requests with time taken 5-10 seconds

  Questo contatore misura il numero di richieste soddisfatte entro un intervallo da 5 a 10 secondi. È possibile che gli utenti facciano clic in un'altra pagina prima che i risultati vengano restituiti.

• SharePointRequests/Number of requests with time taken > 10 seconds

  Questo contatore misura il numero di richieste soddisfatte dopo oltre 10 secondi. Se queste richieste costituiscono una percentuale elevata del valore Total requests, la farm non è disponibile ed è necessario esaminare i colli di bottiglia, nonché valutare l'aggiornamento dell'hardware.

Utilizzo dei registri del Servizio di registrazione unificato per diagnosticare i colli di bottiglia delle query

È possibile utilizzare il Servizio di registrazione unificato (ULS) per monitorare e ottimizzare le prestazioni del sistema Microsoft Office SharePoint Server 2007. Questo servizio può essere utilizzato quale uno dei metodi di ottimizzazione del sistema. Altri metodi sono Performance Monitor, i registri degli eventi e i registri Web.

In questa sezione verrà illustrato come utilizzare i registri ULS per diagnosticare ritardi nelle prestazioni delle ricerche. Utilizzando i registri ULS, è possibile diagnosticare quali fasi del processo di ricerca impiegano più tempo e ritardano la restituzione dei risultati agli utenti. È consigliabile utilizzare i registri ULS anche per valutare i miglioramenti delle prestazioni ottenuti mediante piccole modifiche alla configurazione del sistema.

Configurazione del Servizio di registrazione unificato

Iniziare configurando il servizio ULS nel sito Web Amministrazione centrale di Microsoft Office SharePoint Server 2007.

Per configurare il Servizio di registrazione unificato per diagnosticare i problemi di prestazioni nelle ricerche

1. Fare clic sul pulsante Start, scegliere Tutti i programmi, Microsoft Office Server e quindi fare clic su Amministrazione centrale SharePoint 3.0.

2. Fare clic sulla scheda Operazioni.

3. Nella sezione Registrazione e report fare clic su Registrazione diagnostica.

4. Nella sezione Limitazione eventi fare clic su Sistema di elaborazione delle query MS Search nell'elenco Selezionare una categoria.

5. In Evento meno critico da includere nel registro di traccia fare clic su Livello di traccia alto.

6. Nella parte inferiore della pagina fare clic su OK.

Utilizzo dello strumento Log Parser

Analogamente ai registri IIS, i registri ULS Microsoft Office SharePoint Server 2007 sono file di testo molto estesi. Per analizzare il contenuto di tali file, utilizzare un'utilità di analisi dei registri che consenta di concentrare l'attenzione sulle tracce più interessanti e di formattare i dati. Lo strumento Microsoft Log Parser 2.2(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=148542&clcid=0x410) è gratis ed è una soluzione ideale per questo scopo.

Lo strumento Log Parser è un programma della riga di comando. È necessario utilizzare i parametri seguenti per indicare che i registri ULS sono file di testo Unicode con valori separati da tabulazioni:

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

Oltre a questi parametri, è necessario fornire una query di tipo Transact-SQL che indichi a Log Parser come analizzare il file di registro. Ad esempio, per concentrare l'attenzione sui messaggi del timer del processore, utilizzare la clausola WHERE seguente:

WHERE Category = 'MS Search Query Processor' AND Message LIKE '%Completed query execution with timings:%'

Ricercare messaggi nei registri ULS

Se ULS è configurato come descritto in precedenza, quando gli utenti eseguono le query vengono visualizzati i messaggi seguenti nei file di registro:

• Completed query execution with timings

  Questo messaggio indica che una query è stata completata e include sei intervalli che descrivono la query in millisecondi. I sei intervalli sono descritti di seguito:

  • v1. Il tempo totale impiegato per elaborare la query.

  • v2. La latenza della query misurata dopo l'eliminazione dei duplicati.

  • v3. La latenza della query misurata dopo la limitazione per motivi di protezione.

  • v4. La latenza della query misurata dopo aver unito i risultati dell'indice con quelli del database di ricerca.

  • v5. Il tempo trascorso in attesa dei risultati dal server di indicizzazione.

  • v6. Il tempo trascorso nell'esecuzione di chiamate al database escludendo le proprietà di recupero dal database di ricerca.

  Da questi sei intervalli è possibile calcolare le informazioni seguenti:

  • v1 - v2. Il tempo trascorso recuperando le proprietà ed evidenziando i risultati della ricerca.

  • v2 - v3. Il tempo trascorso per rilevare i duplicati.

  • v3 - v4. Il tempo trascorso nella limitazione per motivi di protezione.

  • v4 - v5. Il tempo trascorso per unire i risultati dell'indice ai risultati del database di ricerca.

• Join retry

  Questo messaggio indica che è stato eseguito un nuovo tentativo poiché i risultati restituiti dal database di ricerca non corrispondevano ai risultati restituiti dall'indice full-text e quindi non potevano essere uniti.

• Security Trimming retry

  Questo messaggio indica che l'utente non è autorizzato a leggere i risultati restituiti dalla query che ha eseguito. Viene quindi eseguito un nuovo tentativo di eseguire tale query, richiedendo un numero maggiore di risultati, fino a ottenere un numero di risultati sufficiente.

• Near duplicate removal retry

  Questo messaggio indica che è stata applicata la limitazione per motivi di protezione a molti documenti virtualmente identici, pertanto il sistema di elaborazione delle query non disponeva di un numero di risultati sufficiente da visualizzare. Viene quindi eseguito un nuovo tentativo di eseguire tale query, richiedendo un numero maggiore di risultati, fino a ottenere un numero di risultati sufficiente.

Analisi degli intervalli delle query

Tra i messaggi descritti in precedenza in questa sezione, il messaggio Completed query execution with timings è quello più utilizzato per diagnosticare i ritardi nell'elaborazione delle query. Ad esempio, se la limitazione per motivi di protezione risulta lenta, il calcolo v3 - v4 costituirà una vasta parte del tempo di elaborazione totale v1.

Per analizzare gli intervalli, passare la query SQL seguente allo strumento Log Parser, che creerà un file con valori separati da virgole con gli intervalli da v1 a v6 e le relative differenze.

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:%'

È possibile importare il file CSV risultante in Microsoft Office Excel o in un altro strumento di analisi per creare grafici e report. Tenere presente che in un sistema con molto traffico vengono eseguite numerose query, pertanto può essere necessario basare le medie su molti risultati per ottenere analisi valide.

Analisi dei tentativi

I dati relativi agli intervalli disponibili nel messaggio Completed query execution with timings non includono informazioni sui tentativi, ad esempio i tentativi causati dalla limitazione per motivi di protezione. Per analizzare il tempo dedicato dal sistema di elaborazione delle query ai tentativi, è necessario confrontare il numero totale di query con il numero di tentativi dei vari tipi.

La query seguente consente di contare il numero totale di query eseguite:

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%'

La query seguente consente di contare il numero totale di tentativi causati dalla limitazione per motivi di protezione:

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%'

La query seguente consente di contare il numero totale di tentativi causati dalla rimozione dei risultati duplicati:

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%'

Utilizzare queste query per diagnosticare il ritardo di restituzione dei risultati causato dai tentativi. Quando il numero di tentativi costituisce una percentuale significativa del numero totale di query, è necessario riesaminare la configurazione. Ad esempio, se solo alcuni utenti possono accedere ai documenti presenti in una delle origini di contenuto, è possibile che il numero di tentativi dovuti alla limitazione per motivi di protezione aumenti. È consigliabile rimuovere questa origine dall'indice.

Ottimizzazione di SQL Server per la ricerca in Office SharePoint Server 2007

Microsoft Office SharePoint Server 2007 utilizza Microsoft SQL Server per archiviare il contenuto, le informazioni di configurazione e le proprietà del contenuto indicizzato. È necessario ottimizzare SQL Server per poter ottenere prestazioni ottimali da Office SharePoint Server.

Ottimizzazione generale di SQL Server

Alcuni tipi di ottimizzazione migliorano le prestazioni di SQL Server indipendentemente dallo scopo del server. È invece necessario accertarsi che queste ottimizzazioni siano adatte a un database Office SharePoint Server.

Quando si pianifica e si distribuisce il server di database, tenere presente i suggerimenti seguenti:

• Se possibile, eseguire SQL Server in un server o una server farm dedicati.

• Implementare la scalabilità orizzontale mediante più server di database in una server farm. In genere è consigliabile installare un server di database per ogni quattro server Web in esecuzione a regime.

• Utilizzare una versione a 64 bit di SQL Server nei computer insieme a sistemi operativi a 64 bit.

• Utilizzare il maggior numero di dischi fisici possibile in base al budget stanziato per l'hardware.

• Utilizzare dischi ad alta velocità.

• Posizionare i database in matrici di dischi RAID 1+0 o RAID 1.

• Posizionare i file di registro in un disco fisico separato in cui non sono archiviati file di dati primari e secondari.

Ottimizzazione di SQL Server per le query di ricerca e l'indicizzazione

Una delle priorità principali per molti amministratori di Microsoft Office SharePoint Server 2007 consiste nell'ottimizzazione della ricerca per indicizzazione, dell'indicizzazione e delle query. L'indice di contenuto di Office SharePoint Server è archiviato nel file system all'esterno di qualsiasi database SQL Server. Nel database di ricerca vengono tuttavia archiviati i metadati dei file indicizzati e degli elenchi di controllo di accesso. Di conseguenza, le prestazioni di SQL Server incidono direttamente sulle due operazioni di ricerca seguenti:

• Indicizzazione, quando Office SharePoint Server archivia metadati ed elenchi di controllo di accesso.

• Esecuzione di query. Tutte le query di Office SharePoint Server includono la limitazione per motivi di protezione, durante la quale Office SharePoint Server verifica gli elenchi di controllo di accesso nel database di ricerca e rimuove i risultati che gli utenti non sono autorizzati a visualizzare. Inoltre, se l'utente ha eseguito una ricerca delle proprietà, i metadati devono inoltre essere recuperati dal database di ricerca.

È consigliabile seguire i suggerimenti per l'ottimizzazione generale di SQL Server illustrati in precedenza in questo articolo, con l'aggiunta delle ottimizzazioni elencate nelle sezioni seguenti che offrono vantaggi in particolare per l'indicizzazione e l'esecuzione di query.

Ottimizzare le prestazioni del database tempdb.

Ogni query eseguita dall'utente implica attività svolte nel database tempdb di SQL Server. Di conseguenza, la configurazione di questo database incide direttamente sulla rapidità di visualizzazione delle risposte della query.

Per ottimizzare il database tempdb, attenersi alla procedura seguente:

• Impostare il modello di recupero su SIMPLE.

• Consentire la crescita automatica dei file tempdb in base alle esigenze.

• Impostare l'incremento di crescita dei file su un valore ragionevole. Di norma, questo incremento deve corrispondere al 10% circa delle dimensioni del file tempdb.

• Preallocare lo spazio per i file tempdb impostando le dimensioni del file su un valore che consenta di gestire tutte le attività durante le ricerche per indicizzazione e l'esecuzione di query.

• Utilizzare più file di dati per ottimizzare la larghezza di banda del disco. Di norma, utilizzare un file di dati per ogni CPU core presente nel computer che esegue SQL Server.

• Creare tutti i file di dati con le stesse dimensioni.

• Posizionare il database tempdb in un disco fisico separato rispetto a quelli in cui sono archiviati i database del contenuto, il database di configurazione e il database di ricerca.

Utilizzare filegroup per migliorare le prestazioni.

La ricerca per indicizzazione e il processo di indicizzazione di Microsoft Office SharePoint Server 2007 richiedono un utilizzo elevato di I/O e scrivono elevati volumi di dati nel database di ricerca. Se nel sistema si verificano periodi in cui l'utilizzo si riduce notevolmente, è consigliabile pianificare l'esecuzione dell'indicizzazione in tali periodi per garantire che non venga eseguita l'indicizzazione per risorse che presentano query degli utenti. In alcune organizzazioni con attività globali o che si estendono su tutte le 24 ore non si verificano tuttavia cali significativi nelle richieste. Se il server di database che ospita il database di ricerca si avvicina alla sua capacità massima di I/O, è opportuno valutare altri modi per separare le operazioni I/O di indicizzazione da quelle associate alle query degli utenti.

Il database di ricerca può essere diviso in tabelle che sono coinvolte nell'indicizzazione e tabelle che sono coinvolte principalmente nelle query degli utenti. Se si separano questi gruppi di tabelle in due dischi fisici, è possibile garantire che l'indicizzazione abbia il minor effetto possibile sulle prestazioni delle query. Sebbene le tabelle di indicizzazione e delle query si trovino in un unico database, è possibile utilizzare la caratteristica dei filegroup di Microsoft SQL Server per attuare questa separazione.

Per questo scopo, creare un filegroup utente in cui è incluso un file di dati secondario. Per ottenere un miglioramento delle prestazioni, è necessario che questo file di dati si trovi su un disco fisico dedicato. Spostare quindi le tabelle coinvolte nell'indicizzazione in tale filegroup utilizzando la procedura seguente, che può richiedere molto tempo, in base alle dimensioni del database di ricerca. È pertanto consigliabile eseguire la procedura quando il livello di richieste è basso.

Per separare le tabelle di indicizzazione in un filegroup dedicato

1. In SQL Server Management Studio fare clic con il pulsante destro del mouse sul database di ricerca e scegliere Proprietà.

2. Nell'elenco Selezione pagina fare clic su Filegroup.

3. Fare clic su Aggiungi e assegnare al nuovo filegroup il nome “CrawlFileGroup”.

4. Nell'elenco Selezione pagina fare clic su File.

5. Fare clic su Aggiungi e assegnare un nome al nuovo file.

6. Nella cella Filegroup selezionare CrawlFileGroup.

7. Nella cella Percorso selezionare un percorso in un disco fisico separato rispetto al filegroup primario.

8. Fare clic su OK.

9. In SQL Server Management Studio fare clic su Nuova query.

10. Copiare la query seguente nella finestra della query e fare clic su Esecuzione. Questo codice Transact-SQL crea una nuova stored procedure che sposta le tabelle nel nuovo filegroup.

    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. In SQL Server Management Studio fare clic su Nuova query.

12. Copiare la query seguente nella finestra della query e fare clic su Esecuzione. Questo codice Transact-SQL esegue la nuova stored procedure per ogni tabella di indicizzazione.

    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'
    

Manutenzione dei database SQL Server per la ricerca

Analogamente ad altri sistemi complessi, i database SQL Server richiedono una manutenzione regolare per mantenere le prestazioni ai massimi livelli. In questa sezione sono illustrate alcune procedure consigliate per mantenere prestazioni ottimali.

Le procedure di manutenzione del disco seguenti consentono di incrementare le prestazioni dei server di database:

• Mantenere libero almeno il 25% dello spazio su disco per consentire la crescita dei database. Monitorare regolarmente le dimensioni del disco e lo spazio libero per evitare un calo di questa percentuale. Se gli amministratori aggiungono nuove origini di contenuto, i database di ricerca possono crescere rapidamente in maniera significativa.

• Se il controller del disco utilizza la cache in scrittura del disco, verificare che sia disponibile una batteria di riserva in modo che un'eventuale interruzione dell'alimentazione non determini l'interruzione del servizio.

Le procedure di manutenzione di SQL Server seguenti consentono di migliorare le prestazioni dei server di database:

• Eseguire regolarmente la routine Transact-SQL DBCC CHECKDB su tutti i database Office SharePoint Server. Questa routine genera tuttavia un carico significativo sul computer con SQL Server e può incidere sulla velocità di risposta. Utilizzare quindi l'opzione PHYSICAL_ONLY e pianificare DBCC CHECKDB per i periodi di minore utilizzo. Non eseguire questa routine durante una ricerca per indicizzazione di Office SharePoint Server.

• Evitare di eseguire operazioni non supportate nei computer di produzione che eseguono SQL Server. Ad esempio, evitare di modificare le regole di confronto del database o di aggiungere colonne a qualsiasi tabella del database Office SharePoint Server. Per ulteriori informazioni sulle operazioni non supportate, vedere l'articolo della Knowledge Base 841057 Supporto per le modifiche apportate ai database utilizzati dai prodotti server di Office e da Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=105589&clcid=0x410).

Nel tempo, la frammentazione degli indici SQL Server che supportano il database di ricerca può incidere sulle prestazioni dell'indicizzazione e delle query. L'articolo della Microsoft Knowledge Base KB943345 include uno script Transact-SQL che crea una stored procedure denominata proc_DefragmentIndices. È possibile utilizzare proc_DefragmentIndices per deframmentare i database di ricerca e del contenuto nella farm Office SharePoint Server. Questa stored procedure tuttavia comporta un utilizzo elevato di risorse del server, pertanto è necessario utilizzarla con cautela per evitare di causare un calo nella velocità di risposta per le query.

È inoltre disponibile una stored procedure di deframmentazione denominata proc_DefragSearchIndexes, progettata in modo specifico per il database di ricerca Office SharePoint Server, che deframmenta solo gli indici che offrono il massimo vantaggio in termini di prestazioni, ad esempio IX_MSSDocProps e IX_MSSDocSdids. In questo modo si riduce l'utilizzo di risorse del server di database. È consigliabile pianificare l'esecuzione della stored procedure in periodi di minor utilizzo e monitorare attentamente l'effetto che produce sugli utenti.

Se si diagnostica un collo di bottiglia del disco o del RAID in un server di database nella farm, le azioni seguenti possono ridurre gli effetti del problema:

• Riposizionare i file di dati e i registri delle transazioni in dischi o matrici RAID separati. L'utilizzo di filegroup, come descritto in precedenza in questo articolo, ottimizza le prestazioni.

• Aggiungere dischi alla matrice RAID.

• Sostituire i dischi lenti con dischi più veloci.

Come evitare l'interruzione del crawler

In un'organizzazione vasta o complessa per configurare il sistema di indicizzazione di Microsoft Office SharePoint Server 2007 è necessario superare notevoli difficoltà. Possono esistere numerose origini di contenuto di vario tipo con un corpo di contenuto molto vasto che richiede molto tempo per l'indicizzazione. È necessario inoltre aver pianificato con cura gli obiettivi per l'aggiornamento delle voci dell'indice allo scopo di garantire che i risultati delle ricerche riflettano i contenuti aggiornati. Per raggiungere gli obietti di aggiornamento, è necessario ottimizzare le prestazioni dell'indicizzatore in modo che esegua regolarmente la ricerca per indicizzazione di tutto il contenuto.

Uno degli ostacoli principali alla velocità del processo di indicizzazione è costituito dall'interruzione del crawler. Il crawler si trova in uno stato interrotto quando non riesce ad allocare un altro thread per recuperare il documento successivo nella coda. L'interruzione può avere le cause seguenti:

• Conflitto per le risorse nel server di database che ospita il database di ricerca

• Partecipazione di un numero eccessivo di host alla ricerca per indicizzazione

• Host che non rilasciano rapidamente un thread.

• Backup eseguiti simultaneamente alla ricerca per indicizzazione

Host che bloccano un thread e ne impediscono il passaggio al documento successivo. Tale blocco può verificarsi nelle circostanze seguenti:

• Quando l'host è lento a causa della mancanza di CPU, memoria o altre risorse.

• Quando l'host richiede un lavoro aggiuntivo per le ricerche per indicizzazione incrementali. Ad esempio, se l'origine è un server Microsoft SharePoint Portal Server 2003, il crawler deve rielaborare un intero documento se le autorizzazioni sono state modificate.

• Host o documenti con numerose proprietà. Se sono presenti numerose proprietà per ogni documento, il server di database che ospita il database di ricerca deve lavorare di più. Le origini di contenuto Catalogo dati business e i siti personali in genere presentano numerose proprietà.

Le ricerche per indicizzazione più efficienti in genere si verificano con i tipi di host seguenti:

• Server Microsoft Office SharePoint Server 2007. Questi server creano un registro delle modifiche che il crawler può utilizzare.

• Condivisioni di file. Il crawler può verificare le modifiche a livello della cartella senza esaminare ogni singolo documento.

• Cartelle pubbliche di Exchange. Il crawler può verificare le modifiche a livello della cartella senza esaminare ogni singolo post.

Linee guida per evitare l'interruzione del crawler

Per ridurre al minimo i casi di interruzione del crawler, attenersi alle procedure consigliate seguenti:

• Limitare al minimo il numero di origini del contenuto. È possibile migliorare l'efficienza raggruppando gli host di dimensione e tipo simili in singole origini di contenuto.

• Eseguire la ricerca per indicizzazione degli host Microsoft Office SharePoint Server 2007 di grandi dimensioni prima di aggiungere altri tipi di host. La ricerca per indicizzazione di tali host è molto efficiente e le ricerche per indicizzazione incrementali rilasciano i thread molto rapidamente.

• Non pianificare ricerche per indicizzazione contemporaneamente per più di un host che blocca i thread.

• Quale punto di partenza, pianificare quattro ricerche per indicizzazione simultanee. Per alcuni server di indicizzazione è possibile incrementare questo numero. Per ulteriori informazioni, vedere la sezione successiva in questo articolo.

• Se il crawler si interrompe, sospendere la ricerca per indicizzazione per gli host che bloccano i thread allo scopo di liberare i thread.

Come diagnosticare l'interruzione del crawler

Quando si installa un nuovo sistema di ricerca Microsoft Office SharePoint Server 2007, realizzare la configurazione del crawler aggiungendo nuove origini di contenuto nell'arco di alcuni giorni o settimane. Monitorare le prestazioni del sistema man mano che si aggiungono le singole origini del contenuto per evitare l'interruzione e agevolare la risoluzione dei problemi. In questo modo è possibile comprendere appieno il comportamento del sistema durante le ricerche per indicizzazione.

Il numero di thread utilizzati dal crawler è determinato dall'impostazione Prestazioni indicizzatore. Per modificare questa impostazione, fare clic sulla scheda Operazioni in Amministrazione centrale, su Servizi nel server e quindi su Servizio di ricerca di Office SharePoint Server. Nella tabella seguente è illustrato il modo in cui l'impostazione Prestazioni indicizzatore controlla i thread della ricerca per indicizzatore.

Impostazione Prestazioni indicizzatore	Numero totale di thread	Numero massimo di thread per ogni host
Ridotte	Numero di processori	Numero di processori
Parzialmente ridotte	4 volte il numero di processori	Numero di processori più 4
Massime	16 volte il numero di processori	Numero di processori più 4

In Microsoft Office SharePoint Server 2007 il numero di thread delle ricerche per indicizzazione non supera mai 64.

La causa più comune di interruzione è il conflitto per le risorse nel server di database. È possibile diagnosticare questo problema monitorando il plug-in di archiviazione. Nel monitor di prestazioni utilizzare l'oggetto Plug-in di archiviazione servizio di ricerca di Office Server e i contatori Totale documenti prima coda e Totale documenti seconda coda. Se entrambi i contatori presentano un valore di 500 per l'istanza Portal_Content o 50 per l'istanza ProfileImport, il crawler è stato interrotto. Può essere opportuno modificare il server di database come descritto nella sezione Ottimizzazione di SQL Server per la ricerca in Office SharePoint Server 2007 in precedenza in questo articolo.

Gli stati di interruzione non causati dal plug-in di archiviazione possono essere diagnosticati mediante l'oggetto Servizio Gatherer del servizio di ricerca di Office Server nel monitor di prestazioni. Esaminare i contatori Thread inattivi, Thread che accedono alla rete e Thread per plug-in e confrontarli con il numero totale di thread per il sistema. Per una descrizione completa di questi contatori, vedere la sezione Monitoraggio dei server di indicizzazione in precedenza in questo articolo.

Come evitare i colli di bottiglia causati dagli elenchi di controllo di accesso

Quando Microsoft Office SharePoint Server 2007 esegue la ricerca per indicizzazione e indicizza un'origine di contenuto, verifica gli elenchi di controllo di accesso e li archivia nel database di ricerca. Quando gli utenti eseguono ricerche nell'indice, ogni risultato viene verificato nel database di ricerca per garantire che l'utente sia autorizzato ad accedervi. Questo processo è definito limitazione per motivi di protezione. Gli elenchi di controllo di accesso più grandi, con numerosi livelli di nidificazione, possono quindi incidere negativamente sulle prestazioni del processo di ricerca per indicizzazione e sulle ricerche in Office SharePoint Server. In questa sezione viene illustrato come limitare al minimo questa riduzione delle prestazioni.

Active Directory offre i seguenti tipi di entità di protezione che possono essere utilizzati per migliorare la protezione dei siti e del contenuto indicizzato di Office SharePoint Server:

• Account utente

• Gruppi globali

• Gruppi locali di dominio

• Gruppi universali

In Microsoft Office SharePoint Server 2007 sono disponibili anche gruppi di SharePoint. Questo sistema è molto flessibile e può includere più livelli di nidificazione. Tuttavia, le entità di protezione possono incidere negativamente sulle prestazioni di ricerca di Office SharePoint Server.

Per ottenere prestazioni ottimali dal crawler e dalle ricerche di Microsoft Office SharePoint Server 2007, attenersi alle regole seguenti quando si utilizzano le entità di protezione di Active Directory e i gruppi di SharePoint:

• Posizionare gli account utente in gruppi globali e i gruppi globali in gruppi locali di dominio. Assegnare le autorizzazioni ai gruppi locali di dominio. Questa è la procedura consigliata per l'utilizzo delle entità di protezione in Active Directory e garantisce che i controller di dominio possano cercare rapidamente le appartenenze ai gruppi e gli utenti possano accedere alle risorse disponibili in tutta la foresta.

• Se sono necessari gruppi universali, utilizzare lo stesso sistema inserendo i gruppi globali all'interno di gruppi universali e i gruppi universali all'interno di gruppi locali di dominio.

• Inserire i gruppi locali di dominio in gruppi di SharePoint per assegnare le autorizzazioni ai siti di SharePoint e ad altre risorse.

• Limitare il numero dei livelli di nidificazione utilizzati nell'appartenenza ai gruppi.

Le situazioni specifiche seguenti incidono negativamente sulle prestazioni della ricerca di Microsoft Office SharePoint Server 2007 e devono essere evitate:

• Non assegnare autorizzazioni del sito Office SharePoint Server a singoli utenti.

  I siti di Office SharePoint Server si rallentano quando nel DACL di un sito sono elencati più di 2.000 entità di protezione. Un gruppo di Active Directory o di SharePoint è considerato tuttavia come una singola entità di protezione, indipendentemente dal numero di utenti che contiene. Di conseguenza, utilizzare i gruppi di SharePoint per assegnare le autorizzazioni dei siti e inserire gli utenti o i gruppi di Active Directory in gruppi di SharePoint.

• Non utilizzare gruppi di protezione Active Directory con livelli di nidificazione elevati.

  Quando un utente tenta di accedere a un sito di Office SharePoint Server, il server deve valutare le appartenenze ai gruppi per autorizzare l'utente. Se i gruppi hanno livelli di nidificazione elevati, sono necessarie molte query nei controller di dominio. Possono inoltre essere necessarie query nei domini remoti della foresta. Tali query devono essere completate prima di concedere l'accesso all'utente.

• Non utilizzare gli elenchi di distribuzione o i gruppi di protezione che contengono contatti.

  I contatti in Active Directory possono essere aggiunti ai gruppi, ad esempio, per distribuire messaggi di posta elettronica. Tuttavia, i contatti non sono entità di protezione e non vengono coinvolti nell'autorizzazione. Se si assegnano autorizzazioni a un gruppo che contiene contatti, è possibile che si verifichi una riduzione delle prestazioni.

In Microsoft Office SharePoint Server 2007 il proprietario del sito per ogni sito può aggiungere utenti e gruppi al DACL del sito. È importante illustrare ai proprietari dei siti il modo in cui utilizzare correttamente le appartenenze ai gruppi per evitare di introdurre colli di bottiglia.

Risoluzione dei problemi relativi alle web part Casella di ricerca mancanti

La web part Casella di ricerca non viene visualizzata nel Centro ricerche e in altre parti dell'interfaccia utente di Microsoft Office SharePoint Server 2007 nelle circostanze seguenti:

• Uno sviluppatore ha modificato la pagina del contenuto del Centro ricerche o la pagina master del sito per nascondere o rimuovere la web part Casella di ricerca.

• Un utente con livello di autorizzazione Controllo completo o Struttura nel sito ha rimosso o nascosto la web part Casella di ricerca.

• Il servizio di ricerca non è disponibile nella farm Office SharePoint Server a causa dell'interruzione del servizio o poiché è stato impostato come non in linea.

Vedere anche

Concetti

Risoluzione dei problemi relativi a Office SharePoint Server 2007
Procedure consigliate per la ricerca in Office SharePoint Server