Nous sommes 2012 2017. Les scripts sont une gueule de bois maladroite et fragile du dernier millénaire. Oracle dispose d'une gamme fantastique de fonctionnalités que nous pouvons exécuter en PL/SQL, ainsi que de procédures stockées Java et d'une planification pour le démarrage des travaux. Hormis l'exécution de DDL pour créer ou modifier des schémas, il n'y a pratiquement aucun besoin de scripts dans un environnement de base de données Oracle ; même les scripts DDL doivent être déclenchés à partir d'un client externe, probablement un outil de construction tel que TeamCity.
En particulier, je considérerais la tentative d'exécution d'un script SQL à partir d'un programme PL/SQL comme un échec architectural. Que faites-vous avec le script que vous ne pouvez pas faire avec une procédure stockée ?
Quant au passage d'une entrée à une procédure stockée, c'est à cela que servent les paramètres. PL/SQL n'est pas interactif, nous avons besoin d'un client pour entrer les valeurs. Selon le scénario, cela peut être fait de manière asynchrone (valeurs dans un fichier ou une table) ou synchrone (appel de la procédure stockée depuis SQL*Plus, SQL Developer ou un frontal sur mesure).
Cela dit, dans le monde réel, nous travaillons avec des architectures désordonnées avec des interdépendances entre la base de données et le système d'exploitation externe. Alors que pouvons-nous faire ?
- Nous pouvons écrire une procédure stockée Java pour exécuter des commandes shell. C'est la solution vénérable, qui existe depuis Oracle 8i. En savoir plus.
- Dans Oracle 10g, remplacez DBMS_JOB par DBMS_SCHEDULER. Une des améliorations de cet outil est sa capacité à exécuter des travaux externes, c'est-à-dire des scripts shell. En savoir plus.
- Étant donné que les tables externes d'Oracle 11g R1 prennent en charge les scripts de préprocesseur, qui exécutent des commandes shell avant d'interroger la table. En savoir plus.
Notez que toutes ces options nécessitent un accès élevé (autorisations sur les objets DIRECTORY, informations d'identification de sécurité, etc.). Ceux-ci ne peuvent être accordés que par des utilisateurs privilégiés (c'est-à-dire des DBA). À moins que notre base de données n'ait une configuration de sécurité étonnamment laxiste, nous n'avons aucun moyen d'exécuter un script shell arbitraire à partir de PL/SQL.
Enfin, les avantages que vous attendez de l'exécution d'un script SQL en PL/SQL ne sont pas clairs. N'oubliez pas que PL/SQL s'exécute sur le serveur de base de données, donc il ne peut pas voir les scripts sur la machine cliente . Cela semble pertinent compte tenu de l'obligation d'accepter les entrées de l'utilisateur.
La solution la plus simple est peut-être la reconfiguration du script d'origine. Divisez l'appel PL/SQL nécessaire en un bloc, puis appelez simplement le script nommé :
begin
proc(para1,para2);
end;
/
@prompt1.sql
