Während der Aufräumarbeiten, die der Sturm Kyrill in unmittelbarer Nähe von Löttmaringhausen hinterlassen hat, kam es heute wohl zu einer Entzündung des zum Abtransport vorbereiteten Holzes. Es waren in jedem Falle wieder viele rote Partymobile im Einsatz. Wenn man sich die Rauchentwicklung von der Ferne aus ansieht, dann machte das allerdings auch Sinn.
Fotos gibts nach dem Click bei Flickr
Oha…
Nicht alles wird gut wenn man von einer 10.1 auf 10.2 updaten will. So steigt die Ora-DB bei der Einstellung “CURSOR_SHARING=FORCE” in manchen Fällen nach einem SQL-Statement mit ORA-01008 (not all variables bound) aus, obwohl alle Variablen brav gebunden sind.
Workaround: CURSOR_SHARING auf “EXACT” stellen, sofern möglich. Oder halt auf ein Fixing des Bugs mit der Nummer #5863277 warten (siehe Metalink)
PS: Der Fehler tritt nur mit dem neuesten Patchset, also der 10.2.0.3 auf…
Nachtrag: Es gibt einen Patch bei Oracle im Metalink – Knappe 80kB gross patcht das Teil den Ora-Kernel und danach sollte es wieder tun… Der Fehler trat übrigens nur bei Zugriff via OCI o.ä. auf. Böse wenn man mit DBD::Oracle unter Perl arbeitet.
Der “Winter”, oder was auch immer das sein mag, hat nun doch noch ein, wahrscheinlich kurzes, Gastspiel im Sauerland eingelegt. So sah es heute morgen hier vor der Türe aus:
Unter meinem Schreibtisch steht, ehm stand, eine APC 700er USV. Vorgestern und gestern roch es irgendwie verdächtig nach etwas verbranntem. Allerdings liess sich die Quelle des Übels nicht genau identifizieren. Gestern Abend dann die Erleuchtung. Als ich die USV angefasst hatte, hätte ich mir fast die Finger verbrannt. Also raus damit. Kann es sein das es bei den älteren Modellen (das war eine 1994er) keine Notabschaltung o.ä. gibt ?
Über Oracle und Blobs könnte man, glaube ich, Bücher schreiben.
Wieder mal etwas interessantes:
Versucht man von einem Schema, nennen wir es A, Daten in eine Blob-Tabelle, sagen wir B.B_TABLE mit Perls DBD/DBI zu “inserten”, quittiert Oracle dies mit einem netten ORA-010321 (insufficient privileges).
Kurz nachgesehen: Hmm, A verfügt über INSERT-Grants für B.B_TABLE. Wer jetzt anfängt den Fehler an anderer Stelle zu suchen, hat schon verloren.
User A benötigt ZWINGEND das UPDATE-Recht auf B.B_BLOB Table. Dann klappts auch mit dem Inserten…
Der Tip kommt frisch aus dem fscklog:
Wer seinem Mail-Client unter OSX Beine machen will, sollte die darunterliegende DB mal reorganisieren.
Wie das geht ?
So:
1. Mail.app beenden (und falls nicht sowieso vorhanden ein Backup anlegen)
2. Terminal öffnen
3. >> sqlite3 ~/Library/Mail/Envelope\ Index vacuum << aufrufen
4. Glücklich sein.
Laut heise haben böse Menschen die Version 2.1.1. von WordPress infiltriert. Daher fix auf die 2.1.2 updaten…
Den vollen heise Artikel gibt hier
