[ORACLE] Problem mit Nebenläufigkeit von Up dates
Gerd Nachtsheim
wie kann man dann einer 9.0.1.1.1 beibringen, folgendes Skript so zu
serialisieren, daß es auch bei konkurrierenden Zugriffen sauber durchläuft.
Ich habe hier ein Javaprogramm, was ein paar Threads losschickt, die so
eine Art Hotspot emulieren (alle versuchen den gleichen Record zu
aktualisieren und ihn danach zu lesen)
Master:
DROP TABLE TESTSEQUENCER
CREATE TABLE TESTSEQUENCER( MAXID INT ,
TABLENAME VARCHAR(25) PRIMARY KEY)
INSERT INTO TESTSEQUENCER(MAXID,TABLENAME) VALUES(1,'Hasi')
und dann jagen sich die Threads mit (z.T. symbolisch ausgedrückt)
SET ISOLATION_LEVEL SERIALIZABLE //müßte auch mit READ_COMMITTED ok sein
START TRANSACTION
UPDATE TESTSEQUENCER
SET MAXID = MAXID + 1
WHERE TABLENAME = 'Hasi'
SELECT MAXID
FROM TESTSEQUENCER
WHERE TABLENAME = 'Hasi'
COMMIT
Im Falle einer SQLException erfolgt in jedem Fall ein ROLLBACK
Im Gegensatz zu anderen Datenbanken (MSSQL,Caché,MySQL) mag Oracle
diesen Ablauf überhaupt nicht, es wird beim UPDATE Versuch offenbar
gleich eng (2 threads):
ORA-08177: Zugriff für diese Transaktion kann nicht serialisiert werden
Bleibt mir hier nichts anderes übrig, als den UPDATE - Versuch so lange
zu wiederholen, bis er erfolgreich war? Oder habe ich irgendwas an
Oracle grundsätzlich nicht verstanden, was es von anderen RDBMS
unterscheidet?
Hier geht es wohlgemerkt nicht um den Versuch, den Oracle Sequencer
überflüssig zu machen sondern obige Transaktion mit konkurrierenden
Zugriffen durchzuführen.
Für ein paar Tips an den Oracle - Neuling wäre ich sehr dankbar
Gerd
--
Gerd Nachtsheim mailto:ge...@users.sourceforge.net ICQ:#13126958
Ulrik Hoffmann
"Gerd Nachtsheim" <ge...@users.sourceforge.net> schrieb im Newsbeitrag
>
[ORA-08177: Zugriff für diese Transaktion kann nicht serialisiert werden]
>
> SET ISOLATION_LEVEL SERIALIZABLE //müßte auch mit READ_COMMITTED ok sein
>
Moin Gerd,
hast Dus mal mit READ_COMMITED probiert?
Gruss
Ulrik
Gerd Nachtsheim
> "Gerd Nachtsheim" <ge...@users.sourceforge.net> schrieb im Newsbeitrag >
> hast Dus mal mit READ_COMMITED probiert?
Danke für den Tip - und es funktioniert sogar, aber *schneckenlahm*,
jetzt müßte ich noch rausfinden, woran das liegt.
Witzigerweise was der ursprüngliche IsolationLevel READ_COMMITTED, dann
wurde er aber hochgestellt bzw. ich hab versucht eine Extra-Oracle
Lösung zu basteln und dann nicht mehr zurückgesetzt.
Momentan braucht Oracle für das Ziehen einer Nummer vier Sekunden,
während die anderen Kandidaten im Bereich von < 100 ms sind.
Im Lockmonitor sieht man (wenn ich das richtig sehe), daß es zu
"Wartezeiten" kommt.
Vielleicht gibt es dafür ja eine Erklärung.
Ulrik Hoffmann
>
> > hast Dus mal mit READ_COMMITED probiert?
>
> Danke für den Tip - und es funktioniert sogar, aber *schneckenlahm*,
> jetzt müßte ich noch rausfinden, woran das liegt.
>
Ist ein Index auf "TABLENAME"? Wieviele Datensätze updatest/insertest Du?
Um wieviele Datensätze geht es? Was sagen die Redo-Logs? Hast Du im
Alert-File in (/$ORACLE_HOME/admin/ORCL/bdump) "checkpoint not complete"s ?
> Witzigerweise was der ursprüngliche IsolationLevel READ_COMMITTED, dann
> wurde er aber hochgestellt bzw. ich hab versucht eine Extra-Oracle
> Lösung zu basteln und dann nicht mehr zurückgesetzt.
Serializable macht bei Oracle häufig Ärger, ich kann mich aber auch nicht
erinnern, den ISOLATION_LEVEL jemals wirklich benötigt zu haben.
>
> Momentan braucht Oracle für das Ziehen einer Nummer vier Sekunden,
> während die anderen Kandidaten im Bereich von < 100 ms sind.
>
läßt sich bestimmt tunen!
Gruß
Ulrik
Gerd Nachtsheim
> Ist ein Index auf "TABLENAME"? Wieviele Datensätze updatest/insertest Du?
> Um wieviele Datensätze geht es? Was sagen die Redo-Logs? Hast Du im
> Alert-File in (/$ORACLE_HOME/admin/ORCL/bdump) "checkpoint not complete"s ?
Es ist genau ein Datensatz, in admin/<service>/bdump/<service>ALRT.LOG
finde ich keinen Hinweis auf Checkpoints, auf Error oder Warning.
die Redo-logs sind 3 * 102MB (huch!), ist das eine Standardgröße?
> Serializable macht bei Oracle häufig Ärger, ich kann mich aber auch nicht
> erinnern, den ISOLATION_LEVEL jemals wirklich benötigt zu haben.
Bei dem gezeigten Verhalten bin ich mir nicht sicher, ob die
Implementierung so toll ist...
>>Momentan braucht Oracle für das Ziehen einer Nummer vier Sekunden,
>>während die anderen Kandidaten im Bereich von < 100 ms sind.
>>
>
>
> läßt sich bestimmt tunen!
Da muß es Wege geben, wie sonst würde man ein System zum Fliegen
bringen, daß eine solche Anforderung hat (permanentes concurrent Update
auf einen Satz)?
Für jede Anregung dankbar
Klaus Zeuch
>
> >>Momentan braucht Oracle für das Ziehen einer Nummer vier Sekunden,
> >>während die anderen Kandidaten im Bereich von < 100 ms sind.
> >>
> >
> >
> > läßt sich bestimmt tunen!
>
> Da muß es Wege geben, wie sonst würde man ein System zum Fliegen
> bringen, daß eine solche Anforderung hat (permanentes concurrent Update
> auf einen Satz)?
>
> Für jede Anregung dankbar
Erster Versuch: Tabelle mit
CREATE TABLE TESTSEQUENCER( MAXID INT ,
TABLENAME VARCHAR(25) PRIMARY KEY) initrans=20
maxtrans=255
anlegen.
Klaus
Gerd Nachtsheim
>
> Erster Versuch: Tabelle mit
>
> CREATE TABLE TESTSEQUENCER( MAXID INT ,
> TABLENAME VARCHAR(25) PRIMARY KEY) initrans=20
> maxtrans=255
Danke für den Tip, wenn man die Gleichheitszeichen weglässt, dann
compiliert es auch :-)
Jetzt sind wir runter auf 2.1 sec/update
Schon besser, aber noch lange nicht gut...
Ulrik Hoffmann
>
>
> Schon besser, aber noch lange nicht gut...
Klingt für mich nach irgendwas anderem. Normalerweise sollte das genauso
schnell wie mit anderen Datenbanken gehen.
Baust Du vielleicht jedesmal ne Connection auf? Wenn ja wie (THIN/OCI)? Wie
sieht Deine TNSNAMES.ora aus (bei OCI)? Wie sieht die Listener.ora aus? Wenn
Du Hostnames verwendest änder die mal durch die IP und/oder trag die Rechner
gegenseitig in die hosts Tabelle ein, damit sie sich in jdem Fall "kennen".
Poste auch vielleicht nochmal zur Sicherheit Deine
init<INSTANCE>.ora -Datei. Kannst Du mit einem Tool (Oracle Top-Session
Monitor, TOAD) mal checken, ob die Threads tatsächlich aufeinander warten?
Viele Grüße
Ulrik
Gerd Nachtsheim
> "Gerd Nachtsheim" <ge...@users.sourceforge.net> schrieb im Newsbeitrag >
>
>>Jetzt sind wir runter auf 2.1 sec/update
>>
>>
>>Schon besser, aber noch lange nicht gut...
>
>
> Klingt für mich nach irgendwas anderem. Normalerweise sollte das genauso
> schnell wie mit anderen Datenbanken gehen.
ich wäre auch arg enttäuscht, wenn's so wäre.
>
> Baust Du vielleicht jedesmal ne Connection auf? Wenn ja wie (THIN/OCI)? Wie
> sieht Deine TNSNAMES.ora aus (bei OCI)? Wie sieht die Listener.ora aus? Wenn
> Du Hostnames verwendest änder die mal durch die IP und/oder trag die Rechner
> gegenseitig in die hosts Tabelle ein, damit sie sich in jdem Fall "kennen".
Das Programm läuft genau wie es ist gegen zwei andere Datenbanken auf
der gleichen Maschine, insofern schliesse ich irgendwelche Netzprobleme
aus. DNS ist auch OK. Ich benutze den 'pure Java' JDBC Treiber, kein OCI.
Ora et labora...:
# TNSNAMES.ORA Network Configuration File:
C:\oracle\ora90\NETWORK\ADMIN\tnsnames.ora
# Generated by Oracle configuration tools.
SATURN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = saturn)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = SHARED)
(SERVICE_NAME = saturn.oracle)
)
)
INST1_HTTP =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = saturn)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = SHARED)
(SERVICE_NAME = MODOSE)
(PRESENTATION = http://HRService)
)
)
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
>
> Poste auch vielleicht nochmal zur Sicherheit Deine
> init<INSTANCE>.ora -Datei. Kannst Du mit einem Tool (Oracle Top-Session
> Monitor, TOAD) mal checken, ob die Threads tatsächlich aufeinander warten?
In meiner laienhaften Interpretation des LockMonitors in dem großen Tool
(Enterprise...) würde ich sagen, die warten aufeinander.
Wo finde ich denn die richtigen ora's für init<Instance?>.ora? Ich habe
eines gefunden, da steht wieder nur ein Verweis auf ein anderes File drin.
Bin leider momentan etwas knapp in der Zeit...
Erstmal Danke fürs Helfen
Ulrik Hoffmann
"Gerd Nachtsheim" <ge...@users.sourceforge.net> schrieb im Newsbeitrag
> Wo finde ich denn die richtigen ora's für init<Instance?>.ora? Ich habe
> eines gefunden, da steht wieder nur ein Verweis auf ein anderes File drin.
>
da wo Du auch BDUMP gefunden hast, ist ein Verzeichnis pfile, da steht die
Datei drin.
Nochmal zu den Connects, connectest Du Dich jedesmal neu? Kannst Du checken,
wie die connection-time ist?
Gruss
Ulrik
Klaus Zeuch
"Ulrik Hoffmann" <ulrik...@hoffmann-kiel.de> schrieb im Newsbeitrag
news:ac00vq$lnqra$1...@ID-13717.news.dfncis.de...
>
> "Gerd Nachtsheim" <ge...@users.sourceforge.net> schrieb im Newsbeitrag
>
> > Wo finde ich denn die richtigen ora's für init<Instance?>.ora? Ich habe
> > eines gefunden, da steht wieder nur ein Verweis auf ein anderes File
drin.
> >
>
> da wo Du auch BDUMP gefunden hast, ist ein Verzeichnis pfile, da steht die
> Datei drin.
Hinweis: mit 9i verwendet man meistens ein spfile (binäre Datei, wird nur
von Oracle aktualisiert, wenn Änderungen mit alter system .... scope=both
bzw. scope=spfile erfolgen; manuelles Nachziehen dieser Änderungen in
init<sid>.ora entfällt damit) anstelle des pfile init<sid>.ora .
Deshalb prüfen, ob
select * from V$SPPARAMETER;
etwas zurückliefert (als user mit DBA-Rolle). Wenn ja, dann wird ein spfile
verwendet. Ein pfile kann dann erzeugt werden mit:
create pfile 'c:\.....\irgendein.name' from spfile;
Klaus
Ulrik Hoffmann
"Klaus Zeuch" <KZe...@hotmail.com> schrieb im Newsbeitrag
> Hinweis: mit 9i verwendet man meistens ein spfile (binäre Datei, wird nur
> von Oracle aktualisiert, wenn Änderungen mit alter system ....
scope=both
> bzw. scope=spfile erfolgen; manuelles Nachziehen dieser Änderungen in
> init<sid>.ora entfällt damit) anstelle des pfile init<sid>.ora .
>
Wußt ich noch nicht (stehe noch bei 8.1.7), klingt plausibel. Benutzt
eigentlich jemand schon 9i "so richtig" produktiv, mit großen Datenmengen
und so? Ich habs deswegen noch nicht installiert, weil die ersten Releases
bei Oracle ja gerne mal Bugs haben...
Gruß
Ulrik
Gerd Nachtsheim
> "Gerd Nachtsheim" <ge...@users.sourceforge.net> schrieb im Newsbeitrag
>
>
>>Wo finde ich denn die richtigen ora's für init<Instance?>.ora? Ich habe
>>eines gefunden, da steht wieder nur ein Verweis auf ein anderes File drin.
>>
>
>
> da wo Du auch BDUMP gefunden hast, ist ein Verzeichnis pfile, da steht die
> Datei drin.
Ich schick Sie Dir per EMail, die NG wollte ich damit nicht beglücken, OK?
>
> Nochmal zu den Connects, connectest Du Dich jedesmal neu? Kannst Du checken,
> wie die connection-time ist?
Jeder Thread connected sich einmal bevor er n Iterationen ausführt. Die
Connection time habe ich noch nicht gemessen, das ist aber kein Problem.
Gerd Nachtsheim
> Deshalb prüfen, ob
>
> select * from V$SPPARAMETER;
250 rows
Klaus Zeuch
> Klaus Zeuch wrote:
>
> > Deshalb prüfen, ob
> >
> > select * from V$SPPARAMETER;
>
> 250 rows
Dann verwendet die Datenbank ein spfile.
Verhalten von 9i beim STARTUP (Rangfolge):
a) Verwenden des spfiles spfile<sid>.ora
b) Verwenden des default spfile
c) Verwenden des pfile init<sid>.ora
d) Verwenden des default pfile
Für Analysezwecke ist ein dump des spfile (binäre Datei) erforderlich:
Gerd Nachtsheim
> Für Analysezwecke ist ein dump des spfile (binäre Datei) erforderlich:
>
> create pfile 'c:\.....\irgendein.name' from spfile;
create pfile 'c:\temp\irgendein.name' from spfile;
ergibt folgende Fehlermeldung:
create pfile 'c:\temp\irgendein.name' from spfile
*
FEHLER in Zeile 1:
ORA-00923: Schlüsselwort FROM nicht an erwarteter Stelle gefunden
Gar nicht so einfach, das Orakel :-}
Klaus Zeuch
> Klaus Zeuch wrote:
>
> > Für Analysezwecke ist ein dump des spfile (binäre Datei) erforderlich:
> >
> > create pfile 'c:\.....\irgendein.name' from spfile;
>
> create pfile 'c:\temp\irgendein.name' from spfile;
>
> ergibt folgende Fehlermeldung:
>
> create pfile 'c:\temp\irgendein.name' from spfile
> *
> FEHLER in Zeile 1:
> ORA-00923: Schlüsselwort FROM nicht an erwarteter Stelle gefunden
>
>
> Gar nicht so einfach, das Orakel :-}
Ja, ja, die Syntax - so ohne 9i und nur aus dem Gedächtnis klappt's nicht
immer:
Entweder:
create pfile from spfile;
oder
create pfile 'c:\........' from spfile 'c:\............';
Für andere Alzheimer-Aspiranten:
http://otn.oracle.com/docs/products/oracle9i/doc_library/901_doc/server.901/
a90117/create.htm#1012774
Klaus
Stefan Moeding
Gerd Nachtsheim writes:
> Da muß es Wege geben, wie sonst würde man ein System zum Fliegen
> bringen, daß eine solche Anforderung hat (permanentes concurrent Update
> auf einen Satz)?
Na ja. Würde mich nicht wundern, wenn andere Datenbanken durch
dirty-read hier Vorteile haben. Es dürfte aber schneller sein, wenn du
das Ganze nur mit einem Statement machst:
UPDATE TESTSEQUENCER
SET MAXID = MAXID + 1
WHERE TABLENAME = 'Hasi'
RETURNING maxid INTO :variable;
COMMIT;
Außerdem würde ich die Tabelle als IOT anlegen. Bei einer normalen
Tabelle mit Primary Key müssen zwei Stellen aktualisiert werden. Beim
IOT hast du Tabelle und Index in einer Struktur.
--
Stefan
Stefan Moeding
Ulrik Hoffmann writes:
> Benutzt eigentlich jemand schon 9i "so richtig" produktiv, mit großen
> Datenmengen und so? Ich habs deswegen noch nicht installiert, weil die
> ersten Releases bei Oracle ja gerne mal Bugs haben...
Wir haben gerade mit Tests angefangen und deine Bemerkung über die Bugs
bestätigt sich hier auch. Insgesamt haben wir den Eindruck, daß 9i
langsamer als 8i ist (auf identischer Hardware). Die 9.0.1.0 hatte
katastrophal wiele Wartezustände, dir 9.0.1.3 ist besser. Die Resumable
Transaktions gehen auf RAC eigentlich gar nicht; die Session ist
mitnichten blockiert und produzierte im Test so 60 MB Rollback pro
Minute. Bei der Replikation werden plötzlich pro Spalte und Zeile 4
Byte mehr übertragen. Wir haben Tabellen mit etwa 50 Spalten und
etlichen Millionen Rows. Damit dauert ein complete Refresh oder Anlegen
des Snapshots unter 9i jetzt dreimal so lange wie unter 8i...
Die normalen Sachen gehen so, aber wenn ich keine 9i Features brauche,
dann kann ich ja gleich auf 8i bleiben.
--
Stefan
Gerd Nachtsheim
> Hi!
>
> Gerd Nachtsheim writes:
>
>
>>Da muß es Wege geben, wie sonst würde man ein System zum Fliegen
>>bringen, daß eine solche Anforderung hat (permanentes concurrent Update
>>auf einen Satz)?
>
>
> Na ja. Würde mich nicht wundern, wenn andere Datenbanken durch
> dirty-read hier Vorteile haben. Es dürfte aber schneller sein, wenn du
> das Ganze nur mit einem Statement machst:
Nein, haben sie nicht. Der Transaction Isolation Level ist
READ_COMMITTED und andere haben damit (fast) kein Problem. Nur Oracle
schafft das offenbar nicht und es kommt zu 'Wartezeiten'. Netürlich
steckt darin irgendwo eine 'kleine' Lücke zwischen Lesen des Primary Key
und Ermitteln der eigentlichen (internen) RowID. Siehe weiter unten.
>
> UPDATE TESTSEQUENCER
> SET MAXID = MAXID + 1
> WHERE TABLENAME = 'Hasi'
> RETURNING maxid INTO :variable;
>
> COMMIT;
Das wäre dann eine ORACLE only Lösung, die sonst nirgends funktioniert.
Der Grundgedanke war mal ein Uralt-Sequencer (kein Mensch würde das
heute so lösen) aber das prinzipielle Problem bleibt bestehen. Wenn ein
UPDATE von einem SELECT gefolgt wird, entstehen offenbar Konflikte.
Dieses Szenario halte ich nicht für ungewöhnlich.
>
> Außerdem würde ich die Tabelle als IOT anlegen. Bei einer normalen
> Tabelle mit Primary Key müssen zwei Stellen aktualisiert werden. Beim
> IOT hast du Tabelle und Index in einer Struktur.
Ich kenne den Begriff IOT zwar nicht, nehme aber an es handelt sich um
eine Tabelle mit immutual primary key, also interne ROWID = PK. Ohne die
Interna des Oracle Locking zu kennen nehme ich an, daß dies eine
potentielle Lösung des Problems ist. Das Locking dürfte sich dann nur
noch auf einen Punkt konzentrieren und einfacher zu serialisieren sein.
BTW, wo setze ich den fest, wie lange ein UPDATE auf einen LOCK wartet
bis er einen LOCKING CONFLICT oder sowas zurückmeldet?
Vielen Dank für die vielen Hinweise, allen anderslautenden Gerüchten zum
Trotze kann man in dieser NG eine Menge lernen und trifft hilfsbereite
und nette Mitmenschen, die ihre Zeit opfern.
Ulrik Hoffmann
"Gerd Nachtsheim" <ge...@users.sourceforge.net> schrieb im Newsbeitrag
Immer wenn man bei Oracle ratlos ist sollte man patchen ;-)
Kann sein, daß Du auf einen Bug läufst, habe allerdings nichts bei Metalink
gefunden, aber Stefan sprach auch davon. Also vielleicht einen Patch
besorgen. Ansonsten kann ich Dir anbieten, das Programm mal hier auf meiner
Kiste auszuführen (8.1.7).
Viele Grüße
Ulrik
Klaus Zeuch
> Stefan Moeding wrote:
> > Außerdem würde ich die Tabelle als IOT anlegen. Bei einer normalen
> > Tabelle mit Primary Key müssen zwei Stellen aktualisiert werden. Beim
> > IOT hast du Tabelle und Index in einer Struktur.
>
> Ich kenne den Begriff IOT zwar nicht, nehme aber an es handelt sich um
> eine Tabelle mit immutual primary key, also interne ROWID = PK.
IOT = index organized table: create table name (... constraint
constraint_name primary key (feld1, ....)) ORGANIZATION INDEX
Im Gegensatz zu einer normalen Tabelle, bei der die Daten "wild" gespeichert
sind, sind in IOT die Daten nach primary key sortiert in einer B-Tree
Index-Struktur gespeichert. Jeder Indexeintrag speichert außer dem
Primary-Key auch die anderen Daten der Tabelle. Im Vergleich zu einer
klassischen Struktur (Tabelle mit unsortierten Daten und der rowid als
internem Schlüssel, B-Tree Index verweist für den Indexwert auf die rowid)
sind solche Tabellen bei primary-Key-Index Zugriff deutlich schneller.
Ich weiß nicht, ob das bei deinem Problem den großartigen Durchbruch bei der
Performance bringt - da hilft nur probieren. Vielleicht mußt du wirklich auf
das Release 2 von 9i warten, das in den nächsten Tagen kommen soll.
Klaus
Stefan Moeding
Gerd Nachtsheim writes:
> Ich kenne den Begriff IOT zwar nicht, nehme aber an es handelt sich um
> eine Tabelle mit immutual primary key, also interne ROWID = PK. Ohne die
> Interna des Oracle Locking zu kennen nehme ich an, daß dies eine
> potentielle Lösung des Problems ist. Das Locking dürfte sich dann nur
> noch auf einen Punkt konzentrieren und einfacher zu serialisieren sein.
Der IOT wurde ja schon erläutert. Ich habe mal kurz getestet und er
scheint sowohl unter 8i als auch unter 9i langsamer zu sein :-(
> BTW, wo setze ich den fest, wie lange ein UPDATE auf einen LOCK wartet
> bis er einen LOCKING CONFLICT oder sowas zurückmeldet?
Gar nicht. Das UPDATE wartet solange, bis der Lock freigegeben wurde.
Es gibt allerdings ein SELECT ... FOR UPDATE, mit dem der Satz gelesen
und gleichzeitig gesperrt wird. Das hat unter 8i die Option NOWAIT, so
daß das Statement bei einem Lock sofort mit "ORA-54: Resource busy"
abbricht. Unter 9i kann man dann auch WAIT x angeben, wobei x die
maximal Wartezeit in Sekunden ist.
--
Stefan
Gerd Nachtsheim
erstmal danke an alle die mich mit Tips und Anregungen 'gefüttert'
haben, es gab eine ganze Menge davon.
Fazit: mit Oracle < 9 gibt es keine Probleme, wenn man das ganze
anpasst, also
SELECT FOR UPDATE
UPDATE
COMMIT
im Gegensatz zu
UPDATE
SELECT
COMMIT
unter anderen Datenbanken (MySQL,MS SQL, Caché).
Mit Oracle 9i in der Version zum freien Download (9.0.1.1.1) war das
ganze nicht für Geld und gute Worte zu einer vernünftigen Performance zu
bewegen, immer wieder schienen sich die Prozesse gegenseitig
auszusperren bzw. die Performance war nicht die zu erwartende. Wie mir
mehrere Leute unabhängig voneinander mitgeteilt haben, ist aber bereits
ein größeres ServicePack im Anmarsch, welches mit den bekannten
Problemen dieser Version aufräumen soll. Diese Erfahrung war wohl
'bleeding edge' :-) und sicher auch z.T. mit meinem fehlendem
Oracle-Spezialwissen zu erklären.
Besonderer Dank an Ulrik Hoffmann, der das ganze mit Oracle 8.1.7
getestet hat, wo es zu den erwartet guten Ergebnissen kam, die sich
nicht von den anderen DB unterschieden ( < 50 ms/transaction ). '
Nota Bene: Dieser Test ist nicht dazu angedacht, harte Facts zur
Performance zu liefern sondern er zeigt das Verhalten bei
Nebenläufigkeit in einem speziellen Falle.
Versionen: die MS SQL Version war SQL Server 2000 (ohne ServicePack),
MySQL 4.0.1-alpha-nt und Caché 5.0 devkit2
Noch ein paar Anmerkungen...
Testen wollte ich noch YardSQL und FirstSQL, ersteres habe ich aus
Zeitgründen noch nicht installiert und von FirstSQL habe ich bisher nur
eine File-basierte Version, die Server Version kommt wohl noch.
Beim Testen von DB2 fiel mir irgendwann auf, daß der mitgeliefert JDBC
Treiber kein Type-4 ist, fiel also auch aus dem Rennen (wer Java nutzt,
möchte nicht noch einen fetten binary client installieren). Es will mir
hier nicht ganz einleuchten, wieso IBM mit seinem überdeutlichen
Java-Bekenntnis keinen echten Type-4 JDBC Treiber mitliefert. Es wurden
bereits ähnliche Anfragen in der comp.databases.ibm-db2 NG gepostet,
ohne daß eine (zufriedenstellende) Antwort kam. Vielleicht weiß ja
jemand hier, ob so etwas in Arbeit ist oder irgendwo versteckt in den
IBM Webseiten schlummert, ich konnte nichts derartiges entdecken.
Selbst Microsoft liefert einen ordentlichen type-4 (pure Java) Treiber
für Windows UND für Unix(jawohl, richtig gehört :-) Auch die freie
Version von I-Net ist OK.
Vielleicht ist ja bereits entsprechendes in Arbeit in Armonk, auf den
Webseiten war allerdings kein Hinweis zu finden. Es fällt mir schwer
einzusehen, warum eine kommerzielle Datenbank ohne echten JDBC Treiber
(für Windows) kommt...
MySQL war in seiner alpha-Version schon erstaunlich stabil, es musste
eine 4er sein, damit auch Transaktionen möglich sind. Der JDBC Treiber
ist der einschlägig bekannte von Mark Matthews.
Wenn jemand Interesse hat, den Test einmal mit anderen Datenbanken
laufen zu lassen, kann man mich gerne anmailen, das Paket (ohne Garantie
oder Copyright) ist wirklich nicht sehr groß und ziemlich einfach
anzupassen. (Vorsicht : nix für Java-Puristen!) Es ist nur ein klein
wenig Java notwendig (ein ganz klein wenig :-)
Danke für Eure Geduld