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.
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 
ikar habt Ihr bei Euch den SQL Server auf dem David noch für andere Zwecke in Verwendung, als nur für den David selbst?
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:
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
Also, beim nächsten Mal, erst den SQL Server Dienst auf dem David Server neu starten, anschließend den Service Layer neu starten
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!
