none
DBCC CheckDB im "suspend" Modus RRS feed

  • Frage

  • Hallo,

    der folgende Check steht seit Stunden im Status "suspend":

    DBCC CHECKDB ([meine_Datenbank]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY

    Das ist dem Maintenance von Ola entnommen.

    Nun denn, wie oben beschrieben bleibt der Check sporadisch im Status SUSPEND stehen. Normale Laufzeiten sind 20 Sekunden, aber wir liegen hier im Extremfall bei vielen Stunden.

    Nach ersten Recherchen steht das wohl im Zusammenhang mti dem "Service Broker". Dieser läuft auf den betroffenen Datenbanken aktuell ist. Und in meiner ganzen Laufbahn ist mir das in der Form auch noch nicht vorgekommen.

    Die Datenbanken liegen aktuell auf einem MS SQL Server 2016 (aktueller Patchlevel). Dort betreiben wir ein AOAG mit 2 Nodes.

    Nun die Frage der Fragen, muss für einen erfolgreichen DBCC CheckDB der Service Broker laufen?

    Führt man die oben gezeigte Query manuell aus, so ist der Job teilweise in wenigen Sekunden durchgelaufen.

    Ich konnte weder im ERRORLOG noch im Defaulttrace verwertbare Infos finden.

    Bin über kreative Ideen / Vorschläge dankbar,

    Grüße

    Andreas


    Donnerstag, 29. März 2018 05:48

Antworten

  • Hallo,

    also nach ersten tiefergehenden Analysen zeigte sich, dass es wohl ein RAM Problem war. Bei den Waits zeigte sich, dass die folgenden Waits über 80% der aktuellen Waits ausmachen:

    RESOURCE_SEMAPHORE

    Daher wurde eine Aufstockung des RAM beauftragt, welche noch aussteht. Das würde aber auch das Verhalten erklären, dass die Jobs mal laufen, und mal Stundenlang auf ein Ergebnis warten lassen.

    Wenn der RAM so klein ist, dass sogar die Ausführung der Query mehr oder weniger verweigert wird, bis entsprechend RAM zur Ausführung bereit ist.

    Nun denn, hausgemachter Fehler, wäre vielleicht mit einer gescheiten Monitoring-Lösung früher zu erkennen gewesen.

    Ich werde, sobald mehr RAM konfiguriert ist, und das Problem damit behoben ist, den Beitrag hier als "beantwortet" markieren.

    Beste Grüße

    Andreas

    Mittwoch, 4. April 2018 05:39

Alle Antworten

  • Hallo Andreas,

    so wie ich das sehe, muss der Service Broker nicht unbedingt laufen. Eine vollständige Beschreibung zum DBCC gibt es von Paul Randall: CHECKDB From Every Angle: Complete description of all CHECKDB stages

    Dein DBCC wartet auf irgendeine Sperre. Welche Art von Sperre, solltest Du im Aktivitätsmonitor sehen, sowie auch die andere Session welche sperrt. Du kannst auch auf der Datenbank den Standard-Bericht für "Alle blockierenden Transaktionen" ausführen.

    Auf jeden Fall kannst Du danach das DBCC gefahrlos beenden (KILL). 


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Donnerstag, 29. März 2018 07:00
    Beantworter
  • Hallo,

    habe mal versucht, das nachzustellen. Der Job läuft nach wenigen Sekunden in den Status suspended, aber im dem von dir genannten Bericht ist kein Blocking zu erkennen.

    Der Job macht auch zwischendurch überhaupt gar nix, CUPTime und DiskIO blieben konstant. Muss jetzt leider los, aber ich glaube, ich muss mein Setup zur Fehlersuche etwas aufbohren.

    Grüße

    Andreas

    Donnerstag, 29. März 2018 07:36
  • Hallo,

    also nach ersten tiefergehenden Analysen zeigte sich, dass es wohl ein RAM Problem war. Bei den Waits zeigte sich, dass die folgenden Waits über 80% der aktuellen Waits ausmachen:

    RESOURCE_SEMAPHORE

    Daher wurde eine Aufstockung des RAM beauftragt, welche noch aussteht. Das würde aber auch das Verhalten erklären, dass die Jobs mal laufen, und mal Stundenlang auf ein Ergebnis warten lassen.

    Wenn der RAM so klein ist, dass sogar die Ausführung der Query mehr oder weniger verweigert wird, bis entsprechend RAM zur Ausführung bereit ist.

    Nun denn, hausgemachter Fehler, wäre vielleicht mit einer gescheiten Monitoring-Lösung früher zu erkennen gewesen.

    Ich werde, sobald mehr RAM konfiguriert ist, und das Problem damit behoben ist, den Beitrag hier als "beantwortet" markieren.

    Beste Grüße

    Andreas

    Mittwoch, 4. April 2018 05:39
  • Hallo,

    sodele, nach den letzten Prüfungen läuft der Job für DBCC CheckDB nun ohne Probleme.

    Es lag wohl wirklich an zu geringem Speicher für den SQL Server.

    Daher wäre der Fall gelöst.

    Beste Grüße

    Andreas

    PS: Kann man seine eigene Antwort als Antwort markieren?

    Freitag, 6. April 2018 08:34
  • Hallo Andreas. Das kann man. Oft etwas seltsam, aber in dem Fall ist es ja eindeutig.

    Die Waits an sich würde wohl jedes halbwegs taugliche Tool anzeigen, in der Tat. Bei SQLSentry wären Dir unter Garantie auch einige Alerts hochgepoppt, da das auch auf unterschiedlich komplex berechnete Schwellwerte setzt.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)

    Freitag, 6. April 2018 14:10