AWR et traces suite régression de performances

Citation:

---

Envoyé par pachot

et de la rendre la plus optimale: l'idéal serait qu'elle ne lise qu'un seul block.

---

comment faire pour lire 1 seul block ? une technique particulière ?
Je pense aussi utiliser le result_cache (nouveauté 11g).
Votre avis ?
Merci.:ccool:

Citation:

---

Effectivement cela se passe comme vous l'avez décrit.
Dois-je utiliser l'appel avec CALL <package>.<procedure> depuis l'interface.
Si oui ce genre d'appel nécessite-il un changement du mécanisme d'appel existant depuis l'interface ? existe-il des restrictions ?

Je n'ai pas l'intention de changer la valeur par défaut de ce paramètre(EXACT) qui en plus demeure la valeur par défaut en 12c (voir le commentaire de Franck).
----------------

---

Si vous utilisez les variables de liaison il n’est donc plus question de mettre le cursor_sharing à FORCE ni de changer les appels BEGIN/END par des CALLS.

Citation:

---

Une autre question SVP :
Dans cette application j'ai une petite requête simple du type

Code:

---

select statut from table_surveillance where...

---

Cette requête est planifiée pour s'exécuter toutes les 4 secondes pour surveiller l'arrivée de flux et déclencher un traitement.
Elle apparaît toujours dans mon rapport AWR : Dois-je me méfier de ce genre de requête très rapide mais consommatrice au final et étudier par exemple la possibilité de réduire la fréquence de leur exécution afin de soulager les ressources machine ou c'est minime comme gain ?
merci.

---

Est-ce que cette requête utilise les variables de liaison ou non ? Lorsque vous dites que cette requête apparaît toujours dans mon rapport AWR, est-ce dans la partie SQL ordered by Executions/by Version Count/by Parse Call ?
Il faut veiller à ce que cette requête soit ’’parsée’’ une fois et exécutée plusieurs fois surtout si elle est exécutée trop souvent.

Faite une trace SQL du traitement. Apprenez où le temps passe et abandonner la stratégie de la devinette. Si votre requête prends 2 pourcent du temps total de traitement, l’améliorer pour qu’elle prend seulement 0,01 % qu’est ce que ça va vous rapporter sur le temps global du traitement ?

Bonjour,

Citation:

---

Envoyé par devkais

Je pense aussi utiliser le result_cache (nouveauté 11g).
Votre avis ?

---

Result cache... L'idée serait que la table est statique (donc résultat en cache) jusqu'au moment où il y a un enregistrement. C'est une bonne idée... à tester...

Citation:

---

Envoyé par devkais

comment faire pour lire 1 seul block ? une technique particulière ?

---

Ça dépend de la table et de la requête. Si la table est très petite - avec un seul bloc de données, la créer en IOT permet de lire un seul block au lieu de 2:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

SQL> create table "TEST" (key primary key,dummy) organization index as select 1,dummy from dual;   Table created.   SQL> exec dbms_stats.gather_table_stats(user,'TEST');   PL/SQL procedure successfully completed.   SQL> select * from test where key=1;   KEY D ---------- - 1 X   SQL> set autotrace on SQL> /   KEY D ---------- - 1 X     Execution Plan ---------------------------------------------------------- Plan hash value: 3684383379   ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 5 | 0 (0)| 00:00:01 | |* 1 | INDEX UNIQUE SCAN| SYS_IOT_TOP_1019314 | 1 | 5 | 0 (0)| 00:00:01 | -----------------------------------------------------------------------------------------   Predicate Information (identified by operation id): ---------------------------------------------------   1 - access("KEY"=1)     Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 1 consistent gets 0 physical reads 0 redo size 383 bytes sent via SQL*Net to client 337 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed   SQL> set autotrace off SQL> drop table "TEST";

---

Pour une table plus grande, un cluster peut être un solution aussi:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

SQL> create cluster "TEST" (key number) single table hashkeys 1;   Cluster created.   SQL> create table "TEST" (key primary key,dummy) cluster "TEST"(key) as select 1,dummy from dual;   Table created.   SQL> exec dbms_stats.gather_table_stats(user,'TEST');   PL/SQL procedure successfully completed.   SQL> select * from test where key=1;   KEY D ---------- - 1 X   SQL> set autotrace on SQL> /   KEY D ---------- - 1 X     Execution Plan ---------------------------------------------------------- Plan hash value: 3196095947   --------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| --------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 5 | 0 (0)| |* 1 | TABLE ACCESS HASH| TEST | 1 | 5 | | ---------------------------------------------------------------   Predicate Information (identified by operation id): ---------------------------------------------------   1 - access("KEY"=1)     Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 1 consistent gets 0 physical reads 0 redo size 383 bytes sent via SQL*Net to client 337 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed   SQL> set autotrace off SQL> drop table "TEST";   Table dropped.   SQL> drop cluster "TEST";

---

Cordialement,
Franck.

Que pensez-vous de la technique Oracle Advanced Queuing pour surveiller l'arrivée d'un flux au niveau de la file d'attente au lieu d'exécuter une requête toute les 2s ?
Packages à utiliser : DBMS_AQ et DBMS_AQADM
merci.

Oui, Advanced Queuing est une bonne solution pour ça.
La solution Result Cache est aussi un bon workaround si on ne peut pas modifier le design de l'appli.