Nachdem ich die ganze Lauferei über die Winterzeit ziemlich schleifen ließ und nur gemächlich dann und wann trabte, war es am 21.03.2010 immerhin so gutes Wetter, dass ich sehen wollte, wie schnell ich die 10 Kilometer eigentlich zu laufen in der Lage war. Sieht man davon ab, dass ich nach dem Lauf völlig kaputt war, lief es sich ganz gut: Ich hielt über die gesamte Strecke einen konstanten Schnitt von 4:40 Minuten pro Kilometer, lief durchschnittlich aber auch auf 93% meiner Herzfrequenz. Am Ende stand eine Zeit von 46:54 und ich war erst einmal zufrieden damit.

6 Wochen später beim BIG25 zu laufen, war an sich gar nicht meine Idee, aber der zeitliche Rahmen passte genau auf den mitgelieferten Trainingsplan dessen Ziel vorsah die Zeit auf 44 Minuten zu drücken.

Also .. ok.

Ehrlich zugegeben: Ich fand – und finde – diese Pläne ein wenig seltsam. Das hat sicherlich damit zu tun, dass man eine Menge Läufe macht, die um das eigentliche Ziel herumkreisen. Ich laufe Intervalle. Ich laufe lang aber relativ langsam. Ich laufe sehr lang und noch viel langsamer. Nirgendwo in diesem Plan gab es den Punkt: So, und jetzt üben wir mal 10km am Stück mit der gewünschten Geschwindigkeit durchzulaufen.

Sicher, das erklärt sich damit, dass der Wettkampf eine Strapaze ist, die nichts zum Training beiträgt und der Plan einen in die Lage versetzt eben diese Leistung zu bringen. Aber so ins Dunkel hinein? Mhm.

Immerhin beinhaltete dieser 6-Wochen-Plan auch meinen ersten Halbmarathon.

Sieht man von meiner allgemeinen Beunruhigung über die unklare Erfolgskontrolle ab, machte sich das Training aber gut: Ich hatte nicht direkt das Gefühl leichter zu laufen, aber mein Puls ging im Schnitt zwischen 5 und 10 Schlägen für die gleiche Geschwindigkeit nach unten.

Am 09.05.2010 hatte ich nun also nicht direkt das Gefühl perfekt vorbereitet zu sein, aber ich hatte meinen Plan soweit brav erfüllt und damit immerhin ein gutes Gewissen.

Ankommen. Warmmachen. Einordnen. Loslaufen.

Ja, da war es, dieses leichte Gefühl vor dem ich bereits gewarnt worden war. Diese adrenalinschwangere Lockerheit, die schnell in einen Katzenjammer umschlagen konnte. Die Masse bremste natürlich, dennoch mußte ich vorsichtig ein wenig langsamer werden. Dennoch: Bei leichtem Gefälle war der Pace des ersten Kilometers bei unter 4:25. Eine Sekunde zu langsam für meinen avisierten Schnitt von 4:24 – aber eben künstlich gebremst durch den Pulk der Läufer.

Danach ging es rascher, bis der erste Eckpunkt kam und das sanfte Gefälle nicht nur endete, sondern zum Anstieg wurde: für Kilometer 6 meldete meine Uhr einen Pace von 04:23, immerhin 19 Sekunden schlechter als beim Vorgänger.

Zu diesem Zeitpunkt hatten sich die 25km-Läufer längst abgespalten und eine sehr dünne Schnur von Läufern zog sich vor mir her – vielleicht alle 20 Meter jemand. Ich blieb relativ konstant beim Tempo, überholte gemächlich den Einen oder Anderen, bis ich etwa bei Kilometer 8,5 selbst das erste Mal seit der Trennung vom großen Pulk selbst überholt wurde.

Woah. Von einer Frau! 1500 Meter blieben noch, also ignorierte ich das leichte Ziehen in der Seite und versuchte mich an ihre Fersen zu hängen. Wider Erwarten klappte das ganz gut, mit ihr als Tempomacher lief ich noch an ein paar Leuten vorbei und dann hinein in das Stadion. Zu dem Zeitpunkt hatte meine Uhr, wahrscheinlich irgendwie irritiert, bereits das Erreichen der 10km-Marke signalisiert, auf den blauen Bahnen wurde aus dem Ziehen dann noch echter Schmerz und als ich über die Ziellinie holperte, war da nicht viel Euphorie.

Gehen – Aua.
Atmen – Aua.

42:33 lautete später meine offizielle Zeit.
Scheint fast, als hätte das mit dem Training ins Blaue hinein funktioniert.

Gestern bin ich das erste Mal wieder richtig gelaufen und das gleich am Limit – als die 10 km durch waren, fühlte ich eine großartige Dankbarkeit. Allgemein lief es sich an sich ganz gut, aber eben auch anstrengend. Zu meinem Erstaunen konnte ich dabei dennoch ein konstantes Tempo halten.

Ansonsten: Heute das erste Mal mit Jacke und Mütze gelaufen. Das hat sicherlich seinen Teil beigetragen. ^^

Insgesamt 12 Kilometer ohne jedes Quentchen mehr.

Und ich konnte die ganze Zeit nebenbei telefonieren. ^^

Tatsächlich war ich dieses Mal mit Runde 1 langsamer als beim ersten Versuch vor einer Woche:

Nunja. In Summe kam ich in der Stunde knapp 100 Meter weiter als letzte Woche. Nun steht zu hoffen, dass der Muskelkater sich in Grenzen hält, damit Donnerstag das nächste Mal stattfinden kann.

Ich hätte mir ja denken können, dass das weh tun wird: Nach einer ganzen Weile habe ich vor zwei Tagen wieder begonnen zu laufen und zwei Runden im Jungfernheidepark gedreht + einige Zusatzstrecke.

Das war soweit auch ganz problemlos, nach der vorgenommenen einen Stunde hatte ich knapp 12 km zurückgelegt und fühlte mich noch ganz frisch.

Knapp drei Stunden später waren die Unterschenkel dann ganz schwer, am nächsten Morgen meldeten sich dann die Oberschenkel – und tun es immernoch. Der Plan sagt: Heute nächste Runde. Das kann ja was werden. :)

create tablespace sysaux datafile 'path/name' SIZE 512M;

Oracle empfiehlt hier Folgendes:

Create the SYSAUX tablespace only if you are upgrading from Oracle Database9i Release 2 (9.2) with the following mandatory attributes:

ONLINE
PERMANENT
READ WRITE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO

Der Haken liegt bei der letzten Option, die unter 9i nicht default ist – normal wird MANUAL gesetzt. Starten wir das Upgrade dann mit diesem falschem Sysaux, schlägt catupgrd sehr schnell fehl:

SELECT TO_NUMBER ('Not AUTO segment space management') from ts$
                   *
ERROR at line 1:
ORA-01722: invalid number

Disconnected from Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

Damit stecken wir dann in der Klemme: Wir können den Tablespace unter 11g nicht löschen:

SQL> drop tablespace sysaux;
drop tablespace sysaux
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kttdtsn-1], [], [], [], [], [], [], [], [], [], [], []

Wir kommen aber auch nicht mehr auf 9i zurück, um das dort zu tun:

SQL> alter database mount;
ORA-00201: controlfile version 9.2.0.0.0 incompatible with ORACLE version 9.2.0.0.0
ORA-00202: controlfile: 'path/file_01.ctl'

Soviel dazu. Gut, dass dies eine Spieldatenbank ist, deren vollständiges Recovery (nicht nur Controlfiles, sondern auch Datenfiles) ganz schnell geht..

1. Installation der Datenbanksoftware 10.2.0.1
2. Erstellung einer Datenbank auf 10.2.0.1 mit passenden Parametern
3. Installation von Grid Control mit dem Full Installer auf 10.2.0.2
4. Patch von Grid Control auf 10.2.0.4
5. Patch der Datenbank auf 10.2.0.4

Ab diesem Punkt entsprach die Software unserem aktuellen produktiven Stand und bis dahin war auch alles problemlos gelaufen. Die Schwierigkeit kam nun beim interessanten Sprung – der Installer brach zwischenzeitlich mit einer Fehlermeldung ab. In den Logs läßt sich dazu Folgendes finden:

Calling updateConfig to notify DCM of new deployments...
failed!
ERROR: Caught exception calling updateConfig: oracle.ias.sysmgmt.exception.ParsingException: Das Plug-In "apache", das von der "OHS"-Komponente zur Verfügung gestellt wird, hat beim Lesen der Konfigurationsdaten eine Exception ausgelöst.
Lösung:
Die Informationen der "OHS"-Komponente in der Basis-Exception sind möglicherweise hilfreich.
Außerdem gibt es folgende allgemeine Problemursachen:
    Falsche Berechtigungen für Dateien
    Konfigurationsdateien fehlen oder sind ungültig
Exception von Plug-In ausgelöst"apache":
oracle.ias.sysmgmt.repository.plugin.advanced.apache.parser.ParserException
parsing e:\oracle\product\oms10g\Apache\Apache\conf\ssl.conf: </ expected at line 39 column 44, but encounter <EOF: END OF FILE>

ERROR! DEPLOY TOOL CANNOT CONTINUE DEPLOYMENTS: could not update DCM repository with newly deployed applications - ALL APPLICATIONS WILL BE UNDEPLOYED.

Undeploying application 'portletapp' from OC4J instance 'home'.

Application 'portletapp' successfully undeployed.
Stopping OC4J instance 'home'...
done.
Terminating DCM...
done.
Copying e:\oracle\product\oms10g/j2ee/deploy.ini to e:\oracle\product\oms10g/j2ee/deploy.ini.1238741828013.bak.
Writing any undeployed entries back to e:\oracle\product\oms10g/j2ee/deploy.ini.

Oc4jDeploy tool completed, but with errors.

Mhm. Ein Blick in die bemängelte ssl.conf zeigt den Fehler: Zum IfDefine SSL gibt es schlicht und einfach kein schließendes Tag. Das kann nun als </IfDefine> einfach ergänzt werden .. und schon läuft alles hübsch durch.

Ein Blick in die Konfiguration unseres produktiven OMS enthüllte übrigens, dass dort alle Tags brav geschlossen sind ..

Update 09.05.2009:

Man soll den Tag ja nicht vor dem Abend loben .. beim Versuch den produktiven OMS zu patchen, gab es genau diesen Fehler. Offenbar wird zwischendurch die alte ssl.conf überschrieben.

Update 02.06.2009:

Es gibt eine Bugbeschreibung von Oracle dazu: 8339545

Das Vorgehen wird dort wie folgt beschrieben:

1) Keep the installer session active at the failure point.

2) Navigate to .../oms10g/Apache/Apache/conf/ and archive the existing ssl.conf file (verify it is only 2kB in size, exemplary of the problem).

3) Copy the ssl.conf.smibak (should be about 7kb in size) to ssl.conf.

4) Select "Retry" in the failed installer session.

5) Watch the 10.2.0.5.0 patchset installation complete successfully.

Stoppen und Starten des Agenten via emctl ist genausowenig hilfreich wie die Erneuerung der Grid Control Konfiguration.

Das Internet brachte einmal mehr die Lösung:

1. Stoppen des Agenten

oraadmin@deerlf0vl1 [AGENT]  /opt/oracle/oraadmin/admin/AGENT
> emctl stop agent
Oracle Enterprise Manager 10g Release 4 Grid Control 10.2.0.4.0.
Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.
Stopping agent ... stopped.

2.  Zurücksetzen der Zeitzone

oraadmin@deerlf0vl1 [AGENT]  /opt/oracle/oraadmin/admin/AGENT
> emctl resetTZ agent
Oracle Enterprise Manager 10g Release 4 Grid Control 10.2.0.4.0.
Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.
Updating /opt/oracle/oraadmin/product/10.2.0.4/initial/agent10g//sysman/config/emd.properties...
Successfully updated /opt/oracle/oraadmin/product/10.2.0.4/initial/agent10g//sysman/config/emd.properties.
Login as the em repository user and run the  script:
exec mgmt_target.set_agent_tzrgn('deerlf0vl1.erlf.siemens.de:3872','Europe/Berlin')
and commit the changes
This can be done for example by logging into sqlplus and doing
SQL> exec mgmt_target.set_agent_tzrgn('deerlf0vl1.erlf.siemens.de:3872','Europe/Berlin')
SQL> commit

3. Verbindung mit sqlplus wie gefordert

SQL> exec mgmt_target.set_agent_tzrgn('deerlf0vl1.erlf.siemens.de:3872','Europe/Berlin')
SQL> commit;

4. Agent neu starten
emctl start agent

Et voila .. unser Ziel schaltet in der Ansicht von Grid Control wieder auf verfügbar um.

Interessanterweise trat dieses Problem nicht bei allen Datenbanken auf – warum kann ich im Moment noch nicht sagen.

Ergänzung: Es ist wichtig die Schritte in der absolut richtigen Reihenfolge auszuführen:

1. emctl stop agent
2. emctl resetTZ agent
3. SQL set_agent_tzrgn
4. emctl start agent

Update: Eine interessante Entwicklung: Ich stieß ein Script an, welches eben diese vier Schritte auf allen Solaris-Zonen ausführen sollte. Nachdem das geschehen war, kamen die entsprechenden Datenbanken wie gewünscht wieder online .. und dazu auch alle anderen Datenbanken. O_o

Das heisst: Tatsächlich muss das Problem an einem mir nicht bekannten Agenten gehangen haben und dessen Sauberstellung sorgte dann dafür, dass sich überall – sogar bei den Windowsmaschinen – die Klemme von allein löste. Faszinierend. :/

Der Entdeckung ging ein „klassisches“ Recovery-Szenario zur Übung voraus: Verlust sämtlicher Kontrolfiles der Datenbank.

Bei 9.2.0.8 und 10.2.0.4 ergibt der Versuch etwas über die DB-Struktur zu erfahren folgenden Fehler:

SQL> select name from v$tempfile;
select name from v$tempfile
                 *
ERROR at line 1:
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/opt/oracle/orarman/oradata/RAPOS/control_1/RAPOS_01.ctl'
ORA-27041: unable to open file
SVR4 Error: 2: No such file or directory
Additional information: 3

Bei 11.1.0.7 habe ich dagegen überhaupt kein Problem: Brav wird mir die Struktur angezeigt, ich kann Änderungen vornehmen (Datenfiles adden beispielsweise) und schliesslich sogar ein alter database backup controlfile to trace durchführen.

Erst wenn ich versuche die Datenbank immediate herunterzufahren bekomme ich einen Fehler – und sobald ich sie mit abort in den Sand gesetzt habe, kann sie natürlich nachher nicht mehr starten.

Das Recovery ist jedoch denkbar einfach: Solange die Datenbank noch läuft, wird mit alter database backup controlfile to trace ein Trace erzeugt und anschließend benutzt. Sogar die noresetlogs-Version funktioniert tadellos.