8
SQL 2005 Server - Datenbanken sichern
Hallo zusammen,
Wir haben einen MS SQL 2005 Server und haben festgestellt, dass wohl seit 3 Jahren nicht mehr gesichert wird. Wir haben Arcserve ein Sicherungssoftware im Einsatz. Die .MDF Datenbankdateien werden auf Band gesichert. Jedenfalls bekommen wir dazu keine Fehler im Jobprotokoll angezeigt. Den SQL Agent im Arcserver haben wir nicht lizensiert, sprich wir sichern nur per Datei die Datenbank ab.
1. Reicht unsere Dateisicherung der Datenbank aus?
2. Habe ich gehört, dass man einen vollständigen SQL Server, also nicht die Express Version, per Dateisicherung sichern kann?
3. Wie erkenne ich, ob ich eine Express oder einen vollständigen SQL Server habe?
Wäre über eine Antwort dankbar.
Wir haben einen MS SQL 2005 Server und haben festgestellt, dass wohl seit 3 Jahren nicht mehr gesichert wird. Wir haben Arcserve ein Sicherungssoftware im Einsatz. Die .MDF Datenbankdateien werden auf Band gesichert. Jedenfalls bekommen wir dazu keine Fehler im Jobprotokoll angezeigt. Den SQL Agent im Arcserver haben wir nicht lizensiert, sprich wir sichern nur per Datei die Datenbank ab.
1. Reicht unsere Dateisicherung der Datenbank aus?
2. Habe ich gehört, dass man einen vollständigen SQL Server, also nicht die Express Version, per Dateisicherung sichern kann?
3. Wie erkenne ich, ob ich eine Express oder einen vollständigen SQL Server habe?
Wäre über eine Antwort dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 122854
Url: https://administrator.de/contentid/122854
Ausgedruckt am: 24.11.2024 um 07:11 Uhr
8 Kommentare
Neuester Kommentar
Wow früh gemerkt
Also die Datenbankdateien so einfach wegsichern würde ich nicht. Wenn ihr die keinen SQL Agenten habt würde ich einen Wartungsplan einrichten. Eftl. auch mit Transaktionsprotokollen und Datenbankbereinigung Geht Recht schön über das Management Studion. Da kann man gleich auf Band sichern oder in Datei und dann mit Arcserv.
Im Management Studio kanns du dir auch Anzeigen lassen ob's ein Express ist oder nicht. Das sieht man unter Eigenschaften des obersten Punktes des Objekt-Explorers
Also die Datenbankdateien so einfach wegsichern würde ich nicht. Wenn ihr die keinen SQL Agenten habt würde ich einen Wartungsplan einrichten. Eftl. auch mit Transaktionsprotokollen und Datenbankbereinigung Geht Recht schön über das Management Studion. Da kann man gleich auf Band sichern oder in Datei und dann mit Arcserv.
Im Management Studio kanns du dir auch Anzeigen lassen ob's ein Express ist oder nicht. Das sieht man unter Eigenschaften des obersten Punktes des Objekt-Explorers
Moin cordial,
und um Frage 1 ("Reicht unsere Dateisicherung der Datenbank aus?") eindeutig zu beantworten.
Absolut NEIN. Eher sogar im Gegenteil, denn die vermeintlich gesicherte MDF-Datei enthält einen undefinierten Zustand, einen Zufalls-Snapshot, der genau das enthält, was die diversen Writer-Prozesse persistiert haben.
Das kann alles mögliche sein, auch alles mögliche zu genau diesem Kopierzeitpunkt Wahre.
Aber eben erstens nicht konsistent/"prozessübergreifend abgestimmt", sondern Threadbezogen.
Beispiel: Einer der User hat nun mal in seiner Session ein COMMIT abgesetzt.
87 andere User aber gerade noch nicht.
Wenn ihr einen derartigen Datenklumpen als Quelle für ein Restore nutzt, kann es sein, dass ein inkonsistenter Daten(schief)stand erzeugt wird.
Sieh es positiv - ihr habt 3 Jahre lang keine brauchbare Datensicherung gehabt.
Aber gottseidank hat auch niemals jemand eine dieser MDF-Dateien als Quelle für ein Zurücksichern genutzt.
Grüße
Biber
und um Frage 1 ("Reicht unsere Dateisicherung der Datenbank aus?") eindeutig zu beantworten.
Absolut NEIN. Eher sogar im Gegenteil, denn die vermeintlich gesicherte MDF-Datei enthält einen undefinierten Zustand, einen Zufalls-Snapshot, der genau das enthält, was die diversen Writer-Prozesse persistiert haben.
Das kann alles mögliche sein, auch alles mögliche zu genau diesem Kopierzeitpunkt Wahre.
Aber eben erstens nicht konsistent/"prozessübergreifend abgestimmt", sondern Threadbezogen.
Beispiel: Einer der User hat nun mal in seiner Session ein COMMIT abgesetzt.
87 andere User aber gerade noch nicht.
Wenn ihr einen derartigen Datenklumpen als Quelle für ein Restore nutzt, kann es sein, dass ein inkonsistenter Daten(schief)stand erzeugt wird.
Sieh es positiv - ihr habt 3 Jahre lang keine brauchbare Datensicherung gehabt.
Aber gottseidank hat auch niemals jemand eine dieser MDF-Dateien als Quelle für ein Zurücksichern genutzt.
Grüße
Biber
Danke für eure Antworten. Wir haben uns entschieden folgendes Produkt zur Datenbanksicherung zu nehmen:
http://www.dd-medsoft.de/produkte/dbsave/
Die Backupdateien werden dann aufs Band gesichert.
http://www.dd-medsoft.de/produkte/dbsave/
Die Backupdateien werden dann aufs Band gesichert.
Und warum habt ihr euch dafür entschieden?
Das kann der SQL von sich selbst auch.
Das kann der SQL von sich selbst auch.
Hi Wiesi200,
Ich war im Management Studio und habe da die Funktion "Sichern" gefunden als ich auf eine Datenbank "rechtsklick" gemacht habe, aber da habe ich nichts gesehen, womit das man
automatisieren kann, sprich ich habe nur die Funktion gesehen, dass man manuell sichern kann. Habe ich dort was übersehen?
Ich war im Management Studio und habe da die Funktion "Sichern" gefunden als ich auf eine Datenbank "rechtsklick" gemacht habe, aber da habe ich nichts gesehen, womit das man
automatisieren kann, sprich ich habe nur die Funktion gesehen, dass man manuell sichern kann. Habe ich dort was übersehen?
Du kannst im Management Studio (nicht bei Express) unter Verwaltung Wartungspläne hinterlegen. Das ganze geht sogar recht schön mit bunten Ablaufdiagrammen.
Ach es würde eftl. nicht schaden wenn du deinen Chef fragst ob er dir irgendwo nen kleinen Crasch Kurs für nen SQL spendiert.
Ach es würde eftl. nicht schaden wenn du deinen Chef fragst ob er dir irgendwo nen kleinen Crasch Kurs für nen SQL spendiert.
Danke Wiesi200 für die Tipps.
Habe heute mal etwas rumgetestet und mir nun ein Datenbanksicherungskonzept mit dem Commandobefehl "SQLCMD" und einem Script ausgearbeitet und die Datenbanken werden nun so jeden Tag gesichert.
Habe heute mal etwas rumgetestet und mir nun ein Datenbanksicherungskonzept mit dem Commandobefehl "SQLCMD" und einem Script ausgearbeitet und die Datenbanken werden nun so jeden Tag gesichert.
Hallo zsam,
Ich habe auf einem TestPC SQL 2005 Express SP3 + Management Studio SP3 installiert. Auf dem TestPC habe ich die eine Datenbank zurückgespielt. Hat auch soweit geklappt. Ich wollte mit einem Programmviewer schauen, ob alle Daten soweit korrekt wiederhergestellt worden sind. Dazu muss ich am ODBC Treiber im SYSTEM-DNS den SQL Server hinzufügen. Leider bekomme ich die Verbindung nicht hin. Habe mal einfach vom TestPC auf die richtigen SQLServer ein Verbindungstest gemacht. Ging ohne Probleme. Woran scheiter ich? Weiss nicht mehr weiter....
Wäre über einen Tipp dankbar.
Ich habe auf einem TestPC SQL 2005 Express SP3 + Management Studio SP3 installiert. Auf dem TestPC habe ich die eine Datenbank zurückgespielt. Hat auch soweit geklappt. Ich wollte mit einem Programmviewer schauen, ob alle Daten soweit korrekt wiederhergestellt worden sind. Dazu muss ich am ODBC Treiber im SYSTEM-DNS den SQL Server hinzufügen. Leider bekomme ich die Verbindung nicht hin. Habe mal einfach vom TestPC auf die richtigen SQLServer ein Verbindungstest gemacht. Ging ohne Probleme. Woran scheiter ich? Weiss nicht mehr weiter....
Wäre über einen Tipp dankbar.
