L'extension oci8 fournit trois fonctions différentes pour se connecter à Oracle. La fonction de connexion standard est la fonction oci_connect(). Cette fonction crée une connexion à la base de données Oracle et retourne une ressource utilisée par les futurs appels à la base de données.
La connexion à un serveur Oracle est une opération raisonnablement coûteuse en terme de temps que cela nécessite. La fonction oci_pconnect() utilise un cache persistant de connexions qui peut être réutilisé à travers différents scripts. Cela signifie qu'une seule connexion sera utilisée par processus PHP (ou un fils Apache).
Si votre application se connecte à Oracle en utilisant un jeu différent de droits pour chaque utilisateur web, le cache persistant utilisé par la fonction oci_pconnect() devient moins approprié car l'augmentation du nombre d'utilisateurs concurrents va affecter les performances de votre serveur Oracle, car il devra maintenir trop de connexions en cache. Si votre application est de ce type, il est recommandé d'optimiser votre application en utilisant les options de configuration oci8.max_persistent et oci8.persistent_timeout (elles vous donnent le contrôle sur la taille et la durée de vie du cache de connexions persistantes) ou utilisez le pool de connexions résidentes d'Oracle (pour les bases de données Oracle 11g et suivants), ou encore, utilisez plutôt la fonctionoci_connect().
Les fonctions oci_connect() et oci_pconnect() emploient un cache de connexions ; si vous faites des appels multiples à oci_connect(), en utilisant les mêmes paramètres dans un script donné, le second appel ainsi que les suivants retourneront le gestionnaire de connexion existant. Le cache utilisé par la fonction oci_connect() est nettoyé à la fin de l'exécution du script ou lorsque vous fermez explicitement le gestionnaire de connexion. oci_pconnect() a un comportement sensiblement identique, à la différence que le cache est maintenu séparément et est conservé entre les requêtes HTTP.
Il est important de se souvenir de cette fonctionnalité de cache, car il donne l'apparence que les deux gestionnaires ne sont pas isolés au niveau des transactions, (ils représentent en fait le même gestionnaire de connexion, ils ne sont donc absolument pas isolés). Si votre connexion a besoin de deux connexions séparées, isolées au niveau des transactions, vous devez utiliser la fonction oci_new_connect().
Le cache de la fonction oci_pconnect() est effacé et toutes les connexions à la base de données sont closes lorsque le processus PHP se termine, aussi, les connexions persistantes n'ont d'intérêts que lors de l'utilisation de PHP comme module Apache ou utilisé avec FGCI ou similaire. Les connexions persistantes n'ont aucun intérêts via oci_connect() lorsque PHP est utilisé comme CGI ou en ligne de commande.
oci_new_connect() crée toujours une nouvelle connexion au serveur Oracle, indépendamment de l'existence d'autres connexions. Les applications web à fort trafic doivent éviter d'utiliser oci_new_connect(), particulièrement dans les sections les plus chargées de l'application.
PHP, depuis la version 5.3, (PECL OCI8 1.3) supporte le pool de connexion résidentes Oracle (DRCP). DRCP permet d'utiliser plus efficacement la mémoire de la base de données et permet une meilleure évolution. Peu ou pas de modifications sont nécessaires afin de profiter de DRCP.
DRCP est prévu pour les applications qui se connecte en utilisant peu de schéma de base de données, et qui conserve les connexions ouvertes sur une courte période de temps. Les autres applications doivent utiliser le processus dédié à la base de données Oracle, ou utiliser les serveurs partagés.
DRCP bénéfice des 3 fonctions de connexion, mais seule la fonction oci_pconnect() offre le plus de performance.
Pour rendre DRCP disponible avec OCI8, la version des bibliothèques clientes Oracle utilisées par PHP ainsi que la version de la base de données Oracle doivent être 11g ou supérieure.
La documentation sur DRCP peut être trouvé dans les différents manuels Oracle. Par exemple, reportez-vous à la » configuration du pool de connexions résidentes à la base de données de la documentation Oracle pour un exemple d'utilisation. Un » livre blanc sur DRCP contient plusieurs informations internes sur DRCP.
Pour utiliser DRCP, vous devez construire PHP avec l'extension OCI8 1.3 (ou supérieur) et les bibliothèques Oracle 11g (ou supérieur), puis, suivre ces étapes :
En utilisant les privilèges d'administrateur de la base de données, utilisez un programme comme SQL*Plus pour commencer un pool de connexion à la base de données :
SQL> execute dbms_connection_pool.start_pool;
Optionnellement, utilisez dbms_connection_pool.alter_param() pour configurer les options DRCP. Les options courantes du pool peuvent être trouvées en utilisant la vue DBA_CPOOL_INFO.
Mettre à jour les chaînes de connexion utilisées. Pour les applications PHP qui se connecte actuellement via un nom de connexion réseau comme MYDB:
$c = oci_pconnect("myuser", "mypassword", "MYDB");
modifiez le fichier tnsnames.ora file et ajoutez une clause (SERVER=POOLED), par exemple :
MYDB = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=myhost.dom.com)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales)
(SERVER=POOLED)))
Sinon, vous pouvez modifier la syntaxe de connexion facile en PHP et ajouter :POOLED après le nom du service :
$c = oci_pconnect("myuser", "mypassword", "myhost.dom.com:1521/sales:POOLED");
Éditez php.ini et choisissez le nom de la classe de connexion. Ce nom indique une division logique du pool de connexion et peut être utilisé pour isoler le pool des différentes applications. Toutes applications PHP utilisant le même utilisateur ainsi que la même valeur de classe de connexion pourront se partager le pool de connexions, permettant ainsi d'obtenir une plus grande disponibilité.
oci8.connection_class = "MY_APPLICATION_NAME"
Exécutez votre application, connectez-vous à la base de données 11g (ou supérieur).
Note:
Les applications utilisant Oracle 10g qui ont besoin de la performance des connexions persistantes, peuvent réduire la quantité de mémoire allouée au serveur de la base de données en utilisant les serveurs partagés Oracle (connu auparavant comme serveurs multi-threadés). Reportez-vous à la documentation Oracle pour plus d'informations.
La modification d'un mot de passe lors de connexions DRCP échouera avec l'erreur "ORA-56609: Usage not supported with DRCP". Ceci est une restriction documentée de la base de données Oracle 11g.
Depuis OCI8 1.3, les connexions persistantes peuvent désormais être fermées par l'utilisateur, permettant ainsi un meilleur contrôle des ressources de connexion. Les connexions persistantes peuvent maintenant être fermées automatiquement lorsqu'aucune variable PHP ne les références, comme ce pourrait être le cas à la fin d'un contexte d'une fonction utilisateur PHP. Ceci annulera toutes les transactions non validées. Ces changements dans les connexions persistantes font qu'elles fonctionnent comme les fonctions non-persistantes, simplifiant l'interface, permettant une plus grande cohérence de l'application et de prévisibilité. Définissez la directive oci8.old_oci_close_semantics à On pour retrouver l'ancien comportement.
Si la base de données Oracle est à la version 11.1.0.6, le patch 6474441 doit être appliqué à la base de données afin de pouvoir utiliser DRCP. Sans ce patch, les erreurs comme ORA-01000: maximum open cursors exceeded, ORA-01001 invalid cursor ou ORA-01002 fetch out of sequence peuvent survenir. Ce bogue a été corrigé à partir des versions 11.1.0.7.
Si ce patch ne peut être appliqué à votre base de données Oracle version 11.1.0.6, voici 3 façons de contourner ces problèmes :
Les bases de données Oracle 11.1.0.7 et 11.1.0.6 patché pour le bogue 6474441 permettent aux applications PHP utilisant les connexions DRCP d'utiliser un trigger LOGON pour définir les propriétés de session au moment de la création de la session, comme définir la langue ou le format de la date.
Si le patch à la base de données 11.1.0.6 n'a pu être appliqué, un des contournements suivants peut être utilisé à la place des triggers LOGON :
Le ré-établissement automatique des connexions persistantes PHP après une rupture des processus Apache ou FGCI fait que les triggers LOGON en PHP ne sont recommandés que pour définir les attributs de session et non les requêtes de connexions utilisateurs par applications. Ceci est d'autant plus vrai avec DRCP vu la taille automatique du pool ainsi que la façon dont les triggers LOGON sont émis avec l'authentification DRCP.