Zum Inhalt wechseln


Foto

Langsame Auswertungen im Live Betrieb "umgehen"


  • Bitte melde dich an um zu Antworten
9 Antworten in diesem Thema

#1 Harald_82

Harald_82

    Newbie

  • 2 Beiträge

 

Geschrieben 20. Dezember 2016 - 20:58

Hallo an Alle!

Bin neu im Forum und auch ziehmlich neu im Thema SQL. Aktuell stehe ich vor dem Problem, dass einer unserer Lieferanten meint, unser SQL Server bzw. die Datenbank wäre schuld daran das eine Auswertung im laufenden Betrieb das System fast zum Stillstand bringt. DB Größe, ca. 10 GB.

Vorschlag des Lieferanten, wir könnten die DB einfach spiegeln und wenn eine Auswertung ansteht, auf den Clients zur gespiegelen DB switchen und die Auswertung über diese (gespiegelte DB) laufen lassen. Dadurch, kann die live DB weiterhin befüllt werden und das System wird nicht so langsam, das man nicht mehr damit arbeiten könnte.

Jetzt meine Fragen zu dem Thema:

1. ist der Vorschlag sinnvoll und bringt er auch den gewünschten Erfolg? Also das das Programm flüssig weiter läuft, weil "nur" die gespiegelte Datenbank zur Auswertung herangezogen wird?
Ist es überhaupt möglich im laufenden Betrieb von der live- zur source-DB zu wechseln und wieder zurück?

2. Könnte man das Problem auch so lösen: Wenn eine "komplett-Auswertung ansteht, erstellen wir ein Backup der DB und die Verantwortlichen werten aus der Backup Datei aus? Ein paar Stunden Zeitunterschied sind egal. Geht das technisch und ist dies auch "normalen" PC Anwendern möglich?

3. Was wäre eine andere Lösung?

Unterm Strich noch folgende Infos: Die Analge rennt 365 Tage 24/7. Eine komplette Auswertung steht regelmäßig an, macht aber das Arbeiten mit dem System/der Analge für fast zwei Tage so gut wie unmöglich (Performance). Was kann man SQL mäßig hier machen?

Danke für die Hilfe!!

#2 magheinz

magheinz

    Newbie

  • 1.249 Beiträge

 

Geschrieben 20. Dezember 2016 - 21:07

Was gibts noch an infos?

Liegt die Datenbank auf einer Netapp und ist der Snapmanager im Einsatz kann man genau so etwas machen: DB clonen ohne echten Platzverbrauch (linked clone).

Das ganze geht dann tatsächlich per Knopfdruck.

 

Aber mal ganz zu Anfang: Wo liegt denn eigentlich das Performanceproblem? Eventuell könnte man ja auch den Host aufrüsten.



#3 Sanches

Sanches

    Newbie

  • 402 Beiträge

 

Geschrieben 20. Dezember 2016 - 21:22

Moin,

 

Magheinz hat es schon angedeutet - liefere doch mal ein paar Infos zur Umgebung.

 

Ist der Server virt. oder phys.?

Welche Ausstattung hat der Host?

Wie ist das Festplattenkonstrukt?

Welcher SQL Server ist im Einsatz? Welche Edition?

Wurde das Problem auf dem SQL Server bereits näher analysiert?

Sind die DB Parameter, Versionsabhängigkeiten, etc. vom Lieferanten beachtet worden?

...

 

Wenn der Lieferant behauptet, es läge am Server oder an der DB, dann hat er euch doch bestimmt mal eine kleine Analyse präsentiert z.B. bzgl. Reads and Writes in der DB während der Auswertung. Oder?

Wir hatten mal einen Fall, dort hat unser Lieferant auch behauptet, unser Server sei zu langsam (u.a. waren die CPUs ständig am Anschlag). Nach unserer(!) näheren Analyse wurde feststellt, das 2 Indexe fehlten.

Nachdem diese vorhanden waren, langweilte sich unser Server und die Software lief um einiges schneller.

 

Gruß Sebastian


Bearbeitet von Sanches, 20. Dezember 2016 - 21:23.


#4 MDD

MDD

    Newbie

  • 32 Beiträge

 

Geschrieben 21. Dezember 2016 - 08:14

Morgen,

 

was mich stutzig macht ist folgende Aussage:

 

Unterm Strich noch folgende Infos: Die Analge rennt 365 Tage 24/7. Eine komplette Auswertung steht regelmäßig an, macht aber das Arbeiten mit dem System/der Analge für fast zwei Tage so gut wie unmöglich (Performance). Was kann man SQL mäßig hier machen?

 

10 GB finde ich für eine DB nicht groß. Das man durch Auswertungen das System dadurch fast zum stehen bringt verwundert mich ein wenig. (Aber es fehlt noch einiges an Informationen über die Umgebung).

Durch deine Lösungswege 1 und 2 wirst du meines Erachtens in erster Linie Locking Problemen aus dem Weg gehen. Wenn die "neue" DB dazu noch auf einem anderen Rechner liegt wirst du möglicherweise auch Ressourcen-Engpässe verringern.

 

Ohne eine Analyse wo das Problem liegt wirst du aber vermutlich das falsche Problem lösen. Und das Thema Indexe ist, wie Sanches sagt, hier sicher ein wichtiger Ansatz. Genauso wie das Thema Wartung der Indexe; zu gern passiert es, dass diese aus irgendeinem Grund die Wartung auf einmal nicht mehr passiert und dann die besten Indexe nicht mehr verwendet werden können.

 

Gruß MDD


Wir finden für jede Lösung ein Problem

Man steckt immer in einem Sumpf voll Arbeit, nur die Tiefe ändert sich.


#5 NilsK

NilsK

    Expert Member

  • 11.950 Beiträge

 

Geschrieben 21. Dezember 2016 - 08:19

Moin,

 

wichtig wäre auch zu wissen, was die "Auswertung" denn überhaupt macht. Typische Kandidaten für schlechte Performance sind fehlende Indizes (oder fehlende Indexpflege, siehe den Beitrag von MDD) oder schlechte Abfragen, die sich gegenseitig blockieren.

 

Gruß, Nils


Bearbeitet von NilsK, 21. Dezember 2016 - 11:07.

Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#6 Doso

Doso

    Board Veteran

  • 2.316 Beiträge

 

Geschrieben 21. Dezember 2016 - 10:51

Ich befürchte da müsst ihr euch erst mal intensive mit dem Thema beschäftigen und rausfinden wo es genau hackt. Das geht zu weit als das man das über ein Forum lösen wird können. Mit dem Thema Auswertungen zu beschleunigen beschäftigt sich eine ganze Branche (ERP), da wird teilweise viel Geld investiert.

 

Es kann sein das die vorgeschlagene Lösung funktioniert. Kann aber auch sein das euer SQL Server total überlastet ist weil zu langsame Platten, zu wenig Speicher, schlecht gemachte Abfrage ohne ordentlichen Index und so. Das kann man nur raten. Es gibt entsprechende Tools beim SQL Server wo man das überwachen kann - muss man sich halt einarbeiten.

 

Wir haben eine Teststellung wo wir eine Sybase Datenbank per MSQ SQL Reporting Services abfragen. Da kam es auf den Syntax der Abfrage an ob es Stunden gelaufen ist oder nur wenige Minuten. Bei der einen Abfrage wurde der Index verwendet, bei der anderen nicht. Was bei einigen Millionen Einträgen einen großen Unterschied macht.



#7 Dunkelmann

Dunkelmann

    Expert Member

  • 1.860 Beiträge

 

Geschrieben 21. Dezember 2016 - 19:32

Moin,

 

Nils hat es schon beschrieben: Fehlende Indizes wäre auch mein erster Favorit.

10 GB ist keine Größe für eine DB, da muss der 'Wurm' woanders zu suchen sein.

 

Spiegeln dürfte das Problem nur dublizieren, jedoch nicht lösen ;)

 

Bei regelmäßig wiederkehrenden Abfragen würde ich, je nach Art und Umfang der Abfrage, über Views oder Analysis Services nachdenken.


Keep It Small - Keep It Simple


#8 Harald_82

Harald_82

    Newbie

  • 2 Beiträge

 

Geschrieben 22. Dezember 2016 - 08:18

Hallo!

 

Sorry für die späte Antwort.

 

Also, die DB bzw. SQL Server rennt auf einer VM. 16GB RAM 4 Core CPU. Was mittlerweile noch aufgefallen ist. Der Server selbst, langweilt sich lt. Task Manager während der Auswertung. Also die Hardware (wenn auch virtuell) kann es dann ja schon mal nicht sein oder?

 

Mit Indiezes kenne ich mich leider überaupt nicht aus. Anfang nächsten Jahres findet noch einmal ein Treffen mit der verantwortlichen Firma statt. Vlt. können wir ihnen dann klar machen, dass sie ihre DB selbst prüfen sollen, da ja unsere Hardware anscheinend ausreichend ist. 

 

Wie kann ich denn den Fragmentierungsgrad der DB sehen?



#9 magheinz

magheinz

    Newbie

  • 1.249 Beiträge

 

Geschrieben 22. Dezember 2016 - 09:54

die kiste langweilt sichsber hhoffentlich nicht weil die CPUs auf die Olatten warten?!

#10 Sunny61

Sunny61

    Expert Member

  • 21.887 Beiträge

 

Geschrieben 22. Dezember 2016 - 10:01

Wenn ihr an der Stelle kein KnowHow im Haus habt, dann müsst ihr euch jemanden holen, der das KnwoHow hat. Wenn der Hersteller der SW nicht weiter kommt, gibt es auch andere Spezialisten die helfen können.


Gruppenrichtlinien: http://www.gruppenrichtlinien.de/