Apercu des transactions autonomes (PRAGMA AUTONOMOUS_TRANSACTION).

On sait qu'une des règles fondamentales d'un SGBD est d'apporter une cohérence complète lors de transactions (atomicité de la transaction) ; cependant, il arrive que certaines transactions doivent être exécutées indépendamment de celle qui l'appelle. C'est ce qu'on nomme les transactions autonomes.

Oracle a mis en place un mécanisme permettant cette exception : la clause PRAGMA AUTONOMOUS_TRANSACTION. Cette clause se place à la déclaration de la procédure / fonction / trigger et précise ainsi que celle-ci sera autonome.

Ainsi, le commit et le rollback à l'intérieur de la transaction autonome n'auront aucun effet sur les procédures appelantes.
La meilleure façon de comprendre les transactions autonomes est de les voir en action (exemple détaillé). Pour ce faire,on va créer une table TEST et de la remplir avec deux rangées sans faire le commit;

SQL> insert into test values (1,' Ceci est un test numéro 1 ');
 1 row inserted

SQL> insert into test values (2,' Ceci est un test numéro 2 ');
 1 row inserted

ORA-04091: Table en mutation.

Dans un premier temps, on va essayer de créer un déclencheur (trigger) sur la table EMP du schéma SCOTT.

Voici le code:
create or replace trigger TR_EMP_COUNT
AFTER DELETE ON EMP
FOR EACH ROW
  DECLARE
  num  number;
  BEGIN
      SELECT COUNT(*) INTO NUM
      FROM EMP;
      DBMS_OUTPUT.PUT_LINE(' Nbre d''employés' ||num);
  END;

Ensuite, on essaye de faire un DELETE sur cette table:
DELETE FROM EMP
WHERE DEPTNO=30;

À ce moment là, le trigger se déclenche et Oracle génére une erreur de type table en mutation (ORA-04091).

Pour résoudre ce problème, il y a deux possibilités:

• Enlever FOR EACH ROW ou
• Utiliser PRAGMA AUTONOMOUS_TRANSACTION.

Maintenant, l'opération de DELETE fonctionne parfaitement:

SQL> delete from emp
  2  where deptno=30;

6 rows deleted

Debug avec Oracle Forms 10g.

Voici une astuce pour faire exécuter une form étape par étape - DEBUG -  (il passe par tous les déclencheurs de la form) avec Oracle Forms 10g.

Url (exécution avec Java 7)
http://hostmachine:8889/forms/frmservlet?config=jpi&debug_messages=yes&form=d:\summit.fmx

Vous devez configurer le chemin des fichiers exécutables de forms (*.fmx). d:\summit.fmx, celui-ci est un exemple... 

ORA-01000: maximum open cursors exceeded

Si vous avez cette erreur, cela veut dire que le nombre maximum des curseurs ouverts par un utilisateur est atteint. Pour savoir plus le nombre de curseurs ouverts, exécuter cette requête (compte sys as sysdba):


select max(a.value) as open_cur, p.value as max_open_cur
from v$sesstat a, v$statname b, v$parameter p
where a.statistic# = b.statistic#
and b.name = 'opened cursors current'
and p.name= 'open_cursors'
group by p.value

Dans mon cas:

 OPEN_CUR MAX_OPEN_CUR
---------- -----------------------------
        77                 300

Pour régler ce problème de ORA-01000, il faudrait tout d'abord vérifier la valeur de la configuration du paramètre en exécutant cette requête et changer la valeur de ce dernier.

SQL> select name, value from v$parameter where name ='open_cursors'

NAME                                                                             VALUE
---------------------------------------------------------------------------
open_cursors                                                                     300

Pour modifier cette valeur, il faudrait exécuter ceci:
SQL> ALTER SYSTEM SET OPEN_CURSORS=350 SCOPE=MEMORY;

System altered

ATTENTION: SI VOUS VOULEZ CHANGER CE PARAMÈTRE POUR LE PROCHAIN DÉMARRAGE DE L'INSTANCE, IL FAUDRAIT REMPLACER MEMORY PAR SPFILE.
 
SQL> select name, value from v$parameter where name ='open_cursors' ;

NAME                                                                             VALUE
--------------------------------------------------------------------------------
open_cursors                                                                     350

Oracle Forms 10g avec Java 7 Update 21.

Après avoir modifier le fichier de configuration de " Oracle Forms 10g " formsweb.cfg et faire toutes les étapes, j'ai constaté que le problème est revenu pour Jinitiator et quand j'exécute la Form avec le browser (Firefox v21), j'ai eu le fameux message d'erreur à l'écran:

FRM-92095: Oracle Jnitiator version too low

 

Après une recherche fructueuse sur le net, j'ai vu sur le blogue d'Oracle qu'il faudrait télécharger le patch (mise à jour) dont le numéro est 14614795. 

Pour plus de détails concernant l'application de la patch, veuillez me contacter à cette adresse: aabed@oraweb.ca
Maintenant, mon problème est résolu et Forms 10g fonctionne à 100% avec Java 7 UP 21.
Testé avec Firefox 21, Windows 7 32 bits et Oracle Forms 10g.

FLASHBACK Version Query....

Le but de ce billet est d'afficher l'historique des salaires pour un employé d'une session active:
Dans l'exemple suivant, le salaire de l'employé est de 8600.

On va modifier le salaire de cet employé pour 9000.

On va valider le tout avec un COMMIT et on va augmenter le salaire de 30%.

Ensuite, les différentes versions du salaire sont affichées en spécifiant la clause VERSIONS.
Par défaut, elle peut être spécifiée comme suit: VERSIONS BETWEEN {SCN | TIMESTAMP} MINVALUE ET MAXVALUE.
 
La clause VERSIONS est une extension SQL pour les requêtes. Vous pouvez avoir des opérations DML et DDL qui utilisent une clause de versions dans les sous-requêtes. 

  

On voit bien l'historique du salaire de cet employé.
 

Utilisation de PURGE avec la commande DROP TABLE.

Pour supprimer la table test, c'est vraiment très simple. Il suffit de taper ceci: DROP TABLE test. Si on veut la récupérer, on peut utiliser la syntaxe FLASHBACK, voir le lien sur mon blogue ou en cliquant ici.

On peut vérifier l'objet effacé avec l'instruction suivante:

SELECT original_name, operation, droptime FROM recyclebin;

Oracle Database 10g introduit une nouvelle fonctionnalité pour supprimer des tables. Lorsque vous supprimer une table, Oracle ne libère pas immédiatement l'espace associé à la table. Au contraire, la base de données renomme la table et Oracle le place dans une corbeille, où il peut ensuite être récupéré avec la déclaration  FLASHBACK TABLE tel qu'expliqué dans le lien. 
Si vous voulez libérer immédiatement l'espace associé à la table au moment où vous lancez l'instruction DROP TABLE, puis inclure la clause PURGE comme indiqué comme suit: DROP TABLE test PURGE

Spécifiez PURGE seulement si vous voulez supprimer la table et libérer de l'espace qui lui est associée en une seule étape. Si vous spécifiez PURGE, Oracle ne place pas la table et ses objets dans la corbeille.
Cette clause vous permet d'économiser une étape dans le processus. Il fournit également une sécurité renforcée.

Note: Vous ne pouvez pas annuler une instruction DROP TABLE avec la clause de PURGE, et vous ne pouvez pas récupérer la table si vous spécifiez la clause PURGE. Cette fonctionnalité n'était pas disponible dans les versions antérieures. C'est nouveau dans la version 10g.

Migration Oracle Database 10.2.0.3 vers 10.2.0.4

J'ai mis un document en ligne qui explique en détail la migration d'Oracle Database 10.2.0.3 vers la version 10.2.0.4. Voici le lien de mon site web pour télécharger la documentation pdf (www.oraweb.ca, aller dans le menu Documentation - Administration BD Oracle 10g ou directement en cliquant ici).

Désinstaller APEX 4.0

Si vous voulez désinstaller Oracle Application Express 4.0, voici les étapes:

• Positionnez dans le répertoire d'APEX afin de lancer le script.
• Connectez-vous avec le compte sys as sysdba sous SQL*Plus

• Exécutez le script APXREMOV.SQL  (sous sqlplus, @apxremov.sql).
• Le processus de la désinstallation commencera.

 

Utilisation de SYS_CONTEXT Oracle 10g.

Cette fonction est très utile pour déterminer par exemple le nom de la machine, l'adresse IP ainsi que d'autres fonctions (système d'exploitation utilisé, problème de connexion à la BD, audit, etc...).

Pour voir des exemples de l'usage de SYS_CONTEXT (audit de la BD), on va créer deux objets (une table et un trigger ).

La création de la table est comme suit:

 Et la création d'un trigger:

create or replace trigger logon_succes_bd
AFTER LOGON ON DATABASE

begin
    begin
     -- Insertion dans la table audit_logon
     insert into v$audit_logon (
     audit_date    ,
     db_user_name  ,
     os_user_name  ,
     computer_name ,
     ip_address    ,
     module        ,
     comments )
     values  (
     sysdate       ,
     user          ,
     sys_context('USERENV','OS_USER'),
     sys_context('USERENV','HOST'),
     sys_context('USERENV','IP_ADDRESS'),
     sys_context('USERENV','MODULE'),
     ' Connexion avec succès à la BD ' || sys_context('USERENV','DB_NAME'));
     exception
          when others then null;
    end;
end;

 Lorsqu'on fait une connexion avec la BD, il y aura une insertion dans la table. Voici les résultats:

Une interrogation da la table v$audit_logon permet d'afficher les informations de la connexion à la BD.

Voici la liste de tous les paramètres de SYS_CONTEXT:

Exemple d'utilisation de cette fonction:
select sys_context('USERENV','NLS_DATE_FORMAT') from DUAL;