none
wie geht das mit dem Loggen? RRS feed

  • Frage

  • Wie ist das, wenn ich z.B. ein INSERT/UPDATE ausführe mit dem Loggen eigentlich? Kann man sagen, dass die Aktion auf der Disk gelandet ist, wenn ich vom Server eine Antwort bekomme oder kann es sein, dass das Log auch verzögert geschrieben wird (von mir aus ein paar Millisekunden oder so) ... die Frage kam daher auf, weil ich das mal ausgemessen habe. Im Durchschnitt kam er mir nach 1.59 [ms] zurück und ich hab mich gefragt, ob die Festplatte auf dem Test-Computer überhaupt so schnell ist. Ausserdem hatte ich keine 100% Aktivität erkennen können auf der Disk (natürlich hab ich noch gelesen, das könnte der Grund sein) ... aber so richtig habe ich auch keine Dokumentation finden können, die mir bestätigt, dass der Server ein OK von der Disk hat, wenn er mir die Antwort vom INSERT/UPDATE zurückgibt...

    Wär schön, wenn jemand mehr Informationen dazu hat.

    Sonntag, 14. Dezember 2014 15:26

Antworten

  • Hallo Rudolf,
    schau Dir mal diesen Artikel an, da wird es recht gut erklärt:
    http://technet.microsoft.com/en-us/library/ms186259(v=sql.105).aspx
    Write-Ahead Transaction Log

    Am Ende wird auch noch mal darauf hingewiesen, dass die verwendete Hardware dabei nicht außer Betracht gelassen werden kann. Falls diese also sagt: Daten sind auf Disk, sie sich aber eigentlich noch in einem Puffer befinden, könnten sie bei einem unerwarteten Neustart verloren gehen. Batteriegepufferte Caches reduzieren diese Fehler.

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

    Montag, 15. Dezember 2014 09:25
  • Wie alt diese Berichte sind ist fraglich... das sind halt so Anekdoten von Informatik-Supporter :-) um's mal so zu nennen. Ich selber reg mich nur jeweils über Dinge wie den WSUS auf, der intern den SQL mit JOINs in Timeouts treibt und so. Das hat aber mit dem Thema nichts zu tun.

    Aber zurück zum Thema. Ich denke diese zwei Links sind die interessantesten:

    http://technet.microsoft.com/en-us/library/cc966500.aspx

    http://technet.microsoft.com/library/Cc917726

    Ausserdem habe ich untersucht (ProcMon) mit welchen Flags der SQL 2008 R2 (wird bei anderen gleich sein) die Logdatei öffnet. Und das ist tatsächlich mit WriteThrough und NoBuffering. Ausserdem wird beschrieben, dass die Antwort abgewartet wird. Und dass sie 512er Blöcke nutzen mit WriteFile (nicht WriteFileGather für Logs). Das ist recht interessant. Hab's noch nicht ganz durchgelesen, aber ich muss wohl morgen mal einen Test machen um WriteFile mit 512er Blöcken mit einem WriteFileGather mit 4kB Blöcken zu vergleichen... und dann entscheiden, was wir in Zukunft in unserer Software nutzen werden. Wird sicher noch ein paar Diskussionen geben... da geht's dann wieder um die Frage "was ist wichtiger? Durchsatz oder Einzeloperation-Latenz?"

    Danke für die Antworten.

    Montag, 15. Dezember 2014 19:56

Alle Antworten

  • Hallo.

    Erst einmal ist das wohl Normal, dass du keine 100% Auslastung des Laufwerks erkennst. Egal ob Normales Magnetlaufwerk oder diese neuen Laufwerk (SSD).

    Zum zweiten ist ist es doch so, dass Schreibvorgänge vor der wirklichen Ausführen als Transaktion protokolliert werden (siehe Wikipedia). D.H., dass nur die Information gespeichert werden muss, quasi als "Notiz"; deshalb kann ich mir schon vorstellen, dass es kein Problem sein sollte, vor allem, da MS SQL Server sehr ausfallsicher ist und damit wohl nicht Daten irgendwie nur Flüchtig behaltet (Außer du hast In-Memory Funktionen aktiv).


    (C) 2014 Thomas Roskop

    Sonntag, 14. Dezember 2014 16:06
  • Erst einmal ist das wohl Normal, dass du keine 100% Auslastung des Laufwerks erkennst. Egal ob Normales Magnetlaufwerk oder diese neuen Laufwerk (SSD).

    Zum zweiten ist ist es doch so, dass Schreibvorgänge vor der wirklichen Ausführen als Transaktion protokolliert werden (siehe Wikipedia). D.H., dass nur die Information gespeichert werden muss, quasi als "Notiz"; deshalb kann ich mir schon vorstellen, dass es kein Problem sein sollte, vor allem, da MS SQL Server sehr ausfallsicher ist und damit wohl nicht Daten irgendwie nur Flüchtig behaltet (Außer du hast In-Memory Funktionen aktiv).

    Hallo...

    Also, doch, das mit der vollen Auslastung krieg ich hin. Ist nicht mal so schwer. Und ich hab auch Programme (selber geschrieben), die das hinbekommen. Das ist bei denen der bremsende Faktor (natürlich, evtl. ist die Zugriffsstrategie etwas ungünstig, das versuche ich gerade rauszufinden) ... und da wird pro 3-5 [ms] ein Job verarbeitet. Das ist aber aktuell auch nicht die Frage... das find ich schon noch raus.

    Das mit dem Protokollieren ist mir klar. Jedoch kenne ich genügend Berichte, dass ein SQL nach dem Ausfall (wie der auch immer aussieht... also z.B. durch Prozess abschiessen oder Stromausfall) nicht mehr hochfahren und auch das Recovery ziemlich versemmeln... das, gepaart mit den doch recht schnellen Zugriffszeiten beim Schreiben und den teilweise doppelt so hohen Zugriffszeiten beim Lesen (da kann er nicht schummeln, weil er die Daten braucht), lässt das ganze zwar noch immer plausibel aussehen, aber ich dachte, ich frag doch lieber mal nach, ob die z.B. ... was weiss ich... eine Verzögerung von 10 [ms] drin haben oder mit dem Runterschreiben beginnen, wenn sie melden, dass die Transaktion fertig ist oder so (also z.B. -> sobald es der Disk übergeben wurde, wird das ok gemeldet... könne ja sein) ... wär zwar für mich nicht ganz sauber, aber ... wär auch nicht völlig aus der Luft gegriffen sowas anzunehmen.

    Sonntag, 14. Dezember 2014 17:44
  • Hallo.

    Wenn du es unbedingt wissen willst, dann würde ich dir Empfehlen der Datenbanksoftware mal auf den Zahn zu fühlen. Nimm ein Programm, welches alle Aktionen überwachen kann (Zum Beispiel den Procmon von SysInternals), und beobachte den Server bei der Arbeit. Evtl. kannst du von der Datenbank vor und nach der Aktion einen Schnappschuss anfertigen. Also vorher die Datei kopieren, dann den Befehl ausführen, dann die Datenbank per Taktmanager stoppen (Bitte nicht bei Produktivsystemen, nimm eine Testumgebung!!!) und vergleiche, ob die Änderungen geschrieben wurden (in der Datei sind).

    Wenn du was raus hast, dann melde dich doch, wäre wohl für viele andere auch sehr interessant.


    (C) 2014 Thomas Roskop

    Sonntag, 14. Dezember 2014 17:56
  • Hallo Rudolf,

    der SQL Server schreibt die Daten nicht sofort auf die Disk, das macht der Lazy Writer, der regelmäßig "dirty pages" (= geänderte Datenseiten) weg schreibt, siehe Writing Pages . Das kann man auch mit dem CHECKPOINT (Transact-SQL) Befehl forcieren.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Montag, 15. Dezember 2014 08:13
  • Hallo Rudolf,
    schau Dir mal diesen Artikel an, da wird es recht gut erklärt:
    http://technet.microsoft.com/en-us/library/ms186259(v=sql.105).aspx
    Write-Ahead Transaction Log

    Am Ende wird auch noch mal darauf hingewiesen, dass die verwendete Hardware dabei nicht außer Betracht gelassen werden kann. Falls diese also sagt: Daten sind auf Disk, sie sich aber eigentlich noch in einem Puffer befinden, könnten sie bei einem unerwarteten Neustart verloren gehen. Batteriegepufferte Caches reduzieren diese Fehler.

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

    Montag, 15. Dezember 2014 09:25
  • Hier habe ich noch was gefunden:
    https://support.microsoft.com/kb/234656/en-us
    Description of using disk drive caches with SQL Server that every database administrator should know

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

    Montag, 15. Dezember 2014 10:32
  • ... Jedoch kenne ich genügend Berichte, dass ein SQL nach dem Ausfall (wie der auch immer aussieht... also z.B. durch Prozess abschiessen oder Stromausfall) nicht mehr hochfahren und auch das Recovery ziemlich versemmeln...

    Was sind denn das für Berichte?

    In SQL Server hat es schon seit vielen vielen Versionen keine Probleme dieser Art mehr gegeben. Wenn dann muss das von vor SQL Server 4.0 stammen, wo teilweise noch andere Techniken zum Einsatz kamen.

    Spätestens seitdem jedoch ist das von Christoph verwiesene WAL-Protokoll im Einsatz, welches für das D in ACID sorgt. Sprich: wenn das Commit zurückkommt, kann man davon ausgehen, dass die Daten im Log protokolliert worden sind. Caches, die nicht durch Batterien gebacked sind, sind für den Einsatz für SQL Server nicht freigegeben. Wer solche dennoch einsetzt, handelt auf eigene Gefahr. Da kann dann der SQL Server nichts für.

    Das Logging hat mit dem Checkpoint und dem Schreiben der Data-Pages erstmal Nichts zu tun. Dieses passiert aus Performancegründen in der Tat verzögert.


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

    Montag, 15. Dezember 2014 11:10
  • Wie alt diese Berichte sind ist fraglich... das sind halt so Anekdoten von Informatik-Supporter :-) um's mal so zu nennen. Ich selber reg mich nur jeweils über Dinge wie den WSUS auf, der intern den SQL mit JOINs in Timeouts treibt und so. Das hat aber mit dem Thema nichts zu tun.

    Aber zurück zum Thema. Ich denke diese zwei Links sind die interessantesten:

    http://technet.microsoft.com/en-us/library/cc966500.aspx

    http://technet.microsoft.com/library/Cc917726

    Ausserdem habe ich untersucht (ProcMon) mit welchen Flags der SQL 2008 R2 (wird bei anderen gleich sein) die Logdatei öffnet. Und das ist tatsächlich mit WriteThrough und NoBuffering. Ausserdem wird beschrieben, dass die Antwort abgewartet wird. Und dass sie 512er Blöcke nutzen mit WriteFile (nicht WriteFileGather für Logs). Das ist recht interessant. Hab's noch nicht ganz durchgelesen, aber ich muss wohl morgen mal einen Test machen um WriteFile mit 512er Blöcken mit einem WriteFileGather mit 4kB Blöcken zu vergleichen... und dann entscheiden, was wir in Zukunft in unserer Software nutzen werden. Wird sicher noch ein paar Diskussionen geben... da geht's dann wieder um die Frage "was ist wichtiger? Durchsatz oder Einzeloperation-Latenz?"

    Danke für die Antworten.

    Montag, 15. Dezember 2014 19:56