20. Dezember 2007 11:24
Hallo,
Wir haben unsere Navision Installation mit knapp 80 Mandanten von der C/Side Datenbank auf eine MSSQL Datenbank umgestellt.
Als Resultat finde ich jetzt im SQL Server 95208 Tabellen wieder, die es mir unmöglich machen auch nur irgendwas im Bereich der navision Datenbank mit dieser anzufangen, da die Fenster nach dem aufklappen des Unterpunktes Tabellen für bis 4 Stunden hängen.
Sind die Vielzahl der Tabellen Navision Standard und ist dort Besserung in Sicht?
Danke
Nielo
20. Dezember 2007 11:50
Hi,
bei meinem alten Arbeitgeber hatte man max 100 Mandaten pro DB gemacht, da es ab 150 ca gar nicht mehr richtig funktionierte. Natürlich ist das auch abhängig von der Größe der Mandanten.
Jedenfalls finde ich das auch ziemlich schade das man in NAvision nicht (standardmäßig) sagen kann welche übergreifenden Tabellen für die speziellen Manddanten gelten, vieles ist leider pro Mandant gekapselt und so legt man fleißig redundante TAbellen an.
Soweit ich das sehe ist das wohl Navision Standard das pro Mandant immer diese Masse an Tabellen angelegt wird, naja dazu kommen ja noch die ganzen SIFT Tabellen usw. Wenn Du mal alle Tabellen (alle Objekte) SQL mäßig zählst wirst du eine böse Überraschung erleben. Auch eine Aktion wie z.B. Madant umbenennen könnte rein über SQL über 24 Std. dauern. Naja ich höre jetzt lieber auf Navision hat auch seine guten Seiten ;.)
Ciao Tesa.
20. Dezember 2007 14:21
Ja, anders als bei der nativen DB - wo der "Mandant" soz. nur ein Flag in der Tabelle war - muss bei SQL Server jeden Tabelle (DataPerCompany = Yes) pro Mandant angelegt werden, andernfalls würde man in extreme Sperrproblematiken und andere Performance-Probleme hineinlaufen ...
Meine Empfehlung ist: Alle Tabellen, die ihr eh nicht nutzt, im "Object Designer" zu löschen und nur die übrig zu lassen, die in eurem Business notwendig sind.
Vor allem sollte die Notwendigkeit diverser - umfangreicher - Zusatzmodule überprüft werden (die "standardmäßíg" meist mit installiert werden): Commerce Gateway/Biz Talk, Payroll, Cost Accounting, etc..
Das ist zwar riskant und erfordert ausgiebige Tests, wird aber im Resultat eine erhebliche Entlastung für das System darstellen.
20. Dezember 2007 15:49
stryk hat geschrieben:Das ist zwar riskant und erfordert ausgiebige Tests, wird aber im Resultat eine erhebliche Entlastung für das System darstellen.
--> verstehe ich nicht. Welchen Vorteil hat man wenn man eine Tabelle mit 0 Sätzen löscht - ausser das im Enterprise Manager bzw. Mgmt. Studio weniger Tabellen angzeigt werden?
20. Dezember 2007 16:12
- Code:
ausser das im Enterprise Manager bzw. Mgmt. Studio weniger Tabellen angzeigt werden
Weil genau das, das Problem ist! Bei derartig vielen Tabellen können diese im Management Studio nicht mehr angezeigt werden, das "Aufklappen" dauert im beschriebenen Fall mehrere Stunden ... das Problem kann nur dadurch verringert werden, indem man die Anzahl der Tabellen(-objekte) reduziert ...
20. Dezember 2007 16:29
Verstehe. Nach dem löschen der leeren Tabellen - wie testet man hier richtig? Versuchen ob sich noch alle Objekte kompilieren lassen, alle benötigten Funktionen ausprobieren? Wie geht man hier zeitsparend vor?
Danke
20. Dezember 2007 16:39
Kompilieren wäre mein erster Schritt.
Und das auch nur häppchenweise (also z.B. einen Teil der Tabellen).
Der Compiler meldet dann schon, wenn er Verknüpfungen zu der gelöschten Tabelle findet. Die zu entfernen wird nicht immer einfach sein, wenn man den Quelltext, in dem sie verwendet wird, nicht richtig versteht.
Hilfreich in dem Zusammenhang ist sicherlich aus das NDT.
Am besten noch vor Löschung einer Tabelle nachschauen, wo diese überall verwendet wird.
Hört sich alles in allem sehr zeitaufwendig an.
27. Dezember 2007 16:33
hmm, wäre es nicht sinnvoller und einfacher, die Mandanten in mehrere Datenbanken zu verlegen(falls das geht)?
also evtl. solche, die keinerlei übergreifende Auswertungen benötigen usw.
28. Dezember 2007 10:47
wirtnix hat geschrieben:hmm, wäre es nicht sinnvoller und einfacher, die Mandanten in mehrere Datenbanken zu verlegen(falls das geht)?
Technisch funktioniert das schon. Jedoch zieht das zusätzliche Lizenzkosten auf sich und die Wartungsaufwand nimmt auch zu.
mfg
Jürgen
2. Januar 2008 10:30
Vielen Dank für die zahlreichen Antworten.
Mehrere Datenbanken wäre für vieleicht für die Verwaltungsgesellschaften eine Option, da diese relativ wenige Buchungen haben und auch keine Auswertungen von Nöten sind.
Wir nutzen hier ExpandIT Backup.
Leider läuft das Backup knappe 4 Stunden seit der Umstellung auf MSSQL
Fällt das in die gleiche Kategorie wie die Tabellenzahl und lässt sich damit nicht optimieren?
Nielo
8. Januar 2008 14:05
Servus Nielo, wenn ihr NAV jetzt unter SQL verwendet dann benötigst du ja Expandit Backup nicht mehr. Ihr könnt ja dann direkt unter unter SQL ein Backup erstellen - es gibt auch Wizards dafür
mfg
Jürgen
10. Januar 2008 11:29
Hallo Nielo,
also ihr solltet auf jeden Fall auf dieses ExpandITBackup verzichten und SQL AUfträge am SQL-Server anlegen welche dann die Sicherungen der einzelnen Datenbanken vornimmt. So erhälst Du dann konsistente Backup-Files je Datenbank. Das geht auch viel schneller.
Außerdem würde ich empfehlen falls es sich um Produktivdatenbanken handelt eine Sicherung einzurichten (vollständiges Wiederherstellungsmodell), welches eine Rücksicherung zu jedem beliebigen Zeitpunkt ermöglicht. Das bekommt man über den Wizard nicht.
Außerdem empfiehlt es nicht noch Rebuild Index und 2-3 weitere Wartungsschritte z.b. am WE laufen zu lassen (auch per Auftrag).
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.