Letzten Freitag hätte ich beinahe schon wieder die Krise gekriegt... Der brandneu installierte Oracle Application Server reagiert auf einmal absolut merkwürdig: Während ich mich in Firefox ganz normal per Single-Signon in Portal anmelden kann, bringt der IE nach Eingabe von Username und Passwort ein 404. WTF...
Beherzter Neustart verschlimmmbesserte die Situation lediglich dahingehend, daß jetzt sowohl im FF als auch im IE eine Security- Fehlermeldung erschien, die eigentlich darauf hinweist, daß irgendein Dappes das Datenbank- oder OID-Passwort vom ORASSO-User geändert haben muß (denn die müssen auf jeden Fall übereinstimmen). Das konnte aber irgendwie auch nicht sein - ich hatte das Teil ja erst ein paar Tage zuvor installiert, und außer mir war da noch niemand zugange. Außerdem änderte sich das Verhalten auch noch von Versuch zu Versuch - mal funktionierte es im Fuchs, dann wieder nicht.
Im Enterprise-Manager wurde der SSO-Prozess auch brav als "running" angezeigt.
Des Rätsels Lösung: Der Management-Prozess hatte sich wohl irgendwie verhakt (und das unter Solaris!). Nachdem ich alles heruntergefahren, alle anschließend noch existierenden Prozesse im Infrastructure-Home gekillt und dann normal wieder hochgefahren habe war der Spuk wieder vorbei. Das hätte mir sonst aber auch ganz schön das Wochenende versaut.
... und eine gesunde Paranoia hat noch nie geschadet - better safe than sorry (soll heißen: Diesen Beitrag kann ich zu 100% unterschreiben - bei kritischen Aktionen schaue ich immer dreimal hin bevor ich das Kommando abschicke...).
Hier mal ein Video für alle die glauben, eine Oracle-Installation sei unglaublich umständlich und kompliziert und würde Stunden dauern (jedenfalls hat das IBM wohl in Dänemark gegenüber Kunden behauptet - und Miracle beweist eindrucksvoll das Gegenteil - man beachte die Uhr unten rechts):
Zum Beitrag darunter zunächst so viel: Wer mich einigermaßen kennt, der weiß natürlich, daß der Ausspruch die reine Polemik war - trefflich dazu geeignet, Unbekannte in die Irre zu führen oder aber Freunde aus der Reserve zu locken (was leider nicht funktioniert hat), denn selbstverständlich ist es vollkommen logisch, daß Computer an sich perfekt sind:
Noch nie hat ein Computer der Serie 9000 einen Fehler gemacht. Es war immer menschliches Versagen." Computer HAL in 2001 - Odyssee im Weltraum
Natürlich war es auch dieses Mal so. Und zwar Samstag Nacht - ich wollte gerade dem Herrn Müller demonstrieren, wie das wohl aussieht wenn er übers Internet auf meinen "Spielserver" zugreift. Nun hatte der ja schon vor einer ganzen Weile ein nicht wirklich schönes Geräusch von sich gegeben, weshalb ich ihn auch nicht mehr im Dauerbetrieb laufen hatte (von der potentiellen Stromersparnis mal ganz abgesehen) - wer schon mal eine langsam sterbende Festplatte gehört hat, der weiß was ich meine, dieses hochfrequente Sirren. Und just in dem Moment war es dann also soweit: Der Webserver ließ sich nicht mehr starten, und als ich im Log nachsehen wollte, was der wohl für Beschwerden hat - rumms. Also noch mal kurz beherzt einen Power-On-Reset probiert, aber es war nichts mehr zu machen. reiserfsck meldete, daß es an einer bestimmten Stelle nicht auf die Platte schreiben kann und wahrscheinlich ein Hardware-Defekt vorliegt - nachvollziehbar, auch beim zweiten und dritten Versuch. So weit so schlecht.
Montag Nacht habe ich mich dann daran gemacht, zu retten was zu retten war. Mittels dd-rescue - ein sehr schönes Werkzeug, welches bei Knoppix mit an Bord ist - habe ich also den noch lesbaren Inhalt der Platte auf eine andere kopiert. Das schöne daran ist, daß man sich um Parameter (wie Start- und Endblock der Aktion) und das Ausschließen der defekten Blöcke gar nicht zu kümmern braucht: Die 96 bad blocks (die übrigens nicht einmal zusammenhingen) wurden einfach übersprungen, stattdessen werden auf der Zielplatte einfach Nullwerte geschrieben.
"Da sind doch dann aber Löcher an diesen Stellen in den Dateien" höre ich den einen oder anderen Leser schon unken - aber: Don't panic. Nicht umsonst hat man ein "sicheres" Dateisystem. Das anschließende reiserfsck --check meldete zum Glück dann "4 fixable errors" - und diese habe ich dann eben fixen lassen, anschließend konnte ich mein System (übrigens ein betagtes, aber immer noch gutes Suse Professional 8.2) wieder ganz normal hochfahren, und auch die Datenbank und der Webserver laufen wieder "wie neu".
Zwei Dinge bleiben mir noch anzumerken:
- Natürlich war das mehr Glück als Verstand. Eine Festplatte kann nämlich auch so kaputtgehen, daß der Rechner sie erst gar nicht mehr erkennt oder daß deutlich mehr als 44 Kilobyte defekt sind. Wehe, wenn man dann kein Backup hat.
- Natürlich war auf dem Rechner nichts wirklich wichtiges gespeichert, es ist wie gesagt mein "Spielserver", auf dem ich gelegentlich mal etwas ausprobiere (zum Beispiel ob ein Oracle-Patch das gewünschte Ergebnis bringt). Von meinen wirklich wichtigen Daten wie Digitalfotos oder selbstgemachter Musik habe ich selbstredend mindestens zwei Kopien. Dennoch wäre es ärgerlich gewesen. Alles neu aufzusetzen hätte nämlich bedeutend mehr Zeit gekostet als das Wiederherstellen - aber es hat ja zum Glück geklappt.
Wie war das doch gleich? Jede Datei, von der Du nicht mindestens ein Backup hast kannst Du als potentiell gelöscht betrachten.
Ich habe tatsächlich über unseren Lieferanten kostenlos den defekten Akku ausgetauscht bekommen - manchmal hat es seine Vorteile, wenn man Großkunde ist :-)
Die "Seele" des neuen Teils ist übrigens nicht - wie der nach einem Jahr verschiedene - vom Hersteller mit den vier Buchstaben, sondern von der Konkurrenz mit ganz ähnlich klingendem Namen mit fünf Buchstaben - honi soit qui mal y pense...
Der Plan: Ab 16 Uhr ist die Produktion durch, wir haben das System für uns und können mit der Umstellung auf ein neues Release beginnen - spätestens fünf Stunden später sollte es gelaufen sein.
Die Realität: Wir können doch erst gegen 18:30 beginnen. Zunächst klappt alles wie geprobt, wir sind immer noch guter Dinge. Auf einmal kommt es zu einem "Klemmer" - ein Update-Prozess scheint nicht weiterzulaufen, braucht für jeden Schritt Stunden anstelle der erwarteten Minuten. Wir können dieses Verhalten immerhin auf bestimmte Datenbankabfragen eingrenzen, also scheint es kein generelles Problem zu sein.
Gegen 23 Uhr gehen wir ein - selbstverständlich alkoholfreies, man will ja auch noch nach Hause fahren - Bier trinken und schauen dann später noch einmal nach, wie weit das Ganze gediehen ist. Leider sieht es gar nicht gut aus, der Prozeß hat sich kaum von der Stelle bewegt... wir gehen erst einmal nach Hause und treffen uns am Samstag Morgen wieder.
Die Lösung des Problems war dann letztendlich ganz simpel: Statistiken über das von den Änderungen betroffene Schema laufen lassen, und schon flutschte es wieder. Den Verdacht hatte ich eigentlich gestern Nacht schon... 9i verhält sich da eben doch ein wenig anders als 10g.
