Upgrade Server 2012R2 auf 2019 - Datenbanken langsam

[testperson 1.680]

Hi,

 

was sind denn ansonsten noch für Komponenten auf dem jetzt geupgradeten Windows Server 2019? Sind die Komponenten alle für Windows Server 2019 freigegeben bzw. wurden diese im Anschluss ebenfalls auf aktuellen Stand gebracht?

 

Ansonsten könnte bei "so einer Anwendung" in diesem "All-in-One Szenario" evtl. noch TSFairShare für CPU, Disk (und evtl. Netzwerk) bremsen. Die Energieoptionen der Hardware / BIOS / Betriebssysteme sind überall auf "Höchstleistung" bzw. "Max Performance"?

 

Gruß

Jan

[siberia21 13]

Noch eine Frage am Rande: Ich habe bisher immer bei Virtualisierung die HT Kerne deaktiviert. Bei diesem Server hat mein Kollege die jedoch angelassen. Woher soll der HyperV den nun wissen, dass er nicht einen HT Kern der Maschine geben soll, sondern einen echten Vorhandenen? 

 

Hat dies einen Einfluss? 

 

 

bearbeitet 8. Dezember 2022 von siberia21

[daabm 1.356]

AFAIK nein. HT ist nix, von dem Anwendungen wissen. Und dem virtuellen System ist es egal, es muß nur genug Cores haben -> Performance Monitor.

[testperson 1.680]

Hi,

vor 20 Minuten schrieb siberia21:

Hat dies einen Einfluss? 

 

zu einer sehr, sehr hohen Wahrscheinlichkeit nein.

 

Gruß

Jan

[siberia21 13]

Danke euch für die Antworten. Gut dann lasse ich alles wie es ist. 

[siberia21 13]

Ich möchte mich bei euch nochmal bedanken. Letztlich konnte ich den Kunden verdeutlichen, dass er nicht erwarten kann, dass eine Datenbank eines Programms gebaut im Jahr 2008 unter einem System aus 2022 besser oder gleichwertig läuft! Wenn der Hersteller sich schon wunderte, dass ich es unter Windows Server  2012 mit Office 2013 zum laufen bekam. Das war SQL.

 

Die Acess Datenbank musste repariert werden. Hier wurde einfach zu lang gewartet. Interessanter weise ergibt sich hier einen Effekt den ich absolut nicht erwartet hatte noch habe kommen sehen: 

 

So sagte mir die Kollegin heute:

Als vergangen Woche, in der oberen Etage auf der sich normalerweise 5 Kollegen befinden die auf dem TerminalServer über RDP Arbeiten. Nur drei befanden konnte Sie Arbeiten wie vorher. (Vorher ist der alte Server gemeint).

 

Da konnte Sie auf das Drucken Symbol in der Acess basierenden  Programm zwei mal wie gewohnt drauf tippen und zwei mal kam auch der Druckauftrag raus und es war als wäre eine Bremse gelöst. In allem! Alles lief wie vor der Umstellungen. Sie hatte nämlich unter andrem das Problem, dass wenn Sie diesen doppel tipp auf das Symbol zum Drucken  machte also klick, klick... nur ein Druckauftrag raus kam der zweite wurde direkt ignoriert dafür musste Sie dann klick ...... klick machen also sagen wir 2 Sekunden warten. 

 

Nun klingt das sicher witzig oder komisch in eueren Ohren aber als EDV ler wissen wir ja genau, wie nervend Wartezeiten unverhofft und ungewollt sind!

 

Nun eine Frage:

 

Ergibt das für euch einen Sinn? Den mal ehrlich wir haben nach oben zwar nur eine einzige Gigabit Leitung auf Kupfer doch für gerade mal 5 Plätze? Ist das doch mehr als nur ausreichend, da ja die ganze Leistung auf den Server lastet. Die Maschinen selbst machen nur den RDP auf und das sind CoreI3 der 8 Generation als auch kein Spielzeug besonders wenn Fujitsu drauf steht spricht das ja schon für einiges ans Qualität.

 

Bin ich da etwas auf der Spur? Ach her je interpretiert der RDP etwa die Leistung im Sever 2019 anders? Ach her je... jetzt wo ich daran denke... vielleicht hat der RDP jetzt einen höherwerte Grafische Darstellung usw.  das wäre vielleicht auch noch ein Faktor. Allerdings war im 2012er auch alles auf das höchste Level gestellt. 

 

Mich hat die Beschreibung heut etwas Sprachlos gemacht. Der Switch oben ist zwar alt locker aus 2010. Doch DLINK baut nun im 19Zoll Segment auch nicht gerade schlechte Geräte... Alles in allem bin ich verwirrt. 

 

Gruß aus Berlin

André 

[Sunny61 806]

vor 9 Stunden schrieb siberia21:

Die Acess Datenbank musste repariert werden.

Was genau meinst Du mit repariert? Man kann eine Access-DB, egal ob mdb oder accdb auch mit Hilfe der MSAccess.exe reparieren. Auf alle Fälle sollte man sie regelmäßig komprimieren, geht auch mit der MSAccess.exe.

 

Wenn es mit nur 3 Usern problemlos auf dem RDP-Server funktioniert, könnten die fehlenden 2 User etwas bedeuten. Sie lasten, durch was auch immer, den RDP-Server sehr stark aus, die DB hatte Probleme und wurde durch die Reparatur wieder geheilt.

 

Beim Switch kannst Du die Firmware auf Aktualität prüfen.