Declarații DDL în DBMS_JOB

Încerc să programez o slujbă folosind DBMS_JOB (nu pot utiliza DBMS_SCHEDULER din motive de securitate), care utilizează o instrucțiune DDL.

DECLARE
job_num NUMBER;
BEGIN
DBMS_JOB.SUBMIT(job => job_num,
what => 'BEGIN EXECUTE IMMEDIATE ''CREATE TABLE temp1 (ID NUMBER)''; END;'
);
DBMS_OUTPUT.PUT_LINE('JobID'||job_num);
DBMS_JOB.RUN(job_num);
END;
/

Nu reușește să execute, dându-mi un mesaj de eroare:

ORA-12011: nu a reușit să se execute 1 de locuri de muncă   ORA-06512: la "SYS.DBMS_IJOB", linia 548   ORA-06512: la "SYS.DBMS_JOB", linia 278   ORA-06512: la linia 8

La eliminarea instrucțiunii DBMS_JOB.RUN() din interiorul blocului anonim, pot crea cel puțin (și salva) lucrarea. Când verifică lucrarea, aceasta a salvat acest lucru ca fiind codul de executare     BEGIN EXECUTE IMEDIATE 'CREATE TABLE Temp1 (id NUMBER)'; SFÂRŞIT;

Dacă o execut independent, se execută în mod evident. Singura dată când nu reușește atunci când încerc să execut întregul lucru prin apelul la DBMS_JOB.RUN ().

Există o restricție privind utilizarea declarațiilor DDL ca parametru în DBMS_JOB? Nu găsesc nici un indicator în documentație pentru asta.

0
S-a adăugat mesajul de eroare "întotdeauna"
adăugat autor Incognito, sursa
Numele real al tabelului, pe care trebuie să-l creez, nu este numit "TEMP". Tocmai am folosit-o pentru a posta această întrebare aici. De asemenea, intenția mea reală este de a crea numai un tabel temporar, și nu un tabel. Nu am prea multă flexibilitate, deoarece am modificat o anumită secțiune a unei aplicații și trebuie să treacă prin această abordare "fără voie".
adăugat autor Incognito, sursa
Nu am auzit niciodată de mesajul de eroare "întotdeauna" ...
adăugat autor Jeffrey Kemp, sursa
Imposibil de reprodus. A lucrat pentru mine (testat în 11gR2), iar postul a creat tabelul "TEMP" așa cum era de așteptat.
adăugat autor Jeffrey Kemp, sursa
+1 la comentariul lui Aldridge - crearea de tabele pe-the-fly este de obicei un semn al unui design slab al sistemului.
adăugat autor Jeffrey Kemp, sursa
Puteți extinde din motive de securitate care vă împiedică să utilizați DBMS_Scheduler? De asemenea, te-ai uitat la utilizarea tabelelor temporare globale? Văzând un tabel numit TEMP fiind creat este un pic de steag roșu.
adăugat autor David Aldridge, sursa

1 răspunsuri

În timp ce recitiți sentimentele celorlalți comentatori - crearea de tabele în mișcare este un steag roșu care deseori indică faptul că ar trebui să utilizați într-adevăr mese temporare globale - câteva întrebări.

  1. Există un motiv pentru care aveți nevoie de apelul DBMS_JOB.RUN ? Apelul dvs. către DBMS_JOB.SUBMIT indică Oracle să execute sarcina asincronă imediat ce tranzacția mamă se angajează. Deci, în mod normal, ați sunat DBMS_JOB.SUBMIT și apoi doar "COMMIT".
  2. Utilizatorul care depune o lucrare are privilegiul CREATE TABLE acordat direct? Cred că utilizatorul are privilegiul CREATE TABLE acordat printr-un rol. Acest lucru v-ar permite să rulați blocul anonim PL/SQL interactiv, dar nu într-un loc de muncă. Dacă da, veți avea nevoie de DBA pentru a vă acorda privilegiul CREATE TABLE direct, nu printr-un rol.
  3. Atunci când o lucrare nu reușește, o înregistrare este scrisă în jurnalul de alertă cu mesajul de eroare. Puteți obține (sau, mai probabil, DBA) mesajul de eroare și stiva de eroare din jurnalul de alertă și îl postați aici (presupunând că este ceva diferit de problema privilegiilor din # 2).
2
adăugat
Mulțumesc lui Justin. Acest lucru ajută foarte mult. Voi verifica cu DBA acele privilegii pentru a crea primul tabel!
adăugat autor Incognito, sursa