Auf dieser Seite werden leistungsbezogene Probleme wie Zeitüberschreitungen, Ratenbegrenzungen und langsame Vorgänge behandelt.
API-Ratenbegrenzung (HTTP 429)
Fehler: „HTTP 429 – Zu viele Anfragen” oder „Dienstschutzgrenze überschritten”
Ursache: Ihre Anfragen überschreiten die Dataverse-API-Ratenbegrenzungen
Symptome:
• Vorgänge werden erheblich verlangsamt
• Sporadische Ausfälle mit Wiederholungsversuchen
• Fehlermeldungen mit Verweis auf „Drosselung“ oder „Ratenbegrenzung“
• Der Fortschritt stockt oder kehrt sich um, wenn Wiederholungsversuche unternommen werden
Informationen zu den Schutzgrenzen des Dataverse-Dienstes:
Microsoft Dataverse setzt Dienstschutzbeschränkungen durch, um die Stabilität der Plattform zu gewährleisten. Diese Beschränkungen werden in einem gleitenden 5-Minuten-Fenster bewertet und umfassen:
• Anzahl der Anfragen: 6.000 Anfragen pro Benutzer pro 5-Minuten-Fenster
• Ausführungszeit: 20 Minuten (1.200 Sekunden) kombinierte Ausführungszeit pro 5-Minuten-Fenster
• Gleichzeitige Anfragen: 52 gleichzeitige Anfragen pro Benutzer
Wenn eine dieser Beschränkungen überschritten wird, gibt Dataverse einen HTTP-429-Fehler zurück und fügt möglicherweise einen „Retry-After”-Header hinzu, der angibt, wie lange gewartet werden muss.
Lösungen:
1. Wechseln Sie zur voreingestellten Leistungseinstellung „Rate Safe” oder „Conservative”.
2. Reduzieren Sie die maximale Anzahl gleichzeitiger Entitäten auf 2 oder weniger
3. Reduzieren Sie die Batchgröße auf 100 oder weniger.
4. Führen Sie Vorgänge außerhalb der Spitzenzeiten aus.
5. Warten Sie 5 Minuten, bevor Sie es erneut versuchen – das gleitende Fenster wird zurückgesetzt
⚠ Wichtig: Wenn Sie das Ratenlimit erreicht haben, müssen Sie etwa 5 Minuten warten, bevor Sie es erneut versuchen. Wenn Sie es sofort erneut versuchen, schlägt der Vorgang weiterhin fehl und die Drosselungsdauer kann sich verlängern. Das 5-minütige gleitende Fenster bedeutet, dass mit der Zeit Ihre ältesten Anfragen aus dem Fenster „herausfallen“ und Kapazität freigeben.
💡 Tipp: DvSchemaSync verfügt über eine integrierte Wiederholungslogik, die Ratenbegrenzungen berücksichtigt. Wenn Sie jedoch ständig Drosselungen feststellen, sollten Sie Ihre Leistungseinstellungen reduzieren, anstatt sich auf Wiederholungsversuche zu verlassen, da diese den Gesamtdurchsatz verlangsamen.
Zeitüberschreitungsfehler
Fehler: „Zeitüberschreitung bei der Ausführung“ oder „Zeitüberschreitung bei der Anfrage“
Mögliche Ursachen:
• Sehr große Tabellen, deren Synchronisierung zu lange dauert
• Probleme mit der Netzwerklatenz
• Dataverse-Umgebung unter hoher Last
Lösungen:
1. Reduzieren Sie die Batchgröße, um weniger Datensätze pro Anfrage zu verarbeiten
2. Tabellen einzeln statt alle auf einmal synchronisieren
3. Führen Sie den Vorgang außerhalb der Spitzenzeiten durch, wenn die Umgebung weniger ausgelastet ist
Langsame Synchronisierungsleistung
Symptome: Synchronisierungsvorgänge dauern viel länger als erwartet
Optimierungstipps:
1. Parallele Verarbeitung aktivieren: Mehrere Entitäten gleichzeitig verarbeiten
2. Erhöhen Sie die Stapelgröße: Größere Stapel reduzieren den API-Overhead (sofern keine Ratenbeschränkungen erreicht werden).
3. Bulk Copy verwenden: Senken Sie den Bulk Copy-Schwellenwert für große Tabellen
4. Inkrementelle Synchronisierung: Nach der ersten Synchronisierung werden nur geänderte Datensätze synchronisiert.
5. Systemressourcen überprüfen: Ausreichende CPU-, Speicher- und Netzwerkbandbreite sicherstellen
Speicherprobleme
Fehler: „Nicht genügend Speicher“ oder Anwendung reagiert nicht mehr
Ursache: Verarbeitung sehr großer Tabellen oder zu viele gleichzeitige Vorgänge
Lösungen:
1. Reduzieren Sie die Stapelgröße, um weniger Arbeitsspeicher pro Vorgang zu verbrauchen.
2. Verringern Sie die maximale Anzahl gleichzeitiger Entitäten, um die parallele Speicherauslastung zu reduzieren.
3. Schließen Sie andere Anwendungen, um Systemspeicher freizugeben
4. Wechseln Sie zur Voreinstellung „Konservativ“, um die Speicherauslastung zu minimieren
Zeitüberschreitungen bei automatischer Pause in Azure SQL
Fehler: Zeitüberschreitung bei der Verbindung oder „Datenbank ist angehalten“ beim ersten Synchronisierungsversuch
Ursache: Azure SQL Serverless-Datenbanken werden nach einer bestimmten Zeit der Inaktivität automatisch angehalten, um Kosten zu sparen. Wenn DvSchemaSync versucht, eine Verbindung zu einer angehaltenen Datenbank herzustellen, muss Azure die Datenbank „aufwärmen”, bevor sie Verbindungen akzeptieren kann. Dieser Aufwärmprozess kann 30 bis 60 Sekunden oder länger dauern, was die standardmäßige Verbindungszeitüberschreitung überschreiten kann.
Symptome:
• Der erste Verbindungsversuch nach einer Zeit der Inaktivität schlägt mit einem Zeitüberschreitung fehl
• Nachfolgende Verbindungsversuche sind erfolgreich
• Das Problem tritt erneut auf, nachdem die Datenbank inaktiv war (in der Regel 1 Stunde ohne Aktivität).
Lösungen:
1. Wiederholen Sie den Verbindungsversuch: Versuchen Sie nach einer kurzen Wartezeit einfach erneut, die Synchronisierung durchzuführen – die Datenbank sollte dann bereit sein
2. Datenbank vorwärmen: Testen Sie vor der Synchronisierung die Verbindung in der Verbindungsverwaltung, um die Datenbank zu aktivieren
3. Pausierungsverzögerung anpassen: Erhöhen Sie im Azure-Portal die Pausierungsverzögerung oder deaktivieren Sie sie für häufig verwendete Datenbanken
4. Planen Sie regelmäßige Aktivitäten: Richten Sie eine geplante Aufgabe ein, um die Datenbank regelmäßig abzufragen und eine Pause zu vermeiden.
5. Wechseln Sie zur bereitgestellten Ebene: Wenn die automatische Pause häufig Probleme verursacht, sollten Sie einen Wechsel von Serverless zu einer bereitgestellten Rechenebene in Betracht ziehen.
💡 Tipp: Azure SQL Serverless ist kostengünstig für die sporadische Nutzung, aber wenn Sie geplante Synchronisierungen durchführen oder konsistente Antwortzeiten benötigen, ist eine Provisioned-Tier möglicherweise besser geeignet.
Empfehlungen für Azure SQL-Stufen
Die Auswahl der richtigen Azure SQL-Stufe hängt von Ihrem Datenvolumen, der Synchronisierungshäufigkeit und den Leistungsanforderungen ab. Die folgenden Empfehlungen basieren auf typischen DvSchemaSync-Workloads:
| Datengröße | Empfohlene Stufe | Hinweise |
|---|---|---|
| < 5 GB | Basic (5 DTU) oder S0 | Geeignet für kleine Umgebungen, Entwicklung oder Tests. Niedrige Kosten, aber eingeschränkte Leistung. |
| 5–20 GB | S1 oder S2 (20–50 DTU) | Gut geeignet für kleine bis mittlere Produktionsumgebungen. Verarbeitet gleichzeitige Synchronisierungsvorgänge. |
| 20–100 GB | S3 oder S4 (100–200 DTU) | Empfohlen für mittlere Produktions-Workloads. Unterstützt die voreingestellte ausgewogene Leistung. |
| 100–500 GB | S6/S7 oder P1/P2 | Große Umgebungen mit hohem Synchronisierungsvolumen. Die Premium-Stufe bietet eine bessere E/A-Leistung und In-Memory-OLTP. |
| > 500 GB | P4/P6 oder Hyperscale | Bereitstellungen im Unternehmensmaßstab. Hyperscale bietet schnelle Skalierung und bis zu 100 TB Speicherplatz. |
Serverlos vs. bereitgestellte Rechenleistung:
| Funktion | Serverlos | Provisioned |
|---|---|---|
| Am besten geeignet für | Intermittierende, unvorhersehbare Workloads | Konsistente, geplante Arbeitslasten |
| Abrechnung | Pro Sekunde berechnete Rechenleistung | Fester Stundensatz |
| Automatische Pause | Ja (konfigurierbar von 1 bis 7 Tagen) | Nein – läuft immer |
| Kaltstart | 30–60+ Sekunden nach Pause | Keine – sofortige Reaktion |
| Synchronisierungsanwendungsfall | Manuelle/Ad-hoc-Synchronisierungen | Täglich/stündlich geplante Synchronisierungen |
⚠ Wichtig: Dies sind allgemeine Empfehlungen. Ihre tatsächlichen Anforderungen können je nach Anzahl der synchronisierten Tabellen, Datensatzanzahl, Synchronisierungshäufigkeit und gleichzeitigen Benutzern, die Berichte für die Datenbank ausführen, variieren. Überwachen Sie Ihre DTU/vCore-Nutzung im Azure-Portal und skalieren Sie nach oben, wenn Sie die Auslastung von 80 % regelmäßig überschreiten.