SQL-Datenbanken aus NAV verwalten/komprimieren

Wenn hunderte von NAV-Datenbanken zu verwalten sind, dann ist auch der größte Platte schnell zu klein.

Bei der native DB war es relativ einfach, die aktuell benötige DB aus NAV heraus über ein Skript einzeln zu entpacken (mit 7z), mit der richtigen NAV-Clientversion zu öffnen (die verschiedenen Clientversionen kann man beim manuellen Öffnen auch im Kontextmenü auflisten und dann die DB über die rechte Maustaste öffnen), daran zu arbeiten und abschließend abends im Batchverfahren wieder zu packen.

Die nativen DB werden ja mittelfristig weniger werden, daher suche ich nach Verfahren , das vergleichbar komfortabel mit dem SQL-Server abzubilden. Mit NAV 2013 kommt ja noch erschwerend hinzu, dass man ohne SQL-Serverinstanz noch nicht mal mehr eine Tabelle in der Datenbank öffnen kann.

Der SQL-Server bietet ja die Möglichkeit eine Datenbank offline zu schalten. Danach könnte man sie ja verschieben, dort zippen, bei Bedarf wieder entzippen, online schalten, der eigenen Instanz zuordnen usw., oder ist das generell im Zusammenspiel mit NAV nicht machbar und eher Wunschdenken ? . Durch die Power Shell lässt sich über CmdLets einiges komfortabel erledigen, wie man z.B. hier sieht. Ich kann derzeit aber nicht abschätzen, ob unter solchen Operationen die Stabilität insgesamt leidet. Hat jemand Erfahrung mit solchen Anforderungen?

Bei der Suche nach Lösungen bin ich auch auf das Tool SQL Storage Compress gestoßen, hat damit jemand Erfahrungen ohne kennt andere Tools für diesen Zweck?

Hallo,

ich hab mir den Artikel nicht ganz genau durchgelesen, aber das kann schon funktionieren. Man erkauft sich den Plattenplatz aber durch eine höhere Prozessorlast, die das System wieder ausgleichen muss. Außerdem hast du eine zusätzliche Fehlerquelle im System, die an einer sehr gefährlichen, weil zentralen, Stelle sitzt. Wenn dieses Tool auf eine Page- Komprimierung setzt, dann kommt es auch noch auf die Verteilung und Größe der Daten, ob das System hier nicht noch zusätzlichen Overhead erzeugt, weil nicht auf saubere Plattenblöcke zugegriffen werden kann.

Zunächst würde ich mal alle Register der normalen Windowsund SQL- Möglichkeiten setzen (Datenbanken automatisch verkleinern, Wiederherstellungsmodell Einfach, Datenbanken auf komprimiertem Windows- Laufwerk ablegen,...) das kostet nichts und bringt auch schon eine ganze Menge.


Gruß, Fiddi

Wenn hunderte von NAV-Datenbanken zu verwalten sind, dann ist auch der größte Platte schnell zu klein.
...
Der SQL-Server bietet ja die Möglichkeit eine Datenbank offline zu schalten. Danach könnte man sie ja verschieben, dort zippen, bei Bedarf wieder entzippen, online schalten, der eigenen Instanz zuordnen usw., oder ist das generell im Zusammenspiel mit NAV nicht machbar und eher Wunschdenken ? . Durch die Power Shell lässt sich über CmdLets einiges komfortabel erledigen, wie man z.B. hier sieht. Ich kann derzeit aber nicht abschätzen, ob unter solchen Operationen die Stabilität insgesamt leidet. Hat jemand Erfahrung mit solchen Anforderungen?

Also ich mir nicht vorstellen, dass jemand es zuläßt die DB offline zu nehmen (, zu verschieben), und zippen zu lassen. Was spricht gegen eine normale SQL-Sicherung/Rücksicherung?

Volker

@vsnase

Also ich mir nicht vorstellen, dass jemand es zulässt die DB offline zu nehmen (, zu verschieben), und zippen zu lassen. Was spricht gegen eine normale SQL-Sicherung/Rücksicherung?

Kowa benötigt das als Testumgebung. Er muss diese Anzahl DBs vorhalten, um die ganzen unterschiedlichen Kunden- und NAV- Versionen testen zu können .

Gruß, Fiddi

Schon klar, aber die DB soll ja möglichst dem aktuellen Kundenstand entsprechen und der erlaubt bestimmt nicht dauernd ein Offline nehmen der DB.

Aber was ist denn mit VM's. Für jeden Kunden eine VM, sobald die runtergefahren ist kann man die Verschieben wohin man will und bei bedarf auch gleich wieder zurück.

Was ich noch nicht ausprobiert habe ist der TFS um die ganze Entwicklungsarbeit in einer zentralen Unternehmensstelle zu sammeln und zu koordinieren. Ist zwar primär für VS gedacht, sollte aber auch mitanderen Projekten zurecht kommen.

Volker

Aber was ist denn mit VM's. Für jeden Kunden eine VM, sobald die runtergefahren ist kann man die Verschieben wohin man will und bei bedarf auch gleich wieder zurück.

Das würde hunderte von VM's bedeuten. Die DB gehören jeweils zu einem Kunden (nicht unsere direkten Kunden, sonden Endkunde des MBSP die unsere Add-ons für ihren Kunden bestellen).

Schon klar, aber die DB soll ja möglichst dem aktuellen Kundenstand entsprechen und der erlaubt bestimmt nicht dauernd ein Offline nehmen der DB.

Das bekommt der Endkunde ja gar nicht mit. Die Kunden-DB "schlafen" ja , bis sie wieder benötigt werden, weil der Kunde ein Upgrade plant oder sonst irgendetwas etwas geprüft werden muss. Erst dann müssen die möglichst zügig wieder aktiviert werden können und ggf. mit dem letzten Objektstand versorgt werden können. In den meisten sind auch keine Kundenmandantendaten erhalten, weil unsere Add-ons auf Basis des Cronus-Mandanten entwickelt werden und unter diesen Bedingungen geprüft werden. Viele sind zu unserem Auslieferzeitpunkt auch schlicht NAV-Standard + Add-on, weil das beauftragende MBSP die Kundenversion dann später selber dazumergt, bevor das dann an den Endkunden ausgeliefert wird.

Ich würde bei so einem Szenario so wenig Schritte wie möglich vornehmen.
Ich würde da an der Stelle das Komprimieren dem SQL Server überlassen und nicht einem weiteren Tool und damit eine weitere mögliche Fehlerquelle schaffen.

Plattenplatz ist ja nun nicht wirklich teuer.

Vorteilhaft ist auch definitiv das Wegfallen der xp_ndo unter NAV2013.

Wenn man eh nur einen Cronus Mandanten für einen Kunden hat und nicht die DB mit Mandantendaten, ist die Frage aus meiner Sicht eher, ob es überhaupt sinnig ist so ein Verwaltungskonstrukt aufzubauen, wenn man 200 x ~2GB Datenbanken hat. Das sind ~400GB, die du nicht mal über ein SAN redundant vorhalten musst. Wenn man das gegen Erstellung, Wartung und Nutzung durch Personal durchführt, welches stattdessen Dienstleistungen an Kunden fakturieren könnte, sind die Personalkosten definitiv höher als 400GB Plattenplatz anzuschaffen.