Sleep dans un morceau de code !

Bonjour,

Pour un besoin spécifique, j'ai besoin de réaliser une connexion via oracle, de lancer une commander (pour faire sonner un téléphone) puis lancer la commande de fin de sonnerie après un certain temps (X secondes).

Je ne sais pas comment patienter j'avoue... J'ai recherché sur le net mais j'ai trouvé des solutions avec des loops toutes plus sales les unes que les autres...

Je vous donne mon morceau de code exemple (Ne cherchez pas les erreurs, ce n'est qu'un exemple, je ne cherche que le morceau de code à mettre à la place de ##### Sleep ##### ...)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

BEGIN CONNECTION := UTL_TCP.OPEN_CONNECTION (REMOTE_HOST => ADRESSE_IP, REMOTE_PORT => PORT, TX_TIMEOUT => TIME_OUT); EXCEPTION WHEN OTHERS THEN ERROR := 1; BOITIER.LOG ('Impossible de se connecter' || ADRESSE_IP || ':' || PORT); BOITIER.LOG (SQLERRM); END;     IF ERROR <> 1 THEN BEGIN RET_VAL := UTL_TCP.WRITE_LINE (CONNECTION, P_MESSAGE); BOITIER.LOG ('RET_VAL=''' || RET_VAL || ''''); RETOUR := UTL_TCP.GET_LINE (CONNECTION, TRUE); EXCEPTION WHEN OTHERS THEN ERROR := 1; BOITIER.LOG ('Erreur d''ecriture sur le canal TCP ' || ADRESSE_IP || ':' || PORT); BOITIER.LOG (SQLERRM); END;     ##### Sleep #####   UTL_TCP.CLOSE_CONNECTION (CONNECTION); END IF;

---

Merci d'avance pour l'aide ;)

Bonjour,

La procédure qu'il vous faut est DBMS_LOCK.SLEEP

N'oubliez pas d'accorder à l'utilisateur le droit d'exécuter le package DBMS_LOCK

Le problème, c'est que j’exécute ce code dans un .ksh sur le serveur, et que sur les serveurs de prod ça serait bien que j'ai pas à donner de droit à un user...
Comment vérifier que cette utilisateur à les droits?
L'utilisateur par défaut "oracle" doit les avoir dès la naissance non? (:p)

Votre code sera en temps normal une procédure stockée ; cette procédure a un propriétaire ; c'est au propriétaire qu'il faut donner le droit d'exécution sur SYS.DBMS_LOCK.

Non, ça ne sera pas dans une procédure stockée.

Je dois créer un script d'appel et donc ne peux utiliser de l'existant (en tout cas créer ou modifier l'existant).

Je dois donc requêter par le .ksh via sqlplus.

Je parle de l'utilisateur base de données, celui avec lequel vous vous connectez à la base pour exécuter ce code (ou du propriétaire de la procédure si vous décidez de créer une procédure), et non de l'utilisateur système qui lance ce script.

Votre script .ksh contient une connexion à la base pour exécuter ce script, vraisemblablement avec sqlplus. Il suffit de relever le nom de l'utilisateur avec lequel vous vous connectez (je pars du principe que vous ne vous connectez pas avec l'utilisateur SYS,ni avec sqlplus / as ..., ce qui est aussi une connexion en tant que SYS, qui est certes propriétaire du package et n'a besoin de rien pour l'exécuter, mais qui ne doit pas être utilisé pour ce genre de choses)

Il faut alors se connecter en tant que SYS et exécuter la commande suivante :

Code:

---

GRANT EXECUTE ON DBMS_LOCK TO utilisateur;

---

Pour tester, c'est simple : vous vous connectez à SQL*Plus sous le compte que vous avez prévu, et vous faites

Code:

---

exec dbms_lock.sleep(1);

---

Si ça vous pète à la figure, c'est que vous n'avez pas les droits sous ce compte :

Code:

---

1 2 3 4 5 6 7 8 9

SCOTT@ORA112>exec dbms_lock.sleep(1); BEGIN dbms_lock.sleep(1); END;   * ERREUR à la ligne 1 : ORA-06550: Ligne 1, colonne 7 : PLS-00201: l'identificateur 'DBMS_LOCK' doit être déclaré ORA-06550: Ligne 1, colonne 7 : PL/SQL: Statement ignored

---

Dans ce cas, il faut se connecter sous SYS, et donner le droit :

Code:

---

grant execute on dbms_lock to le_compte_qui_va_bien;

---

Edit : Baldrick m'a devancé d'un poil !

Effectivement, l'utilisateur n'a pas les droits en dev et n'a donc surement pas les droits en prod.

Y a t'il une méthode alternative qui n'oblige pas à donner un droit?

J'ai vu :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

IN_TIME INT; --num seconds v_now DATE;   -- 1) Get the date & time SELECT SYSDATE INTO v_now FROM DUAL;   -- 2) Loop until the original timestamp plus the amount of seconds = current date LOOP EXIT WHEN v_now + (IN_TIME * (1/86400)) = SYSDATE END LOOP;

---

Mais j'imagine que ça va bouffer un proc monstre, même si c'est un sleep de maximum 5 secondes je pense...

Citation:

---

Envoyé par SleTT

...Y a t'il une méthode alternative qui n'oblige pas à donner un droit?
...

---

Pourquoi cherchez-vous une mauvaise alternative à celle qui est bonne ?

J'ai bien compris que c'était une bonne solution, je l'utiliserais très certainement dans de prochain cas.

La je ne peux pas utiliser d'autres user que oracle et oracle n'a pas les droits pour faire ce LOCK.
Je ne peux pas non plus GRANT un autre utilisateur parce que c'est utilisé par des gens lambda a des fins de test et qu'ils n'ont pas à savoir les user/mdp à qui mettre des GRANT.

Donc, je cherche toujours une alternative puisque je ne PEUX pas utiliser la solution "classique".

Citation:

---

Envoyé par SleTT

Donc, je cherche toujours une alternative puisque je ne PEUX pas utiliser la solution "classique".

---

Je crois que vous renoncez un peu vite... Si votre besoin est réel, vous n'aurez aucun mal à argumenter auprès du DBA / son chef / le pape pour obtenir ce dont vous avez besoin.

La solution sous forme de boucle est bien entendu affreuse, et a de bonnes chances de ne pas supporter la montée en charge.

Il n’y a pas d’utilisateur Oracle crée par défaut dans une base des données Oracle. Donc pour pouvoir vous connecter et passer vos requêtes quelqu’un (un dba) a créé cet utilisateur et vous a donné les droits de vous connecter. Demandez à la même personne qu’en plus vous donnent les droits nécessaires à votre application pour exécuter les procédures du package dbms_lock

C'est un script de test qui va s’exécuter dans un domaine très sensible et on ne peut pas donner plus de privilèges à un USER.

On ne m'a pas créé de USER, je ne fais qu'utiliser celui présent pour exécuter du SQL.

Le test sera lancé via un utilisateur admin du service oracle sous UNIX via :

Code:

---

1 2 3 4 5

sqlplus /nolog connect / as sysdba   mesrequêtes...

---

S'il n'y a pas de solutions alternatives je le comprendrais, je demande seulement s'il y en a une.

Citation:

---

Envoyé par SleTT

connect / as sysdba

---

Donc vous vous connectez implicitement sous le compte SYS, qui est le superutilisateur de la base. Il a tous les droits possibles dans la base, en particulier celui d'exécuter DBMS_LOCK.
Avez-vous au moins testé ???

:aie:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SQL> connect /as sysdba Connected. SQL> exec dbms_lock.sleep(1); BEGIN dbms_lock.sleep(1); END;   * ERROR at line 1: ORA-06550: line 1, column 7: PLS-00201: identifier 'DBMS_LOCK.SLEEP' must be declared ORA-06550: line 1, column 7: PL/SQL: Statement ignored

---

Quitte à faire un .ksh, découpez votre procédure en deux et collez un sleep unix/linux au milieu.

La par contre, ça arrive à mes limites.

C'est une solution à laquelle je pensais, mais je ne connais qu'un mode de fonctionnement pour ce que je veux faire :

- J'ai une connexion par laquelle je génère un appel TCP_IP vers mon poste (IP + PORT) et qui fait sonner un dispositif.

- Si je coupe le KSH, je vais couper ma connexion et donc ça ne sonnera plus.

- Après avoir patienter, je suis censé renvoyer une trame qui stop la sonnerie.

- L'effet désiré sera donc une sonnerie de X secondes (temps du slip)

D’où le fait que je cherche à faire le sleep via SQL (oracle) plutôt qu'en shell, sinon c'est clair que j'aurais cherché plutôt de ce coté ci effectivement.

Merci pour la proposition en tout cas

Citation:

---

Envoyé par SleTT

:aie:

---

Cette erreur n'est absolument pas normale !
En quelle version êtes-vous ?

Il pourrait y avoir un script DBMSLOCK.SQL à lancer, à voir avec votre DBA.

Citation:

---

Envoyé par Pomalaix

En quelle version êtes-vous ?

---

Code:

---

1 2

ora_9.2.0

---

Le user sysdba n'est pas censé pouvoir "tout" lancer?

Citation:

---

Envoyé par SleTT

[code]Le user sysdba n'est pas censé pouvoir "tout" lancer?

---

Si, mais le responsable de la base, c'est le DBA !
Et comme, soit dit sans offense, vous n'en avez pas les compétences, et que vous dites travailler dans un domaine "très sensible", chacun son boulot...