Java Generics
Venkat Subramaniam macht sich Gedanken, ob die in Java 5 eingeführten Generics halten, was sie versprechen.
Posted at 02:27nachm. Juni 12, 2005 by cetixx in Computers | Kommentare [0]
Java Open Source Debatte
Seit dem die Apache Foundation bekannt gegeben hat, das sie mit dem
Projekt Harmony eine eigene Open Source Java J2SE Implementierung bauen
will, gab's viel Diskussion. Dieser Artikel versucht herauszufinden, was daraus alles entstehen könnte - oder nicht.
Posted at 08:01nachm. Juni 10, 2005 by cetixx in Computers | Kommentare [0]
Oracle Block Corruption
Korrupte Blöcke in einer (Oracle) Datenbank sind etwas ziemlich
Unangenehmes. Vorallem wenn alles in NOLOGGING Modus läuft, also keine
Archivlogs geschrieben werden und ein Offline-Backup (Cold-Backup)
schon länger zurückliegt, da der Betriebsablauf nur kurze und seltene Downtimes für ein
Backup vorsieht. Ich habe das bis jetzt zweimal erlebt und die Ursache
dafür war immer ein Hardware-Defekt. Beim ersten Mal war es so, dass
die Verbindung vom Rechner zum Storage des öfteren einfach weg war. Das
hat wohl mit der der Zeit dazu geführt, dass immer mehr Blöcke kaputt
gingen, da das Storage mitten unter einem Schreibvorgang in einen Block
weg war. Problem ist blos, das die Datenbank sich anschließend zwar
wieder starten läßt, aber das Ganze solange niemand merkt, bis
tatsächlich mal dann eine Query über so einen kaputten Block
drübermaschiert. Beim zweiten Vorfall war die Firmware des Controllers
für das SUN 3510 Storage buggy. Der Controller hat nämlich schlicht und
ergreifend nicht gemerkt, das eine Platte einen fehlerhaften Block
gemeldet hat und hat diese Platte somit auch nicht aus dem RAID 5
Verbund genommen. Wie das allerdings alles so laufen konnte, ist nicht
mal SUN ganz klar.
Nun ja... Es empfiehlt sich deshalb regelmäßig einen Verify mit Hilfe des Oracle-Tools dbv über die Datenfiles zu machen (und natürlich ein Backup ;-). Da die Files READ-ONLY geöffnet werden,
kann man das entweder direkt auf den Live-Datenfiles tun oder besser
man checkt die Datenfiles nach dem Backup. dbv
erkennt zwar auch nicht alles, aber grobe Fehler in den Datenstrukturen
werden auf jeden Fall sichtbar. Das sollte aber zu Traffic armer Zeit
passieren, da dbv schon Einiges an I/O benötigt.
Wie so ein Fehler sich bemerkbar macht, sieht man z.B. hier:
SQL> CREATE TABLE test AS SELECT * FROM TESTTABLE;
*
FEHLER in Zeile 1:
ORA-12801: Fehler in parallelem Abfrage-Server P015 angezeigt
ORA-01578: ORACLE-Datenblock beschädigt (Datei Nr. 56, Block Nr. 357316)
ORA-01110: Datendatei 56: '/u01/data/DATENBANK/data/datenfile.dbf'
Nun in diesem Falle sollte man zuerst Oracle Metalink Note 28814.1
zu Rate ziehen und außerdem alle relevaten Logs auf der Maschine
checken, den die Wahrscheinlichkeit eines Hardwaredefekts ist recht
groß. Es kommt nun drauf an, welches Segment es erwischt hat. Wenn z.B.
ein Objekt im Data Dictionary betroffen ist, wird man meistens um ein
DB-Recovery nicht drumrumkommen. Ist ein Index betroffen, kann man oft
Glück haben und ein Index Rebuild erledigt die Sache gleich wieder. Ist
eine Tabelle hin, kann man zwar die "guten" Daten noch rausholen, aber
ohne Backup gehen dabei fast immer Daten verloren. Ist die Tabelle
partitioniert, kann man einen sog. Partitionstausch (ALTER TABLE ...
EXCHANGE PARTITION ...) machen. D.h. man erstellt eine neue Tabelle und
tauscht die defekte Partition durch diese neue Tabelle aus. Damit ist
die Tabelle dann gewissermaßen für die Anwendungen wieder "ganz". Diese
Tabelle sollte möglichst die gleichen Storagedaten der Partition haben
und natürlich
auch die gleichen Spalten. Das könnte man z.B. wie folgt machen:
CREATE TABLE test_save TABLESPACE tablespace STORAGE ( ... ) AS
SELECT * FROM test WHERE rownum=1;
Sollte das schon nicht mehr hinhauen, kann man das DBMS_REPAIR-Paket verwenden:
EXEC DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('SCHEMANAME','test');
"test" ist hier die Tabelle, die die korrupten Blöcke enthält. Damit sollte dann der CREATE TABLE ... AS SELECT ...
jetzt funken. Damit bekommt man dann z.B. auch die "guten" Daten in die neue
Tabelle, wenn man die WHERE-Klausel wegläßt. Man sollte allerdings die korrupte Tabelle nicht einfach
dropen, sondern am Besten mit ALTER TABLE test RENAME TO test_corrupted;
umbenennen. Dann hat man die Daten noch, um sich die Daten noch genauer
anschauen zu können. Man kann dann ja versuchen, die alte Tabelle neu
anzulegen und die Daten rekonstruieren. Eventl. vorhandene Constraints
wird man ausschalten müssen.
Die interessanten Dokumente dazu findet man im Oracle Metalink, wenn man
nach der Note 28814.1 sucht. Die Not 33405.1 gibt Auskunft über die
Vorgehensweise, wenn man DBMS_REPAIR.SKIP_CORRUPT_BLOCKS
verwenden möchte. Wie man an die Daten mit Hilfe der ROWID oder von
Index-Scans wieder ran kommt, beschreibt Note 61685.1 (für Oracle 8i+).
Nun... Die Moral von der Geschicht, betriebe keine Oracle-Datenbank
ohne vernünftiges Backup nicht ;-) Wenn man noch dazu keine Archivlogs
hat, ist man doppelt aufgeschmissen. Ansonsten könnte man die Datenbank
sogar aus einem uralt Cold-Backup mit den Archivlogs wieder hinbiegen.
Aber manchmal hat man eben auch das nicht. Dann bleibt nur das letzte
Coldbackup und dann sind die Daten vom diesem Backupzeitpunkt bis zum
Schluß u.U. weg. Und wenn man auch das nicht hat... Ja dann... Dann muß man damit rechnen, das Daten einfach futsch sind. DAS ist dann richtig geil ;-)
Posted at 08:45nachm. Juni 09, 2005 by cetixx in Computers | Kommentare [0]
Fedora Directory Server
Nachdem Red Hat den Netscape Directory Server gekauft hat, ist er nun hier als Open Source Projekt zu finden.
Posted at 11:42nachm. Juni 06, 2005 by cetixx in Computers | Kommentare [0]
Wie man seine eigene Linux-Distribution baut...
... beschreibt dieser Artikel.
Posted at 11:39nachm. Juni 06, 2005 by cetixx in Computers | Kommentare [0]
Aqua Icons mit Java 2D
Wie man die Dinger erzeugt, beschreibt dieser Artikel.
Posted at 10:18nachm. Juni 05, 2005 by cetixx in Computers | Kommentare [0]
Pfeil-Icons mit Java 2D
Wie man diese Icon's erzeugt, beschreibt dieser Artikel.
Posted at 10:17nachm. Juni 05, 2005 by cetixx in Computers | Kommentare [0]
Kalender Utilities in JDesktop Native Components
Eine kleine Einführung.
Posted at 09:52nachm. Juni 05, 2005 by cetixx in Computers | Kommentare [0]
Einführung in Java Advanced Imaging
Eine kleine Einführung in JAI.
Posted at 09:48nachm. Juni 05, 2005 by cetixx in Computers | Kommentare [0]
Create test cases for Web applications
Wie man Web-Applikationen mit jWebUnit erstellt, erklärt dieser Artikel.
Posted at 01:01vorm. Juni 05, 2005 by cetixx in Computers | Kommentare [0]
Geld verdienen mit Open Source?
Dieser Artikel versucht einige Antworten zu geben auf diese Fragen.
Posted at 01:02vorm. Juni 04, 2005 by cetixx in Computers | Kommentare [0]
RSYNC über NFS
Hmmm... Manchmal kann einen das rsync
schon in den Wahnsinn treiben. Wenn ich Files per rsync über NFS von
einer Solaris-Kiste auf eine Linux-Kiste mit Debian Sarge (2.4er
Kernel) kopiere, klappt das ohne Probleme. Wenn ich dagegen eine
ähnlich große Datenmenge mit Linux Red Hat Enterprise 3 mit 2.4er
Kernel auf die gleiche Debian-Kiste kopiere, meint er irgendwann:
rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown":
Broken pipe
rsync error: error in rsync protocol data stream (code 12) at
io.c(515)
rsync: writefd_unbuffered failed to write 69 bytes: phase "unknown":
Broken
pipe
rsync error: error in rsync protocol data stream (code 12) at io.c(515)
Alle Mount-Points sind mit den Optionen rsize=32768,wsize=32768,timeo=480,intr,rw,soft
gemountet. Die Buffergrößen sind für diese Art von Anwendung ok. Große
Preisfrage: Wieso ist das nun so? Das rsync selbst, wird jeweils mit
den Optionen -v --archive --delete
gestartet. Hmmm... Solaris auf Linux funkt, Linux auf Linux nicht. Da
liegt die Vermutung nahe, das das rsync das bei Red Hat Enterprise 3
dabei ist, nicht koscher ist. Wir probieren es jetzt mal mit der Option
--whole-file beim rsync. Stay tuned...
Mehr zu dem Thema hier.
Update:
Ich glaube, ich habe jetzt eine Lösung des Problemes. Der Linux-Server
scheint sich manchmal ziemlich mit "sich selber" zu beschäftigen, in
diesem Falle viele I/O's zu machen. Dadurch läuft der NFS-Mount in
einen Timeout irgendwann. Wenn man das soft in den NFS-Optionen durch hard ersetzt, scheint alles zu klappen. hard
ist normalerweise default. Mit der Option soft konnte ich bisher
meistens mehr Probleme lösen, als erzeugen, aber in diesem Fall scheint
das eher das Gegenteil bewirkt zu haben. Der NFS-Client muß in diesem
Fall wohl hardneckig bleiben ;-)
Posted at 09:45nachm. Juni 03, 2005 by cetixx in Computers | Kommentare [0]
Performance Tools for Optimizing Linux
Ein Kapitel aus dem Buch Optimizing Linux Performance: A Hands-on Guide to Linux Performance Tools könnt ihr hier lesen.
Posted at 09:39nachm. Juni 02, 2005 by cetixx in Computers | Kommentare [0]
Oracle Indizies
So... Jetzt bin ich endgültig verwirrt. Ist es denn wirklich nur in
Ausnahmen nötig einen Index zu rebuilden, wie Tom Kyte und Richard
Foote meinen? Oder es doch so machen, wie Don Burleson meint und
Indizies regelmäßig neu aufzubauen?
Pro:
Busting the Oracle Myth Busters
Contra:
Ask Tom: Rebuilding Indexes
Oracle B-Tree Index Internals: Rebuilding The Truth
Posted at 09:14nachm. Juni 02, 2005 by cetixx in Computers | Kommentare [0]
Java Performance
In The Java performance debate packt Andy Roberts dieses heiße Eisen an und räumt mit ein paar Mythen auf, die immer noch einige Leute mit sich herumschleppen.
Posted at 09:12nachm. Juni 02, 2005 by cetixx in Computers | Kommentare [0]