Example transport tablespace

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Script SQL*Plus d'exemple
Rôle Transport de tablespaces entre deux bases
Voir aussi Example partition range number oracle 8

Example transport tablespace illustre le mécanisme des transportable tablespaces pour déplacer un ou plusieurs tablespaces d'une base source vers une base cible, sans passer par un export/import ligne à ligne : seuls les fichiers de données sont copiés physiquement, l'export/import ne portant que sur les métadonnées du dictionnaire.

L'exemple ci-dessous transporte les tablespaces users et users2 d'une base CUSTDB vers une base DWDB. Les noms d'instances, chemins et identifiants de connexion sont fictifs et à remplacer par ceux de l'environnement cible.

Script

CONNECT / AS SYSDBA
SET SERVEROUTPUT ON

-- ==========================================
-- 1. Vérifier que le(s) tablespace(s) sont "self-contained"
--    (aucune dépendance vers un objet situé hors du jeu transporté)
-- ==========================================
EXEC DBMS_TTS.TRANSPORT_SET_CHECK('users, users2', TRUE);

SELECT * FROM transport_set_violations;
-- Si cette requête retourne des lignes, il faut résoudre les
-- dépendances signalées avant de poursuivre.

-- ==========================================
-- 2. Passer les tablespaces en lecture seule et exporter le jeu
--    transportable (métadonnées uniquement, via l'utilitaire exp)
-- ==========================================
ALTER TABLESPACE users  READ ONLY;
ALTER TABLESPACE users2 READ ONLY;

-- Depuis le shell (ou via ! sous SQL*Plus) :
--   exp userid=\"sys/<mot_de_passe>@custdb\" transport_tablespace=y \
--       tablespaces=users,users2 triggers=y constraints=y grants=y \
--       file=users.dmp

-- Copier physiquement les fichiers de données vers la base cible :
--   cp /chemin/oradata/CUSTDB/users01.dbf   /chemin/oradata/DWDB/users01.dbf
--   cp /chemin/oradata/CUSTDB/users2_02.dbf /chemin/oradata/DWDB/users2_02.dbf

ALTER TABLESPACE users  READ WRITE;
ALTER TABLESPACE users2 READ WRITE;

-- ==========================================
-- 3. Se connecter à la base cible et importer le jeu transportable
-- ==========================================
CONNECT sys/<mot_de_passe>@dwdb AS SYSDBA

-- Depuis le shell :
--   imp userid=\"sys/<mot_de_passe>@dwdb as sysdba\" transport_tablespace=y \
--       datafiles='/chemin/oradata/DWDB/users01.dbf, /chemin/oradata/DWDB/users2_02.dbf' \
--       file=users.dmp

-- ==========================================
-- 4. Repasser les tablespaces importés en lecture/écriture
-- ==========================================
ALTER TABLESPACE users  READ WRITE;
ALTER TABLESPACE users2 READ WRITE;

Points d'attention :

  • DBMS_TTS.TRANSPORT_SET_CHECK est une étape obligatoire : un tablespace n'est transportable que s'il est self-contained (pas d'index sur une autre partition de tablespace, pas de contrainte référençant un objet extérieur au jeu, etc.).
  • Les fichiers de données doivent être copiés (ou déplacés) manuellement entre les deux serveurs — exp/imp (ou Data Pump avec expdp/impdp en version plus récente) ne transfère que le dictionnaire de données, jamais le contenu des fichiers.
  • La base source et la base cible doivent avoir le même jeu de caractères et la même version d'endianness (ou passer par RMAN CONVERT en cas d'architecture différente), sans quoi l'import échoue.
  • Les tablespaces restent en lecture seule le temps de la copie physique des fichiers : à planifier hors fenêtre d'écriture applicative.

Voir aussi