3
Datev auf Clients langsam
Hallo,
ich habe hier ein Problem mit Datev Lohn und Gehalt. Die Abrechnung dauert für einen Mandanten ca. 100 Mitarbeiter über 30 min. Das ganze ist jetzt seit der DVd 18.0
Habe andere auch solche oder ähnliche Probleme? Die Clients und der Server sind weiter über der emp. von Datev
Die Rechner sind:
Windows XP SP3
4Gb Arbeitsspeicher
Intel Dual Core e6850
250 Gb Sata II Platte
Netzwerkanbindung 1Gbit
Der Server:
w2x Server nur für Datev
2x Xeon 3,2 Ghz
4Gb Arbeitsspeicher
Raid 5 System auf Sata II Platten (ICP 8087MA Raidcontroller)
Netzwerkanbindung 1Gbit
Es sind 8 Arbeitsplätze die am Server arbeiten
Gruß
Maik
ich habe hier ein Problem mit Datev Lohn und Gehalt. Die Abrechnung dauert für einen Mandanten ca. 100 Mitarbeiter über 30 min. Das ganze ist jetzt seit der DVd 18.0
Habe andere auch solche oder ähnliche Probleme? Die Clients und der Server sind weiter über der emp. von Datev
Die Rechner sind:
Windows XP SP3
4Gb Arbeitsspeicher
Intel Dual Core e6850
250 Gb Sata II Platte
Netzwerkanbindung 1Gbit
Der Server:
w2x Server nur für Datev
2x Xeon 3,2 Ghz
4Gb Arbeitsspeicher
Raid 5 System auf Sata II Platten (ICP 8087MA Raidcontroller)
Netzwerkanbindung 1Gbit
Es sind 8 Arbeitsplätze die am Server arbeiten
Gruß
Maik
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 80652
Url: https://administrator.de/forum/datev-auf-clients-langsam-80652.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
3 Kommentare
Neuester Kommentar
Hi,
wir administrieren und betreiben einige Datev-Plattformen, meist in Terminalserverumgebungen. Seit Ver. 18.0 hat die Datev auf SQL Server 2005 umgestellt. Darin könnte das Problem liegen. Wichtig ist der SQL-Manager, über den man regelmäßig alle Prüfungen und Online-Sicherungen als automatischen Task NEU konfigurieren sollte. Durch die Prüfung erfolgt auch eine Optimierung der Datenbank und Bereinigung des Loggings (allgemeines SQL-Thema).
Im Bereich Datenbank gibt es unzählige Ansatzpunkte zur Leistungssteigerung, angefangen bei der Auswahl von Hardware (Kontroller) und Entscheidung der Segmentierung von Festplatten und RAID-Systemen... (Ein Serversystem basierend auf einem RAID5-System mit mehreren Partitionen ist sicherlich nicht als optimal zu betrachten). Mit eigenem echten und leistungsfähigen SATA-RAID-Kontroller spielt die Prozessorleistung eine untergeordnete, unwichtige Rolle, da hier primär der Datendurchsatz und -geschwindigkeit zählt. Der Speicher ist schon wichtig und mit 4GB für die Standardversion W2xxx (nicht Enterprise) maximal möglich.
Im Bereich der Anwendungsserver (Terminalserver oder Clients) ist die CPU und der Speicher das Maß aller Dinge.... die Netzanbindung mit 1 GBit/s ist für SQL kein performancerelevantes Kriterium
Gruß Jörger
wir administrieren und betreiben einige Datev-Plattformen, meist in Terminalserverumgebungen. Seit Ver. 18.0 hat die Datev auf SQL Server 2005 umgestellt. Darin könnte das Problem liegen. Wichtig ist der SQL-Manager, über den man regelmäßig alle Prüfungen und Online-Sicherungen als automatischen Task NEU konfigurieren sollte. Durch die Prüfung erfolgt auch eine Optimierung der Datenbank und Bereinigung des Loggings (allgemeines SQL-Thema).
Im Bereich Datenbank gibt es unzählige Ansatzpunkte zur Leistungssteigerung, angefangen bei der Auswahl von Hardware (Kontroller) und Entscheidung der Segmentierung von Festplatten und RAID-Systemen... (Ein Serversystem basierend auf einem RAID5-System mit mehreren Partitionen ist sicherlich nicht als optimal zu betrachten). Mit eigenem echten und leistungsfähigen SATA-RAID-Kontroller spielt die Prozessorleistung eine untergeordnete, unwichtige Rolle, da hier primär der Datendurchsatz und -geschwindigkeit zählt. Der Speicher ist schon wichtig und mit 4GB für die Standardversion W2xxx (nicht Enterprise) maximal möglich.
Im Bereich der Anwendungsserver (Terminalserver oder Clients) ist die CPU und der Speicher das Maß aller Dinge.... die Netzanbindung mit 1 GBit/s ist für SQL kein performancerelevantes Kriterium
Gruß Jörger
Hallo,
danke für die Schnelle Aw.
Zum Server
Das raid 5 ist auf einem schnellen Kontroller der nur für Datev ist. das Betriebssystem liegt auf einem Raid 1 (8047 zweiter Controller)
Der Server selber hat eine Cpu nutzung von 18% bei einer Probeabrechung. Der Datendurchsatz auf den Festplatten ist gleich null / die Festplatten machen nix.
Die Datensicherung oder besser der Dump auf die Festplatte aller Datev Datenbanken dauert so ca. 7 min und sind zusammen ca 34 GB ( PMSC hat alleine 28 GB) . Im Personalmanagment sind viele Scanbilder drin, darum die Große Datenbank.
über das netzwerk gehen auch kaum Daten und der Client hat eine Cpu nutzung von ca. 8 %
Wir habe hier noch einen SQl Server (die Selbe Hardware) auf dem die Entwicklung / Programmierung arbeitet. Dieser hat keine Probleme mit der Leistung.
danke für die Schnelle Aw.
Zum Server
Das raid 5 ist auf einem schnellen Kontroller der nur für Datev ist. das Betriebssystem liegt auf einem Raid 1 (8047 zweiter Controller)
Der Server selber hat eine Cpu nutzung von 18% bei einer Probeabrechung. Der Datendurchsatz auf den Festplatten ist gleich null / die Festplatten machen nix.
Die Datensicherung oder besser der Dump auf die Festplatte aller Datev Datenbanken dauert so ca. 7 min und sind zusammen ca 34 GB ( PMSC hat alleine 28 GB) . Im Personalmanagment sind viele Scanbilder drin, darum die Große Datenbank.
über das netzwerk gehen auch kaum Daten und der Client hat eine Cpu nutzung von ca. 8 %
Wir habe hier noch einen SQl Server (die Selbe Hardware) auf dem die Entwicklung / Programmierung arbeitet. Dieser hat keine Probleme mit der Leistung.
Bin ganz neu in administrator.de angemeldet und hab zufällig den Beitrag gesehen. Wir haben erst vor wenigen Tagen einen POWER-DB-Server für SQL mit Erfolg in Betrieb gesetzt und durch die spezielle Auslegung einen deutlich spürbaren Performancezuwachs erzielt (hierbei aber leider nicht für Datev,sondern mit vollst. Microsoft SQL-Server 2005 und durchgängigem 64Bit-System auf 4 RAID-Verbund, das bringts echt).
Folgende Ergänzungen:
Das eigene Raid1 für das Systemswapping (Auslagerungsdatei) ist gut. Auf diesem Raid sollten keine weiteren laufenden bzw. zeitkritischen Lese- oder Schreibzugriffe (wie SQL) über die gleiche oder andere Partitionen stattfinden.
JEDER weitere EIGENE Prozeß/Instanz mit laufenden und zeitkritischen Lese- oder Schreibzugriffen sollte optimalerweise auf einem EIGENEN RAID-Festplattenverbund arbeiten. Dazu gehört zum einen die Datenbank und idealer Weise getrennt davon das SQL-Logging, das von allem das zeitkritischste ist. ALLE Schreibvorgänge auf die Datenbanken laufen zuerst ins Logging und werden erst nach dortigem Abschluß freigegeben.
Von allen RAID-Systemen hat RAID5 die schlechteste Schreibperformance, die Beste hat RAID0 (aber keine Redundanz) bzw. RAID50 (braucht aber mind. 6 Platten).
Mit SQL-Manager meine ich nicht ein Dump-System, wenn ich richtig verstehe: Imaging-System, wie Livestate bzw. Backup-Exec, die für ihren Zweck unersetzlich sind. Der Datev SQL-Manager handelt und sichert die Datenbanksysteme wie der Enterprise Manager logisch und bereinigt diese. Ansonsten werden die Logs immer größer...
Je größer die Datenbanken, je wichtiger sind die o.g. Punkte. Der Server sollte in den Leistungsoptionen der Systemeigenschaften auch auf Systemcache und Hintergrunddienste eingestellt sein.
Wenn die Platten nix machen ... dann läuft schon viel im Speicher, oder der Abrechnungsprozeß am betreffenden Client stellt den Engpaß dar??!!! Trotzdem sind die Datenbanken ganz schön dick und ich würde als erstes den SQL-Manager befragen, Server stoppen und evtl. auch mal defragmentieren, damit wäre dann das DB-Thema fast schon erschöpft ...... puuh
Gruß Jörger
Folgende Ergänzungen:
Das eigene Raid1 für das Systemswapping (Auslagerungsdatei) ist gut. Auf diesem Raid sollten keine weiteren laufenden bzw. zeitkritischen Lese- oder Schreibzugriffe (wie SQL) über die gleiche oder andere Partitionen stattfinden.
JEDER weitere EIGENE Prozeß/Instanz mit laufenden und zeitkritischen Lese- oder Schreibzugriffen sollte optimalerweise auf einem EIGENEN RAID-Festplattenverbund arbeiten. Dazu gehört zum einen die Datenbank und idealer Weise getrennt davon das SQL-Logging, das von allem das zeitkritischste ist. ALLE Schreibvorgänge auf die Datenbanken laufen zuerst ins Logging und werden erst nach dortigem Abschluß freigegeben.
Von allen RAID-Systemen hat RAID5 die schlechteste Schreibperformance, die Beste hat RAID0 (aber keine Redundanz) bzw. RAID50 (braucht aber mind. 6 Platten).
Mit SQL-Manager meine ich nicht ein Dump-System, wenn ich richtig verstehe: Imaging-System, wie Livestate bzw. Backup-Exec, die für ihren Zweck unersetzlich sind. Der Datev SQL-Manager handelt und sichert die Datenbanksysteme wie der Enterprise Manager logisch und bereinigt diese. Ansonsten werden die Logs immer größer...
Je größer die Datenbanken, je wichtiger sind die o.g. Punkte. Der Server sollte in den Leistungsoptionen der Systemeigenschaften auch auf Systemcache und Hintergrunddienste eingestellt sein.
Wenn die Platten nix machen ... dann läuft schon viel im Speicher, oder der Abrechnungsprozeß am betreffenden Client stellt den Engpaß dar??!!! Trotzdem sind die Datenbanken ganz schön dick und ich würde als erstes den SQL-Manager befragen, Server stoppen und evtl. auch mal defragmentieren, damit wäre dann das DB-Thema fast schon erschöpft ...... puuh
Gruß Jörger
