En général, cela n'est probablement pas possible.
En théorie, si vous étiez vraiment déterminé, vous pouvez générer l'audit à grains fins (FGA) déclenche pour chaque table dans votre système qui se déclenche pour chaque SELECT, INSERT, UPDATE et DELETE, obtenir le SQL_ID de V$SESSION, joignez-vous à V$SQL_PLAN, et implémente la logique que vous voulez. C'est techniquement possible, mais cela impliquerait un peu de code et vous ajouteriez une charge potentiellement décente à chaque requête de votre système. Ce n'est probablement pas pratique.
Plutôt que d'essayer d'utiliser un déclencheur, vous pouvez écrire une procédure qui devait exécuter toutes les quelques minutes via les DBMS_JOB ou DBMS_SCHEDULER paquets qui interrogerait V$SESSION pour toutes les sessions actives, joint à V$SQL_PLAN, et mis en œuvre quelle que soit la logique que vous vouliez . Cela élimine la surcharge d'essayer d'exécuter un déclencheur chaque fois qu'un utilisateur exécute une instruction. Mais il implique toujours une quantité décente de code. Au lieu d'écrire du code, en fonction du problème que vous essayez de résoudre, il peut être plus facile de créer resource limits on the user's profile pour qu'Oracle impose des limites sur la quantité de ressources qu'une seule instruction SQL peut consommer. Par exemple, vous pouvez définir CPU_PER_CALL, LOGICAL_READS_PER_CALL ou COMPOSITE_LIMIT de l'utilisateur pour limiter la quantité de CPU, la quantité d'E/S logiques ou la limite composite d'UC et d'E/S logiques qu'une seule instruction peut faire avant qu'Oracle ne la tue .
Si vous voulez encore plus de contrôle, vous pouvez utiliser Oracle Resource Manager. Cela peut vous permettre d'empêcher Oracle d'exécuter des requêtes auprès de certains utilisateurs si leur exécution est estimée trop longue ou de limiter les ressources qu'un groupe d'utilisateurs peut consommer en cas de conflit sur ces ressources. Oracle peut automatiquement déplacer des requêtes de longue durée d'utilisateurs spécifiques vers des groupes de priorité inférieure, il peut tuer automatiquement des requêtes de longue durée, il peut les empêcher de s'exécuter en premier lieu, ou n'importe quelle combinaison de ces éléments.
merci cela m'a ouvert l'esprit de penser différemment. Puis-je demander comment est-ce possible que des applications comme Toad et SQL Developer peuvent et l'utilisateur comme moi Cant. ou est-ce quelque chose que vous avez déjà mentionné que j'ai besoin d'un très gros morceau de code pour cela. – Imran
@Imran - Rien ne vous empêche d'accéder au plan de requête (bien que ce soit beaucoup plus facile avec une session séparée, ce que font Toad et SQL Developer). Vous pouvez joindre 'V $ SESSION' à' V $ SQL_PLAN' sur 'SQL_ID' et voir le plan de requête pour l'instruction SQL en cours d'exécution dans chaque session - c'est ce que vous feriez si vous écriviez un travail planifié. C'est juste que vous devez écrire la logique pour analyser le plan de requête et que la plupart des problèmes que les gens veulent résoudre dans cet espace général sont mieux résolus en utilisant des profils et/ou le gestionnaire de ressources. –
Merci Vraiment Apprécié pour la réponse – Imran