Es gibt bereits mehrere Themen zum Thema 429, aber die Erklärungen unterscheiden sich. Deshalb eröffne ich ein separates Thema für meine eigene Situation.
Ich habe ein Einstiegs-OEM-Konto und habe in den letzten Tagen regelmäßig mit 429-Fehlermeldungen für mehrere Datenbanken zu kämpfen.
Könnt ihr einsehen, ob es ein Problem mit meiner Konfiguration oder vielleicht dem Konto gibt?
Ich habe zufällig diese Woche meine erste Rechnung erhalten, ich weiß nicht, ob das damit etwas zu tun haben könnte?
Vielen Dank für die schnelle Antwort. Mein Live- und Verlauf-Monitoring ist komplett leer (obwohl Aktivitäten ausgeführt wurden und auch wenn ich mehrere Einträge pro Seite auswähle), daher kann ich das Obige nicht ausführen.
Das ist für mich übrigens auch neu; normalerweise wurde hier der Verlauf problemlos angezeigt.
Der itgenboe405 weist darauf hin, dass die Gesamtdauer pro Tag überschritten wurde (TotalDurationMsPerDay).
Es wird empfohlen, die Gesamtdauer aller Anfragen zu optimieren. Die erlaubte Dauer in dieser Form beträgt 1 Stunde, aber es gab ungefähr 4 Stunden durchgehende Aktivität.
Eine Übersicht aller Fehlercodes, die zu einem 429 führen, finden Sie unter:
Gilt das eine Stunde pro Datenbank oder insgesamt?
Übrigens finde ich die Dauer an sich auch sehr lang, besonders da meine Kunden einige Tabellen mit ca. 400k (2 bis 3) haben und der Rest allesamt kleine Dimensionen sind. Die Aktualisierungszeiten bei Vollbeladung dauern etwa 30-45 Minuten.
Gibt es an der Konfigurationsseite der Datenbank etwas, das man tun kann, um dies zu beschleunigen? Beispielsweise Seitengrößen?
Ok, also sehe ich, dass es eine Anzahl von API-Aufrufen pro Tag gibt. Gilt dies jedoch pro Datenbank? Oder wird das Limit auf alle Datenbanken angewendet, sobald es irgendwo überschritten wird?
Alle Grenzen gelten über alle Aktivitäten einer Umgebung hinweg, also auch über Datenbanken hinaus.
Die Grenzen sind im Allgemeinen besonders großzügig bemessen. Sollten Sie dennoch an diese stoßen, wird empfohlen zu prüfen, welche Aktionen einen unverhältnismäßig großen Teil des Limits beanspruchen und diese zu optimieren.
Ich habe mir die Monitoring-Ausgabe angesehen und sehe darin tatsächlich erhebliche Redundanz. Aber wenn ich meinen eigenen Code in Power BI betrachte, ist der Code selbst nicht ineffizient, sondern die inhärente Struktur von Power BI:
Für jede Abfrage werden die Metadaten (odata4/$metadata) erneut abgefragt, selbst wenn es dieselben Metadaten sind. Staging-Tables sind außerdem nicht möglich, wodurch jede Abfrage erneut eine Anfrage an Invantive sendet. Zum Beispiel für die Sales-Order-Tabelle (ExactOnlineREST.SalesOrder.SalesOrderLines@eol):
09-06-2026 01:10:21
09-06-2026 01:13:40
09-06-2026 01:15:11
09-06-2026 01:18:30
09-06-2026 01:20:01
Da der Connector für Power BI gedacht ist und dies ein grundsätzliches Problem in der Art und Weise ist, wie PBI selbst aktualisiert, weiß ich nicht, was ich tun kann.
Außerdem der Punkt: Wenn das Limit für meine gesamte Umgebung auf OEM gilt und dort 4 Kunden anhängen, die jeweils eine tägliche Aktualisierung haben, erreiche ich dieses Limit viel schneller, als wenn diese 4 Kunden ein eigenes Konto hätten. Während ich dasselbe bezahle wie die 4 Kunden zusammen, oder?
Jede Aktualisierung pro Umgebung dauert etwa 1500 Sekunden, was mit einem Limit von 10k in Ordnung ist. Mit 4 Umgebungen (und ich hoffe, mehr hinzuzufügen) sind das 6000 pro Tag. Mit der Entwicklung und möglicherweise einem zusätzlichen Aktualisierungszeitpunkt im Laufe des Tages komme ich sehr schnell über dieses 10k-Limit hinaus.
Danke für die Antwort. SalesOrderLines habe ich anstelle des Bulkprozesses verwendet, da in der Nicht-Bulk-Version einige Spalten enthalten sind, die in der Bulk-Version nicht vorhanden sind. Ich konnte jedoch erheblich beschleunigen, indem ich eine frühere Filterung angewendet habe. Ich werde das auch für andere Abfragen tun, damit das Folding nicht unterbrochen wird.
Ein weiterer großer Beitrag zur Aktualisierungszeit ist ‚odata4/$metadata‘. Kann man hier etwas tun oder ist das inhärent mit der Anzahl der ausgeführten Abfragen verbunden?
Wenn es korrekt ist, sollten alle Felder von SalesOrderLines auch in SalesOrderLinesBulk zu finden sein und umgekehrt. Welche spezifischen Felder fehlen?
Das Abrufen der $metadata sollte nach dem ersten Abruf nur wenige Millisekunden dauern. Es wird empfohlen zu überprüfen, dass nicht zu viele gleichzeitige Anfragen laufen, die dennoch länger warten müssen.
Ab der Version 26.0.285 wird die bei Code itgenboe405 gemeldete Zeit nicht mehr die Wartezeit umfassen, sondern nur die Ausführungszeit. Dies erhöht den verfügbaren Speicherplatz, insbesondere wenn ein Prozess aus dem Ruder gelaufen ist oder wenn viele Anfragen gleichzeitig eingehen, bei denen ein Teil warten muss.
Diese Frage wurde nach einer Woche Inaktivität automatisch geschlossen. Die letzte gegebene Antwort wurde als Lösung markiert.
Bitte stellen Sie eine neue Frage in einem separaten Thema, wenn das Problem erneut auftritt. Bitte fügen Sie in der neuen Frage einen Link zu diesem Thema ein, indem Sie die URL in den Text einfügen.
