Performantes löschen bei großen Datenmengen

[Hellspawn304]

Hallo,

ich hab ne Oracle -DB mit knapp 12 millionen datensätzen und muß nun ein teil der einträge löschen um die geschwindigkeit zu erhöen. Zum selectieren verwende ich:

SELECT /*+ INDEX_JOIN(TB61QUALITYINFO) */ *

FROM nlxinb61.tb61qualityinfo

WHERE testdate < TO_DATE ('20070101', 'yyyymmdd');

Um zu erfahren wieviele Datensätze in diesem bereich liegen, da ich max 300.000 auf einmal löschen kann.

Der selekt läuft nun schon seit fast zwei stunden und ein ende ist nicht absehbar.

Beim löschen sieht das ganze noch schlimmer aus, hab gestern fast 4 h gewartet ohne das was passsiert is. Was kann ich tun um es wenigstens etwas schneller zu bekommen?

Vielen Dank schon mal im Vorraus.

[flashpixx]

Sind die Felder indiziert, nach denen Du suchen musst?

Evtl musst Du commiten (bin da was Oracle Angeht nicht so drin).

Evtl kannst Du das Löschen auch durch eine Stored Procedure realisieren.

HTH Phil

[Hellspawn304]

Ein index ist drauf, zum commiten komm ich erst gar nicht, da er innerhalb von 4h nicht fertig geworden ist.

Wie würde das mit der Stored Procedur aussehen?

Okay, das würde mein performensbroblem auch nicht lösen, was ich momentan hab, weil man ja in der procedur auch nur den delete befehl verwändet. Truncate kann ich auch nicht nehmen, weil ich noch einen bestimmen teil der tabelle benötig.

[flashpixx]

Hi,

Wie würde das mit der Stored Procedur aussehen?

genauen Syntax weiß ich leider nicht. Wenn aber erst die Datenmenge zum Client "geschaufelt" werden muss, um dann zu löschen, ginge es eben mit der SP schneller, da sie direkt auf dem DBMS läuft.

Pseudocode:

create procedure "deletedata" with "

myvar = TO_DATE ('20070101', 'yyyymmdd');

delete from tabele where field < myvar;

commit;

"

Vom Client reicht dann meist ein "select deletedata"

Am besten wirklich danach mal suchen

HTH Phil

[dr.dimitri]

Oh je das sind ja mal Aussagen/Tätigkeiten...

Ich fang mal vorne an:

Zum selectieren verwende ich:

SELECT /*+ INDEX_JOIN(TB61QUALITYINFO) */ *

FROM nlxinb61.tb61qualityinfo

WHERE testdate < TO_DATE ('20070101', 'yyyymmdd');

Also du willst zählen? Ich seh aber leider keinen Count. Dann der Hint: Mal davon abgesehen, dass die Verwendung hier absolut nichts bewirkt und die Syntax falsch ist, solltest du die Finger von Hints lassen und lieber dafür sorgen, dass die Tabelle aktuelle Statistiken besitzt.

da ich max 300.000 auf einmal löschen kann

Wieso? Mach den UNDO TS doch einfach größer.

und muß nun ein teil der einträge löschen um die geschwindigkeit zu erhöen.

Das ist meistens ein Trugschluss. Sind die Statistiken aktuell? Die Statements optimiert etc? Hast Du einen SQL Trace gemacht um herauszufinden woran es eigentlich liegt?

Wenn aber erst die Datenmenge zum Client "geschaufelt" werden muss

Oracle ist nicht Access. Hier wird überhaupt nichts zum Client geschaufelt. Daher ist ein normales SQL erstmal nicht schneller oder langsamer als eines das über eine SP abgesetzt wird.

Wenn Du wirklich noch löschen willst/musst, dann gibt es zwei Möglichkeiten es zu machen:

DELETE FROM nlxinb61.tb61qualityinfo WHERE testdate TO_DATE ('20070101', 'yyyymmdd') AND ROWNUM <= 300000;

COMMIT;

Und das ganze solange bis erstmalig weniger als 300 Tsd Sätze gelöscht werden.

Eine andere Möglichkeit ist es, die Daten die du behalten möchtest in eine andere Tabelle zu kopieren, die Ursprungstabelle zu truncaten und die Daten wieder zurückzukopieren. Ist aber nur problemlos möglich wenn keine anderen Sätze per RI dranhängen und niemand auf die Daten zugreifen muss.

In beiden Fällen vorher und nachher neue Statistiken erfassen.

Poste doch mal den Output deines explain plans.

Dim

PS: Die Frage kommt mir aber irgendwie bekannt vor. Hast die nicht schon mal vor ein paar Tagen in einem anderen Forum gepostet und eine ähnliche Antwort von mir bekommen?

[Hellspawn304]

Danke Dimi,

ich kann die tabelle nicht löschen, bzw. rauskopieren und umbennen, weil die produktionsdaten in diese in echtzeit reingeschrieben werden, somit würden mir datensätze verloren gehen. Was aber nicht gewünscht ist, wie du dir denken kannst. Die größe des rollback kannich nicht vergrößern, weil ich nicht die rechte dafür hab.

Das mit den statistiken muss ich mir mal anschauen.

Nochmals Danke.

PS.: Nein, hab ich nicht.

[dr.dimitri]

Das mit den statistiken muss ich mir mal anschauen.

Unbedingt. Frag bei eurem DBA nach, ob er regelmäßig Statistiken erfasst. Ansonsten soll er es einplanen.

Dim

[dbwizard]

Danke Dimi,

ich kann die tabelle nicht löschen, bzw. rauskopieren und umbennen, weil die produktionsdaten in diese in echtzeit reingeschrieben werden, somit würden mir datensätze verloren gehen. Was aber nicht gewünscht ist, wie du dir denken kannst. Die größe des rollback kannich nicht vergrößern, weil ich nicht die rechte dafür hab.

Das mit den statistiken muss ich mir mal anschauen.

Nochmals Danke.

PS.: Nein, hab ich nicht.

Hallo

Die größe des rollback kannich nicht vergrößern, weil ich nicht die rechte dafür hab.

- Dann frag doch jemanden, der die Rechte hat ?

- Frage : Wird dies Aktion regelmässig durchgeführt, z.b. monatlich oder so ? Dann wäre es eine Möglichkeit, die Tabelle entsprechend zu partitionierern. Ansonsten kann ich mich den Aussagen von Dimitri anschliessen

Gruss

[Hellspawn304]

Hallo

- Frage : Wird dies Aktion regelmässig durchgeführt, z.b. monatlich oder so ? Dann wäre es eine Möglichkeit, die Tabelle entsprechend zu partitionierern. Ansonsten kann ich mich den Aussagen von Dimitri anschliessen

Gruss

Nein, wird sie nicht, weil die QS-daten min ein jahr in der db bleiben müssen.