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, Name
FROM 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 Zeitpunkt 
SELECT 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.

RequestTypeItemActionTimeStartTimeEndTimeDataRetrievalStatusByteCountByteCount_MB
Refresh CacheSaveToCatalog2020-11-02 10:10:01.2832020-11-02 10:13:10.9500rsSuccess552251392526

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.