Contexte

Les erreurs ORA-01555, remontées dans la log d’une instance Oracle, indiquent généralement une « Query Duration » élevée (plusieurs heures). Pour ces cas, la cause est souvent à chercher du côté de la forte activité transactionnelle de l’instance, du paramètre undo_retention, de la taille du UNDO tablespace, ou de l’optimisation même de la requête qui renvoie l’erreur.

Mais qu’en est-il pour les requêtes qui renvoient ORA-01555 avec une Query Duration qui vaut 0 seconde, ou seulement quelques secondes, alors que l’on a pourtant positionné le paramètre undo_retention à une valeur suffisamment élevée ?

La requête qui renvoie l’erreur est affichée dans la log de l’instance Oracle.

 

Cas 1 : s’il s’agit d’une flashback query

Exemple :

ORA-01555 caused by SQL statement below (SQL ID: 7jbhsk4pmqt0p, Query Duration=0 sec, SCN: 0x0193.60b7263a):
Tue Sep 26 12:10:33 2018
select * from ma_table as of timestamp to_timestamp('25/09/2018 14:00:00')

Si la requête contient la clause « as of timestamp », on est dans le cas d’une flashback query. Cela veut dire qu’un utilisateur a voulu accéder aux anciennes données d’une table.

Dans l’exemple ci-dessus, en lançant la requête le 26/09 vers 12h, la requête veut lire les données de la table en date du 25/09/2018 à 14h00 (la veille). Les anciennes données de la table n’étant plus toutes disponibles dans le UNDO tablespace, la requête renvoie immédiatement (d’où le « Query Duration = 0 sec »), l’erreur ORA-01555.

Dans ce cas précis, l’erreur donc est à ignorer car elle est liée à une manipulation d’un utilisateur.

 

Cas 2 : si ce n’est pas une flashback query

Exemple :

ORA-01555 caused by SQL statement below (SQL ID: fb2g086kq5fqq, Query Duration=0 sec, SCN: 0x0193.61865d95):
Tue Sep 28 09:01:48 2018
select * from ma_table

Dans cet exemple, la requête n’est pas une flashback query (car pas de clause « as of timestamp »).

Pour ce cas, il faut étudier la note du support Oracle 1950577.1, qui donne plusieurs pistes :

• Si la requête utilise un dblink, vérifier si la valeur du paramètre undo_retention est adaptée sur la base cible ;
• Reconstruire les indexes de la table (ou des tables) utilisée(s) dans la requête ;
• Créer un nouveau tablespace UNDO à utiliser pour l’instance, et supprimer l’ancien.