2011-03-17 1 views
1

J'ai beaucoup de paquets qui ont dû être compilés lorsque je passe du développement à la production ou lorsque nous publions une demande de changement.procédures de compilation en bloc/sql en vrac

maintenant, nous compilons chacun des paquets un par un en utilisant toad ou sqldbx, y at-il un moyen que je puisse écrire un fichier batch avec la commande sqlplus afin que je puisse exécuter tous mes paquets en une fois. .sql

Répondre

3

Vous pouvez mettre toutes les requêtes sQL dans un fichier texte et d'exécuter que par:

SQL > @/path/script.sql 

Vous avez juste besoin de fournir chemin du script à exécuter.

1

Mon approche serait de copier tous les scripts du paquet dans un répertoire puis de créer un seul script sql dans ce répertoire pour charger tous les paquets, voir l'exemple ci-dessous.

-- load package specifications 
@@package1.pks 
@@package2.pks 

-- load package bodies 
@@package1.pkb 
@@package2.pkb 
3

Normalement, lorsque nous modifions une base de données qui invalide un grand nombre d'objets, la manière la plus facile de les recompiler est d'exécuter sqlplus "/ as sysdba" @?/rdbms/admin/utlrp Cette procédure devient plus intelligente à chaque version et à partir de 10g elle utilise Oracle Scheduler pour fonctionner en parallèle. Bien sûr, cela ne fonctionne qu'avec l'accès dba à la base de données. Si vous manquez de la réponse de Rob van Wijk est la voie à suivre.

0

vous pouvez utiliser dba_objects pour vérifier les objets non valides et utiliser SQL dynamique pour générer de compiler des déclarations, quelque chose comme:

select 'alter ' || object_type || ' ' || owner || '.' || object_name || ' compile;' 
from dba_objects 
where status = 'INVALID' 
and object_type in ('PACKAGE', 'PROCEDURE', 'FUNCTION'); 

vous pouvez mettre cela dans un script SQL.

Vous pouvez également regarder dans le paquet de utl_recomp

+1

toute raison de la récente downvote ...? – tbone

1

Une façon d'aborder c'est de déployer votre code dans le bon ordre.

Les packages PL/SQL sont eux-mêmes l'API du code dans le corps du package et les packages eux-mêmes ne dépendent pas les uns des autres. Les corps de paquet peuvent cependant dépendre de paquets, donc si un paquet est recompilé, il risque d'invalider les corps du paquet qui le référencent.

Malheureusement, il est très fréquent de voir les déploiements qui travaillent dans cet ordre:

create or replace Package A ...; 
create or replace Package Body A ...; 
create or replace Package B ...; 
create or replace Package Body B ...; 
create or replace Package C ...; 
create or replace Package Body C ...; 

Cela a l'effet secondaire que si le code dans le paquet du corps A dépend du paquet B, puis lorsque le groupe B est (re) créé il invalident paquet corps A.

la séquence correcte pour le déploiement est:

create or replace Package A ...; 
create or replace Package B ...; 
create or replace Package C ...; 
create or replace Package Body A ...; 
create or replace Package Body B ...; 
create or replace Package Body C ...; 

S'il n'y a pas eu des changements dans le paquet lui-même alors e Bien sûr, il n'est pas nécessaire de le déployer.Le respect de ces méthodes devrait vous donner beaucoup moins d'objets non valides.

+0

Un paquet peut dépendre d'un autre paquet, si par exemple s'il fait référence à des types déclarés dans une autre spécification de paquet. –

+0

Oui, absolument. Je pense que cela souligne l'importance d'empaqueter le code et de compiler les paquets avant les corps de paquet, à moins que vous pensiez à un problème différent? –

1

emballage têtes premiers:

for i in $(ls *.hed); do sqlplus user/password @$i; done 

Ensuite, emballez le corps:

for i in $(ls *.hed); do sqlplus user/password @$i; done