none
SQL 2008 R2 sichert auf bestimmte andere Server extrem langsam trotz vorhandener Bandbreite RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen,

    wir beobachten hier gerade folgendes Phänomen:

    Mehrere SQL-Server (2008 und 2008R2, auf W2k8R2) sichern teilweise auf andere Server (natives Backup als .bak-File) extrem langsam.

    Ein Filecopy von diesen SQL-Servern auf die entsprechende Freigabe auf die auch das native Backup so langsam läuft ist aber mit voller Bandbreite (also ca. 90MB/s schreibend konstant) möglich.

    Sichert man von einem älteren SQL-Server (2005) gehts ebenfalls problemlos auf diese Freigabe ....

    Wo können wir hier suchen und evtl. drehen um diesem Verhalten auf die Schliche zu kommen?

    Hat jemand eine Idee für uns ?

    Liebe Grüße,

    Markus

    Donnerstag, 28. November 2013 12:27

Alle Antworten

  • Hi Markus,

    schnelle Gegenfrage: Wie schnell oder langsam ist denn die Sicherung, wenn Ihr erst mal lokal sichert (nach Möglichkeit nicht auf das Volume, wo Eure DB Dateien liegen)?

    Damit ließen sich die Bereiche ggf. schon mal etwas eingrenzen.

    Gruß Dirk


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

    Donnerstag, 28. November 2013 12:42
  • hallo Dirk,

    also: lokal geht genauso schnell wie über gigabit (also ca. 100MB/s auf eine 2. HD)

    Donnerstag, 28. November 2013 12:56
  • Jetzt hab ich beim 1. Post vergessen zu fragen: Tritt das Phänomen urplötzlich auf und vorher waren die Backups schneller?

    Wo man vorab schon mal eine kleine Verbesserung erreichen könnte (sofern nicht schon geschehen): Nutze die Backup-Komprimierung. Das reduziert die wegzuschreibende Datenmenge.

    Nur bei Deinen 2008er SQL Servern kann das ggf. nix bringen, wenn diese nur Standard Editionen sind.

    "Die Lösung" oder Ursache fällt mir jetzt leider nicht ein, aber falls die Zeit da ist, dann guck doch mal, ob Du mit den diversen Backupoptionen noch was erreichen kannst. Der Henk van der Valk hat da mal was Schönes gepostet, siehe http://henkvandervalk.com/how-to-increase-sql-database-full-backup-speed-using-compression-and-solid-state-disks

    Wenn mir noch was einfällt, dann poste ich noch mal.


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

    Donnerstag, 28. November 2013 13:50
  • Hallo,

    ich habe jetzt noch ein bisschen rumexperimentiert:

    Sichere ich einen SQL2005-Server auf die Freigabe läuft alles schön, Sicherung wird mit "normaler" Geschwindigkeit gesichert.

    Sichere ich eine Datenbank von einem anderen SQL-Server (egal ob 2008 / 2008R2 und egal ob 64Bit oder 32Bit) komme ich nicht über 1,5% der verfügbaren Bandbreite

    der "Grundrauschen" Level der hier zu sehen ist, ist die Sicherung von einem 2008er Server, der hohe "Peak" ist eine 4GB-Sicherung vom 2005er SQL-Server ....

    Ich habe bereits die Treiber auf den aktuellsten Stand gebracht, alle BIOS Updates für den Server (HP DL380) gemacht etc. etc.

    Hat noch jemand eine Idee ?

    Freitag, 29. November 2013 10:38
  • Hi,

    der SQL 2005 läuft auch auf Win Server 2008 R2 oder einem älteren OS??  Die Backup Destination ist welches OS?

    Werden die SQL Server unter dem gleichen Domain User betrieben?  Ist ggf hilfreich diese Rahmenbedingungennoch zu kennen.

    Gruß Dirk


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

    Freitag, 29. November 2013 14:30
  • Hallo Dirk,

    der 2005er läuft auf einem 2003er OS. Nebenbei: ich kann jeden der betroffenen Server auf z.B. meine Workstation oder auch andere Server problemlos sichern (mit HOHER Bandbreite) eben nur nicht mit diesem einen Server

    Ich habe jetzt mal die Netzwerkkarte im Verdacht und werde die vorhandene gegen einen anderen Herstellen tauschen .... Wie gesagt, eigentlich ist ja das Netzwerk komplett und toll da... nur eben nciht wenn ein SQL das schreiben anfängt.

    :-(


    Schönes Wochenende noch !

    Freitag, 29. November 2013 14:35
  • Ich wollt grad sagen:

    hat mal jemand das Netzwerk von dem Server aus betrachtet? Paketfehler etc.?

    Das Netzwerk im Spiel sein muss, ist ja schon klar, seit es lokal schnell geht.


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Freitag, 29. November 2013 14:40
  • Vom Switch bis zur Netzwerkkarte... jupps.

    Ggf mal gucken was die Porteinstellungen sagen (irgendwo ein auto negotiate drin?)


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

    Freitag, 29. November 2013 14:46
  • Guten Morgen,

    Nein bisher nicht. Ich bekomme heute eine andere NIC und werde es dann noch mal versuchen.

    Grüße,

    markus

    Montag, 2. Dezember 2013 08:08
  • Hallo,

    also die neue NIC hat genau das Selbe gebracht: SQL-Sicherungen langsam, alles andere schnell ....

    grrrrr.......

    Montag, 2. Dezember 2013 15:39
  • Wie schaut es mit den Porteinstellungen aus? Nirgendwo ein Auto-negotiate dazwischen?

    Ansonsten mal Kollegen vom Netzwerkteam (wenn vorhanden) besuchen und nachfragen, ob s ggf. Probleme mit dem Switch gibt?

    Wobei sich dann immer noch die Frage stellt, warum normale Kopierprozesse schnell bzw. normal ablaufen.


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

    Montag, 2. Dezember 2013 15:53
  • So, Problem ist gelöst !

    Es waren die Einstellungen des Array-Controllers bzw. des RAID-Laufwerks.

    Das ursprüngliche Array (mit dem das Sichern sich wie oben beschrieben verhalten hat) wurde über das Controller-BIOS des Servers (HP P400i onBoard Array Controller) gemacht. (also gleich nach dem Einschalten)

    Nachdem ich das Array gelöscht und über das ACU-Utility neu erstellt habe (dort kann man auch andere Block-Größen etc. definieren, in unserem Fall 64k-Blöcke statt der vorher 32K) und dann das Laufwerk neu erstellt habe ist die Sicherung von den 2008er SQL-Servern endlich so wie sie sein soll. Alles ist prima ...

    Danke und liebe Grüße aus München,

    Markus

    Mittwoch, 4. Dezember 2013 12:51