none
SQL 2012: tempdb bleibt konstant bei 200 MB RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo!

    In einer NAV-Installation mit ca. 30 Usern bleibt die tempdb konstant beim Anfangswert von 200 MB stehen. Die Datenbank ist mittlerweile 44 GB groß.

    Da es einige Performance-Probleme gibt, habe ich mit die Einstellungen den tempdb angesehen und wollte die ggf. auf mehrere files aufteilen, doch wenn die Datei sich nicht vergrößert, sehe ich keinen Sinn darin.

    Kann es sein, dass die tempdb nicht verwendet / benutzt wird?
    Welche Gründe kann es geben, dass die Datei bei unter 200 MB "stehen bleibt"?


    • Bearbeitet H.Picht Mittwoch, 4. Juli 2018 12:34
    Mittwoch, 4. Juli 2018 12:27
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Wie du schon sagst, tempdb wird nur in wenigen Fällen überhaupt verwendet und ist somit auch kein Performanceproblem.

    Wenn Performanceprobleme auftreten muss man diese konkret an den ausgeführten SQL's festmachen. Bei unglücklicher Kodierung dauern manche Abfragen eben erheblich länger und können, je nach Server-Hardware (CPU's, Speicher, parallele Ausführung) ebenso auch andere Abfragen massiv beeinflussen.

    Mittwoch, 4. Juli 2018 14:44
    |
  • Question
    Anmelden
    2
    Anmelden

    Da muss ich jetzt aber sehr widersprechen. 

    Die TempDB wird so ziemlich bei allen komplexeren Operationen des SQL Server verwendet und hat extremen Einfluss auf die Leitung des SQL Servers. Auch wenn sich zeitgleich nicht große Mengen an Daten in der TempDB befinden mögen, hat sie dennoch einen sehr hohen Durchsatz. Zudem wird die TempDB bei jedem Server Neustart wieder mit dem Startwert neu erzeugt, daher ist es nicht immer klar ob sie nicht doch mal zwischendurch gewachsen ist.

    Du solltest auf jeden Fall weitere Dateien der TempDB hinzufügen. Hier wäre die Empfehlung dass 8 Datendateien hast.

    https://www.youtube.com/watch?v=MMZAZet64TU&list=PL3L6oZlv02ROjHnWCLgPb4G1C3kWvAxOJ&t=0s&index=38

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012



    Mittwoch, 4. Juli 2018 17:47
    |
  • Question
    Anmelden
    0
    Anmelden

    "Die TempDB wird so ziemlich bei allen komplexeren Operationen des SQL Server verwendet"

    Wenn ich also nur einfache Select/Update/Insert/Deletes und keine Trigger verwende beleibt es ja bei einfachen Operationen und somit zu einer nur geringfügigen Belastung der tempdb.

    Feststellbar ist das aber nur bei einer eingängigen Performanceanalyse.
    https://www.mssqltips.com/sqlservertip/4356/track-sql-server-tempdb-space-usage/
    https://blog.sqlauthority.com/2015/01/23/sql-server-who-is-consuming-my-tempdb-now/

    Hier ist dann wesentlich die Satzversionierung (Transaktionstyp bzw. After-Trigger mit Updates) und Sortierung (wenn kein Index vorhanden) betroffen.

    Donnerstag, 5. Juli 2018 09:18
    |
  • Question
    Anmelden
    2
    Anmelden

    ...

    Wenn ich also nur einfache Select/Update/Insert/Deletes und keine Trigger verwende beleibt es ja bei einfachen Operationen und somit zu einer nur geringfügigen Belastung der tempdb.

    ...

    Ja, wenn man "einfache" Operationen ausführt, hat man "einfache Operationen". Das ist ein Pleonasmus, wenn ich mich nicht irre :-D

    Aber mal zurück zur Realität: Selects sind ja nicht immer "trivial" - und vielleicht dennoch "einfach". Sobald Joins, Filter oder Gruppierungen ins Spiel kommen, wird schnell etwas in Tempdb augelagert .Und das ist es sicherlich, worauf Benjamin hinauswollte. 200 MB klingen tatsächlich etwas wenig.

    H.Picht sollte bitte mal die eventuellen Neustarts im Blick haben ob nicht doch bereit vergrößert wurde, und gern auch die oben aufgeführten DMVs abfragen, was diese zur Tempdb Nutzung sagen. - Wobei ich mir davon wenig verspreche: den die DMVs werden genau das anzeigen, was aktuell benötigt wird: eben die 200MB ggfls. Das wird also nicht weiterführen.

    Die eigentliche Frage ist ja, ob MEHR Platz benötigt wird. Und da müsste es entsprechende Fehler in den Abfragen geben.

    Hilfreich wäre sicher auch mal ein Hinweis zur genauen Konfiguration. V.a. folgende Punkte:

    • Tempdb-Dateieinstellungen
    • CPU und Einstellungen dazu
    • und gern auch mal Wait-Stats

    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)

    Donnerstag, 5. Juli 2018 09:42
    |
  • Question
    Anmelden
    3
    Anmelden

    Hallo Baldur,

    das Problem mit TEMPDB hat mit der Anzahl der erstellten Objekte in TEMPDB und der Frequenz der Erstellung der Objekte zu tun. Wenn z. B. nur ein einziger Prozess seriell auf TEMPDB zugreift, ist IMHO kein nennenswerter Impact erkennbar.

    Sind es aber sehr viele gleichzeitige Zugriffe, dann kann es sehrwohl zu einem nicht unerheblichen Impact kommen. Das Problem nennt sich "Latch Contention" und betrifft vor allen Dingen die System-Datenseiten (PFS und GAM).

    PFS steht für Page Free Space. Ein PFS-Intervall beträgt 8088 Seiten oder 64 MB. Eine PFS-Seite hat keine Bitmap - sie verfügt über eine Byte-Map mit einem Byte für jede Seite im PFS-Intervall. PFS trackt den Füllgrad einer Seite für Heaps / images / text und kann - bei ungeeigneter Datenstruktur - extrem beansprucht werden.

    Der Füllgrad wird nur in % gemessen und kann 5 Zustände haben

    0%, 50%, 80%, 95%, 100%

    Wenn nun mehrere Prozesse gleichzeitig neue Objekte anlegen (egal ob manuelle temporäre Tabellen, Trigger, tablellenvariablen, ...) oder aber systembedingte Objekte angelegt werden (z. B. Table Spool, Sort Spill, ...), immer muss der Weg über die PFS gehen!

    Ich erkläre das in meinen Workshops immer mit einem Einwohnermeldeamt. Wenn nur 10 - 20 Leute in die Stadt ziehen, kann man das recht einfach über einen Schreibtisch laufen lassen; was ist aber, wenn es 200 - ... Leute sind. Der Behördenleiter stellt mehr Schreibtische auf, damit sich die Leute besser verteilen.

    Und genau das ist der Sinn und Zweck der Aufteilung von TEMPDB auf mehrere Files. Einen Schreib- oder Lesevorteil gibt es nicht, wenn - wie empfohlen - die Datendateien und die Protokolldatei auf einem Laufwerk sind.

    Hier noch ein paar interessante Links für das Verständnis für die Storage Engine

    https://www.sqlskills.com/blogs/paul/inside-the-storage-engine-gam-sgam-pfs-and-other-allocation-maps/

    http://db-berater.blogspot.com/2013/10/neue-daten-in-einen-heap-eintragen.html

    (zwar schon älter - wird aber baldigst in meinen neuen Blog überführt :) )

    http://sqlsoldier.net/wp/sqlserver/breakingdowntempdbcontention

    https://www.sqlskills.com/blogs/paul/the-accidental-dba-day-27-of-30-troubleshooting-tempdb-contention/

    Sehr interessanter Artikel. Insbesondere der Hinweis auf TF 1118 ist für SQL Server <= 2014 erwähnenswert, da bei Aktivierung die SGAM-Seite(n) nicht mehr beschrieben werden (die genauere Erläuterung zu den Systemseiten findest Du in Link 1).

    Insgesamt ein sehr komplexes Thema und für Navision würde ich grundsätzlich empfehlen, die Anzahl von 8 Files (sofern >= 8 Cores vorhanden) vollständig auszureizen.

    Zusammenfassung

    Es ist nicht unbedingt wichtig, wie hoch die zu schreibende Datenmenge ist - vielmehr ist zu berücksichtigen, wie viele Schreibprozesse parallel auf TEMPDB zugreifen!

    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Donnerstag, 5. Juli 2018 11:02
    |
  • Question
    Anmelden
    0
    Anmelden
    Nun, bei 30 Usern erwarte ich da keine hohe Transaktionslast die zu konkurierenden Updates mit Wartezeiten/Konkurenzsituationen auf TempDB führen sondern eher, wie eingangs schon gesagt, eher fehlende Indizes, ungünstige SQL's und daraus resultierende Tablescans, die bei 44GB durchaus schon mal wehtun.
    Freitag, 6. Juli 2018 22:28
    |
  • Question
    Anmelden
    1
    Anmelden

    Deine Einschätzung ist durchaus plausibel. Lieder wird es kaum möglich sein ein vernünftiges Index Design über ein Forum zu erzeugen. Die negativen Folgen bei einem schlechten Index (unnötiger, doppelter,... Index) sind deutlich größer was Last und Plattenplatz angeht, als bei der TempDB mal ein paar Files hinzufügen.

    Wenn ich die Anzahl der Datafiles der TempDB auf 8 erhöhe habe ich einen minimalen Arbeitsaufwand und einen zusätzlichen Plattenbedarf von 1,4 GB auf der Platte. Beides sind für mich akzeptable Auswirkungen selbst wenn es keinen nennenswerten Leistungsvorteil bringt. Und da selbst Microsoft inzwischen bei der Installationen eines SQL Servers automatisch weitere TempDB Files anlegt setzt man ja nur eine Best Practice Empfehlung um.

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Samstag, 7. Juli 2018 07:01
    |
  • Question
    Anmelden
    1
    Anmelden
    Nun, bei 30 Usern erwarte ich da keine hohe Transaktionslast die zu konkurierenden Updates mit Wartezeiten/Konkurenzsituationen auf TempDB führen sondern eher, wie eingangs schon gesagt, eher fehlende Indizes, ungünstige SQL's und daraus resultierende Tablescans, die bei 44GB durchaus schon mal wehtun.

    30 User können - abhängig von der Applikation - sehr wohl ein extremes Transaktionsverhalten darstellen. Beispiel wäre zum Beispiel die Standortbestimmung eines Skit in einem Automobilwerk, in dem ca. 200 solcher Skits permanent ihren Standort (Montageeinheit) in eine Datenbank schreiben und bei Austritt den Status ändern/löschen.

    Fehlende Indexe führen in der Regel nur dann zu einer Verwendung von TEMPDB, wenn

    - ein Tablespool verwendet wird

    - eine Sort/Hash-Operation mit falschen Statistiken arbeitet (Spill to TEMPDB)

    Wie ein Tablescan TEMPDB belasten soll, erschließt sich mir nicht. Ist ein typischer Datastream, der KEINE TempDB benötigt.

    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Montag, 9. Juli 2018 19:42
    |
  • Question
    Anmelden
    0
    Anmelden

    Genau das habe ich ja auch behauptet, dass die TempDB hier eigentlich fast keine Rollex spielt;-).

    Und bei Usern bin ich nun nicht von Maschinen ausgegangen. Sicher kann ich beim Sammeln von Messergebnissen, Taktraten, Stückzahlmeldungen usw. entsprechend hohe Transaktionsraten erreichen.
    Aber damit sind ja dann eher Geräte als User gemeint.
    Auch meine BI-Anwendung kann im Dashboard durchaus 30-40 Abfragen (oder auch schon mal mehr) parallel auf eine Datenbank losjagen, aber das sind nur Abfagen und sortiert wird in der Anwendung. Außerdem sind das nur kurzfristige Belastungen (selten mehr als 1 Minute).
    Allenfalls Group By könnte hier über TempDB laufen, falls der Hauptspeicher da nicht ausreichen sollte.

    Es gab auch schon mal User, die sich (was bei BI schon mal passiert), einen Cross-Join generert haben. Aber so was wird nach ein bisschen Wartezeit dann gecancelt.

    Wir können hier noch sicherlich viel weiter spekulieren, an einer Performancemessung/-analyse kommt man bei sowas kaum vorbei.

    Montag, 9. Juli 2018 20:22
    |