Risoluzione dei problemi dei report: prestazioni del report

L'esecuzione del filtro, dell'ordinamento e dell'aggregazione è più efficiente se viene eseguita sull'origine dati anziché durante l'elaborazione del report. Scrivere le query in modo da ottenere solo il livello di dettaglio indicato nel report. Nell'elenco seguente vengono riportati alcuni suggerimenti per la valutazione di ciascuna query del report.

• Scrivere query con clausole WHERE o HAVING per limitare i dati da visualizzare nel report. Utilizzare i parametri di query per limitare i dati da recuperare in fase di esecuzione. I parametri della query vengono associati automaticamente ai corrispondenti parametri del report e consentono all'utente di stabilire quali sono i dati necessari. Per ulteriori informazioni, vedere Filtraggio delle righe utilizzando WHERE e HAVING.

  Quando si crea un report di snapshot che dispone di parametri di report che filtrano i dati, tutti i dati che potrebbero essere visualizzati nel report devono essere salvati nello snapshot. In questo caso, anziché utilizzare i parametri di query nelle query del set di dati, creare manualmente i parametri di report da utilizzare nelle espressioni di filtro per consentire all'utente di specificare i dati del report desiderati.

• Scrivere query con la clausola ORDER BY per ordinare preventivamente i dati che vengono recuperati per un report. Disporre i dati nell'ordine che si desidera venga utilizzato nel report. L'ordinamento preventivo dei dati consente di ridurre i tempi di elaborazione del report grazie alla modalità di archiviazione dei dati in memoria. Numerose attività di elaborazione del report non richiedono l'ordinamento dei dati prima dell'elaborazione. Ad esempio, SUM non è dipendente dall'ordinamento. I dati delle istanze di gruppo non vengono ordinati automaticamente. Se nel report non sono necessari i dati ordinati, non impostare le espressioni di ordinamento nel set di dati o nell'area dati. Per ulteriori informazioni, vedere Clausola ORDER BY (Transact-SQL) e Procedura: Ordinamento dei dati in un'area dati (Generatore report 3.0 e SSRS).

  L'ordinamento dei gruppi o l'ordinamento in base a valori di aggregazione si esegue con più facilità nel report che nella query ed è spesso anche più efficiente.

• Scrivere query con GROUP BY per aggregare i valori nell'origine dati.

  La modalità più efficiente per comunicare le informazioni consiste spesso nell'aggregazione dei valori e nella visualizzazione dei riepiloghi. È possibile calcolare nell'origine dati il livello delle aggregazioni e quindi recuperarle per un set di dati. I dati "dettaglio" nel set di dati rappresentano così le aggregazioni calcolate nell'origine dati. Per ulteriori informazioni, vedere Riepilogo dei risultati di una query (Visual Database Tools).

  Una volta inseriti nel report tali dati preaggregati, è possibile continuare ad aggregare i valori purché si utilizzi una funzione di aggregazione transitiva dal punto di vista matematico, ad esempio SUM. Si supponga ad esempio di disporre di un set di 6 valori: 1, 2, 3, 4, 5, 6. Se si raggruppano i valori in coppie, si dispone di un set di 3 valori: 3, 7, 11. È possibile calcolare la somma del primo set (21) e la somma del secondo set (21). Le somme corrispondono indipendentemente dal raggruppamento. Se si calcola la media dei valori nei set tramite la funzione AVG, si ottiene un risultato diverso per ogni set. La media del set di 6 valori è 21/6 o 3,5. La media del set di 3 valori è 21/3 o 7. AVG non è una funzione transitiva.

• Considerare la quantità di dati necessaria per un grafico o un contatore. Quando si disegnano su un monitor centinaia di punti in pochi pixel, si riducono le prestazioni e non si migliora la rappresentazione visiva delle immagini grafiche. Un grafico a torta composto da più di 7 o 8 sezioni costituisce, ad esempio, un valore discutibile. Per ulteriori informazioni, vedere gli argomenti relativi ai tipi specifici di grafici in Tipi di grafico (Generatore report 3.0 e SSRS).

• Per gli elementi del report con visibilità condizionale, il componente Elaborazione report deve applicare espressioni di raggruppamento, ordinamento e applicazione di filtri anche se inizialmente è visibile solo il primo livello dei dati. Anche se in SQL Server 2008 Reporting Services l'elaborazione su richiesta consente di ottimizzare la valutazione dei dati elaborando solo i dati visibili, tutti i possibili dati vengono considerati come inclusi nel report. Se l'utente desidera visualizzare solo i dati di dettaglio, un report drill-through costituisce la scelta migliore. Per ulteriori informazioni, vedere Tipi di report.

• Creare snapshot dell'esecuzione per un report. Uno snapshot del report include tutti i dati del report recuperati per i set di dati nella definizione del report. Per ulteriori informazioni, vedere Creazione, modifica ed eliminazione di snapshot nella cronologia dei report.

I valori di timeout della query vengono specificati durante la creazione del report al momento della definizione di un set di dati. Il valore di timeout viene archiviato con il report nell'elemento Timeout della query. Per impostazione predefinita, questo valore è impostato su 30 secondi. Per ulteriori informazioni, vedere Impostazione dei valori di timeout per l'elaborazione di report e di set di dati condivisi (SSRS).

Per impostare il valore di timeout per una query del set di dati, vedere Procedura: Creazione di un set di dati condiviso o di un set di dati incorporato (Generatore report 3.0 e SSRS).

L'elevata quantità di dati passati come traffico di rete può causare tempi di attesa per l'utente. A seconda del numero di utenti previsto e del volume previsto per le visualizzazioni dei report, è possibile selezionare l'approccio corretto per la distribuzione dei componenti del server di report. Per ulteriori informazioni, vedere Pianificazione di una topologia di distribuzione.

Ad esempio, le strategie indicate di seguito potrebbero consentire di ridurre i tempi di attesa dell'utente.

• Conservare il catalogo del server di report nello stesso computer del server di report.

  Il database del server di report tempdb gestisce i dati del report recuperati per ogni query del set di dati in una definizione del report. Tramite la conservazione dei dati del report con il componente Elaborazione report si riduce il traffico di rete che potrebbe rallentare l'esecuzione del report.

• Per le origini dati del data warehouse, conservare il data warehouse in un server diverso dal server di report.

  Sebbene il recupero dei dati attraverso la rete aggiunge attività all'esecuzione del report, se il data warehouse e i servizi Reporting Services si contendono la memoria nello stesso server, è possibile che le prestazioni risultino ridotte.

Quando si include un riferimento al campo predefinito [&TotalPages], il componente Elaborazione report deve impaginare l'intero report prima di poter eseguire il rendering della prima pagina. Se non esiste alcun riferimento a [&TotalPages], è possibile eseguire il rendering della prima pagina che quindi può essere restituita immediatamente all'utente, senza elaborare il resto del report. Inoltre, il componente Elaborazione report presuppone che qualsiasi espressione complessa nell'intestazione della pagina o nel piè di pagina possa contenere un riferimento diretto o indiretto a [&TotalPages].

Per evitare che il componente Elaborazione report esegua l'impaginazione di un report lungo, non includere un riferimento a [&TotalPages] o un'espressione complessa nell'intestazione della pagina e nel piè di pagina.

Quando un utente sfoglia le pagine di un report, il componente Elaborazione report combina i dati e le informazioni sul layout del report per ogni pagina del report e passa la pagina al renderer del report. Per un report che non contiene interruzioni di pagina, è necessario elaborare l'intero report prima che l'utente possa vedere visualizzata la prima pagina.

Un renderer di interruzioni di pagina automatiche, ad esempio il visualizzatore HTML, gestisce automaticamente il paging. È possibile eseguire l'override di questo comportamento automatico e configurare il report in modo che sia costituito da una pagina impostando la proprietà del report InteractiveHeight su 0. Per i renderer di interruzioni di pagina manuali, è necessario aggiungere manualmente le interruzioni di pagina. Per ulteriori informazioni sui tipi di renderer, vedere Informazioni sui comportamenti di rendering (Generatore report 3.0 e SSRS).

Verificare che InteractiveHeight non sia impostato su 0 ma su dimensioni della pagina accettabili, ad esempio 8,5 pollici. Per organizzare il report in pagine, aggiungere le interruzioni di pagina agli elementi del report o ai gruppi Tablix. In tal modo si riduce la quantità di dati da elaborare per ogni pagina. Per ulteriori informazioni, vedere Procedura: Aggiunta di un'interruzione di pagina (Generatore report 3.0 e SSRS).

La presenza di molti livelli di gruppi nidificati e adiacenti in un'area dati Tablix può influire sulle prestazioni di elaborazione del report. Considerare il livello di raggruppamento, il numero delle istanze di gruppo e l'utilizzo delle funzioni di aggregazione che richiedono la valutazione dopo l'applicazione delle espressioni di raggruppamento gruppo, filtro e ordinamento. Ad esempio, Previous è una funzione di aggregazione "costosa" perché il suo valore dipende dagli elementi ordinati di un'area dati, mentre Sum, che non è una funzione dipendente da ordine, richiede un numero inferiore di risorse. Altre aggregazioni successive all'ordinamento sono First e Last. Per ulteriori informazioni, vedere Riferimento a funzioni di aggregazione (Generatore report 3.0 e SSRS).

Valutare la struttura del report e considerare se è possibile eseguire un'aggregazione dei dati nell'origine dati. La riduzione della quantità di dati nel report potrebbe essere sufficiente a fornire prestazioni accettabili, senza la necessità di modificare le chiamate alle funzioni di aggregazione.

È necessario comprendere i vantaggi e gli svantaggi dell'utilizzo dei sottoreport. Ogni istanza di un sottoreport è un'esecuzione di query separata e un'attività di elaborazione del report distinta.

• Utilizzare i sottoreport solo se sono presenti poche istanze di sottoreport.

• Non utilizzare i sottoreport all'interno di un gruppo se sono presenti molte istanze di gruppo. Ad esempio, per visualizzare un elenco di vendite e resi per ogni cliente si potrebbero utilizzare i report drill-through. Valutare se è possibile scrivere una query per unire il cliente alle vendite e ai resi e quindi raggruppare i dati in base all'ID cliente.

• Utilizzare i sottoreport quando il sottoreport utilizza un'origine dati diversa dal report principale. Se le prestazioni costituiscono un problema, modificare la query del set di dati nel report principale tramite una delle strategie di attenuazione seguenti:

  • Raccogliere i dati in un data warehouse e utilizzare il data warehouse come origine dati per un solo set di dati.

  • Utilizzare i server collegati SQL Server e scrivere una query che recuperi i dati da più database.

  • Utilizzare la funzionalità OPEN ROWSET per specificare i diversi database.

Più applicazioni che competono per le stesse risorse di memoria in un server di report possono influire sull'elaborazione del report.

Verificare con l'amministratore di sistema che la gestione della memoria sia correttamente configurata per l'utilizzo del server di report. Per ulteriori informazioni, vedere Configurazione della memoria disponibile per applicazioni del server di report.

Per eseguire report di grandi dimensioni, è necessario regolare due timeout: il timeout di esecuzione del report e il timeout di ASP.NET.

I valori di timeout dell'esecuzione del report sono specificati nel server di report. Per ulteriori informazioni, vedere Impostazione dei valori di timeout per l'elaborazione di report e di set di dati condivisi (SSRS).

I criteri del timeout di ASP.NET viene controllato dal file di configurazione del server di report. Il percorso predefinito del file è <unità>:\Programmi\ Microsoft SQL Server\MSRS10_5.MSSQLSERVER\Reporting Services\ReportServer\web.config. Per impostare il numero massimo di secondi per l'esecuzione di una richiesta, aggiungere al file l'elemento httpRuntime:

<configuration>
   . . .
   <system.web.
      . . .
      <httpRuntime executionTimeout="90"/>
      . . .
   </system.web.
   . . .
</configuration>

A seconda delle dimensioni del report, questo valore potrebbe rappresentare diverse ore.

Alcune caratteristiche non sono supportate in tutti i renderer. Se il formato primario per la visualizzazione di un report è un formato di file specifico, potrebbe essere necessario modificare la struttura del report per ottimizzarne la visione per l'utente.

• Aggiungere interruzioni di pagina dove necessario. Ad esempio, ogni interruzione di pagina definisce un nuovo foglio in Excel. Ogni foglio può gestire al massimo 65000 righe. Considerare questi limiti quando si impostano le interruzioni di pagina in un report.

• Per l'esportazione in Excel, non unire le celle in un'area dati Tablix. Nei report in formato libero, allineare gli elementi del report verticalmente. Le celle unite e gli elementi del report non allineati interferiscono con la funzionalità di Excel nel report esportato.

• I parser HTML non offrono un'elevata efficienza per il rendering delle pagine HTML particolarmente grandi. In caso di problemi durante il rendering di un report, scegliere un formato che produca un file di dimensioni più contenute, ad esempio il formato CSV. Se non è possibile scegliere un formato diverso, ad esempio perché la barra degli strumenti per il report non è disponibile, è possibile definire una sottoscrizione per impostare un formato di rendering e recapitare il report come documento statico a una condivisione file. Per ulteriori informazioni, vedere Recapito tramite condivisione file in Reporting Services.