Neu Datenbankoptimierungsratgeber - Alles was (man/ich) wissen muss

[dapole]

Ein wunderschönes hallo in die Runde,

Ich glaube, dass ich nichts verkehrt mache, wenn ich sage, dass wir wohl alle irgendwie mit Performance Problemen zu kämpfen haben.

Nun: was hat das ganze mit dem Titel zu tun?

Genau das ist. Hier die Frage (n)
Und zwar, um etwas konkreter zu werden:

- hat einer von euch schon den Datenbank Optimierer benutzt?
- der Datenbank optimierter scheint ja sehr mächtig zu sein und vor allem mit sehr vielen Funktionen und auch Einstellung Möglichkeiten kompliziert

Kann man mit dem Datenbankoptimierer problemlos herumspielen?
Oder läuft man Gefahr, dass man sich komplette Datenbank?

Ich habe einige versuche auf dem Testsystem durchgeführt und teilweise erschreckende Zahlen gesehen.
Vorab: es waren schon diverse Tests, keiner von denen hat es bislang geschafft, dass ich die Datenbank danach nicht mehr JTL Seite ich nutzen konnte. (Was ja ertmal gvut ist)
Dann gibt es noch die Möglichkeit, die Optimierung anhand des Abfrage Speichers durchzuführen oder auch anhand einer Arbeitsauslastungs-Datei .

Ich habe gestern ein paar Daten für die Arbeitsauslastungs-Datei gesammelt. Diese Datei habe ich in das Testsystem gespielt wo exakt die gleiche Datenbank drauf ist aus der ich Arbeitsauslastungs-Datei (*.trc) erzeugt habe.

Nun lasse ich dort eine Analyse durchlaufen. Nach ca. 2 Stunden steht so noch bei 0%
Das interessante:
Eine geschätzte Verbesserung von 49%


Ich bin gespannt, wie es nachher aussieht.

Nun: die Suche im Forum hat zu dem Thema Datenbank Optimierung gerade mal drei Suchergebnisse gefunden. Entweder wird es hier gar nicht genutzt, entweder soll es nicht genutzt werden oder ich weiss es auch nicht.

Solltet ihr also in dem Bereich irgendwelche Erfahrungen gemacht haben, würde es mich sehr freuen, wenn ihr diese mit uns Teilen könntet.

Das aller wichtigste ist:
Kann ich mit dem Datenbankoptimierer wirklich was kaputt machen?
Falls Ihr es nutzt, könnt ihr mir antworten / Hilfestellungen geben?

Viele Sachen habe ich mir selbst bei gebracht, viele noch nicht ...

B3ie, erzeugen der z.B. Arbeitsauslastungs-Datei (*.trc) über den Profiler hab ich die Möglichkeiten diverse Vorlagen zu verwenden. Bislang Standard genutzt? Welche unterschiede sind es/ sind diese relevant?

Beim Datenbankoptimierer selbst, sieht die Konfiguration so aus: (bzw. plane diese so auf unserem produktiven System, auszuführen)
Spricht da etwas gegen???

Ich freue mich rießig auf Antworten und hoffe, dass es hier einige gibt, die etwas mehr in der Thematik drin stecken als ich.

Nutzen tun tiw Windows Server 2019 mit SQL Server 2019

Grüße

 

[mh1]

Kann man mit dem Datenbankoptimierer problemlos herumspielen?

Der Datenbankoptimierungsratgeber prüft die Datenbank (nicht den Datenbankserver). Er kuckt sich also an, wie und wo die Daten in der Datenbank abgelegt werden und wie darauf zugegriffen wird.
Er kann dir dann mit Empfehlungen helfen, wie du die Datenbankstruktur ändern könntest im Bezug auf die Datenbankobjekte wie z.b. Indizes, indizierte Sichten oder die Partitionierung.
Das ist also eher ein Designer Instrument und in dem Fall hier eher was, dass die Programmierer von JTL nutzen.

Es bringt dir ja nichts, wenn du mit Hilfe des DB-Optimizers rausfindest, dass die Abfragen beim Erstellen einer Pickliste eigentlich zu umständlich sind, oder das bestimmte Aktion irgendwelche Indexe zu schnell fragmentieren....
Du kannst ja die Wawi eh nicht umprogrammieren
Wenn du allerdings deine eigene Wawi programmierst, oder auch nur eine firmeninterne Adressverwaltungsdatenbank aufbauen willst, dann wird der Datenbankoptimierer dein Freund.

Nun: die Suche im Forum hat zu dem Thema Datenbank Optimierung gerade mal drei Suchergebnisse gefunden. Entweder wird es hier gar nicht genutzt, entweder soll es nicht genutzt werden oder ich weiss es auch nicht.

Wahrscheinlich sind o.g. Gründe ausschlaggebend dafür.

 

[SebiW]

Wie mh1 schon schrieb: Das ist ein Tool für die Entwickler der Datenbank, also JTL und nicht für die Anwender. Du kannst damit nicht nur etwas kaputt machen sondern wirst das sogar ziemlich sicher wenn Du damit an der DB rumschraubst.

 

[dapole]

ICh hätte eher gedacht, dass es dafür Sorge tragen kann, genau solche schlechte Abfragen aufgrund von Aufbau eines anderen chaches / Indiexes etc, durchaus optmieren kann ....

Nun Mal schauen... wie sagt man so schln: Probnieren geht über studieren

 

[mh1]

ICh hätte eher gedacht, dass es dafür Sorge tragen kann, genau solche schlechte Abfragen aufgrund von Aufbau eines anderen chaches / Indiexes etc, durchaus optmieren kann ....

Genau so ist es ja auch.
Nur bringt dir das ja nichts. An welcher Stelle willst du denn in die Programmierung der Wawi eingreifen?

 

[JTL_fwenzl]

Änderungen an der Datenbank Struktur z.b. an den Indizes wird relativ sicher dazu führten, das das nächste Wawi Update fehlschlägt.

Davon kann ich nur abraten.

Gruss,
Frank

 

[christian1701]

ICh hätte eher gedacht, dass es dafür Sorge tragen kann, genau solche schlechte Abfragen aufgrund von Aufbau eines anderen chaches / Indiexes etc, durchaus optmieren kann ....

Nun Mal schauen... wie sagt man so schln: Probnieren geht über studieren

Jetzt raten dir eh schon alle mit guten Argumenten ab, sogar offiziell ein JTL Entwickler und was machst du?

 

[SebiW]

ICh hätte eher gedacht, dass es dafür Sorge tragen kann, genau solche schlechte Abfragen aufgrund von Aufbau eines anderen chaches / Indiexes etc, durchaus optmieren kann ....

Nun Mal schauen... wie sagt man so schln: Probnieren geht über studieren

Kannst Du auch. Gratulation: Du hast jetzt einen Fork der Wawi gebaut der nicht mehr kompatibel zu der Version von JTL ist.
Wenn es Dein Ziel ist, für immer auf einer Version zu bleiben und diese zu optimieren: Viel Spaß (wobei wir bei gewerblichem Einsatz hier schnell in rechtliche Probleme vorstoßen, afaik ist die Wawi nicht FOSS).
Solltest Du planen auch zukünftige JTL Versionen zu verwenden hast Du Dich damit mit Anlauf selbst ins Bein geschossen.
Das Tool macht beim Endanwender 0,0 Sinn. Auch wenns spannend ist damit rumzutüfteln. Du kannst aber direkt davon ausgehen, dass JTL das auch getan hat und es Gründe gibt warum sie entsprechendes nicht umgesetzt haben. Wahrscheinlich insbesondere Stabilitäts- und Kompatiblitätsprobleme.

Oder anders: Für jedes komplexe Problem gibt es eine einfache Lösung - und die ist immer falsch.

 

[mvh]

Moin.
Zuerst - ja, probieren ist grundsätzlich gut. Und Nein - erst nach studieren.
Ein zusätzlicher Index, der die Abfrage angeblich stark beschleunigt, ist an sich positiv, wird auch bestimmt mehrere WaWi-Updates überstehen.
Aber wirf mal einen Blick in die Tabelle tDbErrorlog, da stehen einige wenn nicht viele Meldungen "Die Transaktion (Prozess-ID XXXX) befand sich auf Sperre Ressourcen aufgrund eines anderen Prozesses in einer Deadlocksituation".
Viele davon sind Deadlock-Situation wegen einem Index, z.B. wegen IX_dbo_tPickliste_nStatus_nType in der tPickliste.
Also - ein zusätzlicher Index kann die INSERTS/UPDATES in einer Mehrbenutzerumgebung ziemlich negativ beeinflussen und ja - die SELECT-Abfrage wird beschleunigt.
Viele Grüße, Ihr mvh-Team