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.