none
Wechsel von 2000 nach 2008R2 bringt extreme Performanceprobleme RRS feed

  • Frage

  • Hallo,

    der SqlServer2000 soll in Rente und deshalb starte ich die Migration der Datenbanken auf einen 2008R2 Server.

    In einigen Datenbanken stecken relativ komplexe Batchabfragen die 1-2mal am Tag erzeugt werden und dann in Ergebnisstabellen abgelegt sind.

    Ein dieser Abfragen dauert bei Select Top 1000 auf SQL2000 22 Sec gegenüber 45:00 Minuten auf 2008R2!!

    Der Unterschied bei Select Top 100 statt 1000 Sätzen  beträgt 18sec gegenüber 4:30 Minuten auf 2008R2.

    Das kann so nicht bleiben! Wo soll ich zuerst ansetzen?

    Hardware: SQL2K auf Dediziertem Server  Xeon 2 Kerne a 2,8Ghz; 4GB Ram; 2 Raidkanäle mit 15k Platten

    Sql2008R2 Standard auf Win2008R2 auf VM Server zugeteilt sind: 1 Xeon 6550 4 Kerne a 2Ghz; 8BG Ram; Fiberchannel Platten

    Die Datenbank wurde auf Sql2K gesichert und in 2008R2 mit Restore wieder hergestellt. Ein Job für Index und Statistikneuaufbau ist schon gelaufen, bringt aber nichts. Die Datenbank ist ca 6GB Groß und der Server hat 6,5GB Speicher alloziiert.  Sonst läuft noch nichts auf dem Server, es sollen jedoch noch ca 20 weitere Datenbank unterschiedlicher Größe drauf!

    Eigentlich hatte ich erwartet, das es schneller wird als auf dem alten.

    Was kann das Problem sein?

    Danke für euer Hilfe,

    Gruß Dieter

     

    Freitag, 30. September 2011 23:06

Alle Antworten

  • Hallo Dieter,

    SQL 2008 R2 reagiert auf bestimmte Sachen ziemlich allergisch, die bei SQL 2000 bis teils auch 2008 (ohne R2) problemlos liefen.

    Um dir aber helfen zu können, bräuchte man die Abfragedefinition und den Ausführungsplan. Ab und an bringt dir das SSMS hier auch eine sinnvolle Angabe bspw. zu fehlenden Indizes, ...

    Bzgl. Analyse und der Anzeige des Ausführungsplans, den Du dann bitte hier postest, bzw. online zur Verfügung stellst, siehe:

      http://msdn.microsoft.com/de-de/library/ms191227.aspx

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
    Freitag, 30. September 2011 23:29
    Moderator
  • Hallo Stefan,

    Klar kann man die Abfrage, wenn man Sie auf dem R2 Server neu aufbaut auch optimieren, aber es ist nur eine von vielen.

    Eigentlich sollte nur der Server modernisiert werden, da es keinen Support mehr gibt. Heißt das, man muss nun das gesamte Datenbankdesing neu testen und optimieren? Es handelt sich um rund 20 Datenbanken mit gesamt ca 800-1200 Abfragen + Trigger + SP's. Zugegen gibt es hier Abfragen die ohne Rücksicht immer wieder erweitert wurden und daher nicht optimiert sind. Sie haben aber immer funktioniert ohne Timeouts zu erzeugen. Der Updateadvisor lief auch ohne große Probleme aufzuzeigen.

    Gruß Dieter

     

    Samstag, 1. Oktober 2011 08:48
  • Hallo Dieter,

    wie gesagt, ich habe die Erfahrung gemacht, dass bestimmte Abfragen bis einschließlich SQL 2008 problemlos liefen, beim Umstieg auf 2008 R2 dann aber extrem unperformant wurden. Wenn man sich den Ausführungsplan dann angeschaut hat, kam im SSMS oft ein Hinweis auf einen fehlenden Index, der bei mir im Extremfall 99% Performanceverbesserung bringen sollte (und das auch getan hat). Warum das nun bei SQL 2000, 2005 und 2008 auch ohne diesen Index problemlos und sehr performant lief, bei 2008 R2 aber nicht mehr, konnte ich allerdings nicht wirklich nachvollziehen.

    Man kann sich natürlich mal über Extras -> Datenbankoptimierungsratgeber über evtl. Verbesserungsmöglichkeiten informieren lassen, ob das bei dir hilft, weiß ich natürlich nicht.

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
    Samstag, 1. Oktober 2011 09:24
    Moderator
  • Hallo Dieter,
    ich würde auch den Kompatibilitätslevel hochsetzen und testen, ob die
    Anwendung damit funktioniert.
    Dazu gehört auch, dass Du mit
    exec sp_updatestats;
    dbcc updateusage ('MeineDB');
     
    die Statistiken aktualisierst und mit
    ALTER DATABASE MeineDB SET PAGE_VERIFY CHECKSUM  WITH NO_WAIT;
    die Seitenüberprüfung auf den aktuellen Stand hebst.
     
    Der SQL Server wird Dir nach einigen Testläufen auch Hinweise auf fehlende
    Indizes geben. Eine Umstellung, ganz ohne Anpassungen wird es wohl nicht
    geben.
     
    Von Glenn Berry gibt es auch einen ganz aktuellen Satz von SQLs zur Analyse:
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu
     
     
    Dienstag, 4. Oktober 2011 07:41
    Beantworter
  • Hallo Stefan, Hallo Christoph,

    leider sind das keine guten News, denn es sollte nicht alles überarbeitet werden, sondern nur der Server aktualisiert.

    Wird es sich lohnen die Konvertierung mal auf 2008 (R1) zu versuchen?

    Anderenfalls wird das ein Fass ohne Boden, denn ersten sind es sehr viele und sehr alte Anwendungen und zweitens gibt es in den Anwendungen auch einen Abfragegenerator mit dem der Anwender sich selbst Listen zusammenstellen kann.

    Da habe ich gar keinen Einfluss wie die Index liegen sollten.

    Beim 2000er Server hat das immer prächtig funktioniert. Im Gegenteil, bei Tabellen mit weniger als 1000 Datensätzen habe ich gar keine Indexe außer PK definiert und konnte keine Einbussen feststellen.

    War jetzt früher alles besser oder bin ich auf dem Holzweg?

    Gruß Dieter

     


    • Bearbeitet Dieter Mang Dienstag, 4. Oktober 2011 16:29
    Dienstag, 4. Oktober 2011 16:28
  • Hallo Dieter,
    kannst Du mal exemplarisch zu einer Abfrage die beiden Abfragepläne vergleichen? Vielleicht sieht man dort direkt einen deutlichen Unterschied.
     Falls Du das SQL im Management Studio ausführst, erhältst Du auch schon mal einen Hinweis auf fehlende Indizes. Hast Du da schon was gesehen?
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu

    Mittwoch, 5. Oktober 2011 07:29
    Beantworter
  • Hallo Christoph,

    nein, einen Index hat das Managemet Studio nicht vorgeschlagen. Wo sollte der stehen? Aber so wie es aussieht muß die Datenbank eh auf einen 2008R1 Server. Ich werde dann mal neu testen.

    Was ich im Ablaufplan gesehen habe ist die Hauptkostenlast in einer Hilfstabelle mit lediglich 70 Datensätzen. Sowas war nie indiziert. Außer PK natürlich.

    Gruß Dieter

     

     

     

    Mittwoch, 5. Oktober 2011 21:27
  • Hallo Dieter,
    wenn Du Dir den geschätzten Ausführungsplan anzeigen lässt, erscheint im unteren Fenster des SSMS schon mal ein (grüner) Hinweis auf einen fehlenden Index.

    Macht es Sinn mal das Statement und die beiden Ausführungspläne zu diskutieren? Ich kann mir nicht vorstellen, dass eine Tabelle mit 70 Datensätzen alleine Schuld an so einem gewaltigen Unterschied sein soll.

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

    Donnerstag, 6. Oktober 2011 07:14
    Beantworter
  • Hallo Dieter,

    es wurde ja schon mehrfach nach den Ausführungsplänen gefragt, hattest Du jetzt mal die genauer untersucht?

    Es gibt da durchaus kleine Details, die man übersieht. Z.B. wird im Blog Beitrag SQL Server Parallelism–The Dark Side ein vergleichbares Performanzproblem nach einem Upgrade beschrieben; kleine Ursache mit großer Wirkung, welches sich aber auch beheben lässt.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Montag, 10. Oktober 2011 16:51