Erkennen von sinnvoll zu reorganisierenden Indeces

[Martin R.]

Hallo liebe Oracle-Gemeinde,

gibt es eine Möglichkeit zu erkennen, wann es sinnvoll ist Tabellen und Indeces zu reorganisieren.

Bisher dachte ich das u.a. Abgleich reicht
ROUND((SUM(TC.AVG_COL_LEN + 1) + 7) * I.NUM_ROWS /
(I.LEAF_BLOCKS * (8192 -100 - 23 * NVL(I.INI_TRANS, 2)) *
(1 - NVL(I.PCT_FREE, 10) / 100)) * 100, 0)

FROM user_INDEXES I,
user_IND_COLUMNS IC,

<75 ist



Soviel weiss ich dank Dim schon

http://entwickler-forum.de/showpost....02&postcount=5

Weiterhin schau ich mir die Chained rows in der user_tables an.

num_rows, blocks, chain_cnt
151 376 144

Hiebei schau ich mir das Verhältnis von chain_cnt zu num_rows.
Das Gros der Tabellen beinhaltet keine Tatentypen wie z.B Long und auch weniger als 254 Spalten.

Meine Frage hierzu gibt es einen Richtwert, bei dem ich davon ausgehen kann, dass diese Tabelle reorganisiert werden sollte?
Also Quasi chain_cnt/num_rows <x

Und als letztes, gibt es da evtl etwas sinnvolles zu lesen und/oder lohnt sich der Performance-Kurs bei Oracle für solche Fragestellungen bzw. Analysen?


Mein Problem
ich sitze zwischen zwei Stühlen(Externe) Rechenzentrum und Entwickler.
Nun würde ich gern einschätzen wollen, inwieweit es sinnvoll ist, wie z.B. vom software-haus empfohlen, auch wöchentlich zu reorganisieren.

Vielen dank und entschuldigt bitte meine vielen und evtl auch dümmlichen Fragen.

Viele Grüße

Martin

[dimitri]

Hi,

Chained Rows wirst Du durch einen Tabellenreorg nicht los, denn wenn ein Datensatz nicht komplett auf einen Block passt, dann wird das auch nach dem Reorg so sein.
Handelt es sich um jedoch nicht um Chained Rows, sondern um Migrated Rows - also Datensätze, die aus Platzgründen von Block A nach Block B verschoben wurden und auf deren alten Platz nur noch ein Pointer verbleibt, dann verschwinden diese nach dem Reorg.

Die Frage ist dann eher, warum dieses Problem auftritt. Sofern man keinen ASSM Tablespace verwendet, müsste man hier mit den PCTFREE Wert der Tabelle anpassen. Immer und immer wieder zu reorganisieren bringt nichts.

Wir haben hier z.B. eine 4TB Oracledatenbank die seit ca. 2 1/2 Jahren läuft, ein Datenwachstum von ca. 100GB/Monat hat und dort wurde noch nie eine Tabelle reorganisiert - warum auch.

Unsere Hosties reorganisieren ihre DB2 Tabellen einmal in der Woche. Vermutlich ist das auch schon Trandition und wird vom Ausbilder an den Azubi weitergegeben. Die Sinnfrage sollte man hier nicht stellen.

Die Frage ist auch, warum wollt ihr reorganisieren? Nur weil der Hersteller das so empfiehlt oder gibts konkrete Probleme?

Dim

[Martin R.]

Hallo Dim,

vorab vielen Dank!

Leider kann ich im Momemt nicht viel dazu sagen, da ich meinen Zug bekommen muss

Entschuldige bitte.


Und noch kurz, ja, Sie sind der Meinung, dass die nicht reorganisierten Indeces und Tabellen für erhebliche Performancedefiziten führt.

Nun muss ich es mir hatl anschauen und zusehen woran es denn wirklich liegt.

Nochmals vielen Dank!!!

Viele Grüße

Martin

[Martin R.]

Hallo Dim,

zu Deiner Frage.
Ja, der Hersteller empfielt es.
Und es kommt auch teilweise zu erheblichen Performance Problemen.

Eine Ursache haben wir vermeidlich erkannt. Und zwar werden vom Rechenzentrum Statistikjobs gefahren, während Tabellen geändert werden.
Diese werden wir nun sperren und eigenen Statistiken fahren. Entweder jeweils im vorlauf der Jobs oder Quartalsweise, wenn wir sicher stellen können, dass keine Jobs laufen.

pctfree ist auf 10 eingestellt(also imho Standard), pctused auf null.
Der Tablespace ist locally managed.

Und natürlich noch eine Frage

Wie kann ich denn den Anteil der Migrated Rows ermitteln und gibts es einen Richtwert, der Aussagt, ab wann sich eine Reorganisation lohnt?

Danke Dir schon mal und entschuldige bitte mein fliehen am Freitag.

Viele Grüße

Martin

[dimitri]

Das kannst Du z.B. hier nachlesen:
http://www.akadia.com/services/ora_chained_rows.html

Aber das hört sich alles nach herumstochern in. So wie ich das sehen, ist es so, dass "die Datenbank" zu langsam ist. Jetzt wird versucht, mit diversen Tipps, die sich im Internet finden irgendwas zu verbesser - ohne zu wissen, ob es wirklich was bringt.

1. Was genau ist langsam? Gibt es Statements, die identifiziert wurde? Wie sieht ein AWR report bzw. ein Statspack Protokol über ca. 10-20 Minuten aus?
2. Wenn man die Top 10 Statements weiß, gibt es Möglichkeiten diese einfach zu tunen? Sprich wird im Zugriff z.B. der falsche Datentyp verwendet welcher daraufhin die Verwendung des Index ausschließt etc. etc.
3. Wenn das abgeklopft ist, gibt es die Möglichkeit Applikationstuning zu betreiben? werden z.B. diverse Abläufe in einer Schleife ausgeführt, werden Bindvariablen verwendet etc.

Bevor diese Fragen nicht geklärt sind, würde ich mich mit solchen Dingen überhaupt nicht beschäftigen. Das ist definitiv nicht die Lösung eurer Probleme - auch wenn ein Hauch von Systemviews das glauben machen möchte.
Wenn man eine optimal getunte Anwendung besitzt, dann kann man prüfen, ob sich durch Vermeidung von Row Migration (und das beutet nicht, regelmäßig einen Reorg durchzuführen, sondern die Ursache zu beheben) noch bessere Zugriffszeiten zu bekommen.
Oracle migriert eine Zeile übrigends wieder zurück falls sich durch einen UPDATE/DELETE die Möglichkeit bietet.

Dim

[Martin R.]

Hallo Dim,

vielen Dank!

Und Du hast recht, meinerseits ist es ein herrumstochern.
Ob es beim Hersteller und/oder Rechenzentrum ein, wie Du sagst herrumstochern ist vermag ich nicht zu beurteilen. Und hoffe dies auch nicht

Wir gehen nun den Tipps des Hersteller nach, wo Performanceschwächen vermutet werden.
GAnz oben auf der Liste sind halt chained_rows sowie schlechte Indices und Statistiken.

Hast Du schon mal von einem Entwickler gehört, der schlecht entwickelt oder einem Admin, der schlecht administriert?

Danke Dir für die vielen Tipps

Viele Grüße

Martin