Gérer les DBMS_JOB des autres schémas

Enfin terminé les restrictions concernant la gestion des jobs (DBMS_JOBS) appartenant aux autres schémas !!! Vous ne verrez plus le message :

ORA-23421: job number 99 is not a job in the job queue

Il suffit d'utiliser le package "dbms_ijob". Ce package permet, en tant que DBA, de gérer les jobs des autres utilisateurs. Je ne l'ai pas explorer mais tout semble indiquer que le package "dbms_ijob" peut être utilisé de la même façon que "dbms_job".

Selon Tom Kyte, le package "dbms_job" est le seul package supporté par Oracle donc, à utiliser avec modération au cas où... En passant, le caractère "I" dans "IJOB" signifie  "internal".

Utilisation d'Embedded PL/SQL Gateway (EPG)

Embedded PL/SQL gateway (EPG) est intégré à la base de données, plus précisément à Oracle XML DB HTTP listener. Oracle XML DB HTTP listener et Embedded PL/SQL gateway agit au même titre qu'Oracle HTTP Server (OHS) avec mod_plsql et procure les mêmes fonctionnalités internes. Le principale avantage d'utiliser EPG est son architecture très simple qui permet un déploiement simple et rapide (2-tiers) avec une configuration minimale pour une utilisation soit personnelle, de tests ou tout simplement temporaire.

D'un point de vue sécurité, EPG n'est pas l'architecture recommandée pour les applications déployées en production. EPG est principalement utilisé pour des environnements de développement, de tests ou d'autres environnements internes impliquant peu d'utilisateurs. EPG n'est pas la solution idéale pour desservir une application critique accédée par une multitude d'utilisateurs.

Embedded PL/SQL gateway utilise l'architecture partagée (shared server) de la base de données Oracle. Dans cette situation, la valeur du paramètre "SHARED_SERVERS" doit être ajustée pour s'assurer qu'elle soit optimale et en mesure de répondre au nombre d'utilisateurs qui accèdent aux applications sous APEX. La valeur du paramètre "SHARED_SERVERS" peut être vérifiée en exécutant la commande suivante :

show parameter shared_servers

Par défaut la valeur du paramètre est "1". Si cette valeur reste ainsi, cela aura pour effet de provoquer de la contention lors de l'accès aux applications car il n'y a qu'un seul processus pour gérer les requêtes initiées par les utilisateurs.

Les désavantages à utiliser "Embedded PL/SQL gateway" versus "Oracle HTTP Server" sont :

• plus grande sollicitation de la base de données
• plus difficile à diagnostiquer les problèmes (utilisation d'API)
• moins de fonctionnalités et de souplesse
• configuration plus limitée et ardue
• aucune répartition de la charge ou de fonctionnalité de basculement (failover)
• impossible d'installer EPG sur un serveur autre que celui de la base de données ce qui oblige :
• d'exposer la base de données directement sur Internet
• si arrêt de base de données alors arrêt du serveur web aussi (données statiques inaccessibles)

Je n'ai fait aucune mention d'APEX Listener et c'était volontaire. Lors de nos plus récentes mises à l'essai de ce produit, il était plus ou moins évident à configurer et je considère qu'il manque un peu de maturité. N'empêche qu'il est de plus en plus intéressant car Oracle investit beaucoup de temps à développer cette nouvelle solution qui saura répondre davantage aux besoins actuels et futurs. Je vous conseille de gardez un oeil sur APEX Listener car il est voué à un bel avenir.

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é.

Un portefeuille pour la base de données

Afin de permettre à la base de données d’accéder au contenu d’un site sécurisé par le protocole SSL, celui-ci doit avoir un portefeuille (wallet) dans lequel on retrouve les certificats.

1. Obtention des certificats

Cette section décrit comment procéder à l’exportation des certificats associés au domaine (site) dont nous voulons que la base de données puisse accéder.

Note : Les étapes de cette section dépendent du fureteur utilisé. Dans le cas actuel, le fureteur Firefox de Mozilla est utilisé.

• Accéder au site via son adresse sécurisée à l’aide d’un fureteur Internet
• Accéder au détail du certificat du site en cliquant à la gauche de l’adresse URL puis, sur le bouton « More Information… »
• Cliquez sur le bouton « View Certificate » pour faire afficher la fenêtre des propriétés
• Ensuite, déplacez-vous vers l’onglet « Details ». À ce moment, il est important de remarquer dans la partie du haut que la hiérarchie est constituée de plusieurs niveaux. Cela indique que vous devez exporter plusieurs certificats (1 par niveau).
• Pour débuter, sélectionnez le premier niveau puis appuyez sur le bouton « Export » au bas de la fenêtre
• Choisissez le format « X.509 Certificate (PEM) » puis enregistrez le certificat sous un emplacement de votre choix.
• Répéter les deux étapes précédentes pour chacun des niveaux

2. Création du portefeuille

• Accéder au serveur de base de données via un outil tel que « Putty »
• Établir une connexion avec le compte propriétaire (ex. oracle)
• Créer une nouvelle entrée dans le portefeuille

Note : Veuillez spécifier un emplacement et un mot de passe pour le protéger.

(oracle) $ orapki wallet create –wallet [répertoire/du/wallet] -pwd [mot_de_passe] -auto_login

3. Importer les certificats dans le portefeuille

• Transférer les certificats précédemment exportés sur le serveur de base de données
• Accéder au serveur de base de données via un outil tel que « Putty »
• Établir une connexion avec le compte propriétaite (ex. oracle)
• Importer tous les trois certificats en exécutant cette commande pour chacun  :

Note : Assurez-vous de préciser le nom exact du fichier correspondant au certificat.

(oracle) $ orapki wallet add -wallet  [répertoire/du/wallet]  -trusted_cert -cert [Nom_fichier_crt] -pwd [mot_de_passe]

4. Afficher le contenu du portefeuille

Vous pouvez exécuter la commande suivant pour vérifier le contenu du portefeuille. La commande affiche les certificats qu’il contient.

(oracle) $ orapki wallet display -wallet [répertoire/du/wallet]

5. Vérifier le fonctionnement

• Démarrer l’outil SQL*Plus
• Établir une connexion à la base de données avec un compte administrateur (DBA)
• Exécuter la requête SQL suivante :

Note : avant d’exécuter la requête, veuillez spécifier l’emplacement (répertoire) où se trouve le fichier (portefeuille) ainsi que le mot de passe de ce dernier

SELECT utl_http.request('https://[Adresse_URL]','',
       'file:[Nom_fichier_Wallet_incluant_Repertoire]', '[Mot de passe]')
  FROM dual;

Si la requête retourne une série de balise « HTML », cela confirme que c’est fonctionnel.

Et pour terminer, n'oubliez pas de jeter un oeil à la liste de contrôle ACL pour que votre schéma (utilisateur) soit autorisé à accéder au site web.