{"id":5202,"date":"2015-06-17T13:36:43","date_gmt":"2015-06-17T12:36:43","guid":{"rendered":"http:\/\/blog.capdata.fr\/?p=5202"},"modified":"2019-09-13T13:25:12","modified_gmt":"2019-09-13T12:25:12","slug":"ora-01555-et-query-duration0","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/ora-01555-et-query-duration0\/","title":{"rendered":"ORA-01555 et Query Duration=0"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

L’erreur \u00a0ORA-01555 signifie que la requ\u00eate en cours d’ex\u00e9cution cherche \u00e0 obtenir pour une donn\u00e9e une image dans le temps qui n’est plus pr\u00e9sente en base.<\/p>\n

Il est donc tr\u00e8s fr\u00e9quent de trouver cette erreur pour des requ\u00eates avec une dur\u00e9e d’ex\u00e9cution tr\u00e8s longue. Cette information est remont\u00e9e lorsque l’erreur survient (Query Duration = <dur\u00e9e> sec).<\/p>\n

Pour une requ\u00eate rapide, une autre cause possible est une forte activit\u00e9 transactionnelle, ayant pour cons\u00e9quence une saturation du tablespace d’annulation, donc potentiellement une disparition tr\u00e8s rapide des images dans le temps pour les transactions valid\u00e9es.<\/p>\n

 <\/p>\n

Mais il arrive aussi qu’aucune des deux situations ci-dessus ne se pr\u00e9sentent, et que l’on ait tout de m\u00eame \u00e0 faire \u00e0 une ORA-01555 pour une requ\u00eate rapide. Comment analyser cette situation ?<\/p>\n

 <\/p>\n

Voici un exemple concret:<\/b><\/p>\n

Mon Jun 15 02:58:48 2015\r\n\r\nORA-01555 caused by SQL statement below (SQL ID: 2ky0zqc7h049z, Query Duration=0 sec, SCN: 0x000c.54839232):\r\n<\/pre>\n
La requ\u00eate en cause a bien une dur\u00e9e d’ex\u00e9cution inf\u00e9rieure \u00e0 une seconde.
\n 
\n <\/p>\n
On v\u00e9rifie que la partie gestion des segments d’annulation ne soit pas satur\u00e9e sur cette p\u00e9riode:<\/p>\n
SQL>select begin_time, end_time, activeblks, unexpiredblks, expiredblks, tuned_undoretention, maxquerylen \r\nfrom v$undostat where '2015\/05\/15 02:58:48' BETWEEN BEGIN_TIME and END_TIME;\r\n\r\n \r\n\r\nBEGIN_TIME\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 END_TIME\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ACTIVEBLKS UNEXPIREDBLKS EXPIREDBLKS TUNED_UNDORETENTION MAXQUERYLEN\r\n\r\n------------------- ------------------- ---------- ------------- ----------- ------------------- -----------\r\n\r\n2015\/06\/15 02:52:42 2015\/06\/15 03:02:42\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 7696\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 47768\u00a0\u00a0\u00a0\u00a0\u00a0 318328\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1052\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 211<\/pre>\n
 
\nLa r\u00e9tention estim\u00e9e \u00e0 1052 secondes, soit presque 18 minutes, et la pr\u00e9sence d’un grand nombre de blocs expir\u00e9s (c-\u00e0-d correspondant \u00e0 des transactions termin\u00e9es plus anciennes que la p\u00e9riode de r\u00e9tention d\u00e9finie par d\u00e9faut \u00e0 15 minutes via le param\u00e8tre UNDO_RETENTION) nous confirment qu’il n’y a aucune saturation c\u00f4t\u00e9 segments d’annulation.<\/p>\n
L’erreur nous indique indirectement la date de l’image \u00e0 laquelle la requ\u00eate cherche \u00e0 acc\u00e9der, au travers du SCN (system Change Number, identifiant unique d’une entr\u00e9e transactionnelle). Ici, il s’agit de ”\u00a0SCN: 0x000c.54839232″<\/p>\n
La fonction SCN_TO_TIMESTAMP permet de conna\u00eetre le moment \u00a0correspondant \u00e0 ce SCN. Attention, la valeur indiqu\u00e9e dans l’erreur ORA-01555 est au format hexad\u00e9cimal, et elle est parasit\u00e9e par un caract\u00e8re “point”, il faut donc convertir ici\u00a0000c54839232 en valeur d\u00e9cimale pour que SCN_TO_TIMESTAMP nous donne l’information correcte:<\/p>\n
SQL>SELECT SCN_TO_TIMESTAMP(TO_NUMBER('000c54839232','xxxxxxxxxxxx')) FROM DUAL;\r\n\r\nSCN_TO_TIMESTAMP(TO_NUMBER('000C54839232','XXXXXXXXXXXX'))\r\n\r\n---------------------------------------------------------------------------\r\n\r\n15-JUN-15 02.10.16.000000000 AM<\/pre>\n
 
\n <\/p>\n
Notre requ\u00eate, ex\u00e9cut\u00e9e \u00e0 2h58:48 cherchait donc \u00e0 obtenir une image de certaines donn\u00e9es \u00e0 2h10:16 (date de l’ouverture de la transaction), soit plus de 48 minutes dans le pass\u00e9. On est donc tr\u00e8s loin des 15 minutes d\u00e9finies au niveau de l’instance.
\n 
\n <\/p>\n
Deux solutions donc pour r\u00e9soudre ce probl\u00e8me:<\/b><\/p>\n