Ca veut bien dire ce que ca veut dire !
Une fois les policies créées,  les packages et fonctions testées, l’utilisation implicite des polices (par un SELECT sur la table sécurisée par exemple) peut renvoyer cette erreur.

Une xeception est arrivée lors de l’execution qui n’est pas ‘attrapée’ par le programme et remonte donc au noyau. Reste à savoir quelle exception et pourquoi…

Pour avoir plus d’infos, il faut voir le fichier trace *ora*.trc généré dans USER_DUMP_DEST!!!!!!
Voici un exemple de contenu de trace intéressant (chercher éventuellement la chaine ORA-28112 si le fichier est trop gros)

srv-test$ > more pprun_ora_237820.trc
Dump file /work/oracle/log/prod_ora_237820.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /oracle/10GDB
System name: AIX
Node name: sr-pprod-1
Release: 3
Version: 5
Machine: 005F0ADA4C00
Instance name: prod
Redo thread mounted by this instance: 1
Oracle process number: 23
———————————————————-
Policy function execution error:
Logon user : SYSTEM
Table/View : SC1.CONTROLE
Policy name : SC1_APP_RESTRICT
Policy function: SYSTEM.PK_SET_VPD.FN_RESTRICT
ORA-04063: package body “SYSTEM.PK_SET_VPD” has errors
ORA-06508: PL/SQL: could not find program unit being called: “SYSTEM.PK_SET_VPD”
ORA-06512: at line 1
*** 2008-09-11 11:39:48.898
———————————————————-
Policy function execution error:
Logon user : SYSTEM
Table/View : SC1.CONTROLE_RMI
Policy name : SC1_APP_RESTRICT
Policy function: SYSTEM.PK_SET_VPD.FN_RESTRICT
ORA-06508: PL/SQL: could not find program unit being called: “SYSTEM.PK_SET_VPD”
ORA-06512: at line 1

On voit qu’il ne trouve pas le package de la policy dans SYSTEM…parce qu’elle a été créé dans un autre schéma (SC1 sur cet exemple)

L’utilisation de packages APEX hors de l’application APEX, c’est à dire en executant la procédure ‘à la main’, provoque une erreur.

ERROR
ORA-20001: This procedure must be invoked from within an application session.
ORA-06512: at “FLOWS_030000.WWV_FLOW_MAIL”, line 109
ORA-06512: at “FLOWS_030000.WWV_FLOW_MAIL”, line 139

La solution est de se donner les autorisation nécessaires en récupérant le Workspace Id, de l’application concernée dans Apex, via l’interface de gestion. Ensuite on positionne cet ID, avec wwv_flow_api.set_security_group_id et l’on peut executer la procédure désirée.

exemple :

begin
wwv_flow_api.set_security_group_id(1860821609902858);
– et execution d’un envoi de mail
apex_mail.send(p_to => ‘didier.deleglise@dd.fr’,
p_from => ‘test@test.com’,
p_body => ‘test’,
p_subj => ‘test ‘);
end;

Probleme lors de l’export 10g
sur APEX et les applications utilisant des ‘domain index’ORA-01031: insufficient privileges
ORA-06512: at “SYS.DBMS_EXPORT_EXTENSION”, line 257
ORA-06512: at line 1
EXP-00078: Error exporting metadata for index WWV_FLOW_OH_IDX. Index creation wi
ll be skipped
C’est un BUG en plus des droits standards d’export, il faut des GRANT SELECT explicites sur les tables ayant des index de domaine…

On fait un scrit pour trouver les tables à GRANTer :

SQL > select ‘GRANT SELECT ON ‘||OWNER||’.'||TABLE_NAME||’ TO user_qui_fait_lexport;’
from dba_indexes
where index_type=’DOMAIN’

–>

GRANT SELECT ON KF.STATES TO user_qui_fait_lexport;
GRANT SELECT ON KF.INTERSTATES TO user_qui_fait_lexport;
GRANT SELECT ON KF.OCEAN TO ORA_BAT;
GRANT SELECT ON KF.TERRITORIES TO ORA_BAT;
…
et executer les grant !

ORA-01925: maximum of 148 enabled roles exceeded

Attention cet article concerne essentiellement Oracle 9i, le paramètre MAX_ENABLED_ROLES étant obsolète en 10g…

Lors du CREATE ROLE avec option par defaut, le role créé est affecté implicitement au createur qui peut donc le GRANTer grace a son admin option par defaut (et aussi si le role est ensuite revoqué ce qui est plus étonnant…)

remarque : si le role est role ‘ enterprise ‘ ou ‘ global role ‘ dans la terminologie Oracle, le role n’est pas granté au créateur

Dans le cas standard, cet héritage peut etre génant particulierement pour des comptes DBA (genre SYSTEM ou OEM_CONNECT, qui est l’utilisateur par défaut de la console OEM) consommateurs de ce genre de commandes.
Le MAX_ENABLED_ROLES etant une limite PAR USER, il peut etre facilement atteint.

Solution (résolution)

1) vérifier s’il n’y a pas de role superflus et le cas échéant les supprimer

2) dans un deuxieme temps seulement ! : augmenter le MAX_ENABLED_ROLES

remarque : la valeur maximum autorisée de MAX_ENABLED_ROLES est 148

Effet pervers : si la limite courante est atteinte par OEM_CONNECT on ne peut plus se connecter a la console d’administration OEM, par contre cf ce qui est dit + haut on peut eventuellement se connecter en Standalone, via un autre compte DBA…

ORA-12154 Le service n’a pu être résolu
ORA-12154 TNS could not resolve service name

mots clés

problême SQL*Net, problême Oracle Net service, erreur SQL*Net, erreur Oracle Net, erreur ORA-12154, erreur Oracle ORA-12154, solution ORA-12154, résolution ORA-12154

Description du problème

problème de résolution de nom de service SQL*Net ou Oracle Net. En clair le nom de la base sur le réseau ne peut pas être traduit (résolu).

Tests

1) vérifier que la base est active sur le serveur, indépendamment du réseau :
- Se connecter directement au serveur
sous Unix / Linux : telnet ou SSH ,
sous Windows : prise de main a distance ou ouverture d’une session directe sur le serveur
On vérifie et positionne le cas échéant l’environnement Oracle de notre session sur le serveur :
- affectation du ORACLE_HOME (répertoire d’installation d’Oracle)
- ORACLE_SID (identifiant local de la base ) ? la bonne valeur,
sous Unix / Linux : export ORACLE_SID = nom_de_la_base
sous Windows : modifier la variable ORACLE_SID, sous DOS, avec la commande SET ORACLE_SID = nom_de_la_base
ou modifier la base de registre avec regedit (software \ oracle \ ORACLE_HOME et ORACLE_SID) avec la bonne valeur
Puis on tente une connexion locale dans un compte connu
cd ORACLE_HOME
cd bin
sqlplus scott/tiger ou sqlplus system/mot_de_passe_system
2) vérifier que le serveur SQLNET est actif
cd ORACLE_HOME
cd bin
lsnrctl stat
3) verifier la méthode de resolution de nom
A PARTIR DU POSTE CLIENT ! : tnsping nom_de_service
Cette commande indique quelle méthode de résolution est utilisée :
- Implicite avec EZCONNECT
- Locale, avec un fichier de traduction locale : ORACLE_HOME/network/admin/tnsnames.ora
- Distante avec un serveur Oracle Names ou LDAP ou DNS
On peut également le vérifier dans le fichier ORACLE_HOME/network/admin/sqlnet.ora ou sont indiquées dans la variable DIRECTORY_PATH, les méthodes de résolution utilisées et dans quel ordre

Résolution de l’erreur ORA-12154

cas 2 : si le serveur SQL*Net / Oracle*Net est inactif, le démarrer :
dans ORACLE_HOME/bin lancer la commande lsnrctl start
remarque : par défaut le serveur démarre sur le port 1521
cas 3 :
solution universelle : forcer la résolution de nom en local :
dans le fichier ORACLE_HOME/network/admin/sqlnet.ora on met la ligne DIRECTORY_PATH= (TNSNAMES)
puis on crée un fichier ORACLE_HOME/network/admin/tnsnames.ora avec la bonne définition du service, calqué sur celle trouvée dans le fichier tnsnames.ora du répertoire SAMPLE.
Il faudra préciser : le nom de la machine serveur (avec son domaine) ou son @IP, le no de port : 1521 et le nom de service Oracle déclaré sur le serveur.
Remarque : le nom de service réseau est souvent pour des raisons de simplicité,identique au nom de service sur le serveur
Solution adaptée :
Attention !!!! le nom se service sur le serveur doit être exactement identique ? celui précisé dans la résolution de nom (indiqué par le tnsping). On peut le vérifier sur le serveur dans le fichier ORACLE_HOME/network/admin/listener.ora. Notamment si le client cherche une base qui s’appelle TEST.mondomaine.fr on doit avoir dans le listener.ora du serveur également TEST.mondomaine.fr , au caractère près.
Resolution locale :
Idem précédemment : dans le fichier ORACLE_HOME/network/admin/sqlnet.ora on met la ligne DIRECTORY_PATH= (TNSNAMES)
puis on crée un fichier ORACLE_HOME/network/admin/tnsnames.ora avec la bonne définition du service, calqué sur celle trouvée dans le fichier tnsnames.ora du répertoire SAMPLE.
Il faudra préciser : le nom de la machine serveur (avec son domaine) ou son @IP, le no de port : 1521 et le nom de service Oracle déclaré sur le serveur.
Résolution LDAP :
**************** ? compléter
Résolution DNS :
dans le fichier ORACLE_HOME/network/admin/sqlnet.ora on met la ligne DIRECTORY_PATH= (HOSTNAME)
et l’on vérifie que le nom de la base est bien résolu par le serveur DNS : ping nom_base.
En cas de problème de DNS, on peut faire appel ? un fichier ‘hosts’ local pour la résolution.
Il se trouve dans /etc/hosts sur Unix et dans WINDOWS\SYSTEM32\DRIVERS\ETC \HOSTS

ORA-1034 Base Oracle non disponible
ORA-1034 Oracle not available

mots clés

ORA-1034, Oracle 0RA-1034 error, erreur Oracle ORA-1034, erreur Oracle 1034, connexion oracle impossible, oracle non disponible, impossible de se connecter, environnement Oracle, ORACLE_SID, startup,

Description du problème

C’est un problème de disponibilité de la base Oracle ? partir d’un client. Le client peut être un programme utilisateur, une application de gestion, ou un client Oracle : SQL*Plus, export (exp) , import (imp), SQL*Loader, etc.
Concrètement il est impossible de se connecter ? la base….
Ce n’est pas un problème de connexion réseau ou SQL*Net, ou Oracle Net Services, ceux ci déclenchent des erreurs spécifiques (voir plus loin).
A preuve cette erreur peut survenir même si l’on est connecté directement sur le serveur hébergeant la base Oracle, sans utiliser aucune couche réseau.
Cette erreur peut en général avoir 2 causes : soit la base Oracle n’est pas démarrée, soit elle est incorrectement identifiée et le client ne la trouve pas !

Tests

remarque : pour effectuer ces tests on doit au moins savoir quel est le nom de la base (l’identifiant) que l’on veut atteindre
- Se connecter directement au serveur
sous Unix / Linux : telnet ou SSH ,
sous Windows : prise de main a distance ou ouverture d’une session directe sur le serveur
- Vérifier que la base cible est démarrée
sous Unix / Linux : ps -ef|grep oracle et rechercher les process de fond standards d’Oracle (au moins dbwr, lgwr, smon, pmon) suffixés par le nom de la base.
sous Windows : ? partir de panneau de configuration, vérifier dans la liste des services, qu’il existe au moins un service qui s’appelle ‘oracle_NOM_DE_LA_BASE et qu’il est démarré.

Diagnostic

cas 1 : Si la base est démarrée, alors c’est qu’elle est mal identifiée par le client, et que le problème est au niveau de l’environnement du système d’exploitation client
cas 2 : Si la base n’est pas démarrée …il faut la démarrer

Résolution de l’erreur ORA-1034

cas 1 : modififier l’identification de la base.
sous Unix / Linux : export ORACLE_SID = nom_de_la_base
sous Windows : modifier la variable ORACLE_SID, sous DOS, avec la commande SET ORACLE_SID = nom_de_la_base
ou modifier la base de registre avec regedit (software \ oracle \ ORACLE_HOME \ ORACLE_SID) avec la bonne valeur
cas 2 :
vérifier que l’environnement est correct (ORACLE_SID) sinon le positionner commeau paragraphe précédent
arreter la base par sécurité (il se pourrait qu’elle soit dans un état intermédiaire, et que tous les process ne soient pa démarrés)
puis la redémarrer en utilisant sqlplus :
$ sqlplus /nolog
SQL connect sys as sysdba
SQL shutdown abort
SQL startup
vérifier que les process ou le service démarrent correctement