none
OBJECTSTORE LOCK MANAGER verwendet 27GB - Error 1204 - keine lock Escalation? RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich will mal schnell eine Frage loswerden, da ich gerade partout nicht weiter komme. Auf einem DB Server für Sharepoint läuft seit mehr als 5 Stunden schon ein INSERT INTO.... SELECT FROM

    Dies wurde von SP Seite aus initiiert, da eine TeamSite umziehen soll.

    Nun Folgendes Problem: Der Server wirft zwischendurch immer wieder 1204 Meldungen, dass kein Lock mehr gesetzt werden kann. Die Instanz hat nämlich die 60% upper Limit für den Lock Manager erreicht.

    Ursache ist das besagte INSERT, die dahinterliegende SPID hat unzählige Key und PageLocks. Unzählig deshalb, weil eine Abfrage auf sys.dm_tran_locks auch irgendwie ewig läuft. Ist auch wenig verwunderlich, wenn der Lock Manager 27GB verwendet. 

    Was ich jetzt nicht verstehe ist: Wieso erfolgt hier keine Lock Escalation auf die Zieltabelle?

    Eingesetzter SQL Server :  SQL 2014  build 12.0.2000  Std.Ed. Vielleicht hat ja jemand eine Erklärung.  Mein Workaround wäre ja, auf die Zieltabelle ein Tablock zu setzen. Aber da dies von Sharepoint Seite aus kommt, kann ich da derzeit nichts machen.

    Gruß

    Dirk

    May you never suffer the sentiment of spending a day without any purpose

    Mittwoch, 8. Juli 2015 14:03
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Dirk,

    das ist in der Tat merkwürdig. Auf Index-Ebene kann man festlegen, ob Row und/oder Page Locks erlaubt sind. Aber selbst wenn Page Locks hier abgeschaltet sind, sollte die Lock Escalation greifen und auf Table Lock hoch eskalieren; laut Sperrenausweitung (Datenbankmodul) ab 5000 Sperren auf einem einzelnem Objekt.

    Man kann auch auf Tabellen-Ebene über ALTER TABLE (Transact-SQL) mit dem Parameter LOCK_ESCALATION das Sperrverhalten beeinflussen, das könntest Du mal Versuchsweise auf TABLE setzen.,

    Da Du das 60% Limit erwähnst, kann es sein, das jemand per Trace Flag 1211 das Lock Escalation ausgehebelt hat? Siehe http://www.pythian.com/blog/disable-lock-escalation-in-sql-server/

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert Dirk Hondong Mittwoch, 8. Juli 2015 15:12
    Mittwoch, 8. Juli 2015 14:37
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi nochmal,

    unglaublich aber wahr:  die Tabelle als solche hat das Setting SET LOCK_ESCALATION = DISABLE

    Ergo: Das ist wohl ein Prob auf Sharepoint Seite O_o

    May you never suffer the sentiment of spending a day without any purpose


    Mittwoch, 8. Juli 2015 15:08
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Dirk,

    das ist in der Tat merkwürdig. Auf Index-Ebene kann man festlegen, ob Row und/oder Page Locks erlaubt sind. Aber selbst wenn Page Locks hier abgeschaltet sind, sollte die Lock Escalation greifen und auf Table Lock hoch eskalieren; laut Sperrenausweitung (Datenbankmodul) ab 5000 Sperren auf einem einzelnem Objekt.

    Man kann auch auf Tabellen-Ebene über ALTER TABLE (Transact-SQL) mit dem Parameter LOCK_ESCALATION das Sperrverhalten beeinflussen, das könntest Du mal Versuchsweise auf TABLE setzen.,

    Da Du das 60% Limit erwähnst, kann es sein, das jemand per Trace Flag 1211 das Lock Escalation ausgehebelt hat? Siehe http://www.pythian.com/blog/disable-lock-escalation-in-sql-server/

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert Dirk Hondong Mittwoch, 8. Juli 2015 15:12
    Mittwoch, 8. Juli 2015 14:37
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi Olaf,

    die Definition der Indizes ist "Standard". Also mit ROW_LOCKS und PAGE_LOCKS ON. Vom DB / Tabellendesign her halt das, was Sharepoint beim Anlegen einer Seite macht....

    DBCC Tracestatus (-1) hat kein Traceflag ausgegeben. Also auch hier nichts weg vom Standard konfiguriert.

    Ich hab auch schon gesehen, dass Adam MAchanic zu SQL 2008er Zeiten mal ein Connect Item bzgl. Large Insert und ausbleibender Lock Escalation gepostet. Aussage Microsoft zu dem ConnectItem "This will be fixed on SQL2008/PCU2. thanks"

    Eventuell versuche ich morgen das Ganze mal nachzustellen, auch mit unterschiedlichen SQL Server Builds und einer 52 Mio Zeilen Tabelle.  Dann bin ich nahe dran am derzetigen IST Zustand.

    May you never suffer the sentiment of spending a day without any purpose

    Mittwoch, 8. Juli 2015 15:01
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi nochmal,

    unglaublich aber wahr:  die Tabelle als solche hat das Setting SET LOCK_ESCALATION = DISABLE

    Ergo: Das ist wohl ein Prob auf Sharepoint Seite O_o

    May you never suffer the sentiment of spending a day without any purpose


    Mittwoch, 8. Juli 2015 15:08
    |
  • Question
    Anmelden
    0
    Anmelden

    Noch ein kleiner Nachtrag: Es ist ein default von Sharepointseite.  Es wird tatsächlich ein ALTER TABLE SET(LOCK_ESCALATION = DISABLE)  abgesetzt, wenn man eine neue Content Datenbank für Sharepoint anlegen lässt durch die SP Management Console.

    May you never suffer the sentiment of spending a day without any purpose

    Donnerstag, 9. Juli 2015 12:05
    |