Les anciens patchs Oracle ne se téléchargent plus comme avant ? Voici pourquoi

Ça m’est arrivé il y a quelques semaines sur My Oracle Support. Je cherche un patch, je clique sur télécharger, et au lieu du fichier j’obtiens une fenêtre qui me demande un mot de passe.

19.29 : le patch qui a disparu du jour au lendemain

C’est avec le Release Update 19.29 que beaucoup d’entre nous ont découvert ce fonctionnement. Le patch était disponible normalement, puis du jour au lendemain, il a fallu ouvrir un SR pour obtenir le mot de passe permettant de le télécharger.

Ce n’était pas anodin, il y avait un vrai problème derrière : un bug (34352668) capable de provoquer des corruptions de blocs, surtout quand le patch est appliqué en rolling sur du RAC. Oracle a retiré le RU, corrigé le tir, puis republié le patch, sous mot de passe, histoire de garder un minimum de contrôle sur qui le télécharge pendant la période de transition. Jusque-là on peut comprendre la logique, le problème c’est que ça ne semble plus être un cas isolé.

Et ce n’est que le début…

Plusieurs collègues DBA rapportent la même chose sur des RU plus anciens : 19.28, et probablement d’autres en dessous, sans qu’un bug précis soit à chaque fois documenté publiquement.

Un exemple concret : le patch 37957391

Pour illustrer, j’ai essayé de télécharger le patch 37957391 (GI Release Update 19.28.0.0.250715) sur My Oracle Support. La fiche du patch est accessible normalement, avec toutes ses informations (bugs corrigés, taille, plateforme…) :

Mais au moment de télécharger le fichier, la surprise arrive, un password est requis pour pouvoir lancer le téléchargement.

Impossible d’aller plus loin sans ce mot de passe qu’il faut donc obtenir en ouvrant un SR auprès du support Oracle.

Patcher en RU-1, est-ce toujours pertinent aujourd’hui ?

Pendant des années, la règle d’or dans la communauté des DBA était de patcher en utilisant l’avant-dernier RU publié. On restait sur cette version en production, car elle était jugée plus sûre : on attendait que le dernier RU soit suffisamment éprouvé et on laissait le temps aux retours de la communauté de se faire connaître. Cette prudence semblait raisonnable, et elle correspondait d’ailleurs aux recommandations historiques de l’équipe Oracle MAA elle-même.

Sauf que le cas du 19.29/19.30 montre l’inverse. Ceux qui ont patienté et appliqué le RU-1 (le 19.29, une fois le 19.30 disponible) se sont retrouvés bloqués par une demande de mot de passe, sur le patch même qu’ils pensaient le plus fiable.

Et Oracle a changé de discours à ce sujet. Sur son propre blog, dans un billet dont le titre “Prepare Now: Apply the Upcoming Oracle Database Release Update Immediately Upon Availability”, la recommandation est désormais d’appliquer le nouveau RU dès sa disponibilité, sans attendre le cycle suivant.

Deux raisons expliquent ce changement de cap. La première, on vient de la voir : un RU “éprouvé” par le temps n’est plus une garantie de stabilité, puisqu’un patch peut être retiré et corrigé en quelques semaines. La seconde tient à la sécurité : Oracle a publié des recommandations dédiées aux menaces liées à l’IA (note PNEWS3015) qui poussent explicitement à rester sur des RU récents pour réduire la fenêtre d’exposition à des failles déjà exploitées ailleurs.

La check-list à adopter

On ne parle pas de tout réinventer dans nos process de patching, mais d’adopter quelques bonnes pratiques dès aujourd’hui :

• Abandonnez la logique RU-1 par défaut, visez le RU le plus récent dès sa sortie.
• Téléchargez vos patchs bien avant la fenêtre de maintenance pas la veille.
• Vérifiez toujours ce que vous avez vraiment téléchargé et appliqué, avec opatch lspatches ou le README du patch.
• Documentez la procédure d’ouverture de SR pour la demande de password du Patch afin d’éviter de la chercher en plein urgence.