Announcement

Collapse
No announcement yet.

sql-server lahmt ständig

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • sql-server lahmt ständig

    Hallo!

    Wir haben bei unserem Webhoster einen Server stehen auf welchem SBS 2003 läuft und nutzen davon nur den SQL-Server für unseren Shop und B2E-Portal.
    Die Hauptdatenbank hat eine Grösse von etwa 2,5 GB.
    Der Server ist mit 2GB RAM und einem mir im moment nicht bekannten Prozessor ausgestattet (alles insgesamt 3 jahre alt).

    In letzter Zeit haben wir ständig wieder das Problem, dass man mehrere Minuten warten muss bis im Shop eine Seite geladen wurde und auch bei Zugriff per Enterprise Manager läuft es alles andere als zügig.

    Nach Neustart der Dienste geht es wieder für eine Weile aber dann geht es immer wieder von vorne los. Der Server hat in solchen momenten laut Provider eine Auslastung von 100%.
    Das passiert manchmal alle halbe stunde, an manchen tagen läufts wie geschmiert...

    Ich habe geschaut, dass ich die Datenbankzugriffe durch den Shop reduziere so gut es nur irgendwie geht, aber leider habe ich mittlerweile keinen Plan mehr was ich noch machen soll...

    Wer hat ähnliche Probleme gehabt und weiss mögliche Lösungswege? Wie gross sollte die Datenbank maximal sein, bringt mehr RAM was?

    Vielen Dank!

    maba

  • #2
    Hi,

    in meiner Firma haben wir einen Server mit ähnlicher Ausstattung. Auch unsere Datenbank hat eine Größe von derzeit ca. 2,2 GB. Das ist aber alles völlig ausreichend.

    Ich hatte mal ein ähnliches Problem, tagelang läuft der Server perfekt, aber dann ganz plötzlich schnellt die CPU Auslastung auf 100% hoch. Nach einem Server-Neustart lief alles wieder prima.

    Wenn der SQL-Server-Prozess eine Auslastung von 100% hat, versuche mal eine Verbindung herzustellen und gibt folgendes Skript ein:

    -- Analyse
    --
    -- Script 1
    -- wichtig ist die Start-Zeit, Total_Elapsed_Time zeigt die bisherige Abarbeitungsdauer in Millisekunden an
    -- text zeigt das SQL-Script an, welche bearbeitet wird

    SELECT s.text, r.session_id, r.request_id, r.command, r.status, r.cpu_time, r.start_time, r.percent_complete, r.total_elapsed_time, r.estimated_completion_time
    FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) s
    ORDER BY r.start_time;

    Mit diesem Script kannst Du Dir die aktuellen Abfragen auf der Datenbank anschauen. Vielleicht ist ja eine ewig-lang-dauernde dabei. So kannst Du auch herausfinden, ob es vielleicht Abfrage-Schleifen gibt, z.B.: Es wird ein Trigger aktiviert, welcher etwas in eine Tabelle schreibt und denselben Trigger wieder aufruft - das geht ewig so weiter - bis zum Neustart.


    Grüße,
    Kristian

    Comment


    • #3
      Es wird ein Trigger aktiviert, welcher etwas in eine Tabelle schreibt und denselben Trigger wieder aufruft -
      Das würde aber voraussetzen, das die Option "Rekursive Trigger" aktiviert ist; was im Standard aus gutem Grund nicht der Fall ist.

      @Maba, wir habe hier eine vergleichbare Maschine mit insgs. 180 GB Datenbankenumfang, die wir mit Massendaten befeuern; keine Performance-Problem mit der Konstellation. Wir hatten das sogar schon mit einer 990 GB DB getestet.

      Da hilft nur Mitprotokollieren, was gerade läuft; z.B. wie Kristian es beschrieb.
      Wenn wirklich 100% Auslatung hast, solltest Du die "Dedicate Admin Connetcion" nutzen, sonst kannst Du Dich nicht mal anmelden.
      Olaf Helper

      <Blog> <Xing>
      * cogito ergo sum * errare humanum est * quote erat demonstrandum *
      Wenn ich denke, ist das ein Fehler und das beweise ich täglich

      Comment

      Working...
      X