Discussion :

[skyarnangel]

Bonjour,

ALTER INDEX XXX REBUILD COMPUTE STATISTICS PARALLEL

ERROR at line 1:
ORA-12801: error signaled in parallel query server YYY
ORA-01410: invalid ROWID

J'attends un peut, je recommence l'opération même résultat.
Du coup j'ai cherché sur le net et trouvé que l'invalid rowid pouvait provenir d'une migration (Ce qui est possible puisqu'on est passé de la 9i à la 10g il y a quelques mois déjà).

j'ai trouvé une solution de contournement : effectuer un rebuild online qui d'après ce que j'ai compris reconstruit un nouvel index tout en laissant l'ancien jusqu'à ce que le nouveau soit terminé et supprime l'ancien (ça permet en autre de rebuild un index sans intéruption des requêtes qui l'utilise).

Une fois ce rebuild effectué, je reprends ma première requête qui s'exécute sans encombre.

Quelques jours plus tard, mon traitement qui utilise la première requête tombe encore pour le même problème.

Je pense que le problème vient du rowid de la table mais je ne sais pas comment le mettre à jour sans faire un export/import ?

Pouvez vous m'aider svp ?

Merci d'avance.

[pacmann]

Salut,

dbms_redefinition peut être ?
http://docs.oracle.com/cd/B19306_01/...8/d_redefi.htm

[skyarnangel]

Merci pour votre retour réponse.

En revanche, ca me parait un peu compliqué à mettre en place.

Pensez vous qu'un simple transfert de table peut résoudre mon problème ?

En gros dans l'idée faire ceci :

Code :

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

1
2
3
Create table X1 as select * from table X2;
Drop table X2;
Create table X2 as select * from table X1;

Ca devrait me donner de nouveaux rowid non ?

[pacmann]

Oui tout à fait, mais je pensais pas que ça te conviendrait, vu que tu ne voulais pas d'import / export

[skuatamad]

Je pense que le problème vient du rowid de la table mais je ne sais pas comment le mettre à jour sans faire un export/import ?

Peut être en utilisant move :

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
SQL> create table test as select level as lvl from dual connect by level <= 10;
 
Table created.
 
SQL> select rowid, lvl from test;
 
ROWID                     LVL
------------------ ----------
AAAMalAABAAALIRAAA          1
AAAMalAABAAALIRAAB          2
AAAMalAABAAALIRAAC          3
AAAMalAABAAALIRAAD          4
AAAMalAABAAALIRAAE          5
AAAMalAABAAALIRAAF          6
AAAMalAABAAALIRAAG          7
AAAMalAABAAALIRAAH          8
AAAMalAABAAALIRAAI          9
AAAMalAABAAALIRAAJ         10
 
10 rows selected.
 
SQL> alter table test move;
 
Table altered.
 
SQL> select rowid, lvl from test;
 
ROWID                     LVL
------------------ ----------
AAAMamAABAAALIZAAA          1
AAAMamAABAAALIZAAB          2
AAAMamAABAAALIZAAC          3
AAAMamAABAAALIZAAD          4
AAAMamAABAAALIZAAE          5
AAAMamAABAAALIZAAF          6
AAAMamAABAAALIZAAG          7
AAAMamAABAAALIZAAH          8
AAAMamAABAAALIZAAI          9
AAAMamAABAAALIZAAJ         10
 
10 rows selected.
 
SQL>

[skyarnangel]

Je n'ai pas pensé au move.

Je pense que cette solution est la meilleures, puisqu'elle conservera les objets liés à la table

Merci skuatamad

[pachot]

Bonjour,
Le rebuild offline d'un index utilise l'ancien index pour construire le nouveau. Donc s'il y a une corruption logique (ou bug -> dans ce cas ouvrir un SR), on a cette erreur.
Pour contourner, il suffit probablement de mettre l'index unusable avant: ALTER INDEX XXX UNUSABLE

Pensez vous qu'un simple transfert de table peut résoudre mon problème ?

Non: l'erreur invalid ROWID vient de l'index, pas de la table. Mais vu que le MOVE va de toute façon mettre les index unusable...

COMPUTE STATISTICS

C'est quelle version pour préciser COMPUTE STATISTICS ? les versions récentes font un COMPUTE STATISTICS par défaut.

Cordialement,
Franck.

[Mohamed.Houri]

Peut être en utilisant move :

Ce n'est pas le move de la table en soi qui résout le problème. Mais c'est parce que le move de cette table provoque "l'inusabilité" de ses indexes (unusable) vous conduisant à refaire un rebuild de ces indexes. Toute la question vient de l'existence d'un problème dans l'index relativement à la table sur laquelle il est créé. Si vous reconstruisez votre index offline (corrompu, invalid rowid, etc...) vous allez utiliser le même index pour reconstruire le même index; ce qui conduira forcément aux mêmes conséquences.

Donc, dans ce genre de situation, il faut reconstruire l'index sur la base des données de sa table et non sur la base de ce même index.

Comment?

1. en faisant un rebuild online
2. en faisant un rebuild (même offline) d'un index unusable
3. drop index; recreate index

Je n'ai, pour ainsi dire, pas besoin de faire un move de la table. il me suffit de mettre mon index dans un statut unusable et de le reconstruire offline. Ou de le reconstruire online sans l'avoir mis dans un statut unusable.

Voici deux liens qui traitent un sujet ressemblant à celui soulevé ici.

problematic index part II
problematic index part I

[skuatamad]

Ce n'est pas le move de la table en soi qui résout le problème.

Ma réponse ne concernait que la modification du rowid de la table comme indiqué en citation.

N'étant pas dba, je n'avais pas la prétention de résoudre le problème, et je découvre les subtilités de certaines commandes en lisant les très bonnes interventions des dba du forum

[mnitu]

...Une fois ce rebuild effectué, je reprends ma première requête qui s'exécute sans encombre.

Quelques jours plus tard, mon traitement qui utilise la première requête tombe encore pour le même problème.
....

Si quelques jours plus tard c'était juste au moment d'une autre opération de reconstruction de l'index c'est peut être "normal." Index Rebuild