Dans ma base de données de production récemment mise à niveau, je vois un certain nombre d'instructions SQL qui connaissent maintenant des temps d'attente élevés lors de l'événement "redimensionnement du descripteur asynchrone". J'ai récemment mis à niveau de 11.1.0.7 à 11.2.0.2 et les instructions SQL qui n'ont jamais attendu cet événement sont maintenant interceptées.
Oracle 11.2 a légèrement modifié la façon dont la base de données et le noyau du système d'exploitation effectuaient les appels d'E/S asynchrones. Ce qui se passe, c'est qu'il existe un certain nombre de descripteurs d'E/S asynchrones pour pouvoir gérer les appels d'E/S asynchrones. Lorsque le nombre d'appels d'E/S asynchrones augmente, le nombre de descripteurs augmente également. Lorsque le nombre d'appels d'E/S asynchrones diminue, le nombre de descripteurs diminue de la même manière.
Avant qu'Oracle puisse augmenter le nombre de descripteurs, il doit attendre que tous les processus qui effectuent actuellement des E/S asynchrones terminent leurs appels d'E/S. Cette action terrible tue vraiment la partie « asynchrone » des E/S ! Une fois que tous les processus ont terminé leurs appels d'E/S ansych, Oracle peut alors modifier les descripteurs vers le haut ou vers le bas en fonction de la charge de travail.
Si votre processus vient de terminer ses E/S asynchrones, avant de pouvoir effectuer un autre appel d'E/S asynchrones, il doit attendre qu'Oracle modifie le nombre de descripteurs. En tant que tel, vous attendez l'événement d'attente "redimensionnement du descripteur asynchrone".
Cela semble être le bogue 9829397 et vous pouvez télécharger un correctif à partir de Metalink. Ce problème est résolu dans 11.2.0.3, il n'apparaît donc que dans 11.2.0.1 et 11.2.0.2. Une solution de contournement consiste à désactiver les E/S asynchrones, mais pour moi, cette solution de contournement est hautement indésirable. On peut également réduire les occurrences de cet événement d'attente en réduisant leurs E/S directes et en ajustant leurs instructions SQL.
