V$SQL_PLAN : à historiser?

Bonjour les experts,

Pour des raisons d'analyse et d'historique, je voudrais copier le contenu de la vue V$SQL_PLAN dans une table créée par mes soins (même structure que V$SQL_PLAN) car V$SQL_PLAN est réinitialisée lors des arrêts/relances. Le problème est que je comptais faire un trigger en remplacement de l'INSERT sur V$SQL_PLAN mais les triggers sur vue se substituant à l'évènement déclencheur, ça veut dire que ma table sera remplie MAIS l'insert dans V$SQL_PLAN n'aura plus lieu : ce qui n'est pas envisageable!

Je comptais alors faire un trigger sur un évènement système, du genre After logon, pour synchroniser ces deux tables. Néanmoins cette situation ne me satisfait pas pleinement d'un point de vue intellectuel, je préfèrerais vraiment copier ces données dès qu'elles sont insérées dans V$SQL_PLAN.

Est-ce que vous auriez une idée?

Les tables V$_ sont des structures de mémoire...

Est-ce que tu as éssayé l'outil export datapump sur cette tables, et si c'est ok,
tu peux programmer un job pour n'inserer que les enregistrement recents ?

bonne chance

j'ai oublié de te dire aussi que tu peux créer un trigger system de type BEFORE SHUTDOWN, et
mettre un code d'insertions des enregistrements du contenu de v$sql_plan depuis le dernier démarrage de l'instance !

Pourvu qu'ils soient resté en mémoire depuis le dernier démarrage de l'instance...

mnitu, je suis d'accord, V$SQL_PLAN est un synonyme sur V_$SQL_PLAN si je ne me trompe et qui pointe vers des X$ qui sont effectivement des structures mémoires.
Néanmoins, avec SQL Developer, on me propose V$SQL_PLAN dans la liste des vues sur lesquelles je peux créer un trigger. Néanmoins je ne suis pas allé au bout puisque cette solution ne me satisfait plus.

Merci pour le conseil dell68, mais ce week-end je vais essayer de faire plutôt un trigger sur AFTER LOGON et n'insérer que les nouveaux enregistrements depuis le dernier LOGON.

Citation:

---

Envoyé par Ikebukuro

Néanmoins, avec SQL Developer, on me propose V$SQL_PLAN dans la liste des vues sur lesquelles je peux créer un trigger.

---

On vous propose mais c'est juste pour s'amuser. Avez-vous essayé ? Sinon avec votre nouveau trigger c'est à peu prés la même chose : "Pourvu qu'ils soient resté en mémoire ..."

A la limite vous pouvez vous inspirer du mécanisme utilisé par ASH qui se base sur un échantillonnage périodique si je ne m'abuse pas.

Bonjour,
V$SQL_PLAN est automatiquement historisé avec AWR (si diagnostic pack) ou Statspack (level 7). C'est fait pour. Il ne manque que les predicats.
Cordialement,
Franck.

Alors pourquoi compliquer, puis que oracle le fait déjà cette historisation !

Parce que pour utiliser AWR, comme le dit Pachot, il faut avoir le Diagnostic Pack qui n'est pas gratuit.
Quant à Statspack je ne connais pas mais quelque chose me dit qu'il n'est pas simple à utiliser et que c'est une boite noire.

En outre, en essayant de faire les choses par moi-même, j'ai découvert le message d'erreur suivant en voulant créer sous SQL*Plus un trigger sur V_$SQL_PLAN :

Code:

---

1 2 3 4 5 6

SQL> CREATE OR REPLACE TRIGGER TRIGGER1 INSTEAD OF INSERT ON V_$SQL_PLAN BEGIN dbms_output.put_line ('TEST'); END; 2 / CREATE OR REPLACE TRIGGER TRIGGER1 INSTEAD OF INSERT ON V_$SQL_PLAN BEGIN dbms_output.put_line ('TEST'); END; * ERREUR à la ligne 1 : ORA-04089: impossible créer déclencheurs sur objets appartenant à SYS

---

Citation:

---

Envoyé par Ikebukuro

Quant à Statspack je ne connais pas mais quelque chose me dit qu'il n'est pas simple à utiliser et que c'est une boite noire.

---

C'est tout le contraire. Statspack est très bien documenté (spdoc.txt dans ORACLE_HOME/rdbms/admin), tout simple à installer et à utiliser. Et tout le code est visible (package PL/SQL non wrappé et scripts sqlplus).
L'avantage: il a été fait par les développeurs oracle, qui connaissent le mieux les statistiques qu'on trouve dans V$SQL_PLAN
Plus d'info sur Statspack: http://viewer.zmags.com/publication/...b#/dd9ed62b/36

Vouloir mettre des triggers sur les tables du dictionnaire est très dangereux. Les vues V$ ne sont pas des tables mais des vues sur des structures internes. elles ne sont pas mises à jour en SQL, donc pas de triggers. Et attention, les lectures vont poser des latch sur les structures internes de mémoire, qui peuvent avoir des conséquences néfaste sur la base. Mieux vaut s'appuyer sur un mécanisme existant, développé par oracle et qui fontionne depuis des années.

Capturer les plan d'exécution n'est pas simple. Les plans peuvent rester en cache 2 secondes ou un mois.

Citation:

---

V$SQL_PLAN est réinitialisée lors des arrêts/relances

---

Non. C'est une vue sur des structures mémoires très dynamique. Bien sûr elle est vide au démarrage de l'instance, vu que la mémoire est initialisée à ce moment là, mais rien n'est historisé ensuite. Même listant V$SQL_PLAN toutes les secondes (et je vous déconseille de faire ça!) on pas à côté à beaucoup de curseurs.