Bonjour,
 
Je suis en train de bosser sur Oracle 9.2.0.8.0 avec une grosse base bien remplie (85 Gigas). Le tout sur du Unix AIX 5.3. Ma base est composée des plusieurs tablespaces et chaque tablespace est composé de plusieurs fichiers des données.
 
J'aimerai pouvoir réorganiser mon tablespace TOTO composé de 3 fichiers de données (toto1.dbf, toto2.dbf et toto3.dbf) de 10 Gigas chacun.
J'aimerai me retrouver avec seulement 2 fichiers de 15Gigas.
 
Pour cela, j'ai pensé à faire
 
1) Export de mon tablespace avec la commande suivante:
exp userid=SYSTEM/<mon_mot_de_passe> file=/exportbase/tablespace_TOTO.dmp log=/exportbase/tablespace_TOTO.log consistent=yes
 
2) Mettre le tablespace TOTO en Offline
 
3) Casser mes 3 fichiers datafiles (toto1.dbf, toto2.dbf et toto3.dbf)
 
4) Recréer 2 fichiers datafiles (toto1.dbf, toto2.dbf) de 15 Gigas chacun.
 
5) Faire un import de mes données grace à l'export précédement crée.
 
 
 
Ma procédure est elle correcte ?
Je dois effectuer cette opération pour un tablespace contenant des données (TOTO), puis pour un tablespace contenant des index (IDX_TOTO). Ma commande d'export est elle correcte ? Toutes les données de ma tables seront exportée (mes contraintes d'intégrité, vues éventuelles, grant, etc) ?
 
La difficulté dans l'histoire, c'est que je ne sais pas exactement ce que contient chaque tablespace (données, index, vues, procédures stockées, etc).
Donc il faudrait que j'arrive à faire des export qui prennent TOUT ce qu'il y a dans mes tablespaces.
Et SURTOUT, il faut que la base redémarre entièrement après ces opérations. Sinon, je vais me faire ...      
 
 
Si vous pouvez m'aider, je vous en remercie !

déjà pour commencer, faut le faire sur une base de test, et avoir des sauvegardes, on manipule pas n'importe comment
ensuite pourquoi veux-tu avoir 2 datafiles au lieu de 3 ? fondamentalement ca change pas grand chose
 
sinon sur le principe, ouais ca marche, mais je te conseillerais plutôt de ne pas péter tout de suite ton tablespace composé des 3 datafiles, mais plutot de le renommer. Tu le feras sauter que quand tout sera OK
 
pour voir le contenu d'un tablespace tu peux regarder la vue DBA_SEGMENTS et filtrer sur la colonne TABLESPACE_NAME. Les colonnes SEGMENT_NAME et SEGMENT_TYPE t'aideront à voir le contenu exact

sinon pour le tablespace d'index, c'est relativement simple, tu peux faire une palanquée de

ALTER INDEX monindex REBUILD TABLESPACE nouveau_tbs

l'avantage c'est que tu vas tout reconstruire proprement et tu vas potentiellement gagner de la place dans le tablespace

Bonjour,
 
Merci pour ta réponse, je vais essayer comme ça.
 
Pour répondre a ta question, je suis prestataire chez un client et c'est le client qui veut ça... JE sais bien que c'est con, mais le client et roi    
 
Et pas d'inquiétude. J'ai une machine en production et une machine en qualification (branche de test). C'est justement parce que la machine de qualification n'est pas pareille que celle de production qu'il faut que je me démerde pour la remetre "ISO-prod" comme ils disent ici.
 
J'ai bien fait des sauvegardes dans tous les sens, export full + copie de tous les DBF dans un coin, au cas où ...
 
 
 
Encore merci

les DBF ne te serviront à rien si tu n'as pas le controlfile associé, soit tu fais un backup des fichiers à froid (base éteinte) soit tu fais un BEGIN BACKUP
mais de tte facon d'un point de vue données, l'export full est suffisant
 
sinon pour ta procédure :
- ta commande d'export doit posséder l'option FULL=Y
- si tu n'as qu'un seul schéma qui possède toutes les données sur ces tablespaces le mieux est de faire un DROP CASCADE du schéma et de le recréer, car l'import ne marchera pas si tes objets sont encore présents, et ne marchera pas non plus si le user n'est pas crée
- ton import peut se contenter d'un FROMUSER=ton_user si t'es dans le cas précédemment cité
 
mais bon comme y'a pas assez de détails cette procédure peut être complètement fausse
si ca trouve tu as plusieurs schémas, les données du schéma sont sur d'autres tablespaces qu'il ne faut pas toucher, tu n'as pas le mot de passe du user, etc.

Oui, quand je te disais copie des DBF, c'était une copie à froid, avec les fichiers de contrôles associés... Sinon je sais bien que la base est pas d'accord au redémarrage si elle n'a pas les bons CTL    
 
Mes réponses :
 
- OK, je rajoute ça à ma ligne. Je pensais que cette option servait à faire un export full de la base, je ne savais pas qu'il la fallait pour un export de tablespace. J'aurai du lire la doc avant, c'est vrai ...
- J'ai les deux cas en fait un tablespace avec tout les infos qu'il contient appartenant au schéma XXXX et un autre tablespace avec avec des données appartemant un peu à tout le monde    
- OK, je verrai ça pour mon tablespace "multi-schéma".
 
Je sais bien que ça manque un peu de détails... le problème c'est que la personne qui était là avant moi savait tout ça. Elle s'est barrée en ne documentant rien du tout. Du coup, je suis dans le caca, donc ça va être un peu opérations BANZAAAAAÏ. Si ça merde, je peux toujours re-balancer la sauvegarde à froid de toute façon (et recréer mes tablespaces temporaires à la main, sinon ça chie au redémarrage... je sais pas pourquoi exactement).
 
Merci M'sieur.
 
 
[EDIT] Ma base n'est pas en mode archivelog au cas où tu te sois posé la question.

le FULL=Y si tu veux faire une full, mais dans ta ligne tu ne spécifies rien. Si tu veux juste faire un export de tablespace, utilises l'option "TABLESPACES=" dans ta ligne d'export
 
bon on va faire simple : regarde le contenu des tablespaces où tu veux refaire les datafiles, et en fonction des propriétaires et des données plusieurs choses peuvent s'offrir à toi :
- déplacement des objets dans un nouveau tablespace
- export/import partiel
- export/import full
 
Attention au temps d'import. En général l'import dure 1,5 à 3 fois le temps de l'export

Exact !
 
Je t'ai pas copié la ligne qu'il fallait    
 
Celle que je viens de passer c'est :
 

 
 
Je vais partir sur l'export/import et demander aux dev qui travaillenbt avec cette base de vérifier l'intégrité des données une fois cela fait... on vera bien ce qu'ils me disent

Bon, je crois que j'ai un nouveau problème ...
 
 
Apparemment, je ne peux pas supprimer de datafile sur du Oracle 9.2, explications :
 
1) J'ai fait mon export
 
2) J'ai mis mon tablespace Offline
 
3) à cette étape, il faudrait que je supprime (ou déplace ailleurs) mes 3 datafiles pour en créer 2 nouveaux tout neuf.
Seulement, pas possible de les supprimer.... Si je les supprime (ou deplace) coté système, c'est mes fichiers de contrôle qui gueulent (normal). Et coté Oracle, il parrait que la suppression de datafile n'est implémenté qu'à partir de Oracle 10gR2 ! Pas de chance, je suis en 9.2    
(dixit un FAQ de developpez.com -> http://oracle.developpez.com/faq/? [...] tedatafile )
 
J'ai envis de dire .... je l'ai dans le cul c'est ça ?    
 

c'est pour ca que je te disais de recréer un nouveau tablespace pour faire ton import, car tu ne peux pas supprimer un datafile d'un tablespace : tu es obligé de dropper le tablespace avant