Zum Inhalt wechseln


Foto

Verbindung eines ERP-Systems zu einer SQL Datenbank.

MS SQL

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

#31 zahni

zahni

    Expert Member

  • 16.389 Beiträge

 

Geschrieben 13. Mai 2015 - 05:37

Wie schon früher gesagt: Es kommt darauf an, was de Software mit de mit dem Server macht. Wir haben, bis auf wenige Ausnahmen, Client/Server Anwendungen.

Wenn User zum kommunizierten Termin nicht "aufhören", haben sie Pech und müssen mit ihren Vorgängen u.U. von vorn anfangen.

Ich habe auch neulich versehentlich den falschen SQL-Server neu gestartet (bei 7 DB2-Servern kommt man mal durcheinander)

Hat auch Keinen gejuckt. Will sagen: Die Anwendungen bauen die Verbindungen neu auf. Sicher kommen da ein paar Fehlermeldungen.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#32 Sunny61

Sunny61

    Expert Member

  • 22.098 Beiträge

 

Geschrieben 13. Mai 2015 - 08:02

Mittlerweile habe ich selbst den Einwicklern auch nochmals die "IsOpen" Funktion nahegelegt, um eventuelle kurze Verbindungssabbrüche abzufangen. Mir wurde dann nochmal gesagt, dass das angeblich nicht ginge, weil "IsOpen" angeblich nicht bemerken würde, dass die Verbindung weg war und sich damit die Frage nach dem Sinn der Funktion stellen würde, weil sie eigentlich nichts mache. Der Status "Datenbank geöffnet" verbleibe im Hauptspeicher, auch wenn die Verbindung weg ist. Getestet wurde es von den Leuten intern.


Probier es doch selbst aus, mit VB.Net ein Testprojekt aufbauen, einen kleine SQL Server als VM aufsetzen, schon kann es losgehen.
Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#33 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 13. Mai 2015 - 16:04

... Es kommt darauf an, was de Software mit de mit dem Server macht. Wir haben, bis auf wenige Ausnahmen, Client/Server Anwendungen.

 

Ich würde das ERP-System auch mal als Client/Server-Anwendung bezeichnen, weil der Server die Anforderungen der Clients bearbeitet.

 

 

Wenn User zum kommunizierten Termin nicht "aufhören", haben sie Pech und müssen mit ihren Vorgängen u.U. von vorn anfangen.

 

 

Mittlerweile sehe ich es ehrlich gesagt genau so. Es jedem Recht zu machen ist eine Kunst, die keiner kann. Ich probiere zwar den einwandfreien Betrieb der EDV zu gewährleisten, aber irgendwo ist dann auch Ende. Die User bekommen in der Regel meistens lange vorher bescheid, wann sie mit ihren Arbeiten fertig sein sollen.

 

 

Probier es doch selbst aus, mit VB.Net ein Testprojekt aufbauen, einen kleine SQL Server als VM aufsetzen, schon kann es losgehen.

 

Genau das wollte ich heute früh auch schon schreiben. Irgendwo habe ich mich dabei nur gefragt, ob das wirklich meine Aufgabe ist...

Eigentlich stelle ich nur die Infrastruktur bereit und kassiere zudem nicht Stundensätze von fast 100,-€.

Nichts desto trotz. Ich spiele mit dem Gedanken es ernsthaft zu tun, weil es mich auch interessiert.


Bearbeitet von willy-goergen, 13. Mai 2015 - 16:06.


#34 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 30. November 2015 - 19:20

Ich krame das Thema mal wieder heraus...

Zwischenzeitlich blieb es nicht aus, dass ich mich selbst damit auseinander setze.

 

Es sieht ein bisschen so aus, als würden sich die Performanceprobleme mit der ERP-Datenbank zuletzt ein bisschen verschärfen. Das äußert sich dadurch, dass bestimmte Abläufe, je weiter die Datenbank anwächst, länger dauern.

 

Sehr viel Erfahrungen habe ich ja nicht im Datenbankdesign, bzw. bei der Programmierung von Abfragen. Ich glaube aber, dass hier das Problem liegt. Ich werfe mal den fraglichen Standardquery in die Runde, der derzeit eine durchschnittliche Laufzeit von 13 Sekunden alleine auf dem Server hat.

 

Mit dieser Abfrage wird probiert aus mindestens 4 Millionen Ergebnissen das eine richtige zu bekommen.

SELECT * FROM [Arbplan] WHERE [firma]=@1 AND [apnr]=@2 AND [appos]>=@3

Man wählt quasi mal die Tabelle "Arbplan" an. Wenn ich die in ihrer Ganzheit abfrage, dauert das über eine Minute. Was ich bisher nicht verstehe ist wofür die Klammeraffen nach den Sucheinschränkungen stehen.



#35 NilsK

NilsK

    Expert Member

  • 12.332 Beiträge

 

Geschrieben 30. November 2015 - 20:50

Moin,

 

die Klammeraffen sind Variablen. Die werden wohl weiter oben im Code definiert.

 

Hast du schon mal den Indexerstellungs-Assistenten laufen lassen (oder wie der heißt)? Abfragen dieser Art sollten sich durch die passenden Indizes beschleunigen lassen.

Sofern die passenden Indizes existieren, könnte auch eine Indexoptimierung helfen.

 

Gruß, Nils


Nils Kaczenski

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

Kostenlosen Support gibt es nur im Forum, nicht privat!


#36 zahni

zahni

    Expert Member

  • 16.389 Beiträge

 

Geschrieben 01. Dezember 2015 - 09:10

Reorg durchführen und Statistiken aktualisieren (macht  man beim SQL-Server mit einem Wartungsplan), und wie Nils schrieb, mit dem Tuning Advisor einen Workload erfassen und passende Indizes generieren lassen.  https://technet.micr...v=sql.105).aspx


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#37 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 01. Dezember 2015 - 17:32

Danke für die Tipps. Ich hab mich heute auch selbst ein bisschen in das Thema eingelesen. Das mit dem Rebuild bzw. der Reorganisation der Indexe geht auf jeden Fall schon mal in die richtige Richtung. Ich hatte heute auch mal einen Rebuild an der o.g. Tabelle ausprobiert, weil der Index recht stark fragmentiert war. (irgendwas um die 40%)

 

Das hat auf jeden Fall schon mal eine spürbare Verbesserung gebracht. Die Laufzeit der obigen Abfrage hat sich von durchschnittlich ca. 13 Sekunden auf ungefähr drei Sekunden reduziert.

 

Das mit dem Tuning Advisor und dem Wartungsassistenten wäre an sich eine gute Idee, aber leider haben wir in der ganzen Firma nur SQL Express Datenbanken. Da gibt's weder das eine noch das andere. Eventuell wäre da mal eine Investition in eine "richtige" SQL Server Lizenz angebracht.

 

Im Moment bleibt mir meine ich eigentlich nur die eine Möglichkeit, die Reorganisation bzw. die Neuerstellung der Indexe mit einem per geplanten Task gestartetem Skript zu realisieren. Was das betrifft, bin ich noch am Überlegen und am Lesen.


Bearbeitet von willy-goergen, 01. Dezember 2015 - 17:34.


#38 NilsK

NilsK

    Expert Member

  • 12.332 Beiträge

 

Geschrieben 01. Dezember 2015 - 19:30

Moin,

 

ernsthaft jetzt? Ihr betreibt euer ERP auf SQL Express? Na, dann können wir uns ja jeden weiteren Aufwand sparen.

 

Dir ist schon klar, dass SQL Express absichtlich Leistungsgrenzen eingebaut hat, weil Microsoft schließlich mit seiner Datenbank Geld verdienen will?

Und dass es dafür keinen Support gibt - du im Fall des Falles also vielleicht einen freundlichen Gruß am anderen Ende der Leitung hörst, möglicherweise aber sogar schallendes Gelächter?

 

Ja, das solltest du ändern.

 

Gruß, Nils


  • DocData gefällt das

Nils Kaczenski

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

Kostenlosen Support gibt es nur im Forum, nicht privat!


#39 Sunny61

Sunny61

    Expert Member

  • 22.098 Beiträge

 

Geschrieben 01. Dezember 2015 - 21:48

Nebenbei bemerkt, ist die Abfrage wirklich exakt so produktiv? SELECT * FROM ist schon heftig. Der * ist das schlimme daran.

Wie wäre es mit einem Spezialisten vor Ort? Der macht mit dir einen Workshop und holt aus der DB/Instanz etwas mehr raus und Du lernst dazu. Gleichzeitig hast Du etwas für die Kommunikation mit dem Hersteller der DB in der Hand.
Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#40 magheinz

magheinz

    Newbie

  • 1.323 Beiträge

 

Geschrieben 01. Dezember 2015 - 22:20

Jetzt soll er auch noch programmieren lernen um den Dienstleuter zu erklären was der falsch macht?
Ganz im Ernst: weise ihm nach das es nicht am Netzwerk liegt und lass ihn sich kümmern. Im zweifel soll der Dienstleister nachweisen das es nicht an seiner Software liegt.

Ich habe übrigens lustige Erfahrungen gemacht in dem ich bei einem ähnlichen Fall einfach mal die IT-Leute anderer Kunden angerufen habe. Aus dem "überall sonst gehts" wurde schnell ein "alle Kunden haben das gleiche Problem".

#41 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 02. Dezember 2015 - 07:06

Moin,

 

...

ernsthaft jetzt? Ihr betreibt euer ERP auf SQL Express? Na, dann können wir uns ja jeden weiteren Aufwand sparen.

 

Dir ist schon klar, dass SQL Express absichtlich Leistungsgrenzen eingebaut hat, weil Microsoft schließlich mit seiner Datenbank Geld verdienen will?

...

 

Mir war bisher ein Teil der Beschränkungen bekannt gewesen, aber nicht alle. Nachdem ich mir das selbst angesehen habe, kann ich deinen Standpunkt nachvollziehen. Es ist gut möglich, dass durch die Beschränkungen in der eingesetzten Express Version (2008 R2) beim RAM und der CPU das ERP-System zusätzlich ausgebremst wird.

Das System wurde mir damals schon so vorgesetzt. Ich habe jetzt angefangen mich wieder damit auseinander zu setzen, weil in der letzten Zeit massiv Beschwerden über die Performance des ERP-Systems von den Kollegen kommen, die Entwickler selbst total ahnungslos zwecks der Ursache sind und schon seit einem Jahr ergebnislos an der Lösungsfindung arbeiten, bzw. es (gefühlt) ignorieren. Eigentlich müssten die wissen was los ist, weil sie das System inkl. DB installiert haben.

 

 

Nebenbei bemerkt, ist die Abfrage wirklich exakt so produktiv? SELECT * FROM ist schon heftig. Der * ist das schlimme daran.

Wie wäre es mit einem Spezialisten vor Ort? 

 

Das ist 1:1 das was ich aus dem Aktivitätsmonitor der betreffenden SQL-Server Instanz gezogen habe. Auf der Instanz läuft nur das ERP-System.

 

An einen Spezialisten bzw. der Hinzuziehung von externer Beratung denke ich schon eine ganze Weile nach, nicht nur wegen der SQL-Datenbank. Die wäre da nur ein weiterer Punkt, den ich mit ihm besprechen müsste. Meiner Meinung nach sollte da zumindest mal jemand mit über die IT drüber sehen, weil ich nicht glaube, dass alles so 100%ig optimal ist, auch wenn der Laden irgendwie läuft. Außerdem stößt die eingesetzte Technik teilweise in ein bis zwei Jahren absehbar an ihre Grenzen.

 

 

Ganz im Ernst: weise ihm nach das es nicht am Netzwerk liegt und lass ihn sich kümmern. Im zweifel soll der Dienstleister nachweisen das es nicht an seiner Software liegt.

 

Mit denen brauch ich darüber nicht zu reden. Die setzen mir noch einen zusätzlichen Server vor die Nase auf dem nur die Express Version der ERP SQL-DB läuft, weil sie der Meinung sind, das macht es dann besser. Hatte die Angelegenheit auch schon an den Chef gegeben gehabt. Aber so lange alles scheinbar läuft...

 

Grüße

 

Willy


Bearbeitet von willy-goergen, 02. Dezember 2015 - 07:35.


#42 Sunny61

Sunny61

    Expert Member

  • 22.098 Beiträge

 

Geschrieben 02. Dezember 2015 - 07:29

Mir war bisher ein Teil der Beschränkungen bekannt gewesen, aber nicht alle. Nachdem ich mir das selbst angesehen habe, kann ich deinen Standpunkt nachvollziehen. Es ist gut möglich, dass durch die Beschränkungen in der eingesetzten Express Version (2008 R2) beim RAM und der CPU das ERP-System zusätzlich ausgebremst wird.
Das System wurde mir damals schon so vorgesetzt. Ich habe jetzt angefangen mich damit auseinander zu setzen, weil ständig Beschwerden über die Performance von den Kollegen kommen, die Entwickler selbst total ahnungslos zwecks der Ursache sind und schon seit einem Jahr ergebnislos an der Lösungsfindung arbeiten, bzw. es (gefühlt) ignorieren.


Wenn so eine Abfrage aussieht, kann man sich schon ausrechnen warum es so langsam ist. Es ist sicherlich ein Teil die Express Variante, aber IMHO der größere Teil ist die Ahnungslosigkeit mit der an dem System 'gefummelt' wird. Und das fängt bei den Entwicklern der SW an.
 
 

Das ist 1:1 das was ich aus dem Aktivitätsmonitor der betreffenden SQL-Server Instanz gezogen habe. Auf der Instanz läuft nur das ERP-System.
 
An einen Spezialisten bzw. der Hinzuziehung von externer Beratung denke ich schon eine ganze Weile nach, nicht nur wegen der SQL-Datenbank. Die wäre da nur ein weiterer Punkt, den ich mit ihm besprechen müsste. Meiner Meinung nach sollte da zumindest mal jemand mit über die IT drüber sehen, weil ich nicht glaube, dass alles so 100%ig optimal ist, auch wenn der Laden irgendwie läuft.


Der SQL Server ist für sich ein sehr komplexes System, ein Spezialist dafür kann und sollte sich NUR auf den SQL beschränken. Und mit ein paar Handgriffen kann der Uwe Ricken so einiges rausholen und die Fehler der Entwicklern gleich dokumentieren. http://www.db-berater.de/
 

Mit denen brauch ich darüber nicht zu reden. Die setzen mir noch einen zusätzlichen Server vor die Nase auf dem nur die Express Version der ERP SQL-DB läuft, weil sie der Meinung sind, das macht es dann besser. Hatte die Angelegenheit auch schon an den Chef gegeben gehabt. Aber so lange alles scheinbar läuft...


Hol dir den Uwe, der schreibt dir auch einen passenden Bericht, den kannst Du dann bei dem Hersteller abgeben.
Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#43 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 02. Dezember 2015 - 18:03

Danke für den Tipp Sunny61! :)

 

Ich hab den Herrn Ricken heute per Mail kontaktiert, nachdem ich mir seine Homepage angesehen hatte. Er hat sich relativ zeitnah auf meine Anfrage gemeldet und schrieb, ich solle doch einfach mal anrufen. Mehr wurde dann heute allerdings nicht. Ich nehme mal an, er hatte noch andere Sachen zu tun und hatte deswegen sein Handy aus.

 

Mal sehen, was bei der Sache noch heraus kommt und ob er sich überhaupt so "armen Würstchen" wie wir es sind, annehmen will. Ich werde berichten. :)



#44 magheinz

magheinz

    Newbie

  • 1.323 Beiträge

 

Geschrieben 02. Dezember 2015 - 18:40

Letzte, unschöne Möglichkeit: geb deine Bedenken zu Protokoll. Schreib also einen Aktenvermerk und lass das vom Chef abzeichnen.

#45 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 02. Dezember 2015 - 19:16

Letzte, unschöne Möglichkeit: geb deine Bedenken zu Protokoll. Schreib also einen Aktenvermerk und lass das vom Chef abzeichnen.

 

Das ist finde ich die wirklich unschönste Möglichkeit zu probieren so ein ein Problem irgendwie zu "lösen" oder zur Sprache zu bringen. Sowas mach ich maximal mit Kollegen / Vorgesetzten die, wie in einem anderen Thema diskutiert, meiner Meinung nach eine nicht sehr ausgeprägte Sozialkompetenz haben. Und selbst da stellt sich die Frage, ob ich damit nicht total gegen die Wand laufe.

 

Ich weiß nicht wo du arbeitest, aber in Behörden / öffentlichen Einrichtungen macht man das wohl so. Für meinen Teil setze ich hinter so ein Vorgehen immer ein Fragezeichen, weil ich weiß wie das im schlechtesten Fall ausgeht.

 

Die Sache mit der externen Beratung hab ich heute mit meinem Chef abgestimmt. Wir waren uns diesbezüglich einig gewesen. Sofern da nichts anderes dagegen spricht, ist die Sache erst mal auf dem Weg. Nicht zuletzt hab ich auch den Schriftverkehr zwischen meinem AG und dem externen Dienstleister (den Hersteller des ERP-Systems) dokumentiert. Wenn da also Fragen aufkommen sollten...


Bearbeitet von willy-goergen, 02. Dezember 2015 - 19:35.




Auch mit einem oder mehreren der folgenden Tags versehen: MS SQL