none
Suche nach Hilfe von SQL-Server-Experten: tempdb waechst sehr schnell RRS feed

  • Frage

  • Hallo zusammen,

    ich hoffe, dass ich hier richtig bin. Ich bin auf der Suche nach einem MS SQL Server - Spezialist, der mir bei Fragen ueber einem Datenbank-Issue helfen kann.

    Es geht um eine sogenannte tempdb, die sehr schnell waechst. In sehr wenig Zeit hat sie sich gefuellt (57 GB gross und alle belegt). Die Maschine, wo sich diese tempdb befindet, wurde dann durchgestartet, aber das alleine hat keine Loesung gebracht. Einmal wird die Groesse reduziert und dann waechst diese ganz schnell, bis sie wieder ihre maximale Groesse erreicht hat.

    In sich geht es um unseren Kunden, der sich keine richtigen DB-Administratoren leisten kann und uns diese Aufgabe gegeben hat. Ich selbst bin kein MS-SQL Server-Expert.

    Kann mir bitte jemand helfen?. Es waere sehr nett, da diese Aufgabe zu loesen, ist sehr dringend.

    Ich hoffe, da meldet sisch jemand, der sich mit diesem Thema auskennt.
    Freitag, 1. Mai 2015 04:30

Alle Antworten

  • Hallo

    also an sich ist das Wachstum der Tempdb ja nichts Schlechtes. Sie wird halt benötigt. Und wenn Sie so viel Platz benötigt, dann sollte man sie einem manuell auf diese Größe einstellen, damit Sie nicht erst während der Abfragen wachsen muss.

    Wenn Du aber der Ansicht bist, diese 57 GB stehen in so gar keinem Verhältnis zu den auf dem System eingerichteten Datenbanken und ausgeführten Abfragen, und/oder ein Performance-Problem besteht, dann müsste man einmal herausfinden, welche Sitzungen und damit dann Abfragen genau die TempDB beanspruchen, um diese Abfragen dann ev. besser zu schreiben oder mit besseren Indexen zu hinterlegen.

    Auf diesem Blog-Post findest Du einen Script, mit dem man die sessions ermitteln kann: TempDB usage per active session


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Freitag, 1. Mai 2015 09:09
  • Hallo Mayrapper,

    ich habe in Bezug auf den MS SQL-Server auch nur Grundkenntnisse, als bitte nicht alles auf die Goldwaage legen, wenn ich mal etwas daneben liege, aber ich versuche dir mal zu helfen.

    Die Datenbank tempdb gehört zu den Systemdatenbanken des MS SQL und speichert normalerweise nur temporäre Tabellen. Wenn diese DB nun unerwartet schnell anwächst würde ich als erstes mal die Eigenschaften der DB anschauen. Dazu im MS SQL Management Studio unter Datenbanken, Systemdatenbanken die DB tempdb suchen und mit einem Rechtsklick darauf die Eigenschaften öffnen. Unter Optionen mal nachscheuen, ob das Wiederherstellungsmodel auf Einfach steht, das wäre nämlich der Standard. Sollte die  nicht der Fall sein, könnte dies bereits dein Problem sein, da dann die ganzen Änderungen in der DB gespeichert werden, bis ein Backup erstellt wird und die Transaktionen (LOG-File) abgeschnitten werden.

    Sollte das dein Problem nicht schon lösen, stellt sich für mich die Frage, weshalb auf dem Server anscheinend so viele Temp-Tabellen erstellt werden, dass deine DB so schnell wächst. Gibt es womöglich eine neue Anwendung die Amok läuft ...? Das müsste man dann wohl genauer hinterfragen und auch wissen, was auf dem SQL sonst noch so los ist.

    Gruß
    Steffen

    Freitag, 1. Mai 2015 09:21
  • ... Unter Optionen mal nachscheuen, ob das Wiederherstellungsmodel auf Einfach steht, das wäre nämlich der Standard. Sollte die  nicht der Fall sein, könnte dies bereits dein Problem sein, da dann die ganzen Änderungen in der DB gespeichert werden, bis ein Backup erstellt wird und die Transaktionen (LOG-File) abgeschnitten werden....

    zum Glück ist die TempDB vor derartigen Fehlkonfigurationen geschützt: Ihr Recovery-Modell lässt sich nicht ändern :-)

    bleibt also die Suche nach den Sessions, die den Platz beanspruchen.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Freitag, 1. Mai 2015 10:24
  • Hallo Andreas, danke fuer deine Antwort.

    du schreibst, das Wachstum der tempdb ist in sich nicht schlecht. Das Problem ist dass mit dem Wachstum der tempdb der .Laufwerk C gefuellt (schoen full) wird. Es handelt sich um eine virtuelle Maschine, wo sich die tempdb befindet.

    Die tempdb waechst exponentiell und sehr rasch. In 2 Tagen ist diese beispielsweise von 5 MB bis die maximale Groesse gewachsen. Damit das Problem irgendwie und nur temporaer geloest werden kann, muss der Server durchgestartet werden, aber das ist staendig keine gute Loesung. Unser Kunde braucht der Server, der liegt in der Produktionsplattform.

    Wir arbeiten mit der Technologie Siebel CRM und ab und zu laufen queries in der SQL Server - DB.

    Was wuerdest du mir empfehlen, damit ich die Sitzungen oder Abfragen herausfinden kann, die genau die TempDB beanspruchen? Womit oder wie kann ich das analysieren?. Noch weitere Fragen:

    - Was beinhaltet diese TempDB? nur Abfragen?

    - Sollte ich die Sitzungen herausgefunden haben, welche Massnahmen sind da zu ergreifen? ich bin leider kein DB-Administrator :(.

    - Ich habe irgendwo gelesen, dass ein "shrinking" der TEMPDB nicht empfehlbar ist.

    Mir fallen gerade keine weitere Fragen ein. Mit Sicherheit werde ich noch weitere haben. Es wuerde mir helfen, immer wieder hier Unterstuetzung zu haben.


    Freitag, 1. Mai 2015 17:23
  •  Danke S. Meyer. Wenn die TEMPDB nur temporaere Tabellen speichert, warum waechst diese staendig und rasch nun? ich meine damit, irgendwann muessen die Daten drin woandershin gehen, es handelt sich ja um eine temporaere DB, wo ich denke, die Daten nur zwischengespeichert werden.

    Freitag, 1. Mai 2015 17:40
  • Da faellt mir noch was ein: wo kann ich mir die Logs der SQL Server - DB anschauen?. Irgendwo muessen ja auch Infos ueber die SQL Server Sitzungen (und somit der TEMPDB) protokolliert werden, richtig?.

    Viele Gruesse

    Freitag, 1. Mai 2015 17:47
  • Wenn es sich um ein produktives System handelt, dann hat die TempDB nichts auf C verloren. Ein Grund dafür ist genau das Problem, was Ihr da jetzt habt. Neustarts sind in der Tat keine Lösung. Das ist ja nichts anderes als sämtliche offenen Sitzungen zu killen. - Shrinken würde Nichts bringen, während sie gerade wächst. Und im Anschluss auch nicht, weil sie ja WIEDER wachsen wird. Das ist also vertane Zeit und geht nur zu Lasten der Performance.
    Ich kann nur dringend nahelegen, das gesamte Konzept einmal zu prüfen und überdenken.

    Je nachdem was für eine Performance und Verfügbarkeit man von dem System erwartet, muss man dann eben auch das System auslegen. Mit entsprechender Redundanz und mindestens einer Trennung von Betriebssystem und Datenbanken. Wahrscheinlich aber noch viel mehr.

    Was in der Tempdb alles gespeichert wird sind neben temporären Tabellen auch sämtliche Zischenergebnisse aka Worktables von Abfragen, Snapshots von Datensätzen, die durch Trigger erzeugt werden und noch einiges mehr. Hier kann man dazu Weiterlesen: https://msdn.microsoft.com/de-de/library/ms190768.aspx

    Die Abfragen, die die Tempdb verwenden, findest Du mit dem oben verlinkten Script heraus. Einfach mal im laufenden Betrieb ausführen, wenn Wachstum auftritt.

    Das ErrorLog des SQL Server (hier zu finden: https://technet.microsoft.com/de-de/library/ms187885%28v=sql.105%29.aspx) enthält keine Informationen zu Tempdb Wachsum. Die Default Trace protokolliert Dateierweiterungen. Aber das hilft eher wenig. Sich mit den im Management Studo integrierten Berichten vertraut zu machen, kann aber nie schaden - diese zeigen die Daten aus der Default Trace an.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Freitag, 1. Mai 2015 21:42
  • Ich kann nur dringend nahelegen, das gesamte Konzept einmal zu prüfen und überdenken.

    Was meinst du mit dem gesamten Konzept?.

    Danke uebrigens fuer die Link. Mir geht es aber auch darum zu wissen, was ich mit den herausgefundenen Sessions machen soll. Killen? geht das?. Du schreibst (und so habe ich verstanden) Neustarts sind nichts Anderes als die ganzen Sessions zu killen. Meinst du damit auch diejenigen, die die TEMPDB schnell wachsen lassen?.

    Sich mit den im Management Studo integrierten Berichten vertraut zu machen, kann aber nie schaden - diese zeigen die Daten aus der Default Trace an.

    Welche Berichte ganau? und was kann ich damit anfangen?. Da ich newbie in diesem Thema bin, wuerde mich interessieren was du damit meinst. Was ist Default Trace?.

    Samstag, 2. Mai 2015 00:23
  • Hallo,

    um Dein Grundlagen-Wissen zu erweitern, schau Dir bitte mal an:

    Working with tempdb in SQL Server 2005 (gilt im Kern auch für neuere Versionen) Die Ratschläge dort bezüglich der Konfiguration solltest Du beachten.

    Was die Sitzungen angeht: "Killen" sollte man erst mal gar nichts, sondern die Gründe herausfinden. Die intensive Nutzung von tempdb ist zunächst nichts weiter als ein Symptom. Zum einen:

    Werden Sitzungen beendet oder bleiben sie "endlos" offen, d. h. verwaisen sie? Wenn Sitzungen dauerhaft offen bleiben, könnte es auf Probleme der Software hinweisen.

    Welchen Typs sind die Abfragen die intensiv tempdb nutzen? Sind es Standard-Abfragen des CRM, kundenspezifische oder gar Ad-Hoc Abfragen? Wenn die letzteren so können zusätzliche Indizes die tempdb Nutzung verringern. Sind es Abfragen der Standard-Software sollte man den Hersteller (Oracle/Siebel) kontaktieren.

    Gruß Elmar

    Samstag, 2. Mai 2015 06:39
  • Ich kann nur dringend nahelegen, das gesamte Konzept einmal zu prüfen und überdenken.

    Was meinst du mit dem gesamten Konzept?.

    ...

    Ich meine damit den Aufbau des Servers, der im Allgemeinen einem Konzept folgt. Möglicherweise gibt es hier nichtmal ein Konzept. Eine TempDB auf C:\ ist zumindest ein Indikator für das Fehlen eines Datenbankadministrators. Und das kommt häufig im Zusammenhang mit "mal eben so mit installierten SQL Servern".

    Sofern es sich aber um ein wichtiges System handelt, welches Umsätze, Nachweisbarkeit oder Kundenzufriedenheit sicherstellt, sollte man da etwas mehr Mühe investieren, um, wie ich oben bereits schrieb, die benötigte Leistung und Verfügbarkeit sicherzustellen, sowie natürlich auch, ein Notfall-Konzept "was tun, wenn der Server einmal komplett ausfällt". Vielleicht gibt es das ja alles schon - das würde ich an Deiner Stelle mal prüfen, da so ein Vollaufen von C: wegen der tempdb eben schon ein erster fachlicher Schnitzer ist.

    Die Berichte findet man per Rechtsklick auf verschiedenen Knoten im Management Studio Objekt-Explorer.

    Ich kann hier leider keine Buchempfehlung für Einsteigerbücher abgeben, da mir keine geläufig sind. Aber sicherlich findet sich bei Amazon etwas, was für den Ersten Start hilft.

    Gutes Gelingen

    Andreas


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    • Als Antwort vorgeschlagen Benjamin.Hoch Freitag, 11. März 2016 08:55
    Samstag, 2. Mai 2015 08:17
  • Hallo

    Ich kann dir das Buch Microsoft SQL Server 2012 - Ratgeber für Administratoren empfehlen. Es hat mir am Anfang sehr gut geholfen.

    Wenn es sich um eine virtuelle Maschine handelt würde ich mir schnell zusätzliche Platten geben lassen und alle Datenbanken auf separate Platten umziehen. Bis der Fehler gefunden ist sollte die tempDB unbedingt auf eine eigene Platte kommen (schadet auch sonst nicht).

    Gruß

    Benjamin Hoch

    MCSA: Microsoft Certified Solutions Associate - SQL Server 2012,

    MCSA: Microsoft Certified Solutions Associate - Windows Server 2012,

    • Als Antwort vorgeschlagen Benjamin.Hoch Freitag, 11. März 2016 08:55
    Sonntag, 3. Mai 2015 19:43
  • Selbst wenn die 57 GB in der tempdb nur vorübergehend benötigt werden, wird das File auf Platte C nicht kleiner, wenn die tempdb wieder leer ist. Also reicht eine schlechte Aktion aus, um den Platz bis zum nächsten Serverneustart zu reservieren.

    Eine Ursache für die Füllung der tempdb könnten auch fehlende Indizes sein.
    Wie Du die tempdb verschieben kannst, ist hier beschrieben:
    https://msdn.microsoft.com/de-de/library/ms345408.aspx?f=255&MSPPError=-2147217396

    HTH!

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    • Als Antwort vorgeschlagen Benjamin.Hoch Freitag, 11. März 2016 08:55
    Montag, 4. Mai 2015 06:48
    Beantworter