Discussion :

[agdid04]

Bonjour,

Je me demande s il faut reclaculer les stats sur une table après la création d'un nouveau index sur grosse table ? Puisq'il y a eu déjà parsing sans index.

La création d'index dure plus de 2h, pendant ce temps: la table est accessible ? accès perturbé ?

MERCI.

[Ikebukuro]

Salut,

Quand tu fais un CREATE INDEX, Oracle calcule déjà les stats sur ton index, donc de ce côté là, tu n'as rien à faire.
Pour la table, je ne vois pas pourquoi tu vas recalculer les stats de ta table vu que la création d'un index n'a aps d'impact sur le contenu de ta table.

Si la création de ton index dure 2 heures, alors oui, cela risque de ralentir les opérations sur toute ta base et pas que sur ta table. La création d'un index réclame des ressources qui, forcément penda nt ce moment là, ne seront pas disponibles pour les autres opérations.

[agdid04]

Merci de réponse rapide

Maintenant si j'ai déjà un index sur la colonne (A) par exemple puis je créé un nouveau index composé sur les colonnes (A,B): est ce que ce 2ème index composé risque de perturber les requêtes qui utilisent déjà le 1er index sur la colonne (A) ?

MERCI.

A+

[dell68]

Il faudra que tu fasse ça sur une base de test :
en mettant l'ancien index en mode invisible et tu regarde si les nouvelles requêtes utiliseront le nouvel index que
tu viens de créer est-ce que ceci est bénéfiques ou on ?????
A propos du calcul de la table volumineuse tu peux utiliser ce lien pour le calcul des statistiques en mode parallèle ??
voici un exemple de calcul des statistiques sur un schéma entier qui utilise le mode concurrent sur une base de version 12c :
http://ahmedaangour.blogspot.com/201...s-et-mode.html

bonne chance !

[Ikebukuro]

Maintenant si j'ai déjà un index sur la colonne (A) par exemple puis je créé un nouveau index composé sur les colonnes (A,B): est ce que ce 2ème index composé risque de perturber les requêtes qui utilisent déjà le 1er index sur la colonne (A) ?

Si tu as un index sur la colonne A, celui sur les colonnes A et B fera doublon... tu peux donc supprimer celui sur la colonne A seule;

[agdid04]

Bonjour,

MERCI des retours.

Et pour les requêtes qui utilisent index sur la colonne (B): vont pas utiliser l'index composite sur les 2 colonnes (A,B) ? continueront à utiliser index sur (B)?

MERCI.

[Mohamed.Houri]

Bonjour

Je me demande s il faut reclaculer les stats sur une table après la création d'un nouveau index sur grosse table ? Puisq'il y a eu déjà parsing sans index.

Vous n'avez pas besoin de recalculer les stats pour invalider le cursor qui est dans le cache. L'invalidation est automatique à la fin de la création d'un index

Code :

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

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
64
65
66
67
68
69
70
71
SQL> select * from t1 where n3=10;
 
        N1         N2         N3 F DAT1
---------- ---------- ---------- - --------
        11          1         10 Y 11/01/22
 
SQL> @xpsimp
 
 
SQL_ID  bxawy4mb85hss, child number 0
-------------------------------------
select * from t1 where n3=10
 
Plan hash value: 3617692013
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |  1086 (100)|          |
|*  1 |  TABLE ACCESS FULL| T1   |     1 |    23 |  1086   (2)| 00:00:01 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("N3"=10)
 
 
SQL> create index t1_idx_n3 on t1(n3);
 
Index created.
 
SQL> @gvsql
Enter value for sql_id: bxawy4mb85hss
 
SQL_ID        CHILD_NUMBER B B EXECUTIONS  END_FETCH INVALIDATIONS OBJECT_STA
------------- ------------ - - ---------- ---------- ------------- ----------
bxawy4mb85hss            0 N N          1          1             2 INVALID_UNAUTH
 
 
SQL> select * from t1 where n3=10;
 
        N1         N2         N3 F DAT1
---------- ---------- ---------- - --------
        11          1         10 Y 11/01/22
 
SQL> @xpsimp
 
SQL_ID  bxawy4mb85hss, child number 0
-------------------------------------
select * from t1 where n3=10
 
Plan hash value: 3886713857
 
-------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |       |       |     4 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| T1        |     1 |    23 |     4   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | T1_IDX_N3 |     1 |       |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("N3"=10)
 
 
SQL> @gvsql
Enter value for sql_id: bxawy4mb85hss
 
SQL_ID        CHILD_NUMBER B B EXECUTIONS  END_FETCH INVALIDATIONS OBJECT_STA
------------- ------------ - - ---------- ---------- ------------- ----------
bxawy4mb85hss            0 N N          1          1             2 VALID

Et pour les requêtes qui utilisent index sur la colonne (B): vont pas utiliser l'index composite sur les 2 colonnes (A,B) ? continueront à utiliser index sur (B)?

Pour qu'un index soit considéré par Oracle lors de l'optimisation d'un plan d'execution pour une requête, Il est très important pour cet index qu'il commence par au une (ou plusieurs) colonne figurant dans la partie prédicat de cette requête. Et de préférence sur un prédicat d'égalité.

Pour répondre à votre question, un index (A,B) ne sera pas utilisé pour couvrir des requêtes ayant ce genre de pédicats

Code :

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

1
2
3
4
 
 where
      b = xx
and c = zz

Bien à vous