Action post create index

Version imprimable

23/07/2022, 14h26
agdid04

Action post create index

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.
23/07/2022, 15h18
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.
23/07/2022, 15h36
agdid04

Merci de réponse rapide :ccool::ccool:

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+
23/07/2022, 17h38
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 !
23/07/2022, 18h33
Ikebukuro

Citation:

Envoyé par agdid04

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;
24/07/2022, 15h07
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.

Bonjour

Citation:

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:

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

Citation:

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:

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

Bien à vous

24/07/2022, 18h06
agdid04

Merci bien pour toutes réponses.

Une dernière question: pendant la création de nouveau index => l'accès à la table par les autres requêtes utilisant d'autres index reste ouvert ?

L'impact de a création de ce nouveau index c'est plus sur la charge serveur ?

MERCI.

A+
25/07/2022, 14h44
dari68

Bonjour,

Si vous êtes en EE y a l'option CREATE INDEX ONLINE.

A+