Glorf IT

Im ersten Teil der Serie "Vorschläge zur Datensicherung mit SQL-Server" habe ich ein paar Dinge zum Umfeld und zum Verständnis geschrieben. Im zweiten Teil will ich das Vorgehen beim Offline-Backup beschreiben.

Das Offline-Backup wird üblicherweise über Nacht durchgeführt, weil ja niemand in der Zeit des Backup arbeiten kann. Damit ergibt sich schon gleich die wichtigste Einschränkung: Wenn man ein 24x7-Szenario (es wird "rund-um-die-Uhr" gearbeitet) hat, dann kann es nicht eingesetzt werden.

Grundsätzlich sollte man gekoppelt mit dem Backup möglichst auch eine Datenbank-Überprüfung durchführen. Damit man weiss, ob die gesicherte(n) Datenbank(en) auch in Ordnung waren. Daher ergibt sich üblicherweise folgender Ablauf, der z.B. als Batch ausgeführt werden kann:

• Datenbanken überprüfen
• SQL-Server-Dienst stoppen
• Datenbank-Dateien sichern
• Dienst neu starten
• Nacharbeiten

Datenbanken überprüfen

Wenn man die Datenbanken überprüft, dann muss man am nächsten Morgen kontrollieren, ob die Prüfung Fehler entdeckte und ggf. die vorherige Sicherung besonders gut aufheben… Weil,die Sicherung nicht mittels SQL-Mitteln durchgeführt wurde kann der Sicherungsteil nicht oder nur in Ausnahmefällen (z.B. nur eine Datenbank) auf die Prüfung reagieren. Deswegen wurde die Datenbank auf jeden Fall gesichert, selbst wenn es sich dabei um eine defekte Datenbank handelt.

Es versteht sich eigentlich von selbst, aber zur Sicherheit hier noch der genereller Hinweis bei wiederverwendtbaren Medien: Bitte immer mehrere Sicherungsbänder verwenden und die Sicherungen von bestimmten Stichtagen generell aufheben. Beispielsweise könnte man 10 Generationen verwahren: Mo, Di, Mi, Do, Fr, Mo, Di, Mi, Do, Fr. Die Wochenendsicherungen werden dann dauerhaft archiviert: KW23, KW24, KW25, …

Dann kann man bei versehentlichem Löschen die Daten der letzten zwei Wochen tagesaktuell restaurieren und ältere Daten wochengenau.
Wenn man kein SQL kann, dann kann man diesen Schritt auch weglassen, aber sollte vielleicht öfters mal eine Generation der Sicherungen archivieren, z.B. Mittwochs und Samstags… 😛

SQL-Server-Dienst stoppen

Ich bin ein Fan der Kommandozeile, z.B. "net stop mssql$mytestsql", aber hier gibt es beliebige Freiheiten.

Datenbank-Dateien sichern

Das Sichern ist hier denkbar einfach. Dazu werden alle Dateien der zu sichernden Datenbanken gesichtert: MDF, LDF und, falls vorhanden, NDFs. Wichtig beid er Rücksicherung ist, dass immer alle Dateien einer Datenbank konsistent zurückgesetzt werden. Man darf keine unterschiedlichen Stände mischen.

Ich würde empfehlen die Dateien zunächst in ein Verzechnis auf einer anderen Platte zu sichern und von dort zu archivieren. Das reduziert die Down-Zeit erheblich, kostet aber unter umständen viel Plattenplatz.

SQL-Server-Dienst starten

Wieder irgendwie, z.B. auf der Kommandozeile mittels "net start mssql$mytestsql".

Nacharbeiten

Die Dateien werden nur zu diesem Zeitpunkt gesichert und vorbei am SQL-Server. Daher muss man beachten, dass der "Recovery-Modus" der zu sichernden Datenbank darauf abgestimmt ist. Hat man als Recovery-Modus "Full" oder "Bulk-Logged" gewählt, dann wird das Transaktionslog der Datenbank sehr schnell sehr groß. Deswegen muss man in diesem Fall noch das Transaktionslog der (hoffentlich) erfolgreich gesicherten Datenbanken "abschneiden".

Statt dessen kann man auch den Modus "Simple" verwenden. Hier werden im Transaktionslog nur die Daten der Transaktionen gespeichert, die noch nicht im Rahmen eines Checkpoint auf die Platte geschrieben wurden. Damit entfällt das Nachbearbeiten.

Datenbanken am "SQL Server 2000" haben als Default den Modus, wenn sie an eine MSDE angehängt werden, und "Full", wenn sie an eine Standard- oder Enterprise-Edition angehängt wurden. Beim 2005er habe ich das noch nicht überprüft. Ich gehe davon aus, dass es immer noch so ist.

Vorteile dieser Vorgehensweise

• Sie wird auch von Laien verstanden.
• Für die Rücksicherung werden keine Datenbank-Kenntnisse benötigt: Einfach Dienst stoppen, die Dateien zurückkopieren, Dienst starten, fertig.
• Es ist kein SQL-Server-Verwaltungswerkzeug notwendig.
• Sie ist schnell.

Risiken und Nebenwirkungen

• Während der Down-Phase kann nicht mit den datenbanknutzenden Anwendungen gearbeitet werden.
• Die Kopplung mit dem Recovery-Modus "Simple" bietet sich an. Das führt dazu, dass im Crashfall immer auf den letzten Sicherungsstand zurückgesetzt werden muss. Man verliert also vermutlich einen Tag Arbeit.
• Die Datenbank-Dateien werden komplett kopiert, nicht nur die gefüllten Seiten, wie beim Online-Backup. Daher wird mehr Platz auf dem Sicherungsmedium benötigt.
• Sollte in ein anderes Verzeichnis kopiert werden, dann muss dort immer ausreichend Platz zur Verfügung stehen, sonst scheitert die Sicherung. In gewissen Weise ist das bei der Online-Sicherung auch so.
• Sollte der Dienst nicht gestoppt werden, dann werden die Dateien nicht kopiert.
• Im Falle der Rücksicherung verliert man die Arbeit seit dem Datum der letzten Sicherung erledigt wurde. Daher sollte man jede Nacht sichern…

Mein persönliches Resümee:

Diese Art der Sicherung eignet sich besonders für EDV-Laien, die mittlere Anforderungen an die Datenverfügbarkeit haben. Insbesondere die einfache Art der Rücksicherung ist ein großes Plus. (Hinweis: Die Daten-Rücksicherung sollte unbedingt einmal getestet werden… :-))

Im dritten Teil werde ich die Online-Datensicherung beschreiben.

Als ich bei TecChannel las, dass eine SQL-Einspeisung möglich ist, habe ich einen Moment gebraucht bis ich begriffen habe, dass hier "SQL-Injection" ins Deutsche übersetzt wurde.

An der Nachricht finde ich zwei Dinge schrecklich:

• Das ich bei eingedeutschen Fachbegriffen oft einfach nicht oder wenigstens nicht gleich verstehe, was gemeint ist. Wenn ich Infos zum SQL-Server suche, dann suche ich grundsätzlich in den englischen Books-Online. Man kann ja nie wissen, wie das was ich suche ins Deutsche übertragen wurde…
• Das in fast jeder Version-1.0-Software SQL-Injection möglich ist. Erst in späten Versionen werden diese Dinge angegangen. 🙁

Na, jetzt weiß ich jedenfalls, was eine SQL-Einspeisung ist.

Update: Vertipper entfernt

Angeregt durch eine Diskussion in der Newsgroup microsoft.public.de.sqlserver möchte ich ein paar Vorschläge für die Datensicherung der Datenbanken des SQL-Servers unterbreiten. Dabei möchte ich vorausschicken, dass ich hier generell über Wald-und-Wiesen-Anwender rede: also kleine bis mittlere Büros und Privatleute. Diejenigen 2%, die einen Hochverfügbarkeitscluster im Serverraum stehen haben, brauchen meinen Rat vermutlich sowieso nicht, sondern lassen das ihren Admin entscheiden.. 😛

Da man bekanntlich nicht alles haben kann, muss man im ersten Schritt die Prioritäten klären, damit man entscheiden kann, was einem wichtig ist:

• Geringe Ausfallzeit: Darf im Desasterfall die Arbeit eines ganzes Tagen verloren gehen oder muss die Wiederherstellung bis zum Crash-Zeitpunkt gehen?
• Ist die leichte Bedienbarkeit der Datensicherung und Rücksicherung wichtig oder steht geschultes Fachpersonal zur Verfügung?
• Was darf die Sicherungslösung kosten? Was kostet mich der Totalverlust der Daten?

Dann muss man sich überlegen, wie oft und aus welchen Anlässen ich damit rechne die Rücksicherung zu benötigen:

• Werden öfters mal versehentlich ein paar Daten zu viel gelöscht?
• Bietet die Software eine Wiederherstellung von diesen gelöschten Daten an? Die meiste Software bietet so eine Art "Papierkorb" an, dort können gelöschte Datensätze wiederhergestellt werden so lange der Papierkorb noch nicht entgültig "geleert" wurde.
• Wenn nicht, wie kann ich die gelöschten Daten aus einer älteren Sicherung exportieren und in den aktuellen Bestand importieren?

Das war jetzt noch nicht wirklich spezifisch für den SQL-Server. DEshalb komme ich langsam auf die Möglichkeiten, die wir hier zur Verfügung haben: ich möchte mich aber wirklich auf die Datensicherung beschränken. Natürlich sind auch die Hardware-Überlegungen in diesem Zusmamenhang wichtig, damit alles zusammenpasst, bspw. gehört es auch dazu sich zu überlegen, ob man sich ein Raid-System anschafft oder nicht. Aber eine Datensicherung wird in jedem Fall benötigt, auch mit Raid-Systemen. Daher gehe ich in dieser Serie nur auf diesen Aspekt ein.

Ich unterscheide grundsätzlich erstmal zwischen der

• Offline-Datensicherung, d.h. der SQL-Server-Dienst wird gestoppt, die Datenbank-Dateien werden gesichert und der Dienst neu gestartet, und der
• Online-Datensicherung, d.h. im laufenden Betrieb wird der Inhalt der Datenbank mit Bordmitteln des SQL-Servers gesichert. In diesem Fall hat man noch die Wahl erstens immer eine Vollsicherung anzufertigen, zweitens regelmäßige Vollsicherungen durchzuführen und dazwischen mit differentiellen Backups zu arbeiten oder drittens in größeren Abständen Vollsicherungen durchzuführen und in kürzeren Abständen inkrementelle Sicherungen anzufertigen.
• Zuletzt kann mit macher Sicherungssoftware unter Windows Srever 2003 auch der Volume Shadow Copy Service (VSS) genutzt werden, um geöffnete Dateien auf Datei-Ebene zu sichern.

Im Falle der Offline-Datensicherung kann man immer nur eine Vollsicherung durchführen, eine differentielle Sicherung auf Datei-Ebene ist mit SQL-Server sinnlos, da die Datenbank-Dateien bei jedem Start des Dienstes angefasst und damit verändert werden.

Die oben genannten fünf Fälle werden ich in den kommenden Tagen jeweils ausführlich als separates Posting beschreiben.

Heute ist es wieder online, der Weblog, der vorgibt von Joe Celko zu sein:
Joe Celko The SQL Apprentice

Hier ein paar Highlights:

Question: >> Is there a function that can take an @Variable that will drop a table? I can't seem to be able to get Drop Table @Variable to work because Drop Table doesn't want a string, it wants the plain table name. << Joe: Don't write code like this, nor use that mental model for RDBMS. A table models a set of entities or relationships. Having tables appear and disappear in an application is like a magic world in which elephants drop from the sky or mountains dissolve in an instant. [...]

Have you considered using a relational design instead mimicking a
magnetic tape file? There is no such thing as a vague, universal id that you can use to mark all the things in creation. Auto-increment is a way of saying that you have no idea what a key is – and it ain't a physical locator generated by the hardware!

I see that teams have no names, that you have no referencing among the tables, so they are totally unrelated. Instead of computing standing and results, you seem to want to write them to physical storage, thus missing the basic point that tables – unlike files – can be virtual tables. […]

Bei SQL Server Code wird ihm auch eine coole Äußerung zugeschrieben, die ich bei ihm zwar nicht finden konnte, die aber typisch klingt:

Question: >> how to set the PK in SS Mgmt Studio ? << Joe: Who cares?? You are not not a real SQL programmer!! You are a "mousey, mousey, click , click" non-programmer. (with a French accent) we spit on you, Video gamer! to be serious, real programmers use a text editor. They know the language they write in. Those stinking "video game tools"slow us down. And they lead us to ask questiosn like this in newsgroups where people liek me will maek fun of you.

🙂

Aber bei Ken Henderson bestreitet Joe diesen Weblog zu betreiben. Es scheint sich um eine sehr gut gemachte Fälschung zu handeln. Ich finde den Fake jedenfalls unterhaltsamer als die meisten "echten" Blogs… 😉

Bei inside-it.ch wird darüber berichtet, dass Microsoft den Custom Support für bestimmte Produkte auf drei Jahre verlängert:

In Zukunft will Microsoft nun für jedes Produkt, für das es Custom Support gibt, generell von Anfang an eine Frist von drei Jahren garantieren. (Die Frist kann danach noch weiter verlängert werden). Der Preis für den Custom Support wird von Anfang an für diese drei Jahre festgelegt. Und zudem wird nicht mehr ein Einheitspreis verlangt, sondern die Kunden zahlen pro Maschine, auf der noch die alte Software läuft.

Um ehrlich zu sein, verstehe ich den Unterschied zum bisherigen Verfahren nicht, weil mir der Begriff "Custom Support" unklar ist. Und weil ich gerade Urlaub habe, kann ich nicht "mal eben" unseren Experten in der Firma dazu befragen. Hier die FAQ zur Microsoft Support Lifecycle-Richtlinie. Sie wurde aber zuletzt im Februar aktualisiert, enthält diese Änderungen daher nicht nicht.
Ich vermute mit "Custom Support" ist einfach ein Support nach dem "Extended Support" gemeint, den besondere zahlende Kundschaft bekommen kann.

Den extrem langen Lebenszyklus des SQL Server 2000 dürfte das jedoch nicht beeinflussen… 😉

Hier die Details: Microsoft verlängert Gnadenfrist für Softwaregreise.

Update: OK, jetzt weiss ich wieder was es mit dem "Custom Support" auf sich hat. Es wurde 2004 wegen Windows NT Server schon mal hochgekocht. In der Sidebar wird es für Exchange Server 5.5 zusammengefasst:

Microsoft Exchange Server 5.5 will follow the custom support policy announced today for Windows NT 4.0. There will be a full two years of custom support available for Exchange Server 5.5 customers after extended support ends at the end of 2005.

Und das wurde jetzt einfach auf 3 Jahre verlängert. Also Custom-Support für Windows NT Server bis Ende 2007?

Am 25.August hat Microsoft ein neues Whitepaper bereit gestellt: SQL Server 2005 Failover Clustering White Paper. Ehrlich gesagt habe ich es nicht angeschaut, die 37 MB des "comprehensive document" haben mich etwas abgeschreckt. Dafür habe ich im Augenblick einfach nicht die Nerven – schließlich habe ich Urlaub… 😉

Vergleichsweise wenige unserer Kunden nutzen Windows-Cluster, was angesichts der Preise und unserer Zielgruppe auch wieder nicht so verwunderlich ist.

gefunden bei The Daily Grind

Auf developer.com hat Mike Gunderloy einen ganz netten, kurzen Einsteiger-Artikel zum SQL Server Everywhere geschrieben. Er kommt zu folgendem Resüme, dem ich mich uneingeschränkt anschließe:

SQL Server Everywhere is targeted for single-user desktop scenarios, where you've got an application that needs to store data and possibly synchronize it with a server. Within those bounds, though, it's a very attractive solution – and one that you can actively experiment with today.

Hier ist er ganze Artikel: A First Look at SQL Server Everywhere

gefunden bei The Daily Grind

Da ich sie nicht mehr benutze, ist mir noch gar nicht aufgefallen, dass der SQL Server 2005 die alte Syntax für Outer-Joins nicht mehr unterstützt.

select O.OrderID, OD.Quantity
from orders as O, "order details" as OD
where O.OrderID *= OD.OrderID

Wenn man das unbedingt noch nutzen will, dann muss man den "Compatibility Level" für die Datenbank auf "80" setzen. Dann funktionieren freilich einige andere nette, neue Features nicht mehr… 😉

In meinen Augen ist das kein großer Verlust. Lästig ist nur, dass es bei uns garantiert noch ein paar SQL-Anwendungen der ersten Stunde gibt, die an selten geänderten Stellen noch diese Syntax verwenden.

Eine unheimliche Begegnung der dritten Art hatten Kollegen als sie versuchten eine Datenbank vom SQL-Server zu trennen. Es ging nicht, weil die Datenbank noch in Verwendung sei. Als sie nachschauten, stellten sie fest, dass ein SQL-Server-Task die Datenbank verwendete, der "Ghost-Cleanup Task".

Die besten Informationen fand ich dazu in meinem Lieblingsblog "SQL Server Storage Engine" von Paul Randal:

Ghost records

• These are records that have been logically deleted but not physically deleted from the leaf level of an index.
• The reasons for this are complicated, but basically having ghost records simplfies key-range locking and transaction rollback.
• The record is marked with a bit that indicates it's a ghost record and cannot be physically deleted until the transaction that caused it to be ghosted commits. Once this is done, it is deleted by an asynchronous background proces (called the ghost-cleanup task) or it is converted back to a real record by an insert of a record with the exact same set of keys.
• Ghost records will be mentioned later in the series when I discuss page compaction.

Abhilfe brachte die Datenbank zunächst in den Single-User-Mode zu schalten und dann zu trennen.

Heute machte mich mein Kollege Günther darauf aufmerksam, dass Microsoft nicht vor hat, die MSDE unter Windows Vista zu unterstützen:
SQL Server 2000 (including MSDE) on Windows Vista FAQ
Laut Günther wurde das am 8.8.2006 reingeschrieben, auf einer anderen Seite "How to buy: SQL on Vista" stand es schon am 20.7.2006. Aber ich sah es noch in keiner Ankündigung und nichts… Seltsam. 😕

Wenn man die Seite aufmerksam liest, merkt man, dass es für diesen Schritt keine echten technischen Gründe gibt:

SQL Server 2005 presents several advances in technology from its predecessor, SQL Server 2000. One such important advancement is the support for patching SQL Server 2005 editions through Windows Update Services, which is not available for MSDE. Similarly, there are several advances in security and performance in the “Longhorn” and “Vista” platforms, such as ‘User Access Control’ that SQL Server 2005 can work with, but that MSDE cannot.

OK, mit der MSDE unter Vista bin ich also langsamer und nicht so sicher wie mit SQL Server 2005. Verstehe ich. Aber bin ich unsicherer als unter Windows XP oder langsamer als unter Windows XP (Hm, OK, das könnte sein, aber nur bei gleicher Hardware)? Beides eher nicht. Es gibt auch keinen Grund die neuen Features in die MSDE einzubauen.
Microsofties haben sogar festgestellt, dass sie läuft:

Limited testing indicates that MSDE 2000 may install on Windows Vista, but this is not supported and Microsoft does not guarantee that it will install under all circumstances.

Since the decision was made not to support SQL Server 2000 (including MSDE) on Vista, Microsoft did not conduct a thorough evaluation of MSDE functionality on Vista and is therefore not in a position to publish any authoritative guidance.

Given that MSDE is an unsupported product on Windows Vista, we strongly encourage our customers not to run applications with the MSDE database on Windows Vista, even if they are able to successfully install.

Warum treten sie jetzt so vielen Kunden vor das Schienenbein? Das bedeutet doch, dass es wichtige Gründe geben muss.
Ich vermute, dass sie erkannt haben, dass die MSDE einfach zu gut ist. Sie kann in Peer-to-Peer-Umgebungen wunderbar einen echten Server ersetzen. Warum soll ich die teuere Workgroup-Edition einsetzen, wenn es doch die MSDE gibt? Wenn die MSDE also zukünftig nicht mehr geht…

Hat jemand eine andere Erklärung?

Update: Im SQL Server Express WebLog stehen noch mehr Details dazu. Unter anderem:

Windows does not do anything to block MSDE from installing on Vista, but you will get a warning indicating that MSDE is not supported.

Zehn Mythen, die ins sichere Verderben führen, wenn Sie ein Datenbanksystem einsetzen:

1. Machen Sie keine Datensicherung. Die EDV-Systeme sind sicher und arbeiten auch nach Jahren noch völlig fehlerfrei. Auch Sie selber oder Ihre Mitarbeiter machen keine Fehler: Versehentlich gelöschte Daten gibt es nicht.

2. Wenn Sie doch eine Sicherung machen, womöglich regelmäßig, dann testen Sie nicht, ob auch die Rücksicherung klappt. Sie nehmen sich damit im Ernstfall den Nervenkitzel. Nur Weicheier kontrollieren ihre Fallschirme.

3. Verwenden Sie ruhig billige Hardware zur Speicherung Ihrer unternehmenskritschen Daten. Auch billige (S)ATA-Platten können bedenkenlos im Dauereinsatz verwendet werden. Und sollte doch mal ein Fehler auftreten, dann kann das Datenbanksystem das durch Guessing kompensieren.

4. Falls es mal zu sporadischen Problemen kommt, ignorieren Sie sie einfach: Jeder macht mal Fehler! Reiten Sie nicht kleinlich auf den Fehlern des Computers herum. Auch eine Festplatte oder ein Hauptspeicher hat mal einen schlechten Tag. Das hat gar nichts zu bedeuten.

5. Speichern Sie Ihre Daten auf Wechseldatenträger und ziehen sie einfach ab, wenn es Ihnen gefällt. Die "Auswerfen"-Funktion des Betriebssystems ist völlig unnützt und benutzen nur Warmduscher. Die noch vom Betriebssystem gecachten Daten werden durch Infravision auf den Stick übertragen.

6. Falls Sie keine "Unterbrechungsfreie Stromversorgung" (USV) haben und der Festplatten-Cache nicht batteriegepuffert ist, dann schalten sie auf jeden Fall den Schreibcache der Festplatte ein. Performance ist einfach wichtiger als alles andere.
Außerdem gibt es in Deutschland keine Stromausfälle und die Unbekümmertheit der Putzfrauen ist ein Mythos.

7. Stellen Sie Ihre Server in einen kleinen unbelüfteten, stickigen Raum direkt unter dem Dach. Rechner lieben Hitze. Besonders Festplatten feiern dann eine Riesenparty. Die Sicherungsbänder bzw. Sicherungen auf DVD wollen mitfeiern. Legen Sie sie deswegen unbedingt in die pralle Sonne.

8. Oder stationieren Sie Ihre Server im Keller, falls Ihr Büro in Flussnähe oder in einem hochwasser-gefährdeten Gebiet liegt.

10. Sie können natülich auch einfach die wichtigsten Daten allein auf einem Laptop mit Sony-Akkus speichern. 😉

Mehr zu den Ursachen von defekten Datenbanken steht in meiner Serie zu dem Thema.

Neulich schrieb ich noch ganz verschämt als Auftakt für die Reihe mit den Ursachen für defekte Datenbanken: "Wir haben festgestellt, dass das Wetter eindeutig Einfluss auf die Häufigkeit von Datenbank-Defekten hat."

Jetzt ist es "amtlich": im Artikel vom TecChannel werden dazu jede Mange Fakten und Beispiele gebracht.

Allerdings sind die Ursachen für zu „heiße Rechner“ vielfältig. Sie reichen von einem falschen Aufstellungsort des Desktop-PCs oder Notebooks bis hin zu einer mangelhaften Kühlleistung der Systeme. Doch neben dem Praxiswissen sind auch Physikkenntnisse erforderlich, um die Gefahren einer thermischen Überbelastung besser einschätzen zu können.

Näheres steht im Artikel "Hitzetod: Jeder PC ist gefährdet".

Meine Kollegin Beate erzählte heute dazu eine Anekdote: Alle in ihrem Büro konnten genau hören, wenn Sie einen Compilerlauf startete. Dann wurde ihr Rechner so richtig laut. Die CPU wurde warm und der Lüfter brummte. Der herbeigerufene Service-Techniker verschob den PC ein wenig. Damit war die Lüfteröffnung nicht mehr zugestellt und das Problem behoben…