none
SQL Server 2005, Reboot-Zeiten RRS feed

  • Allgemeine Diskussion

  • Hallo Forum,

    wir haben hier 2 Server mit SQL Server 2005 auf Windows 2003, aktuelles Patchlevel. Beide Maschinen brauchen unglaublich lange beim monatlichen (Patchday-)Reboot, also mindestens eine halbe Stunde, eher 45 min. Zäh wie Kaugummi - ähnlich wie das manch einer noch von Exchange 5.5 auf NT4 kennt. Die größten Teil der Zeit nimmt dabei das Herunterfahren in Anspruch, das Hochfahren geht dagegen recht flott. Es nützt auch nichts vor dem Reboot die MSSQLxx Dienste zu beenden o.ä.

    Beide Server sind völlig unterschiedlich, der eine ist ein 4 Jahre alter Pentium D mit 4 GB und 32-bit OS, der andere ein recht aktueller Dual-Quadcore Xeon mit 8GB und alles in 64-bit. Aber die Rebootdauer ist fast gleich.

    Ich bin versucht das als Bug von SQL Server 2005 zu bezeichnen, denn wir haben noch mindestens 20 weitere 2003er Server und ALLE sind in wenigen Minuten neugestartet, auch der Exchange.

    Oder hat jemand eine Erklärung für dieses Verhalten?

    Freitag, 24. September 2010 14:40

Alle Antworten

  • Hi J.Riegner,
     
    > wir haben hier 2 Server mit SQL Server 2005 auf Windows 2003, aktuelles
    > Patchlevel.
    > Beide Maschinen brauchen unglaublich lange beim monatlichen
    > (Patchday-)Reboot, also
    > mindestens eine halbe Stunde, eher 45 min. Zäh wie Kaugummi - ähnlich wie
    > das manch
    > einer noch von Exchange 5.5 auf NT4 kennt. Die größten Teil der Zeit nimmt
    > dabei das
    > Herunterfahren in Anspruch, das Hochfahren geht dagegen recht flott. Es
    > nützt auch nichts
    > vor dem Reboot die MSSQLxx Dienste zu beenden o.ä.
    >
    > Beide Server sind völlig unterschiedlich, der eine ist ein 4 Jahre alter
    > Pentium D mit 4 GB
    > und 32-bit OS, der andere ein recht aktueller Dual-Quadcore Xeon mit 8GB
    > und alles in
    > 64-bit. Aber die Rebootdauer ist fast gleich.
    >
    > Ich bin versucht das als Bug von SQL Server 2005 zu bezeichnen, denn wir
    > haben noch
    > mindestens 20 weitere 2003er Server und ALLE sind in wenigen Minuten
    > neugestartet,
    > auch der Exchange.
    >
    > Oder hat jemand eine Erklärung für dieses Verhalten?
     
    Frage: Wie groß sind die Datenbanken und welches Storage-Subsystem (d.h.
    Storage-Controller, RAID-Level, LUN-Aufteilung, RAID-Cache, Anzahl der
    Festplatten, max. Umdrehungen je Festplatte usw.) liegt darunter?
     
    Zusatzfrage: Welche Zusatzsoftware kann evtl. auf dem Server das verzögerte
    Beenden von Diensten (ggf. warten bis zu einem Timeout) verursachen?
     
     
    Hinweis: Wieso denkt eigentlich jeder IT-Admin, dass ein schneller Server
    durch eine schnelle CPU definiert wird? Eine schnelle CPU (sprich: MHz -
    jedoch nicht die Anzahl der Cores) ist bei einem Server das letzte, was
    wirkliche Performance ausmacht.
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Samstag, 25. September 2010 08:18
  •  
    Frage: Wie groß sind die Datenbanken und welches Storage-Subsystem (d.h.
    Storage-Controller, RAID-Level, LUN-Aufteilung, RAID-Cache, Anzahl der
    Festplatten, max. Umdrehungen je Festplatte usw.) liegt darunter?
     
    Zusatzfrage: Welche Zusatzsoftware kann evtl. auf dem Server das verzögerte
    Beenden von Diensten (ggf. warten bis zu einem Timeout) verursachen?
     
     
    Hinweis: Wieso denkt eigentlich jeder IT-Admin, dass ein schneller Server
    durch eine schnelle CPU definiert wird? Eine schnelle CPU (sprich: MHz -
    jedoch nicht die Anzahl der Cores) ist bei einem Server das letzte, was
    wirkliche Performance ausmacht.

     

    Zu Frage 1: Auf dem alten Server gibts nur eine einzige DB von 800 MB, auf dem neuen
    6 Haupt-DBs zwischen wenigen MB und 3 GB Größe, plus einige Test-DBs die so gut wie nie im Zugriff sind. Also auch hier, relativ unterschiedliche Ausstattung. Das gilt auch für die Storage, aber ich werde jetzt keine weiteren Details aufzählen. Ich lasse mir da keinen Zusammenhang mit der Hardware andrehen, sorry. Es gibt ja auch gar kein Performance-Problem, im Gegenteil. Die langweilien sich die meiste Zeit zu Tode. Aber durch die Dauer des Neustarts muss ich eine Downtime in Kauf nehmen, die mir unnötig lange erscheint und einfach nervt.

    Zur Zusatzfrage: Solche Effektek kann ich weitgehend ausschließen. Auf der neuen Maschine ist außer dem SQL-Server keine Software installiert, auf der anderen habe ich bereits alles an Drittsoftware als Ursache manuell deaktiviert, ohne dass das eine Änderung gebracht hätte.

    Zum Hinweis: Soll ich mich da angesprochen fühlen? Ich wüsste nicht warum. Mir ist schon klar dass bei einem DB-Server das Plattensubsystem eine wichtige Rolle spielt. Die o.g. Details zur Hardware sollten nur verdeutlichen, dass es sich um zwei verschiedene Hardware-Generationen handelt, das Problem aber bei beiden erstaunlich ähnlich ist. 
    Der Vorgänger-Server mit SQL2K hatte es nicht, obwohl dort schon die gleichen DBs drauf waren und das ganze auf Uralt-Hardware und Software(!)-RAID...

    Montag, 27. September 2010 13:49
  • Hi J.Riegner,
     
    > Frage: Wie groß sind die Datenbanken und welches Storage-Subsystem (d.h.
    > Storage-Controller, RAID-Level, LUN-Aufteilung, RAID-Cache, Anzahl der
    > Festplatten, max. Umdrehungen je Festplatte usw.) liegt darunter?
    >
    > Zusatzfrage: Welche Zusatzsoftware kann evtl. auf dem Server das
    > verzögerte
    > Beenden von Diensten (ggf. warten bis zu einem Timeout) verursachen?
    >
    >
    > Hinweis: Wieso denkt eigentlich jeder IT-Admin, dass ein schneller Server
    > durch eine schnelle CPU definiert wird? Eine schnelle CPU (sprich: MHz -
    > jedoch nicht die Anzahl der Cores) ist bei einem Server das letzte, was
    > wirkliche Performance ausmacht.
    >
    >
    > Zu Frage 1: Auf dem alten Server gibts nur eine einzige DB von 800 MB, auf
    > dem neuen
    > 6 Haupt-DBs zwischen wenigen MB und 3 GB Größe, plus einige Test-DBs die
    > so gut
    > wie nie im Zugriff sind. Also auch hier, relativ unterschiedliche
    > Ausstattung. Das gilt auch
    > für die Storage, aber ich werde jetzt keine weiteren Details aufzählen.
    > Ich lasse mir da
    > keinen Zusammenhang mit der Hardware andrehen, sorry. Es gibt ja auch gar
    > kein
    > Performance-Problem, im Gegenteil. Die langweilien sich die meiste Zeit zu
    > Tode. Aber
    > durch die Dauer des Neustarts muss ich eine Downtime in Kauf nehmen, die
    > mir unnötig
    > lange erscheint und einfach nervt.
    >
    > Zur Zusatzfrage: Solche Effektek kann ich weitgehend ausschließen. Auf der
    > neuen Maschine
    > ist außer dem SQL-Server keine Software installiert, auf der anderen habe
    > ich bereits alles
    > an Drittsoftware als Ursache manuell deaktiviert, ohne dass das eine
    > Änderung gebracht hätte.
    >
    > Zum Hinweis: Soll ich mich da angesprochen fühlen? Ich wüsste nicht warum.
    > Mir ist schon
    > klar dass bei einem DB-Server das Plattensubsystem eine wichtige Rolle
    > spielt. Die o.g.
    > Details zur Hardware sollten nur verdeutlichen, dass es sich um zwei
    > verschiedene
    > Hardware-Generationen handelt, das Problem aber bei beiden erstaunlich
    > ähnlich ist.
    > Der Vorgänger-Server mit SQL2K hatte es nicht, obwohl dort schon die
    > gleichen DBs
    > drauf waren und das ganze auf Uralt-Hardware und Software(!)-RAID...
     
    Wenn Du Dir nicht helfen lassen willst.. und schon alles selbst
    ausgeschlossen hast .. dann ruf den Microsoft Support an und lass Dir dort
    als zentrale Instanz bestätigen, ob es sich um ein Bug (kostenlos) oder doch
    um ein nicht produktspezifisches Problem (kostenpflichtig) handelt.
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Montag, 27. September 2010 14:24
  • Wenn Du Dir nicht helfen lassen willst.. und schon alles selbst
    ausgeschlossen hast .. dann ruf den Microsoft Support an und lass Dir dort
    als zentrale Instanz bestätigen, ob es sich um ein Bug (kostenlos) oder doch
    um ein nicht produktspezifisches Problem (kostenpflichtig) handelt.
     
     
     

    Ja, das ist tatsächlich eine Option die man in Betracht ziehen könnte. Nur hab ich nicht alles ausgeschlossen, auch nicht eine Fehlkonfiguration meinerseits. Ich bin kein geschulter SQL-Admin. Hätte ja sein können dass hier jemand ähnliche Erfahrungen gemacht und vielleicht sogar eine Lösung oder einen Tipp hat.

    Wenn ich allerdings jemanden gesucht hätte der mein Problem erstmal auf die Hardware schiebt, hätte ich einfach den nächstbesten Entwickler gefragt - das ist schließlich deren Standardantwort.

    Montag, 27. September 2010 16:14
  • Hi J.Rieger,
     
    >> Wenn Du Dir nicht helfen lassen willst.. und schon alles selbst
    >> ausgeschlossen hast .. dann ruf den Microsoft Support an und lass Dir
    >> dort
    >> als zentrale Instanz bestätigen, ob es sich um ein Bug (kostenlos) oder
    >> doch
    >> um ein nicht produktspezifisches Problem (kostenpflichtig) handelt.
    [..]
    > Ja, das ist tatsächlich eine Option die man in Betracht ziehen könnte. Nur
    > hab ich nicht
    > alles ausgeschlossen, auch nicht eine Fehlkonfiguration meinerseits. Ich
    > bin kein geschulter
    > SQL-Admin. Hätte ja sein können dass hier jemand ähnliche Erfahrungen
    > gemacht und
    > vielleicht sogar eine Lösung oder einen Tipp hat.
    >
    > Wenn ich allerdings jemanden gesucht hätte der mein Problem erstmal auf
    > die Hardware
    > schiebt, hätte ich einfach den nächstbesten Entwickler gefragt - das ist
    > schließlich deren
    > Standardantwort.
     
    frag mal im zugehörigen SQL Server Forum nach, evtl. haben die mehr
    praktische Erfahrung bzgl. Shutdown-Probleme:
     
    http://social.technet.microsoft.com/Forums/de-de/category/sqlserver
     
     
    Hinweis: Meine Fragen bezogen sind auf ein allg. Ausschlussverfahren. Z.B.
    benötigen große Datenbanken auf zu langsamen Festplatten sehr lange beim
    schliessen. Auch ist die Frage nach Zusatzsoftware (z.B. AV-Lösungen usw.)
    nicht zu vernachlässigen usw.. Was weiss denn ich, was ich vor Ort bei dir
    vorfinden würde und evtl. schon alles getestet wurde..?
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
    Montag, 27. September 2010 17:02
  • Hallo

    ist das Problem noch aktuell?

    ist die Richtlinie für das Löschen der Ablagerungsdatei aktiviert? Computerkonfiguration - Windowseinstellungen - Sicherheitseinstellungen - Lokale Richtlinien - Sicherheitsoptionen - Herunterfahren: Auslagerungsdatei des virtuellen Arbeitsspeichers löschen

    Evtl. könnte auch ein sauberer Neustart (alles nicht MS Dienste und Drittanbieter Anwendungen per msconfig deaktivieren) zur Problemeinschränkung weiterhelfen..

    Gruß
    Andrei

    Donnerstag, 30. September 2010 10:12
    Moderator
  • frag mal im zugehörigen SQL Server Forum nach, evtl. haben die mehr
    praktische Erfahrung bzgl. Shutdown-Probleme:
    http://social.technet.microsoft.com/Forums/de-de/category/sqlserver
     
    Hinweis: Meine Fragen bezogen sind auf ein allg. Ausschlussverfahren. Z.B.
    benötigen große Datenbanken auf zu langsamen Festplatten sehr lange beim
    schliessen. Auch ist die Frage nach Zusatzsoftware (z.B. AV-Lösungen usw.)
    nicht zu vernachlässigen usw.. Was weiss denn ich, was ich vor Ort bei dir
    vorfinden würde und evtl. schon alles getestet wurde..?

    Hallo Tobias,

    danke für den Tip mit dem SQL Forum, da hätte die Frage von Anfang rein sollen, ich hatte es nur irgendwie übersehen.

    Ansonsten schon klar was du meinst, aber ich hatte die genannten Punkte halt (zumindest für mich) schon in der Fragestellung ausgeschlossen.

    Was die AV-Lösung betrifft ist VSE 8.7i im Einsatz. Ich hab inzwischen DB-Data + DB-Log Verzeichnis komplett aus dem On-Access Scanner ausgeschlossen. Ob und wie sich das auswirkt, werde ich sehen sobald der nächste Neustart ansteht.

    Freitag, 22. Oktober 2010 13:11
  • ist das Problem noch aktuell?

    ist die Richtlinie für das Löschen der Ablagerungsdatei aktiviert? Computerkonfiguration - Windowseinstellungen - Sicherheitseinstellungen - Lokale Richtlinien - Sicherheitsoptionen - Herunterfahren: Auslagerungsdatei des virtuellen Arbeitsspeichers löschen

    Evtl. könnte auch ein sauberer Neustart (alles nicht MS Dienste und Drittanbieter Anwendungen per msconfig deaktivieren) zur Problemeinschränkung weiterhelfen..

    Hallo Andrei,

    das Problem ist immer noch aktuell. Die genannte Richtlinie ist bei uns nicht aktiv, das war's als nicht.

    Zum Clean Reboot: Dienste usw. muss ich nicht mal unbedingt deaktivieren, es reicht schon wenn das System gerade erst hochgefahren ist und dann sofort wieder neugestartet wird - dann flutscht die Sache und alles dauert nur wenige Minuten...

    Aber wenn die Kiste ein paar Tage läuft und darauf gearbeitet wurde, bringt es nicht mal was den SQL-Server sowie alle anderen nicht benötigten Task/Dienste zu beenden und dann erst neu zu starten. Was meine Annahme bestätigt dass es nichts mit Drittanbieter Software zu tun hat, die ohnehin nur aus McAfee und einem Sage Mehrbenutzerdienst besteht.


    Freitag, 22. Oktober 2010 13:25