SSRS-Blockierungsprozesse

Wir haben einen ausgelasteten SSRS-Berichtsserver (SQL Server 2008 R2), auf dem häufig Blockierungen zwischen den folgenden Prozessen auftreten:

• [dbo]. [CheckSessionLock]
• [dbo]. [WriteLockSession]

Wir sind uns bewusst, dass einige Berichte unannehmbar langsam sind. Ich muss wissen, ob die Blockierung in der ReportServer-Datenbank symptomatisch für einen überlasteten Server ist oder ob die Blockierung dazu führt, dass die Berichte langsam ausgeführt werden.

Ich neige dazu zu glauben, dass dies der erste Fall ist, konnte aber keine Beweise dafür sammeln, dass dies definitiv der Fall ist.

Ich habe den Thread unter https://connect.microsoft.com/SQLServer/feedback/details/698388/blocking-in-ssrs-reportserver-database gelesen, in dem das Problem lose erkannt wird, aber ich kann nicht auf den zur Adressierung angegebenen Link zugreifen dieses Problem.

Haben einige das gleiche Problem mit dem Blockieren in der ReportServer-Datenbank auf den Grund gebracht?

Leider können Sie nicht viel dagegen tun, dieses Verhalten ist beabsichtigt. Das Problem tritt auf, wenn Benutzersitzungen eine Zeitüberschreitung aufweisen, da der Bericht zu lange dauert. Sie können versuchen, die Berichte zu verbessern, oder das Sitzungszeitlimit so konfigurieren, dass es etwas länger ist als der am längsten laufende Bericht

Unter diesem Link finden Sie eine Erklärung zum Warum und einige Möglichkeiten, dies zu umgehen.

Sie können das Sitzungszeitlimit erhöhen, um das Problem zu umgehen. Das Skript ist im Artikel dokumentiert.

Aus dem Artikel:

Es gibt jedoch ein Szenario, in dem der Ping nicht funktioniert, und zwar während der Ausführung des ersten Berichts. Das Problem besteht darin, dass während der Ausführung des Berichts die Sitzung des Benutzers gesperrt wird (während der temporäre Snapshot des Benutzers ausgefüllt wird) und das Keepalive des Viewer-Steuerelements blockiert wird. Normalerweise ist dies kein Problem, da die Ausführung von Berichten nicht lange dauern soll und häufig beendet wird, bevor das Sitzungszeitlimit erreicht ist. Leider gibt es einige Fälle, in denen die Ausführung von Berichten (aus welchen Gründen auch immer) unglaublich lange dauert. In diesem Fall ist die Sitzung des Benutzers während der Ausführung des Berichts veraltet, was zu allerlei seltsamem Verhalten führt.

Angenommen, Sie haben SQL 2008R2 oder höher.

Ja, wir haben dasselbe auch auf einem unserer häufig verwendeten SSRS-Berichtsserver gesehen, und bei der Fehlerbehebung ist dieses Verbindungselement aufgetreten , das als Fehler registriert ist.

Wie erklärt:

SSRS gibt diese Sperren aus, um einen Multithreading-Mechanismus bereitzustellen. Sobald alle Threads, in denen der von Ihnen geschriebene Bericht ausgeführt wird, beendet sind, wird die Sperre aufgehoben. Wenn Sie diese also sehen, ist es normalerweise eine langsame Abfrage auf einem anderen Server, die das Problem verursacht.

Einige Probleme können bei hoher Last auftreten (oder so heißt es), und einige berichten, dass Sortierprobleme die Ausführung von CleanExpiredSessions verhindern.

Ebenfalls,

Dieses Verhalten ist beabsichtigt. Um die Sitzungen am Leben zu erhalten, versucht die Viewer-Steuerung, sie alle 10 Minuten zu pingen. Auf der Serverseite wird der gespeicherte Prozess GetSessionData aufgerufen, der mit dem Aufruf des gespeicherten Prozesses CheckSessionLock beginnt, der versucht, die Schreibsperre für die Sitzung zu lesen. Wenn zum Zeitpunkt des Ping-Vorgangs die Berichtsverarbeitung noch ausgeführt wird, wird CheckSessionLock blockiert, da die Sitzungsschreibsperre während der Berichtsverarbeitung beibehalten wird. Das Zeitlimit für GetSessionData beträgt 10 Minuten (Systemeigenschaft "SessionAccessTimeout"). Wenn die Berichtsverarbeitung länger als 20 Minuten dauert, tritt eine Zeitüberschreitung bei GetSessionData auf und Sie sehen dieses Problem.

Weitere Informationen und Lösungen hierzu finden Sie unter Sitzungszeitlimit während der Ausführung

Das Sperren / Blockieren dient der Gewährleistung der Konsistenz und ist ein normales Verhalten.

Sie können versuchen, die Isolationsstufe für festgeschriebene Snapshots für die ReportServerTempDB-Datenbank und SET ISOLATION LEVEL SNAPSHOT in der WriteLockSession-Prozedur zu lesen

Ich habe die Lösung nicht implementiert und würde sie nicht empfehlen.

Die einzige Lösung für dieses Problem ist die Verwendung eines anderen Berichterstellungstools