SQL-Server *.sql-Datei?

[Nightflyer2000]

Hi Leute,

also nachdem ich begeistert von mySQL und Linux bin, was die Sicherung betrifft, würde ich mir sowas auch für *** SQL Server 2000 wünschen.

Also mein Ziel ist es, am Ende möglichst mit ein paar Befehlen wie stoppen des SQL-Servers, Export und starten des SQL-Servers (in einer Batch-Datei) eine *.sql-Datei zu haben, welche sich dann ja problemlos an jedem anderen SQL-Server wieder einspielen lässt.

So habe ich es mit mySQL und Linux versucht und es klappt einwandfrei.

Ist sowas mit *** SQL-Servern auch zu realisieren? Bis jetzt hatte ich mit SQL von *** noch nicht viel zu tun und habe auch auf Anhieb nix passendes gefunden...

Danke schon mal für alle Antworten...

:confused:

[Goos]

Wo waere da der Vorteil zu der normalen Sicherung die der SQL Server anbietet?

Dass man den Server zum sichen stoppen muss oder wie?

Goos

[Nightflyer2000]

Also den Vorteil erhoffe ich mir dadurch, dass ich eine Art "universelle" Sicherung habe, die ich im Notfall eines HDD-Crashs oder so auf jedem x-beliebigen SQL-Server wieder einspielen kann und nicht genau diese SQL-Version brauche, die ich vorher hatte.

Bis jetzt werden noch viele SQL-Server einfach so gesichert, indem einfach das SQL-Verzeichnis auf Band geschrieben wird.

Das sollte geändert werden, um eben nicht an einen SQL-Serve und eine SQL-Server-Version gebunden zu sein...

:cool:

[just_me]

Stop! Stop! Stop!

Also mein Ziel ist es, am Ende möglichst mit ein paar Befehlen wie stoppen des SQL-Servers, Export und starten des SQL-Servers (in einer Batch-Datei) eine *.sql-Datei zu haben, welche sich dann ja problemlos an jedem anderen SQL-Server wieder einspielen lässt.

Das macht <NULL> Sinn.

Der Trick ist es doch eigentlich, die Daten mit 100% Sicherheit wiederherstellen zu können, nicht wahr?

Warum sollte ich also meine Daten dem Risiko möglicherweise nicht 100% kompatibler Attribute fremder Datenbanken aussetzen? Macht es nicht - rein logisch - viel mehr Sinn, wenn man nicht nur den Inhalt, sondern die "Tüte" gleich mit sichert? Noch dazu, wo dieses "Tüte" kaum Platz in Anspruch nimmt?!

MS SQL Server bieten dir verschiedene Optionen, Strategien und Möglichkeiten an, die Ausfälle auf ein absolutes Minimum zu beschränken.

Die "einfachste" - und sicherlich von dir gesuchte - Möglichkeit ist es, den Befehl Backup zu verwenden, ein SQL-Script zu erzeugen, und dieses alsTeil eines Auftrages automatisch; oder meinethalben auch per selbstgebastelter Scripte (WSH bietet sich förmlich an) auszuführen.

Das so erzeugte Backup, das dann "an der regulären Sicherung vorbei" erstellt wurde, kannst du dir ja ausdrucken und sicherheitshalber auswendig lernen - nur für den Fall, dass es einen Großbrand gibt, und sämtliche Sicherungsmedien das Zeitliche segnen ...

Nein, im Ernst: Die Datensicherung erfolgt i.d.R. IMMER zusammen mit dem Container. Alles andere ist zu viel Gottvertrauen.

Stelle dir doch mal vor, deine Datenbank reisst die Hufe hoch, ist nicht mehr restaurierbar, und du solltest anhand der vorhandenen Daten die du als reines .sql-script á là "INSERT INTO table1 (feld1, feld2, feld3) VALUES (wert1, wert2, wert3)" vorliegen hast, bestimmen, ob "feld1" nun ein varchar(75) oder doch eher ein varchar(60) ist.

Kein Problem, sagst du!? Wen interessiert es, wenn die Daten sowieso nur maximal 50 Zeichen lang zu sein scheinen!? Nun, i.d.R. gibt es Anwendungen, die diese Daten schreiben, und diese erwarten nun einmal fest definierte Attribute, da wäre jede noch so kleine Änderung schlicht tödlich ... zumindest aber verdammt riskant.

Und was die "SQL Server Version" angeht:

Ich weiß nicht, wer dir diesen Bären aufgebunden hat, aber in jedem Fall kannst du ihm/ihr einen schönen Gruß bestellen. Wenn du so leicht zu foppen bist, dann muss die Arbeit mit dir recht lustig sein.

Das Backup ist WEDER an einen bestimmten Server (was purer Wahnsinn wäre), NOCH an eine bestimmte Version gebunden. Letzteres gilt natürlich eingeschränkt, denn rückwärtige Inkompatibilitäten sind nicht immer vollständig auszuschließen, aber die Wahrscheinlichkeit, dass ihr nicht gerade 3 oder 4 Generationen an DBMS überspringt ist doch wohl tendenziell eher als hoch einzustufen, oder?

Und falls du all das trotzdem noch als zu unsicher empfindest, dann lass dich doch einfach mal von den Data Transformation Services (DTS) überraschen. Das Festlegen einer automatisierten/manuell gestarteten Aktion in Kombination mit diesen DTS erlaubt dir, mit wenigen Klicks/Befehlszeilen alle beliebigen Daten aus beliebigen Quellen in beliebige Daten beliebiger Ziele zu schreiben. Das Erstellen von .csv, .xls, .mdb, und und und -Dateien gehört für die DTS zu den eher kleinen Übungen.