9
SQL Datenbank zu 99 Prozent fragmentiert
Hallo zusammen,
ich habe folgende Konstellation. Aktuell läuft die Datenbank auf einem SQL Server 2000.
Ziel ist es die Datenbank auf einem SQL Server 2008 zum Laufen zu bringen und das performant.
Mein Problem:
Nach dem Übertragen/Wiederherstellen der DB auf dem neuen Server ist die Performance nicht spürbar besser.
Die Ausgabe des Befehls "dbcc showcontig" zeigt deutlich, dass die Datenbank sehr stark fragmentiert sind.
Hier ein Auszug einer Tabelle zu dem Befehl:
Die TABLE-Ebene wurde gescannt.
- Gescannte Seiten 3269
- Gescannte Blöcke 411
- Blockwechsel 410
- Seiten pro Block 8.0
- Scandichte [Beste Wert:Tatsächlicher Wert] 99.51% [409:411]
- Blockscanfragmentierung 99.76%
- Bytes frei pro Seite (Durchschnitt) 359.2
- Mittlere Seitendichte (voll) 95.56%
Folgende Punkte wurde zur Performancesteigerung schon umgesetzt:
- Die NTFS Blockgröße ist auf 64kB formatiert, so wie es von MS empfohlen wird
- Die MDF und die LDFs liegen auf einer separaten Festplatte
- Reindex brachte keinen erfolg. Defragmentierung der Indizes auch nicht.
Microsoft schreibt zu der Blockscanfragmentierung, dass der Wert zwischen 0 und 10 % akzeptabel ist. (Bei mir 99.76%)
Deshalb denke ich, dass dies mein größtes Problem ist!
Hat jemand eine Idee wie ich die Blockscanfragmentierung in Richtung 0 % verbessern kann?
Besten Dank!
ich habe folgende Konstellation. Aktuell läuft die Datenbank auf einem SQL Server 2000.
Ziel ist es die Datenbank auf einem SQL Server 2008 zum Laufen zu bringen und das performant.
Mein Problem:
Nach dem Übertragen/Wiederherstellen der DB auf dem neuen Server ist die Performance nicht spürbar besser.
Die Ausgabe des Befehls "dbcc showcontig" zeigt deutlich, dass die Datenbank sehr stark fragmentiert sind.
Hier ein Auszug einer Tabelle zu dem Befehl:
Die TABLE-Ebene wurde gescannt.
- Gescannte Seiten 3269
- Gescannte Blöcke 411
- Blockwechsel 410
- Seiten pro Block 8.0
- Scandichte [Beste Wert:Tatsächlicher Wert] 99.51% [409:411]
- Blockscanfragmentierung 99.76%
- Bytes frei pro Seite (Durchschnitt) 359.2
- Mittlere Seitendichte (voll) 95.56%
Folgende Punkte wurde zur Performancesteigerung schon umgesetzt:
- Die NTFS Blockgröße ist auf 64kB formatiert, so wie es von MS empfohlen wird
- Die MDF und die LDFs liegen auf einer separaten Festplatte
- Reindex brachte keinen erfolg. Defragmentierung der Indizes auch nicht.
Microsoft schreibt zu der Blockscanfragmentierung, dass der Wert zwischen 0 und 10 % akzeptabel ist. (Bei mir 99.76%)
Deshalb denke ich, dass dies mein größtes Problem ist!
Hat jemand eine Idee wie ich die Blockscanfragmentierung in Richtung 0 % verbessern kann?
Besten Dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 161394
Url: https://administrator.de/forum/sql-datenbank-zu-99-prozent-fragmentiert-161394.html
Ausgedruckt am: 24.12.2024 um 13:12 Uhr
9 Kommentare
Neuester Kommentar
Hallo @V-FSI09,
Hast du schonmal die Datenbankfunktion VACUUM ausprobiert? Diese Defragmentieren deine Datenbank normalerweise. Ist auch stark spürbar, wenn der Firefox mal wieder langsam wird. Nachdem ein VACUUM auf die Userdatenbanken (History, Favoriten) losgelassen wurde, rennt er wieder
Gruß
Snow
Hast du schonmal die Datenbankfunktion VACUUM ausprobiert? Diese Defragmentieren deine Datenbank normalerweise. Ist auch stark spürbar, wenn der Firefox mal wieder langsam wird. Nachdem ein VACUUM auf die Userdatenbanken (History, Favoriten) losgelassen wurde, rennt er wieder
Gruß
Snow
Hallo Snow,
kann leider so eine Funktion für den MS SQL Server nicht finden.
Gruß
V-FSI09
kann leider so eine Funktion für den MS SQL Server nicht finden.
Gruß
V-FSI09
Hallo @V-FSI09,
schau dir mal den
Ausserdem: http://www.sqlhacks.com/Optimize/Defragment-Data
Gruß
Snow
schau dir mal den
DBCC INDEXDEFRAG-Befehl an.Ausserdem: http://www.sqlhacks.com/Optimize/Defragment-Data
Gruß
Snow
Hallo,
bist du dir denn sicher, daß du hier überhaupt an der richtigen Stelle suchst ?
http://msdn.microsoft.com/de-de/library/ms175008.aspx sagt zu dieser Fragmentierung:
Prozentsatz der Blöcke, die beim Scannen der Blattseiten eines Indexes nicht richtig einsortiert waren. Diese Zahl ist für Heaps nicht relevant. Ein nicht richtig einsortierter Block ist ein Block, für den der Block, der die aktuelle Seite eines Indexes enthält, physisch nicht der nächste Block nach dem Block ist, der die vorherige Seite des Indexes enthält.
HinweisHinweis Diese Zahl ist bedeutungslos, wenn der Index mehrere Dateien umfasst.
Also schonmal zwei Situationen, wo dieser Wert nix aussagt.
Wie groß ist denn die DB, wieviel RAM hat der Server ?
bist du dir denn sicher, daß du hier überhaupt an der richtigen Stelle suchst ?
http://msdn.microsoft.com/de-de/library/ms175008.aspx sagt zu dieser Fragmentierung:
Prozentsatz der Blöcke, die beim Scannen der Blattseiten eines Indexes nicht richtig einsortiert waren. Diese Zahl ist für Heaps nicht relevant. Ein nicht richtig einsortierter Block ist ein Block, für den der Block, der die aktuelle Seite eines Indexes enthält, physisch nicht der nächste Block nach dem Block ist, der die vorherige Seite des Indexes enthält.
HinweisHinweis Diese Zahl ist bedeutungslos, wenn der Index mehrere Dateien umfasst.
Also schonmal zwei Situationen, wo dieser Wert nix aussagt.
Wie groß ist denn die DB, wieviel RAM hat der Server ?
Hi,
der Server läuft auf 64 Bit und hat 8GB RAM, die betroffene DB hat um die 4 GB. Es gibt aber noch weitere DBs also insgesamt so ca. 16 GB MDFs.
Ich werde mal den DBCC INDEXDEFRAG Befehl ausprobieren...
der Server läuft auf 64 Bit und hat 8GB RAM, die betroffene DB hat um die 4 GB. Es gibt aber noch weitere DBs also insgesamt so ca. 16 GB MDFs.
Ich werde mal den DBCC INDEXDEFRAG Befehl ausprobieren...
Ich habe mal bei mir das Script zur Defragmentierung von Indizes ausgeführt und dabei maxfrag auf 5 gestellt.
Siehe: http://msdn.microsoft.com/de-de/library/ms177571.aspx
"Mit DBCC SHOWCONTIG und DBCC INDEXDEFRAG die Indizes in einer Datenbank defragmentieren"
Es wurden keine Indizes gefunden die über 5 % fragmentiert sind.
Somit brachte DBCC INDEXDEFRAG auch nichts.
Jemand noch ne Idee?
Siehe: http://msdn.microsoft.com/de-de/library/ms177571.aspx
"Mit DBCC SHOWCONTIG und DBCC INDEXDEFRAG die Indizes in einer Datenbank defragmentieren"
Es wurden keine Indizes gefunden die über 5 % fragmentiert sind.
Somit brachte DBCC INDEXDEFRAG auch nichts.
Jemand noch ne Idee?
Hallo V-FSI09,
als Allerweltstip fällt mir noch ein, die Statistiken zu aktualisieren mit "exec sp_updatestats". Hat unter SQL Server 2000 Wunder gewirkt. In neueren Versionen des SQL Server kann man in den Optionen einstellen, daß das automatisch passiert, aber ich weiß nicht, wie die Einstellung ist, wenn Du eine SQL Server 2000 DB da reinbringst, ob das dann eingeschaltet ist. Auch weiß ich nicht, wie zuverlässig die Option ist, auf meinen DBen läuft dieser Befehl jedenfalls immer noch wöchentlich. Und schaden tut es eh nicht
Ob der neue Server unbedingt schneller sein muß, ist eh die Frage. Wir wissen nichts über die Hardware des alten Server und was auf dem alten und neuen Server sonst noch so läuft. Wenn der SQL Server 2000 auf einem nur wenig schwächeren Server lief und die einzige DB und Software war, dann kann es durchaus sein, daß sie auf dem neuen Server mit noch weiteren DBen und vielleicht noch anderen Programmen langsamer läuft. Allein der Wechsel von SQL Server 2000 zu 2008 macht die DB ja noch nicht deutlich schneller.
Und bist Du auch sicher, daß Dein Performanceproblem von der DB an sich herrührt und nicht von Netzwerk, Anwendung, DB-Design, ...? Wenn z.B. Indexe fehlen, wird die DB natürlich langsamer, je voller die Tabellen werden.
Gruß, Mad Max
als Allerweltstip fällt mir noch ein, die Statistiken zu aktualisieren mit "exec sp_updatestats". Hat unter SQL Server 2000 Wunder gewirkt. In neueren Versionen des SQL Server kann man in den Optionen einstellen, daß das automatisch passiert, aber ich weiß nicht, wie die Einstellung ist, wenn Du eine SQL Server 2000 DB da reinbringst, ob das dann eingeschaltet ist. Auch weiß ich nicht, wie zuverlässig die Option ist, auf meinen DBen läuft dieser Befehl jedenfalls immer noch wöchentlich. Und schaden tut es eh nicht
Ob der neue Server unbedingt schneller sein muß, ist eh die Frage. Wir wissen nichts über die Hardware des alten Server und was auf dem alten und neuen Server sonst noch so läuft. Wenn der SQL Server 2000 auf einem nur wenig schwächeren Server lief und die einzige DB und Software war, dann kann es durchaus sein, daß sie auf dem neuen Server mit noch weiteren DBen und vielleicht noch anderen Programmen langsamer läuft. Allein der Wechsel von SQL Server 2000 zu 2008 macht die DB ja noch nicht deutlich schneller.
Und bist Du auch sicher, daß Dein Performanceproblem von der DB an sich herrührt und nicht von Netzwerk, Anwendung, DB-Design, ...? Wenn z.B. Indexe fehlen, wird die DB natürlich langsamer, je voller die Tabellen werden.
Gruß, Mad Max
Hallo,
den Befehl exec sp_updatestats habe ich auch schon ausprobiert, leider auch ohne Verbesserung.
Auf den den Servern sind sonst keine anderen Programme installiert außer der SQL Server.
Der alte/neue Server ist virtualisiert.
alte VM: Server 2000 32Bit mit SQL 2000 Std. mit 3 GB RAM
neue VM: Server 2008 64Bit mit SQL 2008 Std. mit 8 GB RAM
an den DBs hat sich nichts geändert, habe die lediglich auf den neuen wiederhergestellt.
Der alte SQL lief von Anfang an recht flott.
Die Datenbanken sind ja von Zeit zu Zeit langsamer geworden. Habe gehofft dass die Fehler bei der Übernahme auf den neuen Server nicht mit übernommen werden.... aber dem scheint nicht so, obwohl der neue SQL mehr Leistung bringen sollte durch mehr RAM.
Ich habe vor, zum Produktivstart den SQL Profiler mitlaufen zulassen und die Indexe dann optimieren zu lassen.
Wenn das auch nichts hilft, dann weiß ich nicht weiter...
Grüße
den Befehl exec sp_updatestats habe ich auch schon ausprobiert, leider auch ohne Verbesserung.
Auf den den Servern sind sonst keine anderen Programme installiert außer der SQL Server.
Der alte/neue Server ist virtualisiert.
alte VM: Server 2000 32Bit mit SQL 2000 Std. mit 3 GB RAM
neue VM: Server 2008 64Bit mit SQL 2008 Std. mit 8 GB RAM
an den DBs hat sich nichts geändert, habe die lediglich auf den neuen wiederhergestellt.
Der alte SQL lief von Anfang an recht flott.
Die Datenbanken sind ja von Zeit zu Zeit langsamer geworden. Habe gehofft dass die Fehler bei der Übernahme auf den neuen Server nicht mit übernommen werden.... aber dem scheint nicht so, obwohl der neue SQL mehr Leistung bringen sollte durch mehr RAM.
Ich habe vor, zum Produktivstart den SQL Profiler mitlaufen zulassen und die Indexe dann optimieren zu lassen.
Wenn das auch nichts hilft, dann weiß ich nicht weiter...
Grüße
Hallo V-FSI09,
erst dachte ich, daß Du AWE nicht eingeschaltet hast, aber der SQL Server 2008 ist ja 64Bit, da brauchst Du das nicht.
Dann aber noch eine Sache: Die Speicheraufteilung (Management Studio, Servereigenschaften, Arbeitsspeicher) solltest Du nicht SQL Server überlassen. Zum einen darf sich SQL Server nicht den ganzen Speicher krallen, zumindest das BS braucht auch ein bissl. Zum anderen sollten sich unterschiedliche SQL Server Instanzen, wenn Du denn mehrere hast, nicht ins Gehege kommen. Sonst kann es sein, daß da Daten ausgelagert und auf der Festplatte rumgeschaufelt werden.
Und wenns das nicht ist, tippe ich mal auf die Indexe
Gruß, Mad Max
erst dachte ich, daß Du AWE nicht eingeschaltet hast, aber der SQL Server 2008 ist ja 64Bit, da brauchst Du das nicht.
Dann aber noch eine Sache: Die Speicheraufteilung (Management Studio, Servereigenschaften, Arbeitsspeicher) solltest Du nicht SQL Server überlassen. Zum einen darf sich SQL Server nicht den ganzen Speicher krallen, zumindest das BS braucht auch ein bissl. Zum anderen sollten sich unterschiedliche SQL Server Instanzen, wenn Du denn mehrere hast, nicht ins Gehege kommen. Sonst kann es sein, daß da Daten ausgelagert und auf der Festplatte rumgeschaufelt werden.
Und wenns das nicht ist, tippe ich mal auf die Indexe
Gruß, Mad Max
