Risoluzione dei problemi dei report: prestazioni del report
Quando si visualizza un report, è possibile che si debba attendere a lungo prima di vedere la prima pagina. Per comprendere come viene impiegato il tempo di elaborazione del report, vedere Tecniche di risoluzione dei problemi del report. Una volta determinato se il ritardo è causato dal recupero dei dati, dall'elaborazione del report o dal rendering del report, utilizzare questo argomento per risolvere il problema.
Il recupero dei dati richiede troppo tempo
L'elaborazione del report è troppo lunga
L'esecuzione del rendering del report è troppo lunga
Suggerimenti sulla progettazione per l'ottimizzazione dell'elaborazione del report
Il recupero dei dati richiede troppo tempo.
Più sono numerosi i dati del report, maggiori sono l'utilizzo delle risorse, il traffico di rete, il tempo di elaborazione e l'attività di archiviazione richiesti. Analizzare i problemi presentati nel report per determinare i dati effettivamente necessari e quindi recuperare solo tali dati dalle origini dati del report.
Vengono recuperati più dati di quanti ne sono necessari
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 Ordinamento dei dati in un report.
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 Preparazione dei dati per la visualizzazione in un'area dati del grafico.
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.
Timeout della query
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.
Per impostare il valore di timeout per una query del set di dati, vedere Procedura: Creazione di un set di dati (Reporting Services).
L'elevata quantità di traffico di rete causa tempi di attesa per l'utente
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.
L'elaborazione del report è troppo lunga.
L'elaborazione del report avviene dopo che i dati vengono recuperati per i set di dati del report, quando il componente Elaborazione report combina il layout del report e i dati per creare un formato del report provvisorio che viene passato quindi al renderer del report. In generale, il componente Elaborazione report combina dati e layout solo per la pagina corrente visualizzata dall'utente. Il tempo di elaborazione del report può variare in base al layout del report, al paging e alle espressioni complesse nelle aree di un report contenenti molte istanze.
Utilizzare questa sezione per migliorare le prestazioni di elaborazione di un report.
Le espressioni nell'intestazione o nel piè di pagina forzano l'elaborazione di tutte le pagine
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.
Nessuna interruzione di pagina nel report
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.
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 (Reporting Services).
Funzioni di aggregazione e raggruppamento di aree dati Tablix complesse
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 Utilizzo delle funzioni predefinite di report e aggregazione nelle espressioni (Reporting Services).
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.
Molte istanze di sottoreport in un'area dati Tablix rallentano le prestazioni del report
È 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.
I processi competono per la stessa memoria nel server di report
Le diverse 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.
Timeout dell'esecuzione del 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.
Il criterio 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.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.
L'esecuzione del rendering del report è troppo lunga.
Il rendering del report avviene dopo che i dati e il layout vengono combinati in un formato provvisorio e vengono passati a un'estensione per il rendering. Il tempo di esecuzione del rendering varia in base alla quantità di dati, al numero di istanze di elementi del report e al paging. Quando si esporta un report, il formato provvisorio viene passato a un renderer specifico. Se gli utenti visualizzano un report in un solo formato specifico, è necessario ottimizzare il report per quel determinato renderer. Per ulteriori informazioni, vedere Esportazione di report e Informazioni sui comportamenti di rendering.
Utilizzare questa sezione per migliorare le prestazioni del rendering di un report.
Il report non è ottimizzato per il formato di rendering scelto
Alcune funzionalità 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.
Suggerimenti sulla progettazione per l'ottimizzazione dell'elaborazione del report
Se le prestazioni del report sono di importanza strategica, utilizzare le informazioni seguenti per ottimizzare il tempo richiesto per elaborare il report:
Per i report che dispongono di molte istanze di caselle di testo, impostare CanGrow e CanShrink su FALSE nelle caselle di testo. Per impostazione predefinita, in un'area dati Tablix ogni cella contiene una casella di testo, in modo che il numero complessivo di caselle di testo da sottoporre al rendering possa aumentare rapidamente.
Per i report che dispongono di molte immagini, impostare il parametro AutoSize delle immagini su un valore diverso, ad esempio Fit.
Per le caselle di testo, evitare di impostare la proprietà TextAlign su General. Questo valore richiede l'elaborazione condizionale a seconda del contenuto della casella di testo.
Evitare le interruzioni di pagina orizzontali quando non sono necessarie. Esaminare i margini, la larghezza delle colonne e lo spazio vuoto in un report. Ad esempio, eseguire il rendering del report in un file TIFF e visualizzarlo nel Visualizzatore immagini e fax per Microsoft Windows per determinare se per le pagine aggiuntive viene eseguito il rendering.
Impostare la proprietà KeepTogether sui membri Tablix solo quando è necessario controllare il comportamento del rendering specifico per un'area dati Tablix. La funzionalità KeepTogether richiede un'elaborazione straordinaria quando sono calcolate le interruzioni di pagina.