Support de Java sous Oracle Fusion Middleware et/ou Weblogic

Lorsque Java SE est utilisé pour faire fonctionner un produit Oracle, il est considéré comme un composant intégré à ce produit et il se conforme au support de ce dernier (Premier Support life cycle) tout en respectant la politique d'Oracle Lifetime Support.

Voici des exemples provenant du site de support d’Oracle :

• J2SE 1.4.2 End of Life (EOL) was announced for October 2008 and J2SE 5.0 for October 2009. This Java SE End of Life applies to Java SE when used standalone or with 3rd party applications. Many Oracle Fusion Middleware products are installed with or run on these versions of J2SE, (now referred to as Java SE). For Oracle Fusion Middleware products, the Oracle Lifetime Support Policy's Extended Support date takes precedence for a given Oracle Fusion Middleware product.
• Java SE 6  End of Life (EOL) is provided here. This Java SE End of Life applies to Java SE when used standalone or with 3rd party applications. Many Oracle Fusion Middleware products are installed with or run on this version of  Java SE. For Oracle Fusion Middleware products, the Oracle Lifetime Support Policy's Extended Support date takes precedence for a given Oracle Fusion Middleware product.
• For Java SE 7 and newer, the same guidelines will be applicable and as according to the Oracle Fusion Middleware Lifetime Support Policy document.

Pour plus de détails, réfèrez-vous à  la note d’Oracle « Java SE End of Life and Oracle Fusion Middleware Policy [ID 952075.1] »

Un accès SFTP n'a jamais été aussi facile

Voici une simple et complète intégration du support SFTP à Windows Explorer qui s'intitule "Swish".

Swish ajoute un support SFTP à Windows Explorer pour qu'on puisse accéder à nos fichiers sur un autre ordinateur/serveur en toute sécurité via SSH. Swish est facile à utiliser car il s'intègre parfaitement à Windows Explorer pour travailler avec des fichiers distants comme si c'était des disques locaux.

Swish est une belle option pour les utilisateurs de Windows parce qu'il est simple d'utilisation.

Pour plus de détails : http://www.swish-sftp.org/

Impossible de recréer la liste de contrôle d'accès (ACL)

Suite à la suppression de la liste nommée "power_users.xml" qui avait été créée à l'aide du code PL/SQL fournit par Oracle, je n'étais plus en mesure de la recréer. J'obtenais l'erreur "ORA-01403 : NO DATA FOUND" lors de l'exécution des commandes suivantes dans SQL*Plus sous le compte "SYS" sur une base  de données 11gR2 (11.2.0.3) :

SYS@lab11g> exec DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('power_users.xml','test','APEX_040100', TRUE, 'connect');

SYS@lab11g> exec DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('power_users.xml','*');

Après avoir exécuté plusieurs requêtes pour consulter la configuration de l'ACL dans le dictionnaire de la base de données, je fus surpris du résultat de la requête suivante :

SYS@lab11g> select host from net$_acl;
HOST
-----------------------------------------------------
*
192.168.1.109
ftp.oracle.com

La requête m'indiquait que le host "*" était toujours présent dans la base de données malgré la suppression de la liste "power_users.xml". J'ai alors vérifié si ce "host" était assigné à une autre liste dont j'aurais peut-être oublié :

SYS@lab11g> select *
from DBA_NETWORK_ACLS T1, NET$_ACL t2
where t1.aclid=t2.aclid
and t2.host = '*';

no rows selected

Le host "*" n'étant assigné à aucune liste, je l'ai alors supprimé :

SYS@lab11g> delete from NET$_ACL where host = '*';

1 row deleted.

SYS@lab11g> commit;

Commit complete.

Suite à la suppression, je fus en mesure de recréer la liste telle que désirée.

Je ne peux m'empêcher de vous dire qu'il n'est pas recommandé de supprimer des données directement du dictionnaire de la base de données. Mieux vaut contacter le support d'Oracle.

Une limite au maximum

Lors de la création d'une base de données Oracle 11gR2 sous Microsoft Windows Server avec l'utilitaire DBCA, nous avons rencontré l'erreur suivante :

ORA-02249: missing or invalid value for MAXLOGMEMBERS

Nous savions que ceci était directement lié à la création des fichiers de contrôle plus précisément au nombre de membres qui sont autorisés dans chaque groupe de journaux (redo log).

Dans DBCA, nous sommes revenu à l'écran de saisie concernant les paramètres nous permettant de spécifier la valeur de "MAXLOGMEMBERS". La valeur que nous avions inscrite était "6". Rien de très élevé, vous en conviendrez !

Pour comprendre la cause de cette erreur, nous avons effectué quelques recherches pour finalement tomber sur un document d'Oracle indiquant que cela est dû à une restriction codé en dur qui oblige la valeur à être comprise entre 1 et 5. Oracle considère qu'il est peu probable qu'une base de données ait à utiliser plus de 2 ou 3 membres pour chaque groupe de fichiers log. Par conséquent, le maximum de 5 a été mis en place.

La documentation d'Oracle n'est pas clair à ce sujet. Elle indique que la valeur dépend de notre système d'exploitation. Dans le document "Oracle® Database Administrator’s Reference" pour Linux/Unix, il est indiqué que la maximum est 5. Un peu plus de précision dans la documentation ou dans le message d'erreur aurait été apprécié.