SQL MSSQL2014 HW zu schwach oder schlecht programmiert?

[sikarr]

Was ist denn das Frontend? Weiterhin Access? Per ODBC angebunden?
Falls ja: Wurden dann die Sichten in Access belassen (Access-Abfragen) oder wurden die auf dem SQL-Server erzeugt? Access-Abfragen sind in so einem Szenario nämlich richtige Bremsanker.

Ich vermute, dass euer Freelancer leider nicht kompetent genug ist um die Performance-Probleme fachgerecht zu analysieren und dann die passenden Maßnahmen auszuwählen und umzusetzen....

Frontend ist Silverlight, ka wie das auf die DB zugreift, die Entscheidung dazu war vor meiner Zeit. Ich hätte mir ein Webfrontend oder ne schöne NC ähnliche Maske gewünscht.

Das mit der Kompetenz vermute ich leider auch, nur halte ich mich mit solchen Aussagen zurück da ich es selber nicht besser könnte

...
PS: Unsere CRM Datenbank ist (nach der Komprimierung vom Wartungsplan allerdings) als Backup-File gerade einmal knapp 500 MB Groß. Beinhaltet aber Millionen von Datensätzen und, wenn der SQL Server so läuft, belegt das Ganze fast 70GB RAM (von 128GB). Die reinen Größen sagen aber nichts über die Architektur oder gar über die Performance aus. Auch eine In Memory-DB kann langsam sein, wenn die Indizes nicht richtig genutzt werden können, weil eventuell keine passenden vorhanden sind.
...

Da sind wir jetzt dort wo mein Wissen von DBs endet. Was ich weis ist das wir damals Stück für Stück die alten Datensätze pro Kunde migriert haben, auch einige Designfehlentscheidungen des Altsystems wurden korrigiert was uns mehr Möglichkeiten für die Suche gab.

Vielleicht interessiert es ja wen:
Unser Lagersystem funktioniert so "Lagerort -> Kiste -> Akte". Aktuell haben wir so ca. 150.000 - 170.000 Kisten mit je 6 Aktenordnern darin, bei 150.000 Kartons gerechnet 900.000 Datensätze. Wobei das wohl eher ein Schätzwert ist da Kisten auch Hundert Akten oder nur eine enthalten können. Dazu kommen Auslagerungen und Vernichtungen. Die Datensätze werden bei Aktenvernichtung nur auf "Vernichtet" gesetzt und verbleiben in der Datenbank.

Mir ging es bloss um ein paar grundsätzliche Meinungen, da ich halt den Verdacht habe das das nicht sein kann. Vielleicht Zeig ich meinem Chef diesen Thread hier und er kann sich da auch mal mehr Gedanken drüber machen.

Ergänzung (9. Juni 2018)

Welche Version / Lizenz vom MS SQL Server habt ihr eigentlich? Falls ihr mit der Express Version herumgurgt schlagen div. Limitierungen zu:
https://en.wikipedia.org/wiki/SQL_Server_Express
....

2014 Standard glaub ich. Express auf jeden Fall nicht.

 

[ayngush]

Normalerweise halte ich mich, gerade im Internet, auch mit solchen Aussagen zurück. Ich kenne den Menschen ja nicht. Wenn ich jedoch lese, dass der Rat lautet, die Performanceprobleme einer Datenbankanwendung mit mehr Hardware zu erschlagen, dann habe ich da so meine berechtigten Zweifel, in Anbetracht der Tatsache, dass eure bestehende Hardware nicht schlecht ist und von den Rahmendaten her ausreichen muss.

Es mag ja sein, dass da einige Optimierungen der SQL-Server-Konfiguration bezüglich des Xenservers notwendig sind, um das ganze ordentlich zum laufen zu bekommen. Oder, dass da das Datenbankdesign nochmal angeschaut werden sollte. Aber bei beiden kann die Lösung nicht lauten: Baut halt mehr Hardware hin und ersetzt Server aus dem Jahr 2017 mit Servern aus dem Jahr 2018. Das ist irgendwo ganz grober Unfug.

Ein Ansatz wäre ja mal sich die nicht gut funktionierenden Stellen im Client anzuschauen, spezifisch die problematischen SQL-Statements heraus zu arbeiten und diese mal mit dem Ausführungsplan zusammen im Designer anzuschauen. Ich könnte beinahe eine Pfundswette darauf abschließen, dass da einfach ein Index fehlt und an irgend einer Stelle ein Full Table Scan stattfindet.

 

[PHuV]

Wie einige und ich hier schon sagten, holt Euch einen entsprechenden Profi bzw. IT-Dienstleister ins Haus, und laßt die Sache entsprechend analysieren.

Ich weiß ja nicht, wie Ihr so drauf seid, jedoch stelle ich immer wieder fest, daß diverse Mittelständler und Behörden dann doch die Sachen leider so schleifen lassen, weil Budget und Co. fehlt, oder die Vorgesetzten nicht einsehen wollen, daß man hier etwas Geld mit Beratungsleistung in die Hand nehmen muß.

Gute Leute und Experten bekommt man nun mal nicht für ein Appel und ein Ei.

 

[sikarr]

Kleines Update.

Nach dem sich die Performance nun auch auf andere VMs auswirkte haben wir hoffentlich den Übeltäter gefunden. Auf einem Node hat sich einer der Storagecontroller wohl verabschiedet. Nun liefen unsere 3 Stärksten IO-Lastigen VMs auf dem selben Node mit defekten Controller, was die Zugriffszeiten auf das Storage in die Höhe trieb.

Ein verschieben der VMs auf den anderen Node brachte Abhilfe, nächste Woche werden wir die SQL-VM wieder Online bringen in der Hoffnung das es auch das war.

Update: BBU des Controllers war defekt, Controller hat dadurch ohne Cache gearbeitet.

Kann geschlossen werden.

 

[PHuV]

Danke fürs Feedback. Da sieht man mal wieder, man muß das doch entsprechend vor Ort analysieren, und gut gemeinte Forenratschläge bringen meisten nichts, weil schlichtweg Infos fehlen. Gerade Hardwareumgebungen bieten auch - wie bei Euch zu sehen ist - eine enorme Fehlerquelle.