Risoluzione dei problemi di prestazioni dei report

Data creazione: 17 novembre 2008

In questo argomento vengono illustrati i modi in cui è possibile migliorare le prestazioni dei report.

Per risolvere i problemi di prestazioni dei report, utilizzare i file di log di Reporting Services per determinare quale processo richiede più tempo di elaborazione, ovvero il recupero dei dati, l'elaborazione del report o il rendering del report. Per ulteriori informazioni, vedere Risoluzione dei problemi relativi ai report.

Dopo aver determinato quale processo richiede più tempo di elaborazione, utilizzare le informazioni incluse nelle sezioni seguenti per risolvere problemi specifici.

Miglioramento delle prestazioni di recupero dei dati

Miglioramento delle prestazioni di elaborazione del report

Miglioramento delle prestazioni di rendering del report

Miglioramento delle prestazioni di recupero dei dati

Una maggiore quantità di dati del report determina l'utilizzo di un maggior numero di risorse e di spazio di archiviazione aggiuntivo, genera più traffico di rete e richiede più tempo di elaborazione. Per consentire il controllo delle prestazioni dei report, progettare report che presentino una complessità e una quantità di dati accettabili. È ad esempio raro che si desideri visualizzare report costituiti da 1.000 pagine. È possibile che gli utenti abbiano difficoltà a mantenere il contesto per un report drill-down in cui una tabella presenta troppi livelli di nidificazione o a eseguire lo scorrimento di una tabella con troppe colonne. Diagrammi a torta con centinaia di sezioni possono avere un aspetto confuso ed essere difficili da leggere. Analizzare i requisiti del report con attenzione per determinare la quantità di dati necessaria e recuperare quindi solo tali dati dalle origini dati del report.

Utilizzare le informazioni incluse nelle sezioni seguenti per favorire la riduzione del tempo richiesto per il recupero dei dati del report.

Recupero di una quantità di dati superiore al necessario

È molto più efficace filtrare, ordinare e aggregare grandi quantità di dati nell'origine dati anziché durante l'elaborazione del report. Scrivere query che consentano di restituire solo i dati che si desidera visualizzare in un report. Se si prevede di visualizzare solo dati di riepilogo, calcolare aggregati nell'origine dati e non recuperare dati di dettaglio. Nell'elenco seguente sono inclusi suggerimenti per la valutazione di ogni query di report nel report:

• Scrivere query con clausole WHERE o HAVING che limitino i dati esclusivamente a quelli che devono essere visualizzati all'utente nel report. Utilizzare parametri di query per limitare i dati recuperati in fase di esecuzione. Per ulteriori informazioni, vedere Filtraggio delle righe utilizzando WHERE e HAVING.
  Quando si crea un report snapshot che dispone di parametri per il filtro dei dati, tutti i dati che è possibile visualizzare nel report devono essere salvati nello snapshot. In questo caso, non utilizzare parametri di query nelle query del set di dati. Creare invece manualmente parametri di report che è possibile utilizzare nelle espressioni di filtro per consentire all'utente di specificare i dati del report desiderati.
• Scrivere query con la clausola ORDER BY per eseguire l'ordinamento preliminare dei dati recuperati per un report. Ordinare i dati nell'ordine in cui si desidera vengano ordinati nel report. L'ordinamento preliminare dei dati consente di migliorare i tempi di elaborazione grazie al modo in cui i dati vengono archiviati in memoria. Molte attività di elaborazione del report non richiedono l'ordinamento dei dati prima dell'elaborazione del report stesso. La funzione SUM, ad esempio, è indipendente dal tipo di ordinamento. I dati all'interno di istanze di gruppo non vengono ordinati automaticamente. Se non è necessario disporre di dati ordinati nel report, non impostare 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.
  È tuttavia più semplice eseguire l'ordinamento di gruppi o l'ordinamento in base a valori aggregati nel report anziché nella query. L'ordinamento di gruppi nel report risulta in genere più efficace rispetto all'ordinamento di gruppi nella query.
• Scrivere query con la clausola GROUP BY per aggregare valori nell'origine dati.
  Talvolta, il metodo più efficace per comunicare informazioni consiste nell'aggregare valori e visualizzare riepiloghi. È possibile calcolare alcuni livelli di aggregati nell'origine dati e recuperarli per un set di dati. I dati di dettaglio nel set di dati rappresenteranno quindi gli aggregati calcolati nell'origine dati. Per ulteriori informazioni sull'aggregazione nella query, vedere Riepilogo dei risultati di una query (Visual Database Tools).
  Dopo aver incluso questi valori preaggregati nel report, sarà possibile continuare ad aggregare valori utilizzando una funzione di aggregazione matematica transitiva, ad esempio SUM. Si supponga ad esempio di disporre di un set di 6 valori, ovvero 1, 2, 3, 4, 5 e 6. Se si raggruppano i valori in coppie, si otterrà un set di 3 valori, ovvero 3, 7 e 11. È possibile calcolare la somma nel primo set (21) e calcolare la somma del secondo set (21), ottenendo le stesse somme indipendentemente dal raggruppamento. Se si calcola la media dei valori nei set utilizzando la funzione AVG, si otterrà un risultato diverso per ogni set. La media per il primo set di 6 valori è 21/6 oppure 3,5. La media del set di 3 valori è 21/3 oppure 7. La funzione AVG non è transitiva.
• Valutare l'opportunità di analizzare e ottimizzare le prestazioni di query nell'origine dati. Ad esempio, per informazioni su Query Optimizer per SQL Server 2005, vedere Prestazioni delle query e Elaborazione di una singola istruzione SQL.
• Considerare la quantità di dati necessaria per un grafico. In un grafico a linee il disegno di centinaia di punti in un numero limitato di pixel sul monitor determina una riduzione delle prestazioni e non migliora l'aspetto visivo del grafico. In un grafico a torta una quantità di sezioni superiore a 7 o 8 può risultare discutibile.
• Per gli elementi del report con visibilità condizionale, il componente Elaborazione report deve applicare le espressioni di raggruppamento, ordinamento e filtro anche se inizialmente è visibile solo il livello superiore dei dati. Se l'utente è interessato solo alla visualizzazione di dati di dettaglio in determinate circostanze, un report drill-through rappresenta la scelta più adatta. I report drill-through non vengono eseguiti fino a quando l'utente non fa clic sul collegamento drill-through nel report principale. I report drill-through o i sottoreport elaborano tutti i dati anche quando i dati sono inizialmente nascosti. Per ulteriori informazioni, vedere Aggiunta di collegamenti a un report.
• Valutare l'opportunità di creare snapshot di esecuzione per un report. In uno snapshot del report sono inclusi tutti i dati del report recuperati per i set di dati nella definizione del report. Per ulteriori informazioni, vedere Snapshot dei report.

Grandi quantità di traffico di rete causano tempi di attesa più lunghi

Grandi quantità di dati passati come traffico di rete comportano tempi di attesa per gli utenti. Se si conoscono la base utente prevista e il volume previsto di viste del report, sarà possibile utilizzare l'approccio appropriato per la distribuzione dei componenti di un server di report.

Valutare l'opportunità di adottare le strategie seguenti per favorire una riduzione dei tempi di attesa per gli utenti:

• Mantenere il database 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. Per ridurre il traffico di rete che potrebbe rallentare l'esecuzione del report, mantenere il database tmpdb nel server di report.
• Per le origini dati del data warehouse, mantenere il data warehouse in un server separato dal server di report.
  Sebbene il recupero dei dati in rete non comporti l'aggiunta di un'ulteriore attività per l'esecuzione del report, la presenza del data warehouse e di Reporting Services nello stesso server può determinare una riduzione delle prestazioni, poiché entrambi utilizzano la stessa memoria.

Per ulteriori informazioni, vedere Pianificazione della distribuzione di Reporting Services.

Timeout delle query

Se si verifica il timeout di una query del set di dati prima che i dati vengano recuperati, sarà possibile specificare un valore di timeout nel report. Per impostazione predefinita, questo valore è impostato su 30 secondi. Per impostare il valore di timeout per una query del set di dati, vedere Procedura: Creazione di un set di dati (Progettazione report). Per ulteriori informazioni, vedere Impostazione dei valori di timeout per l'esecuzione di report.

Miglioramento delle prestazioni di elaborazione del report

L'elaborazione del report si verifica al termine del recupero dei dati per i set di dati e i parametri di report. Il componente Elaborazione report combina il layout del report e i dati per creare un formato di report provvisorio che viene quindi passato al renderer del report. Il tempo di elaborazione del report può essere influenzato dal layout del report, dalla paginazione e dalle espressioni complesse presenti negli elementi del report che dispongono di molte istanze. Utilizzare le informazioni incluse in questa sezione per favorire il miglioramento delle prestazioni di elaborazione del report.

Scelta dell'area dati appropriata

Se possibile, utilizzare aree dati tabella ed elenco. L'elaborazione di una tabella o di un elenco risulta più efficace rispetto all'elaborazione di una matrice. Le aree dati tabella ed elenco supportano elementi dinamici solo per le righe. I layout matrice supportano elementi dinamici sia per le righe sia per le colonne, consentendo la creazione di strutture di layout più complesse.

Evitare di inserire valori relativi al numero totale di pagine nell'intestazione o nel piè di pagina per renderer di pagine fisiche

Un riferimento al campo globale TotalPages può avere effetto sulle prestazioni di elaborazione del report quando il report viene visualizzato mediante un'estensione per il rendering del layout che esegue la paginazione per pagine fisiche, ad esempio PDF o immagine. Per ulteriori informazioni sui renderer, vedere Considerazioni sulla progettazione del rendering dei report.

Utilizzo delle funzioni di raggruppamento e aggregazione di aree dati complesse

Molti livelli di gruppi nidificati in una tabella o area dati matrice possono influire sulle prestazioni di elaborazione del report. Considerare il livello di raggruppamento e il numero di istanze di gruppo, nonché l'utilizzo di funzioni di aggregazioni che richiedono una valutazione dopo l'applicazione delle espressioni di gruppo, filtro e ordinamento.

Evitare di definire aggregati post-ordinamento. Gli aggregati post-ordinamento dipendono dal tipo di ordinamento e includono le funzioni seguenti: Previous, First, Last e RunningValue Quando si includono una o più di queste funzioni in un'espressione, il componente Elaborazione report deve ordinare i dati di destinazione prima dell'applicazione della funzione. Se possibile, evitare di includere aggregati post-ordinamento nelle espressioni di layout matrice che dispongono di definizioni di gruppo complesse, ad esempio più gruppi nidificati o adiacenti.

Valutare la struttura del report e considerare la possibilità di definire alcune aggregazioni di dati nell'origine dati. La riduzione della quantità di dati nel report potrebbe essere sufficiente per fornire prestazioni accettabili senza modificare le chiamate delle funzioni di aggregazione

Per ulteriori informazioni sulle funzioni di aggregazione, vedere Utilizzo di funzioni di report nelle espressioni (Reporting Services).

Specifica di ricorsione non necessaria nelle espressioni

Specificare un'espressione padre per un gruppo solo quando si definisce una gerarchia ricorsiva, ad esempio un report organizzativo in cui vengono visualizzati responsabili e dipendenti. La proprietà Parent si applica solo a dati ricorsivi. La proprietà Parent non si applica in modo specifico alla relazione padre-figlio di gruppi nidificati.

Utilizzo di sottoreport in un'area dati con molte righe

È necessario valutare i vantaggi e gli svantaggi derivanti dall'utilizzo di sottoreport. Ogni istanza di sottoreport rappresenta un'esecuzione di query distinta e un'attività di elaborazione del report separata.

• Utilizzare i sottoreport in un'area dati in cui esistono solo alcune istanze di sottoreport.
• Evitare di utilizzare i sottoreport in un gruppo area dati in cui esistono molte istanze di gruppo. Ad esempio, per visualizzare un elenco di vendite e utili per ogni cliente, valutare l'opportunità di utilizzare report drill-through. Valutare la possibilità di scrivere la query per unire in join i dati del cliente e i dati relativi alle vendite e agli utili ed eseguire quindi il raggruppamento in base all'ID del cliente.
• Utilizzare sottoreport quando il sottoreport utilizza un'origine dati diversa rispetto al report principale. Per ottenere prestazioni migliori, considerare l'opportunità di modificare la query del set di dati nel report principale utilizzando una delle strategie seguenti:
  • Raccogliere dati in un data warehouse e utilizzare il data warehouse come origine dati per un singolo set di dati.
  • Utilizzare server collegati SQL Server e scrivere una query che consenta di recuperare dati da più database.
  • Utilizzare la funzionalità OPEN ROWSET per specificare database diversi.

Utilizzo dell'ordinamento interattivo

Evitare di utilizzare pulsanti per l'ordinamento interattivo a meno che gli utenti non abbiano la necessità di modificare il tipo di ordinamento dei dati nel report.

Utilizzo di immagini

È necessario conoscere i requisiti a livello di risorse per le immagini.

• Evitare di utilizzare immagini di grandi dimensioni, incluse immagini di sfondo. Le immagini di grandi dimensioni richiedono risorse di memoria, di elaborazione e di rendering, in particolare quando ne viene eseguito il rendering in renderer di stampa, ad esempio PDF e immagini di stampa o documenti.
• Evitare di creare molte istanze di immagini di piccole dimensioni da un database o in un server, ad esempio indicatori di prestazioni chiave (KPI). Includere queste immagini come immagini incorporate nel report.
• Per i report che contengono molte immagini, impostare la proprietà AutoSize delle immagini su un valore diverso, ad esempio Fit.

Processi che utilizzano la stessa memoria nel server di report

Più applicazioni che utilizzano le stesse risorse di memoria in un server di report possono influire sul processo di elaborazione del report.

Rivolgersi all'amministratore di sistema per verificare che la configurazione di gestione della memoria corrisponda al modello corretto per l'utilizzo del server di report. Per ulteriori informazioni, vedere Configurazione della memoria disponibile per Reporting Services.

Timeout dell'esecuzione del report

Per eseguire report di grandi dimensioni, è necessario impostare due timeout, ovvero il timeout dell'esecuzione del report e il timeout di ASP.NET.

I valori di timeout dell'esecuzione del report vengono specificati nel server di report. Per ulteriori informazioni, vedere Impostazione dei valori di timeout per l'esecuzione di report.

I criteri di timeout di ASP.NET vengono controllati dal file di configurazione del server di report. Il percorso predefinito di questo file è <unità>:\Programmi\Microsoft SQL Server\MSSQL.n\Reporting Services\ReportServer\web.config. Per impostare il numero massimo di secondi in cui è possibile eseguire una richiesta, impostare l'elemento httpRuntime sul valore di timeout in secondi. Nel frammento XML seguente viene illustrata la posizione in cui aggiungere questo elemento nel file di configurazione:

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

Per query con esecuzione prolungata o report complessi, potrebbe essere necessario specificare un valore corrispondente a diverse ore.

Miglioramento delle prestazioni di rendering del report

Il rendering del report viene eseguito dopo l'unione di dati e layout e il relativo passaggio all'estensione per il rendering. La durata della fase di rendering dipende dalla quantità di dati, dal numero di istanze degli elementi del report e dalle dimensioni di pagina. Il renderer del report determina la quantità di dati che può contenere una pagina. La definizione di una pagina varia a seconda del renderer. Una pagina per il renderer Excel è un foglio di lavoro, mentre una pagina per il renderer PDF, che consente di stampare un report, è la pagina fisica. Una pagina per il visualizzatore HTML può corrispondere all'intero report. La struttura del report per una pagina stampata può essere diversa dalla struttura del report per la visualizzazione in linea. Se si prevede che gli utenti visualizzeranno un report in un formato specifico, progettare il report per tale formato. Per ulteriori informazioni, vedere Considerazioni sulla progettazione del rendering dei report.

Nella tabella seguente viene illustrato in che modo è possibile migliorare le prestazioni di rendering del report.

In caso di problemi durante il rendering di un report in un determinato formato, selezionare un formato che produca un file di dimensioni più piccole, ad esempio CSV. Per un report pubblicato, è possibile specificare un formato di rendering nell'URL. Per ulteriori informazioni, vedere Specifying a Rendering Format in a URL.

Se non è possibile selezionare un formato diverso, ad esempio perché la barra degli strumenti per il report non è disponibile, sarà 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.

Vedere anche

Concetti

File di log di Reporting Services
Elaborazione di report di grandi dimensioni

Altre risorse

Risoluzione dei problemi relativi a Reporting Services
Errori ed eventi di Reporting Services
Risoluzione dei problemi relativi ai report

Guida in linea e informazioni

Assistenza su SQL Server 2005