Discussion :

[farenheiit]

Bonjour,

Un de nos clients qui utilise notre application a vu une requête exécutée lors du batch de nuit passer des 6 minutes habituels à 45 min.
J'ai pu me connecter à leur base de prod et en exécutant la requête elle s'exécute en 15 minutes (avec quasiment que des physical reads). Lorsque j'exécute la requête une 2ème fois elle s'exécute en qq secondes (0 Physical reads). J'ai récupéré le plan d'exécution dans le referentiel AWR et c'est le même que lorsque je lance la requête de manière unitaire. La requête est un insert-select.

J'ai du mal à comprendre pourquoi cette requête qui passait en 15 minutes max est passé en 45 minutes. Pour moi ça ne peut être qu'un pb d'accès disk ou de contentions sur les datafiles. J'ai demandé un rapport AWR correspondant à la période du batch et je vois que bcp de datafiles ont des vitesse d'accès moyen > 7ms. Selon statspack Analyzer il faut éviter les accès superieur à 7ms.

Comment puis-je valider mon hypothèse? y'aurait-il une autre explication possible qui m'aurait échappé?

La base est une base 10.2.0.4 en RAC Actif/Passif et avec ASM.

merci de votre aide.

[orafrance]

Je pense que tout est dit dans ton test : physical read 15 minutes vs buffer cache à quelques secondes

Par contre, 7 ms c'est trop. Faudrait savoir si quelque chose à changer dans l'archi (chez un client j'ai mis presque un mois à avoir l'info sur l'activation du mirroring sur les baies de disque... en le supprimant le gain de perf était spectaculaire ). Vérifie que t'avais pas de backup en cours à l'heure du passage de cette requête aussi.

Eventuellement, si tu as activé le change block tracking pour RMAN, ça peut aussi avoir ce genre de répercution sur les I/O.

[farenheiit]

Sais tu si y'a moyen de savoir en me connectant à leur base via sqlplus si des backup ont été lancés ou pas ?

900 secondes avec PR et 9 secondes sans PR ça fait un facteur de 100. ça correspond bien à la différence entre un accès physique et un accès logique ?