Import/Export : quid des index?

Version imprimable

02/03/2017, 14h57
Ikebukuro

Import/Export : quid des index?

Bonjour,

J'ai une question : dans le cas d'un import/export, est-ce que je dois inclure les index ou les exclure?
A priori je pense les exclure car rien ne me dit que la valeur des rowid stockés dans les index sera la même entre les deux bases suite à la migration des données.
En outre on peut très bien avoir un nombre de fichiers moindre dans la base cible que dans la base source; cela implique que si on a des rowid dans les index sur un numéro de fichier inconnu dans la base cible, ces index migrés seront inutilisables.

Je pense qu'il serait donc plus judicieux de migrer seulement les données et de construire les index après plutôt que de migrer Données+Index (plus de trafic réseau) et faire un Rebuild des index (opération plus longue qu'un Create Index).

Je pose la question car dans un livre on parle de migrer les index mais comme les index sont fortement dépendants d'une caractéristique physique(le nombre de fichiers Unix), je m'interroge sur qui a raison.

Par avance merci pour les réponses.
02/03/2017, 22h27
pachot

Bonjour,
L'export des index n'exporte que les meta-données. Ils sont reconstruits à l'import. Car effectivement les ROWID seront différents.
(le cas de transportable tablespace est différent bien sûr).
D'ailleurs, la plus grande partie du temps d'import est souvent cette reconstruction d'index.
Cordialement,
Franck.
03/03/2017, 07h41
Ikebukuro

Merci pour ta réponse Franck!
Tu dis que le cas de transportable tablespace est différent : je comprends que si on veut copier le TBS des index, effectivement on va tout récupérer de ce TBS, métadatas et données (donc de mauvais rowid).
Mais dans le cas d'un transportable database? On récupère pour les index que les métadatas ou aussi les données de l'index ou bien c'est juste le cas du transportable tablespace qui inclut les données des index?
03/03/2017, 08h12
pachot

Avec transportable tablespace, les rowid ne changent pas, donc les index sont valides. Le rowid est une adresse physique relative au tablespace.
04/03/2017, 12h24
Ikebukuro

"Avec transportable tablespace" : c'est bien tablespace ou database?
04/03/2017, 16h39
pachot

Citation:

Envoyé par Ikebukuro

"Avec transportable tablespace" : c'est bien tablespace ou database?

Oui, transportable tablespace. Transportable database ça n'existe pas. C'est soit pluggable database. Mais on s'éloigne...
05/03/2017, 09h17
Ikebukuro

Deux remarques :
1) Je lis un bouquin intitulé "Oracle Database Upgrade, Migration & Transformation Tips & Techniques" et page 119 ils ont un chapitre intitulé "Transporting Tablespaces and Databases" et page 120 ils disent "This chapter therefore focuses on two distinct methods of data migration :
- migrating one or more Transportable Tablespaces Sets (TTS) between different OS platforms
- migrating a complete Transportable Database (TDB) between different OS platforms"

La technique de "Transportable Database" semble donc exister (et on est pas dans le cadre des plugabbles databases).

2) je ne comprends pas, dans le cas du Transportable Tablespaces, pourquoi les Rowid sont OK. Dans mon exemple je parle d'un nombre de fichiers pour stocker les données différents entre les bases source et cible. Si les rowid des index source référencent tous les fichiers de ces données source, je ne vois pas comment ces index, une fois migrés tel quels (sans recalcul) pourraient être valides sur la base cible puisque des rowid pointeront vers des fichiers inexistants...

Merci pour tes réponses.
05/03/2017, 10h00
pachot

1) Oui, on peut appeler 'transportable database' le fait de transporter tous les tablespaces d'une base. Mais c'est un peut abusif car les tablespaces SYSTEM, SYSAUX et UNDO ne sont pas transportés.
2) Les ROWID ne pointent pas vers des fichiers, mais ont seulement un numéro de fichier relatif au tablespace (RELATIVE_FNO dans les vues DBA). Donc les ROWID ne changent pas lorsqu'on transporte un tablespace. Lorsqu'on 'plug' le tablespace dans une nouvelle base, c'est juste le dictionnaire qui va faire le lien avec un numéro de fichier absolu (FILE_ID) dans la nouvelle base, et le controlfile qui va faire le lien avec le nom de fichier physique.

Plus d'infos:
https://blog.dbi-services.com/from-80-extended-rowid-to-12c-pluggable-db-or-why-oracle-database-is-still-a-great-software/
https://blog.dbi-services.com/otn-ap...e-tablespaces/