DB anhalten

[Schnake 10]

Hi,

 

ich müßte eine SQL2k DB snapshoten.

Der Snapshot kann aber nur dan sauber funk´tionieren wen auf der Datenbank keiner arbeitet.

Unter den älteren versione gab es einen freeze-Befehl, gibt es unter SQL2k einen änlichen Befehl, freeze funktioniert nicht mehr.

 

Danke

[gr@mlin 10]

hi,

 

meinst du vielleicht

- net stop mssqlserver

- net start mssqlserver

- net pause mssqlserver

- net continue mssqlserver

?

 

gruss, gr@mlin

[Schnake 10]

hi,

 

ntstop und ntstart dauern zulange.

 

ntpause kenne ich nicht !

In welchem Zustand befindet sich die Datenbank nach ntpause ?

Werden die Logs weiter geschrieben ?

Wie lange dauert es nach einem ntpause/ntcontinue bis eine 50GB DB wieder lebt?

[phoenixcp 10]

Wie wäre es wenn du einfach nur alle SQL-Connections zu einem definierten Zeitpunkt killst und sofort im Anschluss den Snapshot machst?

 

Hab zwar keine Vorstellung wie lange der Snapshot für ne 50 GB DB dauert, aber ne Mail an die Anwender sollte vorher sicher verfasst werden, damit die dann auch ja die Füsse stillhalten wenn ihnen ihre Connection wegknallt.

[Schnake 10]

Genau da liegt mein Problem,

 

es arbeiten rund um Uhr Leute auf der DB. Dies sind nicht nur aus meiner Firma, sondern auch übers Web Kunden von uns.

 

Falls die DB länger als 5 min unten ist kommt es zu Problemen.

 

Dies ist der Grund warum die DB mit einem Snapshot gesichert werden soll.

Wie schon geschrieben brauch der Snapshot einen kozestent Zustand und dies war mit einem freeze möglich, da der log nicht geschrieben wurde.

Das ganze dauerte mit freeze-snapshot-thaw nur ne knappe min.

 

Die bräuchte ich auch auf dem neuen System.

[phoenixcp 10]

Und wenn du für den Zeitraum des Snapshots die Schreibrechte entziehst und für die kurze Dauer nur Lesezugriffe durchlässt?

[Schnake 10]

Die Idee ist nicht schlecht.

 

ABER wer will dies vier mal am Tag tun.

 

Danke !!!!

[phoenixcp 10]

Hm, das ist natürlich verständlich.

Bei vier mal am Tag fällt das aus. Mal schauen, wenn mir nochwas einfällt oder über den Weg läuft dann meld ich mich nochmal.

[aba 10]

Original geschrieben von Schnake

....

ABER wer will dies vier mal am Tag tun.

...

 

Ein Auftrag mit einem definierten Zeitplan und TSQL-Anweisungen vielleicht?

[phoenixcp 10]

Fraglich ist hier sicher, ob es den Nutzern zugemutet werden kann vier mal am Tag keine Schreibrechte zu haben. Ich weiß zwar nicht wieviele da auf der DB rumhühnern, aber wenn nach Aussage von Schnake auch Kunden von aussen auf die DB zugreifen, werden es schon einige sein.

 

Aber auf der andren Seite müssten die auch Interesse daran haben, das für den Fall der Fälle vorgesorgt ist.

[aba 10]

Es wäre evtl. interessant zu wissen, wofür der Snapshot der DB gebraucht wird.

[phoenixcp 10]

Ich gehe mal davon aus als Sicherung. Und eben aus diesem Grund will er nen konsistenten Zustand haben.

 

Was mir den ganzen Tag durch den Kopf ging: Wie verhält sich eigentlich ein ganz normales Backup der SQL-DB, wenn während dem Abziehen des Backups Daten manipuliert werden?

Zieht das nen etwaigen inkosistenten Datensatz mit oder werden solche Datensätze einfach ignoriert?

 

Wenn sie ignoriert werden, dann könnte man ja einfach viermal am Tag per Scheduled Job ein DB-Backup ziehen. Hab zwar keine Ahnung wie lange das bei ner 50 GB DB dauern würde, aber in sechs Stunden mit Sicherheit machbar.

[aba 10]

Beim Backup wird im Transaktionsprotokoll eine "Marke" (LSN, Logical Sequenz Number) gesetzt. Alle Transaktionen, die während des Backups durchgeführt werden und im Protokoll landen, werden zum Ende des Backups mit in die Sicherung geschrieben.

D.h. bis zum Ende des Backups gehen keinerlei Transaktionen verloren. Die DB inkl. des Transaktionsprotokolls ist absolut konsistent am Ende der Sicherung.

[phoenixcp 10]

Hm, also gäbe es keinen Grund der gegen ein normales Backup und einen damit konsistenten Stand des Backups spricht.

 

Das Backup kann er dann auf dem andren System einfach wieder einspielen und fertig is der Lack.