L’idée de cet article m’est venue en discutant avec des développeurs et des administrateurs utilisant la version 10g et qui veulent, ou qui ont déjà migré vers la 11g. Un court retour d’expérience a montré qu’il subsiste quelques soucis du coté développement liés à la migration d’une 10g vers une 11g Release 2.
Tous d’abord, je vous invite à vous remémorer l’esprit en consultant les new features de la DB 11g listées ici. Tout cela vous fera également patienter en attendant la 12c !
Vous trouverez dans cet article quelques uns des problèmes les plus fréquemment rencontrés dans ce type de migration, et peu documentés sur le net.

1. Problèmes d‘envoi de mail ou accès à une connexion HTTP/TCP:
L’erreur s’explique via cet exemple :
On crée un petit programme PL/SQL qui permet l’envoi de mail :

begin
  utl_mail.send(
  sender     => 'scott@tiger.com',
  recipients => 'test@company.org',
  message    => 'Bonjour'
  );
end;

Lors de l’exécution, on se retrouve avec l’erreur :

ERROR at line 1:
ORA-24247: network access denied by access control list (ACL)
ORA-06512: at "SYS.UTL_MAIL", line 654
ORA-06512: at "SYS.UTL_MAIL", line 671
ORA-06512: at line 1

Solution :
La nouveauté est que la version d’Oracle database 11g permet l’accès aux fonctions externes (UTL_TCP, UTL_HTTP, UTL_SMTP, UTL_MAIL, UTL_INADDR, DBMS_LDAP) à travers un GRANT spécial explicite pour les owner. Il faut suivre les étapes suivantes:
Création de ACL (access control list), grâce au script plsql suivant :

BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('acl_list.xml','List of special access', 'SYS', TRUE, 'connect');
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('acl_list.xml','*');
END;
/
COMMIT;

GRANT du privilège pour les utilisateurs qui ont besoin d’utiliser cette fonction spéciale

• Exécuter cette instruction SELECT pour voir tous les utilisateurs :

SELECT OWNER, REFERENCED_NAME FROM DBA_DEPENDENCIES WHERE referenced_name IN ('UTL_TCP','UTL_SMTP','UTL_MAIL','UTL_HTTP','UTL_INADDR') AND owner NOT IN ('SYS','PUBLIC','ORDPLUGINS') order by OWNER;

Un exemple de retour:

JAVAUTIL,UTL_HTTP SYSCLI,UTL_SMTP

• Grant to user JAVAUTIL and SYSCLI (remember to commit) :

BEGIN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
acl => 'acl_list.xml',
principal => 'JAVAUTIL',
is_grant => true,
privilege => 'connect');
END;
/
commit;
BEGIN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
acl => 'acl_list.xml',
principal => 'SYSCLI',
is_grant => true,
privilege => 'connect');
END;
/
commit;

2. Erreurs en utilisant java class en base de données
Erreur Oracle rencontrée : The class is not compiled
En 11g, le driver JDBC a été changé, et les classes qui utilisent ces driver doivent importer les nouvelles.
Solution:
Modifier dans l’import class, au lieu d’avoir :

import oracle.jdbc.*;

mettre

import oracle.jdbc.driver*;

3. Erreur dans les procédures ou fonctions qui utilisent dba_users lors du changement du password d’un utilisateur
Erreur Oracle rencontrée : ORA-0600 Internal Error
Sur la base de données 11g, le mot de passe en hash n’est plus accessible via la vue dba_users.
Solution:
Changer les query en utilisant la vue sys.user$.
par exemple au lieu de faire

SELECT username, password FROM DBA_USERS

Exécuter cette requête :

SELECT name,spare4 FROM SYS.USER$ WHERE password is not null;

4. Erreur de login, à cause du mot de passe en « case sensitive »
Erreur Oracle rencontrée : ORA-01017: invalid username/password
Lorsque vous créez ou modifiez des comptes utilisateur, par défaut, les mots de passe sont sensibles à la casse.
Pour contrôler l’utilisation de la casse des mots de passe, définissez le paramètre d’initialisation SEC_CASE_SENSITIVE_LOGON.
Seuls les utilisateurs ayant le privilège ALTER SYSTEM peuvent définir ce paramètre.
Mettre TRUE pour activer la sensibilité à la casse ou FALSE pour la désactiver.
Solution:
Mettre le paramètre d’initialisation “sec_case_sensitive_logon” à FALSE:

SQL> SHOW PARAMETER SEC_CASE_SENSITIVE_LOGON
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon             boolean     TRUE
SQL>
SQL> ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;
 System altered.
SQL>

5. Erreur lors de l’utilisation des curseurs  avec DBMS_SQL
Erreur Oracle rencontrée : Error: ORA-29471: DBMS_SQL access denied
En 11g, oracle a introduit des changements sur la sécurité dans le package DBMS_SQL package pour prévenir les problèmes de vulnérabilité PL/SQL. La meilleure solution est de créer des curseurs en utilisant le niveau de sécurité de façon explicite, par exemple:
curs = dbms_sql.open_cursor(level);
Le niveau 1 exige que les ID des utilisateurs lors de l’exécution, le binding et le parsing soient identiques. Le niveau 2 est plus strict et exige que l’id et les rôles soient les mêmes pour toutes les opérations telles que l’exécution, le binding et le parsing, le fetch … etc
Solution:
Pour contourner l’utilisation des sécurités des curseurs, il faut alors déclarer un niveau par défaut et donc mettre le parametre d’initialisation  “dbms_sql_security_level” à 0 :

SQL> ALTER SYSTEM dbms_sql_security_level = 0;
 System altered.
SQL>