There is no data in the database for @CatalogItemId
Heute mal die kurze Beschreibung einer Fehlersituation, zu der ich sonst nichts im Internet finden konnte. Es dauerte etwas, bis ich die eigentliche Ursache erkannte und abstellen konnte.
Die Symptome
Ein User will auf dem Reportserver (in diesem Fall ein Power BI Report Server) ein Dashboard öffnen und nach ca. 30 Sekunden erhält er lediglich einen weißen Bildschirm anstelle des Dashboards zurück.
Die Fehlersuche
Auch wenn der User keinerlei Fehlermeldung erhält, kann man als Administrator doch immerhin auf die zahlreichen Logfiles des Power BI Report Servers zurückgreifen. Diese findet man im Installationspfad des Power BI Report Servers im Unterverzeichnis LogFiles. Z. B.: "c:\Program Files\Microsoft Power BI Report Server\PBIRS\LogFiles"
Ein kleiner Hinweis am Rande: Wenn man den Power BI Report Server auf C installiert, dann legt er auch seine interne Analysis Service Datenbank dort ab. Falls man das nicht auf C haben will, sollte man sich vorher (!) Gedanken darüber machen.
Fündig wird man im RSPowerBI Log.
2020-11-04 14:40:24.5245|ERROR|145|Unhandled error in the Web API| GET --hier steht die Ressource, bzw. das Dashboard-- Response Unknown| RequestID = --id-- ClientSessionID = --id-- System.IO.IOException: There is no data in the database for @CatalogItemId=e8efe507-4020-48c2-b011-c05b87a7df30; @ContentType=PowerBIReportDefinition
Mit der oben aufgeführten @CatalogItemId kann man im Catalog des Reportservers mal nachschauen, welches Objekt betroffen war, um sicherzustellen, dass diese Meldung auch zu dem Aufruf gehört.
SELECT Path, NameFROM ReportServerPBI.dbo.Catalog
WHERE ItemID = 'e8efe507-4020-48c2-b011-c05b87a7df30';
Falls man die Report Server Datenbank anders benannt hat, ist dies entsprechend zu ändern. Wenn man also sicher ist, dass die Fehlermeldung auch zu dem versuchten Aufruf gehört, ist man schon mal ein Stück weiter, aber noch nicht am Ziel. Warum liefert das Statement ein Resultat, aber der Power BI Report Server konnte darauf nicht zugreifen? Man vermutet recht schnell eine Sperre auf der Datenbank oder Tabelle. Aber von wem?
Hier hilft der Report aus dem Management Studio weiter, der auf Datenbankebene die "Top Transactions by Locks Count" liefert. Wendet man diesen Report auf die Power BI Report Server Datenbank an, sieht man exklusive PAGE-locks auf dbo.CatalogItemExtendedContent. Verursacher war hier ein Update:
UPDATE[dbo].[CatalogItemExtendedContent]
SET [Content]
.WRITE(@Chunk, @Offset, @Length)
WHERE
[Id] = @I
Wer macht denn Updates auf diese Tabelle? Das kann eigentlich nur eine Aktualisierung der Daten sein, von einem Report, der periodisch immer wieder Daten zieht und als Snapshot zur Verfügung stellt. Man sollte hier auch die Uhrzeit des Fehlers etwas im Auge haben. Aber aufgepasst, dies ist nicht die Uhrzeit, wann die Datenaktualisierung gestartet wurde. Diese sieht man z. B. am zugrundeliegenden SQL Server Agent Job, oder auch am Zeitplan im Report Server. Wir können aber auch mit dem Zeitpunkt der Fehlermeldung (ohne Millisekunden) im Execution-Log des Report Servers nachschauen.
-- Was passierte zu dem ZeitpunktSELECT ItemPath, RequestType, ItemAction, TimeStart, TimeEnd, TimeDataRetrieval, Status, ByteCount, ByteCount/1024/1024 AS ByteCount_MB
FROM ReportServerPBI.dbo.ExecutionLog3
WHERE '2020-11-04 14:40:24' BETWEEN TimeStart AND TimeEnd
ORDER BY TimeStart ;
In meinem Fall hat die Datenaktualisierung erst ca. 10 Minuten nach dem Start des Jobs wirklich die Sperre auf der Datenbank produziert. Im Resultset des oben angegebenen Statements sieht man auch den genauen Zeitraum und die Datenmenge, die hier geschrieben wurde.
RequestType | ItemAction | TimeStart | TimeEnd | TimeDataRetrieval | Status | ByteCount | ByteCount_MB |
---|---|---|---|---|---|---|---|
Refresh Cache | SaveToCatalog | 2020-11-02 10:10:01.283 | 2020-11-02 10:13:10.950 | 0 | rsSuccess | 552251392 | 526 |
Hier habe ich den ITEMPATH im Resultset weggelassen um noch einmal genauer darauf einzugehen. Der Wert, der hier zurück gegeben wird, ist genau der Wert, der auch im Select gegen den Catalog geliefert wird. Damit haben wir sichergestellt, dass auch diese Protokollierung wirklich zur Fehlermeldung gehört.
Die Fehlerbehebung
Die Behebung dieses Fehlers gestaltet sich deutlich schwieriger und ist individuell unterschiedlich. Entweder schafft man es, die Daten zur Aktualisierung kleiner zu halten, oder das Intervall der Aktualisierung zu vergrößern, damit der Fehler seltener auftritt. Idealerweise, findet die Aktualisierung nur zu Zeiten statt, wo der Report Server nicht von Anwendern genutzt wird. In diesem Fall sollte aber alle 15 Minuten eine Aktualisierung durchgeführt werden und wir werden durch konzeptionelle Änderungen dieses Intervall gewährleisten ohne diese großen Datenmengen bewegen zu müssen.
Print article | This entry was posted by cmu on 05.11.20 at 08:13:00 . Follow any responses to this post through RSS 2.0. |