SQL Azure - Ein session-locking gesamte DB für Update-und Insert

Azure SQL-Problem.

Ich habe ein Problem, manifestiert sich als die folgende Ausnahme auf unseren (asp.net) Webseite:

Timeout ist abgelaufen. Das Zeitlimit wurde vor Abschluss
der Betrieb oder der server reagiert nicht. Die Anweisung wurde
beendet.

Es führt auch in update-und insert-Anweisungen niemals den Abschluss in SMS-Nachrichten. Es gibt keine X-oder IX-sperren vorhanden, wenn Abfragen von: sys.dm_tran_locks und es gibt keine Transaktionen, die bei der Abfrage sys.dm_tran_active_transactions oder sys.dm_tran_database_transactions.

Das problem vorhanden ist, für jede Tabelle in der Datenbank sondern auch andere Datenbanken auf der gleichen Instanz nicht das problem verursachen. Die Dauer kann man das Problem überall von 2 Minuten bis 2 Stunden und geschieht nicht an bestimmten Zeiten des Tages.

Die Datenbank nicht voll ist.

Irgendwann dieses Problem nicht selbst lösen, aber ich war in der Lage, das Problem zu beheben, indem Sie eine Abfrage sys.dm_exec_connections finden die am längsten laufende Sitzung, und dann töten Sie es. Das seltsame ist, daß die Verbindung war 15 Minuten alt, aber das lock-Problem anwesend waren, für über 3 Stunden.

Gibt es etwas, was ich überprüfen kann?

BEARBEITEN

Als pro Paul ' s Antwort weiter unten. Ich würde eigentlich spürte Sie das problem, bevor er antwortete. Ich poste die Schritte, die ich verwendet, um dies herauszufinden unten aufgeführt, falls Sie Hilfe jemand anderes.

Folgende Abfragen ausgeführt wurden, wenn ein "timeout-Zeit" vorhanden war.

select *  from sys.dm_exec_requests

SQL Azure - Ein session-locking gesamte DB für Update-und Insert

Wie wir sehen können, alle WARTEN Anfragen warten auf Sitzung 1021, die die Replikation Anfrage! Die TM Request zeigt eine DTC-Transaktion und wir nicht verteilte Transaktionen verwenden. Sie können auch sehen, die wait_type von SE_REPL_COMMIT_ACK was wiederum impliziert die Replikation.

select * from  sys.dm_tran_locks

SQL Azure - Ein session-locking gesamte DB für Update-und Insert

Wieder warten auf die Sitzung 1021

SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc

SQL Azure - Ein session-locking gesamte DB für Update-und Insert

Und ja, SE_REPL_CATCHUP_THROTTLE hat eine Gesamt-Wartezeit von 8094034
ms ist 134.9 Minuten!!!

Siehe hierzu auch das folgende forum für Informationen zu diesem Thema.
http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8

Habe ich die folgende Antwort in meiner Kommunikation mit
Microsoft (wir haben gesehen, dass dieses Problem mit 4 unserer 15 Datenbanken in der EU
data center):

Frage: gab es Veränderungen, um diese weichen
Drosselung Grenzen in den letzten drei Wochen der ie da so meine Probleme
gestartet?

Antwort: Nein, gibt es nicht.

Frage: gibt es Möglichkeiten, wie wir können
verhindern oder gewarnt werden, wir nähern uns einer Grenze?

Antwort: Nein. Das Problem
kann nicht sein, verursacht durch Ihre Anwendung kann aber, verursacht durch andere
Mieter sich auf der gleichen physischen hardware. In anderen Worten, Ihre
Anwendung kann sehr wenig Last und noch laufen in das problem.
In anderen Worten, Ihren eigenen Verkehr kann eine Ursache für dieses problem, aber
es kann genauso gut sein, verursacht durch andere Mieter sich auf der gleichen
physische hardware. Es gibt keine Möglichkeit, vorher zu wissen, dass das Problem
wird bald auftreten - es kann jederzeit auftreten, ohne Vorwarnung. Die SQL
Azure-operations-team überwacht nicht diese Art von Fehler, so dass Sie
nicht automatisch versuchen, das problem zu lösen für Sie. Also, wenn Sie laufen
in es haben Sie zwei opitions:

  1. Erstellen einer Kopie der db und verwenden, und hoffen, dass die db ist platziert auf einem anderen server mit weniger Last.

  2. - Kontakt Windows Azure-Unterstützung und informieren über das problem und lassen Sie Sie tun, Option 1 für Sie

InformationsquelleAutor Sam Shiles | 2013-04-03
  1. 9

    Könnten Sie ausgeführt werden, in der SE_REPL* Probleme, die derzeit plagen Sie eine Menge Leute, die mit Sql Azure (meine Firma eingeschlossen).

    Wenn Sie erleben Sie die timeouts, versuchen Sie, Ihre Anfragen warten wait-Typen:

    • SE_REPL_SLOW_SECONDARY_THROTTLE
    • SE_REPL_COMMIT_ACK

    Führen Sie den folgenden, um zu überprüfen Ihre wait-Typen auf aktuelle verbindungen:

    SELECT TOP 10 r.session_id, r.plan_handle,
r.sql_handle, r.request_id,
r.start_time, r.status,
r.command, r.database_id,
r.user_id, r.wait_type,
r.wait_time, r.last_wait_type,
r.wait_resource, r.total_elapsed_time,
r.cpu_time, r.transaction_isolation_level,
r.row_count
FROM sys.dm_exec_requests r

    Können Sie auch prüfen, eine Geschichte von Arten, für die dies durch ausführen von:

    SELECT * FROM sys.dm_db_wait_stats
ORDER BY wait_time_ms desc

    Wenn Sie sehen, eine Menge von SE_REPL* wait-Typen und diese bleiben auf Ihrem verbindungen für irgendeine Länge von Zeit, dann, im Grunde sind Sie geschraubt.
    Microsoft kennt das problem, aber ich habe ein support-ticket öffnen, für eine Woche mit Ihnen jetzt, und Sie arbeiten immer noch daran offenbar.

    Den SE_REPL* wartet dann passieren, wenn die Azure Sql-Replikation-slaves hinter fallen.
    Im Grunde das ganze db unterbricht Abfragen während der Replikation holt :/

    Also im wesentlichen die Aspekt macht Sql Azure hochverfügbare verursacht Datenbanken werden nach dem Zufallsprinzip nicht verfügbar.
    Ich würde lachen über die Ironie, wenn Sie nicht töten Sie uns.

    Haben Sie einen Blick auf diesen thread für details:
    http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8

    • Tausend Dank Paul, Sie nur bestätigt das Fazit kann ich zu! Ich werde zu aktualisieren meinem Beitrag, mit den Daten die ich habe aus, falls es anderen hilft, zu diagnostizieren. Ich habe auch eröffnete ein support-Problem mit MS über diese. Wir sind gold-partner, für alle, die zählt, so dass wir hoffentlich eine Antwort bekommen irgendwann vor Weihnachten!
    • Keine Sorge, tut mir Leid zu hören, Sie haben die gleichen Probleme wie wir. Es ist ein ernsthaftes problem, das so ziemlich unmöglich, zu mildern aus einem coding-Perspektive.
    • Dank einer Tonne für diese Paulus, ich habe seit der Begegnung mit den gleichen Fragen und haben die Jagd überall für eine vernünftige Antwort. Das war mein Verdacht, und Ihre Abfragen geholfen, es zu bestätigen.
    • Keine Sorge, doofer Sie sind, leiden diese auch. Ich denke, das problem ist viel mehr verbreitet als MS ist die Vermietung auf. Mein support-ticket ist noch offen und der dude ich bin den Umgang mit ist ehrlich gesagt ein idiot. Ich lernte mehr über das problem zu googeln, als ich aus meiner support-Kerl. Haben sich die Dinge verbessert, die für uns etwas, was gut ist, da es kauft uns Zeit, um herauszufinden, ob oder nicht zu tun, eine (schmerzhafte, kostspielige) migration zu Amazon RDS. Schade das MS nicht bieten Sql Azure in eine reserved instance-Kapazität :/
    • Paul, wir haben die gleiche Erfahrung gemacht wie du. Obwohl da Amazon RDS bietet keine Multi-AZ-Bereitstellungen für SQL Server, den wir besorgt sind, Amazon die Zuverlässigkeit könnte nicht viel besser sein, als Sql Azure so betrachten, Rackspace und GoGrid.
    • Dieses Problem weiterhin besteht, auch in 2014. In meinem Fall MS-Support wurde langsam erkennen das Problem selbst mit Diagnose-Berichte, die sehr deutlich zeigen, jede Aktualisierung warten auf SE_REPL_SLOW_SECONDARY_THROTTLE. Ich habe bewegen die betroffene Datenbank aus der SQL Azure.

    InformationsquelleAutor Paul DB
Schreibe einen Kommentar