2010-09-21 4 views
1

J'écris un analyseur PL/SQL pour identifier les opérations (Select, Insert, Delete) effectuées sur la table lorsque j'exécute la procédure, la fonction ou le package. OBJECTIF: I But de cet outil est d'identifier quelles tables seront affectées par l'exécution de la procédure, amusant de préparer avec un meilleur cas de test.Analyseur PL/SQL pour identifier l'opération sur la table

Toutes les meilleures idées ou un outil aidera vraiment beaucoup.

INPUT: certains fichier SQL avec procédure

 or proc file. 

SORTIE requise est:

SELECT de: first_table, secondTable

-> Dans la procédure XYZ est --Ce si la procédure est appel d'une procédure supplémentaire

INSERT dans: SomeTable

INSERT dans: SomeDiffTable

-> FIN de la procédure XYZ --Fin d'une procédure supplémentaire.

SUPPRIMER de: xyzTable

INSERT dans: OnemoreTable

Mon exigence est quand je suis analyse porc1 si elle appelle une autre PROC2. Je dois aller à l'intérieur que PROC2 pour savoir ce que toute l'opération est réalisée en cela et revenir à PROC1 et continuer .:

Pour cela, je dois stocker les quelques-uns toutes les procédures d'où et lors de l'analyse je dois vérifier chaque jeton (mot avec espace) dans le tempStorage pour savoir s'il s'agit d'une procédure ou non.

Comme ma logique prend beaucoup de temps. Quelqu'un peut-il suggérer une meilleure logique pour atteindre mon objectif.

Répondre

2

Il y a aussi la possibilité de déclencher des déclencheurs. Cela ajoute une couche supplémentaire de complexité.

Je dirais qu'il vaut mieux extraire DBA_DEPENDENCIES avec une requête récursive pour déterminer l'analyse d'impact dans l'abstrait; il ne capture pas le SQL dynamique, mais rien ne le fera à 100% du temps. Dans votre cas, proc1 dépend de proc2, et proc2 dépend de tout ce qui en dépend, et ainsi de suite. Il ne vous dira pas la nature de la dépendance - INSERT, UPDATE, DELETE, SELECT - mais c'est un début.

Si vous êtes vraiment intéressés à déterminer l'impact réel d'une course-valeur unique variable d'une procédure, la mise en œuvre dans un système non-production, puis activez l'audit sur votre système jusqu'à 11:

begin 
    for i in (select owner, object_type, object_name from dba_objects 
      where owner in ([list of application schemas] 
       and object_type in ('TABLE', 'PACKAGE', 'PROCEDURE', 'FUNCTION', 'VIEW') 
    loop 
    execute immediate 'AUDIT ALL ON ' || i.owner || '.' || i.object_type || 
         ' BY SESSION'; 
    end loop; 
end; 
/

Exécutez votre test et voyez quels objets ont été touchés à la suite de l'exécution en explorant la piste d'audit. Ce n'est pas à toute épreuve, car il ne vérifie que les objets qui ont été touchés par cette exécution, mais il vous dit comment ils ont été touchés.