Sql Datenbanken nach Servercrash weiterverwendbar?

[steven20 10]

Hallo Liebes Forum

 

vielleicht kann mir jemand weiterhelfen und hat hiermit schon ein paar Erfahrungen.

 

Wir haben SQL 2005 ent. laufen.

Was passiert nun mit den Datenbanken wenn der Server Hardwaremässig total abschmiert, sich also wirklich OHNE "kontrollieren" Bluescreen veraschiedet.

 

Ich gehe davon aus das sie zumindest in einer Art "no clean shutdown" ähnlich exchange sein müssten ?

Kann bzw sollte man diese DB's dan überhaupt noch verwenden?

Was muss ich dannach eventuell tuen um sie wieder zum laufen zu bekommen?

Brauche ich die transaction logs?

 

Noch kurz zum Hintergrund:

Wir möchten mit Symantec Backup Exec System Recovery ein Ausfalls Konzept machen (Restore in Virtuelle Maschine).

Es gibt 3 Partionen

1. Betriebssystem u. SQL installation (lokale hdd)

2. Lofiles (lokale hdd)

3. Datenbanken (Auf Storage)

Partition 1 soll mit Backup Exec gesichert werden und zu Virtueller Maschine konvertiert werden.

Falls der SQL nun ausfällt diese Virtuelle Maschine Starten und die Datenbanekn vom Storage einbinden.

 

Kann das so klappen ? hat jemand ein paar Tips.

 

lg

Stefan

[phoenixcp 10]

Hallo Stefan

 

Das von dir angestrebte Konstrukt sollte man nochmal ein wenig verfeinern bzw. näher bedenken.

Was genau ist das Ziel das du anstrebst? Geht es um maximale Verfügbarkeit oder versuchst du nur herauszufinden, was mit einer SQL Datenbank passiert, wenn dir der Server crasht?

 

Für maximale Verfügbarkeit würde ich den Einsatz eines Clusters in Erwägung ziehen.

 

Was genau mit einer Datenbank passiert wenn der Server crasht ist so genau nicht vorraussagbar. Manchmal kommen sie einfach wieder hoch, manchmal sind sie korrupt und müssen per DBCC wiederhergestellt werden, manchmal hilft nur das Backup.

 

Dein Restoreszenario in eine virtuelle Maschine wird so nicht funktionieren. Dafür fehlen in der virtuellen Maschine die Transaktionslogs der Datenbank(en), welche wie ich annehme auf Partition 2 liegen würden.

 

Um dir hier weitere Hinweise oder Anregungen geben zu können, wäre interessant zu wissen, was für Datenbanken in welcher ungefähren Größe, welchen Recoverymodi und der Art der Nutzung auf dem Server laufen.

 

Gruß zum Feiertagsfeierabend

 

Carsten

[steven20 10]

HI

 

danke mal für die Antwort.

 

Prinzipiell geht es darum bei einem Hardwareausfall möglichst schnell wieder einen SQL Betriebsbereit zu haben.

 

Clusterlösung wäre schön sollte man vielleicht auch überlegen (wenn es mit der Symantec Lösung nicht schön klappt) aber frühestens wohl nächstes Jahr da eine Zusätzliche Enterprise Lizenz ein bisschen was Kostet und der Implementierunsaufwand auch anfällt.

 

BTW: Gibt es ab SQL 2005 nicht ein integrierten replikationsdienst so ähnlich wie bei exchange 07, wo man Cluster ohne shared storage ect aufbauen kann?

 

Also die wahrscheinlichkeit das die DB nach so einem Ausfall nicht mehr ok ist, ist recht hoch ok.

Kann man hier nicht mit neuen Transaction Logs weitermachen, wie bei einer Attach / detache migration? Oder sind zwingend die alten Logs nötig (die wie richtig erkannt auf dem Server direkt liegen)?

 

Bezüglich der DB: es sind ca 100GB verteil auf ca 20 DB's vermutlich im Simple Backup Mode mit vollen und differenziellen Sicherungen. Diese gehen lokal auf Platte und werden über Nacht Filebasierend gesichert.

 

Falls du also noch ein paar Tips hast bin ich dankbar :)

 

lg

Stefan

[Windowsbetatest 10]

Hallo,

 

die Logs werden zur Rekonstruktion der Änderungen seit dem letzten Backup benötigt. Wenn du ohne diese weitermachst, hast du eine alten bzw. veralteten Datenbestand auf dem du weiter arbeitest.

 

Ist eventl. ein kleines SAN eine Lösung (lostest ja auch nicht die Welt), somit wären die Daten von der Serverhardware getrennt.

 

Wenn man dazu einen "Cold Standby" Server hättet, könnte man etwas ähniche wie ein Cluster erstmal simulieren und sobald das Geld verfügbar ist, auf ein richtiges migrieren. (Keine richtige aber Übergangslösung)

 

mfg

[phoenixcp 10]

So, ich schalt mich auch nochmal ein.

 

Das Thema "Cold Standby" ist nicht so trivial wie es auf den ersten Blick scheint, gerade schon dadurch das du Cold Standby nur in bestimmten Lizenzkonstrukten fahren kannst. Dazu solltest du mal die Boardsuche benutzen, da wird sich einiges finden. Ansonsten verweise ich hier einfach mal platt auf Windows Server How-To Guides: "Cold" Server Backup für Desaster Recovery - ServerHowTo.de

 

vermutlich im Simple Backup Mode

Das vermutlich sollten wir bitte mal gegen Gewissheit austauschen, bevor wir hier weiter über mögliche Recoveryszenarien sprechen. Welche Recoverymodes werden auf deinem Server für welche Datenbank gefahren?

 

Prinzipiell geht es darum bei einem Hardwareausfall möglichst schnell wieder einen SQL Betriebsbereit zu haben.

Was heißt möglichst schnell? Über was für ein SLA sprechen wir?

 

BTW: Gibt es ab SQL 2005 nicht ein integrierten replikationsdienst so ähnlich wie bei exchange 07, wo man Cluster ohne shared storage ect aufbauen kann?

Ja, gibt es, aber es ist halt kein Cluster, sondern es werden lediglich Informationen von einem Server zum anderen repliziert. Mehr dazu hier: SQL Server 2005-Replikation

 

Clusterlösung wäre schön sollte man vielleicht auch überlegen (wenn es mit der Symantec Lösung nicht schön klappt) aber frühestens wohl nächstes Jahr da eine Zusätzliche Enterprise Lizenz ein bisschen was Kostet und der Implementierunsaufwand auch anfällt.

Die zusätzliche Lizenz würde auch anfallen, wenn du den Replikationsmechanismus einsetzen würdest. Ebenso würde diese Lizenz anfallen, wenn du deine virtuelle Maschine nicht die Vorraussetzungen für ein Cold Standby (siehe HowTo) erfüllt.

[NilsK 2.902]

Moin,

 

OK, dann auch hier noch ein wenig Senf, der evtl. den Hintergrund verstehen hilft:

faq-o-matic.net Warum muss eine Datenbank zum Backup konsistent sein?

 

Gerade SQL Server macht es eigentlich recht leicht, leistungsfähige Recovery-Szenarien einzurichten. Dazu sollte man sich aber ein wenig mit seiner Art der Speicherung und mit den Backupmöglichkeiten beschäftigen.

 

Und wie immer wäre es sinnvoll, vor der Lösungssuche mal das Problem (= die Anforderungen) zu definieren. Das ist in IT-Kreisen höchst unbeliebt, aber trotzdem unerlässlich.

 

Gruß, Nils