Discussion :

[bobunny]

Bonjour,

Je dois migrer une base de données d'une version 8.0.5 vers une 9i. Je vais essayer d'être le plus clair possible.

Actuellement, je n'ai pas les moyens matériels pour tester, je suis en phase de conception seulement.

Voilà, j'aimerai bénéfichier des nouvelles structures de stockage de la 9i, donc utiliser la gestion des tablespace de façon local avec des extents de taille uniforme.

Je dois profiter de cette migration pour réorganiser un peu la base. Donc des nouveaux tablespace sont à créer.

Dans un premier temps, je dois exporter toute la structure de la base sans les données. Je pense faire ça avec un export full avec l'option ROWS=N

J'ai pu constater dans le passé que lors d'un export, le paramètres initial extent était conservé lors de l'import.

Imaginons que j'ai une table sur ma base 8.0.5 qui a un extent initial de 500M. vu que je le l'exporte sans les données, lors de l'import dans la base 9i, quelle place vas occuper ma table, sachant que le nouveau tablespace est gérer de façon local avec taille d'extent uniforme.

Si ma taille d'extent uniforme est de 50M, est-ce qu'au bout de mon import, ma table va occuper juste l'extent de 50M, ou va-elle allouer 500M??

Si quelqu'un a une idée, ça serait super cool.

Merci d'avance

[orafrance]

j'ai du mal à comprendre l'intérêt de l'export avec ROWS=N... Pourquoi ne pas recréer les objets avec les clauses storages spécifiques à la 9i ? C'est pas difficile de générer les scripts SQL de création des objets des tables donc pas de probléme...

Pour ta question, à mon avis la table fera 600M : 500M (initial) + 2* 50M (2 extents de 50M)

Je crois bien (à vérifier... peut-être dans mon article ) qu'Oracle crée l'objet avec 3 extents

[bobunny]

Je crois bien (à vérifier... peut-être dans mon article ) qu'Oracle crée l'objet avec 3 extents

Oui rien ne vaut un petit test. Mais au boulot, pas encore la 9i donc c'est embetant

Pour ta question, à mon avis la table fera 600M : 500M (initial) + 2* 50M (2 extents de 50M)

Moi je pensais qu'en mettant les clauses

Code :

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

1
2
extent management local uniform size XXXM
segment space auto

il devait ne pas tenir compte des paramètres initial vu que c'est au tablespace de se gérer tout seul!

Mais dans ton article, il est juste précisé

AUTO : permet de laisser la base gérer l'espace libre. Oracle ignore alors les paramètres PCTUSED, FREELIST et FREELIST GROUPS des objets du tablespace.

Donc peut être qu'oracle tient compte du paramètre intial. LE meilleur moyen ça serait de pouvoir tester

Je vais essayer de m'installer Oracle sur un poste Win, mais pas sur que j'ai assez de ressource

Sinon, juste une question : si je ne précise pas la clause

Code :

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

segment space auto/manual

est-ce que la valeur par défaut c'est auto?

[orafrance]

exact en UNIFORM : initial = next = size défini

Pour shématiser, AUTO signifie qu'Oracle connait la carte de tous les blocs et connait l'emplacement des blocs libres. En MANUAL, il continue de gérer l'espace libre par les FREELIST (c'est la valeur par défaut )

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c04space.htm#4383

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/tspaces.htm#19132

Ceci étant, je ne vois pas bien ce que peut apporter de savoir si 1, 3 ou 5 extents sont alloués à la création du tablespace... l'important étant simplement que le tablespace soit suffisament grand pour accueuillir toutes les données

[CD]

Pour le LMT, quand on est en uniform size, les extents feront tous la même taille.

Par contre, si vous spécifiez une clause storage dans vos créations de tables, Oracle allouera autant d'extents permettant d'atteindre l'initial en question.

Ainsi, si vous avez un initial à 500M et des extents uniformes de 1M, Oracle allouera 500 extents de 1M pour créer la table.

L'avantage, c'est que ces extents ne devront pas être forcément contigüs comme ils auraient du l'être avec un gestion en DMT.

[bobunny]

OK Je vois.

En fait pour expliquer pourquoi je me pose la question, c'est que dans la procédure de migration 8.0.5 vers 9i, il est proposé en gros de :
1- export full de la base sans les données à partir de la 8.0.5 (ceci permet de récupérer toute la structure et tous les objets de la base, et il y en vraiment beaucoup )
2- import de la structure dans la base 9i
3- suppression des tables, puis recréation de ces tables par scripts car on a une nouvelle réorganisation des tablespaces
4 - export des données de la 8.0.05, puis import de ces données vers la 9

Or dans l'étape 2, les tablespace ne sont plus forcément les même, donc pendant l'import, si le tablespace n'existe pas pour une table, celle-ci est créé dans le tablespace par défaut de l'utilisateur. Donc il faut prévoir taille du tablespace par défaut pour pourvoir stocker la structure de la table importée. C'est pour ça que je voulais savoir l'histoire de l'initial extent, car le tablespace par défaut du user est géré localement ...

Pourquoi on importe les tables alors qu'on doit les recréer manuellement avant l'import des données, me direz vous !
En fait, je crois que c'est pour éviter d'avoir des erreurs lors de l'import vu qu'il y a des vues et pas plein de packages qui font référence aux tables.

Ce n'est peut être un raisonnement correct me direz vous

[CD]

Pourquoi dropper et recréer les tables pour faire une réorganisation de tablespace ?

Il existe des commandes SQL qui permettent de le faire directement :

Code :

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

alter table MaTable move NouveauTablespace

et pour les indexes :

Code :

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

alter index MonIndex rebuild NouveauTablespace

En tout cas, tant qu'à faire un import vide avant d'alimenter les tables, autant ne pas importer les indexes et les créer une fois que la base est importée et réorganisée. Pour avoir les indexes, il suffit, lors de l'import, de spécifier l'option

Code :

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

indexfile=NomFchier

, de l'éditer, et de changer les tablespaces pour qu'ils correspondent à ceux choisis.

[bobunny]

Oui je ne l'ai pas précisé, mais les index ne sont pas importés évidemment. Ils ne sont créés qu'après l'import des données.

Sinon pourquoi dropper les tables. Certaines doivent changer de structures (passage en IOT, partitionnement). Mais sinon, oui c'est peut être aussi bien pour les autres de faire move comme tu le préconises

[orafrance]

Et puis l'import/export peut se faite sans les données (ROWS=N)

[CD]

J'ai fait une réorganisation il y a peu d'une de mes bases pour la passer en LMT. Voilà le script que j'ai utilisé pour faire les moves :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
set feedback off;
set heading off;
set linesize 100;
set pagesize 5000;
set echo off;
 
spool reorg.sql
 
select 'alter '||segment_type||'.'||segment_name||' '||decode(segment_type, 'INDEX', 'rebuild tablespace &2;', 'move tablespace &3;')
from dba_segments
where owner = upper('&1');
 
spool off;
 
@reorg.sql

Je donne un user, son tablespace index, son tablespace données, et il fait le move des objets de ce user.

[orafrance]

manquerait pas un filtre sur le type... parce que move d'une vue c'est pas super

[CD]

Oui, je n'avais pas de vue, c'est pour cela... Mais sinon, c'est vite fait :

Code :

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

1
2
3
4
select 'alter '||segment_type||'.'||segment_name||' '||decode(segment_type, 'INDEX', 'rebuild tablespace &2;', 'move tablespace &3;') 
from dba_segments 
where owner = upper('&1')
and segment_type in ('INDEX', 'TABLE');

[bobunny]

Merci je prends note de toutes ces infos.

En tout cas merci de vos conseils