Langsam löscht aus der Tabelle mit CLOB-Felder in Oracle 10g

Bin ich auf ein Problem, wo Oracle ist sehr langsam, wenn ich versuche zum löschen von Zeilen aus einer Tabelle, die enthält zwei CLOB-Felder. Der Tisch hat Millionen von Zeilen, keine Einschränkungen, und die löscht basierend auf dem Primärschlüssel. Ich habe wieder aufgebaut Indizes und Statistiken neu berechnet, ohne Erfolg.

Was kann ich tun um die Leistung zu verbessern löscht aus dieser Tabelle?

InformationsquelleAutor bitstream | 2009-02-08
  1. 2

    Spur, mit wartet, aktiviert 

    http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_monitor.htm#i1003679

    Finden Sie die trace-Datei im UDUMP-Verzeichnis. TKPROF es.
    Blick auf das Ende und es wird Ihnen sagen, was die Datenbank verbrachte seine Zeit damit, während Sie, dass SQL. Der folgende link eine gute übersicht, wie Sie zu analysieren, ein performance-Problem.

    http://www.method-r.com/downloads/doc_download/10-for-developers-making-friends-with-the-oracle-database-cary-millsap
    • Sehr cool. Ich werde versuchen, diese heute. Danke!
    InformationsquelleAutor Gary Myers
  2. 1

    Mit Oracle zu beachten, dass die Menge an redo-Sie generieren, wenn Sie eine Zeile löschen. Wenn der CLOB-Felder sind sehr groß, es kann nur eine Weile dauern, für Oracle, um Sie zu löschen, da die Menge der redo geschrieben wird und es möglicherweise nicht viel Sie tun können.

    Einen test, den Sie durchführen kann, ist zu sehen, wenn das löschen dauert eine lange Zeit auf eine Zeile, wo beide CLOB-Felder werden auf null gesetzt. Wenn das der Fall ist, dann kann es sein, das index-updates für eine lange Zeit. Wenn das der Fall ist, müssen Sie möglicherweise zu untersuchen, die Konsolidierung der Indizes, wenn möglich, löscht sehr Häufig auftreten.

    Wenn die Tabelle einer abgeleiteten Tabelle, was bedeutet, es kann umgebaut werden von anderen Tabellen, können Sie Blick auf die NOLOGGING-option auf dem Tisch. Sie können die Neuerstellung der Tabelle aus der source-Tabelle mit minimaler Protokollierung.

    Ich hoffe, dieser Eintrag hilft einige, aber etwas mehr details könnten helfen bei der diagnose des Problems.

    • Vielen Dank Nick. Der Letzte test lief ich hatte die CLOB-Felder genullt, sich und das löschen war immer noch langsam. Es gibt nur zwei Indizes, einem PK-index für eine einzelne Spalte und einem FK-index für eine einzelne Spalte. Diese Indizes sind nicht anders von den anderen in der DB die kluge Größe.
    • Wie viele Tabellen sind foreign key-Einschränkungen auf Ihren Tisch? Unabhängig von der Anzahl, die Sie überprüfen möchten, um zu sehen, ob die Tabellen, die id referenzieren dieser Tabelle ist indiziert. Wenn Sie nicht könnte dies die Ursache des Problems.
    InformationsquelleAutor Nick
  3. 1

    Gibt es untergeordnete Tabellen, die diese Tabelle referenzieren, von denen löschen? (Sie können wählen Sie aus user_constraints wo r_constraint_name = primary key name die Tabelle, die Sie löschen sich aus).

    Einen löschen kann langsam sein, wenn Oracle muss sich in eine andere Tabelle, um zu überprüfen es gibt keine untergeordneten Datensätze. Normale Praxis ist, um index alle Fremdschlüssel, die auf die Kind-Tabellen, so ist dies kein problem.

    Folgen Gary Beratung, führen Sie die trace-und nach dem TKPROF-Ergebnisse hier jemand in der Lage sein, weiter zu helfen.

    • Es gibt keine Einschränkungen.
    InformationsquelleAutor WW.
  4. 1

    Ihre UNDO tablespace scheint der Engpass in diesem Fall.

    Überprüfen, wie lange es dauert, um eine ROLLBACK nachdem Sie die Daten löschen. Wenn es Zeit braucht, vergleichbar mit der Uhrzeit der Abfrage selbst (innerhalb 50%), dann ist dies sicherlich der Fall.

    Beim ausführen einer DML Abfrage, die Ihre Daten (sowohl original und geändert) geschrieben, die in die redo-logs und dann angewendet, um die datafiles und die UNDO tablespace.

    Löschen Millionen von CLOB Zeilen dauert das kopieren mehrere hundert Megabyte, wenn nicht Gigabyte, der UNDO tablespace, das dauert zehn Sekunden selbst.

    Was kann man dagegen tun?

    1. Erstellen Sie ein schneller UNDO: legen Sie es auf einem separaten Datenträger machen es weniger spärlich (eine größere Datei).
    2. Verwenden ROLLBACK SEGMENTS statt verwaltet UNDO weisen eine ROLLBACK SEGMENT für diese Abfrage und Ausgabe SET TRANSACTION USE ROLLBACK SEGMENT vor dem ausführen der Abfrage.

    Wenn es nicht der Fall ist, ich. e. ROLLBACK führt viel schneller, als die Abfrage selbst, dann versuchen, mit Ihnen zu spielen REDO Parameter:

    1. Erhöhen Sie Ihre REDO Puffer Größe über LOG_BUFFER parameter.
    2. Increate der Größe der logfiles.
    3. Erstellen Sie Ihre Protokolldateien auf separaten Datenträgern, so dass das Lesen aus einem ersten Datenfile und nicht behindert schreiben zu einem zweiten, einem so auf.

    Beachten Sie, dass UNDO Operationen generieren auch REDO, so es ist nützlich, um all dies zu tun sowieso.

    NOLOGGING beraten, bevor Sie nutzlos ist, wie es angewendet wird, die nur auf bestimmte Gruppe von Operationen aufgeführt hier, DELETE nicht einer von diesen Operationen.

    InformationsquelleAutor Quassnoi
  5. 0

    Gelöscht CLOBs am Ende nicht in die UNDOTBS da Sie versioniert und retented im LOB-Segment. Ich denke, es wird generieren einige LOBINDEX änderungen rückgängig.

    Wenn Sie null-oder leeren des LOBs vor, hast du eigentlich gemessen, dass die Zeit mit commit getrennt von dem LÖSCHEN? Wenn Sie Tausende von löscht, verwenden Sie batch-verpflichtet? Die Instanz ist, die im Leerlauf? Dann AWR-Bericht sollte Ihnen sagen, was Los ist.

    InformationsquelleAutor
Schreibe einen Kommentar