Discussion :

[Mella]

Bonjour

Je travaille sur un environnement Unix avec oracle 9.2.0 et j'ai un problème de données sur ma base.

J'ai un script ksh qui effectue l'export/import de tablespaces d'une base de données vers une autre. Ce script tourne sans problème avec oracle 8i
Sous oracle 9i, il ne génère aucune erreur mais je n'ai pas de données dans la tble cible. Une vérification montre que le tablespace créé utilise bien les fichiers de données copiées et ces derniers ont la même taille que les originaux.
Est ce que vous avez déjà rencontrer ce problème? Quelques idées sur les paramètres à vérifier et/ou la solution à apporter?
Merci

instruction d'export:

Code :

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

1
2
3
exp \"$&#123;LOGIN&#125;/$&#123;PWD&#125; AS SYSDBA\" FILE=exp_tts.dmp TRANSPORT_TABLESPACE=Y TABLESPACES=\&#40;$TTS1, $TTS2\&#41; > exp_tts.log  2>&1 << EOB
/ AS sysdba
EOB

instruction d'import

Code :

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

1
2
3
4
imp FILE=exp_tts.dmp TRANSPORT_TABLESPACE=Y DATAFILES=\('/oradata01/tts_001
.dbf', '/oradata02/tts_002.dbf'\&#41; FROMUSER=USER1 TOUSER=USER1 << EOB
/ AS sysdba
EOB

[Jaouad]

Bonjour ,
estr ce que vous avez bien copié les datafiles , est ce que le TBS est présent dans dba_tablespaces et qu'elle est sont statut ?

Est ce que vous avez le même OS pour les deux versions d'ORACLE et comment avez vous fait le transfert ( FTP ....

[Mella]

Salut

Les datafiles sont copiés via le script et un test est effectué après la copie. En plus de ce test, comme les fichiers copiés ont la même taille que les fichiers originaux, je suppose que la copie s'est bien passée.
Script de copie des bases de données

Code :

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

1
2
3
4
cp /BDD1/oradata01/tts_001.dbf /oradata01/tts_001.dbf &
cp /BDD1/oradata02/tts_002.dbf /oradata02/tts_002.dbf &
wait
exit $?

Le TBS se retrouve bien dans le dba_tablespaces. J'ai suivi le déroulement du script pas à pas afin de voir s'ils étaient bien supprimés avant d'être importés et c'est le cas.
Les deux bases sont sur un même serveur, donc j'utilise juste un cp. Les deux versions d'oracle sont aussi sur ce même serveur. Normalement, on ne travaille plus qu'avec 9i (variable d'environnement) et je dois faire des tests de non regression après migration.

Merci

[Jaouad]

que donne le status des tbs

SI ton tbs provient d'une base en 8i vers une base en 9i alors tu ne penses qu'il faut également un upgrade , non ?

[Mella]

Je me suis mal expliquée.
Je ne fais pas un export/import d'une base 8i vers une base 9i. J'ai deux bases de données ayant une même version. Le traitement courant d'alimentation consite à importer le tablespace de la première vers la seconde. Les scripts que j'utile sont les mêmes que ceux que j'avais dans l'env 8i mais le résultat n'est pas bon. Le script me dit que tout s'est bien passé et pourtant, je n'ai pas de données dans ma base cible.

Sinon, les TBS sont en READ ONLY. ce qui est normal car à la fin du script, on effectue un basculement sur ceux ci ( on ne veut pas faire des modifications dans ces tables une fois les données chargées).

[Jaouad]

Que dit la log de l'export et de l'import

[Mella]

La log est Ok.
j'ai trouvé l'erreur. En fait, le problème s'est produit lors de la migration (migration par supression et creation). Les tablespaces incriminés sont en read only. Lors de la génération du script de création de la base, je ne sais pourquoi, les tables ont été créées sur un autre tablespace. Donc, les données étaient bien présentes après export/import mais on n'y accedait pas parceque les tables pointaient sur un mauvais tablespaces.

Merci pour ton aide.