Update im PLSQL block ist sehr langsam

Ich habe das folgende problem,
führe ich meine procedure aus(siehe beispiel), warte ich ca. 2-3 stunden, bis er das update gemacht hat.

Beispiel:
create or replace procedure xyz is

v_period := 200601;
update xtable set periode = v_period; – dauert im plsql 2-3stunden
commit;

end xyz;

wenn ich aber das update als script ausführe, geht es viel schneller,
wo liegt das problem?
update xtable set periode = 200601; – dauer ca. 10-20 min

gruss south

Hallo,

eigentlich sollte die Prozedur so gar nicht laufen. Ein COMMIT idst doch nur in AUTONOMEN TRANSAKTIONEN möglich.

Ansonsten sollte die Prozedur gleich schnell sein. Es sei denn, der Prozess, der die Prozedur startet hat eine geringere Priorität oder die Zeit ist ungünstig, so dass viele UNDO-Loggs gelesen werden müssen.

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Ich habe das folgende problem,
führe ich meine procedure aus(siehe beispiel), warte ich ca.
2-3 stunden, bis er das update gemacht hat.

  • Kannst du bitte die komplette Prozedur posten ?

Ich habe das folgende problem,
führe ich meine procedure aus(siehe beispiel), warte ich ca.
2-3 stunden, bis er das update gemacht hat.

  • Kannst du bitte die komplette Prozedur posten ?

hier ist der update in der procedure…

UPDATE CP_SHR2.CSCUM_T_UMCOUNT TB
SET cluster_id = CP_ADM.CAP_UTIL.f_cluster_id(ROUND(CHF_AMOUNT), P_Period ,P_LocId)
WHERE al_type_cd = 20001;

sobald ich diesen block aus der procedure herausnehme und alleine ausführen lasse, gehts viel schneller

Hi!

eigentlich sollte die Prozedur so gar nicht laufen. Ein COMMIT
idst doch nur in AUTONOMEN TRANSAKTIONEN möglich.

ähem, Herr Professor, das ist definitiv eine falsche Aussage; ein COMMIT ist _überall_ möglich; ob’s auch ausgeführt werden kann (wenn die Prozedur z.B. von einem Trigger aufgerufen wird), sei mal dahingestellt

Ansonsten sollte die Prozedur gleich schnell sein. Es sei
denn, der Prozess, der die Prozedur startet hat eine geringere
Priorität oder die Zeit ist ungünstig, so dass viele
UNDO-Loggs gelesen werden müssen.

Es sei denn, die Tabelle ist irgendwie in der Prozedure gelockt; oder das Script wird direkt nach der Prozedur gestartet und die DB hat noch alles im Cache; oder oder

Grüße,
Tomh

Hi!

UPDATE CP_SHR2.CSCUM_T_UMCOUNT TB
SET cluster_id =
CP_ADM.CAP_UTIL.f_cluster_id(ROUND(CHF_AMOUNT), P_Period
,P_LocId)
WHERE al_type_cd = 20001;

sobald ich diesen block aus der procedure herausnehme und
alleine ausführen lasse, gehts viel schneller

Auch wenn Du die Funktion „CP_ADM.CAP_UTIL.f_cluster_id“ so drinnen läßt?

Ev. würde ein Function-Based-Index helfen?

Grüße,
Tomh

Wieso denn FBI? Eingeschränkt wird einfach per Konstante und ein Index sollte entweder in beiden Varianten oder garnicht verwendet werden.

an den OP: Poste doch bitte mal den VOLLSTÄNDIGEN Code der beiden Varianten. Ich vermute dass unterschiedliche Dinge gemacht werden, die nur gleich aussehen.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]