Datenbank (Backup/Mirroring/Log Shipping)

Hallo zusammen,

ich habe mir die Finger wundgegoogelt aber leider keinen Hinweis gefunden. Verzweifelt sind wir auf der Suche nach einer praktikablen Lösung aus den Bereichen

Backup / Mirroring / Log Shipping.

Aber zunächst mal meine Umgebung:

Win 2008 Server
Native Datenbank (5.01), ca. 200 GB groß, Update auf SQL Server momentan nicht möglich da zuviel angepasst.
Das Ganze läuft auf einer VMWare VM.

Leider kann ich diesen Server lediglich einmal am Tag sichern (mit Veeam Backup&Replication), da bei der Snapshoterstellung der Maschine ein paar Pings verlorengehen und somit
alle User "rausfliegen". Also dachte ich, wir könnten es ja mal auf Datenbankebene versuchen, aber.....

Es kann doch nicht sein, dass es keinen Drittsoftwarehersteller oder sonstiges gibt, um mit der Datenbank vernünftiges inkrementelles Backup (NO HOTCOPY ), Mirroring oder Log Shipping
durchzuführen? Oder doch? Vielleicht hat hier ja einer einen Vorschlag.

soll das mit der SQL-Migration ein Scherz sein - zu viel angepasst, deswegen nicht möglich => WARUM - wegen nicht vorhandener SQL-optimierter Programmierung?
ne 200GB große native DB - ich habe meine größte 110GB native DB auf SQL migriert und frage mich, wie der
Kunde auf nativ noch arbeiten konnte.
mein Beitrag mag wohl nicht besonders produktiv sein, da ich dir keinen Lösungsansatz unterbreiten kann, aber ich möchte einfach wissen, warum ihr nicht migriert, denn das ist aus meiner Sicht ein Spiel mit dem Feuer....

weiterhin würde mich interessieren, wie lange ihr braucht, die 200gb zu restoren

Hallo,

ein inkrementelles Backup einer Native-Datenbank ist meines Wissens nach nicht möglich.
Und da es bei einer Native-Datenbank auch keine Log-Files wie beim SQL-Server gibt, ist auch ein Backup von Log-Files nicht möglich.
Um automatisch ein Navision-Backup (fbk-Files) zu erstellen, könntest du von ExpandIT das Tool BackupIT ausprobieren.
Allerdings wird das Erstellen dieses Backups bei einer DB-Größe von 200 GB ziemlich viel Zeit beanspruchen.

Gruß
Jörg

Hallo,

das mit der nicht möglichen Konvertierung auf SQL verstehe ich auch nicht, da die Konvertierung normalerweise nichts mit der Programmierung zu tun hat, sondern nur mit den Daten.

Beachten musst du lediglich die geänderte Sortierung von Belegnummern zwischen Native ('1','2','3','10','20','30') und SQL ('1','10','2','20','3','30'). Hast du aber schon bei der Anlage aufgepasst, und deine Nummernserien mit einer festen Länge versehen (A00000010), hast du auch das Problem nicht.

Für die Datensicherung kommt bei dir mit der nativen DB wohl nur HOTCOPY in Frage. Da ein Restore einer FBK zusätzlichen DB-Platz benötigt. D.h. wenn du eine FBK deiner 200GB- DB restoren willst, solltest du eine DB mit mindestens 250 - 300 GB haben. Lässt eure Lizenz das zu?

Ein Restore aus FBK in Native oder auch SQL dürfte je nach Hardware 1 bis 2 Tage dauern. Mit einer SQL-BAK ist das in 1-2 Stunden erledigt.

Gruß, Fiddi

Win 2008 Server
Native Datenbank (5.01), ca. 200 GB groß, Update auf SQL Server momentan nicht möglich da zuviel angepasst.
Das Ganze läuft auf einer VMWare VM.
[...]
Es kann doch nicht sein, dass es keinen Drittsoftwarehersteller oder sonstiges gibt, um mit der Datenbank vernünftiges inkrementelles Backup (NO HOTCOPY ), Mirroring oder Log Shipping
durchzuführen? Oder doch? Vielleicht hat hier ja einer einen Vorschlag.

Was hast du gegen Hotcopy? Du kannst damit beispielsweise über Nacht im laufenden Betrieb die Datenbank sichern.
Das sollte bei 200 GB auch nicht mehr als 3-4 Stunden dauern. Rücksichern sollte auch verträglich sein, da man die Datenbankteile direkt kopiert und kein Schlüssel aufbauen muss.
Man kann mit Hotcopy auch einen "kleinen" Integritätscheck druchführen.
In der Logfile steht dann auch ob das Backup erfolgreich war oder nicht.

Backup completed successfully at ...

Man könnte Hotcopy mit dem Windows-Scheduler starten und dann in einer Batch-Datei die Logfile auswerten

Code:

REM Backup nur archivieren, wenn zuvor das Backup erfolgreich war
findstr /C:"Backup completed successfully" <Logfile-Hotcopy-Pfad>
IF %ERRORLEVEL% == 0 (GOTO OK_BACKUP) ELSE (GOTO ERR_BACKUP)

mfg,
winfy

Zuletzt geändert von winfy am 27. März 2014 17:01, insgesamt 3-mal geändert.

Leider kann ich diesen Server lediglich einmal am Tag sichern (mit Veeam Backup&Replication)

Das mit dem Veeam-Backup kann sehr gefährlich werden, wenn du mehrere Datenbankteile hast.

NAV merkt sich in der Native in jedem Datenbankteil einen Timestamp, stimmen die bei deiner gesicherten Version nicht überein, hast du eine korrupte Datensicherung.

Deshalb vor der Sicherung immer den Native NAV-Server- Dienst stoppen, der hat von VSS noch nichts gehört.

Gruß Fiddi

Hallo zusammen,

zunächst einmal vielen Dank für die interessanten und vielfältigen Antworten. Das hat mir wirklich weitergeholfen. Einige Fragen bzw. Anmerkungen hätte ich doch noch...

1. Die native Datenbank unterstützt nichts, ausser Backup via Hotcopy?! Es ist aber möglich ein technisches Update der Datenbank auf eine SQL-Datenbank zu machen ohne
die Programmierung, Objekte etc. zu verändern?! Muss ich dabei Versionen beachten? Wie geht das technisch vonstatten? Hat jemand einen Link zu einem
"best practice", "how-to" oder sonstwas wie man die Daten migrieren, konvertieren muss?

2. Danke für den Tipp mit Veeam. Die Tests waren eigentlich bisher immer erfolgreich. Werde künftig aber trotzdem den Serverdienst vorher beenden.

3. Warum ich kein Hotcopy benutze? Das dauert bei der Größe viel zu lange inklusive Performance-Impact etc. Dabei habe ich mit der Replikation eine exakte Kopie
der virtuellen Maschine und kann diese innerhalb von Minuten startklar haben. Meine Suche geht daher mehr in Richtung High Availability bzw. Disaster Recovery.
Der Server ist 20 Stunden täglich produktiv, d.h. es reicht einfach nicht mehr diesen nur 1x in der Nacht zu sichern.

Die native Datenbank unterstützt nichts, ausser Backup via Hotcopy

Natürlich funktioniert die FBK- Sicherung auch, aber kannst du Sie auch wieder herstellen in Native? Ein Restore in SQL wird schon funktionieren, wenn die Daten sauber sind (keine Datumsfelder vor 1793??, Codefelder fehlerfrei und keine Sonderzeichen).

Vor der Migration auf SQL wird zunächst die Native DB auf die o.g. Fehler geprüft und ggf. korrgiert. Das dauert bei deiner DB wohl ein bis zwei Tage, wenn du das mit dem Standardtool von MS machst
Bei mibuso gibt es dafür ein Tool (Fieldcheck), das erheblich schneller ist (Allerdings dauert auch das mehrere Stunden).
Es ist keine gute Idee auf diesen ersten Schritt zu verzichten, da ich noch keine Native-DB erlebt habe, die nicht schon vor dem Jahr 100 Bewegungen hatte.
Solltest du nicht alle Fehler korrigiert haben, kannst du zwar eine FBK- Sicherung ziehen, auch der Restore in den SQL lässt sich noch starten, bricht aber dann ab, wenn er fehlerhafte Daten findet. Im Zweifel also nach einem Tag Restore 10 Sekunden vor dem Abschluss.

Danach musst du nur noch deine Clients auf SQL umstellen, und deine Nummern in den Posten/Belegen/Fibukonten/Kontenschemata auf gleiche Länge anpassen, falls gewünscht/nötig (funktioniert am besten auf SQL- Ebene).

Gruß, Fiddi

Ein paar kleine Fallstricke die mir gerade einfallen:

- Alle Code Felder werden nach der Umstellung nicht alphanumerisch sortiert sondern wie Text.
z.B. Kundennummern, Artikel, Belegnummern, Kontonummern usw. (wie Fiddi schon sagte)

- Es kann dann zu anderen Verhalten und Performanceproblemen führen. Ihr müsstet die Objekte mit festen Filtern in Properties/ bzw. C/AL prüfen ob die das berücksichtigen.

- USERID war in der nativen Datenbank immer Großbuchstaben
IF USERID='ADMIN' THEN ... müsste man unter Umständen abändern in IF UPPERCASE(USERID)='ADMIN' THEN

- Ihr solltet die SQL Umstellung vorher in jedem Falle auch einem Performance Check unter realistischen Bedingungen unterwerfen. Siehe Unterschied NAV2009 Native vs NAV2009 SQL (Link), (Link)

mfg,
winfy