Archive-Pfad ändern

  • im ereignisprotokoll sind meldungen unter system (siehe bilder) vorhanden, ebenso unter anwendung.

    ich werde den sql- und david-server heute abend von zuhause neustarten. aktuell im betrieb ist es nicht machbar.


    btw: ich habe mir mittels veeam das vorhandene david-backup angesehen. alle dateien/ordner sind noch vorhanden.

  • ikar ich denke zwar das dies keine Auswirkungen haben sollte, weil die Datendateien vom SQL Server eigentlich so oder so nie die nötigen Kriterien für eine Deduplizierung aufweisen, dennoch würde ich empfehlen deren Pfad noch aus der Deduplizierung auszuschließen.
    Der Pfad sollte bei einer Standardinstallation stets wie folgt lauten:
    \programme\david\code\database

  • ist es möglich, den archive-pfad auf ein NAS zu legen? - falls ja, gibt es ein howto oder tool dafür?

    Ich wollte dazu noch etwas schreiben, da ich vor kurzem selber vor dieser Überlegung stand. Nach einiger Recherche habe ich herausgefunden, wie man Ordner auf andere Festplatten oder sogar ins Netzwerk auslagern kann. Von Letzterem würde ich allerdings abraten, da beim kleinsten Schluckauf im Netzwerk der Kessel am dampfen ist. Von daher möchte ich nur auf die erste Variante eingehen.

    Bei uns steht bald eine Neuinstallation an, bei der ich dann ebenfalls diverse Ordner auf verschiedene Festplatten verteilen möchte. Dafür habe ich schon ein paar Tests gemacht. Ich packe hier mal mein für mich geschriebenes Tutorial als Anhang mit hinzu, wie man einen Ordner auslagern kann. Das kannst du dir ja mal anschauen, vielleicht hilft es dir weiter.

    Disclaimer: Ich habe das Ganze noch nicht live im Einsatz, die ersten Tests (grundlegende Funktionalität, Datenbereinigung) sahen aber gut aus. Ob das Auswirkungen auf andere Bereiche (SQL Server, Datendeduplizierung, etc) hat, kann ich noch nicht beurteilen.

  • der serverneustart hat es wieder gefixt! allerdings hätte es wohl genügt, nur den david-server neu zu starten, da nach dem rebooten des sql-servers das problem weiterhin bestand.

    @riawie: ich habe den pfad aus der deduplizierung ausgeschlossen.

    Einmal editiert, zuletzt von ikar (5. Mai 2021 um 19:36)

  • ikar das dürfte wohl ein Trugschluss sein.
    Wenn der SQL Server keine Verbindungen vom Service Layer mehr angenommen hat - was laut Deinen Infos oben der Fall war - kann es zwar im besten Fall ausreichen nur den SQL Server neu zu starten und es kann durchaus klappen das der Servicelayer das dann später mitbekommt, das muss aber nicht der fall sein, in dem Fall muss man dann auch den ServiceLayer noch neu starten. Was bei dem Fehlerbild jedoch nie funktionieren wird ist nur den ServiceLayer neu zu starten, denn der wird dann hinterher dennoch am SQL Server scheitern.

    Ein ServiceLayer Neustart ist übrigens normaler Weise auch tagsüber unkritisch, der dauert selbst im schlimmsten Fall deutlich weniger als 30 Sekunden und die Clients setzen anschließend Ihre Arbeit fort als wenn nichts gewesen wäre.
    Ich muss sowas nicht häufig machen, aber wenn, dann hatte ich hier bei im Schnitt 75 Nutzern nur selten mehr als zwei oder auch mal drei die es überhaupt bemerkt haben.
    Wenn der SQL Server mal klemmt geht allerdings nicht nur der Chat nicht, sondern auch die Suche hängt. Daher starte ich dann in jedem fall beides auch mitten am Tag neu. Selbst die Anwender welche den Neustart des ServiceLayers mitbekommen nehmen diesen minimalen Hänger lieber hin als für den Rest des Tages keine suche zu haben ;)

  • dass der neustart des service layers nur einen kleinen minimalen hänger verursacht, habe ich bereits mitbekommen. ich musste das schon einige male neustarten. den sql-server dagegen kann ich nicht einfach mittendrin mal rebooten, da davon einiges mehr abhängt, auch wenn es aufgrund einer virtuellen maschine schnell geht.

  • die installation bzw. den umzug auf die virtuellen server und die einrichtung hat ein it-systemhaus vorgenommen. so wie ich das mitbekommen habe, nutzen wir einen eigenen virtuellen sql-server, über den auch datev und banking läuft.

  • die installation bzw. den umzug auf die virtuellen server und die einrichtung hat ein it-systemhaus vorgenommen. so wie ich das mitbekommen habe, nutzen wir einen eigenen virtuellen sql-server, über den auch datev und banking läuft.

    Das passt nicht zu Deinem Bild einer der Meldungen von weiter oben:
    1270-fehler-1-jpg

    Das solltest Du folglich noch mal genauer prüfen.
    Denn wenn Ihr real doch den standardmäßigen SQL Express Server welchen David bei seiner Installation mit auf dem David Server installiert nutzt würde das bedeuten das Du zukünftig bei derartigen Fehlern schneller für Abhilfe sorgen kannst ;)

  • ich habe mir mal die apps auf dem david-server angesehen und ja, da ist der ms sql server 2017 installiert. das würde evtl. auch erklären, wieso der chat nach dem reboot des dedizierten sql-servers noch nicht lief.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!