DATEV- monatliches Update / Erfahrungen

[#1]

Immerhin läßt mich das Ding nichts administrieren

[#2]

Warten auf die Schnecke...

OK, der Ersatz- PC war beim letzten Update ausgeschaltet und zieht jetzt ReWe nach, während der Server für das klitzekleine Zahlungsverkehr, welches dort überhaupt nicht installiert ist, einen Neustart anfordert.

Wie kann man verhindern, daß der Fileserver jedes mal in eine Plattform- Installation rennt?

______________
Edit zur Schnecke:

Glück gehabt, damit ist das Update schneller durch...
Beim 2. Update (nach dem Server- Neustart natürlich) funktionierte dann auch das ViWas- Update als Ewigkeitswerk, wie wir es ja kennen.

[#3]

Hallo @martinkolberg ,

der Fileserver installiert die Plattform, wie jeder Rechner, nur, wenn für die Plattform tatsächlich ein Update vorliegt.  Die Prüfung hierfür differenziert sowohl dahingehend, ob die gesamte Service-Release-Lieferung schon auf dem Rechner installiert ist, als auch danach, ob ein einzelnes Plattform-Produkt nicht, oder in älterer Version vorliegt.

Für die Lauffähigkeit aller Rechner ist es obligatorisch, die Plattform-Updates zu installieren.

Wir sind bemüht zur nächsten größeren Lieferung die Dauer der Plattform-Updates zu optimieren.

Mit freundlichen Grüßen,

Katrin Zahlten

[#4]

@martinkolberg 

Was ist das überhaupt für ein Zahlungsverkehr-Update gewesen?

Sehe weder was bei Release noch bei Hotfix.

[#5]

---

@Katrin_Zahlten  schrieb:

Hallo @martinkolberg ,

der Fileserver installiert die Plattform, wie jeder Rechner...

... ob ein einzelnes Plattform-Produkt nicht, ... vorliegt.

Für die Lauffähigkeit aller Rechner ist es obligatorisch, die Plattform-Updates zu installieren.

Wir sind bemüht zur nächsten größeren Lieferung die Dauer der Plattform-Updates zu optimieren.

Bitte prüfen Sie ab, welche Produkte wirklich auf dem Fileserver notwendig sind.
Unser Server wurde erst vor knapp einen Jahr als Fileserver neu aufgezogen und eigentlich nur das installiert, was die Server- Installation verlangte.

Ziel ist, daß kleine DATEV- Updates den Server in Ruhe lassen. Notfalls per Option für den Admin, der vielleicht besser einschätzen kann, ob der Server wirklich beim einfachen LODAS- Update mitmachen muß.

Beim letzten ReWe- Update war irgend ein SiPa- Update dabei (SC steckt nicht am Fileserver), welches wohl unbedingt sein sollte.

Warum jetzt 14 tage später wieder eine Plattform- Aktualisierung an einem Gerät erfolgen muß, der doch nur die SQL- Datenbanken (und den noch nie aufgerufenen DAP) vorhält, ist mir schleierhaft.
Selbst der Lizenzmanager hängt noch am alten SBS, obwohl dort der Rest von DATEV nur ein Zombie- Dasein führt. (Nicht deinstalliert, aber alle Dienst deaktiviert und Gerät auch der Liste raus gekickt)

[#6]

Hallo @martinkolberg ,

die Installation prüft explizit, was auf dem System installiert ist.

Es werden nur Produkte aktualisiert, die auf dem System installiert sind. Aus Security-Gründen müssen wir gewährleisten, dass alle Produkte und deren Bestandteile aktuell gehalten werden.

Mit freundlichen Grüßen,

Katrin Zahlten

[#7]

Aus andren DATEV- unabhängigen Gründen kann es gelegentlich unmöglich sein, den Server neu zu starten.
Was nun, wenn der olle Laptop die lange ausgesetzte Installation nachholt und damit der komplette Kanzlei- Ablauf steht?

Bitte überarbeiten Sie die Routine, so daß der allwissende Admin selber entscheiden darf, ob das Update auf dem Server starten soll. Ich rede nicht von Riesen- Updates, wie der neuen DVD, sondern vom kleinen LODAS- Update.

Dieses ins offene Messer Gerenne darf nicht sein!

Stellen Sie sich vor, am Montag um 9:00 Uhr erhält der Admin den Anruf. "Wir benötigen das neue LODAS- Update, jetzt, sofort..." OK, Update- Lauf starten, aber wenn jetzt der Server einen Neustart verlangt ??? NOGO !!!

Zur Entscheidungsfindung: Sie wissen doch, was neu ist. Wenn es nur ein LODAS- Update und einen BiBer- Hotfix gibt, dann darf die Verteilung an den Fileserver gar nicht starten. Egal, wie der Stand auf dem Server ist! (Was vorher funktionierte, wird auch nach dem LODAS- Update auf den Arbeitsplätzen laufen)
Wenn das nicht automatisch funktioniert, dann bitte ein [ x ] "nur Arbeitsplätze aktualisieren"

Danke. 

[#8]

Hallo Herr Zahlten,

ich muss jetzt auch mal meinen Unmut zur neuen netzweiten Installation seit der Programme 15.0 äußern.

Die unsägliche Meldung "Server erfordert" und "Server wartet auf" ist schlicht weg ein Zeitfresser. Wenn diese Routinen sauber funktionieren würden, wäre es nicht so ärgerlich. Aber mir ist bei jeder Updateinstallation (Kanzleinetz, Mandantennetz) es immer wieder passiert, dass ein oder mehrere Clients die "Server"-Sperre nicht bekommen haben oder die Sperre für einen kurzen Moment offen war, weil der Server dann selber in die Installation gelaufen ist. 

Das führt dann unweigerlich zu den komischen Zeitschleifen, in denen man mehrere Clients nicht weiter aktualisieren kann und/oder der Server wartet, bis die "Schnellläufer" endlich fertig sind. Übrigens inkl. Datenanpassungen... 

Es kann also nicht wirklich überlebensnotwendig für den Server sein, dass die Plattform komplett und in allen Fassetten aktuell und fertig ist, wenn die Schnellläufer ohne Probleme alles durchlaufen. 

Die netzweite Aktualisierung muss wieder auf den Stand der 14.x gebracht werden. Es kostet einfach unfassbar viel Zeit... 

Haben Ihre Kollegen aus der DATEVasp und SmartIT nicht solche Erfahrungen machen dürfen? Oder interessiert es dort nicht, weil die Updates aus Images ausgerollt werden?

Beste Grüße
Christian Ockenfels

[#9]

Der Kritik von chrisocki kann ich mich nur anschließen.

Gerade habe ich knapp 45 min. dafür verwendet mit der "netzweiten Installation" den letzten Patch/SR des Zahlungsverkehr an drei (3) Arbeitsplätzen zu installieren.  Warum dazu eine Plattforminstallation am Server erfolgen musste, die keine erkennbaren Installationen durchgeführt hat, außer die aktuelle VIWAS Version, die ich bewusst nicht eingespielt hatte, zu installieren, wissen nur die Götter.

Leider wurde meine - Zynismus an - hervorragende - Zynismus aus - Meinung über dieses Stück "Software" wieder einmal bestätigt.

Manuell wäre das SR in max. 15 min. installiert gewesen.

[#10]

Wir haben früher die netzweite Aktualisierung am Fileserver gestartet und alle Server haben dann fröhlich ihre Updates installiert, inklusive Datenanpassung.

Aktuelles Vorgehen:
Netzweite Aktualisierung wird am Fileserver gestartet, welcher sofort mit der Installation beginnt. 4 Terminalserver machen auch direkt mit, die anderen 5 WTS warten auf einen Neustartet des Fileserver. Der kann aber nicht neu starten, weil er auf die 4 Terminalserver wartet, welche gerade die Updates installieren. Nachdem die 4 Terminalserver fertig sind, startet der Fileserver neu und erst jetzt fangen die anderen 5 Terminalserver an, die Updates zu installieren. Nun starten wir die Datenbankanpassungen auf einem der 4 Terminalserver (welche die Updates bereits installiert haben). Datenbankanpassungen und die anderen 5 Terminalserver werden zum Glück ungefähr gleichzeitig fertig.

Sollte man allerdings einen Server vorher für die Datenbankanpassungen ausgewählt haben, der sich bei den 5 WTS befindet, welche später installiert wurden,... dann dauert alles deutlich länger.

So richtig rund ist das nicht im Vergleich zu früher.

[#11]

Ich habe den Eindruck, dass wurde für die Masseninstallation so gestrickt… da kommt es eher auf Stabilität als auf Geschwindigkeit an, da man ja an mehreren Farmen gleichzeitig installiert.

Für einzelne Installationen ein riesengrosser Rückschritt…

[#12]

Möchte gerne auch meine Erfahrungen hier einfließen lassen, die sich noch auf die Version 14.X beziehen virtuelles WTS-System (sind nun in Smart-IT).

Grundsätzlich möchte ich festhalten, dass bei uns die Installationsroutinen und auch die Netzweite Installation robust funktionierten und den Installationsaufwand reduzierten (keine nachhaltigen Beschädigungen des Systems oder Fehler, die nicht spätestens beim 2. Durchlauf beseitigt waren). Dennoch gibt es einige Klippen und Aspekte die man wohl kennen muss.

In 14.0 liefen die zahlreichen Updates mittels netzweiter Installation bei uns immer zuverlässig durch - außer das Thema An- und Abmeldung der TS-Clients sowie unerwartete Neustarts oder auch mal keine.

Ab 14.1 kam es regelmäßig zu Problemen mit gestoppten Diensten am File-Server, durch die Plattformupdates. Dabei stoppen Maschinen, die da gerade auf einen Dienst (DFL-Dienst glaube ich?) zugreifen wollten die Updateinstallation sofort und endgültig (nach Abschluss aller anderen Maschinen erneute netzweite Installation erforderlich). Dies trat fast regelmäßig auf und konnte nur durch die Einzel-Installation am Fileserver vorab behoben werden.

Die Neustartanforderungen, welche in der Datev-Dokumentation zu den Service-Releases standen waren häufig unzuverlässig. Auch die Beschreibung der Hotfixes (auf Web-Page) hinsichtlich der Installationsanforderungen empfand ich absolut ungenügend.

In der 15 scheint das Thema gestartete Dienst durch "Warten" beseitigt worden sein?!

Hinsichtlich der "Plattform-Updates" ist die Übersicht der Service-Releases ungeeignet, weil nicht zugeordnet. Außerdem werden manchmal Programme gelistet, die so im Installationsmanager nicht auftreten (z.B. wenn Teil der Plattform oder eines anderen Programmes).

Auch die verunsichernde Warnung einzelne Programme nicht zu installieren ist m.E. zu präsent. Die Installationsroutine sollte zuverlässig prüfen, ob das Update eines einzelnen Programms (z.B. Lohn) möglich ist, und welche weiteren Updates ggf. erforderlich wären (bisher hatten wir z.B. L&G immer einzeln vor dem i.d.R. 1-2-Montate später installierten großen Update installiert (lief immer!!).

Was ich mir immer wünschte:

• Neustart der Updateroutine an einer Maschine nach Abbruch (z.B. weil Dienst temporär nicht erreichbar) auslösbar
• ggf. Möglichkeit manueller Anstoß der sofortigen Anmeldung des Installationsnutzers am Client
• Möglichkeit die Installationsstarts der einzelnen Maschinen bei Netzweiter Aktualisierung manuell auslösen und ggf. auch stoppen zu können
• Zuverlässige Beschreibung von Anforderungen bei Installation Service-Releases und Hotfixes (Neustart, Datenanpassung, Plattform, im Betrieb möglich, Abhängigkeiten und Vorrausetzungen ....

Mit solche Möglichkeiten und Informationen sollte m.E. die Installation ohne Überraschungen planbar und durchführbar sein.

PS: Auch wegen dieser ständigen Updates (MS-Patches, Datev-Patches, ...) sind wir letztlich in die Smart-IT gewechselt.

Hoffe, die Funktionalitäten des Installationsmanagers werden um Möglichkeiten des optionalen manuellen Eingriffes ergänzt (könnte ja auch das Warten ggf. vermeiden helfen). 

Danke an dieser Stelle auch an Herrn @martinkolberg (und andere Schnellinstallierer), deren Feedback ich vor Installation der Service-Releases häufig abgewartet habe.

[#13]

Bei uns läuft seit dem Datev Update auch alles langsamer.

PDF Dateien in der Dokumentenablage und in Outlook öffnen deutlich langsamer. 

Das Öffnen von Rechnungswesen dauert länger.

Ein paar Mal konnte keine Verbindung zum RZ erzeugt werden.

[#14]

Ist denn bei euch überall der richtige Proxy hinterlegt? Bei uns hat es geholfen den Proxy über die Managementconsole zu verteilen.

Glaube der macht da auch irgendwo einen Abgleich mit dem Internet.. vlt langsame Verbindung?

[#15]

---

@w_paul  schrieb:

Bei uns läuft seit dem Datev Update auch alles langsamer.

PDF Dateien in der Dokumentenablage und in Outlook öffnen deutlich langsamer. 

Das Öffnen von Rechnungswesen dauert länger.

Ein paar Mal konnte keine Verbindung zum RZ erzeugt werden.

---

Hallo W_Paul

das Phänomen, dass nach einer Neu-/Updateinstallation das gesamte System langsamer läuft, kann ich aus leidvoller und stundenlanger Ursachensuche bestätigen.  Allerdings konnte ich bis heute keine Ursache finden; selbst die Analyse durch Mitarbeiter der DATEV war unergiebig.

Ich beobachte bei uns jedoch, dass nach ca. 1 Woche die "alte" Geschwindigkeit der Programme wieder zu beobachten ist.

[#16]

---

@agmü  schrieb:

Ich beobachte bei uns jedoch, dass nach ca. 1 Woche die "alte" Geschwindigkeit der Programme wieder zu beobachten ist.

---

Das wäre jetzt ja echt trivial, aber was ist mit  1080330 und  1071153 ?

(Weil Datev hat ja bereits analysiert)

[#17]

@agmü ,

... hat der Datev-Support von einem 'seltenen' oder 'einmaligen' Effekt gesprochen oder ist das ein 'altbekanntes', häufiges Phänomen ?

... und ist die Verbesserung der Performance eher ein Bauchgefühl oder ist es auch messbar

@siro ,

... ist die regelmäßige Anwendung der Maintenance-Scripte quasi 'Pflicht' des Datev-Installateurs oder werden diese Scripte auch automatisch bei bestimmten 'Triggern' ausgeführt, z.B. bei starker Fragmentierung ?

... ich war eigentlich der Meinung, dass der SQL-Server sich weitgehend selbst organisiert und optimiert

... das häufige manuelle Starten der Maintenance-Scripte ist verdammt zäh

... würde es nicht schon reichen, nach einer neuen netzweiten Aktualisierung bestimmte Scripte oder Aktionen zu starten, um schon von Anfang an eine 'akzeptable' Performance zu erreichen ?

[#18]

---

@vogtsburger  schrieb:

@agmü ,

... hat der Datev-Support von einem 'seltenen' oder 'einmaligen' Effekt gesprochen oder ist das ein 'altbekanntes', häufiges Phänomen ?

... und ist die Verbesserung der Performance eher ein Bauchgefühl oder ist es auch messbar

---

Aus den Äußerungen schließe ich, dass das Phänomen nicht besonders häufig beim Service moniert wird, was für mich bedeutet: selten

ich sitze nicht mit der Stoppuhr daneben

[#19]

---

@agmü schrieb:

... ich sitze nicht mit der Stoppuhr daneben ...

---

... das Messen der Start-/Stopp- und Laufzeiten übernehmen ja die Wartungsläufe, falls sie eingerichtet sind.

... habe auch schon mit diesen Wartungsläufen experimentiert. 

Der manuelle Aufruf ist sehr zäh. Man sitzt wie die Katze vor dem Mauseloch und wartet auf Godot bzw. auf das Ende eines Wartungslaufs.

Während der Wartungsläufe erhält man nämlich keinerlei Infos zum Fortschritt oder zur voraussichtlichen Dauer.

... und im Anschluß an eine netzweite Aktualisierung auch noch zeitaufwändige Wartungsläufe zu starten, ist vermutlich eher nicht so beliebt beim Datev-Installateur.

... die unbeaufsichtigten (geplanten) Wartungsläufe sind sicher weniger 'ausbremsend', allerdings auch etwas trickreich bei der Einrichtung. Diese Wartungsläufe dürfen ja auch nicht mit anderen SQL-Aktionen kollidieren.

... wenn es aber schon ausreicht, dass ein PC nach der Datev-Aktualisierung über Nacht gestartet bleibt, dann sind ja keine besonderen Klimmzüge erforderlich. Nachts haben die PCs wenigstens die Gelegenheit, "in einen Ruhezustand zu kommen".

... eigentlich wären regelmäßige und automatisch erstellte Informationen über eingerichtete Wartungsläufe am bequemsten, am besten als regelmäßige E-Mail-Benachrichtigung ähnlich wie bei der täglichen E-Mail-Benachrichtigung bzgl. Datenbankprüfung

("Die Datenbankprüfung auf dem Server XXXXXXXX wurde erfolgreich abgeschlossen.")

[#20]

Hallo zusammen,

wir müssen hier mehrere Dinge wohl mal differenzieren.

1. SQL-Performance

2. Client (Application)-Performance

zu 1.

Grundsätzlich organisiert der SQL sich zur Laufzeit selber. D.h. er organisiert primär und insbesondere seinen Cache im Hauptspeicher. Wenn zum Zwecke der nächtlichen Datensicherung der SQL gestoppt wird, ist die Performance am nächsten Tag durchaus spürbar schlechter. Der SQL muss dann nämlich die DB's erst wieder in den Cache laden, etc.

--> SQL durchlaufen lassen / Sicherung via VSS

Die Datenbanken optimieren (manuell) bringt vielleicht was, aber ggf. werden zum einen die Effekte schlimmer (Fragmentierung) oder im WorstCase, die DB ist im Eimer. Je nach Optimierung werden DB-Duplikate erstellt und dann die Daten kopiert. Wenn es hier kracht --> Datenrücksicherung... 

Wartungsscripte: Die sollten einmal im Taskmanager / Aufgabenplanung eingerichtet werden. Ich habe bei div. Kanzleien sogar die WE (Wochenende)-Scripte im täglichen Aufruf, da die Dauer nur wenige Sekunden/Minuten braucht. Hierbei werden Indexe, etc. neu geschrieben und geladen, was den SQL wiederum unterstützt.

Sollte für ein Systembetreuer eine Fingerübung zur Einrichtung sein.

Datenbankchecks können mittlerweile auch Benachrichtigungen verschicken und in Kombination mit der Sicherung im SQL-Manager ausgeführt werden. 

zu 2)

Nach einem Update werden die Native-Images erstellt. Diese sollten eigentlich in Ruhephasen der Rechner erstellt werden (erfolgt automatisch). Diese können aber auch manuell gestartet werden (dauert).

Bei Terminalservern im Regelfall kein Problem, die laufen meistens durch in die Images werden Nachts erstellt.

Ob die Images vorhanden sind, kann mit dem Leistungsindex.cmd geprüft werden.

Aufruf: %DATEVPP%\PROGRAMM\RWAPPLIC\Leistungsindex.cmd

Zudem können sich auf einem Rechner/Terminalserver die Virenscanner negativ auswirken. Und wie schon zuvor geschrieben, kann das auch der ViWas/McAfee sein. 

Beste Grüße
Christian Ockenfels

[#21]

Mit den "Wartungsläufen" habe ich mich noch nicht beschäftigt.

Der Zugriff auf den SQL und der Server selbst scheinen nicht das eigentliche Problem zu sein.   Aus den Beobachtungen heraus schließe ich eher auf andere Ursachen.

@chrisocki : 

Die Erstellung der Native Images manuell anzustoßen ist bei mir "Standard" nach jeder Installation.  Allerdings gehen die damit erzielten Verbesserungen - nach meiner Erfahrung - zwischenzeitlich in der insgesamt unvorteilhaften Performance nach einer (Neu-)Installation unter. 

[#22]

---

@chrisocki schrieb:

... Nach einem Update werden die Native-Images erstellt ...

---

... bloß wann genau ?

... erst nachdem REWE gestartet wurde oder auch bei abgemeldetem Benutzer ?

... wenn nach der netzweiten Aktualisierung ('AfterWork-Party') einfach alle Arbeitsplätze über Nacht gestartet  und der Administrator abgemeldet bleiben könnten und am nächsten Tag wäre alles wieder 'geschmeidig', dann wäre ja 'alles gut'.

... aber das nachträgliche 'Herumeiern' mit der Performance ist ziemlich 'ätzend'

---

@chrisocki schrieb:

... Wenn zum Zwecke der nächtlichen Datensicherung der SQL gestoppt wird, ist die Performance am nächsten Tag durchaus spürbar schlechter. Der SQL muss dann nämlich die DB's erst wieder in den Cache laden, etc. ...

---

... mal ganz naiv gefragt:

warum kann der SQL-Server die DBs, nicht wieder 'freiwillig' und 'mit vorauseilendem Gehorsam' in den Cache laden ?

... z.B. genau die DBs die er vor dem Stoppen des SQL-Servers im Cache hatte ?

[#23]

---

@vogtsburger schrieb: 

... bloß wann genau ?

... erst nachdem REWE gestartet wurde oder auch bei abgemeldetem Benutzer ?

---

 Hmm... gem. Dokument 1080330 "wenn der Rechner in einen Ruhezustand kommt"  Zugegeben, dass kann alles bedeuten...

Aber es heißt weiter: "Lassen Sie den Rechner ... nach der Installation über Nacht bei gesperrten Bildschirm eingeschaltet". 

--> Würde bedeuten: Benutzer angemeldet lassen... 

... aber das nachträgliche 'Herumeiern' mit der Performance ist ziemlich 'ätzend'

Mit einem Kix-Script könnten Sie es auch automatisieren.

1. Task für die tägliche Ausführung des Scripts einplanen (Start 22:xx Uhr oder wann auch immer)

2. In dem Script fragen Sie die Existenz einer "Wartungsdatei" ab. Wenn die vorhanden ist, keine Ausführung, wenn die Datei nicht vorhanden ist, Wartung ausführen.

--> eine Datei pro Rechner / Ablage in einer beliebigen SMB-Freigabe

Nach jedem Update löschen Sie die Datei(en) und Nachts werden die Rechner gezwungen die Images zu erstellen.

Und ja: Einen solchen oder ähnlichen Mechanismus könnte DATEV als Option im Installations-Manager vorsehen... 

Beste Grüße
Christian Ockenfels

[#24]

... noch ein Nachtrag:

---

@chrisocki schrieb:

... Die Datenbanken optimieren (manuell) bringt vielleicht was, aber ggf. werden zum einen die Effekte schlimmer (Fragmentierung) oder im WorstCase, die DB ist im Eimer. Je nach Optimierung werden DB-Duplikate erstellt und dann die Daten kopiert. Wenn es hier kracht --> Datenrücksicherung... 

---

... genau solche "Effekte" könnte ich absolut nicht gebrauchen,

... nachts, wenn man eigentlich froh ist, dass eine 'netzweite Aktualisierung' gut 'über die Bühne gegangen ist'. 

... oder am nächsten Morgen zu 'unchristlicher' Zeit durch einen Hilferuf der ersten 'Early Bird'-Mitarbeiter*Innen, dass der SQL-Manager streikt.

... technisch unterscheiden sich doch die manuell und die automatisch ausgeführten Wartungsläufe nicht, oder ?

... also könnte auch bei den "geplanten" Wartungsläufen der Worst Case einer defekten Datenbank auftreten, und dazu noch 'in Abwesenheit' des Datev-Installateurs.

... keine angenehme Vorstellung ...

... wenn ich solche Scripts anlege, will ich auch über die Ergebnisse benachrichtigt werden, z.B. per E-Mail, damit man zur Not noch reagieren kann, z.B. per RemoteAccess oder per pedes oder per Bike, per ÖPNV oder auf 4 Rädern.

[#25]

@vogtsburger  schrieb:

---

@chrisocki schrieb:

... Die Datenbanken optimieren (manuell) bringt vielleicht was, aber ggf. werden zum einen die Effekte schlimmer (Fragmentierung) oder im WorstCase, die DB ist im Eimer. Je nach Optimierung werden DB-Duplikate erstellt und dann die Daten kopiert. Wenn es hier kracht --> Datenrücksicherung... 

... genau solche "Effekte" könnte ich absolut nicht gebrauchen,

... nachts, wenn man eigentlich froh ist, dass eine 'netzweite Aktualisierung' gut 'über die Bühne gegangen ist'. 

... oder am nächsten Morgen zu 'unchristlicher' Zeit durch einen Hilferuf der ersten 'Early Bird'-Mitarbeiter*Innen, dass der SQL-Manager streikt.

---

Deswegen sollte man die Funktionen "Optimieren" und "Verkleinern" generell in Ruhe lassen.

---

... also könnte auch bei den "geplanten" Wartungsläufen der Worst Case einer defekten Datenbank auftreten, und dazu noch 'in Abwesenheit' des Datev-Installateurs.

---

Wenn Sie die Maintenance-Scripte planen und laufen lassen, besteht keine Gefahr. Hier werden "nur" die Indexe neu sortiert und optimiert. Die Datenbanken selber werden nicht geändert.

Manuell --> DB optimieren, verkleinern = Finger davon!

---

... wenn ich solche Scripts anlege, will ich auch über die Ergebnisse benachrichtigt werden, z.B. per E-Mail, damit man zur Not noch reagieren kann

---

Wie gesagt, bei den empfohlenen Wartungsscripten: keine Gefahr. Die laufen bei meinen Netzen seit Jahren ohne Auffälligkeiten.

Benachrichtigungen sollten halt für die technischen Prüfungen und die evtl. eingerichtete DATEV-SQL-Sicherung eingerichtet und funktional sein.

Beste Grüße
Christian Ockenfels

[#26]

Das liest sich hier langsam wie "Langzeitfolgen der SQL Wartung" 😞

Datev empfiehlt zusätzlich zu den automatischen Optimierungen die täglichen und wöchentlichen Optimierungen lt. Dok 1071153

Da geht nichts "kaputt", oder der SQL Manager streikt oder dergleichen. Bei bis jetzt jeder Performancereklamation bei der Datev wurde u.a. auf die Einrichtung der Scripte verwiesen, und dies wir auch bei den Schulungen immer angesprochen.

Die 'native Images' sind ein ganz anderes Thema, auch diese sollten nach einem MS ODER DATEV Update erzeugt werden. Man kann die sogar in den Aufgabenplaner packen, denn wenn die NI schon da sind macht der Aufruf einfach 'nichts'. 

Ein GANZ anderes Thema sind die Funktionen Verkleinern/optimieren etc. IM SQL Manager. Diese sind NICHT ständig auszuführen und sind teilweise kontraproduktiv, auch in Bezug auf Performance.

hergebrannt 😁

[#27]

---

@chrisocki  schrieb:

---

Nach jedem Update löschen Sie die Datei(en) und Nachts werden die Rechner gezwungen die Images zu erstellen.

Und ja: Einen solchen oder ähnlichen Mechanismus könnte DATEV als Option im Installations-Manager vorsehen... 

---

Ergänzung :

[#28]

---

---

... mal ganz naiv gefragt:

warum kann der SQL-Server die DBs, nicht wieder 'freiwillig' und 'mit vorauseilendem Gehorsam' in den Cache laden ?

... z.B. genau die DBs die er vor dem Stoppen des SQL-Servers im Cache hatte ?

---

Wir haben noch das alte Script im Einsatz, der den SQL vor der Sicherung stoppt und anschließend neu startet.

Bei flotter Hardware insbes. SSD dauert das erste Starten des DAP am Tag keine 2 Sekunden länger, als üblich.

Damit können wir leben und können auf die Erfahrung zurückblicken, daß der SQL oder gar gesperrte Daten  hier noch nie Probleme verursachte.

[#29]

Achso.. das langsame Programmverhalten liegt bei uns an fehlenden NATIV-Images.

Ich habe gestern Abend die neuen SR's installiert - und das mit der neuen Installationsroutine so lange dauert - hatte ich keine Lust mehr die NGEN auszuführen. Der Haken für das automatische Erzeugen ist im Inst-Man gesetzt.  Macht er aber nicht...

Heute dann Probleme beim öffnen von PDF's aus DAP heraus mit anschließendem Absturz DAP.

Nach ausführen der ngen keine Probleme mehr und läuft Performant.

[#30]

Das Übliche...

C:\DATEV\PROGRAMM\B0001508\NGenAll40.cmd

EDIT:

C:\DATEV\PROGRAMM\RWApplic\Leistungsindex.cmd