Oracle 9.2 - Tablespace ändern bei Datenimport bzw. -export
Schema Kopie per exp und imp soll in andere Tablespaces
Hallo!
Bei unserer Oracle 9.2.0.6 speichert eine Applikation alle Daten unter dem Schema/dem User PROD in der Instanz db01. Die DB-Objekte des Schemas sind in 3 verschiedenen Tablespaces (TS1,TS2,TS3) abgelegt.
Nun möchte ich aus Testzwecken eine Testumgebung erstellen und dazu eine Kopie des Schemas in der gleichen Instanz erstellen. Ich exportiere dazu zuerst die Daten per exp.exe von User PROD:
Danach mache ich ein DROP auf den Testuser TEST und erstelle ihn neu mit Default-Tablespace TSTEST.
Soweit funktioniert es auch noch. Nur liegen die Tabellen im Schema TEST in den gleichen Tablespaces wie die aus dem Schema PROD (TS1-3), und nicht komplett - nämlich überhaupt nicht - in Tablespace TSTEST.
Gibt es dafür eine Lösung?
Klaus
Hallo!
Bei unserer Oracle 9.2.0.6 speichert eine Applikation alle Daten unter dem Schema/dem User PROD in der Instanz db01. Die DB-Objekte des Schemas sind in 3 verschiedenen Tablespaces (TS1,TS2,TS3) abgelegt.
Nun möchte ich aus Testzwecken eine Testumgebung erstellen und dazu eine Kopie des Schemas in der gleichen Instanz erstellen. Ich exportiere dazu zuerst die Daten per exp.exe von User PROD:
exp system@db01 file=c: empprod.dmp owner=PROD consistent=y buffer=20000000Danach mache ich ein DROP auf den Testuser TEST und erstelle ihn neu mit Default-Tablespace TSTEST.
imp system@db01 file=c: empprod.dmp fromuser=PROD touser=TEST buffer=20000000Soweit funktioniert es auch noch. Nur liegen die Tabellen im Schema TEST in den gleichen Tablespaces wie die aus dem Schema PROD (TS1-3), und nicht komplett - nämlich überhaupt nicht - in Tablespace TSTEST.
Gibt es dafür eine Lösung?
Klaus
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 61327
Url: https://administrator.de/forum/oracle-9-2-tablespace-aendern-bei-datenimport-bzw-export-61327.html
Ausgedruckt am: 30.04.2025 um 19:04 Uhr
5 Kommentare
Neuester Kommentar
Moin haegar4020,
willkommen im Forum.
Ich verstehe Dein Problem in zweifacher Hinsicht nicht:
Grüße
Biber
willkommen im Forum.
Ich verstehe Dein Problem in zweifacher Hinsicht nicht:
- die "kopierten" Daten liegen doch in einem anderen Schema ("Test"). Und jedes Schema, also auch das "Original" ("Prod") verwaltet doch eigene Tablespaces. Dann gibt es doch keine Kollisionen zwischen PROD.TS1 und TEST.TS1 ?
- und WTF sollte Oracle oder sonst irgendjemand auf die Idee kommen, die "importierten" Daten in einen Tablespace namens TSTEST zu stellen? Da verstehe ich Deine Erwartungshaltung nicht ganz
Grüße
Biber
Hallo,
irgendwo hat Biber schon recht.
Ich kann Dich aber auch verstehen, manchmal möchte man die Tabellen/Indizes halt in einen anderen Tablespace haben.
Ich sehe daher zwei Möglichkeiten:
1. CREATE TABLE TEST.xxx AS SELECT * FROM PROD.xxx;
Vorher dem User TEST den gewünschten Tablespace als Default geben, Indizes, Constraints und Rechte alle
manuell anlegen oder vorab Skripte schreiben.
2. Zwei Exports machen, einen mit, einen ohne Daten (ROWS=N). Den ohne Daten importieren,
Tabellen werden angelegt (im "falschen" TS),
diese mit ALTER TABLE xxx MOVE TABLESPACE xxxx; verschieben und dann den vollen Export (mit Daten) mit der Option
IGNORE=Y importieren.
Gruß - René
irgendwo hat Biber schon recht.
Ich kann Dich aber auch verstehen, manchmal möchte man die Tabellen/Indizes halt in einen anderen Tablespace haben.
Ich sehe daher zwei Möglichkeiten:
1. CREATE TABLE TEST.xxx AS SELECT * FROM PROD.xxx;
Vorher dem User TEST den gewünschten Tablespace als Default geben, Indizes, Constraints und Rechte alle
manuell anlegen oder vorab Skripte schreiben.
2. Zwei Exports machen, einen mit, einen ohne Daten (ROWS=N). Den ohne Daten importieren,
Tabellen werden angelegt (im "falschen" TS),
diese mit ALTER TABLE xxx MOVE TABLESPACE xxxx; verschieben und dann den vollen Export (mit Daten) mit der Option
IGNORE=Y importieren.
Gruß - René
Erstmal danke für die Anregungen.
@Biber:
ad 1. Als in meinem Oracle gibt es den TS1 nur einmal, und sowohl Tabellen vom Schema PROD als auch vom Schema TEST sind darin enthalten.
ad 2. Nunja, meine Erwartung war, dass der Default-Tablespace (TSTEST) des Schemas greift und die importierten Daten allesamt darin landen.
@René:
ad 1. Da die Tabellen aus einer zugekauften Applikation sind habe ich für die ca. 3000 Tabellen, Views, Constraints etc. keine CREATE Skripts. Mir ist auch kein Verfahren bekannt, wie ich die CREATE Skripts aus einer bestehenden DB erstellen könnte, PHPMyAdmin geht ja nicht für Oracle.
ad 2. wäre ev. noch einen Versuch Wert, die DBObjekte müsste ich ja als Liste aus irgendwelchen Oracle-Systemviews/tables bekommen, dann noch ein regexp-Ersetzen und die ALTER-Statements sollten dastehen.
Ich inzwischen selber noch rumgesucht und bin auch auf einen anderen Lösungsvorschläge gestoßen:
Wie unter Orafaq.com zu lesen ist, wird soll man dem neuen User/Schema keinen UNLIMITED TABLESPACE zugestehen, und auf die alten TS - in meinem Fall die der Produktivdatenbank - keine Quota geben. Danach sollte ein Import mit ignore=y die Objekte im Default-Tablespace des Schemas anlegen. Leider funktioniert das in meinem Fall aber nicht mit allen Objekten. Einige Tabellen hat das imp-Util mit expliziten CREATE TABLE [...] TABLESPACE TS1 etc. anzulegen versucht, ist dann aber an den fehlenden Rechten des Users TEST gescheitert, womit die Daten dann nicht vollständig waren.
Hilft mir vielleicht dieser ominöse transportable tablespace Modus vom imp/exp Utility? Kann ich damit irgendwie den Tablespace beim Import umbiegen?
Klaus
@Biber:
ad 1. Als in meinem Oracle gibt es den TS1 nur einmal, und sowohl Tabellen vom Schema PROD als auch vom Schema TEST sind darin enthalten.
ad 2. Nunja, meine Erwartung war, dass der Default-Tablespace (TSTEST) des Schemas greift und die importierten Daten allesamt darin landen.
@René:
ad 1. Da die Tabellen aus einer zugekauften Applikation sind habe ich für die ca. 3000 Tabellen, Views, Constraints etc. keine CREATE Skripts. Mir ist auch kein Verfahren bekannt, wie ich die CREATE Skripts aus einer bestehenden DB erstellen könnte, PHPMyAdmin geht ja nicht für Oracle.
ad 2. wäre ev. noch einen Versuch Wert, die DBObjekte müsste ich ja als Liste aus irgendwelchen Oracle-Systemviews/tables bekommen, dann noch ein regexp-Ersetzen und die ALTER-Statements sollten dastehen.
Ich inzwischen selber noch rumgesucht und bin auch auf einen anderen Lösungsvorschläge gestoßen:
Wie unter Orafaq.com zu lesen ist, wird soll man dem neuen User/Schema keinen UNLIMITED TABLESPACE zugestehen, und auf die alten TS - in meinem Fall die der Produktivdatenbank - keine Quota geben. Danach sollte ein Import mit ignore=y die Objekte im Default-Tablespace des Schemas anlegen. Leider funktioniert das in meinem Fall aber nicht mit allen Objekten. Einige Tabellen hat das imp-Util mit expliziten CREATE TABLE [...] TABLESPACE TS1 etc. anzulegen versucht, ist dann aber an den fehlenden Rechten des Users TEST gescheitert, womit die Daten dann nicht vollständig waren.
Hilft mir vielleicht dieser ominöse transportable tablespace Modus vom imp/exp Utility? Kann ich damit irgendwie den Tablespace beim Import umbiegen?
Klaus
Hallo,
nein, der "Transportable Tablespace"-Modus wird Dir nicht helfen, TTS ist für den Transport zwischen 2 Datenbanken gedacht.
Ein neuer Ansatz:
Bei 3000 Objekten solltest Du mal über eine eigene Testdatenbank auf einem eigenen Server nachdenken oder einen zweite Instanz auf deinem Server erstellen. Somit hättest Du mit Import und Export kein Problem mehr.
Noch eine weitere Sache, es gibt bei Oracle ein Package, welches die Definitionen von alles Objekten liefert, der Name fällt mir im Moment nicht ein, ich melde mich nochmal.
Gruß - René
nein, der "Transportable Tablespace"-Modus wird Dir nicht helfen, TTS ist für den Transport zwischen 2 Datenbanken gedacht.
Ein neuer Ansatz:
Bei 3000 Objekten solltest Du mal über eine eigene Testdatenbank auf einem eigenen Server nachdenken oder einen zweite Instanz auf deinem Server erstellen. Somit hättest Du mit Import und Export kein Problem mehr.
Noch eine weitere Sache, es gibt bei Oracle ein Package, welches die Definitionen von alles Objekten liefert, der Name fällt mir im Moment nicht ein, ich melde mich nochmal.
Gruß - René
Hallo,
das Package nennt sich DBMS_METADATA .
Gruß - René
das Package nennt sich DBMS_METADATA .
Gruß - René
