Laden...

EF 6, Azure SQL DB ... The request limit for the database is XXX and has been reached

Erstellt von micha0827 vor 6 Jahren Letzter Beitrag vor 6 Jahren 1.183 Views
M
micha0827 Themenstarter:in
85 Beiträge seit 2015
vor 6 Jahren
EF 6, Azure SQL DB ... The request limit for the database is XXX and has been reached

verwendetes Datenbanksystem: MS SQL

Hallo Zusammen,

Ist wahrscheinlich eine Grundsatzfrage, aber ich komme im Moment da nicht weiter. Mein Hauptprogramm ruft in einer Schleife 3 Methoden auf die jeweils eine DB Connection benötigen. Die Werte für die Schleife kommen aus einer anderen DB. Ich arbeite immer mit using.

Habe schon 2 Varianten probiert, einmal ein Using in jeder Methode und auch ein Using vor der Schleife und die Connection an die Methode mit übergeben.

Immer bekomme ich einen Fehler: > Fehlermeldung:

"The request limit for the database is XXX and has been reached" . Die Schleife hat 55.000 Durchläufe und wird NICHT parallel abgearbeitet.

Hat jemand eine Idee ? Müsste der Using nicht automatisch die Connection wieder schliessen ?

Michael

16.834 Beiträge seit 2008
vor 6 Jahren

ADO.NET schließt keine Verbindungen (prinzipiell) sondern verwendet sie in einem eigenen Pool wieder.
Die Fehlermeldung kommt von Azure SQL und besagt, dass die aktuell verfügbaren/gebuchten DTUs ausgelastet sind.
Hier bezieht sich das Limit auf die Requests; in der Tabelle der DTU Übersicht auch ab und an Worker genannt.
Du hast es mit XXX verschleiert; auf alle Fälle wird genau das überschritten.

Das using() alleine kann nicht die Hilfe sein, da die Anzahl der Verbindungen (Sessions) auch nicht der Auslöser ist, sondern eben die Requests.
Du beschreibst aber, dass es prinzipiell eine serielle Verarbeitung ist und es demnach auch nur einen parallelen Request gibt.

Aber:
Intern in SQL - gerade bei Joins - wird aber der SQL Befehl parallel abgearbeitet.
Default mäßig ist das Max Parallelism von Azure SQL 0, was unlimitiert bedeutet.
Dies kann auch nur durch den Azure Support geändert werden.

Du kannst mal SELECT * FROM sys.resource_stat
ausführen und schauen, was bei max_worker_percent steht.
Das wird hier sicherlich bei 100% sein und daher kommt es zur Exception.

Mit Sessions hat die Fehlermeldung nichts zutun.
Steht ja auch Requests und nicht Connections in der Meldung 😉

M
micha0827 Themenstarter:in
85 Beiträge seit 2015
vor 6 Jahren

Kleines Update:

Der Fehler tritt auf wenn das Programm als Webjob in Azure ausgeführt wird. Lasse ich es als Konsolenanwendung auf einem Nicht Azure Server laufen, läuft es durch.

@Abt: das verschleierte Limit der Requests lag bei 400

Michael

16.834 Beiträge seit 2008
vor 6 Jahren

Die Exception kommt von der Datenbank; nicht vom Client.

Ich wüsste nicht, was daran der Client (hier WebApp vs Server) schuld sein könnte.