Larry Ratlos:
Widerspenstiges Oracle ...

Larrys Kollegen und Vorgesetzte sind zufrieden: Das Unternehmens-CMS läuft inzwischen so, wie man sich das vorgestellt hatte. Larry hoffte also, nun endlich beruhigt Urlaub machen zu können. - Doch weit gefehlt: Es gibt schon wieder ein neues Problem, das auf seine Lösung wartet.

„Wir können so nicht richtig arbeiten!“ beklagt sich der Vertrieb seit geraumer Zeit. „Unsere Kundendaten sind total veraltet: Firmenstandorte sind zum Teil schon seit Jahren nicht mehr aktuell, Ansprechpartner nicht mehr aufzufinden.“ Daraufhin hat sich die Geschäftsleitung zu einer groß angelegten Aktion zur Aktualisierung der Kundendatenbank entschlossen.

Nachdem die Entwickler einen Batch Job zur Aktualisierung der Kundendatenbank bereitgestellt haben, müssen die Administratoren diesen Job auf den sehr umfangreichen Datenbeständen laufen lassen. Der Job beinhaltet viele Full Table Scans, da alle Daten zu verarbeiten sind. Das aber dauert den Administratoren viel zu lange.

Dieses Problem landete - wie sollte es auch anders sein - mal wieder auf Larrys Tisch. Da fällt ihm ein: Er hatte da doch mal was in seiner Oracle Dokumentation gelesen ...

Larry versucht, sich selbst zu helfen

Schnell hat Larry die Stelle wiedergefunden, an der er gelesen hatte, dass der Parameter db_file_multiblock_read_count die Anzahl der Blöcke bei einem sequentiellen Scan festlegt. Als er den Wert zur Probe auf 64 erhöht und einen Full Table Scan analysiert, stellt er jedoch fest, dass die Anzahl nicht, wie erwartet, 64 sondern höchstens 32, meist aber noch geringer ist.

Anbei ein Auszug aus der Trace Datei von Larrys Forschungen. Der Parameter p3 gibt die Anzahl der Blöcke an, welche mit einem I/O gelesen werden:

WAIT #1: nam='db file scattered read' ela= 18651 p1=12 p2=10 p3=12
WAIT #1: nam='db file scattered read' ela= 4231 p1=12 p2=23 p3=13
WAIT #1: nam='db file scattered read' ela= 3787 p1=12 p2=37 p3=16

Larry ist ratlos. Können Sie ihm helfen?

Warum tut Oracle nicht das, was es tun soll? Können Sie ihm mögliche Gründe nennen?

Senden Sie Ihre Begründungen bis zum 15. Juli 2005 an kniffel@ordix.de. Wie immer wird sich Larry mit einer kleinen Aufmerksamkeit bei seinen Helfern bedanken und einige der eingesandten Lösungen veröffentlichen.

Die Lösung des Rätsels aus der ORDIX News 1/2005

In der letzten ORDIX News hatte Larry mit der Access Control für Solaris zu kämpfen. Um das Unternehmens-CMS mit Dateien zu „füttern“, sollten Benutzer ihre Dateien einfach auf ein Samba-Share ziehen können, die dann über einen Dienst vom CMS übernommen werden. Besondere Beachtung fand dabei die Definition der Benutzerrechte, die nun die Aufnahme der Dateien in das CMS regeln:

setfacl -s d:mask:rwx,d:user::---,d:group::---,d:other:---, d:user:cms:rw,\
user::rwx,group::rwx,other:---,user:cms:rwx,mask:rwx cmsVerzeichnis

Diese Kommandozeile sorgt dafür, dass der CMS-Dienst automatisch Lese- und Schreib­rechte bekommt, sobald eine Datei abgelegt wird, die übernommen werden soll. Root-Rech­­te verbieten sich aus Sicherheitsgründen von selbst.

Seitenanfang

Seite drucken

Seite weiterempfehlen