[Oracle 10g]ORA-25143: default storage clause [Résolu]

[userB]

Bonjour à tous,

J'ai recement créé plusieurs tablespaces de cette facon :

Code :

1
2
3
4
5
 
CREATE TABLESPACE IND_XL	
DATAFILE '/data/ora/Mondbf.dbf'
SIZE 80M REUSE AUTOEXTEND ON next 20M MAXSIZE 300M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K ;

Malheureusement j'ai besoin maintenant de modifier l'extent, fastoche je me suis dis, et je me suis empressé d'essayer ceci (trouver sur le net)

Code :

1
2
 
ALTER TABLESPACE IND_XL MINIMUM EXTENT 4M;

Seulement voila, message d'erreur :

Code :

1
2
 
ORA-25143: DEFAULT storage clause IS NOT compatible WITH allocation policy

Alors je fouille un peu sur le net et je trouve qu'il suffit de "omit the default storage".
Alors moi je veux bien mais meme apres recherche j'ai pas trouver comment m'y prendre. Des idées ?

[Heaven93]

en locally managed, on ne peut pas choisir le minextents, le maxextents, le next, et pctincrease.
tu voulais modifier quoi au fait? taille de l'extent, ou bien nombre minimum d'extents?

[userB]

je voulais modifier la taille de l'extent, le passer de 64K à 4M.

Mais tu sous entends que c'est impossible en l'état c'est bien ca ?

[Heaven93]

vivi, j'en ai bien peur. tu dois dropper ton TBS pour le créer de nouveau avec une clause locally managed uniform size 4M, et le faire plus grand dans ce cas, car 80M ou 300 au plus, ce n'est pas beaucoup...

[userB]

Uniquement pour augmenter la taille des extent je dois drop et recreer mes tablespace...

Ca me parait violent quand meme

[philcero]

Tu ne peux changer la taille de ton EXTENT pour la simple raison que Oracle créé une multitude de BITMAP INDEX où chaque BIT correspond à un EXTENT et indiquent si :

• celui-ci est occupé ou non.
• à qui il appartient.
• ...etc...etc...

Bref il y a une relation mathématique directe & incontournable qui fait que cette taille ne peut changer.

Maintenant rien ne t'empêche de changer les clauses de tes objets (tables & indexs) qui sont dedans.

[userB]

Tres bien, c'est bien plus compliqué que je ne croyais.

Et je continu (malheureusement) mes deboires.

1- J'ai créé de nouveaux tablespaces avec cette fois la bonne taille d'extent.

2- J'ai deplacé tous les objets de mes anciens tablespaces vers mes nouveaux

3- J'ai droppé les anciens tablespaces

4 - J'ai renommé les nouveaux tablepaces et datafiles avec le noms des anciens.

Seulement voila, lorsque je veux repasser mes tablespaces disposant de datafile fraichement renommés en ONLINE, j'ai un somptueux message d'erreur (tres inquietant au demeurant) me disant :

Code :

1
2
3
4
5
6
7
8
 
SQL> ALTER TABLESPACE Mon_TBS ONLINE;
ALTER TABLESPACE Mon_TBS ONLINE
*
ERROR at line 1:
ORA-01122: DATABASE file 12 failed verification CHECK
ORA-01110: DATA file 12: '/data/ora/ORA_SID/u03/Mon_TBS/Mon_TBS_01.dbf'
ORA-01251: Unknown File Header Version READ FOR file number 12

Et là, un effroie indescriptible me parcourt l'echine... apres de nombreuses recherches sur le net je n'ai absolument rien trouvé.

Pour l'instant j'ai 2 pistes :

• Cause 1 : Lors de mon deplacement des segments j'ai oublié de mettre ma variable NLS_LANG à french (elle est malheureusement à american par defaut)
• Cause 2 : La taille des nouveaux extents, je m'explique, je disposais de segment "formatés" à 64Ko et la, je les deplace dans des TBS qui disposent d'extent d'une taille de 4M voir parfois 16M !

En esperant que vous pourrez m'aider.

Desesperement,
userB

[orafrance]

Envoyé par userB

4 - J'ai renommé les nouveaux tablepaces et datafiles avec le noms des anciens.

t'as fait ça comment ?

[userB]

J'ai fais ca en plusieurs etapes :

• Je passe le tablespace OFFLINE : ALTER TABLESPACE MonTBS OFFLINE;
• Je renomme le datafile avec la commande unix mv
• Je fais un alter de mon tablespace pour lui dire que le chemin de son datafile a ete modifié :
  
  Code :

  1
  2
  3
  4
  ALTER TABLESPACE MonTbs
    RENAME DATAFILE '/data/ora/ORASID/u03/ancienPath/AncienNomdeDBF.dbf'
      TO '/data/ora/ORASID/u03/NewPath/NewNomdeDBF.dbf';    
  ALTER TABLESPACE MonTbs ONLINE;

[orafrance]

je crains que le move soit mal passé

[userB]

Si ce n'est que ca je suis à moitié rassurer.

Je suis en train de me remonter une nouvelle base de prototypage (mais c'est long...), pour la peine tu me conseillerai de renomer mes datafile de quelle facon ?

[orafrance]

Finalement t'as pas répondu à la bonne question

J'ai renommé les nouveaux tablepaces et datafiles avec le noms des anciens.

tu l'as renommé comment le tablespace ?

[userB]

Ah pardon, et bien pour renommer le tablespace j'ai fait :

Code :

1
2
 
ALTER tablespace MonTbs_new RENAME TO MonTbs;

Suite à ca j'ai successivement :

• Passer mon Tablespace offline
• Renommer via la commande mv le nom du datafile, puis le nom du repertoire contenant le datafile
• Effectuer la commande ALTER TABLESPACE que j'ai posté au dessus pour specifier à ORACLE que le datafile avait ete modifier
• Tenté de repasser le Tablespace ONLINE

Et c'est lorsque j'essai de remettre mon Tablespace ONLINE que le drame arrive.

ps : pour information je suis sur une 10g

[orafrance]

un recover est peut-être nécessaire

[orafrance]

essaye en copiant le fichier plutôt qu'un move.

[userB]

Un recover ca ne me parle pas du tout.

Je vais essayer en copiant, je vous tiens au courrant.

ps : En tout cas merci pour ton aide precieuse

[orafrance]

Code :

RECOVER DATAFILE 12;

[userB]

Probleme resolu

Alors le fond du probleme venait du fait que lorsque je supprimais mes anciens TABLESPACE j'utilisai uniquement la commande DROP sans utiliser DROP ... CONTENTS INCLUDING DATAFILE.

Du coup lorsque je faisais mes mv pour renommer mes nouveaux datafiles (qui venaient de recuperer tous les anciens segments), dans le nom des anciens datafiles (non supprimés) il devait y avoir des conflits. De ce fait il etait impossible pour ORACLE de les remettre ONLINE.

Merci à tous pour votre aide !