Gérer les dépendances

<Lesson Title>Gérer les dépendances
Objectifs
effectuer le suivi des dépendances procédurales
prédire les conséquences de la modification d'un objet de base de données sur des fonctions et des procédures stockées
gérer des dépendances procédurales
But du chapitre
Ce chapitre décrit les dépendances d'objet, ainsi que la recompilation implicite et explicite d'objets non valides.
11-*
Comprendre les dépendances
Objets dépendants et référencés
Certains objets font référence à d'autres objets dans le cadre de leur définition. Ainsi, une procédure stockée pourra contenir une instruction SELECT chargée de sélectionner les colonnes d'une table. Dans ce cas, la procédure stockée est appelée objet dépendant, tandis que la table est qualifiée d'objet référencé.
Problèmes liés aux dépendances
Si vous modifiez la définition d'un objet référencé, il se peut que les objets dépendants ne fonctionnent plus correctement. Dans l'exemple de la diapositive, toute modification de la définition de la table peut entraîner une erreur de fonctionnement au niveau de la procédure.
Le serveur Oracle enregistre automatiquement les dépendances entre les objets. Pour permettre la gestion des dépendances, tous les objets du schéma disposent d'un état (VALID ou INVALID) enregistré dans le dictionnaire de données. La vue du dictionnaire de données USER_OBJECTS permet de visualiser cet état.
Etat
Sens
VALID
L'objet de schéma a été compilé et peut être utilisé immédiatement lorsqu'il est référencé.
INVALID
L'objet de schéma doit être compilé avant de pouvoir être utilisé.
11-*
Dépendances
Dépendante
Référencée
Dépendante
Référencée
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
Procédure
Objets dépendants et objets référencés (suite)
Une procédure ou une fonction peut référencer de manière directe ou indirecte (par l'intermédiaire d'une vue, d'une procédure, d'une fonction, d'une procédure de package ou d'une fonction de package) les objets suivants :
tables
vues
séquences
procédures
fonctions
11-*
Dépendances locales
Gérer les dépendances locales
Dans le cas des dépendances locales, les objets sont situés sur le même noeud dans la même base de données. Le serveur Oracle gère automatiquement toutes les dépendances locales à l'aide de la table des dépendances internes (depends-on table) de la base de données. Lorsqu'un objet référencé est modifié, les objets dépendants sont invalidés. Lors de l'appel suivant de l'objet invalidé, le serveur Oracle le recompile automatiquement.
11-*
Dépendances locales
INVALID
INVALID
INVALID
Le serveur Oracle recompile implicitement tout objet INVALID lorsque ce dernier est de nouveau appelé
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
vvvvvvvvvvvvvv
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
xxxxxxxxxxxxxx
vvvvvvvvvvvvvv
Gérer les dépendances locales (suite)
Supposons qu'il y ait une modification de la structure de la table sur laquelle une vue est basée. Lorsque vous décrivez la vue à l'aide de la commande iSQL*Plus DESCRIBE, vous recevez un message d'erreur indiquant que l'objet ne peut pas être décrit en raison de son caractère non valide. La raison en est simple : la commande en question n'est pas une commande SQL et, à ce stade, la vue n'est pas valide car la structure de sa table de base a changé. Si vous interrogez la vue à présent,
celle-ci est recompilée automatiquement et affiche un résultat en cas de succès.
11-*
Scénario de dépendances locales
La procédure QUERY_EMP référence directement la table EMPLOYEES. La procédure ADD_EMP met à jour indirectement la table EMPLOYEES, à l'aide de la vue EMP_VW.
Dans chacun des cas ci-dessous, la procédure ADD_EMP sera-t-elle invalidée ? Sera-t-elle recompilée avec succès ?
1. La logique interne de la procédure QUERY_EMP est modifiée.
2. Une nouvelle colonne est ajoutée à la table EMPLOYEES.
3. La vue EMP_VW est supprimée.
11-*
SELECT name, type, referenced_name, referenced_type
FROM user_dependencies
Afficher les dépendances directes en utilisant USER_DEPENDENCIES
Définissez les objets de base de données à recompiler manuellement en affichant les dépendances directes à partir de la vue du dictionnaire de données USER_DEPENDENCIES.
Examinez les vues ALL_DEPENDENCIES et DBA_DEPENDENCIES ; chacune d'elles contient une colonne supplémentaire, OWNER, référençant le propriétaire de l'objet.
Colonne
Type de l'objet dépendant (PROCEDURE, FUNCTION, PACKAGE, PACKAGE BODY, TRIGGER ou VIEW)
REFERENCED_OWNER
Lien de base de données permettant d'accéder à l'objet référencé
11-*
Afficher les dépendances directes et indirectes
1. Exécuter le script utldtree.sql pour créer les objets permettant d'afficher les dépendances directes et indirectes
2. Exécuter la procédure DEPTREE_FILL
EXECUTE deptree_fill('TABLE','SCOTT','EMPLOYEES')
Afficher les dépendances directes et indirectes à l'aide des vues fournies par Oracle
DEPTREE et IDEPTREE sont des vues utilisateur supplémentaires fournies par Oracle, qui permettent d'afficher les dépendances directes et indirectes.
Exemple
1. Assurez-vous que le script utldtree.sql s'est correctement exécuté. Il se trouve dans le dossier $ORACLE_HOME/rdbms/admin. (Il est fourni dans le dossier lab des fichiers de cours.)
2. Entrez dans la table DEPTREE_TEMPTAB les informations relatives à un objet référencé particulier en appelant, à cette fin, la procédure DEPTREE_FILL. Cette procédure admet trois paramètres :
object_type
object_owner
object_name
11-*
Afficher les dépendances
Exemple
Affichez une représentation sous forme de tableau de tous les objets dépendants en interrogeant la vue DEPTREE.
Affichez une représentation avec indentation de ces mêmes informations en interrogeant la vue IDEPTREE. Cette dernière se compose d'une seule colonne nommée DEPENDENCIES.
Par exemple,
FROM ideptree;
fournit une seule colonne de résultats avec indentation qui présente les dépendances sous forme de structure hiérarchique.
11-*
Autre scénario de dépendances locales
Table EMPLOYEES
Exemple 1
Prévoyez les effets induits par une modification de la définition d'une procédure sur la recompilation d'une procédure dépendante.
Supposons que la procédure RAISE_SAL mette à jour directement la table EMPLOYEES, et que la procédure REDUCE_SAL mette à jour indirectement la table EMPLOYEES à l'aide de RAISE_SAL.
Dans chacun des cas suivants, la procédure REDUCE_SAL sera-t-elle recompilée avec succès ?
1. La logique interne de la procédure RAISE_SAL est modifiée.
2. L'un des paramètres formels de la procédure RAISE_SAL est éliminé.
11-*
Scénario de dépendances de résolution de noms locale
QUERY_EMP
procédure
Prévoir les effets des modifications sur les objets dépendants (suite)
Exemple 2
Il est un cas où la création d'une table, d'une vue ou d'un synonyme peut invalider de façon imprévisible un objet dépendant parce qu'il perturbe la hiérarchie du serveur Oracle en ce qui concerne la résolution des références de nom.
Prévoyez l'effet qu'aura le nom d'un nouvel objet sur une procédure dépendante.
Supposons que la procédure QUERY_EMP référençait initialement un synonyme public nommé EMPLOYEES. Cependant, vous venez de créer une table EMPLOYEES dans votre propre schéma. Cette modification invalidera-t-elle la procédure ? Lequel des deux objets EMPLOYEES la procédure QUERY_EMP référencera-t-elle après sa recompilation ?
Supposons maintenant que vous supprimiez la table privée EMPLOYEES. Cela invalidera-t-il la procédure ? Que se passera-t-il lors de la recompilation de la procédure ?
Vous pouvez effectuer le suivi des dépendances de sécurité dans la vue du dictionnaire de données USER_TAB_PRIVS.
11-*
Comprendre les dépendances distantes
Comprendre les dépendances distantes
Dans le cas des dépendances distantes, les objets sont situés sur des noeuds différents. En ce qui concerne les dépendances entre les objets de schéma distants, le serveur Oracle gère uniquement les dépendances de type "procédure locale vers procédure distante" (y compris les fonctions, les packages et les déclencheurs). La procédure stockée locale et tous les objets dépendants seront invalidés, mais ne seront pas recompilés automatiquement lors du premier appel les concernant.
11-*
Comprendre les dépendances distantes
Recompilation des objets dépendants : locaux et distants
Assurez-vous que la recompilation explicite des procédures dépendantes distantes et la recompilation implicite des procédures dépendantes locales se sont déroulées avec succès. Pour ce faire, vérifiez l'état des procédures dans la vue USER_OBJECTS.
Si la recompilation implicite et automatique des procédures dépendantes locales s'avère infructueuse, l'état reste non valide et le serveur Oracle renvoie une erreur lors de l'exécution. Aussi, pour éviter toute interruption de la production, est-il vivement conseillé de recompiler manuellement les objets dépendants locaux, plutôt que de recourir à un mécanisme automatique.
11-*
Concepts des dépendances distantes
choisi par l'utilisateur :
vérification d'horodatage (TIMESTAMP)
Vérification d'horodatage (TIMESTAMP)
Chaque programme PL/SQL comporte un horodatage défini lors de sa phase de création ou de recompilation. Lorsque vous modifiez un programme PL/SQL ou un objet de schéma associé, tous les programmes dépendants sont marqués comme étant non valides et doivent être recompilés avant de pouvoir s'exécuter. La comparaison d'horodatage effective a lieu lorsqu'une instruction figurant dans le corps d'une procédure locale appelle une procédure distante.
Vérification de signature (SIGNATURE)
La date, l'heure et la signature sont enregistrées pour chaque programme PL/SQL. La signature d'une structure PL/SQL contient des informations sur les éléments suivants :
le nom de la structure (procédure, fonction, package),
les types de base des paramètres de la structure,
les modes des paramètres (IN, OUT ou IN OUT),
le nombre des paramètres.
L'horodatage du programme appelant est comparé à celui du programme distant appelé. Si les valeurs correspondent, l'appel s'effectue normalement. Dans le cas contraire, la couche des appels RPC (Remote Procedure Call) effectue un test simple visant à comparer la signature et à déterminer si l'appel est sécurisé ou non. Si la signature n'a subi aucune modification de nature à affecter sa compatibilité, l'exécution se poursuit ; dans le cas contraire, une erreur est renvoyée.
11-*
Paramètre REMOTE_DEPENDENCIES_MODE
Définir REMOTE_DEPENDENCIES_MODE :
REMOTE_DEPENDENCIES_MODE = value
Définir le paramètre REMOTE_DEPENDENCIES_MODE
11-*
Dépendances distantes
et horodatage
Utilisation de l'horodatage pour la recompilation automatique des objets locaux et distants
Si des valeurs d'horodatage sont utilisées pour traiter les dépendances entre des programmes PL/SQL, chaque fois que vous modifiez un programme ou un objet de schéma associé, tous les programmes dépendants sont marqués comme étant non valides et doivent être recompilés avant de pouvoir s'exécuter.
11-*
Dépendances distantes
et horodatage
Utilisation de l'horodatage pour la recompilation automatique des objets locaux et distants
Dans l'exemple présenté sur la diapositive, la définition de la table est modifiée. Par conséquent, tous les programmes dépendants sont marqués comme étant non valides et doivent être recompilés avant de pouvoir s'exécuter.
En cas de modification d'objets distants, il est vivement conseillé de recompiler manuellement les objets dépendants locaux pour éviter toute interruption de la production.
Le mécanisme de dépendance distante est différent du mécanisme local décrit précédemment. La première fois qu'un sous-programme distant recompilé est appelé par un sous-programme local, le système renvoie une erreur lors de l'exécution et le sous-programme local est invalidé ; lors de l'appel suivant, une recompilation implicite est effectuée automatiquement.
11-*
Compilation de la procédure distante B
à 8H00
Procédures locales référençant des procédures distantes
Le serveur Oracle invalidera toute procédure locale référençant une procédure distante si la recompilation de cette dernière est postérieure à la compilation de la procédure locale.
Mécanisme de dépendance distante automatique
Lors de la compilation d'une procédure, le serveur Oracle enregistre les valeurs d'horodatage de la compilation dans le pseudo-code de la procédure.
Sur la diapositive, lorsque la procédure distante B est correctement compilée à 8h00, cette heure est enregistrée comme valeur d'horodatage.
11-*
Compilation de la procédure locale A
à 9H00
Mécanisme de dépendance distante automatique
Lors de la compilation d'une procédure locale faisant référence à une procédure distante, le serveur Oracle enregistre également l'horodatage de la procédure distante dans le pseudo-code de la procédure locale.
Sur la diapositive, la procédure locale A, qui est dépendante de la procédure distante B, est compilée à 9H00. Les valeurs d'horodatage de la procédure locale A et de la procédure distante B sont enregistrées dans le pseudo-code de la procédure A.
11-*
Exécution de la procédure A
Procédure locale A
Dépendance distante automatique
Lorsque la procédure locale est appelée, le serveur Oracle compare lors de l'exécution les deux valeurs d'horodatage de la procédure distante référencée.
Si ces valeurs sont identiques (indiquant ainsi que la procédure distante n'a pas été recompilée), le serveur Oracle exécute la procédure locale.
Dans l'exemple présenté sur la diapositive, l'horodatage enregistré dans le pseudo-code de la procédure distante B est identique à celui enregistré dans la procédure locale A. Par conséquent, la procédure locale A est valide.
11-*
Recompilation de la procédure distante B à 11H00
Valide
Procédures locales référençant des procédures distantes
Supposons que la recompilation de la procédure distante B se soit correctement effectuée à 11H00. Sa nouvelle valeur d'horodatage est enregistrée dans le pseudo-code.
11-*
Exécution de la procédure A
Procédure locale A
Dépendance distante automatique
Si les valeurs d'horodatage sont différentes (indiquant ainsi que la procédure distante a été recompilée), le serveur Oracle invalide la procédure locale et renvoie une erreur lors de l'exécution.
Si la procédure locale, désormais marquée comme étant non valide, est appelée une seconde fois, le serveur Oracle la recompile avant de l'exécuter, conformément au mécanisme de dépendance locale automatique.
Remarque : Si une procédure locale renvoie une erreur lors de l'exécution la première fois qu'elle est appelée (indiquant ainsi une modification de l'horodatage de la procédure distante), il convient de mettre au point une stratégie permettant d'appeler à nouveau la procédure locale.
Dans l'exemple présenté sur la diapositive, la procédure distante est recompilée à 11H00. Cette heure est enregistrée en tant que valeur d'horodatage dans le pseudo-code. Le pseudo-code de la procédure locale A indique toujours 8H00 comme valeur d'horodatage pour la procédure distante B.
L'horodatage enregistré dans le pseudo-code de la procédure locale A diffère de celui enregistré dans la procédure distante B. Par conséquent, la procédure locale est marquée comme étant non valide. Lorsque la procédure locale est appelée pour la seconde fois, elle est correctement compilée et est marquée comme étant valide.
Inconvénients liés à l'horodatage
L'horodatage a pour inconvénient d'être un mode trop rigide. La recompilation d'objets dépendants sur le réseau s'effectue souvent alors qu'elle n'est pas strictement nécessaire, ce qui entraîne une dégradation des performances.
11-*
Mode signature
les types de données des paramètres
les modes des paramètres
La signature de la procédure distante est enregistrée dans la procédure locale.
Lors de l'exécution d'une procédure dépendante, la signature de la procédure distante référencée est comparée.
Signatures
Le mode signature vous permet d'atténuer certains problèmes associés au modèle de dépendance basé uniquement sur l'horodatage. Il permet de recompiler la procédure distante sans affecter les procédures locales, ce qui revêt une importance toute particulière si la base de données est distribuée.
La signature d'un sous-programme contient les informations suivantes :
le nom du sous-programme,
les modes des paramètres,
le nombre des paramètres,
le type de données de la valeur renvoyée pour une fonction.
Si un programme distant est modifié et recompilé, et si la signature ne subit aucun changement, la procédure locale pourra exécuter la procédure distante. En mode horodatage, une erreur aurait été générée du fait de la non-correspondance des valeurs d'horodatage.
11-*
Recompilation
La recompilation :
est traitée automatiquement par le biais d'une recompilation implicite lors de l'exécution
est traitée par le biais d'une recompilation explicite avec l'instruction ALTER
ALTER PROCEDURE [SCHEMA.]procedure_name COMPILE;
ALTER FUNCTION [SCHEMA.]function_name COMPILE;
ALTER PACKAGE [SCHEMA.]package_name COMPILE [PACKAGE];
ALTER PACKAGE [SCHEMA.]package_name COMPILE BODY;
ALTER TRIGGER trigger_name [COMPILE[DEBUG]];
Recompilation d'objets PL/SQL
Si la recompilation aboutit, l'objet devient valide. Sinon, le serveur Oracle renvoie une erreur et l'objet reste non valide.
Lorsque vous recompilez un objet PL/SQL, le serveur Oracle commence par recompiler tous les objets invalides dont il dépend.
Procédure
Tout objet local dépendant d'une procédure sera également invalidé (procédures qui appellent la procédure compilée ou corps de package qui définissent les procédures appelant la procédure recompilée, par exemple).
Packages
L'option COMPILE PACKAGE recompile la spécification et le corps du package, qu'il soit valide ou non. Quant à l'option COMPILE BODY, elle recompile uniquement le corps du package.
La recompilation d'une spécification de package invalide tout objet local dépendant de la spécification ; c'est le cas par exemple des procédures appelant d'autres procédures ou fonctions du package. Notez que le corps d'un package dépend également de sa spécification.
11-*
Recompilation d'un programme PL/SQL
est traitée automatiquement par le biais d'une recompilation implicite lors de l'exécution
est traitée par le biais d'une recompilation explicite avec l'instruction ALTER
ALTER PROCEDURE [SCHEMA.]procedure_name COMPILE;
ALTER FUNCTION [SCHEMA.]function_name COMPILE;
ALTER PACKAGE [SCHEMA.]package_name COMPILE [PACKAGE];
ALTER PACKAGE [SCHEMA.]package_name COMPILE BODY;
ALTER TRIGGER trigger_name [COMPILE[DEBUG]];
Recompilation d'objets PL/SQL (suite)
Déclencheurs
La recompilation explicite évite la recompilation implicite lors de l'exécution et les erreurs de compilation associées, tout en empêchant une réduction des performances.
L'option de débogage (DEBUG) indique au compilateur PL/SQL de générer et de stocker le code utilisé par le programme de débogage PL/SQL.
11-*
Echec de la recompilation
dépendantes échouera dans les cas suivants :
l'objet référencé a été supprimé ou renommé
le type de données de la colonne référencée a été modifié
la colonne référencée a été supprimée
une vue référencée a été remplacée par une vue avec des colonnes différentes
la liste des paramètres d'une procédure référencée a été modifiée
Echec de la recompilation
Il arrive que la recompilation des procédures dépendantes n'aboutisse pas ; c'est le cas lorsqu'une table référencée est supprimée ou renommée.
Le succès d'une recompilation repose sur une dépendance parfaite. Si une vue référencée est recréée, tout objet dépendant devra être recompilé. Le succès de la recompilation dépend des colonnes présentes dans la vue, ainsi que des colonnes dont les objets dépendants ont besoin pour leur exécution. Si les colonnes requises ne font pas partie de la nouvelle vue, l'objet restera non valide.
11-*
Recompilation réussie
dépendantes réussira dans les cas suivants :
la table référencée comporte de nouvelles colonnes
le type de données des colonnes référencées n'a pas été modifié
une table privée a été supprimée, mais il existe une table publique avec les mêmes nom et structure
le corps PL/SQL d'une procédure référencée a été modifié et recompilé avec succès
Recompilation réussie
de nouvelles colonnes sont ajoutées à une table référencée,
toutes les instructions INSERT contiennent une liste de colonnes,
aucune nouvelle colonne n'est définie comme étant NOT NULL.
En cas de suppression d'une table privée référencée par une procédure dépendante, l'état de la procédure dépendante devient non valide. Si la procédure est recompilée, soit explicitement, soit implicitement, et s'il existe une table publique, la compilation pourra réussir, mais la procédure deviendra dépendante de la table publique. La recompilation aboutira uniquement si la table publique contient les colonnes dont la procédure a besoin ; dans le cas contraire, l'état de la procédure restera non valide.
11-*
Recompilation des procédures
infructueuses en :
effectuant des interrogations à l'aide de la notation SELECT *
ajoutant une liste de colonnes aux instructions INSERT
Recompilation des procédures
Vous pouvez réduire le nombre des échecs de recompilation en suivant les règles présentées sur la diapositive.
11-*
Packages et dépendances
Gestion des dépendances
Vous pouvez simplifier considérablement la gestion des dépendances associée aux packages lorsque vous référencez une fonction ou une procédure de package depuis une fonction ou une procédure autonome :
Si le corps du package est modifié mais pas sa spécification, la procédure autonome qui référence la structure du package reste valide.
Si la spécification du package est modifiée, la procédure externe qui référence une structure de package est invalidée, au même titre que le corps du package.
11-*
Packages et dépendances
Gestion des dépendances (suite)
Si une procédure autonome référencée dans le package est modifiée, tout le corps du package est invalidé ; cependant, sa spécification reste valide. Par conséquent, il est vivement conseillé d'intégrer la procédure au package.
11-*
Synthèse
effectuer le suivi des procédures dépendantes
recompiler les procédures manuellement dès que possible après la modification de la définition d'un objet de base de données
Synthèse du chapitre
Pour éviter toute interruption de la production, effectuez le suivi des procédures dépendantes et recompilez-les manuellement, dès que possible, après la modification de la définition d'un objet de base de données.
Situation
La procédure dépend d'un objet local
Oui, lors de la première réexécution
La procédure dépend d'une procédure distante
Oui, mais lors de la seconde réexécution ; effectuez une recompilation manuelle lors de la première réexécution, ou appelez-la une seconde fois
La procédure dépend d'un objet distant autre qu'une procédure
Non
11-*
Présentation de l'exercice 11
utiliser DEPTREE_FILL et IDEPTREE pour visualiser les dépendances
recompiler des procédures, des fonctions et des packages
Présentation de l'exercice 11
Dans cet exercice, vous allez utiliser la procédure…