Example transport tablespace
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_CHECKest 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 avecexpdp/impdpen 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 CONVERTen 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
- Example partition range number oracle 8 — autre script d'exemple de manipulation de tablespaces/partitions