Behandeln von Problemen bei Berichten: Berichtsleistung
Wenn Sie einen Bericht anzeigen, dauert es möglicherweise lange, bis die erste Seite angezeigt wird. Informationen zum Bestimmen der Prozesse, für die die Berichtsverarbeitungszeit aufgewendet wird, finden Sie unter Problembehandlungstechniken für Berichtsprobleme. Nachdem Sie bestimmt haben, ob die Verzögerung durch Datenabruf, Berichtsverarbeitung oder Berichtsrendering verursacht wird, verwenden Sie dieses Thema für die Problembehandlung.
Der Abruf von Daten erfordert zu viel Zeit.
Die Verarbeitung meines Berichts erfordert zu viel Zeit.
Das Rendern meines Berichts erfordert zu viel Zeit.
Entwurfstipps zum Optimieren der Berichtsverarbeitung
Der Abruf von Daten erfordert zu viel Zeit.
Mit zunehmendem Umfang der Berichtsdaten nimmt auch der Umfang der Ressourcennutzung, des Netzwerkverkehrs, der Verarbeitungszeit und des Speichers zu. Analysieren Sie die im Bericht dargestellten Aspekte, um die Menge der Daten zu bestimmen, die Sie benötigen, und rufen Sie dann nur diese Daten aus den Berichtsdatenquellen ab.
Es werden mehr Daten als erforderlich für einen Bericht abgerufen.
Filterung, Sortierung und Aggregation erfolgen in der Datenquelle effizienter als während der Berichtsverarbeitung. Schreiben Sie Abfragen, mit denen nur die Detailebene zurückgegeben wird, die im Bericht angezeigt wird. Die folgende Liste bietet Vorschläge zum Überprüfen der einzelnen Berichtsabfragen in einem Bericht.
Schreiben Sie Abfragen mit WHERE-Klauseln oder HAVING-Klauseln, um die Daten auf die Informationen zu begrenzen, die im Bericht für den Benutzer angezeigt werden müssen. Verwenden Sie Abfrageparameter, um die Daten einzuschränken, die zur Laufzeit abgerufen werden. Abfrageparameter werden automatisch an entsprechende Berichtsparameter gebunden und ermöglichen es dem Benutzer, zu entscheiden, welche Daten relevant sind. Weitere Informationen finden Sie unter Filtern von Zeilen mithilfe von WHERE und HAVING.
Wenn Sie einen Snapshotbericht erstellen, der Berichtsparameter zum Filtern der Daten aufweist, müssen alle Daten, die potenziell im Bericht angezeigt werden, in dem Snapshot gespeichert werden. Verwenden Sie in diesem Fall in den Datasetabfragen keine Abfrageparameter. Erstellen Sie stattdessen manuell Berichtsparameter, die Sie in Filterausdrücken verwenden können, damit der Benutzer die gewünschten Berichtsdaten angeben kann.
Schreiben Sie Abfragen mit der ORDER BY-Klausel, um für einen Bericht abzurufende Daten vorzusortieren. Sortieren Sie die Daten in der Reihenfolge, in der sie im Bericht sortiert werden sollen. Aufgrund der Art der Speicherung vorsortierter Daten verringern diese die Verarbeitungszeit von Berichten. Für viele Berichtsverarbeitungstasks müssen Daten nicht vor dem Verarbeiten sortiert werden. Beispielsweise ist SUM eine von der Reihenfolge unabhängige Funktion. Daten in Gruppeninstanzen werden nicht automatisch sortiert. Wenn Sie in einem Bericht keine sortierten Daten benötigen, legen Sie keine Sortierungsausdrücke für das Dataset oder den Datenbereich fest. Weitere Informationen finden Sie unter ORDER BY-Klausel (Transact-SQL) und Sortieren von Daten in einem Bericht.
Das Sortieren von Gruppen oder das Sortieren nach Aggregatwerten erfolgt in einem Bericht viel einfacher als in einer Abfrage und ist außerdem häufig effizienter.
Schreiben Sie Abfragen mit GROUP BY, um Werte in der Datenquelle zu aggregieren.
Häufig lassen sich Informationen am wirkungsvollsten vermitteln, indem Werte aggregiert und Zusammenfassungen angezeigt werden. Sie können Werte auf einer bestimmten Aggregatebene in der Datenquelle berechnen und sie für ein Dataset abrufen. Die Detaildaten im Dataset stellen jetzt in der Datenquelle berechnete Aggregate dar. Weitere Informationen finden Sie unter Zusammenfassen von Abfrageergebnissen (Visual Database Tools).
Wenn diese vorab aggregierten Werte in einem Bericht vorhanden sind, können Sie diese Werte so lange weiter aggregieren, wie Sie eine Aggregatfunktion, z. B. SUM, verwenden, die mathematisch transitiv ist. Angenommen, Sie verfügen beispielsweise über einen Satz von 6 Werten: 1, 2, 3, 4 ,5, 6. Wenn Sie die Werte in Paare gruppieren, haben Sie einen Satz von 3 Werten: 3, 7, 11. Sie können die Summe des ersten Satzes (21) und die Summe des zweiten Satzes (21) berechnen. Die Summen sind unabhängig von der Gruppierung gleich. Wenn Sie den Durchschnitt der Werte der Sätze mit der AVG-Funktion ermitteln, erhalten Sie jedoch für jeden Satz ein anderes Ergebnis. Der Mittelwert für den Satz der 6 Werte ist 21/6 oder 3,5. Der Mittelwert für den Satz der 3 Werte ist 21/3 oder 7. AVG ist keine transitive Funktion.
Berücksichtigen Sie den Umfang an Daten, der für ein Diagramm oder Messgerät benötigt wird. Beim Zeichnen von Hunderten von Punkten in einigen wenigen Pixeln auf einem Monitor wird die Leistung verringert, die visuelle Darstellung der Grafiken jedoch nicht verbessert. Mehr als 7 oder 8 Slices in einem Kreisdiagramm sind von zweifelhaftem Wert. Weitere Informationen finden Sie unter Vorbereiten von Daten für die Anzeige in einem Diagrammdatenbereich.
Für Berichtselemente mit bedingter Sichtbarkeit muss der Berichtsprozessor Gruppierungs-, Sortier- und Filterausdrücke anwenden, selbst wenn zunächst nur die oberste Ebene der Daten sichtbar ist. Zwar wird durch die bedarfsgesteuerte Verarbeitung in SQL Server 2008 Reporting Services die Datenauswertung optimiert, indem nur sichtbare Daten verarbeitet werden, jedoch sind alle potenziellen Daten Teil des Berichts. Wenn der Benutzer Detaildaten nur für eine bestimmte Zeitspanne anzeigen möchte, ist ein Drillthroughbericht die bessere Lösung. Weitere Informationen finden Sie unter Berichtstypen.
Erstellen Sie Ausführungssnapshots für einen Bericht. Ein Berichtssnapshot umfasst alle für die Datasets in der Berichtsdefinition abgerufenen Berichtsdaten. Weitere Informationen finden Sie unter Erstellen, Ändern und Löschen von Snapshots im Berichtsverlauf.
Timeout der Abfrage
Abfragetimeoutwerte werden im Rahmen der Erstellung eines Berichts beim Definieren eines Datasets angegeben. Der Timeoutwert wird zusammen mit dem Bericht im Element Timeout für die Abfrage gespeichert. Standardmäßig ist dieser Wert auf 30 Sekunden festgelegt. Weitere Informationen finden Sie unter Festlegen von Timeoutwerten für die Berichtsverarbeitung.
Informationen zum Festlegen des Timeoutwerts für eine Datasetabfrage finden Sie unter Vorgehensweise: Erstellen von Datasets (Reporting Services).
Große Mengen an Netzwerkverkehr verursachen Wartezeiten für den Benutzer.
Große Mengen an Daten, die als Netzwerkverkehr übergeben werden, können zu Wartezeiten für den Benutzer führen. Sie können die Herangehensweise zum Bereitstellen von Berichtsserverkomponenten entsprechend der erwarteten Benutzergruppe und der erwarteten Menge an Berichtsansichten auswählen. Weitere Informationen finden Sie unter Planen einer Bereitstellungstopologie.
Beispielsweise lässt sich die Wartezeit für Benutzer mit folgenden Strategien möglicherweise verringern:
Speichern Sie den Berichtsserverkatalog auf dem Computer, auf dem sich der Berichtsserver befindet.
Die Berichtsserverdatenbank tempdb verwaltet Berichtsdaten, die für jede Datasetabfrage in einer Berichtsdefinition abgerufen werden. Wenn sich die Berichtsdaten auf demselben Computer wie der Berichtsprozessor befinden, lässt sich der Netzwerkverkehr verringern, der eine langsamere Berichtsausführung verursachen kann.
Speichern Sie für Data Warehouse-Datenquellen das Data Warehouse auf einem anderen Server als dem Berichtsserver.
Das Abrufen von Daten über das Netzwerk führt zwar zu einer zusätzlichen Task für die Berichtsausführung, jedoch kann die Leistung beeinträchtigt werden, wenn Data Warehouse und Reporting Services Services um Arbeitsspeicher auf demselben Server konkurrieren.
Die Verarbeitung meines Berichts erfordert zu viel Zeit.
Die Berichtsverarbeitung erfolgt, nachdem Daten für Berichtsdatasets abgerufen wurden und wenn der Berichtsserver das Berichtslayout und die Daten kombiniert, um ein zwischenzeitliches Berichtsformat zu erstellen, das dann an den Berichtsrenderer übergeben wird. Im Allgemeinen kombiniert der Berichtsprozessor Daten und Layout nur für die aktuelle Seite, die vom Benutzer angezeigt wird. Layout, Paginierung und komplexe Ausdrücke in Berichtsbereichen mit vielen Instanzen können sich auf die Berichtsverarbeitungszeit auswirken.
Die Informationen in diesem Abschnitt helfen Ihnen dabei, die Berichtsverarbeitungsleistung zu erhöhen.
Ausdrücke im Seitenkopf oder -fuß erfordern, dass alle Seiten verarbeitet werden.
Wenn Sie einen Verweis auf das integrierte Feld [&TotalPages] einschließen, muss der Berichtsprozessor den gesamten Bericht paginieren, bevor er die erste Seite rendern kann. Wenn kein Verweis auf [&TotalPages] vorhanden ist, kann die erste Seite sofort gerendert und an den Benutzer zurückgegeben werden, ohne den Rest des Berichts zu verarbeiten. Außerdem geht der Berichtsprozessor davon aus, dass ein komplexer Ausdruck im Seitenkopf oder -fuß einen direkten oder indirekten Verweis auf [&TotalPages] enthalten kann.
Um zu verhindern, dass der Berichtsprozessor einen umfangreichen Bericht paginiert, fügen Sie keinen Verweis auf [&TotalPages] und keine komplexen Ausdrücke im Seitenkopf oder -fuß ein.
Keine Seitenumbrüche im Bericht
Wenn ein Benutzer durch einen Bericht blättert, kombiniert der Berichtsprozessor Daten und Berichtslayoutinformationen für jede Berichtsseite und übergibt die Seite an den Berichtsrenderer. Bei einem Bericht ohne Seitenumbrüche muss der gesamte Bericht verarbeitet werden, bevor der Benutzer die erste Seite anzeigen kann.
Ein Renderer mit weichem Seitenumbruch, z. B. der HTML-Viewer, behandelt die Paginierung automatisch. Sie können dieses automatische Verhalten überschreiben und festlegen, dass der Bericht aus einer einzigen Seite besteht, indem Sie die Report-Eigenschaft InteractiveHeight auf 0 festlegen. Für Renderer mit hartem Seitenumbruch müssen Sie Seitenumbrüche manuell hinzufügen. Weitere Informationen zu den Typen von Renderern finden Sie unter Grundlegendes zu Renderingverhaltensweisen.
Stellen Sie sicher, dass InteractiveHeight nicht 0 ist und auf eine angemessene Seitengröße, z. B. 8,5 Zoll, festgelegt ist. Fügen Sie Berichtselementen oder Tablix-Gruppen Seitenumbrüche hinzu, um den Bericht nach Seiten zu strukturieren. Dies verringert die Datenmenge, die für jede Seite verarbeitet werden muss. Weitere Informationen finden Sie unter Vorgehensweise: Hinzufügen eines Seitenumbruchs (Reporting Services).
Komplexe Tablix-Datenbereichsgruppierung und Aggregatfunktionen
Viele Ebenen von geschachtelten und angrenzenden Gruppen in einem Tablix-Datenbereich können die Berichtsverarbeitungsleistung beeinträchtigen. Berücksichtigen Sie die Gruppierungsebene, die Anzahl von Gruppeninstanzen und die Verwendung von Aggregatfunktionen, die ausgewertet werden müssen, nachdem Gruppierungs-, Filter- und Sortierausdrücke angewendet wurden. Beispielsweise ist Previous eine aufwendige Aggregatfunktion, weil ihr Wert von den sortierten Elementen eines Datenbereichs abhängt. Für Sum ist die Reihenfolge nicht wichtig, und diese Funktion erfordert geringere Ressourcen. Weitere Aggregatfunktionen, die von der Sortierung abhängen, sind First und Last. Weitere Informationen finden Sie unter Verwenden von integrierten Berichts- und Aggregationsfunktionen in Ausdrücken (Reporting Services).
Überprüfen Sie den Entwurf des Berichts und erwägen Sie, ob in der Datenquelle Datenaggregation erfolgen kann. Möglicherweise reicht es aus, den Umfang an Daten im Bericht zu verringern, um eine akzeptable Leistung bereitzustellen, ohne Aggregatfunktionsaufrufe zu ändern.
Viele Instanzen von Unterberichten in einem Tablix-Datenbereich führen zu einer geringeren Berichtsleistung
Machen Sie sich mit den Vor- und Nachteilen der Verwendung von Unterberichten vertraut. Jede Instanz eines Unterberichts ist eine eigene Abfrageausführung und eine eigene Berichtsverarbeitungstask.
Verwenden Sie Unterberichte, wenn nur wenige Unterberichtsinstanzen vorhanden sind.
Verwenden Sie keine Unterberichte in einer Gruppe, wenn viele Gruppeninstanzen vorhanden sind. Um beispielsweise eine Liste von Verkäufen und Rückläufen für jeden Kunden anzuzeigen, bietet sich die Verwendung von Drillthroughberichten an. Überlegen Sie, ob Sie in der Abfrage den Kunden mit Verkäufen und Rückläufen verknüpfen und dann die Daten nach Kunden-ID gruppieren können.
Verwenden Sie Unterberichte, wenn für den Unterbericht eine andere Datenquelle als für den Hauptbericht verwendet wird. Bei Leistungsproblemen können Sie die Datasetabfrage im Hauptbericht mithilfe einer der folgenden Vermeidungsstrategien ändern:
Listen Sie Daten in einem Data Warehouse auf, und verwenden Sie das Data Warehouse als Datenquelle für ein einzelnes Dataset.
Verwenden Sie SQL Server-Verbindungsserver, und schreiben Sie eine Abfrage, die Daten aus mehreren Datenbanken abruft.
Verwenden Sie die OPENROWSET-Funktion, um unterschiedliche Datenbanken anzugeben.
Prozesse, die um den gleichen Arbeitsspeicher auf dem Berichtsserver konkurrieren
Mehrere Anwendungen, die um die gleichen Speicherressourcen auf einem Berichtsserver konkurrieren, können die Berichtsverarbeitung beeinträchtigen.
Überprüfen Sie gemeinsam mit dem Systemadministrator, ob die Berichtsverwaltungskonfiguration das geeignete Modell für Ihre Verwendung des Berichtsservers ist. Weitere Informationen finden Sie unter Konfigurieren des verfügbaren Arbeitsspeichers für Berichtsserveranwendungen.
Timeout der Berichtsausführung
Um umfangreiche Berichte auszuführen, müssen zwei Timeouts angepasst werden: Timeout für die Berichtsausführung und ASP.NET-Timeout.
Timeoutwerte für die Berichtsausführung werden im Berichts-Manager angegeben. Weitere Informationen finden Sie unter Festlegen von Timeoutwerten für die Berichtsverarbeitung.
ASP.NET-Timeoutrichtlinien werden von der Berichtsserver-Konfigurationsdatei gesteuert. Der Standardspeicherort für diese Datei ist <Laufwerk>:\Programme\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\web.config. Um die maximale Anzahl von Sekunden für die Ausführung einer Abfrage festzulegen, fügen Sie dieser Datei das httpRuntime-Element hinzu:
<configuration>
. . .
<system.web.
. . .
<httpRuntime executionTimeout="90"/>
. . .
</system.web.
. . .
</configuration>
Je nach Größe des Berichts muss dieser Wert möglicherweise mehrere Stunden darstellen.
Das Rendern meines Berichts erfordert zu viel Zeit.
Das Rendern eines Berichts erfolgt, nachdem Daten und Layout in einem zwischenzeitlichen Format kombiniert und dann an eine Renderingerweiterung übergeben wurden. Der Umfang der Daten, die Anzahl der Instanzen von Berichtselementen und die Paginierung können sich auf die Renderingdauer auswirken. Wenn Sie einen Bericht exportieren, übergeben Sie das zwischenzeitliche Format an einen bestimmten Renderer. Wenn Sie wissen, dass die Benutzer einen Bericht in einem bestimmten Format anzeigen, müssen Sie den Bericht für den entsprechenden Renderer optimieren. Weitere Informationen finden Sie unter Exportieren von Berichten und Grundlegendes zu Renderingverhaltensweisen.
Die Informationen in diesem Abschnitt helfen Ihnen dabei, die Renderingleistung für einen Bericht zu verbessern.
Bericht ist nicht für das ausgewählte Renderingformat optimiert.
Einige Features werden nicht von allen Renderern unterstützt. Wenn das primäre Format zum Anzeigen eines Berichts ein bestimmtes Dateiformat ist, müssen Sie eventuell den Berichtsentwurf ändern, um die Anzeige für den Benutzer zu optimieren.
Fügen Sie Seitenumbrüche hinzu, wo dies sinnvoll ist. Beispielsweise definiert jeder Seitenumbruch in Excel ein neues Arbeitsblatt. Jedes Arbeitsblatt kann maximal 65000 Zeilen behandeln. Berücksichtigen Sie diese Grenzen, wenn Sie die Seitenumbrüche in einem Bericht festlegen.
Führen Sie für den Export in Excel keine Zellen in einem Tablix-Datenbereich zusammen. Richten Sie Berichtselemente in Freiformberichten vertikal aus. Zusammengeführte Zellen und nicht ausgerichtete Berichtselemente behindern die Excel-Funktionalität im exportierten Bericht.
HTML-Parser sind zum Rendern sehr umfangreicher HTML-Seiten nicht besonders effizient. Wenn beim Rendern eines Berichts Probleme auftreten, sollten Sie ein Format auswählen, durch das kleinere Dateien generiert werden (z. B. CSV). Sollten Sie kein anderes Format auswählen können, weil die Berichtssymbolleiste nicht verfügbar ist, können Sie für ein Abonnement ein Renderformat definieren und den Bericht als statisches Dokument an eine Dateifreigabe übermitteln. Weitere Informationen finden Sie unter Dateifreigabeübermittlung in Reporting Services.
Entwurfstipps zum Optimieren der Berichtsverarbeitung
Wenn die Berichtsleistung für Sie von primärer Bedeutung ist, können Ihnen die folgenden Informationen dabei helfen, die Dauer der Berichtsverarbeitung zu verringern:
Legen Sie für Berichte mit vielen Instanzen von Textfeldern CanGrow und CanShrink für Textfelder auf FALSE fest. Standardmäßig enthält jede Zelle in einem Tablix-Datenbereich ein Textfeld. Daher kann die Anzahl der zu rendernden Textfelder schnell zunehmen.
Legen Sie für Berichte mit vielen Bildern AutoSize für Bilder auf einen anderen Wert, z. B. Fit, fest.
Legen Sie für Textfelder die Eigenschaft TextAlign nicht auf General fest. Dieser Wert erfordert eine bedingte Verarbeitung abhängig vom Inhalt des Textfelds.
Vermeiden Sie horizontale Seitenumbrüche, wenn sie nicht erforderlich sind. Überprüfen Sie die Ränder, Spaltenbreiten und Leerzeichen in einem Bericht. Rendern Sie beispielsweise den Bericht als TIFF-Datei, und zeigen Sie ihn in der Microsoft Windows Bild- und Faxanzeige an, um zu bestimmen, ob zusätzliche Seiten gerendert werden.
Legen Sie für Tablix-Elemente die KeepTogether-Eigenschaft nur fest, wenn Sie das spezifische Renderingverhalten für einen Tablix-Datenbereich steuern müssen. Das KeepTogether-Feature erfordert zusätzliche Verarbeitung, wenn Seitenumbrüche berechnet werden.