Discussion :

[genio]

Bonjour, j'ai un petit problème à résoudre...
Nous avons un package de prod assez long qui effectue des mises à jour de tables, donc avant de le lançer, nous mettons les Index Unusable, pour ensuite les reconstruire... ce traitement fonctionne très bien !
Quand nous le passons en test, après avoir mis les Index UNUSABLE, le traitement plante en

ORA-1502 : Index 'TOTO' or partition of such index is in unusable state...

Questions : Pourquoi le traitement se plante-t-il en test et pas en prod ? Est-ce une question de paramétrage ? Et que faut-il faire pour que cela ne se reproduise pas ?

Merci pour vos réponses...

PS : Unix AIX... Oracle version 9.2.0.1

[genio]

J'ai oublié de vous dire que les deux traitements passent avec :
alter session se SKIP_UNUSABLE_INDEXES = TRUE... que les index unique et bitmaps ne sont pas mis UNUSABLE, et que mes index sont identiques entre la prod et le test !


Merci pour vos réponses !

[aline]

ce qui m'étonne, c'est que tu passes en prod un traitement qui ne passe pas en test!!

[genio]

De la vient justement ma question... qu'est-ce qui peut faire que le trt passe en prod et pas en test ?

[pifor]

Cela pourrait venir du fait que l'index est unique ou utilisé par une contrainte. Mais est-tu absolument sûr que toutes les tables ont les mêmes index en test et en prod et que les paramètres du .ini sont généralement identiques ?

[pifor]

Il faudrait vérifier avec EXPLAIN PLAN sur la requête en erreur que le plan d'execution généré est le même en test et en production.
Est-ce que les statistiques sont mises à jour de la même façon sur les 2 bases ?

[genio]

Merci pour tes réponses.. justement je m'essaie à l'explain (je suis encore un petit scarabée !) mais je n'arrive pas à alimenter ma plan_table... je l'ai bien créée, j'ai effectué l'EXPLAIN, mais elle reste déséspérement vide...
Saurais-tu me dire pourquoi...

Voici ma commande d'explain :

explain plan set statement_id='tutu_select' into monschéma.plan_table for
SELECT Madonnée
FROM tutu.table_IND
WHERE Donnée1 = :toto
AND donnée2= :tutu ;

J'ai essayé avec la commande suivante :

explain plan for
SELECT Madonnée
FROM tutu.table_IND
WHERE Donnée1 = :toto
AND donnée2= :tutu ;

Rien n'y fait !

Merci pour ta réponse...

PS : J'ai donné le rôle PLUSTRACE à Monschéma

[Jaouad]

Peux t'on avoir le code SQL sui génère cette erreur

[genio]

Le voilà !

Open CURSOR cu_vm (cu_no_pol_off VARCHAR2, cu_cd_cvt VARCHAR2, cu_cd_typ_prd VARCHAR2, cu_cd_uct VARCHAR2, cu_cd_ste VARCHAR2) IS
SELECT NO_POL_OFF
FROM VMVIE_IND
WHERE NO_POL_OFF = cu_no_pol_off
AND CD_CVT = cu_cd_cvt
AND CD_STE = cu_cd_ste
AND CD_TYP_PRD = cu_cd_typ_prd
AND NVL(CD_UCT,'XXXXXX') = NVL(cu_cd_uct,'XXXXXX');

[genio]

Merci Pifor pour tes conseils.. en effet les stats n'étaient pas à jour mais cependant, je ne m'explique pas pourquoi (et peut-être Jaouad où toi pouvez-vous me renseigner !) ) l'index incriminé a fait planter l'ordre select en ORA-1502...
Je m'explique : Sur metalink, ils disent que le SKIP_UNUSABLE_INDEX n'empêche pas le plantage si l'index est UNIQUE ou s'il 'applique une contrainte' (Là j'ai pas bien compris ce qu'ils voulaient dire !)
OR
mon index etait NON-UNIQUE, son statut 'UNUSABLE' avec SKIP_UNUSABLE_INDEX = TRUE... Donc, ça n'aurait pas dû planter !

Moi, je pense que, les stats étaient dans les choux et que le select s'est perdu dans les limbes de l'optimiseur Oracle...
Est-ce une honorable conclusion ?
Merci pour vos réponses