Lenteur base de données depuis copie des tables avec SQLDEVLOPER

Bonsoir

J'ai copié les tables de la base1 en Oracle11R2 vers la base2 Oracle11R2 avec SQLDEVLOPPER et depuis ma base2 semble tres lente ?
J'ai rebuildé tous les index, mais sans résultats ?

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

1 pour le rebuild des index SELECT ' ALTER INDEX ' || INDEX_NAME || ' REBUILD ; ' FROM USER_INDEXES     Les resultats de rapidite me semble bien long ? select a.begin_time, a.end_time, round(((a.value + b.value)/131072),2) "GB per sec" from v$sysmetric a, v$sysmetric b where a.metric_name = 'Logical Reads Per Sec' and b.metric_name = 'Physical Reads Direct Per Sec' and a.begin_time = b.begin_time;   01/06/17 01/06/17 2,36 01/06/17 01/06/17 2,35     select to_char(begin_time,'hh24:mi') time, round( value * 10, 2) "Response Time (ms)" from v$sysmetric where metric_name='SQL Service Response Time';   06:55 10,52     Puis un full stat EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=>'mabase',DEGREE=>16, CASCADE=>TRUE);

---

Merci de votre aide

As-tu lancé les stats sur tes tables de la base 2 ?

bonsoir

Je viens de lancer un full stat, je verrais cela mardi, c'est une base de test

la commande est toujours aussi lente ce matin

Code:

---

1 2 3

select to_char(begin_time,'hh24:mi') time, round( value * 10, 2) "Response Time (ms)" from v$sysmetric where metric_name='SQL Service Response Time';

---

Citation:

---

27,22

---

Collectez plus d'infos via AWR si vous avez la licence ou statspack ou encore via la trace étendu d'un traitement lent.

Hello,
dans ce cas j'ai pour habitude de récupérer le sql_id de la requête et de visualiser sont historique d'exécution. Si hash_value différent, alors vérifier les steps différents dans le plan d'exécution et les objets ayant de mauvaises cardinalité et/ou des nouvelles statistiques.
Sinon, en mode "fast", un petit refresh des stats sur les fixed tables peut aider :

Code:

---

1 2 3 4

select count(*) from sys.tab_stats$; exec DBMS_STATS.GATHER_FIXED_OBJECTS_STATS select count(*) from sys.tab_stats$;

---

Sur une de mes bases (en 11.2.0.4) c'est intantané :

Code:

---

1 2 3 4 5 6 7 8 9 10

------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5 | 245 | 1 (100)| 00:00:01 | |* 1 | FIXED TABLE FULL| X$KEWMDRMV | 5 | 245 | 1 (100)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"='SQL Service Response Time' AND "FLAG1"=1 AND ("GROUPID"=2 OR "GROUPID"=3) AND "INST_ID"=USERENV('INSTANCE'))

---

Idem en 12.1.0.2 :

Code:

---

1 2 3 4 5 6 7 8 9 10

------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 96 | 8 (100)| 00:00:01 | |* 1 | FIXED TABLE FULL| X$KEWMDRMV | 2 | 96 | 8 (100)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"='SQL Service Response Time' AND "FLAG1"=1 AND ("GROUPID"=2 OR "GROUPID"=3) AND "INST_ID"=USERENV('INSTANCE'))

---

oups, j'ai cru que c'était la requête sur v$sysmetric qui était longue.
C'est le SQL Service Response Time qui affiche une valeur élevé.

Dans ce cas, comme dit mnitu, un awr devrait t'indiquer les principales attentes, les requêtes les plus consommatrices et les temps d'accès aux datafiles.