Discussion :

[Sebmoistien]

Bonjour,

Nous avons effectué une migration de Oracle 12c vers Oracle 19c (19.10.0.0.0) récemment. Depuis une requête en particulier plante régulièrement. Il s'agit d'un update sur une table avec une jointure sur d'autres tables dans le where via une clause EXISTS et une sous requête. La requête est banale et fonctionnait très bien depuis 2 ans en 12c.

En l'occurrence, ça plante particulièrement quand la sous-requête n'a qu'une ligne à exploiter (table principale issue d'un xmlelement) et ne renvoie rien (donc aucune mise à jour ne se fait).

En outre, le problème semble aléatoire même lorsque ces conditions sont remplies. Cette requête appelée des milliers de fois par heure dans un contexte de PROD plante environ 1 fois sur 3 et 1 jour sur 3 (les 2 autres jours, aucun plantage et les jours ou ça plante, 2 fois sur 3 ça marche sans explication).

On a changé le EXISTS par un IN pour la jointure via sous requête (ce qui est moins bien pour les perfs...) et depuis ça remarche à tous les coups.

Il semble donc y avoir un bug dans la 19c qui plante sur une certaine structure de requête UPDATE WHERE EXISTS et selon des conditions que je n'ai pas réussi à clairement identifier (sous requête renvoie 0 ligne Ok ; mais pourquoi certains jours et certains appels et pas d'autres ??? Peut être en lien avec le traffic sur la BDD).

Je n'ai malheureusement pas le code erreur d'Oracle car l'exception est cachée et rendue générique (encore une fois en contexte de PROD). Et je n'ai pas d'environnement de test avec exactement la même version d'Oracle sur lequel on reproduirait le problème.

Est-ce que quelqu'un aurait entendu parler de ce genre de bug en 19c pour m'aider à y voir plus clair et savoir quel patch appliquer ?

Merci d'avance,
Seb

[vanagreg]

Bonjour,

Si tu ne donnes ni l'erreur ni la requête, ça va être compliqué d'aider. Quand tu dis plante, c'est une erreur ou un mauvais résultat?
Il est possible qu'il y ait un bug, mais si ça produit aléatoirement ce sera difficile de faire analyser. Puisque tu as migré en 19c, je te conseille d'appliquer le dernier RU, ça corrige souvent beaucoup de bugs.

[Ikebukuro]

Vu que ton erreur est aléatoire, regarde si cette requête n'a pas plusieurs plans d'exécutions : peut-être que l'un est appelé selon les valeurs de la clause WHERE et c'est lui qui plante.
Regarde pour cela dans V$SQL_PLAN et DBA_HIST_SQL_PLAN (mais là tu n'auras que les requêtes les plus consommatrices de ressources).

Est-ce que ta table ou ses index sont partitionnés? Si oui, peut-être qu'une partition se trouve sur un disque dur qui est tombé ou un serveur éteint et c'est lors d'un UPDATE avec des valeurs précises que cette ou ces partitions sont appelées et ça fait planter la requête.

[Sebmoistien]

Bonjour,

Merci pour vos réponses.

Quand je dit que ça plante c'est effectivement une erreur Oracle qui lève une exception ORA-xxxx dont je n'ai pas le code.

Nous sommes en version Standard pour des raisons de coûts de licence. Nous avons spécifiquement migré vers la 19c pour bénéficier du HA (haute dispo actif passif) car le RAC (haute dispo actif actif) n'est plus permis en mode Standard par Oracle.

Je vais regarder si j'ai accès aux plans d'exécution de cette requête au moment où elle plantait versus ok.

[skuatamad]

Qu'est ce qu'il y a dans l'alert.log ?

[Sebmoistien]

Bonjour,

Je n'ai malheureusement pas pu récupérer les plans d'exécution du moment où le bug se produisait (il faut dire que je n'ai pas accès à grand chose, la BDD étant infogérée en externe).

Concernant l'alert.log, pas vu d'erreur spécifique les jours où le bug a eu lieu, seulement des artefacts de la migration (software edition is incompatible with SQL plan management) apparemment sans impact d'après ce que j'ai lu, et des traces de quelques incidents avec microcoupures de la base et pertes de connexions.

Je suis pas mal occupé par le rattrapage des données suite à ce bug. Je reprendrais ma chasse au sorcières un peu plus tard...