[ORACLE] Datenhandling der Prozesse

[sayso]

Hallo Jungs,

ich habe mal eine Frage bzw. möchte einmal eine Diskussion über das Datenhandling bei Oracle anstoßen.

Ich war gestern auf einen Oracle Workshop und dort wurde folgendes diskutiert bzw. besprochen und ich kann mir das relativ schwer vorstellen.

Ich war bisher der folgenden Meinung:

Die Oracle Schattenprozesse lesen die Daten aus den DB-Files und "schreiben" die gelesenen Daten in die SGA (bzw. Buffer Cache). Dann werden diese Daten dort evtl. durch einen Update oder sonstiges manipuliert und werden über einen Algorithmus wieder in die DB Files geschrieben (vom DBWR). Die geänderten Daten werden als Dirty Blocks bezeichnet und bei Checkpoints in die DB Files geschrieben. (nach Commit)

Ist das bis hier her alles korrekt? Ich denke schon.

Nun kam die folgende Behauptung bei dem Workshop auf:

Wenn ein HASH Join oder ein Sort nicht mehr in der PGA der Schattenprozesse abgehandelt werden kann, dann schreiben die Schattenprozesse von Oracle direkt auf die Temporary Tablespace Files....

Das würde doch die komplette Logik des DBWR umgehen und könnte doch zu inkosistenzen bzw. Block-Waits führen wenn kein Concurrent I/O verwendet wird. Man stelle sich mal vor ich habe viele Schattenprozesse die alle versuchen gleichzeitig in den Temporary Tablespace (direkt!!) zu schreiben und zu lesen.

Ist Euch sowas auch bekannt oder gibt es hierzu vielleicht ein Dokument, das solche "Sonderfälle" beschreibt?

Vielen Dank!

Gruß

[Jasper]

Nun kam die folgende Behauptung bei dem Workshop auf:

Wenn ein HASH Join oder ein Sort nicht mehr in der PGA der Schattenprozesse abgehandelt werden kann, dann schreiben die Schattenprozesse von Oracle direkt auf die Temporary Tablespace Files....

das ist korrekt.

Das würde doch die komplette Logik des DBWR umgehen und könnte doch zu inkosistenzen bzw. Block-Waits führen wenn kein Concurrent I/O verwendet wird. Man stelle sich mal vor ich habe viele Schattenprozesse die alle versuchen gleichzeitig in den Temporary Tablespace (direkt!!) zu schreiben und zu lesen.

DBWR hat mit den tempfiles nichts zu tun. jede session hat ihr eigenes temp-segment, da kommt es zu keinen inkonsistenzen oder blockierungen.

-j

[sayso]

DBWR hat mit den tempfiles nichts zu tun. jede session hat ihr eigenes temp-segment, da kommt es zu keinen inkonsistenzen oder blockierungen.

Hallo Jasper,

erstmal vielen Dank für deine Antwort.

Aber die TEMP-Segmente werden doch im Temporary Tablespace abgelegt.

Hinter dem Tablespace verstecken sich genauso Datafiles auf Filesystemebene.

Wenn nun ein Schattenprozess gerade in den Temporary Tablespace schreibt ist das File dank I-Node locking blockiert. D.h. die 2te Session (=2ter Schattenprozess) muss warten bis die erste fertig ist, da durch I-Node locking kein gleichzeitiger Zugriff auf die selbe Datei erlaubt wird - oder sehe ich da etwas falsch?

Das Problem kann man durch Concurrent I/O umgehen, aber wenn ich das nicht will bzw. habe blockieren sich die Session für eine kurze Zeit, oder nicht?

Gruß

[Jasper]

Wenn nun ein Schattenprozess gerade in den Temporary Tablespace schreibt ist das File dank I-Node locking blockiert. D.h. die 2te Session (=2ter Schattenprozess) muss warten bis die erste fertig ist, da durch I-Node locking kein gleichzeitiger Zugriff auf die selbe Datei erlaubt wird - oder sehe ich da etwas falsch?

achso, du meinst locking auf filesystemebene. da hst du generell recht, aber nicht das file wird gelockt, sondern nur der betroffene i-node. ein inode umfasst mindestens 1 filesystemblock, generell aber mehr. dadurch kann es zu überlappungen und damit zu wartezuständen kommen. je kleiner ein inode, desto besser oder gleich rawdevices nehmen.

-j

[sayso]

Hi Jasper,

vielen Dank für deine Antwort... noch eine kleine Ergänzungsfrage...

Daten aus dem Temporary Tablespace werden somit nie im Buffercache abgelegt? Der DBWR sieht nie Daten vom Temporary Tablespace?

Der Zugriff (egal ob lesend oder schreibend) geschieht immer direkt über die Schattenprozesse? (bei TEMP Daten)

Die Temp-Segmente werden ja beim Herunterfahren der DB "automatisch" aufgeräumt, das Handling der Segmente im laufenden Betrieb liegt somit auch in der Verantwortung der Schattenprozesse?

Gruß

[Jasper]

Daten aus dem Temporary Tablespace werden somit nie im Buffercache abgelegt? Der DBWR sieht nie Daten vom Temporary Tablespace?

Der Zugriff (egal ob lesend oder schreibend) geschieht immer direkt über die Schattenprozesse? (bei TEMP Daten)

ja, genau so ist es.

Die Temp-Segmente werden ja beim Herunterfahren der DB "automatisch" aufgeräumt, das Handling der Segmente im laufenden Betrieb liegt somit auch in der Verantwortung der Schattenprozesse?

das aufräumen erledigt der smon.

-j