# oracle-import von dmp-Datei



## Manderby (2. Juli 2004)

Hallo zusammen,

ich stehe vor einem kleinen Problem, das mich nun bereits seit einigen Stunden beschäftigt. Ich bin sicher, es gibt hier Leute, die mir sofort sagen können, woran es liegt.

Ich möchte (bzw. muss) eine fremde (von jemandem mir gegeben) oracle-dmp-Datei in eine meiner leeren Datenbanken einlesen.
Folgende Fakten:

Oracle 9i auf Win2000
Administrator: Ich, alle Rechte und Passwörter bei mir
Komplettinstallation auf lokalem Computer (kein Server).
OMS läuft.
Benutzer in Windows sind angepasst (von wegen Stapel-Jobs und so)

Aber: Wenn ich den Import nun endlich zum laufen gebracht habe, kommt schlicht die folgende Meldung: 


```
Job hat keine Ausgabe erzeugt.
```

Bei den Jobs sehe ich dann, dass es nicht erfolgreich war.

Um vermeindliche lästige Gegenfragen zu beantworten:
Die Datei ist nicht leer (4 MB)
Ich kenne die Struktur der zur erstellenden Datenbank nicht.
Google bringt 0 Hits zu der obigen Meldung.

Ich freue mich riesig auf eure Antworten! Danke im Voraus!

Grussi


----------



## JensG (2. Juli 2004)

Ich bin kein Oracle Experte aber ich habe das mal bei Oracle 7 gemacht
und zwar gab es da über die Konsole die Möglichkeit mit

imp71 User/Kennwort File=C:\Test.dmp Tables=Tabelle1,Tabelle2

Das Tables kann man weglassen wenn alle importiert werden sollen.
Die zu importierenden Tabellen dürfen nicht existieren.

Vielleicht gibt es das unter Oracle 9 auch in ähnlicher Form.

Gruß
Jens


----------



## Manderby (2. Juli 2004)

> _Original geschrieben von JensG _
> 
> imp71 User/Kennwort File=C:\Test.dmp Tables=Tabelle1,Tabelle2
> 
> Vielleicht gibt es das unter Oracle 9 auch in ähnlicher Form.


Nun, ich habe den imp-Befehl gefunden und auch ausprobiert (Danke für den Tipp!). Ich hatte schon beinahe Freude, dass dies vielleicht funktionieren könnte, nun aber meldet das Terminal mir folgenden Fehler:


```
Export-Datei wurde von EXPORT:V09.02.00 über konventionellen Pfad erstellt
Importvorgang mit Zeichensatz WE8MSWIN1252 und Zeichensatz AL16UTF16 NCHAR druchgeführt.
. Import SYSTEM's Objekte in SYSTEM
. Import NETADM's Objekte in NETADM
IMP-00003: Oracle-Fehler 1435 gefunden
ORA-01435: Benutzer ist nicht vorhanden
Der Import-Vorgang endete erfolgreich mit Warnungen.
```

Nun, dass der Benutzer nicht existiert, kann ich mir noch gut vorstellen, denn ich bin ja nicht der gleiche Benutzer, wie derjenige, der diese Datenbank erstellt hat. Wie aber könnte ich diesen Benutzer denn nun erstellen, wenn ich keine Ahnung habe, wie dieser heisst (das wird er mir nämlich nicht verraten, da es sich um sensible Daten handelt, welche auf seinem Computer immer noch verwendet werden)?


----------



## Movera (2. Juli 2004)

Hallo,


das ist eine sehr mysteriöse Meldung, sowas habe ich bisher weder von Oracle noch von w2000 erhalten. 

Oracle bringt immer ordentliche Fehlermeldungen in der Form:

ORAXXXXX: Tabelle existiert nicht, o.ä.

Wahrscheinlich startest du den Import über irgendeine Oberfläche. Suche einfach im Verzeichnis c:\orant\bin nach einem Programm mit dem Namen ImpXX (XX steht für die Versionsnummer) und starte den Import von da aus. Es handelt sich um eine Konsolenanwendung mit der man den Import Dialoggeführt starten kann.



------------------------ hat sich gekreuzt ------------------------------------------


----------



## Movera (2. Juli 2004)

Während ich den vorigen Beitrag geschrieben habe kam dein Posting.

In älteren Versionen hat es gereicht, den Benutzer einfach anzulegen. Der Import hat kein Passwort verglichen sondern brav die Tabellen erzeugt. Wäre einen Versuch wert.


----------



## Manderby (2. Juli 2004)

> _Original geschrieben von Movera _
> *Während ich den vorigen Beitrag geschrieben habe kam dein Posting.
> *


Jup, habs gemerkt, trotzdem danke.

Das mit dem Benutzer hab ich natürlich schon versucht, aber wie gesagt, weiss ich dessen Name gar nicht (es sei denn, ich würde ihn tausendmal darum bitten, dass er mir Vertrauen soll und ihn nennen könnte). Ich habe, als die Aufforderung, einen Benutzernamen einzugeneb kam, innem Texteditor das DMP-File angekuckt, und da seh ich als einzigen Anhaltspunkt die folgenden Zeichen:

```
...EXPORT:V09.02.00..SYSTEM..USERS..2048.....
```
Aber viel nützt mir das nicht. Habs dann natürlich mit SYSTEM ausprobiert. Aber die Meldung war die oben dargestellte (und einen SYSTEM-User habe ich selbstverständlich).

Habe auch schon ausprobiert, nur eine Auflistung mir geben zu lassen, nix.

Thja. Wasnu? Wenns die einzige Möglichkeit ist, den Benutzernamen zu kennen, dann muss ich wohl oder über diese Möglichkeit ins Auge fassen. Ansonsten habe ich echt keine Ahnung mehr, was ich da machen könnte (es sah alles so gut aus am anfang ;( )



EDIT:

Ich habs versuchsweise mit NETADM versucht, und siehe da, es geht voran!

Aber viel weiter bin ich immer noch nicht. Bis jetzt konnte ich gerade mal die VIEWS importieren, für den Rest sagt er mir, dass der Benutzer zuwenig Rechte hat. Er hat jedoch ANY PRIVILEGES. (Sowohl derjenige, der den Import-Befehl startet, als auch derjenige, dem die Datenbank gehört)

?


----------



## Manderby (2. Juli 2004)

Ich habs geschafft!

Danke euch allen, die ihr mich unterstützt habt!

Das schlussendliche Problem waren noch einige Berechtigungs-Konflikte. Nachdem ich alle Benutzer sauber ausgeputzt hatte, gings auf einmal. Das Zeug ist jetzt alles da.

Juppiiiii!

BTW: Sehr gutes Forum!


----------



## duude (20. Juli 2006)

Hallo, 
habe leider das gleiche Problem - wissen Sie noch an welchen Berechtigungsproblemen es lag, bzw. wie oder welche Benutzer "sauber ausgeputzt" werden müssen?

Danke

S.Reuter


----------



## Exceptionfault (20. Juli 2006)

Zunächst mal 2 Dinge zum import.

1.) Es ist immer sehr sehr hilfreich zu wissen WIE der Export gemacht wurde. D.h. welche User exportiert wurden, mit welchen Parametern etc. Also grundsätzlich bei jedem Export und jedem Import ein Logfile generieren und zum Dump dazu legen

2.) Import und Export sollte immer mit dem User SYSTEM gemacht werden. Er hat die Rollen EXP_FULL_DATABASE und IMP_FULL_DATABASE.

Und nun der "im Normalfall" beste Aufruf für das Imp Utility:


```
imp username@datenbank file=importfile.dmp log=importfile.log ignore=y full=y
```

Ein Full Export würde man dann so machen:

```
exp username@datenbank file=exportfile.dmp log=exportfile.log compress=n direct=y consistent=y full=y statistics=none
```

Nun, und ab Oracle 10g nicht mehr imp und exp verwenden, sondern die DataPump, also impdp und expdp!


----------



## duude (20. Juli 2006)

Danke für die Antwort,

ich kann leider nicht sagen,  wie und von wem die export datei (xxx.dmp) generiert wurde. Somit weiss ich leider nicht, mit welchem Benutzer die Datei erstellt wurde. Habe den Import mit DataPump probiert, aber es kam ein Abbruch mit dem Hinweis das es eine normale imp Datei ist. Deshalb funktioniert es mit impdp anscheind nicht denke ich. Deshalb wollte ich den Weg über imp gehen. Dafür muss ich aber wissen, wie der Benutzer hieß der die Datei erstellt (fromuser=) hat, denn es erscheint laufend folgende Fehlermeldung:

IMP-00003: Oracle-Fehler 1435 gefunden
ORA-01435: Benutzer ist nicht vorhanden
Der Import-Vorgang endete erfolgreich mit Warnungen

An den Benutzernamen zu kommen ist mir im Moment nicht möglich. Vielleicht hat ja noch jemand einen Tip.

Danke


----------



## Exceptionfault (20. Juli 2006)

Mit welchem Benutzer meldest du dich denn an der Datenbank an ? SYSTEM ist hier immer richtig.
Wenn du den Parameter FULL=Y angibst, brauchst du die FROMUSER / TOUSER Parameter nicht. Dann legt er die User die fehlen an. (deshalb System, der darf nämlich User anlegen) Wichtig ist, dass du dazu auch den Parameter IGNORE=Y angibst. Der sorgt dafür, dass der Import auch dann weiter geht wenn du einen User importieren willst der schon da ist. In dem Fall werden die Importierten Daten zum Bestehenden hinzugefügt.

Und noch ein kleiner Tip: Ist ein Benutzer schon vorhanden und wird mit FULL=Y importiert, wird das Passwort des Benutzers auf das Passwort im Importfile gesetzt. Das ist normalerweise nicht weiter schlimm, wenn man aber nicht weiss, was im Importfile drin steht kann das gefährlich werden wenn z.B. das SYS Passwort überschrieben wird.
Daher am besten mit SQL*Plus an der Datenbank als User SYS anmelden. Dann Import fahren, und danach in SQL*Plus einfach mit ALTER USER SYS IDENTIFIED BY <altes Passwort> das Passwort wieder überschreiben. (sofern es überhaupt geändert wurde)
Somit ist sichergestellt, dass ihr zumindest mit dem SYS User noch in die Datenbank reinkommt.


----------



## duude (21. Juli 2006)

Vielen Dank für die Tips - jetzt es hat funktioniert . Noch mal vielen Dank für die Hilfe.


----------

