Erreurs : ORA-00942

Lors de l’exploitation d’une base de données Oracle dans un environnement de production, certaines erreurs peuvent survenir avec une criticité plus ou moins importante. Nous allons voir dans cet article, la gestion d’une erreur spécifique, mais qui n’implique pas forcément une erreur importante : ORA-00942.

Nous constatons, toujours dans notre cas d’étude, que cette erreur survient notamment lors de l’exécution de SQL tels que utlrp.sql, etc…

    • ORA-00942
  • Analysons donc l’erreur survenue : ORA-00942 : Table ou vue inexistante.
    ORACLE:/home/oracle $ oerr ora 942
    00942, 00000, "table or view does not exist"
    // *Cause: The table or view entered does not exist, a synonym that is not allowed here was used,
    or a view was referenced where a table is required. Existing user tables and views can be
    listed by querying the data dictionary. Certain privileges may be required to access the
    table. If an application returned this message, the table the application tried to access
    does not exist in the database, or the application does not have access to it.
    // *Action: Check each of the following:
    - The spelling of the table or view name.
    - That a view is not specified where a table is required.
    - That an existing table or view name exists.
    Contact the database administrator if the table needs to be created or if user or
    application privileges are required to access the table. Also, if attempting to access a
    table or view in another schema, make certain the correct schema is referenced and that
    access to the object is granted.

    Nous remarquons donc, que cette erreur peut survenir sur bien des cas différents et ne se réfère pas qu’à un seul problème. Si comme nous l’avons expliqué en début d’article, cette erreur peut survenir lors de l’utilisation de scripts directement issus de la souche Oracle et peuvent être ignorés (dans certains cas, ne l’oublions pas); elle peut également apparaître suite à certaines opérations :

    1. Le nom du propriétaire de la table n’a pas été spécifié lors de la connexion en tant que non-propriétaire de la table.
    2. L’erreur survient lors de l’import (imp ou impdp).
    3. L’erreur survient lors du rafraîchissement des vues matérialisées.

    Toutefois, l’erreur ORA-00942 lors d’un insert est commune quand l’utilisateur avec lequel on est connecté n’a pas les droits pour voir la table. De plus, certains ont rencontré l’erreur ORA-00942 lors d’un import (comme listé précédemment), il s’agit d’une erreur dans les tables qui sont importées.

    Sur ce dernier point, le support Oracle donne de bonnes informations sur l’erreur ORA-00942 qui survient suite à un import. En effet, le système cherche à trouver la table parente et la lier à une autre table. Pour résoudre ce problème, le support indique de procéder de la manière suivante :

    1. Utiliser la directive Show = Y pour voir ce que va effectuer l’import (il s’agit d’une simulation).
    2. Ainsi, l’administrateur pourra vérifier si la table importé a une contrainte qui empêche l’action. On peut également ajouter l’option log = pour créer un fichier d’import qui comportera toutes les informations relatives à notre import.

    3. Importer la table en utilisant les options Show = N et Rows = N. Ceci importera seulement la structure de la table.
    4. Désactiver toutes les contraintes sur les nouvelles tables.
    5. Une fois l’import effectué, réactiver les contraintes.

    6. Importer la table avec l’option Ignore = Y pour éviter que l’erreur ne soit remontée.

    Il se peut également que l’erreur ORA-00942 survienne sur une vue matérialisée. Cette erreur peut apparaître lors de l’utilisation de dbms_view.refresh :

    begin dbms_mview.refresh('STATUS_REP'); end;
    *
    ERROR at line 1:
    ORA-00942: table or view does not exist
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 617
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 674
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 654
    ORA-06512: at line 1

    Dans ce cas précis, on ne peut dire quelle est la table qui remonte l’erreur. L’utilisateur devra donc activer une trace SQL (TKPROF) au niveau de la session pour déterminer exactement quelle table renvoie cette erreur.

    Lien pour marque-pages : Permaliens.

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *