Tenebrias

~ Ein Spiegel für den Winter meiner Seele ~

Lauf IV

Verfasst von Tenebrias am 03.10.2009 - 14:11

Puh. Heute ging beinahe gar nichts. Ich konnte zwar ohne Einwärmung laufen, aber die Beine waren schwer. Wie beim letzten Mal habe ich auch diesmal die Stunde durchtelefoniert, gefühlt hat das diesmal aber deutlich mehr belastet.

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

Insgesamt 12 Kilometer ohne jedes Quentchen mehr.

# Hinlaufen Runde 1 Runde 2 Endschleife
03.10.2009 00:03:33 00:23:41 00:24:00 00:09:49
01.10.2009 00:03:41 00:22:29 00:21:56 00:11:54
29.09.2009 00:03:37 00:23:09 00:21:35 00:11:37
22.09.2009 00:03:13 00:22:36 00:22:23 00:11:18

Veröffentlicht in Leben | Verschlagwortet mit : | Kommentar schreiben »

Lauf III

Verfasst von Tenebrias am 01.10.2009 - 16:17

Heute bin ich gefühlt sehr leicht gelaufen, ebenso gefühlt auch relativ langsam. Die Zeiten widersprechen dem und tatsächlich habe ich im Vergleich zum letzten Lauf erneut knapp 100 Meter Gesamtstrecke in der Stunde zugelegt. Auffällig diesmal: Das Warmlaufen, für das ich sonst immer mindestens 3 Kilometer brauche, fiel aus.

Und ich konnte die ganze Zeit nebenbei telefonieren. ^^

# Hinlaufen Runde 1 Runde 2 Endschleife
01.10.2009 00:03:41 00:22:29 00:21:56 00:11:54
29.09.2009 00:03:37 00:23:09 00:21:35 00:11:37
22.09.2009 00:03:13 00:22:36 00:22:23 00:11:18

Veröffentlicht in Leben | Verschlagwortet mit : | Kommentar schreiben »

Lauf II

Verfasst von Tenebrias am 29.09.2009 - 18:39

Diesmal war der Anfang gefühlt leichter als beim erste Mal und ich hatte das Gefühl auch besser voranzukommen, obwohl es letztlich wieder ähnlich ablief: Erste Runde schwer. Zweite Runde deutlich besser.

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

# Hinlaufen Runde 1 Runde 2 Endschleife
29.09.2009 00:03:37 00:23:09 00:21:35 00:11:37
22.09.2009 00:03:13 00:22:36 00:22:23 00:11:18

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.

Veröffentlicht in Leben | Kommentar schreiben »

Muskelkater

Verfasst von Tenebrias am 24.09.2009 - 07:17

Aua.

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. :)

Veröffentlicht in Leben | Verschlagwortet mit : | Kommentar schreiben »

Fallstricke bei der 11g Migration

Verfasst von Tenebrias am 13.05.2009 - 08:48

Fallstricke bei der Migration auf 11g Szenario: Unsere 9i Spieldatenbank soll auf 11g migriert werden. Die Vorbereitungen sind weitgehend abgeschlossen, nur der SYSAUX-Tablespace fehlt noch. Diesen erstellen wir noch unter 9i unter Ignoranz der Oracle-Empfehlung einfach mit den Defaultwerten:

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..

Veröffentlicht in Arbeit | Kommentar schreiben »

Grid Control Update von 10.2.0.4 auf 10.2.0.5 schlägt fehl

Verfasst von Tenebrias am 06.04.2009 - 07:53

Zwecks Test des neu erschienenen Grid Control Updates von 10.2.0.4 auf 10.2.0.5 auf Windows erstellte ich eine komplett neue Installation mitsamt Repository in folgender Reihenfolge:

  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.

Veröffentlicht in Arbeit | Verschlagwortet mit : , , , , , | 3 Kommentare »

Grid Control und die Sommerzeit

Verfasst von Tenebrias am 30.03.2009 - 08:04

Wie bereits befürchtet, hat uns die Zeitumstellung am gestrigen Sonntag bei Grid Control Probleme bereitet. Ganz knapp: Nahezu alle unsere Datenbanken hatten den Status Pending und konnten nicht mehr überwacht werden.

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. :/

Veröffentlicht in Arbeit | Kommentar schreiben »

Controlfiles bei 11.1.0.7

Verfasst von Tenebrias am 27.03.2009 - 13:43

Ein für mich neues Feature von 11.1.0.7 (ich habs bei 11.1.0.6 nicht getestet): Offenbar werden die Controlfiles nur noch zum starten und stoppen der Datenbank benötigt.

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.

Veröffentlicht in Arbeit | Verschlagwortet mit : , , , , , , | Kommentar schreiben »

Waitevents beim Erstellen eines OMS

Verfasst von Tenebrias am 26.03.2009 - 11:53

Nachdem nun seit einigen Tagen Grid Control in Version 10.2.0.5 für Windows und Linux verfügbar ist, habe ich mich entschlossen einen ersten Test durchzuführen. Dafür sollte die brav laufende OMS-Landschaft (Repository auf 10.2.0.4, ein OMS auf Windows, ein OMS auf Solaris) nicht angetastet werden.

Also installierte ich auf einer freien Maschine zuerst eine 10.2.0.1 DB-Software samt Datenbank in Defaulteinstellung und schob dann die Installation des OMS in Version 10.2.0.2 an.

Dabei waren an der Datenbank noch ein paar Extraeinstellungen notwendig:

  • session_cached_cursors auf mindestens 200
  • aq_tm_processes auf mindestens 1
  • DBMS_SHARED_POOL erstellen: @?/rdbms/admin/dbmspool

Danach lief der Installer brav an .. und lief .. und lief .. und lief …

2 Stunden später begann ich mich ernstlich zu fragen, was da eigentlich noch passierte.

Ein Blick in v$session_wait zeigte mir knapp 20 sehr lange andauernde Waits der wait_class <b>Scheduler</b> mit dem Even: <b>resmgr:become active</b>.

Mhm. Noch nie gesehen. Danach schaute ich in v$sql um zu sehen, ob überhaupt etwas neues kommt – Fehlanzeige.

Google hilft weiter:

resmgr:become active (Oracle 10g and higher)

* Meaning: Preventing database connections due to an active QUIESCE session
* Optimization steps:

Generally, this wait situation occurs when you execute certain EMCA operations such as the operation for creating the EM repository. As a result of these operations, the systems implicity switches to QUIESCE mode. Therefore, all database connections (except users SYS and SYSTEM) must wait for „resmgr:become active“. In this case, refer to Note 1044758 and execute the following command if necessary:

ALTER SYSTEM UNQUIESCE;

Nach diesem schönen Statement verschwanden die Waits augenblicklich, v$sql wurde mit neuen Anweisungen geflutet .. alles lief weiter.

Wunderhübsch.

Veröffentlicht in Arbeit | Verschlagwortet mit : , , , , | Kommentar schreiben »

Nauntelrir

Verfasst von Tenebrias am 14.11.2008 - 18:42

Für den eiligen Leser

  • Einordnung: Artefakt, eine Widderhornkrone
  • Schöpfer: Khalizius
  • Besitzer: Cobija
  • Beinamen: Grimmstirn
  • Sonstiges: Die Widderhornkrone wurde es dem Bruchstück eines zersprengten Seraphs geformt

Beschreibung

Öffentlich

Nauntelrir, auch Grimmstirn gerufen – das sind im Normalzustand einfach nur zwei verdrehte, goldglänzende Widderhörner von entsprechendem Gewicht, die durch ein eisernes Runenband von knapp einem Spann Länge verbunden sind. Erst wenn ein Träger diese Hörner an den eigenen Schädel hält, offenbart sich die eigentliche Gestalt: Binnen Momenten überzieht helles Gold den gesamten Kopf bis zum Hals hin und verdeckt alle Details. Augen, Ohren und Mund entstehen erst gut einer Minute und erlauben dem Erstickenden wieder Atem zu schöpfen – formen dabei eine gräßliche Dämonenfratze, die allein die Emotionen der flüsternden Widderhörner zuläßt.

Begabte

Die Widderhornkrone ist nicht nur frei von Magie, sondern besitzt nicht einmal eine astrale Aura. Für astrale Wahrnehmung ist sie vollkommen unsichtbar.

Geweihte

Die Widderhornkrone besitzt eine eigene Aura, die sich keiner bekannten Wesenheit zuordnen läßt und weder wirklich als gut noch als böse eingeordnet werden kann. Tatsächlich ist Nauntelrir einfach als Nauntelrir zu erkennen – eine eigenständige Entität.

Geschichte

Öffentlich

Nahezu unbekannt. Bisweilen wird die goldene Widderhornkrone unter dem Namen Grimmstirn in Märchen erwähnt, in denen es in erster Linie um Lehren in Eitelkeit geht. Zugeschriebene Fähigkeiten sind die eines flüsternden Ratgebers ebenso wie die des Bösen Blicks, der Pflanzen verdorren und Blut in den Adern stocken läßt.

Sehr gut sortierte Bibliotheken

Die Widderhornkrone wird als Höllenartefakt beschrieben, ohne dass es genauere Aussagen über den Schöpfer gäbe. Die zugeschriebenen Fähigkeiten entsprechen zumeist denen der Märchen, zuweilen erweitert um eine unspezifizierte Aussage, dass Feenpfade geöffnet werden könnten. Hier läßt sich unter Umständen auch die Beobachtung wiederfinden, dass die Krone keine astrale Signatur besitzt.

Ubirath

Nauntelrir wurde durch den Höllenschmied Khalizius aus dem Bruchstück eines Seraphen geschaffen, um den dämonischen Horden eine Möglichkeit zu bieten unbemerkt und unbehelligt zwischen den Welten wandern zu können und besitzt damit die Funktion eines echten Portalöffners in fremde Welten.

In diesem Sinne wurde das Artefakt auch erprobt, als Cobija, damals noch in den Diensten des Lichtes die Pforten des Übergangs bewachend, zufällig darauf stieß. Es gelang ihm das Stück zu erbeuten, Ubirath selbst entschied indes, dass die Krone nicht vernichtet, sondern nur verborgen werden sollte. Unter Skara Brae wurde das Versteck angelegt und durch einen Teil der Prophezeiung des Weltenwandels ergänzt:

Wenn Die Nacht Am Tage Hereinbricht,
Wenn Die Felsen Sich Erheben,
Wenn Die Hüter Des Fluches Zum Fluch Werden,
Wenn Der Gesang Der Äonen Die Wirklichkeit Durchtreibt,
Wenn Der Quell Der Seelen In Tiefste Dunkelheit Fällt.

Dann Wird Die Maske Des Verderbers Offenbar,
Dann Versagen Mut Und Kraft Vor Den Worten Des Falschen Spiegels,
Dann Werden Aus Kraft Geschriebene Worte Zum Himmel Steigen
Und Der Nabel Der Welt Findet Einen Neuen Ort.

Dort blieb Nauntelrir lange Jahre verborgen. Cobija selbst, der von seinen Pflichten schliesslich überwältigt wurde und ins Dunkel fiel, sammelte eine halbe Ewigkeit lang die Essenz seiner lichten Geschwister um das Siegel vorübergehend zu öffnen und die Krone an sich nehmen – unbemerkt vom Wächter des Neunten Tores, der seinen Platz im Spiegelraum eingenommen hatte.

Fähigkeiten

Nauntelrir ist in der Lage Portale zwischen den Welten zu öffnen und zwar an der Aufmerksamkeit der dafür bestellten Wächter vorbei.

Darüber hinaus ermöglicht die Krone durch alle Formen von Materie hindurchzublicken und verleiht jedem Träger die Fähigkeit die astrale Wirklichkeit wahrzunehmen, selbst die Ebene der Toten kann auf diese Weise durchblickt werden.

Diese Fähigkeiten haben jedoch ihren Preis: Nauntelrir ist selbst eine sich völlig bewußte Entität und kann, einmal aufgesetzt, erst nach 24 Stunden wieder abgenommen werden. Während dieser Zeit weidet die Krone sich am Karma des Trägers, Sterbliche werden zudem erschöpft, wie nach schwerem Blutverlust. Es ist durchaus denkbar, dass die Nutzung der Widderhörner durch Auszehrung zum Tode führt oder zumindest bleibende Schäden hinterläßt.

Einen Preis kündet Nauntelrir sogar selbst an: Der Träger mag bestimmen wohin die Weltentore sich öffnen, aber irgendwann wird die Krone etwas.. oder Jemanden .. entrücken, der dem Träger lieb und wertvoll ist.

Veröffentlicht in Artefakt, Rollenspiel | Verschlagwortet mit : , , , , | Kommentar schreiben »