Lancer un exécutable en PL/SQL

Version imprimable

01/02/2005, 10h32
Doctor Z

Lancer un exécutable en PL/SQL

Bonjour à tous,

Comment puis-je faire pour qu'un script me génère l'export d'une base de
données ?

Par avance, merci.

[Modération, Orafrance : Titre modifié pour illustrer plus exactement la problèmatique] ;)
01/02/2005, 10h36
SheikYerbouti

Et bien, il faut que votre script invoque l'utilitaire d'export (EXP)
01/02/2005, 10h44
orafrance

ce qui sera particulièrement retor en PL/SQL puisqu'il faut développer une procédure java qui permet d'exécuter un exécutable sur le systéme :?
01/02/2005, 10h49
Doctor Z
OK, donc en faisant un script de ce type :
Code:

1 2 3 BEGIN EXP system/manager OWNER=moi ... END ;
je pourrais évoquer de manière automatique l'export ?

Sinon dans la section DECLARE du bloc PL/SQL, je définit plusieurs
variables, de manière à paramétrer mon export, comment pourrais-je
faire ensuite pour demander à l'utilisateur quelle base dois-je exporter ?
(en fait, je cherche l'instruction PL/SQL qui me permette de demander à
l'utilisateur de rentrer une valeur ...).

Par ailleurs, un script PL/SQL doit-il être enregistré sous avec l'extension .SQL ?

Par avance, merci beaucoup !
01/02/2005, 10h50
Doctor Z

Citation:

Envoyé par orafrance

ce qui sera particulièrement retor en PL/SQL puisqu'il faut développer une procédure java qui permet d'exécuter un exécutable sur le systéme :?

Bonjour,

Tu peux développer un peu plus, s'il te plait ?

Merci.
01/02/2005, 10h54
LeoAnderson

A mon avis, il serait beaucoup plus simple de faire cela en script OS (Bat ou shell) afin de générer le parfile et l'appel de l'export.... 8O
01/02/2005, 10h56
SheikYerbouti

Oui, ou de coder simplement l'appel de EXP dans un script Sql*lus avec la commande HOST() ou !
01/02/2005, 10h59
orafrance

http://www.developpez.net/forums/viewtopic.php?t=180815

Mais je reste convaincu que le PL/SQL n'est pas fait pour éxécuter des programmes OS :?

à lire aussi : http://asktom.oracle.com/pls/ask/f?p=4950:8:8518670148420852553::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:952229840241
01/02/2005, 11h10
orafrance

Avec DBMS_PIPE expliqué par Tom Kyte

Si tu as accés au support Metalink voila d'autres méthodes :

Dynamic SQL and System Commands Using DBMS_PIPE

Calling Operating System Commands from PL/SQL using External Procedures
01/02/2005, 11h12
orafrance

Et pour être tout à fait complet, voila la doc Oracle :
http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_pipe2.htm#1003387
01/02/2005, 11h16
Doctor Z

OK, en fait dans ce cas de figure spécifique, l'utilisation du PL/SQL sera plus compliquée que de passer par un fichier batch ... ?
01/02/2005, 11h26
LeoAnderson

Si vous pouvez le faire par batch, à mon avis c'est préférable et plus simple à mettre en place, à comprendre et à maintenir... :)

Bien sûr, c'est TOUJOURS plus difficile :?

Le PL/SQL n'a d'intérêt que pour éxécuter des taches spécifiques à Oracle et en aucun cas lancer des programmes divers.

Pour info j'ai testé ceci sous Unix :

Installation :

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
$ more host.csh
#!/bin/csh -f
 
sqlplus apps/apps <<"EOF" | grep '^#' | sed 's/^.//' > tmp.csh
 
set serveroutput on
 
declare
        status  number;
        command varchar2(255);
begin
        status := dbms_pipe.receive_message( 'HOST_PIPE' );
        if ( status <> 0 ) then
                dbms_output.put_line( '#exit' );
        else
                dbms_pipe.unpack_message( command );
                dbms_output.put_line( '##!/bin/csh -f' );
                dbms_output.put_line( '#' || command );
                dbms_output.put_line( '#exec host.csh' );
        end if;
end;
/
spool off
"EOF"
 
chmod +x tmp.csh
exec tmp.csh

Code:

1
2
3
4
5
6
7
8
9
10
11
 
SQL> create or replace procedure host( cmd in varchar2 )
  2  as
  3      status number;
  4  begin
  5      dbms_pipe.pack_message( cmd );
  6      status := dbms_pipe.send_message( 'HOST_PIPE' );
  7      if ( status <> 0 ) then raise_application_error( -20001, 'Pipe error' );
  8      end if;
  9  end;
 10  /

Execution :

Code:

1
2
3
$ ./host.csh&
[1]     1859672
$

Code:

1
2
3
4
5
6
7
SQL> exec host('touch ok.orafrance');
 
Procédure PL/SQL terminée avec succès.
 
SQL> exec host('dir')
 
Procédure PL/SQL terminée avec succès.

Résultat :

Sous linux :

Citation:

tmp.csh: dir: introuvable.

Code:

1
2
3
 
$ ls -ltr ok*
-rw-r--r--   1 oracle   dba              0 01 fév 11:24 ok.orafrance

Donc, ça marche parfaitement bien :)

01/02/2005, 11h34
Doctor Z

Merci beaucoup pour toutes ses précisions.
Je vais consulter les différents liens proposés et analyser le tout.

Merci encore.
01/02/2005, 14h06
LeoAnderson
Citation:
Envoyé par orafrance

Code:

1 2 $ ls -ltr ok* -rw-r--r-- 1 oracle dba 0 01 fév 11:24 ok.orafrance

Donc, ça marche parfaitement bien Smile
:!: JAMAIS je ne mettrais ça en place directement !!!
Parce que l'utilisateur (au sens Oracle) qui le lance a l'air (fort logiquement, d'ailleurs) de se retrouver en tant qu'utilisateur "oracle" sur le système UNIX, et donc membre du groupe DBA, ....
En environnement opérationnel, c'est plus que limite....
01/02/2005, 14h12
orafrance

c'est clair que c'est TRES dangereux et que bien entendu, une telle manipulation nécessite de bien restreindre les droits d'exécution de la procedure HOST... en fait, c'est exactement pareil que pour UTL_FILE qui peut être TRES dangereux si une directory comme ORACLE_HOME est créée :?

Par ailleurs, j'en profite pour rappeller que le privilège ALTER ANY USER est aussi très dangereux puisqu'il permet de se connecter à n'importe quel compte (donc SYS ou SYSTEM) sans que personne puisse s'en rendre compte :?
01/02/2005, 14h21
SheikYerbouti

Bon les gars, à quand un petit papier sur les 10 règles d'or sur la sécurité ?
01/02/2005, 14h21
orafrance

si seulement il n'y en avait que 10 :lol:
01/02/2005, 14h23
SheikYerbouti

au moins celles qui permettent de ne pas être califfe à la place du califfe !
01/02/2005, 14h27
orafrance

à toi l'honneur :aie:
01/02/2005, 14h29
SheikYerbouti

règle n°1 : Auncun développeur ne se verra attribué un rôle DBA !
:mrgreen:
01/02/2005, 14h35
orafrance

règle n°2 : Aucun utilisateur n'ayant pas le rôle DBA n'aura de privilege de type ANY (SELECT ANY TABLE, SELECT ANY DICTIONNARY,...) !

règle n°3 : On ne crée des synonymes public que lorsque c'est vraiment nécessaire et seulement sur des objets non systéme !

règle n°4 : On ne mettra JAMAIS les password des utilisateurs DBA en clair dans les scripts !

au suivant :mrgreen:
01/02/2005, 14h38
LeoAnderson

Règle n°5 : jamais à * tu ne positionneras UTL_FILE_DIR
Règle n°6 : A chaque création de compte, la date d'expiration tu renseigneras
01/02/2005, 14h51
orafrance

Citation:

Envoyé par LeoAnderson

Règle n°5 : jamais à * tu ne positionneras UTL_FILE_DIR

Règle N°5 bis : à partir de la 8i, il faudra mettre UTL_FILE_DIR à NULL et utiliser les DIRECTORY :)