Performance nach SR v. 31.03.

[#1]

Hallo,

nachdem ich vom DATEV-Service keine befriedigende oder gar nachvollziehbare Antwort erhalte - an dieser Stelle eine Kurze Nachfrage in die Runde:

Seit der Installation des Service-Release vom 31.03.2017 am 01.04. sinkt die Performance der DATEV-Programme täglich um 12:00 Uhr auf Werte die miserabel sind.  Die Performance war so miserabel, dass sich alle Programme samt DATEV-Arbeitsplatz ins Nirvanna verabschiedet haben.

Bei uns wird im 12:00 Uhr über den DATEV-SQL-Manager eine Sicherung der Datenbanken angestoßen.  Diese Sicherung hat bis 30.03. zu keinerlei spürbaren Performance-Einbußen geführt.

Tritt das Verhalten in anderen Kanzleien auch auf?

Danke für die Rückäußerung.

Andreas G. Müller

NS.: Bitte keine Hinweise auf die Performance-Verbesserung mit Systemnahen Lösungen.  Das System war mehr als zufriedenstellend Lauffähig.  Die Probleme müssen aus meine Sicht mit dem SR zusammenhängen.

[#2]

Ist das System denn wieder "mehr als zufriedenstellend Lauffähig" wenn der Task im SQL Manager deaktiviert wird?

Bzw. in der Aufgabenplanung einfach mal ausgesetzt wird.

Ansonsten vielleicht mal die "Native Images" von Hand anstoßen und bauen lassen.

[#3]

Das System läuft nachdem die Sicherung angestoßen wird wieder "zufriedenstellend" (schneller geht immer).

Nach einer Woche Einsatz des SR sollten alle Native Images erstellt sein.  Zumal deren Erstellung nach dem Start manuell angestoßen wurde.

[#4]

Hallo Herr Müller,

liegts evtl. an den  Anwalts-SRs? Oder haben Sie auch andere (KA-Rewe) Programme im Einsatz?

[#5]

Hallo Herr Hofmeister,

Die Anwalts SR hatte ich zunächst auch im Verdacht - Sorry an die Entwicklung. Allerdings müssten die Performanceprobleme dann über den ganzen Tag verteilt auftreten.  Tatsächlich aber kann ich fast die Uhr danach stellen; jeden Tag um 12:00 Uhr und nach ca. 2-3 Minuten läuft wieder alles normal, gerade so als ob nichts gewesen sei.  Die einzige Besonderheit zu dieser Zeit ist der Start der Datensicherung.

[#6]

Welche Form der Datensicherung haben Sie?

Warum mittags um 12 Uhr und nicht abends um 18 Uhr  (nur mal so gefragt..?)

[#7]

.. das habe ich mich auch gefragt ... wenn um 12 Uhr allgemeine Mittagspause wäre, würde es ja keiner merken:-)

[#8]

...und haben Sie sie testweise schon mal ausgestellt/verschoben um zu schauen, ob diese den Performance-Einbruch auslöst?

[#9]

Die Datenbanksicherung die sich im DATEV-SQL-Manager Skript gesteuert einstellen lässt (vgl. Prüfung und Sicherung von Microsoft-SQL-Datenbanken mit dem DATEV SQL-Manager)​. 

Die Uhrzeit war mit dem Gedanken der Mittagspause und der geringeren Serverlast so gewählt.  Dennoch soll es vorkommen, dass auch während andere Mittagspause machen gearbeitet werden muss; oder später Mittag gemacht wird.  Auch ich mache lieber später meine Mittagspause.  Daher kann ich auch das Systemverhalten im "Betrieb" recht zuverlässig einschätzen.

Um die Sicherung zu einem späteren/andern Zeitpunkt durchführen zu können, müsste etwas mehr als nur das Datensicherungskonzept umgestellt werden; (manches mal wünsche ich mir ich hätte mich nicht zu einem Client-Server-System überreden lassen und das alte P2P System beibehalten. Das hätte mir mehr als nur eine schlaflose Nacht und eine Menge Ärger erspart).

Den Beiträgen entnehme ich, dass das Phänomen nicht bekannt ist, so dass ich weiter Suche muss.

Danke für die Gedanken und Tipps

[#10]

Doch, nachdem Sie nun mitgeteilt haben, dass das der SQL-Check mit SQL-Sicherung ist:

auf unserem alten Server konnte ich das auch nachvollziehen. War aber ein rel. betagtes System. Dort lief diese Sicherung auch immer (erst) abends.

Aber auch während dieser Sicherung kam es zu den von Ihnen beschriebenen Effekten.

Dieses Phänomene haben wir auf dem neuen System dann überhaupt nicht mehr. Da laufen dann auch mehrere Sicherungen nebeneinander. Ohne diese Auffälligkeiten.

[#11]

Ich hoffe doch, dass ein im Dezember 2015 angeschaffter Server noch nicht zum alten Eisen gehört.

[#12]

Moin,

das ist durch die gewählte Technik ein ganz normales Verhalten. Je nachdem wie der SQL-Server gerade genutzt wird, sind die offenen Daten evtl.recht umfangreich und der für die Datensicherung genutzte Vorgang dauert etwas länger. Versuchen Sie einmal den Sicherungspfad auf ein anderes physikalisches Laufwerk zu legen. Gerade bei RAID 5 und größer kann es zu "Staus" bei den IO Operationen kommen.

Gruß

KP

[#13]

Hallo Herr Müller,

die SRs sollten ein derartiges Verhalten eigentlich nicht verursachen. Eventuell hilft ein kurzer Blick auf die Konfiguration Ihres Systems via Fernbetreuung. Sie können mich hierzu gerne per Mail kontaktieren: christian.deuerlein@datev.de

Schöne Grüße

Christian Deuerlein

[#14]

Hallo Herr Deuerlein,

Danke für das Angebot.

Richtig ist, ein SR sollte ein derartiges Programmverhalten nicht auslösen; zumal lediglich drei Programmpakete (Anwalt classic, Rechnungswesen und Basis Wirtschaftsberatung), bereitgestellt und installiert wurden; Programmpakete die noch nicht einmal auf dem Server laufen.

[#15 · Accepted solution]

Hallo Herr Müller,

hier noch einige Ansätze zur Eingrenzung:

Prüfen Sie in der Historie der Datenbankprüfungen (SQL-Manager > Kontextmenü des Servers > ERgebnisdatei DB-Prüfung anzeigen) die Laufzeiten. Es werden dort alle Vorgänge seit der Installation des Systems angezeigt.

Hat sich die Laufzeit der Prüfungen/Sicherungen eventuell verändert?

Wieviel Zeit wird aktuell für den Vorgang benötigt?

Liegt eventuell ein Engpass im Bereich des Storage-Systems vor?

Dies kann z. B. mit dem Passmark Performance Test festegestellt werden (www.passmark.com). Am Server installieren und den Test "Disk" laufen lassen. Die Werte bei Lesen/Schreiben/Random sollten bei einem lokalen RAID > 300 - 500 MB/Sekunde liegen.

Alternativ kann ich Ihnen eine Analyse durch unser Tool Perfalyser anbieten. Sie können sich dies hier herunterladen, am Server entpacken und dort mit _start.cmd installieren (Standardwerte der Abfragen beibehalten). Das Tool protokolliert dann nach C:\perflogs\Messung. Diesen Ordnder können Sie mir gepackt nach 2 - 3 Tagen zukommen lassen, ich werte die Daten dann aus. Kosten entstehen für Sie nicht.

https://go.datev.de/uta/

Benutzername:

bJrVxSVX

Passwort:

46JF3pde

[#16]

Es soll irgend jemand die Technik verstehen.  Das Problem wurde, Dank der Unterstützung durch Herrn Deuerlein gelöst.  Ich hätte nicht erwartet, dass ein zwei Jahre alter/junger Server solche Schwierigkeiten bereiten kann.

Danke nochmals.

[#17]

Interessehalber, wer war der Übeltäter?

[#18]

der fehlende Schreibcache beim Raid 1 war's wohl; obwohl diese Einstellungen seit der Auslieferung nicht geändert wurden.

[#19]

Na, da hätte man ja lange hier über Datensicherungsszenarien philosophieren können. Aber immerhin. Erfahrungsaustausch dank Community. Klasse Sache hier, oder?

Schöne Ostertage!

LG, A. Hofmeister

[#20]

Die DATEV-Community ist eine Spitzen Einrichtung und die Reaktionszeiten sind häufig sensationell.  Wir hätten sicher noch Jahre über Sicherungskonzepte nachdenken können.

Für mich bleibt dennoch ein schaler Nachgeschmack:  Die "Problemlösung" fühlt sich so an als ob ich wegen blockierender Bremsen die Bremsleuchten austausche; aber so scheint IT zu funktionieren

Schöne und erholsame Osterfeiertage

[#21]

Den schalen Beigeschmack hätte ich auch, obwohl aus anderen Gründen. Üblicherweise wird der Schreibcache mit einer Batterie (oder Akku oder Kondensator) abgesichert. Diese "Notstromversorgung" des Cache wird durch den Controller überwacht. Einige bessere Modelle können einen leeren (warum auch immer) Akku erkennen und schalten dann den Schreibcache ab. Bei weiteren Betrieb sollten Sie einmal den Status des Akkus prüfen (lassen) um Datenverluste zu vermeiden.

Auch ich wünsche schöne Ostertage.

Gruß

KP

PS: Dummspruch aus dem Radio heute. Der für das Osterwetter zuständige Server wurde von einem Trojaner verseucht, es handelt sich um den Regenwurm...

[#22]

bei den meisten controllern lassen sich auch regelmässige testläufe einrichten, die den allgemeinzustand des akkus testen. während dieses tests wird der cache deaktiviert und wenn der test fehlschlägt, bleibt dieser auch deaktiviert und der akku sollte getauscht werden. bei uns war nach 3 jahren der akku schon hin.. die hersteller sagen ca. 5 jahre.

[#23]

manches mal wünsche ich mir ich hätte mich nicht zu einem Client-Server-System überreden lassen und das alte P2P System beibehalten. Das hätte mir mehr als nur eine schlaflose Nacht und eine Menge Ärger erspart.

Durchschlafen kann man damit. Dafür würden Sie sich wahrscheinlich mittlerweile während der Arbeitszeit ständig kaputtkonfigurieren bzw. stundenlang die Hotline (per Remote auf dem Server / erfolglos) bemühen, während Ihre Kollegen frei haben. Es weiss nämlich keiner, wie man die neue Benutzerverwaltung im P2P konfiguriert.

[#24]

Die neue Benutzerverwaltung habe ich erstmals unter unserem alten P2P-System eingerichtet.  War - unter Berücksichtigung des damaligen Umsetzungsstandes - weitgehend problemlos möglich.

Aber, Hand auf's Herz, ob ich eine schlaflose nach wegen der Benutzerverwaltung habe oder weil die Einstellungen am Server nicht optimal sind, ist für mich egal.

Durch die Änderungen am Server scheint jetzt der Rest der DATEV-Programme Schwierigkeiten zu machen - Jedenfalls erhalte ich seither gehäuft Programm reagiert nicht Meldungen - muss ich weiter beobachten und sehen wie die Kollegen reagieren.  Vielleicht fehlt dem Server auch nur die notwendige Last

[#25]

wieviel ram und wieviel arbeitsspeicher ist dem sql/server zugewiesen? wieviele nutzer sind es?

[#26]

Arbeitsspeicher ist ausbaubar.  Derzeit nur 8 GB bei max. 3 Nutzern.

Das eigentlich nicht logische Phänomen, dass die DATEV-Software bei geringer Nutzerzahl (1 Nutzer) an Performance zu verlieren scheint, beobachte ich schon länger, ohne dass sich es greifen oder eingrenzen könnte.

Nachdem zwischenzeitlich die maximale Anwenderzahl tätig ist reagieren die Programme auch wieder erwartungskonform.

[#27]

Alls kleines Update für die Interessierten Leser:

Die Datensicherung hat dieses mal die Anlage einer Akte massiv beeinträchtigt.  Bis das Fenster für die Kollisionsprüfung erscheinen ist sah sich der Arbeitsplatz veranlasst den Hinweis zu geben, dass diese Prüfung mehrere Minuten dauern könne.  Dann wollte er die Akte nicht speichern, weil angeblich ein Nachname fehlen würde ....

Es bleibt spannend.  Offensichtlich war der Ausbau der Bremsleuchte für die Beseitigung der Bremsblockade doch nicht wirklich hilfreich.

Ich werde den Interessierten und geneigten Lesern weiter berichten.

[#28]

irgendetwas läuft da auf den hammer... bei uns läuft auch jeden mittag eine sql sicherung und bei 20 anwendern lässt es sich noch ganz passabel arbeiten.

würde, wenn keine ssd, eine extra partition für die auslagerungsdatei erstellen und diese bei 20gb fixieren. dann schauen, was der ram so macht. unser sql, ausschiesslich sql, braucht max 3gb ram für das system ect. die restlichen 20gb nimmt datev-sql, 1gb puffer. das kann man im sql manager fixieren.. weiss aber gerade nicht mehr wo.

[#29]

Danke für den Hinweis,

Das eigentliche Problem liegt darin, dass bei identischer Hardwareausstattung das Einspielen eines Servicerelease - noch nicht einmal am Server selbst - zu einem Performanceeinbruch führt und dies auch nur einmal am Tag.

Für mich fehlt hier jeder Zusammenhang zu einer auszulagernden Partition oder der (de-)Aktivierung eines Schreib-Cache oder der Größe des Arbeitsspeichers.   Bei einem neues System oder einer neuen Softwareversion hätte ich das Verhalten nachvollziehen können.

[#30]

- eventuell ist auch bei der Installation des SR etwas schief gelaufen

- oder, es passt nicht mehr durchs Loch, entsprechend blockiert die ganze Maschine (entsprechend etwas Umlagern)

- was sagt die Ereignisanzeige auf dem Server?

- eventuell liegt auch ein Hardwaredefekt vor. Technische Prüfung des SQL in Ordnung? SMART-Werte der Platten in Ordnung?

- Trojaner/Wurmbefall?

Es kann vieles sein.