SQL Anwendung läuft langsam

[BWendle 3]

Guten Tag Zusammen,

 

ich hoffe ihr könnt mir bei meinem bestehenden Problem aushelfen.

 

Wir betreiben unsere Etikettensoftware NiceLabel auf einem eigenständigen Server mit folgender Konfiguration.

 

Windows Server 2016 Standard 10 x-64

Intel Xeon God 6142 CPU 2,6Ghz, 2594 Mhz, 2 Core Prozessor

Installierter physical Memory 8 GB

Verfügbarer physical Memory 3,54 GB

Total virtual Memory 9,25 GB

Verfügbarer virtual Memory 4,5 GB

Festplatte C: 50 GB / 12 GB frei

Festplatte D: 30 GB / 11 GB frei (Software installiert)

 

Microsoft SQL Server 2017 Express 14.0.3465 (64-bit)

 

Software NiceLabel

- NiceLabel Print (lokal installierte Anwendung an jedem PC)

- NiceLabel Control Center (=Dokumetenspeicher) (webbasierte Anwendung auf Server installiert)

 

 

Seit 2 Wochen haben wir plötzlich das Problem, dass die Anwendung (NL Print) nur mit unzumutbaren Ladezeiten in den Produktionen läuft.

Dabei bestehen Momente, in der die Anwendung schnell die Abfragen verarbeitet (5-10 Sekunden) aber bei den nächsten Abfragen die Wartezeiten zwischen ca. 45 Sekunden bis über 3 Minuten sind.

 

Die Anwendung wird maximal von 3 Arbeitsplätzen verwendet und auf die Daten auf dem Server zugreifen.

 

Auch die webbasierte Anwendung kann erst nach einer sehr langen Wartezeit von mehreren Minuten aufgerufen werden.

 

Auch wenn die webbasierte Anwendung direkt auf dem Server aufgerufen wird, ist die Seite ebenfalls erst nach mehreren Minuten geladen.

Beim Neustart des Servers oder der Dienste (sowohl Task Manager als auch SQL Server Configurations Manager) waren die Ladezeiten nur wieder kurzfristig normal bevor wieder die langen Ladezeiten  bestehen.

 

Bei der Überprüfung der CPU- und Speicherauslastung gab es jetzt keine gravierenden Unstimmigkeiten.

Die CPU hat eine Auslastung von Ø3-5% und der Speicher standardmäßig um ca. 50%. 

 

Was mir bei der SQL-Datenbank der Software auffällt, ist das diese fast 8,5 GB groß ist aber beim auslesen der Datenvolumen der enthaltenen Tabellen, diese gesamt nicht mal 200 MB umfassen. Auch ist mir das hohe Datenvolumen der Transaktionsprotokolle aufgefallen. Hier habe ich schon ein vollständiges Backup der DB durchgeführt.

 

Könnt ihr mir noch Tipps geben, wodurch die Performance wieder verbessert wird.

An den Einstellungen wurden keine Änderungen vorgenommen außer reguläre Systemupdates wurden durchgeführt.

 

Beim Auslesen  des Ereignisprotokolls werden jeweils ein ID-Fehler in der Applikation und im System wiederkehrend aufgeführt:

- Applikation: 1008

- System : 10016 

 

Ich bin mir schon fast am überlegen, daß System auf einem neuen Server mit folgender groben Konfiguration neu aufzusetzen und den bestehenden damit zu ersetzen:

 

Microsoft SQL Server 2019

Microsoft SQL Server 2017

Webbasierte Anwendung mit HTTPS-Unterstützung

 

Zudem würde ich die standardmäßige Einstellung beim Server-Backup von full auf simple umstellen.

 

Wie ich dabei die DB am Besten auf den neuen Server "umziehe" weiß ich nicht, welcher Weg wäre da am Besten aus eurer Sicht?

 

- Bei Backup / Restore bin ich mir nicht sicher, ob ich Datenmüll und ggf. unsaubere Berechtigungseinstellungen übernehmen würde.

- Bei Skript generieren bin ich mir wieder nicht sicher, welche Daten ich zwingend übernehmen muss, damit das System fehlerfrei läuft.

- Datenbank exportieren / importieren

 

 

Auch den Support von NiceLabel habe ich schon um Hilfe gebeten aber hier wird in erster Linie der Verdacht auf "veraltete Hardware" geschoben und empfohlen ein Softwareupdate durchzuführen.

 

Gibt es eine Möglichkeit mit Boardsystemen um zu überprüfen, ob die Serverhardware und Systemeinstellungen (z.B. IIS) fehlerfrei funktionieren oder hier ein "Flaschenhals" besteht? Ich finde es wirklich seltsam, dass das System zeitweise normal läuft aber die meiste Zeit einfach langsam ist....

 

Über Hilfe und Vorschläge zur Lösungsfindung oder ggf. um einen neuen Server optimal neu aufzusetzen würde ich mich sehr freuen und Bedanke mich schon jetzt dafür.

Gebt mir gerne Bescheid, falls ihr detailliertere Informationen benötigt. Versuche diese schnellstmöglich nachzureichen.

 

Vielen herzlichen Dank

 

Mit freundlichen Grüßen

Bernd

 

 

 

 

[Sunny61 773]

Bezüglich der Größe der Transaktionsprotokolle kannst Du diesen Artikel lesen und umsetzen. https://www.faq-o-matic.net/2014/08/27/sql-server-transaktionsprotokoll-verkleinern/

Wie geschrieben steht, kann man das auch mehrmals machen müssen, dann sollte es aber Wirkung zeigen. Anschließend am besten einen Job einrichten, der das regelmässig macht.

 

Bezüglich der Performance ist es aus der Ferne schwierig, was Du aber machen kannst, ist das SQL Server Management Studio starten, oben auf die Instanz mit rechts klicken und im Kontextmenü Berichte und dann das Leistungsdashboard anwählen. Ziemlich weit unten gibt es den Eintrag Fehlende Indizes, dort drauf klicken. Gibt es dort fehlende Indizes? Wenn ja, kannst Du, nach einer ordentlichen Sicherung und nur mit Rücksprache des Datenbank Herstellers, die dort gen. Statements ausführen. Es sollte sich positiv bemerkbar machen.

[BWendle 3]

Hallo Sunny61,

 

vielen Dank für deine schnelle Hilfe zu meinem Problem.

 

Bezüglich den Transaktionsprotokollen hatte ich eigentlich alles schon durchgeführt, wie in dem Artikel beschrieben nur den Verkleinerungsprozess hatte ich nicht sofort umgesetzt. Dies habe ich jetzt nachgeholt und jetzt wird mir bei Transaction Log Space Reserved nur noch 50 MB angezeigt.

 

Meiner Meinung nach kann ich dafür leider kein Job einrichten, da mir bei der SQL Express-Version der JobAgent nicht zur Verfügung steht.

 

Wegen den fehlenden Indizes habe ich auch gleich mal geschaut und hier werden mir 5 Stück angezeigt.

Diese Information werde ich gleich mal an den Hersteller weiterleiten und mal schauen, ob wir dies optimieren können.

 

Vielen herzlichen Dank für deine Tipps.

 

Sobald ich hier weitere Informationen habe, werde ich dies posten.

 

Mit freundlichen Grüßen

Bernd

[Dukel 436]

Wird von dem Server ein regelmäßiges Transaktionslog Backup gemacht? Damit sollte das T-Log klein bleiben und es sollte kein Shrink Job notwendig sein.

 

Evtl. wäre auch zu überlegen, ob man den Modus auf Simple stellt, dann muss man sich nicht um T-Log kümmern.

[Nobbyaushb 1.359]

Moin,

 

läuft das auf Physik oder einer VM?

Was mich stört:

vor einer Stunde schrieb BWendle:

 

Windows Server 2016 Standard 10 x-64

Intel Xeon God 6142 CPU 2,6Ghz, 2594 Mhz, 2 Core Prozessor

Installierter physical Memory 8 GB

Verfügbarer physical Memory 3,54 GB

Total virtual Memory 9,25 GB

Verfügbarer virtual Memory 4,5 GB

Festplatte C: 50 GB / 12 GB frei

Festplatte D: 30 GB / 11 GB frei (Software installiert)

Warum hat der nur 8GB RAM? - wie man sieht, werden über 9GB auf Disk ausgelagert

Wird kein aktuelles OS unterstützt, Server 2022?

Die Platten finde ich extrem klein - was sind das? (siehe erste Frage...)

 

Und dann würde ich auch einen aktuellen SQL verwenden, wenn man das schon mal umziehen möchte

Natürlcih nur mit dem Hersteller-Support

Ggf. kann sich auch der Kauf eines SQL rechnen, wenn man Arbeitszeit gegenrechnet (ja, muss man...)

Die Vollversionen haben nicht die Einschränkungen von der kostenlosen Express-Version

 

 

PS: ich denke, das ist ein Gold-Xeon, alleine daher gehe ich von VM aus..
Trotzdem wäre es schön schön zu wissen, welcher Hyper-Visor und was für Platten in dem Host sind

[Sunny61 773]

vor 22 Minuten schrieb BWendle:

Meiner Meinung nach kann ich dafür leider kein Job einrichten, da mir bei der SQL Express-Version der JobAgent nicht zur Verfügung steht.

In der Express Variante muss man mit Batch und der Aufgabenplanung von Windows regelmässige Jobs erstellen. Hier ist ein Beispiel: https://www.aspicon.de/news/zeitgesteuerte-aufgaben-ohne-sql-server-agent-ausloesen/

Du kannst auch aus der Aufgabenplanung von Windows eine Batch aufrufen, die ein SQL Script ausführt:

 

REM sqlcmd -S <ComputerName>\<InstanceName> -i <MyScript.sql>

cd "C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn"

sqlcmd.exe -S "deinSQL\deineInstanz" -i "Pfad_zurPro.sql"

 

Die sqlcmd.exe wirst Du vermutlich vorher installieren müssen und dann hier den Pfad dorthin anpassen. Der Rest sollte verständlich sein, wenn Du die Standardinstanz in Verwendung hast, dann reicht IMHO der SQL Server ohne Instanznamen.

 

In diesem Beispiel wird noch mehr angeboten, falls Du Mails bekommen möchtest: https://codekabinett.com/rdumps.php?Lang=1&targetDoc=sql-server-express-backup-automatisieren

[t-sql 17]

Am 7.12.2023 um 16:01 schrieb Nobbyaushb:

Moin,

 

läuft das auf Physik oder einer VM?

Was mich stört:

Warum hat der nur 8GB RAM? - wie man sieht, werden über 9GB auf Disk ausgelagert

Wird kein aktuelles OS unterstützt, Server 2022?

Die Platten finde ich extrem klein - was sind das? (siehe erste Frage...)

 

Und dann würde ich auch einen aktuellen SQL verwenden, wenn man das schon mal umziehen möchte

Natürlcih nur mit dem Hersteller-Support

Ggf. kann sich auch der Kauf eines SQL rechnen, wenn man Arbeitszeit gegenrechnet (ja, muss man...)

Die Vollversionen haben nicht die Einschränkungen von der kostenlosen Express-Version

 

 

Leider völlig am Thema vorbei. Für eine DB die kein Gigabyte groß ist reichen 8 GB völligst aus. Für was sollen die Platten größer sein? Brauchen die nicht. Vollversion SQL Server ist bei der Anwendung auch völlig überzogen.

 

Am 7.12.2023 um 14:38 schrieb BWendle:

Was mir bei der SQL-Datenbank der Software auffällt, ist das diese fast 8,5 GB groß ist aber beim auslesen der Datenvolumen der enthaltenen Tabellen, diese gesamt nicht mal 200 MB umfassen. Auch ist mir das hohe Datenvolumen der Transaktionsprotokolle aufgefallen. Hier habe ich schon ein vollständiges Backup der DB durchgeführt.

 

 

Das Transactionlog wird durch eine Vollsicherung nicht geleert. Ein gängiger Irrglaube.

 

Am 7.12.2023 um 15:45 schrieb Dukel:

Evtl. wäre auch zu überlegen, ob man den Modus auf Simple stellt, dann muss man sich nicht um T-Log kümmern.

Das stimmt nur bedingt. Wenn eine Transaktion aktiv ist und lange läuft platzt dir auch bei Simple Mode das Transactionlog.

 

@BWendle Schau bitte in das Errorlog deines SQL Servers nach. Da könnte was drin stehen. 

[Nobbyaushb 1.359]

vor 2 Minuten schrieb t-sql:

Leider völlig am Thema vorbei. Für eine DB die kein Gigabyte groß ist reichen 8 GB völligst aus. Für was sollen die Platten größer sein? Brauchen die nicht. Vollversion SQL Server ist bei der Anwendung auch völlig überzogen.. 

Sehe ich anders, aber das will ich nicht diskutieren und gehört hier auch nicht hin 

Irgendwas muss dann aber trotzdem sein stimmen, sonst würde das OS nicht über 9G auf die Platte legen 

 

[NilsK 2.785]

Moin @t-sql,

 

wir glauben dir alle, dass du sehr großes Fachwissen zum SQL Server hast. Möchtest du hier nun auch etwas Konstruktives beitragen, oder geht es dir nur darum zu zeigen, dass du es besser weißt? Wenn die Experten sich gegenseitig niedermachen, ist dem TO ja nicht geholfen.

 

Gruß, Nils

 

[BWendle 3]

Hallo Zusammen,

 

vielen herzlichen Dank für die vielen Anregungen.

 

Bei meiner weiteren Überprüfung, um den Fehler identifizieren zu können, sind mir noch folgende Punkte aufgefallen:

 

1. Wenn ich im IIS die Webseite der Anwendung auswähle und die Authentication-Einstellungen aufrufe, erhalte ich eine Fehlermeldung, dass in der web.config ein Error besteht.

2. Bei der Überprüfung der Serverinstanz auf fehlende Indexe, werden 5 fehlende Indexe ebenfalls der Anwendung betreffend aufgeführt.

 

Rückmeldung seitens dem Hersteller Support ist, dass es sich um ein sehr seltsames Verhalten handelt und mir empfohlen wird die Anwendung neu zu installieren.

 

3. Habe ich mal die Systemanforderung der Software/Anwendung überprüft (siehe Anhang der Gegenüberstellung). Hier ist mir wiederum aufgefallen, daß mein System aktuell mehr oder weniger die Mindestanforderung der Software leistet.

Bei der Systemanforderung steht bezügl. der Mindestanforderung, dass diese ausreicht, um "einfache" Ausdrucke zu tätigen und wenn sonst keine weiteren Anwendungen auf dem System ausgeführt werden. 

Bei der empfohlenen Anforderung steht, dass diese notwendig ist, wenn mehrere Drucker verwendet werden und große Mengen an Etiketten ausgedruckt werden.

 

Dazu kann ich sagen, das auf dem System selber nur diese Anwendung grundlegend läuft, wenn man die systemseitigen Anwendungen wie Systemupdate und Virenschutzüberwachung, etc. außer acht lässt.

Die Anwendung selber kann im worse case an vier Arbeitsplätzen zeitgleich in Verwendung sein und mind. an 3 unterschiedlichen Druckern ein Etikettendruck gestartet werden.

Eine große Menge an Etiketten wird auf jeden Fall über die Anwendung ausgedruckt.

 

Was mir bei den Druckmasken sehr stark auffällt ist, das der Ladeprozess hauptsächlich bei den Dateneingaben lange dauert, bei denen es sich nicht nur um reine Eingaben handelt, sondern beim System eine "kleine" Abfrage generiert wird.

Wir haben z.B. für unsere Produkte jeweils eine separate Datei angelegt, die wiederum alle Produktvarianten der Produkte enthalten. Zudem gibt es noch weitere separate Produktdateien für länderspez. Anforderungen.

 

Bei der Eingabe der Etiketten-Nr. (= individuell ausgedrucktes Etikett) wird beim System abgefragt, welche Etikettendatei abgerufen werden muss. Genau diese Abfrage kann bis zu mehreren Minuten dauern.

Bei einer weiteren Eingabe der Mitarbeiter-ID wird der entsprechende Mitarbeiter abgefragt. Diese Abfrage erfolgt wiederum zentral in der Druckmaske über eine hinterlegte VbScribt-Abfrage mit einer wenn-dann-Funktion.

Bei dieser Abfrage müssen nur 8 mögliche ID-Nr. überprüft werden aber auch diese Abfrage kann bis zu einer Minute dauern?!

 

Eigentlich sehe ich das System vom Umfang her für diese Anwendung, wie T-SQL auch, völlig ausreichend aber mit dem Fehler mit dem unzumutbaren Ladeprozess, habe ich entweder ein Systemfehler oder den Arbeitsspeicher in Verdacht. 

 

Außerdem, da es sich um einen sehr wichtigen Prozess handelt, würde ich trotzdem eine Umstellung auf eine kostenpflichtige SQL Server in Betracht ziehen.

 

Jetzt wäre nur noch die Überlegung, wie diese Neuinstallation während dem laufenden Prozess am Besten umgesetzt werden kann und ob das Update des Arbeitsspeichers ggf. auch erst im Nachgang falls notwendig durchgeführt werden könnte.

 

Hier habe ich mal eine Anfrage bei unserer IT gestartet.

 

Vielen Dank für eure weiteren Rückmeldungen.

 

Mit freundlichen Grüßen

Bernd

 

 

 

Übersicht_Systemanforderung_NiceLabel.pdf

[Nobbyaushb 1.359]

Moin,

danke für deine ausführliche und aufschlußreiche Antwort

Mir selber fehlt nur einess - ist das eine VM?

Wenn ja, was für ein Hyper-Visor?

[NilsK 2.785]

Moin,

 

ich danke auch für die Beschreibung. Was ich vor allem daraus lese: Anscheinend geht es um eine durchaus komplexe Anwendung, die aus mehreren Komponenten besteht. Von denen ist die Datenbank offenbar nur eine. Verzögerungen der genannten Art können an mehreren Stellen in diesem Aufbau auftreten und sich durchaus auch summieren. Simpel gesprochen: Es kann ja auch durchaus sein, dass die Webanwendung schlecht gebaut ist. Und wer weiß, auf welche Hindernisse das genannte VBScript stößt ...

Einfache Antworten würde ich hier also eher nicht erwarten, und es ist sicher sinnvoll, den Hersteller einzubinden.

 

Was die Datenbank selbst angeht: Auf mehrere mögliche Engpässe bist du ja schon gestoßen. Denen würde ich nun erst mal nachgehen. Meine Vermutung ist aber, dass das die Probleme noch nicht löst, sondern nur einzelne Auswirkungen lindert.

 

Gruß, Nils

 

bearbeitet 14. Dezember 2023 von NilsK

[BWendle 3]

Hallo Nobbyaushb,

 

stimmt, deine Fragen waren noch ausstehend, die ich noch beantworten wollte. 

 

Anbei habe mal im Anhang die System Information. Wie du richtig vermutest, handelt es sich um eine VM und eine Gold-Xeon.

 

Wegen dem Hyper-Visor habe ich jetzt nur die Information (siehe ganz unten) finden können.

 

Ich hoffe mit den Informationen kann ich deine Fragen beantworten.

 

Gruß Bernd.

[mwiederkehr 351]

Die teilweise extrem langen Zeiten deuten eher auf ein Timeout als eine lange laufende Abfrage hin.

 

Ich würde während der Wartezeit die Systeme beobachten: Auf welchem Server wird CPU-Zeit verbraucht? Von welchem Prozess? Der SQL Server Profiler zeigt Anfragen und deren Laufzeiten an. Das Performance Dashboard des SQL Server Management Studios zeigt die am längsten laufenden Abfragen an: https://learn.microsoft.com/en-us/sql/relational-databases/performance/performance-dashboard?view=sql-server-ver16

 

Da die Wartezeit nicht immer gleich hoch ist, würde ich auch ein Augenmerk auf die GUI legen. Ist es jeweils beim ersten Aufruf langsam oder immer, wenn man im geöffneten Formular etwas ändert? Besonders Anwendungen mit moderner GUI (WPF) können Effekte zeigen, die wie langsame Datenbank-Abfragen aussehen. Einmal hat ein Kunde sich beschwert, dass das Ausklappen des Dropdowns mit der Projektliste fast eine halbe Minute dauere. Das war nicht wie vermutet die Datenbank, sondern der Client war diese Zeit auf 100 % CPU und die Ursache war das Laden vieler Elemente ins Dropdown. Beim zweiten Klick ging das Dropdown sofort auf. Aber nicht, weil die Projekte nicht nochmals von der Datenbank abgerufen werden mussten, sondern weil sie schon als GUI-Elemente im RAM vorhanden waren.

[BWendle 3]

Hallo mwiederkehr,

 

bei jedem Druckprozess müssen folgenden Eingaben in der Druckmaske eingetragen werden, damit der Etikettendruck gestartet werden kann:

 

- Etiketten-Nr. (= Abfrage der notwendigen Etikettendatei mit den fixen Daten) -> sehr hohe Ladezeit

- Chargen-Nr. (= reine variable Eingabe in die Etikettendatei) -> keine Ladezeit

- Produktionsdatum (= siehe Chargen-Nr.) -> keine Ladezeit

- Druckmenge (= siehe Chargen-Nr.) -> keine Ladezeit

- Mitarbeiter-ID (= VbScript-Abfrage mit wenn-dann-Funktion) -> kurze/ mittlere Ladezeit

 

Wenn nach der Etiketten-Nr. zu früh die Chargen-Nr. eingegeben wird (Barcode abscannen), kann es passieren, dass die Ladezeit noch länger dauert oder die Anwendung abstürzt.

 

Die Anwendung wird nach dem Etikettendruck nicht neu gestartet, sondern nach dem Etikettendruck erfolgt eine autom. Löschung der Eingaben (ebenfalls in der Anwendung über VbScript).

Ps.: Die Anwendung unterstützt aktiv die VbScript-Programmierung

 

Dabei kommt es eben vor, dass der Druckprozess "normal" mit einer kurzen Wartezeit von unter 1 Minute erfolgen kann aber plötzlich bei den nächsten Druckprozessen wieder erst nach über 5 Minuten erfolgt. Wir haben eben mit hohen aber auch schwankenden Ladezeiten zu kämpfen.

 

Das Performance Dashboard hatte ich mir schon mal vor einigen Tagen angeschaut als ich die Serverinstanz auf fehlenden Indexe überprüft habe.

 

Was mir heute dabei aufgefallen ist, ist dass das System vor einigen Tagen 5 fehlende Indexe aufgeführt hatte und heute werden sogar 11 fehlende Indexe aufgelistet.

 

Zudem habe ich mal im Anhang die Informationen aus dem Dashboard gezogen.

Dabei ist wieder ersichtlich, dass die CPU überhaupt nicht ausgelastet ist aber das System bei einigen Prozessen hohe Wartezeiten aufweist.

Welche Prozesse das im Detail jetzt wirklich sind, kann ich nicht genau sehen aber würde sagen, die meisten die Software-DB "NiceAN" betrifft, auf der eben alle Dokumente und Dateien für den Etikettendruck abliegen und auch die webbasierte Anwendung zugreift. 

 

Mit freundlichen Grüßen

Bernd. 

 

 

SQL Server Performance Dashboard.pdf