Fiktives Worst Case Szenario

[PMP161316]

Hallo,

ich bin zur Zeit am überlegen, was ich machen kann, wenn mein Navision Server einmal richtig den Geist aufgibt.
Nehmen wir an, der ganze Navison Server (NativeDB) löst sich um 14:00 Uhr in Rauch auf:
- beide Festplatten des Raid1 sind nicht mehr zu gebrauchen.
- natürlich habe ich mind. eine Hotcopy Sicherung auf einem NAS und auf Band ... nur eben den Stand aus der Nacht zuvor.
- alle Daten, die im Laufe des Tages geändert wurden sind in dieser Sicherung nicht enthalten.

Wie sichert ihr euch gegen einen solchen "Worst Case" ab?
Gibt es mit der Native DB überhaupt eine Möglichkeit davor sicher zu sein?
Gibt es vielleicht so etwas wie ein Transaction Log, das ich automatisch auf meinem NAS ablegen lassen kann und dessen Änderungen ich im Notfall in die Backup-DB übernehmen kann ?

Mit freundlichen Grüßen,

PMP161316

[McClane]

Du könntest den Server spiegeln

[PMP161316]

Ja, das würde dann aber einen ständigen Abgleich der Festplatten vorraussetzten.
Die einzige mir bekannte Möglichkeit so etwas zu machen ist ein RAID1 over TCP unter Linux ... dummerweise gibt es den Navision Server nicht für Linux.
Natürlich kann ich nicht einfach die DB-Datei im laufenden Betrieb ständig auf den zweiten Server kopieren.
Gibt es andere Möglichkeiten 2 Server immer genau identisch zu halten?

[fiddi]

Hallo PMP161316,

eine weitere Alternative wäre die Verwendung einer Storrage- Lösung. Bei einigen von Ihnen gibt es, so viel ich weiß, die Möglichkeit den Plattenspeicher zu spiegeln.
Ob das allerdings billiger ist, als ein SQL-Server ist fraglich.

Gruß, Fiddi

[AlterHase]

Sorry, diese Lösungen halte ich für fahrlässig. Es geht hier immerhin um das Stück Software, an der das komplette Unternehmen hängt.

Die NativeDB ist definitiv in punkte Ausfallsicherheit die schlechteste Lösung. Hier muss abgewogen werden zwischen günstig und sicher. Beides werdet Ihr mit professionellen Mitteln wohl kaum hinbekommen.
Sattelt um auf SQL und fahrt mit Transactionlog-Backups oder Replikation auf einen Standby-Server. Ein potenzieller Systemausfall kostet schnell ein zigfaches der Anschaffungssumme.

[PMP161316]

Vielen Dank für die Antworten.
Wie ich befürchtet habe, gibt es also keine Möglichkeit, die Native DB wirklich ausfallsicher zu betreiben.
Zum Vorschlag einer MSSQL-DB:
Gibt es hier im Forum oder irgendwo im Internet einen Leistungs-/Geschwindigkeitsvergleich zwischen Native- und SQL-DB?
Ich habe zwar schon des öfteren danach gesucht, aber keine klaren Aussagen finden können.

[fiddi]

Also die Anforderungen an die Hardware sind sicherlich höher als bei der Native-DB, dafür gibt es aber i.d.R. weniger Tabellensperren, und die Möglichkeit mit den Reporting- Sevices Auswertungen zu fahren.

Du solltest bei einem Einsatz von MS-SQL aber auf jeden Fall deine technische Umgebung auf NAV5.0SP1 bringen, da diese mit dem SQL-Server wesentlich performanter läuft als deine 3er- Version

Gruß, Fiddi

[vsnase]

Ich hätte da vielleicht noch was. Das ganze auf Win 2008 oder SBS2008 betreiben. Mit dem Block-Based-Bauckup kann man da doch ziemlich regelmäßg und schnell auf eine exteren HD sichern.

Volker

[PMP161316]

Vielen Dank für die Antworten.
Ich bin mit "Block-Based-Backup" nicht vertraut, ich werde mich darüber informieren.
Hat jemand noch eine Antwort auf meine zweite Frage:
Gibt es hier im Forum oder irgendwo im Internet einen Leistungs-/Geschwindigkeitsvergleich zwischen Native- und SQL-DB?

[McClane]

Ich denke, dass man da schlecht eine Pauschal-Aussage treffen kann. Je nach DB-Größe, NAV-Version, Anzahl der User und der Hardware dürfte es ganz unerschiedliche Ergebnisse geben.

Seine Stärken hat der SQL-Server nach meiner Erfahrung im besseren Sperrverhalten und, wenn durch Table Relations Dinge ausgelöst werden, die auf den manchmal ungüstigen PK zurück greifen. Als Beispiel: das Umbenennen eines Artikels hat bei mir früher 40 min gedauert und durch die Tabellensperren in dieser Zeit quasi allen anderen Usern das Arbeiten unmöglich gemacht. Seit SQL dauert der ganze Spaß 30 Sekunden. Andere Dinge, wie zB ein kompletter Planungslauf, laufen um den Faktor 2 schneller. Während der "normalen" Arbeit bemerkt man aber keinen großartigen Unterschied.

Andrerseits können Fälle auftreten, in denen Aufgaben auf dem SQL-Server zuerst einmal langsam laufen und verbessert werden müssen. Zu dem Thema findest du hier einige Beiträge.

Dazu muss man allerdings sagen, dass die Hardware des SQL-Servers wesentlich höher dimensioniert ist als der alte Server, auf dem die Native lief. Trotzdem hat sich der Umstieg absolut gelohnt.