2016-12-06 6 views
2

Wird es eine CPU binden, während es "schläft" oder eine andere unerwünschte Nebenwirkung?Ist die PL/SQL-Funktion dbms_lock.sleep sicher?

Ja - paranoid, aber mit einigen kritischen Code arbeiten und wollen keine gotchas.

+2

Es wird ein Leerlauf warten. "Unerwünschte Nebenwirkung" ist jedoch ein bisschen breit. Es gibt eine gewisse Ungewissheit darüber, wann genau der Faden erwacht sein wird. Wenn Sie zum Beispiel für ein paar Hundertstelsekunden schlafen, wachen Sie vielleicht eine Zehntelsekunde später auf. Weniger wichtig, wenn Sie mehrere Sekunden schlafen. –

+0

In meinem Fall ist Präzision nicht wichtig. Ich habe es mit einer Situation zu tun, in der ein System ein anderes System überlastet, wodurch es zum Absturz kommt. Ich bin auf der Suche nach einem Weg, wie man auf das Zielsystem geworfen wird. Schlaf schien der ideale Weg dafür zu sein. – Jeff

+1

Das mag völlig in Ordnung sein. Je nach Umfang des Problems möchten Sie möglicherweise eine asynchrone Warteschlange, in die ein Prozess Nachrichten in eine Warteschlange einreihen kann, und ein anderer Prozess (oder andere Prozesse) kann später aus der Warteschlange entfernt werden. Auf diese Weise können die Verbraucherprozesse selbst dafür sorgen, dass sie sich selbst drosseln, anstatt dass der Hersteller weiß, wie er Gas geben kann. –

Antwort

3

DBMS_LOCK.SLEEP verbraucht keine wichtigen Ressourcen und ist absolut sicher zu verwenden.

Ich habe es viele Male benutzt und habe nie irgendwelche Probleme erfahren. Der folgende Test erzeugt eine große Menge an Schlafjobs, verursacht jedoch keine Probleme.


die SLEEP Funktion zu testen, eine riesige Menge an Jobs, die schlafen alle zur gleichen Zeit erstellen.

Stellen Sie zuerst sicher, dass die Datenbank eine große Anzahl von Jobs unterstützen kann. Es gibt verschiedene Parameter, die dies einschränken können. Überprüfen Sie die folgenden Parameter:

select name, value 
from v$parameter 
where name in ('job_queue_processes', 'processes', 'sessions') 

Erstellen Sie 1000 geplante Jobs, die 30 Sekunden warten.

begin 
    for i in 1 .. 1000 loop 
     dbms_scheduler.create_job(
      job_name => 'JOB_'||i, 
      job_type => 'PLSQL_BLOCK', 
      start_date => systimestamp, 
      enabled => true, 
      job_action => 'begin dbms_lock.sleep(30); end;' 
     ); 
    end loop; 
end; 
/

Nun sehen, wie viele Aufträge ausgeführt werden:

select count(*) from gv$session where schemaname = user; 
select count(*) from dba_scheduler_running_jobs where owner = user; 

Auf meinem Desktop nur ich 239 Arbeitsplätze erhalten. Es ist nicht 1000 wegen der ursprünglichen Parameter, aber ich würde 239 immer noch als einen guten "großen" Wert betrachten.

Trotz all dieser Aktivitäten merke ich keine Leistungsprobleme und Oracle verwendet weniger als 1% der CPU.

+1

sehr gute Antwort. Einzige Sache, es sollte keine Transaktion oder Sperren vor dem Schlaf geben, die das Zeug blockieren können. –