Discussion :

[SleTT]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Baldrick]

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

[SleTT]

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)

[Pomalaix]

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.

[SleTT]

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.

[Baldrick]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

GRANT EXECUTE ON DBMS_LOCK TO utilisateur;

[Pomalaix]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

grant execute on dbms_lock to le_compte_qui_va_bien;

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

[SleTT]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[mnitu]

...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 ?

[SleTT]

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".

[Pomalaix]

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.

[mnitu]

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

[SleTT]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Pomalaix]

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é ???

[SleTT]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Waldar]

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

[SleTT]

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

[Pomalaix]

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.

[SleTT]

En quelle version êtes-vous ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ora_9.2.0

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

[Pomalaix]

[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...