Structure ORACLE / Import

**Thamior** · 14/02/2008, 19h41

Bonjour à tous !

Chouette, une section [débutant]

Ce que j'aime dans Oracle, c'est que lorsque que je pense avoir compris, il me suffit d'attendre 5mn pour me rendre compte que ce n'est pas le cas ^^

Voilà ce qui m'amène.
Nous n'avons pas de pro-ORACLE chez nous mais pourtant de nombreuses "appliquettes" à tourner dessus. Le serveur (vieux, très vieux...) va être migré et nous faisons donc quelques test pour préparer çà au mieux.

L'ancienne mouture est un peu hasardeuse... il y a une instance PROD et une instance DEV qui comporte toutes les 2 des applis en production

Parfois les DATA et les INDEX sont séparés dans des tablespaces différents, parfois non... on a même des tables stockées dans le tbs system, bref c'est un peu le bazard...

On a donc décidé de créer plusieurs instances propres, des tablespaces avec des noms explicites, les DATA sur une partition (APPLI1_TBS.dbf), les INDEX sur une autre (APPLI1_INDX.dbf), les archives sur une 3ème.
Je pense que c'est un peu la philosophie d'oracle ?

Chose que je ne saisis pas, lorsque nous migrerons les données une dernière fois de l'ancien serveur, après tests, on s'est rendu compte que l'on devait supprimer les tables pour que le dump ne renvoie pas d'erreur (avec du coup le travail sur les index à refaire). On a aussi essayé avec l'option ignore=y mais là, tout les tuples sont en doublons

J'ai aussi essayé un truncate des tables mais j'ai plein de problème de contraintes qui m'empêche de les vider...
Dois-je comprendre que lorsque que nous ferons le dernier import, il faudra de nouveau changer les tbs des index ?
Pourquoi est-ce aussi compliqué d'importer uniquement les rows ?
Pourquoi ne peux-t-on pas déclarer pour un schémas un tbs d'index par défaut, de façon à ce que l'index créé dynamiquement se stocke directement dedans...

Enfin, pardonnez mon ignorance ^^

**orafrance** · 14/02/2008, 20h57

Envoyé par Thamior

Je pense que c'est un peu la philosophie d'oracle ?

complétement

Envoyé par Thamior

Dois-je comprendre que lorsque que nous ferons le dernier import, il faudra de nouveau changer les tbs des index ?

Si tu droppes les tables, les indexes sont droppés aussi

Envoyé par Thamior

Pourquoi est-ce aussi compliqué d'importer uniquement les rows ?

Pour comprendre le problème il suffit de regarder le log, tu verras qu'un import se compose de la création de la table (avec ignore=y l'erreur est ignorée si la table existe), insert des données (donc si la table existait t'as des doublons), création des indexes et contraintes, attribution des droits.

Envoyé par Thamior

Pourquoi ne peux-t-on pas déclarer pour un schémas un tbs d'index par défaut, de façon à ce que l'index créé dynamiquement se stocke directement dedans...

parce que l'import est assez basique comme outil... datapump (en 10g) permet des choses bien plus intéressante notamment la création des indexes dans un autre tablespace

Envoyé par Thamior

Enfin, pardonnez mon ignorance ^^

aucun problème, t'es dans la bonne section

**Thamior** · 14/02/2008, 21h56

Merci pour ces renseignements

Donc, si je comprends bien et pour pas ne me prendre trop la tête, nos phases de tests ont démontré que çà fonctionnait. Lorsqu' arrivera le jour J de la bascule vers le nouveau serveur, on fait un dump des schémas applicatifs de l'ancien serveur (les DATA doivent arrivées dans les tbs déclarés par défaut lors de la création de nos nouveaux users) et on exécute un petit script dynamique (alter index....) pour basculer les INDEX sur les tbs dédiés à çà.

En réfléchissant un peu plus, la manip n'est pas si compliquée que çà, étant normalement faite pour la dernière fois...

Si je pousse un peu plus loin la réflexion, nous avons décidé d'investir dans un serveur de référence, identique donc (matériel et pile logiciel) à la production, sur lequel nous exécuterons et testerons les correctifs ou autres patchs d'applications.

Nous pensons mettre en place une réplication faite la nuit entre la prod et le ref, mais si on réplique par le biais des fichiers (sauvegarde à froid, copie des fichiers via le rso), logiquement le problème d'emplacement des INDEX ne se pose plus non ? Nous aurons vraiment un clone de la base, sans aucune manip particulière ?

**scheu** · 15/02/2008, 09h02

Tu peux aussi faire la méthode bourrin

:
1) désactiver toutes les contraintes sur la base cible
2) truncate de toutes les tables
3) import avec ignore=y
4) réactiver les contraintes
Si la base cible est en 9i, il faudra ensuite faire un rebuild de chaque index pour le changer de tablespace, sinon comme dit Orafrance en 10g tu as le datapump (mieux que export/import)

Pour répliquer, soit des exports/imports réguliers, ou bien regarde du côté de STREAMS

**orafrance** · 15/02/2008, 10h15

Envoyé par Thamior

Nous pensons mettre en place une réplication faite la nuit entre la prod et le ref, mais si on réplique par le biais des fichiers (sauvegarde à froid, copie des fichiers via le rso), logiquement le problème d'emplacement des INDEX ne se pose plus non ? Nous aurons vraiment un clone de la base, sans aucune manip particulière ?

Oui, aucun problème avec les indexes. Et pas de manip pourvu que le SID soit le même et les fichiers avec exactement le même chemin qu'en prod

Sinon, il faudra recréer les control files ce qui n'est pas compliqué : http://orafrance.developpez.com/dbahelp/#L2

**Tracnac** · 15/02/2008, 10h43

Bonjour,

Visiblement il y en a qui aime bien ce compliquer la vie... !?

Ton user à un tablespace par defaut on vas dire DATA pour simplifier les choses... Comme tu es un bon DBA... Tu veux répartir les data dans le tablespace DATA et les index dans le tablespace INDX.

Ben c'est tout simple...

Tu lances ton export :

Code :

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

exp file=./monbordelamoi.dmp log=./monbordelamoi.log owner=monschemabordelique

tu "drop"/"create" ton schéma
Puis tu verifie que ton user a bien comme tablespace par defaut DATA

Code :

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

1
2
3
alter user monschemabordelique quota unlimited on DATA;
alter user monschemabordelique quota 0K on INDX;
revoke unlimited tablespace from monschemabordelique;

-- le grant resource donne souvent unlimited tablespace ici on en veut surtout pas...

Tu lances l'import :

imp file=./monbordelamoi.dmp log=./imp_monbordelamoi_data.log fromuser=monschemabordelique touser=monschemabordelique indexes=n constraints=n

Tu "switch" le user avec comme tablespace par defaut INDX

Code :

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

1
2
3
alter user monschemabordelique default tablespace INDX;
alter user monschemabordelique quota 0K on DATA;
alter user monschemabordelique quota unlimited on INDX;

Tu lances l'import (Pour les indexes) :

imp file=./monbordelamoi.dmp log=./imp_monbordelamoi_data.log fromuser=monschemabordelique touser=monschemabordelique rows=n ignore=y

Voila voili qu'il est beau mon schéma...

Donc en gros ça donne : il te faut un DATA et un INDX comme tablespace...

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
set linesize 1024
drop user TEST cascade;
create user TEST identified by TEST123;
alter user TEST default tablespace DATA;
grant connect,resource to TEST;
revoke unlimited tablespace from TEST;
alter user TEST quota unlimited on DATA;
alter user TEST quota unlimited on INDX;
connect test/test123
create table t1data (a varchar2(1)) tablespace DATA;
create index t1data_n1 on t1data (a) tablespace DATA; 
create table t1index (a varchar2(1)) tablespace INDX;
create index t1index_n1 on t1index  (a) tablespace INDX;
select owner,segment_name, tablespace_name from dba_segments where owner = 'TEST';
! exp file=./TEST.dmp log=./TEST.log owner=TEST
connect / as sysdba
drop user TEST cascade;
create user TEST identified by TEST123;
alter user TEST default tablespace DATA;
grant connect,resource to TEST;
alter user TEST quota unlimited on DATA;
revoke unlimited tablespace from TEST;
! imp file=./TEST.dmp log=./imp_TEST.log fromuser=TEST touser=TEST indexes=n constraints=n
select owner,segment_name, tablespace_name from dba_segments where owner = 'TEST';
alter user TEST default tablespace INDX;
alter user TEST quota unlimited on INDX;
alter user TEST quota 0K on DATA;
! imp file=./TEST.dmp log=./imp_TEST.log fromuser=TEST touser=TEST rows=n ignore=y
select owner,segment_name, tablespace_name from dba_segments where owner = 'TEST';

**Tracnac** · 15/02/2008, 10h45

Ah oui je suis parti du principe que tu n'avais pas de LOBs sinon les choses se complique un peu (Pas beaucoup plus...)

Cordialement.

**Thamior** · 15/02/2008, 11h17

Envoyé par scheu

Tu peux aussi faire la méthode bourrin

:
1) désactiver toutes les contraintes sur la base cible

On peut désactiver et réactiver toutes les contraintes d'un schémas en une seule requête (dynamique) ?

@Tracnac,
c'est vraiment censé être moins compliqué ta démonstration ?

Je me rends compte que je n'ai pas précisé les versions, donc win2k3 et Oracle 9.2.0.3 (donc pas de datapump pour l'instant).

**Tracnac** · 15/02/2008, 11h42

Thamior c'est la plus propre car tu ne fragmente pas ton tablespace DATA avec des "move" indexes...

Sinon pour l'os ça change rien...

Cordialement.

**Thamior** · 15/02/2008, 14h53

J'ai regardé ta méthode Tracnac et il y a quelques points ou j'ai besoin de lumière.

Envoyé par Tracnac

Code :

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

alter user monschemabordelique quota 0K on INDX;

Je ne comprends pas l'utilité de cette requête. Pourquoi mettre le quota à zéro sur INDX puisque le user ne va pas écrire dessus (à moins que...).

Envoyé par Tracnac

Code :

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

revoke unlimited tablespace from monschemabordelique;

-- le grant resource donne souvent unlimited tablespace ici on en veut surtout pas...

Encore une subtilité qui m'échappe... pourquoi est ce que l'on en veut surtout pas, de l'unlimited tablespace. A quoi sert ce privilège ?

Envoyé par Tracnac

Code :

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

alter user monschemabordelique quota 0K on DATA;

Idem que pour la première question

Merci pour l'intérêt porté à mes demandes.

**orafrance** · 15/02/2008, 15h09

le but du quota à 0 c'est de mettre une erreur sur chaque tentative de copie de data dans le tablespace à 0... dans le 1° cas tu peux pas écrire les indexes dans le 2° c'est les datas.

Ceci dit, INDEXFILE me parait plus judicieux qu'un log farci d'erreurs

**scheu** · 15/02/2008, 15h13

Envoyé par Thamior

On peut désactiver et réactiver toutes les contraintes d'un schémas en une seule requête (dynamique) ?

Avec du SQL Dynamique oui, par exemple (je ne l'ai pas testé)

Code :

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

1
2
3
4
5
6
7
8
9
begin
for cur in (
select owner,constraint_name,table_name from all_constraints
where owner = 'MON_SCHEMA'
)
loop
 execute immediate 'ALTER TABLE '||cur.owner||'.'||cur.table_name||' MODIFY CONSTRAINT '||cur.constraint_name||' DISABLE';
end loop;
/

Et pour réactiver idem en mettant ENABLE au lieu de DISABLE
Il se peut que tu ais quelques soucis si tu désactives des PK avant les FK associées, au pire lancer le script en plusieurs fois avec d'abord un filtre sur " WHERE constraint_type = 'R' "(pour d'abord désactiver les FK), et ensuite avec " WHERE constraint_type <> 'R' ", et l'inverse pour réactiver

**orafrance** · 15/02/2008, 15h22

rappellons la page sources : http://oracle.developpez.com/sources...active_fk_user
http://oracle.developpez.com/sources...active_fk_user

**Tracnac** · 15/02/2008, 15h51

Envoyé par orafrance

le but du quota à 0 c'est de mettre une erreur sur chaque tentative de copie de data dans le tablespace à 0... dans le 1° cas tu peux pas écrire les indexes dans le 2° c'est les datas.

Excuse moi j'ai rien compris !? il n'y a aucune erreur !!

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
Import: Release 10.2.0.1.0 - Production on Fri Feb 15 15:50:24 2008
 
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
 
Username: / as sysdba
 
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
 
Export file created by EXPORT:V10.02.01 via conventional path
import done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
import server uses WE8MSWIN1252 character set (possible charset conversion)
. importing TEST's objects into TEST
. . importing table                      "T1INDEX"          0 rows imported
. . importing table                      "T1USERS"          0 rows imported
Import terminated successfully without warnings.
 
 
 
Import: Release 10.2.0.1.0 - Production on Fri Feb 15 15:50:48 2008
 
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
 
Username: / as sysdba
 
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
 
Export file created by EXPORT:V10.02.01 via conventional path
import done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
import server uses WE8MSWIN1252 character set (possible charset conversion)
. importing TEST's objects into TEST
Import terminated successfully without warnings.

**orafrance** · 15/02/2008, 16h02

Il manque les commandes

T'as des données exportées ? Parce que pas d'erreur mais 0 ligne importée c'est étrange

**Tracnac** · 15/02/2008, 16h06

Envoyé par Thamior

J'ai regardé ta méthode Tracnac et il y a quelques points ou j'ai besoin de lumière.
Je ne comprends pas l'utilité de cette requête. Pourquoi mettre le quota à zéro sur INDX puisque le user ne va pas écrire dessus (à moins que...).

Désolé, bon je recommence (L'exemple etait la representation logique de mon explication)
Je pars du principe que c'est le bordel absolu... donc tu ne sais pas ou sont tes datas, des indexes... donc en virtuel ça donne :

TABLESPACE DATA = DATA + INDEX
TABLESPACE INDEX = DATA + INDEX

Le but est d'interdire a l'outil "import" la creation de data dans des tablespaces que tu ne veux pas... d'ou le quota à 0 sur INDEX. Tu es sur que tout est créé dans le tablespace DATA.

Donc imp avec indexes=n constraints=n tu n'importe que les datas...

Après tu switch pour faire l'inverse tu ne veux plus de data mais tu veux les indexes donc quota à 0 sur DATA et unlimited sur INDEX

Donc imp avec rows=n ignore=y tu n'import que les indexes

Encore une subtilité qui m'échappe... pourquoi est ce que l'on en veut surtout pas, de l'unlimited tablespace. A quoi sert ce privilège ?

Idem que pour la première question

Merci pour l'intérêt porté à mes demandes.

Unlimited tablespace est un privilège qui te permets de crée des objets dans n'importent quel tablespaces...
Ce que tu NE veux surtout PAS ici lors de ta réorg...

**Tracnac** · 15/02/2008, 16h09

Envoyé par orafrance

Il manque les commandes

T'as des données exportées ? Parce que pas d'erreur mais 0 ligne importée c'est étrange

Reprends mon example il n'y a pas de lignes... c'est normal j'ai pas fait d'insert... les commandes sont dans l'exemple aussi...

**orafrance** · 15/02/2008, 16h17

ha ok, c'est juste pour créer les objets, j'avais pas vu

Enfin, y'a l'option indexfile, autant l'utiliser non ?

**Tracnac** · 15/02/2008, 16h19

Envoyé par orafrance

ha ok, c'est juste pour créer les objets, j'avais pas vu

Enfin, y'a l'option indexfile, autant l'utiliser non ?

En fait indexfile et show=y je l'utilise quand cela ce complique (LOB et TABLE PARTITIONNEES) sinon la méthode sus cité est valable dans 99 % des cas...

**Thamior** · 15/02/2008, 18h28

Un grand merci pour cet éclaircissement. Je n'ai plus qu'à retenir çà plus de 5mn dans ma cervelle de moineau

@+

Structure ORACLE / Import

Oracle

Discussions similaires

Partager

Partager