Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

13. Dezember 2006 um 21:57

Caching im Festplattensubsystem

Mein Kollege Hans machte mich gestern auf das Dokument "Description of using disk drive caches with SQL Server that every database administrator should know" von Microsoft aufmerksam. Der Hintergrund sind weitgehend unbekannte oder besser ignorierte Ursachen für zerstörte Datenbanken. Tatsächlich sollte jeder Admin über die Risiken Bescheid wissen, denen man bei der Default-Konfiguration von PCs und Servern ausgesetzt ist.

Konkret geht es um die verschiedenen Caches, die so ein Datensatz durchlaufen muss, bis er endlich echt auf der Platte gesichert wurde. Treue Leser werden bei mir auch schon den einen oder anderen Hinweis dazu gelesen haben… ;-)

Schön finde ich, dass hier endlich mal alle Dokument zu einem zusammengefasst werden.

PS: In der (automatischen) deutschen Übersetzung lautet der Titel übrigens "Mit SQL Server zwischenspeichert Beschreibung von Verwenden von Laufwerk dass jeder Datenbank-Administrator kennen sollte". Noch Fragen?

7. November 2006 um 20:43

Backup-Song

Yesterday (nach der Melodie von den Beatles)

Yesterday,
All those backups seemed a waste of pay.
Now my database has gone away.
Oh I believe in yesterday.

Suddenly,
There's not half the files there used to be,
And there's a milestone hanging over me
The system crashed so suddenly.

I pushed something wrong
What it was I could not say.
Now all my data's gone
And I long for yesterday-ay-ay-ay.

Yesterday,
The need for backups seemed so far away.
I knew my data was all here to stay,
Now I believe in yesterday.

Diesen Song habe ich mal Anfang der 90er aus irgendeiner PC-Zeitschrift kopiert, habe leider vergessen aus welcher…

6. November 2006 um 21:12

Umfrage zum Thema Datensicherung

Es gibt Neuigkeiten zu meinem heimlichen Lieblingsthema "Datensicherung": eine Umfrage von Kroll Ontrack unter 1400 Anwendern in den USA kommt zu frapierenden Ergebnissen…

Obwohl die Anwender ihren Daten einen hohen Wert zuschreiben, geht ein großer Teil recht sorglos mit seinen Daten um und unterschätzt das Risiko von Fehlfunktionen. Auf die Frage, wie lange sie ihren aktuellen Rechner nutzen wollen, gaben 58 Prozent der Befragten zum Beispiel an, "so lange, bis er kaputt geht" oder "bis er die ersten Ausfallserscheinungen zeigt". Diese Gleichgültigkeit belegen auch die Ergebnisse, dass 63 Prozent der Anwender ihre kritischen Daten weniger als einmal monatlich sichern und 23 Prozent keinerlei Backups vornehmen.

Natürlich ist es wichtig zu schauen, wer so eine Umfrage in Auftrag gegeben und formuliert hat. Ontrack verdient sein Geld mit Datenrettungsaktionen und möchte auf seine Dienste aufmerksam machen. Dennoch decken sich die Ergebnisse durchaus mit meinen Erfahrungen.

Und was kann man da machen? Meines Erachtens gar nichts. Man kann nur bei sich selber anfangen. Diejenigen, die sich nicht für Datensicherungen interessieren, lesen weder solche Studien noch meinen Blog…
Die IT-Fachleute müssen ihre Kunden natürlich anhalten Datensicherungen zu machen, aber da auch ihnen vorrangig kommerzielle Interessen unterstellt werden, reicht deren Einfluss leider nicht so weit, wie es nötig wäre. Hinzu kommt die Grundeinstellung, die auch im obigen Zitat rauskommt: "Solange alles gut läuft, muss ich mich doch um nichts kümmern."

gefunden bei TecChannel.de

28. Oktober 2006 um 21:43

SQLIOSim: Ist die Hardware in Ordnung?

Leider habe ich es gerade eben erst entdeckt, aber die Freude ist u so größer.

DER Nachfolger für SQLIOStress ist da: SQLIOSim

typische Einsatzgebiete:

  • Jemand will im voraus wissen, ob mit seiner Hardware Probleme für den SQl-Server zu erwarten sind: defekte Datenbank aufgrund ungeeigneter Hardware.
  • Ein anderer möchte wissen, ob die neue systemnahe Software dem SQL-Server falsche oder defekte Seiten unterschiebt: bspw. Virenscanner, Verschlüsselungssoftware oder Backup-Software.
  • Ein anderer hat vielleicht schon eine defekte Datenbank und möchte die Gründe finden.

Das Werkzeug gibt es in einer GUI- und in einer CmdShell-Variante. Ich kann es fast nicht erwarten bis ich wieder ins Büro komme, um das auszuprobieren!

Hier etwas O-Ton von Jerome Halmans:

Wouldn’t you rather know there is a problem before you entrust your data to such a complex process?

SQLIOSim is designed to generate exactly the same type and patterns of IO requests at a disk subsystem as SQL Server would, and verify the written data exactly as SQL Server would.
[…]

Want to see how your system will behave when that scheduled a DBCC CHECKDB check runs? No problem, just add the AuditUser section to the config file.

Have bulk load jobs? Well just add the BulkUpdateUser section.

Quelle: SQL Server Storage Engine : SQLIOSim available for download

17. August 2006 um 21:50

Datenbanken: 10 Schritte ins sichere Verderben

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.

17. August 2006 um 21:42

Hitzetod: Keine schöne Art seinen Rechner zu schrotten

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…

14. August 2006 um 20:27

Handbuch "Datenrettung" von Ontrack zum Download

Bei der PC-Welt gibt es das Handbuch "Datenrettung" von Ontrack zum kostenlosen Download. Der Preis besteht in dem Umstand sich einen (kostenlosen) Account bei der PC-Welt (bzw. dem Verlag IDG) anlegen zu müssen.

Die Lektüre der insgesamt 116 Seiten lohnt sich meines Erachtens für alle, die für die Sicherheit bzw. Sicherung von Datenbeständen verantwortlich sind. Es liest sich flüssig und ist sehr informativ. Auch für mich sind neue Infos dabei.

Im Gegensatz zu der in den Medien oft verbreiteten Meinung spielen
Naturkatastrophen als Ursache für Datenverlust nur eine untergeordnete
Rolle. Tatsächlich beruhen drei Viertel aller Schadensfälle
auf Störungen an der Hardware oder auf Bedienungsfehlern.

Als Hauptursachen werden genannt (aus einer Ontrack-Studie von 2002):

  • 44% – Funktionsstörungen der Hardware oder des Systems
  • 32% – Bedienungsfehler
  • 10% – Software-Fehler o. Funktionsstörungen von Software
  • 7% – Computerviren
  • 3% – Höhere Gewalt (Naturkatastrophen, Brände etc.)
  • 4% – Sonstiges
Diese Ursachen werden übrigens wieder als ach so beliebtes Kuchendiagramm dargestellt. Es ist diesmal zwar beschriftet, aber falsch…

Das die Bedienungsfehler (z.B. versehentliches Überschreiben) so häufig sind, hätte ich nicht gedacht. Allerdings bekomme ich davon auch nichts mit: unsere Kunden wenden sich nur an uns, wenn die Dateien noch da aber defekt sind. ;-)

Zu den Ursachen, die defekte Datenbanken haben können, verweise ich auch gerne auf meine Serie zu dem Thema.

7. August 2006 um 12:30

Vorgehen bei Datenbank-Reparaturen (Teil 2b)

Im vorherigen Teil der Serie zum Vorgehen bei Datenbank-Reparaturen am SQL Server 2000 wurde erklärt, wie man vorgeht, wenn das Tranlog defekt ist und die Datenbank ordentlich geschlossen wurde, d.h. das Transaktionslog im Prinzip leer ist. Trotz Urlaub will ich daran anknüpfen:
Was macht man aber, wenn die Datenbank nicht geschlossen wurde, sondern der Server abstürzte, weil die Festplatte langsam schrottet und just da auch noch das Tranlog rüber rudert? Das ist ein häufiges Szenario, weil das Tranlog sehr oft zugegriffen wird. Und deswegen besonders oft von Festplattenproblemen betroffen ist.

In diesem Fall muss wird die "Reparatur" etwas fummelig. Wenn man Glück hat, dann ist die Datenbank noch am SQL Server angehängt, aber als suspekt markiert. Wenn man den vorherigen Tipp ausprobiert hat ohne vorher die Master-Datenbank zu sichern oder einem die DB-Dateien zur Untersuchung zugeschickt wurden, dann muss man der SQL-Server erst mal austricksen, um die defekte Datenbank an den Server angehängt zu bekommen. Wenn man dann soweit ist, dass die Datenbank angehängt, aber suspekt ist, dann ist es nicht mehr so schwierig. Mit beiliegendem Statement bekommt man übrigens eine Liste aller Datenbanken mit deren Status:

SELECT name, databasepropertyex(name, 'status')
        FROM master.dbo.sysdatabases

Im Folgenden wird erklärt, wie man das Tranlog löscht und vom SQL Srever ein Neues anlegen lässt. Da im Tranlog aber eventuell wichtige Daten standen, erzeugt man dadurch möglicherweise einen inkonsistenten Datenbestand.

(1) Datenbank in den "Emergency-Mode" schalten. Beim nächsten Start wird für die Datenbank kein Recovery versucht:

– Änderungen in den Systemtabellen erlauben
exec sp_configure 'allow update', 1
reconfigure WITH override
go
– Datenbank in den Emergency mode setzen
UPDATE master..sysdatabases
        SET STATUS = STATUS | 32768
        WHERE name = 'MyCrashDB'
go
– Änderungen in den Systemtabellen verbieten
exec sp_configure 'allow update', 0
reconfigure WITH override

(2) SQL-Server-Dienst stoppen und neu starten. Erst danach ist die Datenbank im Emergency-Mode.

(3) Jetzt kann ein neues Transaktionslog angelegt werden. Vorher muss man die alte Tranlog-Datei noch schnell umbenennen (oder löschen, denn man hat ja vorher eine Kopie gemacht, oder?)

– Log neu erzeugen lassen:
DBCC rebuild_log ('MyCrashDB')

Das Ergebnis sieht etwa so aus:

Warning: The log for database 'MyCrashDB' has been rebuilt. Transactional consistency has been lost. DBCC CHECKDB should be run to validate physical consistency. Database options will have to be reset, and extra log files may need to be deleted.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

(4) Jetzt muss man die DB nur wieder auf "normal" schalten:

ALTER DATABASE MyCrashDB
SET online

Und schon hat man es geschafft.
Die gute Nachricht ist, dass man beim SQL Server 2005 nicht mehr in den Systemtabellen rumpfuschen muss. Die schlechte ist, dass immer noch viel Handarbeit notwendig ist. Naja, aber so arme Hunde wie ich müssen ja auch leben… ;-)

Im dritten Teil geht es dann um Reparaturen rund um DBCC CHECKDB.

4. August 2006 um 16:51

Ignorieren bis das Problem verschwindet

Ich staune immer wieder über das Urvertrauen, dass Menschen ihrer EDV-Anlage entgegen bringen…

Kürzlich passiert: Ein Kunde hat keine Probleme, aber lässt ganz brav mal eine Datenbank-Prüfung durchlaufen. Dabei werden Fehler gefunden und angezeigt. Aber der Kunde ignoriert das zwar, aber mit sowas rechnet unsere Software… ;-)
Von diesem Zeitpunkt an weisst unsere Software den Anwender nun ganz tapfer bei jedem Programmstart darauf hin, dass beim letzten Prüflauf Fehler gefunden wurden und dass er dringend etwas unternehmen soll… Z.B. mal eine Reparatur anstoßen oder unseren Service anrufen.
Im konkreten Fall haben die Anwender (sie kommt bei JEDEM: Chef und Mitarbeiter) die Meldung ebenso tapfer weggeklickt und einfach weitergearbeitet.

"Aufgeflogen" ist das Ganze nur, weil unser Datentrafo (im Rahmen eines Programm-Updates) sich weigerte auf einer defekten Datenbank loszulegen. Bei der Reparatur im Haus konnte nur eine Reparatur mit Datenverlusten durchgeführt werden. Einige "ältere" Daten sind einfach weg. Und weil der Defekt schon so lange besteht, kann der Kunde auch nicht einfach auf den letzten sauberen Stand zurücksetzen… Ich befürchte, dass der Kunde nicht nach der Ursache suchte, sondern jetzt wieder zufrieden ist.

Meine Erfahrung ist, dass PCs hier zu menschlich behandelt werden: "Jeder macht mal einen Fehler, Schwamm drüber." Meiner Ansicht nach ist Checkdisk schon recht einfach. Es wird nicht gemacht, weil das Bewusstsein für das Risiko nicht da ist.

Ich will nicht zu sehr mit Steinen werfen, denn ich bin in den meisten Dinge auch nicht besonders konsequent. Wenn allerdings meine berufliche Existenz davon abhängen würde… ;-)

31. Juli 2006 um 20:46

Vorgehen bei Datenbank-Reparaturen (Teil 2a)

Im ersten Teil der Reihe zum Vorgehen bei Datenbank-Reparaturen wurde erklärt, wie man vorgehen kann, wenn man eine Datenbank an einen SQL Server 2000 anhängen will, das aber nicht klappt, weil die Datenbank kaputt ist.

In diesem Teil geht es darum, wie man vorgehen kann, wenn das Transaktionslog defekt ist oder es von jemandem gelöscht wurde, der es für eine "ganz normale Log-Datei" hielt, die man ruhig löschen kann. Diese Irrlehre hält sich noch in einigen Köpfen… ;-)

Wenn das Transaktionslog futsch oder defekt ist, muss man beachten das eine inkrementelle Sicherungsstrategie damit schwere Rückschläge bekommt. Mann muss sofort nach der Reparatur eine Voll-Sicherung durchführen. Wie man bei der Wiederherstellung vorgeht, hängt vom Zustand der Datenbank ab. Wenn die Datenbank ordentlich geschlossen wurde und das Tranlog defekt ist, dann hat man sehr gute Chancen ohne Datenverluste aus der Geschichte rauszukommen. Wichtig ist immer, dass man vor dem Beginn der Analyse Kopien der Datenbank-Dateien anfertigt! Ich rate dazu den SQL Server zu stoppen und auch die Master-Dateien zu sichern.

Beispiel aus der Praxis: Ein Mitarbeiter hat etwas zu viel gelöscht. Jetzt wird der Admin gebeten die Sicherung vom Vortag wieder einzuspielen. Der Admin überschreibt die Dateien von heute mit der Sicherung von gestern (Festplattenvollsicherung bei gestopptem SQL Server, benutzt wird Simple Recovery Mode). Unerklärlicherweise lässt sich die Datenbank danach nicht zugreifen. Analyse: Tranlog-Datei völlig geschrottet. Die Datenbank wurde als suspekt markiert, weil kein Recovery durchgeführt werden konnte.

In diesem Beispiel kann man vergleichsweise einfach zum Ziel kommen. Die Datenbank-Datei wurde ordnungsgemäß geschlossen. Daher enthält das Tranlog keine Infos, die nicht schon in der Datenbank eingepflegt wurden. Man kann den SQL Server "einfach" ein Neues anlegen lassen:

(1) SQL Server stoppen, LDF umbenennen (oder löschen, man hat ja eine Kopie), SQL Server starten.

(2) Datenbank trennen und nur mittels der MDF wieder anhängen:

exec sp_detach_db 'MyCrashDB'

exec sp_attach_single_file_db 'hahaha',
'e:\Programme\Microsoft SQL Server\MSSQL$MYLITTLESQL\data\MyCrashDB.MDF'

Man bekommt beim Anhängen zwar einen Fehler, aber die Datenbank lässt sich prima wieder anhängen.

Device activation error. The physical file name 'e:\Programme\Microsoft SQL Server\MSSQL$MYLITTLESQL\data\MyCrashDB_log.LDF' may be incorrect.
New log file 'e:\Programme\Microsoft SQL Server\MSSQL$MYLITTLESQL\data\MyCrashDB_log.LDF' was created.

Und fertig ist die Lauge. Herzlichen Glückwunsch. Man sollte danach in jedem Fall eine neue Datensicherung machen. Nicht nur, wenn man ein inkrementelles Backup verwendet.

Im nächsten Teil geht es dann darum, was man macht, wenn die Datenbank nicht sauber heruntergefahren wurde.

28. Juli 2006 um 21:55

Was bringen CheckDB-Läufe?

Vor ein paar Tagen hat Paul Randall in seinem Artikel Can't I ever get a guarantee? diskutiert, ob man sicher sein kann, dass alles OK ist, wenn der DBCC-CheckDB-Lauf keine Fehler meldete. Er weißt zu Recht darauf hin, dass seit der Prüfung der ersten Seiten inzwischen genau dort ein Problem aufgetreten sein könnte. Das ist natürlich etwas spitzfindig, aber es ist nicht ganz von der Hand zu weisen. Generell bringt sie aber schon eine deutliche Sicherheit, ob das was man sichern will, auch OK ist.

Kann eine Prüfung schaden? Als wir noch den Sybase SQL-Anywhere einsetzten, kam einmal der Verdacht auf, dass eine Datenbank durch die Prüfung zerstört worden sein soll. Dazu muss man wissen, dass man ihn so einstellen kann, dass die Datenbank-Dateien generell geschlossen sind und nur geöffnet werden, wenn jemand darauf zugreift. Zwischen zwei Prüfläufen wurde die Datenbank angeblich nicht angfasst und dennoch war sie bei der vorletzten Prüfung OK und bei der Letzten wurde ein Fehler gemeldet.

Wenn man etwas wackelige Hardware einsetzt, z.B. ein defektes RAM im RAID-Controller, dann kann es schon sein, dass die Datenbank durch das Öffnen/Schließen und den damit verbundenen Checkpoints defekt wird.
Aber bevor ich wegen dieser Möglichkeit mein Sicherungskonzept überdenke, würde ich lieber vor der Datenbank-Prüfung eine Hardware-Prüfung durchführen…

24. Juli 2006 um 22:34

Vorgehen bei Datenbank-Reparaturen (Teil 1)

Wir haben an "schlechten" Tagen täglich mit Datenbank-Defekten unseren Kunden zu tun, was sicher auch damit zu tun hat, dass wir diese Reparaturen bis vor kurzem meistens kostenfrei durchführten. Für den Microsoft SQL Server 2000 möchte ich ein paar Tipps geben, die ich immer wieder gerne versuche, wenn sich herausstellen sollte, dass die einfachen Mittel (dbcc checkdb) nicht mehr helfen….

Im ersten Teil geht es um Probleme, wenn die Datenbank nicht angehängt werden kann.

Wie kann das passieren?
Der Kunde meldet sich bei der Hotline und beklagt, dass die Datenbank defekt ist. Dann führen die Jungs und Mädels ein paar Standard-Dinge durch. Manchmal kommen sie zu dem Schluss, dass man vor Ort einfach nichts mehr machen kann und holen die Daten in die Firma. Um sie dann im Hause untersuchen zu können, muss man die Datenbank erst mal an einen SQL-Server anhängen. Wenn das mit Bordmitteln nicht mehr geht, dann ist das ein ganz schlechtes Zeichen. Aber meist kann man da noch etwas machen. Das Anhängen geht meistens dann noch über einen Dummy:

  1. Ich lege eine neue leere Datenbank irgendwo an. Die Datenbank muss mit so vielen Dateien angelegt werden, wie das anzuhängende Original. Um es einfacher zu haben, liegen bei mir dann immer alle Dateien im gleichen Verzeichnis.
  2. Dann stoppe ich den SQL-Server.
  3. Löschen der Dateien der neuen leeren Datenbank.
  4. Die originalen Dateien der defekten Datenbank dorthin kopieren.
  5. SQL Server starten.
    Weil die Datenbank sich nicht einfach öffnen lässt, wird sie beim Starten als suspekt markiert.
  6. Jetzt kann man die Datenbank in den Emergency-Mode setzen.
  7. Dann muss man den SQL-Server nochmals stoppen ud starten. Dabei wird für die Datenbank kein Recovery versucht.
  8. Und schon kann man die eigentliche Analyse bzw. Reparatur beginnen.

So setzt man die Datenbank beim SQL-Server-2000 in den Bypass- bzw. Emergency-Mode:

exec sp_configure 'allow updates', 1
reconfigure WITH override
GO
UPDATE sysdatabases SET STATUS =  STATUS | 32768 WHERE name = "myDB"
go
exec sp_configure 'allow updates', 0
reconfigure WITH override

Quelle: Das habe ich aus den Books-Online. Ich finde aber gerade nicht die Stelle. Bitte nach der Reparatur nicht vergessen den Status zurückzusetzen… ;-)

Beim SQL-Server-2005 ist das deutlich einfacher:

ALTER DATABASE myDB SET emergency

Demnächst geht es weiter…

Anbei die Links zu der Serien mit den Ursachen von Datenbank-Defekten:

  • skurrile Gründe im ersten Teil
  • Probleme mit Festplatten im zweiten Teil
  • Datenverluste durch eine defekte Datensicherung im dritten Teil
  • systemnahe Programme, die den I/O umbiegen, im viertel Teil
  • defekter Hauptspeicher im fünften Teil