Discussion :

[grouhan]

Bonjour,

dans l'AWR un nombre important de requête SELECT c from t AS OF SCN sont remontées.

Avez-vous une idée de l'origine de ces requêtes ?

Savez-vous si elles peuvent être responsabmle des nombres I/O waits remontées par Oracle ?

[Ikebukuro]

Salut,
La copie écran de ton rapport AWR ne nous apprend rien, la requête dont tu parles en est absente. Aurais-tu une autre image, notamment avec le user qui lance la requête?

Les requêtes de type "SELECT...AS OF SCN" sont des requêtes Flashback : cela signifie dire que tu veux voir les données dans le passé.
A priori c'est une requête non interne à Oracle, sinon le FROM serait sur une table du genre obj$, tab$... il faudrait donc identifier qui lance ce SELECT.

[grouhan]

Bonjour,

merci pour ton retour, ci-joint le top 10 (les requêtes select from Table OF SCN sont identifiés par le module JDBC Thin Client)



Ci-joint un exemple de requêtes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT "MOUANAANN", "MOUANANUM", "MOUANAOOP" FROM ZMOUANA0 AS OF SCN 22265335847 WHERE MOUANADOP >= 1220407 AND MOUANAETA = 1

[vanagreg]

Bonjour,

Les requêtes ont l'air de vendre des règles de nommage qui font rêver. Bref, d'après ta copie-écran, ces requêtes ne sont responsables que de 3% du temps de la fenêtre choisie. Soit la fenêtre choisie est trop large, soit elles ne posent pas de problème. D'ailleurs, quel est le problème que tu essaies d'identifier?

On peut voir également d'autres requêtes qui forcent l'utilisation d'un index, ce qui est très rarement nécessaire (et peut d'ailleurs avoir des conséquences inverses que celles escomptées) .

Il nous faudrait aussi la section "Top 10 foreground events by Total Wait Time".

[grouhan]

Bonjour,

les requêtes qui te font rêver, sont générées à partir d'un programme de portage ISERIES -> UNIX pour émuler un existant fonctionnant sur ISeries/DB2 et le porter sur Unix.
Sur Iseries, les requêtes se positionnent sur un enregistrement et effectuent des NEXT sur les enregistrements suivants.
La requête ci-dessous permet de reproduire ce comportement sous ORACLE, en forçant l'utilisation de l'index souhaité pour avoir le tri souhaité. Chaque sous requête retourne les enregsitrements suivants ceux de la sous requêtes précédente suivant les conditions de filtre.
J'avoue , les premières fois (ça pique un peu). Cette émulation nous as posé problème lors de la montée en Oracle 12 avec le paramètre _optimizer_batch_table_access_by_rowid que nous avons été obligé de désactiver pour garantir l'ordre dans les sous requête.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT /*+ FIRST_ROWS INDEX_ASC( ZECHCPB0 IDX_ZECHCPB0) */ ECHCPBETA, ECHCPBPLA, ECHCPBCOM, ECHCPBCMI, ECHCPBDAE, ECHCPBAGI, ECHCPBSTA, ECHCPBMIN, ECHCPBTYM, ECHCPBMAX, ECHCPBTVA, ECHCPBTM1, ECHCPBTT1, ECHCPBMM1, ECHCPBMT1, ECHCPBMR1, ECHCPBTR1, ECHCPBTP1, ECHCPBTM2, ECHCPBTT2, ECHCPBMM2, ECHCPBMT2, ECHCPBMR2, ECHCPBTR2, ECHCPBTP2, ECHCPBTM3, ECHCPBTT3, ECHCPBMM3, ECHCPBMT3, ECHCPBMR3, ECHCPBTR3, ECHCPBTP3, ECHCPBTM4, ECHCPBTT4, ECHCPBMM4, ECHCPBMT4, ECHCPBMR4, ECHCPBTR4, ECHCPBTP4, ECHCPBTM5, ECHCPBTT5, ECHCPBMM5, ECHCPBMT5, ECHCPBMR5, ECHCPBTR5, ECHCPBTP5, ECHCPBTM6, ECHCPBTT6, ECHCPBMM6, ECHCPBMT6, ECHCPBMR6, ECHCPBTR6, ECHCPBTP6, ECHCPBDEV, ECHCPBCUM, ECHCPBBAS, ECHCPBCOV, ECHCPBCOD, ECHCPBTRA, ECHCPBEXO, ECHCPBDAF, ECHCPBPER, ECHCPBTMI, ECHCPBIMI, ECHCPBMMI, ECHCPBRMI, ECHCPBTMA, ECHCPBIMA, ECHCPBMMA, ECHCPBRMA, ECHCPBCET, ECHCPBICN, ID FROM SABSTD.ZECHCPB0 WHERE SAB_MBR = :1 AND ECHCPBETA = :2 AND ECHCPBPLA = :3 AND ECHCPBCOM = :4 AND ECHCPBCMI = :5 AND ECHCPBDAE >= :6 UNION ALL SELECT /*+ FIRST_ROWS INDEX_ASC( ZECHCPB0 IDX_ZECHCPB0) */ ECHCPBETA, ECHCPBPLA, ECHCPBCOM, ECHCPBCMI, ECHCPBDAE, ECHCPBAGI, ECHCPBSTA, ECHCPBMIN, ECHCPBTYM, ECHCPBMAX, ECHCPBTVA, ECHCPBTM1, ECHCPBTT1, ECHCPBMM1, ECHCPBMT1, ECHCPBMR1, ECHCPBTR1, ECHCPBTP1, ECHCPBTM2, ECHCPBTT2, ECHCPBMM2, ECHCPBMT2, ECHCPBMR2, ECHCPBTR2, ECHCPBTP2, ECHCPBTM3, ECHCPBTT3, ECHCPBMM3, ECHCPBMT3, ECHCPBMR3, ECHCPBTR3, ECHCPBTP3, ECHCPBTM4, ECHCPBTT4, ECHCPBMM4, ECHCPBMT4, ECHCPBMR4, ECHCPBTR4, ECHCPBTP4, ECHCPBTM5, ECHCPBTT5, ECHCPBMM5, ECHCPBMT5, ECHCPBMR5, ECHCPBTR5, ECHCPBTP5, ECHCPBTM6, ECHCPBTT6, ECHCPBMM6, ECHCPBMT6, ECHCPBMR6, ECHCPBTR6, ECHCPBTP6, ECHCPBDEV, ECHCPBCUM, ECHCPB BAS, ECHCPBCOV, ECHCPBCOD, ECHCPBTRA, ECHCPBEXO, ECHCPBDAF, ECHCPBPER, ECHCPBTMI, ECHCPBIMI, ECHCPBMMI, ECHCPBRMI, ECHCPBTMA, ECHCPBIMA, ECHCPBMMA, ECHCPBRMA, ECHCPBCET, ECHCPBICN, ID FROM SABSTD.ZECHCPB0 WHERE SAB_MBR = :1 AND ECHCPBETA = :2 AND ECHCPBPLA = :3 AND ECHCPBCOM = :4 AND ECHCPBCMI > :5 UNION ALL SELECT /*+ FIRST_ROWS INDEX_ASC( ZECHCPB0 IDX_ZECHCPB0) */ ECHCPBETA, ECHCPBPLA, ECHCPBCOM, ECHCPBCMI, ECHCPBDAE, ECHCPBAGI, ECHCPBSTA, ECHCPBMIN, ECHCPBTYM, ECHCPBMAX, ECHCPBTVA, ECHCPBTM1, ECHCPBTT1, ECHCPBMM1, ECHCPBMT1, ECHCPBMR1, ECHCPBTR1, ECHCPBTP1, ECHCPBTM2, ECHCPBTT2, ECHCPBMM2, ECHCPBMT2, ECHCPBMR2, ECHCPBTR2, ECHCPBTP2, ECHCPBTM3, ECHCPBTT3, ECHCPBMM3, ECHCPBMT3, ECHCPBMR3, ECHCPBTR3, ECHCPBTP3, ECHCPBTM4, ECHCPBTT4, ECHCPBMM4, ECHCPBMT4, ECHCPBMR4, ECHCPBTR4, ECHCPBTP4, ECHCPBTM5, ECHCPBTT5, ECHCPBMM5, ECHCPBMT5, ECHCPBMR5, ECHCPBTR5, ECHCPBTP5, ECHCPBTM6, ECHCPBTT6, ECHCPBMM6, ECHCPBMT6, ECHCPBMR6, ECHCPBTR6, ECHCPBTP6, ECHCPBDEV, ECHCPBCUM, ECHCPBBAS, ECHCPBCOV, ECHCPBCOD, ECHCPBTRA, ECHCPBEXO, ECHCPBDAF, ECHCPBPER, ECHCPBTMI, ECHCPBIMI, ECHCPBMMI, ECHCPBRMI, ECHCPBTMA, ECHCPBIMA, ECHCPBMMA, ECHCPBRMA, ECHCPBCET, ECHCPBICN, ID FROM SABSTD.ZECHCPB0 WHERE SAB_MBR = :1 AND ECHCPBETA = :2 AND ECHCPBPLA = :3 AND ECHCPBCOM > :4 UNION ALL SELECT /*+ FIRST_ROWS INDEX_ASC( ZECHCPB0 IDX_ZECHCPB0) */ ECHCPBETA, ECHCPBPLA, ECHCPBCOM, ECHCPBCMI, ECHCPBDAE, ECHCPBAGI, ECHCPBSTA, ECHCPBMIN, ECHCPBTYM, ECHCPBMAX, ECHCPBTVA, ECHCPBTM1, ECHCPBTT1, ECHCPBMM1, ECHCPBMT1, ECHCPBMR1, ECHCPBTR1, ECHCPBTP1, ECHCPBTM2, ECHCPBTT2, ECHCPBMM2, ECHCPBMT2, ECHCPBMR2, ECHCPBTR2, ECHCPBTP2, ECHCPBTM3, ECHCPBTT3, ECHCPBMM3, ECHCPBMT3, ECHCPBMR3, ECHCPBTR3, ECHCPB TP3, ECHCPBTM4, ECHCPBTT4, ECHCPBMM4, ECHCPBMT4, ECHCPBMR4, ECHCPBTR4, ECHCPBTP4, ECHCPBTM5, ECHCPBTT5, ECHCPBMM5, ECHCPBMT5, ECHCPBMR5, ECHCPBTR5, ECHCPBTP5, ECHCPBTM6, ECHCPBTT6, ECHCPBMM6, ECHCPBMT6, ECHCPBMR6, ECHCPBTR6, ECHCPBTP6, ECHCPBDEV, ECHCPBCUM, ECHCPBBAS, ECHCPBCOV, ECHCPBCOD, ECHCPBTRA, ECHCPBEXO, ECHCPBDAF, ECHCPBPER, ECHCPBTMI, ECHCPBIMI, ECHCPBMMI, ECHCPBRMI, ECHCPBTMA, ECHCPBIMA, ECHCPBMMA, ECHCPBRMA, ECHCPBCET, ECHCPBICN, ID FROM SABSTD.ZECHCPB0 WHERE SAB_MBR = :1 AND ECHCPBETA = :2 AND ECHCPBPLA > :3 UNION ALL SELECT /*+ FIRST_ROWS INDEX_ASC( ZECHCPB0 IDX_ZECHCPB0) */ ECHCPBETA, ECHCPBPLA, ECHCPBCOM, ECHCPBCMI, ECHCPBDAE, ECHCPBAGI, ECHCPBSTA, ECHCPBMIN, ECHCPBTYM, ECHCPBMAX, ECHCPBTVA, ECHCPBTM1, ECHCPBTT1, ECHCPBMM1, ECHCPBMT1, ECHCPBMR1, ECHCPBTR1, ECHCPBTP1, ECHCPBTM2, ECHCPBTT2, ECHCPBMM2, ECHCPBM T2, ECHCPBMR2, ECHCPBTR2, ECHCPBTP2, ECHCPBTM3, ECHCPBTT3, ECHCPBMM3, ECHCPBMT3, ECHCPBMR3, ECHCPBTR3, ECHCPBTP3, ECHCPBTM4, ECHCPBTT4, ECHCPBMM4, ECHCPBMT4, ECHCPBMR4, ECHCPBTR4, ECHCPBTP4, ECHCPBTM5, ECHCPBTT5, ECHCPBMM5, ECHCPBMT5, ECHCPBMR5, ECHCPBTR5, ECHCPBTP5, ECHCPBTM6, ECHCPBTT6, ECHCPBMM6, ECHCPBMT6, ECHCPBMR6, ECHCPBTR6, ECHCPBTP6, ECHCPBDEV, ECHCPBCUM, ECHCPBBAS, ECHCPBCOV, ECHCPBCOD, ECHCPBTRA, ECHCPBEXO, ECHCPBDAF, ECHCPBPER, ECHCPBTMI, ECHCPBIMI, ECHCPBMMI, ECHCPBRMI, ECHCPBTMA, ECHCPBIMA, ECHCPBMMA, ECHCPBRMA, ECHCPBCET, ECHCPBICN, ID FROM SABSTD.ZECHCPB0 WHERE SAB_MBR = :1 AND ECHCPBETA > :2

Mais je m'égare. Mon pb initial était de comprendre l'origine des requête SELECT x from T AS SCN et de comprendre leur impact sur les événements d'attente remontés dans l'AWR et notamment les 73% DBTIme.

Je ne comprend pas très bien non plus les attentes db file sequentiel read et le read by other session lors de la requête d'INSERT.

Ci-dessous les différentes captures demandées

[Ikebukuro]

Comme je disais, la requête suivante permet d'interroger ta table ZMOUANA0 dans le passé, lorsque le SCN valait 22265335847.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT "MOUANAANN", "MOUANANUM", "MOUANAOOP" FROM ZMOUANA0 AS OF SCN 22265335847 WHERE MOUANADOP >= 1220407 AND MOUANAETA = 1;

Autre remarque, c'est normal d'avoir autant de hints dans tes requêtes, notamment le FIRST_ROWS?