psql
Chronométrage activé.
psql (9.6.1)
Saisissez "help" pour l'aide.
select version();
version
------------------------------------------------------------------------------------------
PostgreSQL 9.6.1 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit
(1 ligne)
Temps : 0,346 ms
-- 15h13min44
START TRANSACTION;
START TRANSACTION
Temps : 0,425 ms
-- on attend 1 minute
SELECT CURRENT_TIMESTAMP;
now
-------------------------------
2016-11-22 15:13:44.862139+01
(1 ligne)
Temps : 1,408 ms
-- on attend 1 minute
SELECT CURRENT_TIMESTAMP;
now
-------------------------------
2016-11-22 15:13:44.862139+01
(1 ligne)
Temps : 0,179 ms
\q
psql
Chronométrage activé.
psql (9.6.1)
Saisissez "help" pour l'aide.
postgres=# SELECT current_timestamp;
now
-------------------------------
2016-11-22 16:14:19.260113+01
(1 ligne)
postgres=# SELECT current_timestamp;
now
-------------------------------
2016-11-22 16:14:23.660406+01
(1 ligne)
postgres=# SELECT current_timestamp;
now
------------------------------
2016-11-22 16:14:27.15526+01
(1 ligne)
Nous avons ici utilisé le fait que CURRENT_TIMESTAMP retourne toujours l’heure de début de transaction. Cela permet de constater qu’il est possible de démarrer explicitement une transaction avec START TRANSACTION et que la transaction est effectivement démarrée dès l’exécution de cette commande.
Mais il est aussi possible d’exécuter des commandes sans avoir utilisé START TRANSACTION. Dans ce cas, à chaque commande correspond une transaction immédiatement validée. Ce comportement ne peut d’ailleurs pas être désactivé côté serveur. Pour éviter ce comportement, le client doit donc explicitement démarrer une transaction avec START TRANSACTION avant d’envoyer d’autres commandes. Cela peut être fait automatiquement par certains outils clients comme psql (\set AUTOCOMMIT off).
Comment se comporte Oracle à présent ? Démonstration avec Oracle 12.1.0.2 :
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> START TRANSACTION;
SP2-0310: unable to open file "TRANSACTION.sql"
SQL> SELECT systimestamp FROM dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
22-NOV-16 04.26.35.381450 PM +01:00
SQL> desc t1;
Name Null? Type
----------------------------------------- -------- ----------------------------
C1 TIMESTAMP(6)
SQL> SELECT * FROM t1;
no rows selected
SQL> SELECT b.start_time
FROM v$session a, v$transaction b
WHERE a.saddr = b.ses_addr
and a.sid = (select sys_context('USERENV','SID') from dual);
no rows selected
SQL> INSERT INTO t1 SELECT systimestamp FROM dual;
1 row created.
SQL> SELECT b.start_time
FROM v$session a, v$transaction b
WHERE a.saddr = b.ses_addr
and a.sid = (select sys_context('USERENV','SID') from dual);
START_TIME
--------------------
11/22/16 16:40:24
SQL> SELECT * FROM t1;
C1
---------------------------------------------------------------------------
22-NOV-16 04.40.24.773974 PM
Tout d’abord, Oracle ne permet PAS de démarrer explicitement une transaction avec START TRANSACTION. START est en fait une commande sqlplus. Oracle interprète donc notre commande START TRANSACTION comme une demande d’exécuter le contenu d’un fichier TRANSACTION.sql, ce qui n’a rien à voir avec notre sujet.
Mais il est bien sûr tout de même possible de démarrer une transaction avec Oracle. Nous ne disposons pas d’une fonction donnant l’heure de début de transaction donc nous interrogeons la vue v$transaction afin de savoir si une transaction est démarrée dans notre session. Cela permet de constater qu’une transaction est implicitement démarrée à la première commande DML (INSERT, UPDATE, DELETE, MERGE).